Transcript The future of IP Router-Alert

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
Old Dog Consulting
Tony Li
Redback
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 so
above questions can be answered
Structure Change from Previous
Version (as per feedback/guidance)
draft-rahman-rtgrouter-alert-considerations-00
draft-rahman-rtgrouter-alert-considerations-01
• Based on current RAO definition
• BCP Track
• Concerns & Recommendations
draft-narayanan-rtgrouter-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 ratelimiting 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” (as currently
specified)
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 specifics on how to
implement it
Next Steps (1/2)
 Add text for a generic recommendation to implement
RAO protection but without actual specifics
 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)
 Replace 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 ...”
by :

“As a last resort, if the SP does not have any means to safely
transport e2e RAO packets over his network, the SP MAY drop those
packets.
 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