Paloalto - Packet Flow

PAN-OS: Day in the life of a packet Packet flow sequence in PAN-OS October 2010 Palo Alto Networks 232 E. Java Dr. Sunnyvale, CA 94089 408.738.7700 www.paloaltonetworks.com

© 2010 Palo Alto Networks Page 2

Table of Contents Overview ............................................................................................................................................ 3 Ingress Stage ..................................................................................................................................... 3

Packet Parsing................................................................................................................................ 5 Tunnel decapsulation ......................................................................................................................... 6

Flood and per-packet anomaly detection ....................................................................................... 8 TCP state check ............................................................................................................................. 8 Forwarding setup ............................................................................................................................ 8

Interface Mode ............................................................................................................................ 8 Forwarding action........................................................................................................................ 8 Tap .............................................................................................................................................. 8 Virtual Wire.................................................................................................................................. 8 Layer 2 ........................................................................................................................................ 8 Layer 3 ........................................................................................................................................ 8

NAT policy lookup........................................................................................................................... 9 User ID............................................................................................................................................ 9 Security policy lookup..................................................................................................................... 9 Session allocation........................................................................................................................... 9

Firewall session fast path................................................................................................................. 10 Application Identification................................................................................................................... 10 Summary .......................................................................................................................................... 11


Overview This document describes the packet handling sequence inside of PAN-OS device. The ingress and forwarding/egress stages handles network functionalities to make packet forwarding decisions on per packet basis. The rest of stages are flow-based security modules highlighted by App-ID and Content-ID. This decoupling offers stateful security functions at application layer, and the resiliency of per-packet forwarding, and flexibility of deployment topologies. Security policies are always evaluated whenever there is an application change either from unknown to a known one, or from a tunneling application to tunneled application.

Ingress Stage Ingress stage receives packet from the network interface, parses the packet and determines whether the given packet is subject to firewalling. If the packet is subject to firewalling then continue with firewall session lookup and enter security processing stage, otherwise forward the packet. Note: During packet processing, a packet may be discarded because of protocol violation. In certain cases which are considered firewall attack prevention features the packet maybe discarded without configurable options because those packets will eventually be discarded by the end hosts.



Packet Parsing

Packet parsing starts with layer2 header of the packet received from interface, Layer2: The ingress-port, 802.1q tag, destination MAC address is used as key to lookup ingress logical interface. If interface is not found the packet is discarded. The hardware interface counter "receive error" and global counter “flow_rcv_dot1q_tag_err” are incremented.

Layer3: The IP header is parsed.

IPv4: A packet can discarded for any one of the following reasons

• Mismatch of Ethernet type and IP version

• Truncated IP header

• IP protocol number 0

• TTL zero

• Land attack

• Ping of death

• Maritain IP address

IPv6: A packet can discarded for any one of the following reasons

• mismatch of Ethernet type and IP version,

• truncated IPv6 header,

• truncated IP packet (IP payload buffer length less than IP payload field),

• JumboGram extension (RFC 2675),

• truncated extension header

Layer 4:

TCP: The packet is discarded if • TCP header is truncated,

• data-offset field is less than 5

• Checksum error,

• port zero

• invalid combination of TCP flags

UDP: The packet is discarded if • UDP header truncated,

• UDP payload truncated (not IP fragment, and

• UDP buffer length less than UDP length field)

• Checksum error


Tunnel Decapsulation Tunnel decapsulation/decryption is also performed at the parsing stage. After parsing, if the packet is determined that it matches tunnel, i.e. IPSec, SSL-VPN with SSL transport, then the following sequence is executed:

• packet will be decapsulated first, discarded if any error, • the tunnel interface associated with the tunnel will be assigned to packet as new ingress

interface, then packet will be fed back to parsing process, starting with packet header defined by tunnel type.

Currently all supported tunnel types are IP layer tunneling, thus packet parsing (for tunneled packet) starts with IP header.

IP Defragmentation IP fragments will be parsed, be reassembled by defragmentation process and fed back to the parser starting with IP header. A fragment may be discarded due to tear-drop attack (overlapping fragments).

Firewall Session Lookup A packet is subject to firewall processing depending on the packet type and the interface mode. The table below summarizes the packet processing behavior for a given interface operation mode and packet type.

Interface Operational Mode

Virtual wires

Packet type

Layer3 Layer 2 Default Multicast

firewalling on IPv6-

firewalling on

Tap

IPv4 unicast

Inspect and

forward

Inspect and

forward

Inspect and

forward

Inspect and forward

Inspect and forward

Inspect and drop

IP limited broadcast

drop forward ( flood)

forward Inspect and forward

forward drop

IP directed broadcast

drop forward ( flood)

forward Inspect and forward

forward drop


If the packet is subject to firewall inspection, flow lookup is performed on the packet. A firewall session consists of two unidirectional flows each uniquely identified by 6-tuple key. In PAN-OS implementation a flow is uniquely identified using a 6-tuple key.

• Source and destination addresses: IP addresses from the IP packet. • Source and destination ports: Port numbers from TCP/UDP protocol headers. For

non-TCP/UDP, different field from protocols are used. For ICMP, ICMP identifier and sequence numbers are used, for IPSec SPI is used to identify the flow and GRE call ID is used for PPTP.

• Protocol: The IP protocol number from the IP header is used to derive the flow key • Security zone: This field is derived from the ingress interface at which a packet

arrives. Active flows are stored in the flow lookup table. When a packet is determined to be eligible for firewall inspection, the 6-tuple flow key is extracted from the packet and flow lookup is performed to match the packet with an existing flow. Each flow has a client and server component, where client is sender of the first packet of the session from firewall perspective, and server is receiver of this very first packet. Note: The distinction of client and server is from the firewalls point of view and may or may not be the same from the end hosts point of view. Based on above definition of client and server there will be a client-to-server (C2S) and server-to-client (S2C) flow , where all client-to-server packets should contains same key as that of C2S flow, and so on for S2C flow.

Interface Operational Mode

Virtual wires

Packet type

Layer3 Layer 2 Default Multicast

firewalling on IPv6-

firewalling on

Tap

Martian address

drop drop drop drop drop drop

IPv6 drop forward forward Inspect if IPv6

firewalling is on

Inspect and forward

drop

Non-IP process if applicable

forward forward forward forward drop


Firewall Session Setup The following steps are taken to setup a firewall session

Flood and per-packet anomaly detection

Once the packet arrives on a firewall interface, the ingress interface information is used to determine the ingress zone. If there are any zone protection profiles configured for that zone, the packet is subject to evaluation as configured in the zone protection profile.

TCP state check

For any first TCP packet that does not have SYN bit set will be discarded. If SYN flood settings are configured in the zone protection profile, then TCP SYN cookie is triggered if the number of SYN matches the activate threshold. SYN cookie implementation works as follows:

• The seed to encode cookie is generated each time dataplane boots up via random number generator

• If an ACK packet received from the client does not match cookie encoding, it treats the packet as non-SYN and discards the packet.

• A session that passes SYN cookies process are subject to TCP sequence number translation as firewall acted as proxy for TCP 3-way handshake.

Note:

I. The firewall can be configured to allow the first TCP packet even if it does not have SYN bit set. Even though this is not a recommended setting, scenarios with asymmetric flow will require this

II. It is recommended to have firewall set to reject TCP non-SYN when SYN cookies are enabled.

Forwarding setup

This stage determines packet forwarding path. Packet forwarding depends on the way firewall interface is configured. The table below summarizes packet forwarding behavior. Interface Mode Forwarding action Tap Egress interface/zone is the same ingress interface/zone. The packet is

discarded Virtual Wire Egress interface is the peer interface configured in the virtual wire Layer 2 Egress interface for the destination MAC is retrieved from the MAC

table. If the information is not present the frame is flooded to all interface except the ingress interface in the VLAN

Layer 3 Route table lookup is used to determine the next hop


NAT policy lookup

This is applicable only in layer 3 mode. At this stage the ingress and egress zone information is available. NAT rules are applied to the original packet.

• For destination NAT, a second route lookup for the translated address is performed to determine the egress interface

• For source NAT, the IP address is translated as the packet forwarded out via the egress interface.

Note: For more information on NAT, refer to the document Understanding PAN-OS NAT.

User ID

If the user information is not available for the IP address, and the packet is destined to TCP/80, a captive portal rule lookup is checked to see if the packet is subject to captive portal authentication. If captive portal is applicable, the packet is redirected to the captive portal daemon

Security policy lookup

At this stage the ingress and egress zone information is available. If the security policy action is to allow the packet, the packet is forwarded out via egress interface. If the policy action is deny, the packet is dropped. Any traffic that does not match a security rule is denied. Any intra zone traffic is permitted by default. Note: Security rules are applied to the contents of the original packet, even there are NAT rules configured Port scan/ Address sweep protection Port scan and address sweep protection is enforced if zone protection profile is configured on the ingress zone

Session allocation

A new session entry from the free pool will be allocated once all of the above steps are successfully completed. Session allocation failure may occur at this point due to resource constraint

• VSYS session maximum reached, or • All available sessions are allocated,

Once the session allocation is successful

• Session content will be filled with flow keys extracted from packet and forwarding/policy results

• Session state changes from INIT (pre-allocation) to OPENING (post-allocation) • If the application has not identified, the session timeout value is set to default value of the

transport protocol


Firewall session fast path

A packet that matches an existing session will enter the fast path. This stage starts with Layer2 to layer4 firewall processing,

• If the session is in discard state, then the packet will be discarded. A session can be marked as discard state due to a policy action change to deny, or a threat detected.

• If the session is active, refresh session timeout • If the packet is a TCP FIN/RST, the session timeout is changed to timeout-tcpwait value • If NAT is applicable, translate the L3/L4 header if applicable.

A packet matching an existing session is subject to layer7 processing if any of the following, condition matches.

• Packet has TCP/UDP data, or it is a non-TCP/UDP packet • If session application is not detected yet, application identification is performed. • A session that has application identified will be subject to content inspection, either

because of the application itself requires content inspection, if an ALG is involved, application is tunneled application, or the security rule has security profile associated.

If a application uses TCP as transport, it will be processed by TCP reassembly module before stream data is fed to layer7 module. TCP reassembly module will also perform window check, buffer out-of-order data and skip TCP retransmission.

Application Identification (App-ID) Application Identification consists of two cases:

a) Session application from undecided to defined one, and b) From one defined application to another

Application-override policy lookup is done first to see if there is matched rule. If so we have an application. If there is no application override rule, then application signature are used to identify the application. Once the application is matched the destination IP/port/ and protocol that identifies the application is stored into App-ID cache to speed up subsequent lookups if applicable. For application changing from one to another, is done via protocol decoding in content inspection, After session application is identified, access control, content inspection, traffic management and logging will be setup as configured.

• Security policy lookup: The identified application as well as IP/port/protocol/zone/user in the session as keys to find rule match.

• If security policy has logging enabled at session start, there will be a traffic log generated • If security policy has associated profile and/or application is subject to content inspection,

setup content inspection session • If security policy action is allow, perform QoS policy lookup and assign matched QoS class • If security policy action is allow application is SSL, perform SSL decryption policy lookup

and setup proxy contexts if there is decryption rule match


Summary Palo Alto Networks next-generation firewalls are based on a unique Single Pass Parallel Processing (SP3) Architecture – which enables high-throughput, low-latency network security, even while incorporating unprecedented features and technology. Palo Alto Networks solves the performance problems that plague today’s security infrastructure with the SP3 architecture, which combines two complementary components-Single Pass software, Parallel Processing hardware. The results is the perfect mix of raw throughput, transaction processing and network security that today’s high performance networks require.

Documents

Paloalto - Packet Flow