IP Router-Alert Considerations and usage draft-rahman-rtg-router-alert-considerations-01 Reshad Rahman David Ward Francois Le Faucheur Ashok Narayanan Cisco Adrian Farrel OldDog Consulting Tony Li Ericsson

What is this all about? RAO security concerns & solutions not documented well Some feel careful implementation & careful deployment address the RAO security concerns Some feel concerns are far from addressed Practical questions remain unanswered: Should an operator block e2e RAO packets to protect itself? Should IETF stop (some) extensions to existing protocols using RAO? Should IETF discourage definition of new protocols using RAO? Should RAO definition be enhanced? Objective: documents concerns/solutions and answer above questions

Structure Change from Previous Version (as per feedback/guidance) draft-rahman-rtg- router-alert-considerations-00 draft-rahman-rtg- router-alert-considerations-01 Based on current RAO definition BCP Track Concerns & Recommendations draft-narayanan-rtg- router-alert-extensions-00 Explores enhanced RAO definition

RAO Concern & Protection Approaches No mechanism specified to facilitate triage between desired & undesired RAO packets PID may be used, but not granular enough e.g. “my RSVP-TE packets” vs “e2e RSVP packets”? e.g. “Protocol-1 over TCP” vs “Protocol-2 over TCP” RAO Protection can be achieved by: Assume only “desired RAO” (controlled-environment) Rely on RAO implementation to perform triage and rate- limiting of “undesired RAO” Tunnel “undesired RAO” (draft-dasmith-mpls-ip-options) Block “undesired RAO” at the edge

Guidelines for new e2e Applications e2e delivery of RAO packets cannot be relied on today new Apps are likely to be muxed over shared transport protocol (which makes triage difficult)  “it is RECOMMENDED that new end to end applications or protocols be developed without using IP Router Alert”

Use of RAO (by existing protocols) RAO can be used safely in Controlled-environments RAO can be used safely in some open environments provided the operator can protect itself efficiently by: Implementing efficient triage & rate-limiting of “undesired RAO” at every hop (possibly combined with some protocol specific mechanism to reduce RAO dependency e.g. RSVP-TE Refresh Reduction) Tunneling “undesired RAO” (draft-dasmith-mpls-ip-options) extensions to existing protocols that use RAO are OK provided extension is applicable to the above environments

Use of RAO (by existing protocols) “it is RECOMMENDED that a Service Provider protects his network from attacks based on IP Router Alert using mechanisms that avoid (or at least minimize) dropping of end to end IP Router Alert packets (other than those involved in the attack)”.

RAO Router Implementation Section 4 currently provides examples of protection mechanisms that may be supported by an RAO implementation Received Feedback: “too implementation-specific to become recommendations” “Not IETF job to specify how to implement” Proposal: Include a generic recommendation to implement RAO protection (possibly suggesting selective rate-limiting of undesirable RAO) but without actual details on how to implement it

Next Steps (1/2) Add text for a generic recommendation to implement RAO protection but without actual details Turn section 4.4 into a clarification to make explicit what is implicit in current RAO definition i.e. Router ought to forward RAO packet for protocols that are not of interest to the router

Next Steps (2/2) Remove fall-back SP recommendations: “As a last resort, if the SP does not have any means to safely transport e2e RAO packets over his network, it is RECOMMENDED that, rather than dropping those packets, the SP forwards these packets through his network after removing the RAO from the IP header on ingress/receipt of the packet.” “Where the SP does not ensure reliable transport of RAO packets (i.e., those get dropped) for an e2e protocol of interest to a user, the user can consider removing the RAO from the IP header before sending the packet to the SP and may then intercept the packet on the other ...” Because if we were to specify RAO manipulation behavior we may as well specify more effective ones as discussed in draft-narayanan-rtg-router-alert- extension

Q & A