1. 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

2. 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

3. 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

4. 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

5. 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”

6. 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

7. 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)”.

8. 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

9. 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

10. 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

11. Q & A