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

1
IP Router-AlertConsiderations and usage
draft-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 dont 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

• Dont 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
• Dont 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
• Dont 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/clarificatio
  n of IP RAO procedures to determine packets of
  interest?
• And finally, do these points apply to all IP
  Options?