Routed traffic and fragmented packets

Fragmented packets are problematic for IP security implementations because transport layer headers (UDP, TCP, and so on) are not present in every fragment. For some packet fragments, the transport layer selector values (for example, UDP ports, ICMP type and code) are indeterminate, which complicates IP packet filtering. In the case of IPv6, a fragment's IP protocol value might also be indeterminate.

Tip: z/OS® Communications Server filters fragmented packets only for routed traffic. For all local traffic, z/OS Communications Server performs filtering on the fully assembled packet.

Because some packet fragments do not contain the transport layer header and cannot be filtered based on transport layer selector values, z/OS Communications Server enforces the following restriction for routed traffic.

Restriction: All routed traffic between two endpoints must be filtered in the same manner without regard to TCP or UDP port, ICMP or ICMPv6 type and code, or OSPF and MIPv6 type.

Guideline: To perform more granular filtering for this traffic, enforce a port-specific filtering policy, or a type-specific and code-specific filtering policy, at the final destination for this IP traffic.

z/OS Communications Server supports the specification of Opaque for matching indeterminate IPv6 protocol values in packet fragments. Packets that have an indeterminate value match filter rules only when Opaque or Any is specified.

z/OS Communications Server also supports explicit matching on fragmented packets. The IpService policy object's fragment specification can be used to match any fragmented packet, even if the packet's selector values are known. Explicit matching can be used to deny all fragmented packets in situations in which they are not part of normal traffic patterns and are considered to be a security risk.