Practical IPv6 Filtering

1. Practical IPv6 Filtering Ben Eater eater@juniper.net

2. IPv4/IPv6 Feature Parity • Features and tools will lag • Vendors need to figure out what will be useful before committing engineering resources • Not everything published in an RFC will get implemented • Early adopters like DREN are instrumental in guiding this process • Once basic IPv6 forwarding is implemented, most other features can be easily added • Filtering (and features that rely on it) presents additional challenges

3. Filtering IPv6 • Filtering is required to implement many security mechanisms • Simple accept/discard actions • Selecting traffic to monitor/log/count/mirror • Rate limiting • Policy route, QoS handling, others… • Filtering IPv6 traffic presents some challenges.

4. Filtering IPv6 in Software • Pros • Very easy to do • Cons • Lack of predictable performance • Impossible to use in high-bandwidth applications • Lack of headroom can allow attacks to exhaust limited CPU resources even in lower bandwidth applications

5. Filtering IPv6 in Hardware • Pros • Predictable performance • Performance under load (or during an attack) • Cons • Most (but not all) existing equipment will need totally new hardware to support IPv6 • State of the art in hardware-based filtering evolved with IPv4 in mind.

6. IPv4 Filtering Assumptions • To filter on any field in the L3/L4 header: • Look at a fixed offset into the packet • Match based on the bits you find at that offset • This model breaks in the presence of IP options • Most (all?) network operators drop all IP-option packets anyway

7. IPv6 Filtering • IPv6 uses extension headers • An arbitrary number of extension headers can be chained together • Header fields are no longer always in the same place • Hardware filtering technology designed for IPv4 can’t cope

8. So what can current HW do? • The IP header is always in the same place • Source address • Destination address • Class of service • Flow label • Packet length • Next header

9. So what can current HW do? • If there are no other extension headers • TCP, UDP, ICMP, ESP, AH, etc. header will be next • These headers are now in a predictable location • If there are other extension headers • There is no way to find the TCP, UDP, or ICMP header. • What do we do? • Permit the packet • Drop the packet

10. Extension Headers • Hop-by-Hop Options Header • Used for router alert. • Specified as an IP option in IPv4 • Not widely used in IPv4 • Routing Header • Used for source routing • Not widely used in IPv4

11. Extension Headers • Fragment Header • IPv6 fragmentation is only done by the sending node • Sender really should use PMTU discovery • Effective PMTU discovery obviates fragmentation • Destination Options Header • Only defined option is padding the packet to a 64-bit boundary

12. Drop packets with Extension Headers? • IPv4 IP-Options packets • Require extra processing by routers • Can’t be filtered in hardware • None of the defined options are widely used • Most network operators simply drop them • IPv6 Extension headers • Doomed to a similar fate?

13. Practical filtering of IPv6 • Near Term • Network operators will drop all packets with extension headers • Normal filtering is possible • Longer Term • A “killer app” would be required to rejuvenate interest in using extension headers • Barring this, I don’t see how extensive effort would be expended to support extension headers

14. Thank you!eater@juniper.net