idnits 2.17.1 draft-ietf-intarea-router-alert-considerations-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (June 27, 2011) is 4685 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) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 June 27, 2011 5 Expires: December 29, 2011 7 IP Router Alert Considerations and Usage 8 draft-ietf-intarea-router-alert-considerations-05 10 Abstract 12 The IP Router Alert Option is an IP option that alerts transit 13 routers to more closely examine the contents of an IP packet. 14 Resource reSerVation Protocol (RSVP), Pragmatic General Multicast 15 (PGM), Internet Group Management Protocol (IGMP), Multicast Listener 16 Discovery (MLD), Multicast Router Discovery (MRD) and General 17 Internet Signalling Transport (GIST) are some of the protocols that 18 make use of the IP Router Alert option. This document discusses 19 security aspects and usage guidelines around the use of the current 20 IP Router Alert option. Specifically, it provides recommendation 21 against using the Router Alert in the end-to-end open Internet as 22 well as identify controlled environments where protocols depending on 23 Router Alert can be used safely. It also provides recommendation 24 about protection approaches for Service Providers. Finally it 25 provides brief guidelines for Router Alert implementation on routers. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 29, 2011. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Security Concerns of Router Alert . . . . . . . . . . . . . . 6 65 4. Guidelines for use of Router Alert . . . . . . . . . . . . . . 9 66 4.1. Use of Router Alert End-to-End In the Internet (Router 67 Alert in Peer Model) . . . . . . . . . . . . . . . . . . . 9 68 4.2. Use of Router Alert In Controlled Environments . . . . . . 10 69 4.2.1. Use of Router Alert Within an Administrative Domain . 10 70 4.2.2. Use of Router Alert In Overlay Model . . . . . . . . . 12 71 4.3. Router Alert Protection Approaches for Service 72 Providers . . . . . . . . . . . . . . . . . . . . . . . . 15 73 5. Guidelines for Router Alert Implementation . . . . . . . . . . 17 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 76 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 78 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 79 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 80 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 83 1. Terminology 85 For readability, this document uses the following loosely defined 86 terms: 88 o Slow path : Software processing path for packets 90 o Fast path : ASIC/Hardware processing path for packets 92 o Next level protocol: the protocol transported in the IP datagram. 93 In IPv4 [RFC0791], the next level protocol is identified by the 94 IANA protocol number conveyed in the 8-bit "Protocol" field in the 95 IPv4 header. In IPv6 [RFC2460], the next level protocol is 96 identified by the IANA protocol number conveyed in the 8-bit "Next 97 Header" field in the IPv6 header. 99 1.1. Conventions Used in This Document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 2. Introduction 107 [RFC2113] and [RFC2711] respectively define the IPv4 and IPv6 Router 108 Alert Option (RAO). In this document, we collectively refer to those 109 as the IP Router Alert. The IP Router Alert Option is an IP option 110 that alerts transit routers to more closely examine the contents of 111 an IP packet. 113 Resource reSerVation Protocol (RSVP) ([RFC2205], [RFC3175], 114 [RFC3209]), Pragmatic General Multicast (PGM) ([RFC3208]), Internet 115 Group Management Protocol (IGMP) ([RFC3376]), Multicast Listener 116 Discovery (MLD) ([RFC2710], [RFC3810]), Multicast Router Discovery 117 (MRD) ([RFC4286]) and NSIS General Internet Signalling Transport 118 (GIST) ([RFC5971]) are some of the protocols that make use of the IP 119 Router Alert. 121 Section 3 describes the security concerns associated with the use of 122 the Router Alert option. 124 Section 4 provides guidelines for the use of Router Alert. More 125 specifically, Section 4.1 recommends that Router Alert not be used 126 for end to end applications over the Internet, while Section 4.2 127 presents controlled environments where applications/protocols relying 128 on IP Router Alert can be deployed effectively and safely. 129 Section 4.3 provides recommendations on protection approaches to be 130 used by Service Providers in order to protect their network from 131 Router Alert based attacks. 133 Finally, Section 5 provides generic recommendations for router 134 implementation of Router Alert aiming at increasing protection 135 against attacks. 137 The present document discusses considerations and practices based on 138 the current specification of IP Router Alert ([RFC2113], [RFC2711]). 139 Possible future enhancements to the specification of IP Router Alert 140 (in view of reducing the security risks associated with the use of IP 141 Router Alert) are outside the scope of this document. One such 142 proposal is discussed in [I-D.narayanan-rtg-router-alert-extension] 143 but at the time of this writing, the IETF has not adopted any 144 extensions for this purpose. 146 The IPv6 base specification [RFC2460] defines the hop-by-hop option 147 extension header. The hop-by-hop option header is used to carry 148 optional information that must be examined by every node along a 149 packet's delivery path. The IPv6 Router Alert Option is one 150 particular hop by hop option. Similar security concerns to those 151 discussed in the present document for the IPv6 Router Alert apply 152 more generically to the concept of IPv6 hop-by-hop option extension 153 header. However, addressing the broader concept of IPv6 hop-by-hop 154 option thoroughly would require additional material so as to cover 155 additional considerations associated with it (such as the attacks 156 effectiveness depending on how many options are included and on the 157 range from to which the option-type value belongs, etc.), so this is 158 kept outside the scope of the present document. A detailed 159 discussion about security risks and proposed remedies associated with 160 IPv6 hop-by-hop option can be found in [I-D.krishnan-ipv6-hopbyhop]. 162 The IPv4 base specification [RFC0791] defines a general notion of 163 IPv4 options that can be included in the IPv4 header (without 164 distinguishing between hop-by-hop versus end-to-end option). The 165 IPv4 Router Alert Option is one particular IPv4 option. Similar 166 security concerns to those discussed in the present document for the 167 IPv4 Router Alert apply more generically to the concept of IPv4 168 option. However, addressing the security concerns of the broader 169 concept of IPv4 option thoroughly is kept outside the scope of the 170 present document because it would require additional material so as 171 to cover additional considerations associated with it (such as lack 172 of option ordering, etc.), and because other IPv4 options are often 173 blocked in firewalls and not very widely used, so the practical risks 174 they present are largely non-existent. 176 3. Security Concerns of Router Alert 178 The IP Router Alert option is defined ([RFC2113], [RFC2711]) as a 179 mechanism that alerts transit routers to more closely examine the 180 contents of an IP packet. [RFC4081] and [RFC2711] mention the 181 security risks associated with the use of the IP Router Alert: 182 flooding a router with bogus (or simply undesired) IP datagrams which 183 contain the IP Router Alert could impact operation of the router in 184 undesirable ways. For example, assuming the router punts the 185 datagrams containing the IP Router Alert option to the slow path, 186 such an attack could consume a significant share of the router's slow 187 path and could also lead to packet drops in the slow path (thus, 188 affecting operation of all other applications and protocols operating 189 in the slow path). 191 Furthermore, [RFC2113] specifies no (and [RFC2711] specifies very 192 limited) mechanism for identifying different users of IP Router 193 Alert. As a result, many fast switching implementations of IP Router 194 Alert punt most/all packets marked with IP Router Alert into the slow 195 path (unless configured to systematically ignore or drop all Router 196 Alert packets). 198 Some IP Router Alert implementations may be able to take into account 199 the next level protocol as a discriminator for the punting decision 200 for different protocols using IP Router Alert. However, this still 201 only allows very coarse triage among various protocols using IP 202 Router Alert for two reasons. First, the next level protocol is the 203 same when IP Router Alert is used for different applications of the 204 same protocol (e.g., RSVP vs. RSVP-TE), or when IP Router Alert is 205 used for different contexts of the same application (e.g., different 206 levels of RSVP aggregation [RFC3175]). Thus, it is not possible to 207 achieve the necessary triage in the fast path across IP Router Alert 208 packets from different applications or from different contexts of an 209 application. Secondly, some protocols requiring punting may be 210 carried over a transport protocol (e.g., TCP or UDP) possibly because 211 they require the services of that transport protocol, possibly 212 because the protocol does not justify allocation of a scarce next 213 level protocol value or possibly because not relying on a very widely 214 deployed transport protocol is likely to result in deployment issues 215 due to common middlebox behaviors (e.g. Firewalls or NATs discarding 216 packets of "unknown" protocols). Thus, considering the next level 217 protocol does not allow triage in the fast path of IP Router Alert 218 packets from different protocols sharing the same transport protocol. 219 Therefore, it is generally not possible to ensure that only the IP 220 Router Alert packets for next level protocols of interest are punted 221 to the slow path while other IP Router Alert packets are efficiently 222 forwarded (i.e., in fast path). 224 Some IP Router Alert implementations may be able to take into account 225 the value field inside the router alert option. However, only one 226 value (zero) was defined in [RFC2113] and no IANA registry for IPv4 227 Router Alert values was available until recently ([RFC5350]). So 228 this did not allow most IPv4 Router Alert implementation to support 229 useful classification based on the value field in the fast path. 230 Also, while [RFC2113] states that unknown values should be ignored 231 (i.e. The packets should be forwarded as normal IP traffic), it has 232 been reported that some existing implementations simply ignore the 233 value field completely (i.e. Process any packet with an IPv4 Router 234 Alert regardless of its option value). An IANA registry for further 235 allocation of IPv4 Router Alert values has been introduced recently 236 ([RFC5350]) but this would only allow coarse-grain classification, 237 when, and if, supported by implementations. For IPv6, [RFC2711] 238 states that "the value field can be used by an implementation to 239 speed processing of the datagram within the transit router" and 240 defines an IANA registry for these values. But again, this only 241 allows coarse-grain classification. Besides, some existing IPv6 242 Router Alert implementations are reported to depart from that 243 behavior. 245 [RFC2711] mentions that limiting, by rate or some other means, the 246 use of IP Router Alert option is a way of protecting against a 247 potential attack. However, if rate limiting is used as a protection 248 mechanism but if the granularity of the rate limiting is not fine 249 enough to distinguish among IP Router Alert packet of interest from 250 unwanted IP Router Alert packet, a IP Router Alert attack could still 251 severely degrade operation of protocols of interest that depend on 252 the use of IP Router Alert. 254 In a nutshell, the IP router alert option does not provide a 255 convenient universal mechanism to accurately and reliably distinguish 256 between IP Router Alert packets of interest and unwanted IP Router 257 Alert packets. This, in turn, creates a security concern when IP 258 Router Alert option is used, because, short of appropriate router 259 implementation specific mechanisms, the router slow path is at risk 260 of being flooded by unwanted traffic. 262 Note that service providers commonly allow external parties to 263 communicate with a control plane application in their routers, such 264 as with BGP peering. Depending on the actual environment and BGP 265 security practices, the resulting DOS attack vector is similar, or 266 somewhat less serious, with BGP peering than with Router Alert option 267 for a number of reasons that include: 269 o With BGP, edge routers only exchange control plane information 270 with pre-identified peers and can easily filter out any control 271 plane traffic coming from other peers or non-authenticated peers, 272 while the Router-Alert option can be received in a datagram with 273 any source address and any destination source. However, we note 274 that effectiveness of such BGP filtering is dependent on proper 275 security practices; poor BGP security practices (such as 276 infrequent or inexistent update of BGP peers authentication keys) 277 create vulnerabilities through which the BGP authentication 278 mechanisms can be compromised. 280 o with BGP Peering, the control plane hole is only open on the edge 281 routers, and core routers are completely isolated from any direct 282 control plane exchange with entities outside the administrative 283 domain. Thus, with BGP, a DOS attack would only affect the edge 284 routers, while with Router Alert option, the attack could 285 propagate to core routers. However, in some BGP environments, the 286 distinction between edge and core routers is not strict, and many/ 287 most/all routers act as both edge and core routers; in such BGP 288 environments, a large part of the network is exposed to direct 289 control plane exchanges with entities outside the administrative 290 domain (as it would be with Router Alert). 292 o with BGP, the BGP policy control would typically prevent re- 293 injection of undesirable information out of the attacked device, 294 while with the Router-Alert option, the non-filtered attacking 295 messages would typically be forwarded downstream. However, we 296 note that there has been real life occurrences of situations where 297 incorrect information was propagated through the BGP system, 298 causing quite widespread problems. 300 4. Guidelines for use of Router Alert 302 4.1. Use of Router Alert End-to-End In the Internet (Router Alert in 303 Peer Model) 305 Because of the security concerns associated with Router Alert 306 discussed in Section 3, network operators need to actively protect 307 themselves against externally generated IP Router Alert packets. 308 Because there is no convenient universal mechanisms to triage between 309 desired and undesired router alert packets, network operators 310 currently often protect themselves in ways that isolate them from 311 externally generated IP Router Alert packets. This may be achieved 312 by tunneling IP Router Alert packets [RFC6178] so that the IP Router 313 Alert option is hidden through that network, or it may be achieved 314 via mechanisms resulting in occasional (e.g., rate limiting) or 315 systematic drop of IP Router Alert packets. 317 Thus, it is RECOMMENDED that applications and protocols not be 318 deployed with a dependency on processing of the Router Alert option 319 (as currently specified) across independent administrative domains in 320 the Internet. Figure 1 illustrates such a hypothetical use of Router 321 Alert end-to-end in the Internet. We refer to such a model of Router 322 Alert option use as a "Peer Model" Router Alert option use, since 323 core routers in different administrative domains would partake in 324 processing of Router Alert option datagrams associated with the same 325 signalling flow. 327 -------- -------- -------- -------- 328 / A \ / B \ / C \ / D \ 329 | (*) | | (*) | | (*) | | (*) | 330 | | |<============>| |<=============>| |<=============>| | | 331 | - | | - | | - | | - | 332 \ / \ / \ / \ / 333 -------- -------- -------- -------- 335 (*) closer examination of Router Alert option datagrams 337 <==> flow of Router Alert option datagrams 339 Figure 1: Use of Router Alert End-to-End in the Open Internet (Router 340 Alert in Peer Model) 342 While this recommendation is framed here specifically in the context 343 of router alert, the fundamental security risk that network operators 344 want to preclude is to allow devices/protocols that are outside of 345 their administrative domain (and therefore not controlled) to tap 346 into the control plane of their core routers. Whether this control 347 plane access is provided through router alert option or would be 348 provided by any other mechanism (e.g. Deep packet inspection) 349 probably results in similar security concerns. In other words, the 350 fundamental security concern is associated with the notion of end to 351 end signaling in a Peer Model across domains in the Internet. As a 352 result, it is expected that network operators would typically not 353 want to have their core routers partake in end-to-end signalling with 354 external uncontrolled devices through the open Internet, and 355 therefore prevent deployment of end to end signalling in a Peer model 356 through their network (regardless of whether that signalling uses 357 Router Alert or not). 359 4.2. Use of Router Alert In Controlled Environments 361 4.2.1. Use of Router Alert Within an Administrative Domain 363 In some controlled environments such as within a given Administrative 364 Domain, the network administrator can determine that IP Router Alert 365 packets will only be received from trusted well-behaved devices or 366 can establish that specific protection mechanisms (e.g., RAO 367 filtering and rate-limiting) against the plausible RAO-based DoS 368 attacks are sufficient. In that case, an application relying on 369 exchange and handling of RAO packets (e.g., RSVP) MAY be safely 370 deployed within the controlled network. A private enterprise network 371 firewalled from the Internet and using RSVP reservations for voice 372 and video flows may be an example of such controlled environment. 373 Such an environment is illustrated in Figure 2. 375 ------------------------- -------- -------- 376 / A \ / B \ / C \ 377 | (*) (*) | -- | | | | 378 | | |<============>| | |--|FW|--| |--------| | 379 | - - | -- | | | | 380 \ / \ / \ / 381 ------------------------- -------- -------- 383 (*) closer examination of Router Alert option datagrams 385 <==> flow of Router Alert option datagrams 387 FW Firewall 389 Figure 2: Use of Router Alert Within an Administrative Domain 391 In some controlled environments, several Administrative Domains have 392 a special relationship whereby they cooperate very tightly and 393 effectively operate as a single trust domain. In that case, one 394 domain is willing to trust another with respect to the traffic 395 injected across the boundary. In other words, a downstream domain is 396 willing to trust that the traffic injected at the boundary has been 397 properly validated/filtered by the upstream domain. Where it has 398 been established that such trust can be applied to router alert 399 option packets, an application relying on exchange and handling of 400 RAO packets (e.g., RSVP) MAY be safely deployed within such a 401 controlled environment. The entity within a company responsible for 402 operating multimedia endpoints and the entity within the same company 403 responsible for operating the network may be an example of such 404 controlled environment. For example, they may collaborate so that 405 RSVP reservations can be used for video flows from endpoints to 406 endpoints through the network. 408 In some environments, the network administrator can reliably ensure 409 that router alert packets from any untrusted device (e.g., from 410 external routers) are prevented from entering a trusted area (e.g., 411 the internal routers). For example, this may be achieved by ensuring 412 that routers straddling the trust boundary (e.g., edge routers) 413 always encapsulate those packets (without setting IP Router Alert -or 414 equivalent- in the encapsulating header) through the trusted area (as 415 discussed in [RFC6178]). In such environments, the risks of DOS 416 attacks through the IP Router Alert vector is removed in the trusted 417 area (or greatly reduced) even if IP Router Alert is used inside the 418 trusted area (say for RSVP-TE). Thus an application relying on IP 419 Router Alert MAY be safely deployed within the trusted area. A 420 Service Provider running RSVP-TE within his network may be an example 421 of such protected environment. Such an environment is illustrated in 422 Figure 3. 424 -------- -------------------------- -------- 425 / A \ / B \ / C \ 426 | | | (*) (*) | | | 427 | |-------TT | |<=============>| | TT------- | | 428 | | | - - | | | 429 \ / \ / \ / 430 -------- -------------------------- -------- 432 (*) closer examination of Router Alert option datagrams 434 <==> flow of Router Alert option datagrams 436 TT Tunneling of Router Alert option datagrams 438 Figure 3: Use of Router Alert Within an Administrative Domain 440 4.2.2. Use of Router Alert In Overlay Model 442 In some controlled environment: 444 o the sites of a network A are interconnected through a service 445 provider network B 447 o the service provider network B protects itself from IP Router 448 Alert messages without dropping those when they transit over the 449 transit network (for example using mechanisms discussed in 450 [RFC6178]) 452 In such controlled environment, an application relying on exchange 453 and handling of RAO packets (e.g., RSVP) in the network A sites (but 454 not inside network B) MAY be safely deployed. We refer to such a 455 deployment as a use of Router Alert in a Water-Tight Overlay. 456 "Overlay" because Router Alert option datagrams are used in network A 457 on top of, and completely transparently to, network B. "Water-Tight" 458 because router alert option datagrams from A cannot leak inside 459 network B. A private enterprise intranet, whose sites are 460 interconnected through a Service Prover network, and using RSVP to 461 perform reservations within the enterprise sites for voice and video 462 flows may be an example of such controlled environment. Such an 463 environment is illustrated in Figure 4. 465 -------- -------- 466 / A \ / A \ 467 | (*) | | (*) | 468 | | |<=================================>| | | | 469 | - | | - | 470 \ / \ / 471 -------- -------- 472 \ / 473 \ ------------------------- / 474 \ / B \ / 475 \| |/ 476 TT TT 477 | | 478 \ / 479 ------------------------- 481 (*) closer examination of Router Alert option datagrams 483 <==> flow of Router Alert option datagrams 485 TT Tunneling of Router Alert option datagrams 487 Figure 4: Use of Router Alert In Water-tight Overlay 489 In the controlled environment described above, an application relying 490 on exchange and handling of RAO packets (e.g. RSVP-TE) in the 491 service provider network B (but not in network A) MAY also be safely 492 deployed simultaneously. Such an environment with independent, 493 isolated, deployment of router alert in overlay at two levels is 494 illustrated in Figure 5. 496 -------- -------- 497 / A \ / A \ 498 | (*) | | (*) | 499 | | |<=================================>| | | | 500 | - | | - | 501 \ / \ / 502 -------- -------- 503 \ / 504 \ ------------------------- / 505 \ / B \ / 506 \| (*) (*) |/ 507 TT | |<============>| | TT 508 | - - | 509 \ / 510 ------------------------- 512 (*) closer examination of Router Alert option datagrams 514 <==> flow of Router Alert option datagrams 516 TT Tunneling of Router Alert option datagrams 518 Figure 5: Use of Router Alert In Water-tight Overlay at Two Levels 520 In some controlled environment: 522 o the sites of a network A are interconnected through a service 523 provider network B 525 o the service provider B processes router alert packets on the edge 526 routers and protect these edge routers against RAO based attacks 527 using mechanisms such as (possibly per port) RAO rate limiting and 528 filtering 530 o the service provider network B protects its core routers from 531 Router Alert messages without dropping those when they transit 532 over the transit network (for example using mechanisms discussed 533 in [RFC6178]) 535 In such controlled environment, an application relying on exchange 536 and handling of RAO packets (e.g., RSVP) in the network A sites and 537 in network B Edges (but not in the core of network B) MAY be safely 538 deployed. We refer to such a deployment as a use of Router Alert in 539 a Leak-Controlled Overlay. "Overlay" because Router Alert option 540 datagrams are used in network A on top of, and completely 541 transparently to, network B core. "Leak-Controlled" because router 542 alert option datagrams from A leak inside network B's B edges but not 543 inside network B's core. A private enterprise intranet, whose sites 544 are interconnected through a Service Prover network, using RSVP for 545 voice and video within network A sites as well as on Network B's edge 546 to extend the reservation onto the attachment links between A and B 547 (as specified in [RFC6016]) may be an example of such controlled 548 environment. Such an environment is illustrated in Figure 4. 550 -------- -------- 551 / A \ / A \ 552 | | | | 553 | | ------------------------ | | 554 | (*) | /(*) (*) \ | (*) | 555 | | |<======>| |<============>| |<=====>| | | | 556 | - | | - - | | - | 557 \ / | \ - - / | \ / 558 -------- | TT-| | | |-TT | -------- 559 | - - | 560 \ / 561 ------------------------ 563 (*) closer examination of Router Alert option datagrams 565 <==> flow of Router Alert option datagrams 567 TT Tunneling of Router Alert option datagrams 569 Figure 6: Use of Router Alert In Leak-Controlled Overlay 571 4.3. Router Alert Protection Approaches for Service Providers 573 Section 3 discusses the security risks associated with the use of the 574 IP Router Alert and how it opens up a DOS vector in the router 575 control plane. Thus, it is RECOMMENDED that a Service Provider 576 implements strong protection of his network against attacks based on 577 IP Router Alert. 579 As discussed in Section 4.2.2 some applications can benefit from the 580 use of IP Router Alert packets in an Overlay model (i.e. Where 581 Router Alert packets are exchanged transparently on top of a Service 582 Provider). Thus, it is RECOMMENDED that a Service Provider protects 583 his network from attacks based on IP Router Alert using mechanisms 584 that avoid (or at least minimize) dropping of end to end IP Router 585 Alert packets (other than those involved in an attack). 587 For example, if the Service Provider does not run any protocol 588 depending on IP Router Alert within his network, he may elect to 589 simply turn-off punting/processing of IP Router Alert packet on his 590 routers; this will ensure that end-to-end IP Router Alert packet 591 transit transparently and safely through his network. 593 As another example, using protection mechanisms such selective 594 filtering and rate-limiting (that Section 5 suggests be supported by 595 IP Router Alert implementations) a Service Provider can protect the 596 operation of a protocol depending on IP Router Alert within his 597 network (e.g., RSVP-TE) while at the same time transporting IP Router 598 Alert packets carrying another protocol that may be used end to end. 599 Note that the Service Provider might additionally use protocol 600 specific mechanisms that reduce the dependency on Router Alert for 601 operation of this protocol inside the Service Provider environment; 602 use of RSVP refresh reduction mechanisms ([RFC2961]) would be an 603 example of such mechanisms in the case where the Service Provider is 604 running RSVP-TE within his network since this allows refresh of 605 existing Path and Resv states without use of the IP Router Alert 606 option. 608 As yet another example, using mechanisms such as those discussed in 609 [RFC6178] a Service Provider can safely protect the operation of a 610 protocol depending on IP Router Alert within his network (e.g., 611 RSVP-TE) while at the same time safely transporting IP Router Alert 612 packets carrying another protocol that may be used end to end (e.g., 613 IPv4/IPv6 RSVP). We observe that while tunneling of Router Alert 614 option datagrams over an MPLS backbone as discussed in [RFC6178] is 615 well understood, tunneling Router Alert option datagrams over an non- 616 MPLS IP backbone presents a number of issues (and in particular for 617 determining where to forward the encapsulated datagram) and is not 618 common practice at the time of writing this document. 620 As a last resort, if the SP does not have any means to safely 621 transport end to end IP Router Alert option packets over his network, 622 the SP MAY drop those packets. It must be noted that this has the 623 undesirable consequence of preventing the use of the Router Alert 624 option in the Overlay Model on top of this network, and therefore 625 prevents users of that network from deploying a number of valid 626 applications/protocols in their environment. 628 5. Guidelines for Router Alert Implementation 630 It is RECOMMENDED that router implementations of IP Router Alert 631 option include protection mechanisms against Router Alert based DOS 632 attacks appropriate for their targeted deployment environments. For 633 example, this can include ability on an edge router to "tunnel" IP 634 Router Alert option of received packets when forwarding those over 635 the core as discussed in [RFC6178]. As another example, although not 636 always available from current implementations, new implementations 637 MAY include protection mechanisms such as selective (possibly 638 dynamic) filtering and rate-limiting of IP Router Alert option 639 packets. 641 If an IP packet contains the IP Router Alert option, but the next 642 level protocol is not explicitly identified as a protocol of interest 643 by the router examining the packet, the behavior is not explicitly 644 defined by [RFC2113]. However, the behavior is implied and, for 645 example, the definition of RSVP in [RFC2205] assumes that the packet 646 will be forwarded using normal forwarding based on the destination IP 647 address. Thus, a router implementation SHOULD forward within the 648 "fast path" (subject to all normal policies and forwarding rules) a 649 packet carrying the IP Router Alert option containing a next level 650 protocol that is not a protocol of interest to that router. The "not 651 punting" behavior protects the router from DOS attacks using IP 652 Router Alert packets of a protocol unknown to the router. The 653 "forwarding" behavior contributes to transparent end to end transport 654 of IP Router Alert packets (e.g., to facilitate their use by end to 655 end application). 657 Similarly, an implementation MAY support selective forwarding within 658 "the fast path" (subject to all normal policies and forwarding rules) 659 or punting of a packet with the IP Router Alert Option, based on the 660 Value field of the Router Alert Option. This would allow router 661 protection against DOS attacks using IP Router Alert packets with 662 value that is not relevant for that router (e.g. Nesting levels of 663 Aggregated RSVP Reservation [RFC5350]). 665 6. Security Considerations 667 This document discusses security risks associated with current usage 668 of the IP Router Alert Option and associated practices. 670 7. IANA Considerations 672 None. 674 8. Contributors 676 The contributors to this document (in addition to the editors) are: 678 o Reshad Rahman: 680 * Cisco Systems 682 * rrahman@cisco.com 684 o David Ward: 686 * Juniper Networks 688 * dward@juniper.net 690 o Ashok Narayanan: 692 * Cisco Systems 694 * ashokn@cisco.com 696 o Adrian Farrell: 698 * OldDog Consulting 700 * adrian@olddog.co.uk 702 o Tony Li: 704 * tony.li@tony.li 706 9. Acknowledgments 708 We would like to thank Dave Oran, Magnus Westerlund, John Scudder, 709 Ron Bonica, Ross Callon, Alfred Hines, Carlos Pignataro and Roland 710 Bless for their comments. This document also benefited from 711 discussions with Jukka Manner and Suresh Krishnan. The discussion 712 about use of the value field in the IPv4 Router Alert borrowed from a 713 similar discussion in [RFC5971]. 715 10. References 717 10.1. Normative References 719 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 720 September 1981. 722 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 723 February 1997. 725 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 726 (IPv6) Specification", RFC 2460, December 1998. 728 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 729 RFC 2711, October 1999. 731 [RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the 732 IPv4 and IPv6 Router Alert Options", RFC 5350, 733 September 2008. 735 10.2. Informative References 737 [I-D.krishnan-ipv6-hopbyhop] 738 Krishnan, S., "The case against Hop-by-Hop options", 739 draft-krishnan-ipv6-hopbyhop-05 (work in progress), 740 October 2010. 742 [I-D.narayanan-rtg-router-alert-extension] 743 Narayanan, A., Faucheur, F., Ward, D., and R. Rahman, "IP 744 Router Alert Option Extension", 745 draft-narayanan-rtg-router-alert-extension-00 (work in 746 progress), March 2009. 748 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 749 Requirement Levels", BCP 14, RFC 2119, March 1997. 751 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 752 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 753 Functional Specification", RFC 2205, September 1997. 755 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 756 Listener Discovery (MLD) for IPv6", RFC 2710, 757 October 1999. 759 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 760 and S. Molendini, "RSVP Refresh Overhead Reduction 761 Extensions", RFC 2961, April 2001. 763 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 764 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 765 RFC 3175, September 2001. 767 [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., 768 Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, 769 L., Tweedly, A., Bhaskar, N., Edmonstone, R., 770 Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport 771 Protocol Specification", RFC 3208, December 2001. 773 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 774 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 775 Tunnels", RFC 3209, December 2001. 777 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 778 Thyagarajan, "Internet Group Management Protocol, Version 779 3", RFC 3376, October 2002. 781 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 782 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 784 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 785 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 787 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 788 RFC 4286, December 2005. 790 [RFC5971] Schulzrinne, H. and R. Hancock, "GIST: General Internet 791 Signalling Transport", RFC 5971, October 2010. 793 [RFC6016] Davie, B., Le Faucheur, F., and A. Narayanan, "Support for 794 the Resource Reservation Protocol (RSVP) in Layer 3 VPNs", 795 RFC 6016, October 2010. 797 [RFC6178] Smith, D., Mullooly, J., Jaeger, W., and T. Scholl, "Label 798 Edge Router Forwarding of IPv4 Option Packets", RFC 6178, 799 March 2011. 801 Author's Address 803 Francois Le Faucheur (editor) 804 Cisco Systems 805 Greenside, 400 Avenue de Roumanille 806 Sophia Antipolis 06410 807 France 809 Phone: +33 4 97 23 26 19 810 Email: flefauch@cisco.com