Download rtgarea

Reshad Rahman, Editor

Adrian Farrel

Tony Li

OldDog Consulting
Ericsson
David Ward
Francois LeFaucheur
Ashok Narayanan
Cisco

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”

IP Router-Alert in E2E Applications

IP Router-Alert in Networks

Example router protection mechanisms

Possible standards work to improve IP RAO

Questions


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
“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:
1. Implement IP RAO protection mechanisms on routers
2. Encapsulate and transport IP RAO packets across network
3. Remove IP RAO option and forward packet
4. Drop packet

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

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

Is there a real issue with IP Router-Alert as currently
defined and implemented?

Applications:

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?
◦ 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?