IPv6 Flow-Based Processing

IPv6 advanced flow adds IPv6 support for firewall, NAT, NAT-PT, multicast (local link and transit), IPsec, IDP, JSF framework, TCP Proxy, and Session manager on SRX Series Firewalls. MIBs are not used in the IPv6 flow.

In order to avoid the impact on the current IPv4 environment, IPv6 security is used. If IPv6 security is enabled, extended sessions and gates are allocated. The existing address fields and gates are used to store the index of extended sessions or gates. If IPv6 security is disabled, IPv6 security-related resources are not allocated.

New logs are used for IPv6 flow traffic to prevent impact on performance in the existing IPv4 system.

The behavior and implementation of the IPv6 advanced flow are the same as those of IPv4 in most cases.

The implementations of sessions, gates, ip-actions, processing of multithread, distribution, locking, synchronization, serialization, ordering, packet queuing, asynchronous messaging, IKE traffic issues, sanity check, and queues for IPv6 are similar to IPv4 implementations.

Some of the differences are explained below:

• Header Parse IPv6 advanced flow stops parsing the headers and interprets the packet as the corresponding protocol packet if it encounters the following extension headers:

  • TCP/UDP

  • ESP/AH

  • ICMPv6

  IPv6 advanced flow continues parsing headers if it encounters the following extension headers:

  • Hop-by-Hop

  • Routing and Destination, Fragment

  IPv6 advanced flow interprets the packets as an unknown protocol packet if it encounters the extension header No Next Header

• Sanity Checks— IPv6 advanced flow supports the following sanity checks:

  • TCP length

  • UDP length

  • Hop-by-hop

  • IP data length error

  • Layer 3 sanity checks (for example, IP version and IP length)

  • ICMPv6 Packets In IPv6 advanced flow, the ICMPv6 packets share the same behavior as normal IPv6 traffic with the following exceptions:

    • Embedded ICMPv6 packet

    • Path MTU message

• Host Inbound and Outbound Traffic IPv6 advanced flow supports all route and management protocols running on the Routing Engine (RE), including OSPF v3, RIPng, Telnet, and SSH. Note that no flow label is used in the flow.

• Tunnel Traffic IPv6 advanced flow supports the following tunnel types:

  • IPv4 IP-IP

  • IPv4 GRE

  • IPv4 IPsec

  • Dual-stack lite

• Events and Logs The following logs are for IPv6-related flow traffic:

  • RT_FLOW_IPVX_SESSION_DENY

  • RT_FLOW_IPVX_SESSION_CREATE

  • RT_FLOW_IPVX_SESSION_CLOSE

This topic introduces the architecture for the SRX5400, SRX5600, and SRX5800 devices. Flow processing on these devices is similar to that on branch SRX Series Firewalls.

These devices include I/O cards (IOCs) and Services Processing Cards (SPCs) that each contain processing units that process a packet as it traverses the device. These processing units have different responsibilities.

• A Network Processing Unit (NPU) runs on an IOC. An IOC has one or more NPUs. An NPU processes packets discretely and performs basic flow management functions.

  When an IPv6 packet arrives at an IOC, the packet flow process begins.

  • The NPU performs the following IPv6 sanity checks for the packet:

    • For the IPv6 basic header, it performs the following header checks:

      • Version. It verifies that the header specifies IPv6 for the version.

      • Payload length. It checks the payload length to ensure that the combined length of the IPv6 packet and the Layer 2 header is shorter than the Layer 2 frame length.

      • Hop limit. It checks to ensure that the hop limit does not specify 0 (zero).

      • Address checks. It checks to ensure that the source IP address does not specify ::0 or FF::00 and that the destination IP address does not specify ::0 or ::1.

    • The NPU performs IPv6 extension header checks, including the following:

      • Hop-by-hop options. It verifies that this is the first extension header to follow the IPv6 basic header.

      • Routing extension. It verifies that there is only one routing extension header.

      • Destination options. It verifies that no more than two destination options extension headers are included.

      • Fragment. It verifies that there is only one fragment header.

      Note:

      The NPU treats any other extension header as a Layer 4 header.

    • The NPU performs Layer 4 TCP, UDP, and ICMP6 protocol checks, including the following:

      • UDP. It checks to ensure that IP Payload Length packets, other than a first-fragment packet, are at least 8 bytes long.

      • TCP. It checks to ensure that IP Payload Length packets, other than a first-fragment packet, are at least 20 bytes long.

      • ICMPv6. It checks to ensure that IP Payload Length packets, other than a first-fragment packet, are at least 8 bytes long.

  • If the packet specifies a TCP or a UDP protocol, the NPU creates a tuple from the packet header data using the following information:

    • Source IP address

    • Destination IP address

    • Source port

    • Destination port

    • Protocol

    • Virtual router identifier (VRID)

      The device looks up the VRID from a VRID table.

  • For Internet Control Message Protocol version 6 (ICMPv6) packets, the tuple contains the same information as used for the TCP and the UDP search key, except for the source and destination port fields. The source and destination port fields are replaced with the following information extracted from the ICMPv6 packet:

    • For ICMP error packets: The pattern "0x00010001"

    • For ICMP information packets: The type, or code, field identifier

  • For packets with an Authentication Header (AH) or an Encapsulating Security Payload (ESP) header, the search key is the same as that used for the TCP and the UDP tuple, except for the source and destination port fields. In this case, the security parameter index (SPI) field value is used instead of the source and destination ports. For Encapsulating Security Payload (ESP) header and Authentication Header (AH), before enhancements to the cenral point architecture it is hashed by the 3-tuple and the security parameter index (SPI) field, after enhancements to the cenral point architecture it is hashed by an IP pair.

  • If a session exists for the packet’s flow, the NPU sends the packet to the SPU that manages the session.

  • If a matching session does not exist,

    • The NPU sends the packet information to the central point, which creates a pending session.

    • The central point selects an SPU to process the packet and create sessions for it.

    • The SPU then sends session creation messages to the central point and the ingress and egress NPUs, directing them to create a session for the packet flow.

• A central point, which can run on a dedicated SPU, or share the resources of one if there is only one SPU. A central point takes care of arbitration and allocation of resources, and it distributes sessions in an intelligent way. The central point assigns an SPU to be used for a particular session when the SPU processes the first packet of its flow.

  • For SRX5000 line devices, the central point architecture is divided into two modules—the application central point and the distributed central point (DCP). The App-CP is responsible for global resource management and loading balancing, while DCP is responsible for traffic identification (global session matching). The App-CP functionality runs on the dedicated central point SPU, while the DCP functionality is distributed to the rest of the SPUs.

• One or more SPUs that run on a Services Processing Card (SPC). All flow-based services for a packet are executed on a single SPU, within the context of a session that is set up for the packet flow.

  The SPC for SRX5000 line devices has two SPUs.

  Several SPCs can be installed in a chassis.

  Primarily, an SPU performs the following tasks:

  • It manages the session and applies security features and other services to the packet.

  • It applies packet-based stateless firewall filters, classifiers, and traffic shapers.

  • If a session does not already exist for a packet, the SPU sends a request message to the NPU that performed the search for the packet’s session, to direct it to add a session for it.

These discrete, cooperating parts of the system store the information identifying whether a session exists for a stream of packets and the information against which a packet is matched to determine if it belongs to an existing session.

• Purpose
• Action