[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]