ACL Packet Length Matching - NCS55xx and NCS5xx

Introduction

Access Control Lists have been implemented for a long time now and has been integral part of data plane security for almost every organization.

Though everyone would be aware of what an access control list is, I would like to brush up some basics before deepdiving into complex functionalities.

ACL’s can be considered as an ordered list of conditions used to test the network traffic that traverses through the router interfaces. On the basis of the defined lists, the router decides which packets to accept and which to drop. ACL’s help in managing the traffic and secure the access to and from the network.

ACL’s can make permit/deny decisions based on source/destination address, source/destination ports, L3 protocols, L4 port numbers and many others.

Overview

Security ACL’s introduction, feature support and statistics is covered at high level in the Link

In this document, we will deepdive how the NCS55xx and NCS5xx program the packet length in the TCAM and use it to filter the packets. The main use case of this matching criteria is to identify malicious packet ranges entering the network and denying them.

ACL’s on NCS55xx and NCS5xx, uses the Programmable Mapping and Filtering (PMF) functionality and TCAM (internal/exertnal) in both the Ingress Receive Packet Processing (IRPP) blocks and Egress Receive Packet Processing (ERPP) blocks. The line cards in these platforms are based on the Broadcom family of chipsets. These chipsets uses a pipeline architecture which has dedicated hardware blocks for performing various functions.

ACL’s contains one or more ACEs which are used to match packets and perform an action on those packets. Typical action of the ACE is to either Permit or Deny. The TCAM is programmed with tables, may be like a database on which the match criteria and action criteria are performed.

In hardware, we have databases that are unique to each feature. For ACL, we have further defined unique databases based on these fields:

• Protocol (IPv4, IPv6, L2)
• Direction (ingress/egress)
• Compression (uncompressed/compressed)
• Default TCAM key or user-defined (UDK) TCAM key

Supported ACL Match Criteria

• Packet Length
• IP Fragmentation
• Source and Destination Port
• User Defined Keys - UDK
• User Defined Field - UDF

Note: We will have dedicated posts for explaining each matching criterias.

Header Definition - IPv4

In NCS55xx and NCS5xx, when we configure an ACE through CLI, the total IP packet includes only IPv4 header. As per the above figure, only IP payload is taken into the consideration when you define the packet length in an ACE. It does not include any L2 headers, including ethernet/vlan. Therefore, when matching the packets on the router, the layer 2 headers needs to be taken into consideration and the packet length value should be configured accordingly. We will see this with an example in later section.

Packet matching criterias

We have different criterias for the matching

RP/0/RP0/CPU0:N55-24(config-ipv4-acl)#40 permit ipv4 any any packet-length ?
   eq     Match only packets with a given value
  gt     Match only packet with a greater value
  lt     Match only packets with a lower value
  neq    Match only packets not on a given value
  range  Match only packets in the range of value
RP/0/RP0/CPU0:N55-24(config-ipv4-acl)#40 permit ipv4 any any packet-length 

ACL configuration

Lets us configure a simple ACL for matching packet length and attaching it to the interface

RP/0/RP0/CPU0:N55-24#show access-lists ipv4 test-acl-v4-pkt-length 
Thu Jul 23 06:46:11.884 UTC
ipv4 access-list test-acl-v4-pkt-length
 10 permit ipv4 any any packet-length eq 800
 20 permit ipv4 any any packet-length eq 1000
 30 permit ipv4 any any packet-length eq 1500
RP/0/RP0/CPU0:N55-24#

RP/0/RP0/CPU0:N55-24#show running-config interface tenGigE 0/0/0/0.10
Thu Jul 23 06:46:34.378 UTC
interface TenGigE0/0/0/0.10
 description using it for ACL testing
 ipv4 address 60.1.1.1 255.255.255.0
 load-interval 30
 encapsulation dot1q 10
 ipv4 access-group test-acl-v4-pkt-length ingress
!

Note: After IOS-XR release, 6.5.2 and later the packet length is not supported by default TCAM key and we need to configure a UDK to have it in the key.

hw-module profile tcam format access-list ipv4 src-addr dst-addr src-port dst-port proto packet-length frag-bit port-range

ACL Verification

Other show commands are extensively covered in the Link

Hardware or TCAM programming of the ACL

The above 2 output shows us that the IPv4 L3 ACL database is programmed and a Database ID is created for it. NPU details is extracted, dedicated to interface where the ACL is applied. We can see the bank_ID with the entry size as 320 bits. For more information on memory banks please Refer. This data/values will help us in understanding the values configured in the hardware.

The above output shows the TCAM programming of the packet length configured in Hexadecimal

Traffic Tests

• Below is the snapshot of the traffic stream used.
• It has a packet length of 822 bytes. (800 bytes plus 18 bytes of the Ethernet header + 4 bytes VLAN header)

The traffic is matching the first ACE with packet length of 800 bytes. As mentioned earlier, that the TCAM doesnt consider L2 headers. So the traffic stream has to be sent accordingly. In real production network, the ACE has to be configured accordingly so we can permit or deny legitimate packets. This can be done by configuring range command. It will be explained in the later section

RP/0/RP0/CPU0:N55-24#show access-lists ipv4 test-acl-v4-pkt-length hardware ingress location 0/0/CPU0
Thu Jul 23 08:40:42.081 UTC
ipv4 access-list test-acl-v4-pkt-length
 10 permit ipv4 any any packet-length eq 800 (4124541 matches)
 20 permit ipv4 any any packet-length eq 1000
 30 permit ipv4 any any packet-length eq 1500
RP/0/RP0/CPU0:N55-24#

Note: Permit ACL stats are not enabled by default. We need to configure the below hw-module profile to enable the same

hw-module profile stats acl-permit

Changing the frame size

Modifying the packet length to 800: traffic drops as the packet does not match any ACE. For the traffic to match we need to configure an ACE with packet length 800-22 = 778 bytes, due to the reason stated above.

RP/0/RP0/CPU0:N55-24#show access-lists ipv4 test-acl-v4-pkt-length hardware ingress location 0/0/CPU0
Thu Jul 23 08:49:28.720 UTC
ipv4 access-list test-acl-v4-pkt-length
 10 permit ipv4 any any packet-length eq 800
 20 permit ipv4 any any packet-length eq 1000
 30 permit ipv4 any any packet-length eq 1500
RP/0/RP0/CPU0:N55-24#

Packet Length range

For scenarios, where we are not sure on the absolute packet length, we have the option to configure range. In the below ACL, we have confgured 2 ACE’s. Sequence 10 is a range and sequence 20 is an absolute value.

ipv4 access-list test-acl-v4-pkt-length
 10 permit ipv4 any any packet-length range 800 1000
 20 permit ipv4 any any packet-length eq 1500

We can see that with range command only 8 (7+ 1 internal usage) entries are consumed in the TCAM. If we configure different values that would utilize one entry each.

Hardware Programming of the range

As per the above ACL, TCAM programmed values

When configuring the range command the algorithm takes into account the mask as well the value. For example, 3E0/FFF8 has 3E0 as value and FFF8 is mask. Accordingly it programs all the values in batches of entries for the given range into the TCAM. Let us understand, how the range is configured in the TCAM w.r.t value/mask pair and how to interpret it.

3E0/FFF8
3E0 -- Value
FFF8 -- Mask
FFF8 in binary is 1111111111111000
The last 3 bits are 0 
So we can program 2^3 = 8 values. Which means 3E0 to 3E7
3E0 = 992
3E7 = 999

• Hence, the key here is the bits in the mask with 0’s, according to which the values are programmed in the TCAM

Header Definition - IPv6

For IPv6 the “payload length” field in the packet does not include the IPv6 headers. It only covers the payload length (the data following this headers).The IPv6 header is assumed to be 40 bytes; so the configured ACE’s packet length is reduced by 40 bytes and this value is configured into the TCAM as the match criteria for the IPv6 header. For example, if the ACE is configured for the packet length of 200, the TCAM will configure it as 160

The IPv6 header is really not a fixed size, because there can be one or more extension headers. Currently, the hardware does not take this into consideration and simply assumes the IPv6 header is a fixed 40 bytes. We can similarly apply a IPv6 ACL and check the programming using the same commands.We will dedicate the a separate post for IPv6 Extension Header

Optimizing Memory usage

Sometimes in real production networks, we are not sure what packet length we will receive on the interface. Whether it have a VLAN header or not, or what will be the size of the packet. In this scenarios, it is recommended to use range option. This will help in optimizing resource utilization with lesser TCAM entries. For example, if we want to permit packets only with length 800 to 810 bytes while denying others. This will consume 13 entries in the TCAM

• Instead of using the individual ace’s if we use range option, we will use only 5 entries

References

• Security ACL’s on NCS5500
• CCO documentation

Summary

Hope this document helps to understand the matching criteria on the basis of packet length. This can be particularly useful in mitigating packets with sizes which are known for malicious behaviour. Those can be detected and prevented from causing data plane security issues.

We also saw how to utilize the internal tcam resources optimally by using range command. This is particularly useful when we have many ACE’s in traditional ACL’s. Configuring higher or lower packet length doesnt cause the TCAM entries to increase.

Stay tuned for the next matching criteria and its interpretation at the hardware level.