IP Router-Alert Considerations and usage draft-rahman-rtg-router-alert-considerations-00

1. IP Router-AlertConsiderations and usagedraft-rahman-rtg-router-alert-considerations-00 Reshad Rahman, Editor

2. Additional Contributors • Adrian FarrelOldDog Consulting • Tony LiEricsson • David WardFrancois LeFaucheurAshok NarayananCisco

3. The problem • Perception that IP Router-Alert is a security threat • RFC2113 just says “packets with this option must be examined further by the router” • Efficient fast path implementation unclear • Fast path punts all IP Options packets to RP • High cost to routers which don’t need to process the packets received with IP RAO • Attack vector against router CPU/backplane • Some networks respond by dropping IP RAO packets at the edge • Protocols using IP RAO are viewed as “dangerous”

4. Agenda • IP Router-Alert in E2E Applications • IP Router-Alert in Networks • Example router protection mechanisms • Possible standards work to improve IP RAO • Questions

5. IP Router Alert in E2E Applications • End-to-end application/protocol use of IP Router-Alert is questionable at best • Delivery is not guaranteed end-to-end • Intermediate routers could drop these, or turn off IP RAO • Desired service unlikely to be received from SP routers • Therefore, new application use of IP Router-Alert is currently considered harmful and strongly discouraged • Existing applications… • MUST NOT extend their use of IP RAO • MUST NOT propose extensions that need IP RAO in an E2E manner • SHOULD document RAO limitations for E2E use • MAY investigate reduction or removal of IP RAO use

6. IP Router Alert in Networks • “Walled-garden” networks can safely deploy applications with IP Router-Alert, if they can protect themselves against IP RAO attack from untrusted nodes. • Existing applications MAY continue to use IP RAO in a walled-garden network • Networks exposed to IP RAO attacks from untrusted nodes SHOULD take action to mitigate this attack. • Systematic dropping of IP RAO packets is undesirable. Networks should protect themselves, in this order of preference: • Implement IP RAO protection mechanisms on routers • Encapsulate and transport IP RAO packets across network • Remove IP RAO option and forward packet • Drop packet

7. Router Alert Protection Mechanisms • Don’t automatically punt all packets with IP RAO option • Unless protocol of interest is enabled, forward in fast path • Configuration should be per-interface and/or global • Don’t punt packets for unknown or unsupported protocols • Rate-limit all punted & locally addressed packets • Different queues for different IP-RAO protocols • Ability to control rate-limiting per interface and box-wide • For RAO option value 0, look at IP Protocol ID • Keep table of matching IP PIDs of interest • Don’t punt anything with a different PID

8. Standards extensions to IP RAO • Main weakness in IP RAO is lack of definition in determining packets of interest • For Option Value 0, filter on IP PID only • Compatible with RSVP, IGMP, PGM • IP Protocol ID is scarce • Use IP RAO 16-bit field as an IANA-registered selector • Fast switching looks only at the IP RAO option value to determine whether they want the packet • Legacy option values require additional IP PID lookup

9. Questions for the floor • Is there a real issue with IP Router-Alert as currently defined and implemented? • Applications: • Is there a safe alternative to banning IP RAO use by new applications? • Should we prevent any extensions to protocols that currently use IP RAO? • Should router protection implementation guidelines be BCP? • Is there value in standards extension/clarification of IP RAO procedures to determine packets of interest? • And finally, do these points apply to all IP Options?