Request for support to filter any type of protocol in a ACL entry

[Pull-eckermann]

Request for support to filter any type of protocol in a ACL entry configuration

Problem

There are some systems that have support to ACL entry configuration without the needing of specify just one, or a group of protocols to permit/deny, but any protocol at same time.

In the current OpenConfig version, the configuration of protocol filter in ACL entry is defined int the leaf /acl/acl-sets/acl-set/acl-entries/acl-entry/ipv4/config/protocol with the type oc-pkt-match-types:ip-protocol-type. This type is based in the IP protocol numbers table, defined by IANA (https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml). The problem is that the IP protocol numbers table does not have a number that can be used to expecify "any protocol".

Ipinfusion OcNOS and CISCO supports this type of configuration, both using CLI or NETCONF configuration.
In OcNOS, the type is defined as a union of a set of enums and the uint8 range of "0..255". A enum named "any" receives the value 256 and is used to define in a ACL entry configuration that the filter is considered for any protocol. (line 700, acl_ip_protocol_names_t typedef from file https://github.com/IPInfusion/OcNOS/blob/OcNOS-SP-6.4.2/yang-files/ipi/acl/ipi-acl-types.yang)

Aproach proposal

It could be created one identity named IP_ANY with base IP_PROTOCOL, so that type ip-protocol-type can represent the configuration of any protocol in a ACL entry. (https://github.com/openconfig/public/blob/master/release/models/acl/openconfig-packet-match-types.yang)

[dplore]

Hi, can you provide some examples of ACL rules which use an IP protocol == ANY?

We are wondering if ANY is implicit when, for example, defining an ACL entry like:
source_address: 10.1.1.1 , destination_address: 10.2.2.2. action:deny
which would block all IP traffic (ie: any IP protocol) between these addresses.

[Pull-eckermann]

Hi dplore, thanks for the reply.

Specifying the protocol as "ANY" explicitly in an ACL entry could be beneficial for clarity and explicitness some scenarios.

We can see in CISCO systems that "ip" is always used in CLI ACEs configurations to especify an IP protocol == ANY. An example can be found here in the "Deny Telnet Traffic (TCP, Port 23)" scenario were telnet traffic is denied while all other IP traffic is permitted. To permit all other traffic the CLI "access-list 102 permit ip any any" is used, were the value ip refers to any protocol.

In the yang Cisco-IOS-XE-acl.yang, line 2526, we can also see that this "ip" enum is defined with the value 256, this to represent "any" protocol. Also, in cisco-xe-openconfig-acl-ext.yang, line 35 to 44, they've created a augmentation to define new identities in the OpenConfig model to define this values.

For Ipinfusion OcNOS we can also find an example of CLI configuration here in "ip access-list filter" example, were the option "any" is used to indicate permission of any protocol for the ACL created rule. Also, as pointed before, they defined the enum any with value 256 in their yang to represent this configuration.

Aruba Networks AOS also uses the "any" expecification in CLI commands as can be seen here.

As we can see, ANY protocol rule can be implicit in ACL rules like the mentioned one, but it would be good to have something to get this explicit, for the sake of clarity and explicitness, as the mentioned vendors do. It leaves no ambiguity about the intended behavior of the ACL rule.

I hope that this answer can help in the wonderings.

[LimeHat]

+1 to the implicit option. It is widely used in the industry.
It's not clear to me what's the benefit of making the protocol mandatory.

We can see in CISCO systems that "ip" is always used in CLI ACEs configurations to especify an IP protocol == ANY. An example can be found here in the "Deny Telnet Traffic (TCP, Port 23)" scenario were telnet traffic is denied while all other IP traffic is permitted. To permit all other traffic the CLI "access-list 102 permit ip any any" is used, were the value ip refers to any protocol.

permit ip here means that the traffic is ipv4 (identity ACL_IPV4 in OC terms), it doesn't say anything about the protocol field of the header (hence, it is also implicit in this example)

[github-actions]

This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.