[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Firewall Profile: Target types and specifiers
|
From: openc2-actuator@lists.oasis-open.org <openc2-actuator@lists.oasis-open.org> on behalf of Brule, Joseph M <jmbrule@radium.ncsc.mil>
Sent: Tuesday, April 3, 2018 10:10 AM To: 'openc2-actuator@lists.oasis-open.org' Subject: [openc2-actuator] 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? --- We could, though I think most of the use cases would be block this IP as a source or destination, so that may be odd to think of using ip-conn. I think you would have to make two calls to do that which would be counterintuitive. I think the common case is you just want it blocked, you dont care about the details. 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? --- I think this could get too complicated. Blocking an IP seems to me to be something that is easy to understand and probably implement for a packet filter or firewall. Directionally blocking is more of a feature of a stateful firewall. If we decide to support this for a stateless
firewall, it gets pretty complicated quickly. We probably then need to support TCP flags, group names, ACL names, physical and logical interfaces, policy names, etc. I just dont know how a packet filter service would know exactly what to do with the command.
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. --- I am leaning towards this is a good feature and leaning toward comment 2. 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? -- I would lean towards persistent. You really dont want an undetermined outcome just because of a reboot or reload of rules. Also, many firewalls and packet filters dont support this transient only config. 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'? -- duration seems more logical to me. Just keep in mind that there are probably few firewalls that would support this option initially. -Alex
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]