idnits 2.17.1 draft-rahman-rtg-router-alert-considerations-03.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 (October 26, 2009) is 5290 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-07) exists of draft-ietf-tsvwg-rsvp-l3vpn-02 == Outdated reference: A later version (-05) exists of draft-krishnan-ipv6-hopbyhop-03 Summary: 2 errors (**), 0 flaws (~~), 4 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 October 26, 2009 5 Expires: April 29, 2010 7 IP Router Alert Considerations and Usage 8 draft-rahman-rtg-router-alert-considerations-03 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 April 29, 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, MRD and GIST are some of the protocols that make use 59 of the IP Router Alert option. This document discusses security 60 aspects and usage guidelines around the use of the current IP Router 61 Alert option. Specifically, it provides recommendation against using 62 the Router Alert in the end-to-end open Internet as well as identify 63 controlled environments where protocols depending on Router Alert can 64 be used safely. It also provides recommendation about protection 65 approaches for Service Providers. Finally it provides brief 66 guidelines for Router Alert 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. Security Concerns of Router Alert . . . . . . . . . . . . . . 7 74 4. Guidelines for use of Router Alert . . . . . . . . . . . . . . 10 75 4.1. Use of Router Alert End-to-End In the Internet (Router 76 Alert in Peer Model) . . . . . . . . . . . . . . . . . . . 10 77 4.2. Use of Router Alert In Controlled Environments . . . . . . 11 78 4.2.1. Use of Router Alert Within an Administrative Domain . 11 79 4.2.2. Use of Router Alert In Overlay Model . . . . . . . . . 13 80 4.3. Router Alert Protection Approaches for Service 81 Providers . . . . . . . . . . . . . . . . . . . . . . . . 16 82 5. Guidelines for Router Alert Implementation . . . . . . . . . . 18 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 85 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 86 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 88 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 89 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 92 1. Terminology 94 For readability, this document uses the following loosely defined 95 terms: 97 o Slow path : Software processing path for packets 99 o Fast path : ASIC/Hardware processing path for packets 101 1.1. Conventions Used in This Document 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 2. Introduction 109 [RFC2113] and [RFC2711] respectively define the IPv4 and IPv6 Router 110 Alert Option (RAO). In this document, we collectively refer to those 111 as the IP Router Alert. The IP Router Alert Option is an IP option 112 that alerts transit routers to more closely examine the contents of 113 an IP packet. 115 RSVP ([RFC2205], [RFC3175], [RFC3209]), PGM ([RFC3208]), IGMP 116 ([RFC3376]), MLD ([RFC2710], [RFC3810]), MRD ([RFC4286]) and NSIS 117 General Internet Signalling Transport (GIST) ([I-D.ietf-nsis-ntlp]) 118 are some of the protocols that make use of the IP Router Alert. 120 Section 3 describes the security concerns associated with the use of 121 the Router Alert option. 123 Section 4 provides guidelines for the use of Router Alert. More 124 specifically, Section 4.1 recommends that Router Alert not be used 125 for end to end applications over the Internet, while Section 4.2 126 presents controlled environments where applications/protocols relying 127 on IP Router Alert can be deployed effectively and safely. 128 Section 4.3 provides recommendations on protection approaches to be 129 used by Service Providers in order to protect their network from 130 Router Alert based attacks. 132 Finally, Section 5 provides generic recommendations for router 133 implementation of Router Alert aiming at increasing protection 134 against attacks. 136 The present document discusses considerations and practises based on 137 the current specification of IP Router Alert ([RFC2113], [RFC2711]). 138 Possible future enhancements to the specification of IP Router Alert 139 (in view of reducing the security risks associated with the use of IP 140 Router Alert) are outside the scope of this document. A proposal for 141 such enhancements can be found in 142 [I-D.narayanan-rtg-router-alert-extension]. 144 The IPv6 base specification [RFC2460] defines the hop-by-hop option 145 extension header. The hop-by-hop option header is used to carry 146 optional information that must be examined by every node along a 147 packet's delivery path. The IPv6 Router Alert Option is one 148 particular hop by hop option. Similar security concerns to those 149 discussed in the present document for the IPv6 Router Alert apply 150 more generically to the concept of IPv6 hop-by-hop option extension 151 header. However, addressing the broader concept of IPv6 hop-by-hop 152 option thoroughly would require additional material so as to cover 153 additional considerations associated with it (such as the attacks 154 effectiveness depending on how many options are included and on the 155 range from to which the option-type value belongs, etc.), so this is 156 kept outside the scope of the present document. A detailed 157 discussion about security risks and proposed remedies associated with 158 IPv6 hop-by-hop option can be found in [I-D.krishnan-ipv6-hopbyhop]. 160 The IPv4 base specification [RFC0791] defines a general notion of 161 IPv4 options that can be included in the IPv4 header (without 162 distinguishing between hop-by-hop versus end-to-end option). The 163 IPv4 Router Alert Option is one particular IPv4 option. Similar 164 security concerns to those discussed in the present document for the 165 IPv4 Router Alert apply more generically to the concept of IPv4 166 option. However, addressing the broader concept of IPv4 option 167 thoroughly would require additional material so as to cover 168 additional considerations associated with it (such as lack of option 169 ordering, etc.), so this is kept outside the scope of the present 170 document. 172 3. Security Concerns of Router Alert 174 The IP Router Alert option is defined ([RFC2113], [RFC2711]) as a 175 mechanism that alerts transit routers to more closely examine the 176 contents of an IP packet. [RFC4081] and [RFC2711] mention the 177 security risks associated with the use of the IP Router Alert: 178 flooding a router with bogus (or simply undesired) IP datagrams which 179 contain the IP Router Alert could impact operation of the router in 180 undesirable ways. For example, assuming the router punts the 181 datagrams containing the IP Router Alert option to the slow path, 182 such an attack could consume a significant share of the router's slow 183 path and could also lead to packet drops in the slow path (thus, 184 affecting operation of all other applications and protocols operating 185 in the slow path). 187 Furthermore, [RFC2113] specifies no (and [RFC2711] specifies very 188 limited) mechanism for identifying different users of IP Router 189 Alert. As a result, many fast switching implementations of IP Router 190 Alert punt most/all packets marked with IP Router Alert into the slow 191 path (unless configured to systematically ignore or drop all Router 192 Alert packets). 194 Some IP Router Alert implementations may be able to take into account 195 the IP PID [RFC0791] as a discriminator for the punting decision for 196 different protocols using IP Router Alert. However, this still only 197 allows very coarse triage among various protocols using IP Router 198 Alert for two reasons. First, the IP PID is the same when IP Router 199 Alert is used for different applications of the same protocol (e.g., 200 RSVP vs. RSVP-TE), or when IP Router Alert is used for different 201 contexts of the same application (e.g., different levels of RSVP 202 aggregation [RFC3175]). Thus, it is not possible to achieve the 203 necessary triage in the fast path across IP Router Alert packets from 204 different applications or from different contexts of an application. 205 Secondly, some protocols requiring punting may be carried over a 206 transport protocol (e.g., TCP or UDP) possibly because they require 207 the services of that transport protocol or perhaps because the 208 protocol does not justify allocation of a scarce IP PID value. Thus, 209 considering the PID does not allow triage in the fast path of IP 210 Router Alert packets from different protocols sharing the same 211 transport protocol. Therefore, It is generally not possible to 212 ensure that only the IP Router Alert packets of interest are punted 213 to the slow path while other IP Router Alert packets are efficiently 214 forwarded (i.e., in fast path). 216 Some IP Router Alert implementations may be able to take into account 217 the value field inside the router alert option. However, only one 218 value (zero) was defined in [RFC2113] and no IANA registry for IPv4 219 Router Alert values was available until recently. So this did not 220 allow most IPv4 Router Alert implementation to support useful 221 classification based on the value field in the fast path. Also, 222 while [RFC2113] states that unknown values should be ignored (i.e. 223 The packets should be forwarded as normal IP traffic), it has been 224 reported that some existing implementations simply ignore the value 225 field completely (i.e. Process any packet with an IPv4 Router Alert 226 regardless of its option value). An IANA registry for further 227 allocation of IPv4 Router Alert values has been introduced recently 228 ([RFC5350]) but this would only allow coarse-grain classification, 229 when, and if, supported by implementations. For IPv6, [RFC2711] 230 states that "the value field can be used by an implementation to 231 speed processing of the datagram within the transit router" and 232 defines an IANA registry for these values. But again, this only 233 allows coarse-grain classification. Besides, some existing IPv6 234 Router Alert implementations are reported to depart from that 235 behavior. 237 [RFC2711] mentions that limiting, by rate or some other means, the 238 use of IP Router Alert option is a way of protecting against a 239 potential attack. However, if rate limiting is used as a protection 240 mechanism but if the granularity of the rate limiting is not fine 241 enough to distinguish among IP Router Alert packet of interest from 242 unwanted IP Router Alert packet, a IP Router Alert attack could still 243 severely degrade operation of protocols of interest that depend on 244 the use of IP Router Alert. 246 In a nutshell, the IP router alert option does not provide a 247 convenient universal mechanism to accurately and reliably distinguish 248 between IP Router Alert packets of interest and unwanted IP Router 249 Alert packets. This, in turn, creates a security concern when IP 250 Router Alert option is used, because, short of appropriate router 251 implementation specific mechanisms, the router slow path is at risk 252 of being flooded by unwanted traffic. 254 It can be observed that opening up a hole in the control plane of 255 Service Provider routers is commonly done for other applications such 256 as BGP peering. However, the resulting DOS attack vector is arguably 257 more serious with Router Alert option than with BGP peering for a 258 number of reasons including: 260 o with BGP Peering, the control plane hole is only open on the edge 261 routers and core routers are completely isolated from any direct 262 control plane exchange with entities outside the administrative 263 domain; with BGP, a DOS attack would only affect the edge 264 router(s), while with Router Alert option, the attack could 265 propagate to core routers; 267 o with BGP, the BGP policy control would typically prevent re- 268 injection of undesirable information out of the attacked device, 269 while with Router-Alert option, the non-filtered attacking 270 messages would typically be forwarded downstream. 272 o With BGP, edge routers only exchange control plane information 273 with pre-identified peers and can easily filter out any control 274 plane traffic coming from other peers, while the Router-Alert 275 option can be received in a datagram with any destination address 276 and any destination source. 278 4. Guidelines for use of Router Alert 280 4.1. Use of Router Alert End-to-End In the Internet (Router Alert in 281 Peer Model) 283 Because of the security concerns associated with Router Alert 284 discussed in Section 3, network operators need to actively protect 285 themselves against externally generated IP Router Alert packets. 286 Because there is no convenient universal mechanisms to triage between 287 desired and undesired router alert packets, network operators 288 currently often protect themselves in ways that isolate them from 289 externally generated IP Router Alert packets. This may (ideally) be 290 achieved by tunneling IP Router Alert packets 291 [I-D.dasmith-mpls-ip-options] so that the IP Router Alert option is 292 hidden through that network, or it may be achieved via mechanisms 293 resulting in occasional (e.g., rate limiting) or systematic drop of 294 IP Router Alert packets. 296 Thus, it is RECOMMENDED that applications and protocols not be 297 deployed with a dependency on processing of the Router Alert option 298 (as currently specified) across independent administrative domains in 299 the Internet. Figure 1 illustrates such a hypothetical use of Router 300 Alert end-to-end in the Internet. We refer to such a model of Router 301 Alert option use as a "Peer Model" Router Alert option use, since 302 core routers in different administrative domains would partake in 303 processing of Router Alert option datagrams associated with the same 304 signalling flow. 306 -------- -------- -------- -------- 307 / A \ / B \ / C \ / D \ 308 | (*) | | (*) | | (*) | | (*) | 309 | | |<============>| |<=============>| |<=============>| | | 310 | - | | - | | - | | - | 311 \ / \ / \ / \ / 312 -------- -------- -------- -------- 314 (*) closer examination of Router Alert option datagrams 316 <==> flow of Router Alert option datagrams 318 Figure 1: Use of Router Alert End-to-End in the Open Internet (Router 319 Alert in Peer Model) 321 While this recommendation is framed here specifically in the context 322 of router alert, the fundamental security risk that network operators 323 want to preclude is to allow devices/protocols that are outside of 324 their administrative domain (and therefore not controlled) to tap 325 into the control plane of their core routers. Whether this control 326 plane access is provided through router alert option or would be 327 provided by any other mechanism (e.g. Deep packet inspection) 328 probably results in similar security concerns. In other words, the 329 fundamental security concern is associated with the notion of end to 330 end signaling in a Peer Model across domains in the Internet. As a 331 result, it is expected that network operators would typically not 332 want to have their core routers partake in end-to-end signalling with 333 external uncontrolled devices through the open Internet, and 334 therefore prevent deployment of end to end signalling in a Peer model 335 through their network (regardless of whether that signalling uses 336 Router Alert or not). 338 4.2. Use of Router Alert In Controlled Environments 340 4.2.1. Use of Router Alert Within an Administrative Domain 342 In some controlled environments such as within a given Administrative 343 Domain, the network administrator can determine that IP Router Alert 344 packets will only be received from trusted well-behaved devices or 345 can establish that specific protection mechanisms (e.g., RAO 346 filtering and rate-limiting) against the plausible RAO-based DoS 347 attacks are sufficient. In that case, an application relying on 348 exchange and handling of RAO packets (e.g., RSVP) MAY be safely 349 deployed within the controlled network. A private enterprise network 350 firewalled from the Internet and using RSVP reservations for voice 351 and video flows may be an example of such controlled environment. 352 Such an environment is illustrated in Figure 2. 354 ------------------------- -------- -------- 355 / A \ / B \ / C \ 356 | (*) (*) | -- | | | | 357 | | |<============>| | |--|FW|--| |--------| | 358 | - - | -- | | | | 359 \ / \ / \ / 360 ------------------------- -------- -------- 362 (*) closer examination of Router Alert option datagrams 364 <==> flow of Router Alert option datagrams 366 FW Firewall 368 Figure 2: Use of Router Alert Within an Administrative Domain 370 In some controlled environments, several Administrative Domains have 371 a special relationship whereby they cooperate very tightly and 372 effectively operate as a single trust domain. In that case, one 373 domain is willing to trust another with respect to the traffic 374 injected across the boundary. In other words, a downstream domain is 375 willing to trust that the traffic injected at the boundary has been 376 properly validated/filtered by the upstream domain. Where it has 377 been established that such trust can be applied to router alert 378 option packets, an application relying on exchange and handling of 379 RAO packets (e.g., RSVP) MAY be safely deployed within such a 380 controlled environment. The entity within a company responsible for 381 operating multimedia endpoints and the entity within the same company 382 responsible for operating the network may be an example of such 383 controlled environment. For example, they may collaborate so that 384 RSVP reservations can be used for video flows from endpoints to 385 endpoints through the network. 387 In some environments, the network administrator can reliably ensure 388 that router alert packets from any untrusted device (e.g., from 389 external routers) are prevented from entering a trusted area (e.g., 390 the internal routers). For example, this may be achieved by ensuring 391 that routers straddling the trust boundary (e.g., edge routers) 392 always encapsulate those packets (without setting IP Router Alert -or 393 equivalent- in the encapsulating header) through the trusted area (as 394 discussed in [I-D.dasmith-mpls-ip-options]). In such environments, 395 the risks of DOS attacks through the IP Router Alert vector is 396 removed in the trusted area (or greatly reduced) even if IP Router 397 Alert is used inside the trusted area (say for RSVP-TE). Thus an 398 application relying on IP Router Alert MAY be safely deployed within 399 the trusted area. A Service Provider running RSVP-TE within his 400 network may be an example of such protected environment. Such an 401 environment is illustrated in Figure 3. 403 -------- -------------------------- -------- 404 / A \ / B \ / C \ 405 | | | (*) (*) | | | 406 | |-------TT | |<=============>| | TT------- | | 407 | | | - - | | | 408 \ / \ / \ / 409 -------- -------------------------- -------- 411 (*) closer examination of Router Alert option datagrams 413 <==> flow of Router Alert option datagrams 415 TT Tunneling of Router Alert option datagrams 417 Figure 3: Use of Router Alert Within an Administrative Domain 419 4.2.2. Use of Router Alert In Overlay Model 421 In some controlled environment: 423 o the sites of a network A are interconnected through a service 424 provider network B 426 o the service provider network B protects itself from IP Router 427 Alert messages without dropping those when they transit over the 428 transit network (for example using mechanisms discussed in 429 [I-D.dasmith-mpls-ip-options]) 431 In such controlled environment, an application relying on exchange 432 and handling of RAO packets (e.g., RSVP) in the network A sites (but 433 not inside network B) MAY be safely deployed. We refer to such a 434 deployment as a use of Router Alert in a Water-Tight Overlay. 435 "Overlay" because Router Alert option datagrams are used in network A 436 on top of, and completely transparently to, network B. "Water-Tight" 437 because router alert option datagrams from A cannot leak inside 438 network B. A private enterprise intranet, whose sites are 439 interconnected through a Service Prover network, and using RSVP to 440 perform reservations within the enterprise sites for voice and video 441 flows may be an example of such controlled environment. Such an 442 environment is illustrated in Figure 4. 444 -------- -------- 445 / A \ / A \ 446 | (*) | | (*) | 447 | | |<=================================>| | | | 448 | - | | - | 449 \ / \ / 450 -------- -------- 451 \ / 452 \ ------------------------- / 453 \ / B \ / 454 \| |/ 455 TT TT 456 | | 457 \ / 458 ------------------------- 460 (*) closer examination of Router Alert option datagrams 462 <==> flow of Router Alert option datagrams 464 TT Tunneling of Router Alert option datagrams 466 Figure 4: Use of Router Alert In Water-tight Overlay 468 In the controlled environment described above, an application relying 469 on exchange and handling of RAO packets (e.g. RSVP-TE) in the 470 service provider network B (but not in network A) MAY also be safely 471 deployed simultaneously. Such an environment with independent, 472 isolated, deployment of router alert in overlay at two levels is 473 illustrated in Figure 5. 475 -------- -------- 476 / A \ / A \ 477 | (*) | | (*) | 478 | | |<=================================>| | | | 479 | - | | - | 480 \ / \ / 481 -------- -------- 482 \ / 483 \ ------------------------- / 484 \ / B \ / 485 \| (*) (*) |/ 486 TT | |<============>| | TT 487 | - - | 488 \ / 489 ------------------------- 491 (*) closer examination of Router Alert option datagrams 493 <==> flow of Router Alert option datagrams 495 TT Tunneling of Router Alert option datagrams 497 Figure 5: Use of Router Alert In Water-tight Overlay at Two Levels 499 In some controlled environment: 501 o the sites of a network A are interconnected through a service 502 provider network B 504 o the service provider B processes router alert packets on the edge 505 routers and protect these edge routers against RAO based attacks 506 using mechanisms such as (possibly per port) RAO rate limiting and 507 filtering 509 o the service provider network B protects its core routers from 510 Router Alert messages without dropping those when they transit 511 over the transit network (for example using mechanisms discussed 512 in [I-D.dasmith-mpls-ip-options]) 514 In such controlled environment, an application relying on exchange 515 and handling of RAO packets (e.g., RSVP) in the network A sites and 516 in network B Edges (but not in the core of network B) MAY be safely 517 deployed. We refer to such a deployment as a use of Router Alert in 518 a Leak-Controlled Overlay. "Overlay" because Router Alert option 519 datagrams are used in network A on top of, and completely 520 transparently to, network B core. "Leak-Controlled" because router 521 alert option datagrams from A leak inside network B's B edges but not 522 inside network B's core. A private enterprise intranet, whose sites 523 are interconnected through a Service Prover network, using RSVP for 524 voice and video within network A sites as well as on Network B's edge 525 to extend the reservation onto the attachment links between A and B 526 (as specified in [I-D.ietf-tsvwg-rsvp-l3vpn]) may be an example of 527 such controlled environment. Such an environment is illustrated in 528 Figure 4. 530 -------- -------- 531 / A \ / A \ 532 | | | | 533 | | ------------------------ | | 534 | (*) | /(*) (*) \ | (*) | 535 | | |<======>| |<============>| |<=====>| | | | 536 | - | | - - | | - | 537 \ / | \ - - / | \ / 538 -------- | TT-| | | |-TT | -------- 539 | - - | 540 \ / 541 ------------------------ 543 (*) closer examination of Router Alert option datagrams 545 <==> flow of Router Alert option datagrams 547 TT Tunneling of Router Alert option datagrams 549 Figure 6: Use of Router Alert In Leak-Controlled Overlay 551 4.3. Router Alert Protection Approaches for Service Providers 553 Section 3 discusses the security risks associated with the use of the 554 IP Router Alert and how it opens up a DOS vector in the router 555 control plane. Thus, it is RECOMMENDED that a Service Provider 556 implements strong protection of his network against attacks based on 557 IP Router Alert. 559 As discussed in Section 4.2.2 some applications can benefit from the 560 use of IP Router Alert packets in an Overlay model (i.e. Where 561 Router Alert packets are exchanged transparently on top of a Service 562 Provider). Thus, it is RECOMMENDED that a Service Provider protects 563 his network from attacks based on IP Router Alert using mechanisms 564 that avoid (or at least minimize) dropping of end to end IP Router 565 Alert packets (other than those involved in an attack). 567 For example, if the Service Provider does not run any protocol 568 depending on IP Router Alert within his network, he may elect to 569 simply turn-off punting/processing of IP Router Alert packet on his 570 routers; this will ensure that end-to-end IP Router Alert packet 571 transit transparently and safely through his network. 573 As another example, using protection mechanisms such selective 574 filtering and rate-limiting (that Section 5 suggests be supported by 575 IP Router Alert implementations) a Service Provider can protect the 576 operation of a protocol depending on IP Router Alert within his 577 network (e.g., RSVP-TE) while at the same time transporting IP Router 578 Alert packets carrying another protocol that may be used end to end. 579 Note that the Service Provider might additionally use protocol 580 specific mechanisms that reduce the dependency on Router Alert for 581 operation of this protocol inside the Service Provider environment; 582 use of RSVP refresh reduction mechanisms ([RFC2961]) would be an 583 example of such mechanisms in the case where the Service Provider is 584 running RSVP-TE within his network since this allows refresh of 585 existing Path and Resv states without use of the IP Router Alert 586 option. 588 As yet another example, using mechanisms such as those discussed in 589 [I-D.dasmith-mpls-ip-options] a Service Provider can safely protect 590 the operation of a protocol depending on IP Router Alert within his 591 network (e.g., RSVP-TE) while at the same time safely transporting IP 592 Router Alert packets carrying another protocol that may be used end 593 to end (e.g., IPv4/IPv6 RSVP). 595 As a last resort, if the SP does not have any means to safely 596 transport end to end IP Router Alert option packets over his network, 597 the SP MAY drop those packets. It must be noted that this has the 598 undesirable consequence of preventing the use of the Router Alert 599 option in the Overlay Model on top of this network, and therefore 600 prevents users of that network from deploying a number of valid 601 applications/protocols in their environment. 603 5. Guidelines for Router Alert Implementation 605 It is RECOMMENDED that router implementations of IP Router Alert 606 option include protection mechanisms against Router Alert based DOS 607 attacks appropriate for their targeted deployment environments. For 608 example, this can include ability on an edge router to "tunnel" IP 609 Router Alert option of received packets when forwarding those over 610 the core as discussed in [I-D.dasmith-mpls-ip-options]. As another 611 example, although not always available from current implementations, 612 new implementations may include protection mechanisms such as 613 selective (possibly dynamic) filtering and rate-limiting of IP Router 614 Alert option packets. 616 If an IP packet contains the IP Router Alert option, but the payload 617 protocol is not explicitly identified as a Payload of interest by the 618 router examining the packet, the behavior is not explicitly defined 619 by [RFC2113]. However, the behavior is implied and, for example, the 620 definition of RSVP in [RFC2205] assumes that the packet will be 621 forwarded using normal forwarding based on the destination IP 622 address. Thus, a router implementation SHOULD forward within the 623 "fast path" (subject to all normal policies and forwarding rules) a 624 packet carrying the IP Router Alert option containing a payload that 625 is not a payload of interest to that router. The "not passing" 626 behavior protects the router from DOS attacks using IP Router Alert 627 packets of a protocol unknown to the router. The "forwarding" 628 behavior contributes to transparent end to end transport of IP Router 629 Alert packets (e.g., to facilitate their use by end to end 630 application). 632 6. Security Considerations 634 This document discusses security risks associated with current usage 635 of the IP Router Alert Option and associated practices. 637 7. IANA Considerations 639 None. 641 8. Contributors 643 The contributors to this document (in addition to the editors) are: 645 o Reshad Rahman: 647 * Cisco Systems 649 * rrahman@cisco.com 651 o David Ward: 653 * Cisco Systems 655 * wardd@cisco.com 657 o Ashok Narayanan: 659 * Cisco Systems 661 * ashokn@cisco.com 663 o Adrian Farrell: 665 * OldDog Consulting 667 * adrian@olddog.co.uk 669 o Tony Li: 671 * tony.li@tony.li 673 9. Acknowledgments 675 We would like to thank Dave Oran, Magnus Westerlund, John Scudder, 676 Ron Bonica, Ross Callon, Alfred Hines and Carlos Pignataro for their 677 comments. This document also benefited from discussions with Jukka 678 Manner and Suresh Krishnan. The discussion about use of the value 679 field in the IPv4 Router Alert borrowed from a similar discussion in 680 [I-D.ietf-nsis-ntlp]. 682 10. References 684 10.1. Normative References 686 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 687 September 1981. 689 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 690 February 1997. 692 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 693 (IPv6) Specification", RFC 2460, December 1998. 695 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 696 RFC 2711, October 1999. 698 10.2. Informative References 700 [I-D.dasmith-mpls-ip-options] 701 Jaeger, W., Mullooly, J., Scholl, T., and D. Smith, 702 "Requirements for Label Edge Router Forwarding of IPv4 703 Option Packets", draft-dasmith-mpls-ip-options-01 (work in 704 progress), October 2008. 706 [I-D.ietf-nsis-ntlp] 707 Schulzrinne, H. and M. Stiemerling, "GIST: General 708 Internet Signalling Transport", draft-ietf-nsis-ntlp-20 709 (work in progress), June 2009. 711 [I-D.ietf-tsvwg-rsvp-l3vpn] 712 Davie, B., Faucheur, F., and A. Narayanan, "Support for 713 RSVP in Layer 3 VPNs", draft-ietf-tsvwg-rsvp-l3vpn-02 714 (work in progress), May 2009. 716 [I-D.krishnan-ipv6-hopbyhop] 717 Krishnan, S., "The case against Hop-by-Hop options", 718 draft-krishnan-ipv6-hopbyhop-03 (work in progress), 719 July 2009. 721 [I-D.narayanan-rtg-router-alert-extension] 722 Narayanan, A., Faucheur, F., Ward, D., and R. Rahman, "IP 723 Router Alert Option Extension", 724 draft-narayanan-rtg-router-alert-extension-00 (work in 725 progress), March 2009. 727 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 728 Requirement Levels", BCP 14, RFC 2119, March 1997. 730 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 731 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 732 Functional Specification", RFC 2205, September 1997. 734 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 735 Listener Discovery (MLD) for IPv6", RFC 2710, 736 October 1999. 738 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 739 and S. Molendini, "RSVP Refresh Overhead Reduction 740 Extensions", RFC 2961, April 2001. 742 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 743 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 744 RFC 3175, September 2001. 746 [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., 747 Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, 748 L., Tweedly, A., Bhaskar, N., Edmonstone, R., 749 Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport 750 Protocol Specification", RFC 3208, December 2001. 752 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 753 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 754 Tunnels", RFC 3209, December 2001. 756 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 757 Thyagarajan, "Internet Group Management Protocol, Version 758 3", RFC 3376, October 2002. 760 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 761 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 763 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 764 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 766 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 767 RFC 4286, December 2005. 769 [RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the 770 IPv4 and IPv6 Router Alert Options", RFC 5350, 771 September 2008. 773 Author's Address 775 Francois Le Faucheur (editor) 776 Cisco Systems 777 Greenside, 400 Avenue de Roumanille 778 Sophia Antipolis 06410 779 France 781 Phone: +33 4 97 23 26 19 782 Email: flefauch@cisco.com