idnits 2.17.1 draft-rahman-rtg-router-alert-considerations-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 3, 2009) is 5403 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Le Faucheur, Ed. 3 Internet-Draft Cisco 4 Intended status: BCP July 3, 2009 5 Expires: January 4, 2010 7 IP Router Alert Considerations and Usage 8 draft-rahman-rtg-router-alert-considerations-02 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 4, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 The IP Router Alert Option is an IP option that alerts transit 57 routers to more closely examine the contents of an IP packet. RSVP, 58 PGM, IGMP/MLD and MRD are some of the protocols which make use of the 59 IP Router Alert option. This document discusses security aspects, 60 common practices and usage guidelines around the use of the current 61 IP Router Alert option. Specifically, it provides recommendations on 62 the use of Router Alert by new protocols, discusses controlled 63 environments where existing protocols depending on Router Alert can 64 be used effectively and discusses protection approaches for Service 65 Providers. Finally it provides brief guidelines for Router Alert 66 implementation on routers. 68 Table of Contents 70 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 72 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Guidelines for use of Router Alert . . . . . . . . . . . . . . 7 74 3.1. Use of Router Alert by New Protocols . . . . . . . . . . . 7 75 3.2. Use of Router Alert by Existing Protocols in 76 Controlled Environments . . . . . . . . . . . . . . . . . 8 77 3.3. Router Alert Protection Approaches for Service 78 Providers . . . . . . . . . . . . . . . . . . . . . . . . 8 79 4. Guidelines for Router Alert Implementation . . . . . . . . . . 11 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 86 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 1. Terminology 91 For readability, this document uses the following loosely defined 92 terms: 94 o Slow path : Software processing path for packets 96 o Fast path : ASIC/Hardware processing path for packets 98 1.1. Conventions Used in This Document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. Introduction 106 [RFC2113] and [RFC2711] respectively define the IPv4 and IPv6 Router 107 Alert Option. In this document, we collectively refer to those as 108 the IP Router Alert. RSVP ([RFC2205], [RFC3175], [RFC3209]), PGM 109 ([RFC3208]), IGMP ([RFC3376]), MLD ([RFC2710], [RFC3810]) and MRD 110 ([RFC4286]) are some of the protocols which make use of the IP Router 111 Alert. Those protocols are used in different ways, possibly even in 112 multiple ways simultaneously: For example, they are used to support 113 critical elements of the Internet infrastructure (e.g. RSVP-TE for 114 traffic engineering within a service provider network) and as such 115 they need to be protected; As another example, they are also used end 116 to end, say inside a company's private network, often transiting over 117 the Internet infrastructure. 119 IP datagrams carrying the IP Router Alert are usually examined in a 120 router's slow path and an excess of such datagrams can cause 121 performance degradation or packet drops in a router's slow path. 123 [RFC4081] and [RFC2711] mention the security risks associated with 124 the use of the IP Router Alert: flooding a router with bogus IP 125 datagrams which contain the IP Router Alert would cause a performance 126 degradation of the router's slow path and can also lead to packet 127 drops in the slow path. 129 [RFC2113] specifies no mechanism for identifying different users of 130 IP Router Alert. As a result, many fast switching implementations of 131 IP Router Alert punt most/all packets marked with IP Router Alert 132 into the slow path. Some IP Router Alert implementations may be able 133 to take into account the IP PID [RFC0791] as a discriminator for the 134 punting decision for different protocols using IP Router Alert. 135 However, this still only allows very coarse triage among various 136 protocols using IP Router Alert for two reasons. First, the IP PID 137 is the same when IP Router Alert is used for different applications 138 of the same protocol (e.g., RSVP vs. RSVP-TE), or when IP Router 139 Alert is used for different contexts of the same application (e.g., 140 different levels of RSVP aggregation [RFC3175]). Thus, it is not 141 possible to achieve the necessary triage in the fast path across IP 142 Router Alert packets from different applications or from different 143 contexts of an application. Secondly, some protocols requiring 144 punting may be carried over a transport protocol (e.g., TCP or UDP) 145 possibly because they require the services of that transport protocol 146 or perhaps because the protocol does not justify allocation of a 147 scarce IP PID value. Thus, considering the PID does not allow triage 148 in the fast path of IP Router Alert packets from different protocols 149 sharing the same transport protocol. Therefore, It is generally not 150 possible to ensure that only the IP Router Alert packets of interest 151 are punted to the slow path while other IP Router Alert packets are 152 efficiently forwarded (i.e., in fast path). 154 [RFC2711] mentions that limiting, by rate or some other means, the 155 use of IP Router Alert option is a way of protecting against a 156 potential attack. However, if rate limiting is used as a protection 157 mechanism but if the granularity of the rate limiting is not fine 158 enough to distinguish among IP Router Alert packet of interest from 159 unwanted IP Router Alert packet, a IP Router Alert attack could still 160 severely degrade operation of protocols of interest that depend on 161 the use of IP Router Alert. 163 In some environments where it is not possible to accurately and 164 reliably distinguish between IP Router Alert packets of interest and 165 unwanted IP Router Alert packets, operators have resorted to actively 166 protecting themselves against externally generated IP Router Alert 167 packets in ways that result in end to end IP Router Alert packets 168 being (occasionally or systematically) dropped and/or ignored on a 169 segment. The consequences of such practises on the use of IP Router 170 Alert by new applications and protocols are discussed in Section 3.1 171 of the present document. 173 Section 3.2 discusses environments where existing applications/ 174 protocols relying on IP Router Alert can be deployed effectively and 175 safely. 177 Section 3.3 provides recommendations on protection approaches to be 178 used by Service Providers in order to protect their network from 179 Router Alert based attacks. 181 Finally, Section 4 provides generic recommendations for router 182 implementation of Router Alert aiming at increasing protection 183 against attacks. 185 The present document discusses considerations and practises based on 186 the current specification of IP Router Alert ([RFC2113], [RFC2711]). 187 Possible future enhancements to the specification of IP Router Alert 188 (in view of reducing the security risks associated with the use of IP 189 Router Alert) are outside the scope of this document. A proposal for 190 such enhancements can be found in 191 [I-D.narayanan-rtg-router-alert-extension]. 193 3. Guidelines for use of Router Alert 195 3.1. Use of Router Alert by New Protocols 197 First, as mentioned earlier, some networks actively protect 198 themselves against externally generated IP Router Alert packets. 199 This may be by tunneling IP Router Alert packets 200 [I-D.dasmith-mpls-ip-options] so that the IP Router Alert option is 201 hidden through that network or it may be via mechanisms resulting in 202 occasional (e.g., rate limiting) or systematic drop of IP Router 203 Alert packets. 205 Secondly, application protocols are often not carried directly on top 206 of IP but rather are carried by a transport protocol such as UDP, 207 TCP, or SCTP that in turns runs over IP. In these cases, the 208 application protocol is not visible in the IP header (that only 209 contains information about the transport protocol) and could not be 210 determined without further "deep packet" inspection. In the event of 211 the IP Router Alert option being used for an application protocol 212 carried in a transport protocol, the intercepted IP packet would be 213 delivered to the transport protocol for processing in accordance with 214 [RFC2113] (as opposed to being delivered directly to the application 215 protocol). However, the behavior of the transport protocol in these 216 circumstances is not defined, and may cause rejection of the packet 217 for various reasons. 219 As a consequence, in the general case of open networks, applications 220 can not safely rely on IP Router Alert packets being visible to all 221 nodes on the path today, and more importantly can not even rely on IP 222 Router Alert packets being transported end to end. 224 [RFC2113] implies that the router may examine other fields of a 225 received packet that contains the IP Router Alert option to decide 226 whether that packet needs further processing, but no further advice 227 is given. Examination of other fields of the received IP packet that 228 carries the IP Router Alert to help determine what to do with the 229 packet would result in implementation-specific behavior that is 230 unpredictable to the sender of the packet. Therefore applications 231 cannot depend on IP Router Alert interception involving inspection of 232 fields in the packet outside the IP header. 234 Thus, creating a new application or end-to-end protocol that depends 235 on use of the current IP Router Alert ([RFC2113], [RFC2711]) is 236 considered harmful and it is RECOMMENDED that new application or 237 protocol be developed without using IP Router Alert. A different 238 mechanism SHOULD be used in order to increase likelihood of operation 239 of that application/protocol end-to-end and to decrease the risk of 240 impacting existing protocols that use the IP Router Alert option. 242 3.2. Use of Router Alert by Existing Protocols in Controlled 243 Environments 245 In some controlled environments, the network administrator can 246 determine that IP Router Alert packets will only be received from 247 trusted well-behaved devices or can establish that the protection 248 mechanisms discussed in the present document against the plausible 249 RAO-based DoS attacks (e.g., RAO filtering and rate-limiting) are 250 sufficient. In that case, an application relying on exchange and 251 handling of RAO packets (e.g., RSVP) may be safely deployed within 252 the controlled network. A private enterprise network firewalled from 253 the Internet and using RSVP for voice and video reservation and 254 admission control may be an example of such controlled environment. 256 In some environments, the network administrator can reliably ensure 257 that router alert packets from any untrusted device (e.g., from 258 external routers) are prevented from entering a trusted area (e.g., 259 the internal routers). For example, this may be achieved by ensuring 260 that routers straddling the trust boundary (e.g., edge routers) 261 always encapsulate those packets (without setting IP Router Alert -or 262 equivalent- in the encapsulating header) through the trusted area (as 263 discussed in [I-D.dasmith-mpls-ip-options]). In such environments, 264 the risks of DOS attacks through the IP Router Alert vector is 265 removed in the trusted area (or greatly reduced) even if IP Router 266 Alert is used inside the trusted area (say for RSVP-TE). Thus an 267 application relying on IP Router Alert may be safely deployed within 268 the trusted area. A Service Provider running RSVP-TE within his 269 network may be an example of such protected environment. 271 When a controlled environment requires RAO packet exchange across his 272 routers for some application (e.g., RSVP) and transits via a Service 273 Provider network (that is not part of the controlled environment), 274 the administrator of the controlled environment needs to ensure with 275 the Service Provider that the Service Provider network protects 276 itself from IP Router Alert messages without dropping those when they 277 transit over the Service Provider network (for example using 278 mechanisms discussed in [I-D.dasmith-mpls-ip-options]). In this 279 case, an application relying on IP Router Alert (e.g. RSVP) may be 280 deployed within the controlled environment and effectively 281 transparently over the Service Provider network without affecting the 282 security of the Service Provider network. 284 3.3. Router Alert Protection Approaches for Service Providers 286 Section 2 discusses the security risks associated with the use of the 287 IP Router Alert and how it opens up a DOS vector in the router 288 control plane. Opening up a hole in the control plane of Service 289 Provider edge routers is commonly done for other applications such as 290 BGP peering. However, the resulting DOS attack vector is arguably 291 more serious with Router Alert option than with BGP peering for a 292 number of reasons including: 294 o with BGP, a DOS attack would only affect the edge router(s), while 295 with Router Alert option, the attack could propagate to core 296 routers 298 o with BGP, the BGP policy control would typically prevent re- 299 injection of undesirable information out of the attacked device, 300 while with Router-Alert option, the non-filtered attacking 301 messages would typically be forwarded downstream. 303 Thus, it is RECOMMENDED that a Service Provider implements strong 304 protection of his network against attacks based on IP Router Alert. 306 Since some existing applications would benefit from end-to-end 307 transport of IP Router Alert packets (e.g. RSVP in a controlled 308 environment), it is RECOMMENDED that a Service Provider protects his 309 network from attacks based on IP Router Alert using mechanisms that 310 avoid (or at least minimize) dropping of end to end IP Router Alert 311 packets (other than those involved in the attack). 313 For example, if the Service Provider does not run any protocol 314 depending on IP Router Alert within his network, he may elect to 315 simply turn-off punting of IP Router Alert packet on his routers; 316 this will ensure that end-to-end IP Router Alert packet transit 317 transparently and safely through his network. 319 As another example, using protection mechanisms such selective 320 filtering and rate-limiting (that Section 4 suggests be supported by 321 IP Router Alert implementations) a Service Provider can protect the 322 operation of a protocol depending on IP Router Alert within his 323 network (e.g., RSVP-TE) while at the same time transporting IP Router 324 Alert packets carrying another protocol that may be used end to end. 325 Note that the Service Provider might additionally use protocol 326 specific mechanisms that reduce the dependency on Router Alert for 327 operation of this protocol inside the Service Provider environment; 328 use of RSVP refresh reduction mechanisms ([RFC2961]) would be an 329 example of such mechanisms in the case where the Service Provider is 330 running RSVP-TE within his network since this allows refresh of 331 existing Path and Resv states without use of the IP Router Alert 332 option. 334 As yet another example, using mechanisms such as those discussed in 335 [I-D.dasmith-mpls-ip-options] a Service Provider can safely protect 336 the operation of a protocol depending on IP Router Alert within his 337 network (e.g., RSVP-TE) while at the same time safely transporting IP 338 Router Alert packets carrying another protocol that may be used end 339 to end (e.g., IPv4/IPv6 RSVP). 341 As a last resort, if the SP does not have any means to safely 342 transport end to end IP Router Alert option packets over his network, 343 the SP MAY drop those packets. 345 4. Guidelines for Router Alert Implementation 347 It is RECOMMENDED that router implementations of IP Router Alert 348 option include protection mechanisms against Router Alert based DOS 349 attacks appropriate for their targeted deployment environments. For 350 example, this can include ability on an edge router to "tunnel" IP 351 Router Alert option of received packets when forwarding those over 352 the core as discussed in [I-D.dasmith-mpls-ip-options]. As another 353 example, altough not always available from current implementations, 354 new implementations may include protection mechanisms such as 355 selective (possibly dynamic) filtering and rate-limiting of IP Router 356 Alert option packets. 358 If an IP packet contains the IP Router Alert option, but the payload 359 protocol is not explicitly identified as a Payload of interest by the 360 router examining the packet, the behavior is not explicitely defined 361 by [RFC2113]. However, the behavior is implied and, for example, the 362 definition of RSVP in [RFC2205] assumes that the packet will be 363 forwarded using normal forwarding based on the destination IP 364 address. Thus, a router implementation SHOULD forward within the 365 "fast path" (subject to all normal policies and forwarding rules) a 366 packet carrying the IP Router Alert option containing a payload that 367 is not a payload of interest to that router. The "not passing" 368 behavior protects the router from DOS attacks using IP Router Alert 369 packets of a protocol unknown to the router. The "forwarding" 370 behavior contributes to transparent end to end transport of IP Router 371 Alert packets (e.g., to facilitate their use by end to end 372 application). 374 5. Security Considerations 376 This document discusses security risks associated with current usage 377 of the IP Router Alert Option and associated practices. 379 6. IANA Considerations 381 None. 383 7. Contributors 385 The contributors to this document (in addition to the editors) are: 387 o Reshad Rahman: 389 * Cisco Systems 391 * rrahman@cisco.com 393 o David Ward: 395 * Cisco Systems 397 * wardd@cisco.com 399 o Ashok Narayanan: 401 * Cisco Systems 403 * ashokn@cisco.com 405 o Adrian Farrell: 407 * OldDog Consulting 409 * adrian@olddog.co.uk 411 o Tony Li: 413 * tony.li@tony.li 415 8. Acknowledgments 417 We would like to thank Dave Oran, Magnus Westerlund, John Scudder, 418 Ron Bonica, Ross Callon and Alfred Hines for their comments. 420 9. References 422 9.1. Normative References 424 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 425 September 1981. 427 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 428 February 1997. 430 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 431 RFC 2711, October 1999. 433 9.2. Informative References 435 [I-D.dasmith-mpls-ip-options] 436 Jaeger, W., Mullooly, J., Scholl, T., and D. Smith, 437 "Requirements for Label Edge Router Forwarding of IPv4 438 Option Packets", draft-dasmith-mpls-ip-options-01 (work in 439 progress), October 2008. 441 [I-D.narayanan-rtg-router-alert-extension] 442 Narayanan, A., Faucheur, F., Ward, D., and R. Rahman, "IP 443 Router Alert Option Extension", 444 draft-narayanan-rtg-router-alert-extension-00 (work in 445 progress), March 2009. 447 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 448 Requirement Levels", BCP 14, RFC 2119, March 1997. 450 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 451 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 452 Functional Specification", RFC 2205, September 1997. 454 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 455 Listener Discovery (MLD) for IPv6", RFC 2710, 456 October 1999. 458 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 459 and S. Molendini, "RSVP Refresh Overhead Reduction 460 Extensions", RFC 2961, April 2001. 462 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 463 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 464 RFC 3175, September 2001. 466 [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., 467 Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, 468 L., Tweedly, A., Bhaskar, N., Edmonstone, R., 469 Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport 470 Protocol Specification", RFC 3208, December 2001. 472 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 473 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 474 Tunnels", RFC 3209, December 2001. 476 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 477 Thyagarajan, "Internet Group Management Protocol, Version 478 3", RFC 3376, October 2002. 480 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 481 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 483 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 484 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 486 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 487 RFC 4286, December 2005. 489 Author's Address 491 Francois Le Faucheur (editor) 492 Cisco Systems 493 Greenside, 400 Avenue de Roumanille 494 Sophia Antipolis 06410 495 France 497 Phone: +33 4 97 23 26 19 498 Email: flefauch@cisco.com