OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

openc2-actuator message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Firewall Profile: Target types and specifiers


Actuator Profile SC, 

I ran into some interesting questions while going through the target types and request feedback on the following five questions: 

QUESTION ONE: 
The current draft has the ip-connection target type which is:  src address, dest address, src port, dest port and next protocol
The current draft also has the ip-addr target type
So the question is, do we really need the ip-addr?  It seems to me that we can just have the ip-connection target type and you don't have to specify the complete five-tuple.  Logical?  

QUESTION TWO:  
During one of the AP biweeklies, one of the members stated we need to be able to specify if the deny or allow is for the inbound or outbound traffic.  
I cooked up a specifier called 'interface' and then say the allowable values are 'ingress', 'egress' or both.  
So the question is:  are these the correct terms?  Or should we use something else such as outbound, inbound,  or internal, external?  
Also, I assume the default value should be 'both'.  Correct?  

QUESTION THREE: 
During one of the AP biweeklies, one of the members suggested we have a 'heartbeat' target type for query.  The use case is along the lines of the orchestrator wants to confirm that the actuator is up and running and sends a 'query heartbeat' and I suspect that the appropriate response code is 200 (or 401)  
So the question is:  Is 'heartbeat' ok for the target type?  
BTW, I did get two comments on this topic:  
Comment one:  We don't need the heartbeat target type because you can handle that at layer four.  
Comment two:  Rather than have a 'heartbeat' target type, simply define 'heartbeat' as one of the specifiers in the (preexisting) openc2 target type.  

QUESTION FOUR:  
The persistent option results in a permanent rule that will be retained in the event of a powerdown, restart or reset.  The running option results in an ephemeral rule that is active while the firewall is running, but not retained after a reset.  
There are two questions here:  Question one, which should be default (there was a slight preference for persistent during the last teleconference).  Question two, should we bubble this one up to the LSC or do you see it as more of a niche?     

QUESTION FIVE: 
In the current language spec, we have the following command options: start-time, stop-time and duration.  
I would argue that for the firewall profile, we can use 'stop-time' OR 'duration' but we probably should not have both because having both leads to some ambiguity wrt how one builds the command.  
Question, should we have stop-time or 'duration'?  












[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]