Reshad Rahman, Editor

Adrian FarrelOldDog Consulting

Tony LiEricsson

David WardFrancois LeFaucheurAshok NarayananCisco

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 RPHigh cost to routers which don’t need to process the

packets received with IP RAOAttack 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 routers2. Encapsulate and transport IP RAO packets across network3. Remove IP RAO option and forward packet4. Drop packet

Don’t automatically punt all packets with IP RAO optionUnless protocol of interest is enabled, forward in fast

pathConfiguration should be per-interface and/or globalDon’t punt packets for unknown or unsupported protocols

Rate-limit all punted & locally addressed packetsDifferent queues for different IP-RAO protocolsAbility to control rate-limiting per interface and box-wide

For RAO option value 0, look at IP Protocol IDKeep table of matching IP PIDs of interestDon’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:◦ 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?