idnits 2.17.1 draft-ietf-intarea-router-alert-considerations-02.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 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 25, 2010) is 4925 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 1883 (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-ip-options-04 Summary: 2 errors (**), 0 flaws (~~), 3 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 25, 2010 5 Expires: April 28, 2011 7 IP Router Alert Considerations and Usage 8 draft-ietf-intarea-router-alert-considerations-02 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. RSVP, 14 PGM, IGMP/MLD, MRD and GIST are some of the protocols that make use 15 of the IP Router Alert option. This document discusses security 16 aspects and usage guidelines around the use of the current IP Router 17 Alert option. Specifically, it provides recommendation against using 18 the Router Alert in the end-to-end open Internet as well as identify 19 controlled environments where protocols depending on Router Alert can 20 be used safely. It also provides recommendation about protection 21 approaches for Service Providers. Finally it provides brief 22 guidelines for Router Alert implementation on routers. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 28, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 This document may contain material from IETF Documents or IETF 57 Contributions published or made publicly available before November 58 10, 2008. The person(s) controlling the copyright in some of this 59 material may not have granted the IETF Trust the right to allow 60 modifications of such material outside the IETF Standards Process. 61 Without obtaining an adequate license from the person(s) controlling 62 the copyright in such materials, this document may not be modified 63 outside the IETF Standards Process, and derivative works of it may 64 not be created outside the IETF Standards Process, except to format 65 it for publication as an RFC or to translate it into languages other 66 than English. 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 o Next level protocol: the protocol transported in the IP datagram. 102 In IPv4 [RFC0791], the next level protocol is identified by the 103 IANA protocol number conveyed in the 8-bit "Protocol" field in the 104 IPv4 header. In IPv6 [RFC1883], the next level protocol is 105 identified by the IANA protocol number conveyed in the 8-bit "Next 106 Header" field in the IPv6 header. 108 1.1. Conventions Used in This Document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 2. Introduction 116 [RFC2113] and [RFC2711] respectively define the IPv4 and IPv6 Router 117 Alert Option (RAO). In this document, we collectively refer to those 118 as the IP Router Alert. The IP Router Alert Option is an IP option 119 that alerts transit routers to more closely examine the contents of 120 an IP packet. 122 RSVP ([RFC2205], [RFC3175], [RFC3209]), PGM ([RFC3208]), IGMP 123 ([RFC3376]), MLD ([RFC2710], [RFC3810]), MRD ([RFC4286]) and NSIS 124 General Internet Signalling Transport (GIST) ([I-D.ietf-nsis-ntlp]) 125 are some of the protocols that make use of the IP Router Alert. 127 Section 3 describes the security concerns associated with the use of 128 the Router Alert option. 130 Section 4 provides guidelines for the use of Router Alert. More 131 specifically, Section 4.1 recommends that Router Alert not be used 132 for end to end applications over the Internet, while Section 4.2 133 presents controlled environments where applications/protocols relying 134 on IP Router Alert can be deployed effectively and safely. 135 Section 4.3 provides recommendations on protection approaches to be 136 used by Service Providers in order to protect their network from 137 Router Alert based attacks. 139 Finally, Section 5 provides generic recommendations for router 140 implementation of Router Alert aiming at increasing protection 141 against attacks. 143 The present document discusses considerations and practises based on 144 the current specification of IP Router Alert ([RFC2113], [RFC2711]). 145 Possible future enhancements to the specification of IP Router Alert 146 (in view of reducing the security risks associated with the use of IP 147 Router Alert) are outside the scope of this document. A proposal for 148 such enhancements can be found in 149 [I-D.narayanan-rtg-router-alert-extension]. 151 The IPv6 base specification [RFC2460] defines the hop-by-hop option 152 extension header. The hop-by-hop option header is used to carry 153 optional information that must be examined by every node along a 154 packet's delivery path. The IPv6 Router Alert Option is one 155 particular hop by hop option. Similar security concerns to those 156 discussed in the present document for the IPv6 Router Alert apply 157 more generically to the concept of IPv6 hop-by-hop option extension 158 header. However, addressing the broader concept of IPv6 hop-by-hop 159 option thoroughly would require additional material so as to cover 160 additional considerations associated with it (such as the attacks 161 effectiveness depending on how many options are included and on the 162 range from to which the option-type value belongs, etc.), so this is 163 kept outside the scope of the present document. A detailed 164 discussion about security risks and proposed remedies associated with 165 IPv6 hop-by-hop option can be found in [I-D.krishnan-ipv6-hopbyhop]. 167 The IPv4 base specification [RFC0791] defines a general notion of 168 IPv4 options that can be included in the IPv4 header (without 169 distinguishing between hop-by-hop versus end-to-end option). The 170 IPv4 Router Alert Option is one particular IPv4 option. Similar 171 security concerns to those discussed in the present document for the 172 IPv4 Router Alert apply more generically to the concept of IPv4 173 option. However, addressing the broader concept of IPv4 option 174 thoroughly would require additional material so as to cover 175 additional considerations associated with it (such as lack of option 176 ordering, etc.), so this is kept outside the scope of the present 177 document. 179 3. Security Concerns of Router Alert 181 The IP Router Alert option is defined ([RFC2113], [RFC2711]) as a 182 mechanism that alerts transit routers to more closely examine the 183 contents of an IP packet. [RFC4081] and [RFC2711] mention the 184 security risks associated with the use of the IP Router Alert: 185 flooding a router with bogus (or simply undesired) IP datagrams which 186 contain the IP Router Alert could impact operation of the router in 187 undesirable ways. For example, assuming the router punts the 188 datagrams containing the IP Router Alert option to the slow path, 189 such an attack could consume a significant share of the router's slow 190 path and could also lead to packet drops in the slow path (thus, 191 affecting operation of all other applications and protocols operating 192 in the slow path). 194 Furthermore, [RFC2113] specifies no (and [RFC2711] specifies very 195 limited) mechanism for identifying different users of IP Router 196 Alert. As a result, many fast switching implementations of IP Router 197 Alert punt most/all packets marked with IP Router Alert into the slow 198 path (unless configured to systematically ignore or drop all Router 199 Alert packets). 201 Some IP Router Alert implementations may be able to take into account 202 the next level protocol as a discriminator for the punting decision 203 for different protocols using IP Router Alert. However, this still 204 only allows very coarse triage among various protocols using IP 205 Router Alert for two reasons. First, the next level protocol is the 206 same when IP Router Alert is used for different applications of the 207 same protocol (e.g., RSVP vs. RSVP-TE), or when IP Router Alert is 208 used for different contexts of the same application (e.g., different 209 levels of RSVP aggregation [RFC3175]). Thus, it is not possible to 210 achieve the necessary triage in the fast path across IP Router Alert 211 packets from different applications or from different contexts of an 212 application. Secondly, some protocols requiring punting may be 213 carried over a transport protocol (e.g., TCP or UDP) possibly because 214 they require the services of that transport protocol or perhaps 215 because the protocol does not justify allocation of a scarce next 216 level protocol value. Thus, considering the next level protocol does 217 not allow triage in the fast path of IP Router Alert packets from 218 different protocols sharing the same transport protocol. Therefore, 219 it is generally not possible to ensure that only the IP Router Alert 220 packets of interest are punted to the slow path while other IP Router 221 Alert packets are efficiently forwarded (i.e., in fast path). 223 Some IP Router Alert implementations may be able to take into account 224 the value field inside the router alert option. However, only one 225 value (zero) was defined in [RFC2113] and no IANA registry for IPv4 226 Router Alert values was available until recently. So this did not 227 allow most IPv4 Router Alert implementation to support useful 228 classification based on the value field in the fast path. Also, 229 while [RFC2113] states that unknown values should be ignored (i.e. 230 The packets should be forwarded as normal IP traffic), it has been 231 reported that some existing implementations simply ignore the value 232 field completely (i.e. Process any packet with an IPv4 Router Alert 233 regardless of its option value). An IANA registry for further 234 allocation of IPv4 Router Alert values has been introduced recently 235 ([RFC5350]) but this would only allow coarse-grain classification, 236 when, and if, supported by implementations. For IPv6, [RFC2711] 237 states that "the value field can be used by an implementation to 238 speed processing of the datagram within the transit router" and 239 defines an IANA registry for these values. But again, this only 240 allows coarse-grain classification. Besides, some existing IPv6 241 Router Alert implementations are reported to depart from that 242 behavior. 244 [RFC2711] mentions that limiting, by rate or some other means, the 245 use of IP Router Alert option is a way of protecting against a 246 potential attack. However, if rate limiting is used as a protection 247 mechanism but if the granularity of the rate limiting is not fine 248 enough to distinguish among IP Router Alert packet of interest from 249 unwanted IP Router Alert packet, a IP Router Alert attack could still 250 severely degrade operation of protocols of interest that depend on 251 the use of IP Router Alert. 253 In a nutshell, the IP router alert option does not provide a 254 convenient universal mechanism to accurately and reliably distinguish 255 between IP Router Alert packets of interest and unwanted IP Router 256 Alert packets. This, in turn, creates a security concern when IP 257 Router Alert option is used, because, short of appropriate router 258 implementation specific mechanisms, the router slow path is at risk 259 of being flooded by unwanted traffic. 261 It can be observed that opening up a hole in the control plane of 262 Service Provider routers is commonly done for other applications, 263 such as BGP peering. Depending on the actual environment and BGP 264 security practises, the resulting DOS attack vector is similar, or 265 somewhat less serious, with BGP peering than with Router Alert option 266 for a number of reasons that include: 268 o With BGP, edge routers only exchange control plane information 269 with pre-identified peers and can easily filter out any control 270 plane traffic coming from other peers or non-authenticated peers, 271 while the Router-Alert option can be received in a datagram with 272 any source address and any destination source. However, we note 273 that effectiveness of such BGP filtering is dependent on proper 274 security practises; poor BGP security practices (such as 275 infrequent or inexistent update of BGP peers authentication keys) 276 create vulnerabilities through which the BGP authentication 277 mechanisms can be compromised. 279 o with BGP Peering, the control plane hole is only open on the edge 280 routers, and core routers are completely isolated from any direct 281 control plane exchange with entities outside the administrative 282 domain. Thus, with BGP, a DOS attack would only affect the edge 283 routers, while with Router Alert option, the attack could 284 propagate to core routers. However, in some BGP environments, the 285 distinction between edge and core routers is not strict, and many/ 286 most/all routers act as both edge and core routers; in such BGP 287 environments, a large part of the network is exposed to direct 288 control plane exchanges with entities outside the administrative 289 domain (as it would be with Router Alert). 291 o with BGP, the BGP policy control would typically prevent re- 292 injection of undesirable information out of the attacked device, 293 while with the Router-Alert option, the non-filtered attacking 294 messages would typically be forwarded downstream. However, we 295 note that there has been real life occurences of situations where 296 incorrect information was propagated through the BGP system, 297 causing quite widespread problems. 299 4. Guidelines for use of Router Alert 301 4.1. Use of Router Alert End-to-End In the Internet (Router Alert in 302 Peer Model) 304 Because of the security concerns associated with Router Alert 305 discussed in Section 3, network operators need to actively protect 306 themselves against externally generated IP Router Alert packets. 307 Because there is no convenient universal mechanisms to triage between 308 desired and undesired router alert packets, network operators 309 currently often protect themselves in ways that isolate them from 310 externally generated IP Router Alert packets. This may (ideally) be 311 achieved by tunneling IP Router Alert packets 312 [I-D.ietf-mpls-ip-options] so that the IP Router Alert option is 313 hidden through that network, or it may be achieved via mechanisms 314 resulting in occasional (e.g., rate limiting) or systematic drop of 315 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 [I-D.ietf-mpls-ip-options]). In such environments, the 416 risks of DOS attacks through the IP Router Alert vector is removed in 417 the trusted area (or greatly reduced) even if IP Router Alert is used 418 inside the trusted area (say for RSVP-TE). Thus an application 419 relying on IP Router Alert MAY be safely deployed within the trusted 420 area. A Service Provider running RSVP-TE within his network may be 421 an example of such protected environment. Such an environment is 422 illustrated in 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 [I-D.ietf-mpls-ip-options]) 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 [I-D.ietf-mpls-ip-options]) 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 [I-D.ietf-mpls-ip-options] a Service Provider can safely protect the 610 operation of a protocol depending on IP Router Alert within his 611 network (e.g., RSVP-TE) while at the same time safely transporting IP 612 Router Alert packets carrying another protocol that may be used end 613 to end (e.g., IPv4/IPv6 RSVP). We observe that while tunneling of 614 Router Alert option datagrams over an MPLS backbone as discussed in 615 [I-D.ietf-mpls-ip-options] is well understood, tunnelling Router 616 Alert option datagrams over an non-MPLS IP backbone presents a number 617 of issues (and in particular for determining where to forward the 618 encapsulated datagram) and is not common practise at the time of 619 writing this document. 621 As a last resort, if the SP does not have any means to safely 622 transport end to end IP Router Alert option packets over his network, 623 the SP MAY drop those packets. It must be noted that this has the 624 undesirable consequence of preventing the use of the Router Alert 625 option in the Overlay Model on top of this network, and therefore 626 prevents users of that network from deploying a number of valid 627 applications/protocols in their environment. 629 5. Guidelines for Router Alert Implementation 631 It is RECOMMENDED that router implementations of IP Router Alert 632 option include protection mechanisms against Router Alert based DOS 633 attacks appropriate for their targeted deployment environments. For 634 example, this can include ability on an edge router to "tunnel" IP 635 Router Alert option of received packets when forwarding those over 636 the core as discussed in [I-D.ietf-mpls-ip-options]. As another 637 example, although not always available from current implementations, 638 new implementations MAY include protection mechanisms such as 639 selective (possibly dynamic) filtering and rate-limiting of IP Router 640 Alert option packets. 642 If an IP packet contains the IP Router Alert option, but the next 643 level protocol is not explicitly identified as a protocol of interest 644 by the router examining the packet, the behavior is not explicitly 645 defined by [RFC2113]. However, the behavior is implied and, for 646 example, the definition of RSVP in [RFC2205] assumes that the packet 647 will be forwarded using normal forwarding based on the destination IP 648 address. Thus, a router implementation SHOULD forward within the 649 "fast path" (subject to all normal policies and forwarding rules) a 650 packet carrying the IP Router Alert option containing a next level 651 protocol that is not a protocol of interest to that router. The "not 652 punting" behavior protects the router from DOS attacks using IP 653 Router Alert packets of a protocol unknown to the router. The 654 "forwarding" behavior contributes to transparent end to end transport 655 of IP Router Alert packets (e.g., to facilitate their use by end to 656 end application). 658 Similarly, an implementation MAY support selective forwarding within 659 "the fast path" (subject to all normal policies and forwarding rules) 660 or punting of a packet with the IP Router Alert Option, based on the 661 Value field of the Router Alert Option. This would allow router 662 protection against DOS attacks using IP Router Alert packets with 663 value that is not relevant for that router (e.g. nesting levels of 664 Aggregated RSVP Reservation [RFC5350]). 666 6. Security Considerations 668 This document discusses security risks associated with current usage 669 of the IP Router Alert Option and associated practices. 671 7. IANA Considerations 673 None. 675 8. Contributors 677 The contributors to this document (in addition to the editors) are: 679 o Reshad Rahman: 681 * Cisco Systems 683 * rrahman@cisco.com 685 o David Ward: 687 * Juniper Networks 689 * dward@juniper.net 691 o Ashok Narayanan: 693 * Cisco Systems 695 * ashokn@cisco.com 697 o Adrian Farrell: 699 * OldDog Consulting 701 * adrian@olddog.co.uk 703 o Tony Li: 705 * tony.li@tony.li 707 9. Acknowledgments 709 We would like to thank Dave Oran, Magnus Westerlund, John Scudder, 710 Ron Bonica, Ross Callon, Alfred Hines and Carlos Pignataro for their 711 comments. This document also benefited from discussions with Jukka 712 Manner and Suresh Krishnan. The discussion about use of the value 713 field in the IPv4 Router Alert borrowed from a similar discussion in 714 [I-D.ietf-nsis-ntlp]. 716 10. References 718 10.1. Normative References 720 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 721 September 1981. 723 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 724 (IPv6) Specification", RFC 1883, December 1995. 726 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 727 February 1997. 729 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 730 (IPv6) Specification", RFC 2460, December 1998. 732 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 733 RFC 2711, October 1999. 735 [RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the 736 IPv4 and IPv6 Router Alert Options", RFC 5350, 737 September 2008. 739 10.2. Informative References 741 [I-D.ietf-mpls-ip-options] 742 Jaeger, W., Mullooly, J., Scholl, T., and D. Smith, 743 "Requirements for Label Edge Router Forwarding of IPv4 744 Option Packets", draft-ietf-mpls-ip-options-04 (work in 745 progress), May 2010. 747 [I-D.ietf-nsis-ntlp] 748 Schulzrinne, H. and M. Stiemerling, "GIST: General 749 Internet Signalling Transport", draft-ietf-nsis-ntlp-20 750 (work in progress), June 2009. 752 [I-D.krishnan-ipv6-hopbyhop] 753 Krishnan, S., "The case against Hop-by-Hop options", 754 draft-krishnan-ipv6-hopbyhop-05 (work in progress), 755 October 2010. 757 [I-D.narayanan-rtg-router-alert-extension] 758 Narayanan, A., Faucheur, F., Ward, D., and R. Rahman, "IP 759 Router Alert Option Extension", 760 draft-narayanan-rtg-router-alert-extension-00 (work in 761 progress), March 2009. 763 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 764 Requirement Levels", BCP 14, RFC 2119, March 1997. 766 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 767 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 768 Functional Specification", RFC 2205, September 1997. 770 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 771 Listener Discovery (MLD) for IPv6", RFC 2710, 772 October 1999. 774 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 775 and S. Molendini, "RSVP Refresh Overhead Reduction 776 Extensions", RFC 2961, April 2001. 778 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 779 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 780 RFC 3175, September 2001. 782 [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., 783 Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, 784 L., Tweedly, A., Bhaskar, N., Edmonstone, R., 785 Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport 786 Protocol Specification", RFC 3208, December 2001. 788 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 789 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 790 Tunnels", RFC 3209, December 2001. 792 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 793 Thyagarajan, "Internet Group Management Protocol, Version 794 3", RFC 3376, October 2002. 796 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 797 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 799 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 800 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 802 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 803 RFC 4286, December 2005. 805 [RFC6016] Davie, B., Le Faucheur, F., and A. Narayanan, "Support for 806 the Resource Reservation Protocol (RSVP) in Layer 3 VPNs", 807 RFC 6016, October 2010. 809 Author's Address 811 Francois Le Faucheur (editor) 812 Cisco Systems 813 Greenside, 400 Avenue de Roumanille 814 Sophia Antipolis 06410 815 France 817 Phone: +33 4 97 23 26 19 818 Email: flefauch@cisco.com