Default Direction

[alevere]

I propose that default direction is changed from "both" to "ingress" . If the directional argument is not specified, it shall be assumed the intended direction is either not applicable or inbound/ingress.

[jmbrule]

‘Not applicable’ does not make sense to me. The address (or port or whatever) has to be either a source , destination or both. What does not applicable mean?

[Vasileios-Mavroeidis]

For firewalls that have one interface, ingress is the traffic from the internet to the internal networks. Egress is the traffic from inside to outside. For other firewalls that have more than one interface (like a router), the interface (at the LAN side) defines as ingress the traffic originating from the internal network that goes out. For the interface at the internet's side ingress is the incoming traffic again.

Machines are supposed to be absolute and unmistakable. Humans though tend to do mistakes and a "default both" may save the situation (blocking malicious traffic from the inside and outside). On the other hand, this floods the fw with rules because a rule has always a direction defined (explicitly in the rule or the basic configuration of the firewall).

[jmbrule]

When I think of the terms 'ingress' and 'egress', I think of it from the perspective of an autonomous system (AS), i.e. a collection of nodes within some administrative entity.

Given that perspective, then 'ingress' is any traffic that is coming into your AS that originated from another AS and 'egress' is any traffic that was generated in your AS and destined for another AS.

If I read the last comment correctly, then the term 'ingress' vs 'egress' is from the perspective of the location of the NIC? and not the AS? If that is in fact the case, then the selection of the terms ingress and egress were unfortunate. From an effects based point of view, the ability to add precision to the command (in terms of whether it originated from our AS vs an external AS) has value. Requiring the orchestrator to keep track of all the network interface cards and change the terms ingress and egress in accordance with the context of the NIC is complex and prone to error.

My suggestion, spell out that desired effect of the direction argument and leave it to the implementer to comply.

This topic illustrates the concern of bubbling each and every argument up to the language specification. Do we really want to go down a path where we define ALL command arguments and capture the nuances for ALL possible actuators as it applies to ALL potential cyber eco-systems into a SINGLE language specification? It makes sense to leave the semantics, syntax, abstract actions and targets in the overarching language specification and use the actuator profiles to put it in the context of the actuator. Arguments by their very nature refine or add precision to a command. This is best done if it is in the context of a particular actuator.

[jmbrule]

In the context of @alevere 's original issue; His logic is fine, in fact it makes sense that the 'default' is to filter the traffic coming in and you dont want a 'default' that overloads or is excessively burdensome. The comment made by @Vasileios-Mavroeidis adds a nuance that I had not considered. If I understand the comment correctly, the firewall industry uses the NIC as the origin.
Propose that additional text be added to the SLPF to state that in the context of OpenC2, ingress is to mean source

and egress is to mean dst

.
Logical?

[Vasileios-Mavroeidis]

What source and destination means in this particular context. Incoming and outgoing traffic?

If we want to be specific we would need something like: ingress is traffic originating outside a local network that is transmitted to an entity within a network and the opposite for egress.

The definitions right now are ok I think, and also apply to my use case as well. Maybe to avoid disappointments we should just eliminate the option of treating a non-populated direction argument as "both". If it is treated as both then we don't even need the 3rd option "both" in table 2.1.3-2.

If you believe that ingress is the right way to go, I'm ok, but I would still eliminate the non-populated directionality to be treated as both.

I really want to understand why do we give extra weight to ingress traffic. My logic says that an internal station will contact a particular malicious IP and what we do right now is blocking both directions. Having default ingress means that I can contact the malicious server but the server cannot contact me back. In any case, I just send an indicator that I am compromised but you cannot contact me on the IP that I have blacklisted. I wouldn't like that.

[jmbrule]

In the context of your question 'why do we give extra weight to ingress?' I defer to you and Alex.

[jmbrule]

@alevere and @Vasileios-Mavroeidis , can you resolve the 'extra weight to ingress' vs 'both' matter? I am not qualified to provide an opinion one way or the other, but would like to get this one resolved.

[Vasileios-Mavroeidis]

I would go with the notion of having the directionality required if we want to avoid issuing double rules. Otherwise, I would leave it "both" for fault-tolerance, especially in the era of IPV6. We can also have additional text such as "in the cases of IPV4 and 6 net the use of directionality is recommended for avoiding rule duplication".

Still, required directionality would solve ambiguities.

[jmbrule]

Leaning towards 'otherwise leave it both for fault tolerance'. I do not know if this is a problem or not so request that people step in and tell me it is a non-issue. As of now, the language spec has arguments as an option and there is no other command that 'requires' an argument. Not stating it is an issue, but worth thinking about before 'requiring the direction' argument.
Alex? Vasileios? Other firewall experts?

[alevere]

@Vasileios-Mavroeidis is right, typically ingress is viewed from the system that is affected by the change. For a server, that is the NIC. For an enterprise firewall, it may be the network or networks. Regarding not applicable, for instance, some Palo Alto Networks/Juniper devices do not have a direction requirement. Since one specifies the zones, directionality is known/implicit (e.g. rule is from zone A to zone B or vice versa). @Vasileios-Mavroeidis also specified what I typically see implemented in lists. If an IP address is in the list, the device reads both the src and dest of each IP packet. If either src/dst match an entry, the packet is discarded. So, direction is either both or not applicable depending on one's perspective. Lastly, yes, ingress is the typical default and most common request type.

[alevere]

I also plan to clarify what direction means: Direction is required by some packet filters. For a host-based or host interface-based packet filter, inbound indicates a packet that originated from a different host. For a network-based packet filter ,such as a router or a switch, ingress indicates a packet entering a physical or logical interface that your organization controls.

pkt ----> to Host (ingress) <--- pkt generated by Host (egress) pkt ----> eth0_Router_eth1---->Host (ingress to eth0, egress from eth1)

[Vasileios-Mavroeidis]

Your description looks adequate and understandable for the different use cases and types of SLPF.

1) End-device fw 2) Intermediary device fw

This description allows changing the default directionality when the argument is not specified from “both" to “ingress" and be fault tolerant now (it is explained why on 113 GitHub issue).

[alevere]