idnits 2.17.1 draft-ietf-intarea-router-alert-considerations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 (March 1, 2010) is 5169 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-05 == 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 March 1, 2010 5 Expires: September 2, 2010 7 IP Router Alert Considerations and Usage 8 draft-ietf-intarea-router-alert-considerations-00 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 to IETF 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), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 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 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on September 2, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 77 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3. Security Concerns of Router Alert . . . . . . . . . . . . . . 7 79 4. Guidelines for use of Router Alert . . . . . . . . . . . . . . 10 80 4.1. Use of Router Alert End-to-End In the Internet (Router 81 Alert in Peer Model) . . . . . . . . . . . . . . . . . . . 10 82 4.2. Use of Router Alert In Controlled Environments . . . . . . 11 83 4.2.1. Use of Router Alert Within an Administrative Domain . 11 84 4.2.2. Use of Router Alert In Overlay Model . . . . . . . . . 13 85 4.3. Router Alert Protection Approaches for Service 86 Providers . . . . . . . . . . . . . . . . . . . . . . . . 16 87 5. Guidelines for Router Alert Implementation . . . . . . . . . . 18 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 90 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 97 1. Terminology 99 For readability, this document uses the following loosely defined 100 terms: 102 o Slow path : Software processing path for packets 104 o Fast path : ASIC/Hardware processing path for packets 106 1.1. Conventions Used in This Document 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in [RFC2119]. 112 2. Introduction 114 [RFC2113] and [RFC2711] respectively define the IPv4 and IPv6 Router 115 Alert Option (RAO). In this document, we collectively refer to those 116 as the IP Router Alert. The IP Router Alert Option is an IP option 117 that alerts transit routers to more closely examine the contents of 118 an IP packet. 120 RSVP ([RFC2205], [RFC3175], [RFC3209]), PGM ([RFC3208]), IGMP 121 ([RFC3376]), MLD ([RFC2710], [RFC3810]), MRD ([RFC4286]) and NSIS 122 General Internet Signalling Transport (GIST) ([I-D.ietf-nsis-ntlp]) 123 are some of the protocols that make use of the IP Router Alert. 125 Section 3 describes the security concerns associated with the use of 126 the Router Alert option. 128 Section 4 provides guidelines for the use of Router Alert. More 129 specifically, Section 4.1 recommends that Router Alert not be used 130 for end to end applications over the Internet, while Section 4.2 131 presents controlled environments where applications/protocols relying 132 on IP Router Alert can be deployed effectively and safely. 133 Section 4.3 provides recommendations on protection approaches to be 134 used by Service Providers in order to protect their network from 135 Router Alert based attacks. 137 Finally, Section 5 provides generic recommendations for router 138 implementation of Router Alert aiming at increasing protection 139 against attacks. 141 The present document discusses considerations and practises based on 142 the current specification of IP Router Alert ([RFC2113], [RFC2711]). 143 Possible future enhancements to the specification of IP Router Alert 144 (in view of reducing the security risks associated with the use of IP 145 Router Alert) are outside the scope of this document. A proposal for 146 such enhancements can be found in 147 [I-D.narayanan-rtg-router-alert-extension]. 149 The IPv6 base specification [RFC2460] defines the hop-by-hop option 150 extension header. The hop-by-hop option header is used to carry 151 optional information that must be examined by every node along a 152 packet's delivery path. The IPv6 Router Alert Option is one 153 particular hop by hop option. Similar security concerns to those 154 discussed in the present document for the IPv6 Router Alert apply 155 more generically to the concept of IPv6 hop-by-hop option extension 156 header. However, addressing the broader concept of IPv6 hop-by-hop 157 option thoroughly would require additional material so as to cover 158 additional considerations associated with it (such as the attacks 159 effectiveness depending on how many options are included and on the 160 range from to which the option-type value belongs, etc.), so this is 161 kept outside the scope of the present document. A detailed 162 discussion about security risks and proposed remedies associated with 163 IPv6 hop-by-hop option can be found in [I-D.krishnan-ipv6-hopbyhop]. 165 The IPv4 base specification [RFC0791] defines a general notion of 166 IPv4 options that can be included in the IPv4 header (without 167 distinguishing between hop-by-hop versus end-to-end option). The 168 IPv4 Router Alert Option is one particular IPv4 option. Similar 169 security concerns to those discussed in the present document for the 170 IPv4 Router Alert apply more generically to the concept of IPv4 171 option. However, addressing the broader concept of IPv4 option 172 thoroughly would require additional material so as to cover 173 additional considerations associated with it (such as lack of option 174 ordering, etc.), so this is kept outside the scope of the present 175 document. 177 3. Security Concerns of Router Alert 179 The IP Router Alert option is defined ([RFC2113], [RFC2711]) as a 180 mechanism that alerts transit routers to more closely examine the 181 contents of an IP packet. [RFC4081] and [RFC2711] mention the 182 security risks associated with the use of the IP Router Alert: 183 flooding a router with bogus (or simply undesired) IP datagrams which 184 contain the IP Router Alert could impact operation of the router in 185 undesirable ways. For example, assuming the router punts the 186 datagrams containing the IP Router Alert option to the slow path, 187 such an attack could consume a significant share of the router's slow 188 path and could also lead to packet drops in the slow path (thus, 189 affecting operation of all other applications and protocols operating 190 in the slow path). 192 Furthermore, [RFC2113] specifies no (and [RFC2711] specifies very 193 limited) mechanism for identifying different users of IP Router 194 Alert. As a result, many fast switching implementations of IP Router 195 Alert punt most/all packets marked with IP Router Alert into the slow 196 path (unless configured to systematically ignore or drop all Router 197 Alert packets). 199 Some IP Router Alert implementations may be able to take into account 200 the IP PID [RFC0791] as a discriminator for the punting decision for 201 different protocols using IP Router Alert. However, this still only 202 allows very coarse triage among various protocols using IP Router 203 Alert for two reasons. First, the IP PID is the same when IP Router 204 Alert is used for different applications of the same protocol (e.g., 205 RSVP vs. RSVP-TE), or when IP Router Alert is used for different 206 contexts of the same application (e.g., different levels of RSVP 207 aggregation [RFC3175]). Thus, it is not possible to achieve the 208 necessary triage in the fast path across IP Router Alert packets from 209 different applications or from different contexts of an application. 210 Secondly, some protocols requiring punting may be carried over a 211 transport protocol (e.g., TCP or UDP) possibly because they require 212 the services of that transport protocol or perhaps because the 213 protocol does not justify allocation of a scarce IP PID value. Thus, 214 considering the PID does not allow triage in the fast path of IP 215 Router Alert packets from different protocols sharing the same 216 transport protocol. Therefore, It is generally not possible to 217 ensure that only the IP Router Alert packets of interest are punted 218 to the slow path while other IP Router Alert packets are efficiently 219 forwarded (i.e., in fast path). 221 Some IP Router Alert implementations may be able to take into account 222 the value field inside the router alert option. However, only one 223 value (zero) was defined in [RFC2113] and no IANA registry for IPv4 224 Router Alert values was available until recently. So this did not 225 allow most IPv4 Router Alert implementation to support useful 226 classification based on the value field in the fast path. Also, 227 while [RFC2113] states that unknown values should be ignored (i.e. 228 The packets should be forwarded as normal IP traffic), it has been 229 reported that some existing implementations simply ignore the value 230 field completely (i.e. Process any packet with an IPv4 Router Alert 231 regardless of its option value). An IANA registry for further 232 allocation of IPv4 Router Alert values has been introduced recently 233 ([RFC5350]) but this would only allow coarse-grain classification, 234 when, and if, supported by implementations. For IPv6, [RFC2711] 235 states that "the value field can be used by an implementation to 236 speed processing of the datagram within the transit router" and 237 defines an IANA registry for these values. But again, this only 238 allows coarse-grain classification. Besides, some existing IPv6 239 Router Alert implementations are reported to depart from that 240 behavior. 242 [RFC2711] mentions that limiting, by rate or some other means, the 243 use of IP Router Alert option is a way of protecting against a 244 potential attack. However, if rate limiting is used as a protection 245 mechanism but if the granularity of the rate limiting is not fine 246 enough to distinguish among IP Router Alert packet of interest from 247 unwanted IP Router Alert packet, a IP Router Alert attack could still 248 severely degrade operation of protocols of interest that depend on 249 the use of IP Router Alert. 251 In a nutshell, the IP router alert option does not provide a 252 convenient universal mechanism to accurately and reliably distinguish 253 between IP Router Alert packets of interest and unwanted IP Router 254 Alert packets. This, in turn, creates a security concern when IP 255 Router Alert option is used, because, short of appropriate router 256 implementation specific mechanisms, the router slow path is at risk 257 of being flooded by unwanted traffic. 259 It can be observed that opening up a hole in the control plane of 260 Service Provider routers is commonly done for other applications such 261 as BGP peering. However, the resulting DOS attack vector is arguably 262 more serious with Router Alert option than with BGP peering for a 263 number of reasons including: 265 o with BGP Peering, the control plane hole is only open on the edge 266 routers and core routers are completely isolated from any direct 267 control plane exchange with entities outside the administrative 268 domain; with BGP, a DOS attack would only affect the edge 269 router(s), while with Router Alert option, the attack could 270 propagate to core routers; 272 o with BGP, the BGP policy control would typically prevent re- 273 injection of undesirable information out of the attacked device, 274 while with Router-Alert option, the non-filtered attacking 275 messages would typically be forwarded downstream. 277 o With BGP, edge routers only exchange control plane information 278 with pre-identified peers and can easily filter out any control 279 plane traffic coming from other peers, while the Router-Alert 280 option can be received in a datagram with any destination address 281 and any destination source. 283 4. Guidelines for use of Router Alert 285 4.1. Use of Router Alert End-to-End In the Internet (Router Alert in 286 Peer Model) 288 Because of the security concerns associated with Router Alert 289 discussed in Section 3, network operators need to actively protect 290 themselves against externally generated IP Router Alert packets. 291 Because there is no convenient universal mechanisms to triage between 292 desired and undesired router alert packets, network operators 293 currently often protect themselves in ways that isolate them from 294 externally generated IP Router Alert packets. This may (ideally) be 295 achieved by tunneling IP Router Alert packets 296 [I-D.dasmith-mpls-ip-options] so that the IP Router Alert option is 297 hidden through that network, or it may be achieved via mechanisms 298 resulting in occasional (e.g., rate limiting) or systematic drop of 299 IP Router Alert packets. 301 Thus, it is RECOMMENDED that applications and protocols not be 302 deployed with a dependency on processing of the Router Alert option 303 (as currently specified) across independent administrative domains in 304 the Internet. Figure 1 illustrates such a hypothetical use of Router 305 Alert end-to-end in the Internet. We refer to such a model of Router 306 Alert option use as a "Peer Model" Router Alert option use, since 307 core routers in different administrative domains would partake in 308 processing of Router Alert option datagrams associated with the same 309 signalling flow. 311 -------- -------- -------- -------- 312 / A \ / B \ / C \ / D \ 313 | (*) | | (*) | | (*) | | (*) | 314 | | |<============>| |<=============>| |<=============>| | | 315 | - | | - | | - | | - | 316 \ / \ / \ / \ / 317 -------- -------- -------- -------- 319 (*) closer examination of Router Alert option datagrams 321 <==> flow of Router Alert option datagrams 323 Figure 1: Use of Router Alert End-to-End in the Open Internet (Router 324 Alert in Peer Model) 326 While this recommendation is framed here specifically in the context 327 of router alert, the fundamental security risk that network operators 328 want to preclude is to allow devices/protocols that are outside of 329 their administrative domain (and therefore not controlled) to tap 330 into the control plane of their core routers. Whether this control 331 plane access is provided through router alert option or would be 332 provided by any other mechanism (e.g. Deep packet inspection) 333 probably results in similar security concerns. In other words, the 334 fundamental security concern is associated with the notion of end to 335 end signaling in a Peer Model across domains in the Internet. As a 336 result, it is expected that network operators would typically not 337 want to have their core routers partake in end-to-end signalling with 338 external uncontrolled devices through the open Internet, and 339 therefore prevent deployment of end to end signalling in a Peer model 340 through their network (regardless of whether that signalling uses 341 Router Alert or not). 343 4.2. Use of Router Alert In Controlled Environments 345 4.2.1. Use of Router Alert Within an Administrative Domain 347 In some controlled environments such as within a given Administrative 348 Domain, the network administrator can determine that IP Router Alert 349 packets will only be received from trusted well-behaved devices or 350 can establish that specific protection mechanisms (e.g., RAO 351 filtering and rate-limiting) against the plausible RAO-based DoS 352 attacks are sufficient. In that case, an application relying on 353 exchange and handling of RAO packets (e.g., RSVP) MAY be safely 354 deployed within the controlled network. A private enterprise network 355 firewalled from the Internet and using RSVP reservations for voice 356 and video flows may be an example of such controlled environment. 357 Such an environment is illustrated in Figure 2. 359 ------------------------- -------- -------- 360 / A \ / B \ / C \ 361 | (*) (*) | -- | | | | 362 | | |<============>| | |--|FW|--| |--------| | 363 | - - | -- | | | | 364 \ / \ / \ / 365 ------------------------- -------- -------- 367 (*) closer examination of Router Alert option datagrams 369 <==> flow of Router Alert option datagrams 371 FW Firewall 373 Figure 2: Use of Router Alert Within an Administrative Domain 375 In some controlled environments, several Administrative Domains have 376 a special relationship whereby they cooperate very tightly and 377 effectively operate as a single trust domain. In that case, one 378 domain is willing to trust another with respect to the traffic 379 injected across the boundary. In other words, a downstream domain is 380 willing to trust that the traffic injected at the boundary has been 381 properly validated/filtered by the upstream domain. Where it has 382 been established that such trust can be applied to router alert 383 option packets, an application relying on exchange and handling of 384 RAO packets (e.g., RSVP) MAY be safely deployed within such a 385 controlled environment. The entity within a company responsible for 386 operating multimedia endpoints and the entity within the same company 387 responsible for operating the network may be an example of such 388 controlled environment. For example, they may collaborate so that 389 RSVP reservations can be used for video flows from endpoints to 390 endpoints through the network. 392 In some environments, the network administrator can reliably ensure 393 that router alert packets from any untrusted device (e.g., from 394 external routers) are prevented from entering a trusted area (e.g., 395 the internal routers). For example, this may be achieved by ensuring 396 that routers straddling the trust boundary (e.g., edge routers) 397 always encapsulate those packets (without setting IP Router Alert -or 398 equivalent- in the encapsulating header) through the trusted area (as 399 discussed in [I-D.dasmith-mpls-ip-options]). In such environments, 400 the risks of DOS attacks through the IP Router Alert vector is 401 removed in the trusted area (or greatly reduced) even if IP Router 402 Alert is used inside the trusted area (say for RSVP-TE). Thus an 403 application relying on IP Router Alert MAY be safely deployed within 404 the trusted area. A Service Provider running RSVP-TE within his 405 network may be an example of such protected environment. Such an 406 environment is illustrated in Figure 3. 408 -------- -------------------------- -------- 409 / A \ / B \ / C \ 410 | | | (*) (*) | | | 411 | |-------TT | |<=============>| | TT------- | | 412 | | | - - | | | 413 \ / \ / \ / 414 -------- -------------------------- -------- 416 (*) closer examination of Router Alert option datagrams 418 <==> flow of Router Alert option datagrams 420 TT Tunneling of Router Alert option datagrams 422 Figure 3: Use of Router Alert Within an Administrative Domain 424 4.2.2. Use of Router Alert In Overlay Model 426 In some controlled environment: 428 o the sites of a network A are interconnected through a service 429 provider network B 431 o the service provider network B protects itself from IP Router 432 Alert messages without dropping those when they transit over the 433 transit network (for example using mechanisms discussed in 434 [I-D.dasmith-mpls-ip-options]) 436 In such controlled environment, an application relying on exchange 437 and handling of RAO packets (e.g., RSVP) in the network A sites (but 438 not inside network B) MAY be safely deployed. We refer to such a 439 deployment as a use of Router Alert in a Water-Tight Overlay. 440 "Overlay" because Router Alert option datagrams are used in network A 441 on top of, and completely transparently to, network B. "Water-Tight" 442 because router alert option datagrams from A cannot leak inside 443 network B. A private enterprise intranet, whose sites are 444 interconnected through a Service Prover network, and using RSVP to 445 perform reservations within the enterprise sites for voice and video 446 flows may be an example of such controlled environment. Such an 447 environment is illustrated in Figure 4. 449 -------- -------- 450 / A \ / A \ 451 | (*) | | (*) | 452 | | |<=================================>| | | | 453 | - | | - | 454 \ / \ / 455 -------- -------- 456 \ / 457 \ ------------------------- / 458 \ / B \ / 459 \| |/ 460 TT TT 461 | | 462 \ / 463 ------------------------- 465 (*) closer examination of Router Alert option datagrams 467 <==> flow of Router Alert option datagrams 469 TT Tunneling of Router Alert option datagrams 471 Figure 4: Use of Router Alert In Water-tight Overlay 473 In the controlled environment described above, an application relying 474 on exchange and handling of RAO packets (e.g. RSVP-TE) in the 475 service provider network B (but not in network A) MAY also be safely 476 deployed simultaneously. Such an environment with independent, 477 isolated, deployment of router alert in overlay at two levels is 478 illustrated in Figure 5. 480 -------- -------- 481 / A \ / A \ 482 | (*) | | (*) | 483 | | |<=================================>| | | | 484 | - | | - | 485 \ / \ / 486 -------- -------- 487 \ / 488 \ ------------------------- / 489 \ / B \ / 490 \| (*) (*) |/ 491 TT | |<============>| | TT 492 | - - | 493 \ / 494 ------------------------- 496 (*) closer examination of Router Alert option datagrams 498 <==> flow of Router Alert option datagrams 500 TT Tunneling of Router Alert option datagrams 502 Figure 5: Use of Router Alert In Water-tight Overlay at Two Levels 504 In some controlled environment: 506 o the sites of a network A are interconnected through a service 507 provider network B 509 o the service provider B processes router alert packets on the edge 510 routers and protect these edge routers against RAO based attacks 511 using mechanisms such as (possibly per port) RAO rate limiting and 512 filtering 514 o the service provider network B protects its core routers from 515 Router Alert messages without dropping those when they transit 516 over the transit network (for example using mechanisms discussed 517 in [I-D.dasmith-mpls-ip-options]) 519 In such controlled environment, an application relying on exchange 520 and handling of RAO packets (e.g., RSVP) in the network A sites and 521 in network B Edges (but not in the core of network B) MAY be safely 522 deployed. We refer to such a deployment as a use of Router Alert in 523 a Leak-Controlled Overlay. "Overlay" because Router Alert option 524 datagrams are used in network A on top of, and completely 525 transparently to, network B core. "Leak-Controlled" because router 526 alert option datagrams from A leak inside network B's B edges but not 527 inside network B's core. A private enterprise intranet, whose sites 528 are interconnected through a Service Prover network, using RSVP for 529 voice and video within network A sites as well as on Network B's edge 530 to extend the reservation onto the attachment links between A and B 531 (as specified in [I-D.ietf-tsvwg-rsvp-l3vpn]) may be an example of 532 such controlled environment. Such an environment is illustrated in 533 Figure 4. 535 -------- -------- 536 / A \ / A \ 537 | | | | 538 | | ------------------------ | | 539 | (*) | /(*) (*) \ | (*) | 540 | | |<======>| |<============>| |<=====>| | | | 541 | - | | - - | | - | 542 \ / | \ - - / | \ / 543 -------- | TT-| | | |-TT | -------- 544 | - - | 545 \ / 546 ------------------------ 548 (*) closer examination of Router Alert option datagrams 550 <==> flow of Router Alert option datagrams 552 TT Tunneling of Router Alert option datagrams 554 Figure 6: Use of Router Alert In Leak-Controlled Overlay 556 4.3. Router Alert Protection Approaches for Service Providers 558 Section 3 discusses the security risks associated with the use of the 559 IP Router Alert and how it opens up a DOS vector in the router 560 control plane. Thus, it is RECOMMENDED that a Service Provider 561 implements strong protection of his network against attacks based on 562 IP Router Alert. 564 As discussed in Section 4.2.2 some applications can benefit from the 565 use of IP Router Alert packets in an Overlay model (i.e. Where 566 Router Alert packets are exchanged transparently on top of a Service 567 Provider). Thus, it is RECOMMENDED that a Service Provider protects 568 his network from attacks based on IP Router Alert using mechanisms 569 that avoid (or at least minimize) dropping of end to end IP Router 570 Alert packets (other than those involved in an attack). 572 For example, if the Service Provider does not run any protocol 573 depending on IP Router Alert within his network, he may elect to 574 simply turn-off punting/processing of IP Router Alert packet on his 575 routers; this will ensure that end-to-end IP Router Alert packet 576 transit transparently and safely through his network. 578 As another example, using protection mechanisms such selective 579 filtering and rate-limiting (that Section 5 suggests be supported by 580 IP Router Alert implementations) a Service Provider can protect the 581 operation of a protocol depending on IP Router Alert within his 582 network (e.g., RSVP-TE) while at the same time transporting IP Router 583 Alert packets carrying another protocol that may be used end to end. 584 Note that the Service Provider might additionally use protocol 585 specific mechanisms that reduce the dependency on Router Alert for 586 operation of this protocol inside the Service Provider environment; 587 use of RSVP refresh reduction mechanisms ([RFC2961]) would be an 588 example of such mechanisms in the case where the Service Provider is 589 running RSVP-TE within his network since this allows refresh of 590 existing Path and Resv states without use of the IP Router Alert 591 option. 593 As yet another example, using mechanisms such as those discussed in 594 [I-D.dasmith-mpls-ip-options] a Service Provider can safely protect 595 the operation of a protocol depending on IP Router Alert within his 596 network (e.g., RSVP-TE) while at the same time safely transporting IP 597 Router Alert packets carrying another protocol that may be used end 598 to end (e.g., IPv4/IPv6 RSVP). 600 As a last resort, if the SP does not have any means to safely 601 transport end to end IP Router Alert option packets over his network, 602 the SP MAY drop those packets. It must be noted that this has the 603 undesirable consequence of preventing the use of the Router Alert 604 option in the Overlay Model on top of this network, and therefore 605 prevents users of that network from deploying a number of valid 606 applications/protocols in their environment. 608 5. Guidelines for Router Alert Implementation 610 It is RECOMMENDED that router implementations of IP Router Alert 611 option include protection mechanisms against Router Alert based DOS 612 attacks appropriate for their targeted deployment environments. For 613 example, this can include ability on an edge router to "tunnel" IP 614 Router Alert option of received packets when forwarding those over 615 the core as discussed in [I-D.dasmith-mpls-ip-options]. As another 616 example, although not always available from current implementations, 617 new implementations may include protection mechanisms such as 618 selective (possibly dynamic) filtering and rate-limiting of IP Router 619 Alert option packets. 621 If an IP packet contains the IP Router Alert option, but the payload 622 protocol is not explicitly identified as a Payload of interest by the 623 router examining the packet, the behavior is not explicitly defined 624 by [RFC2113]. However, the behavior is implied and, for example, the 625 definition of RSVP in [RFC2205] assumes that the packet will be 626 forwarded using normal forwarding based on the destination IP 627 address. Thus, a router implementation SHOULD forward within the 628 "fast path" (subject to all normal policies and forwarding rules) a 629 packet carrying the IP Router Alert option containing a payload that 630 is not a payload of interest to that router. The "not passing" 631 behavior protects the router from DOS attacks using IP Router Alert 632 packets of a protocol unknown to the router. The "forwarding" 633 behavior contributes to transparent end to end transport of IP Router 634 Alert packets (e.g., to facilitate their use by end to end 635 application). 637 6. Security Considerations 639 This document discusses security risks associated with current usage 640 of the IP Router Alert Option and associated practices. 642 7. IANA Considerations 644 None. 646 8. Contributors 648 The contributors to this document (in addition to the editors) are: 650 o Reshad Rahman: 652 * Cisco Systems 654 * rrahman@cisco.com 656 o David Ward: 658 * Juniper Networks 660 * dward@juniper.net 662 o Ashok Narayanan: 664 * Cisco Systems 666 * ashokn@cisco.com 668 o Adrian Farrell: 670 * OldDog Consulting 672 * adrian@olddog.co.uk 674 o Tony Li: 676 * tony.li@tony.li 678 9. Acknowledgments 680 We would like to thank Dave Oran, Magnus Westerlund, John Scudder, 681 Ron Bonica, Ross Callon, Alfred Hines and Carlos Pignataro for their 682 comments. This document also benefited from discussions with Jukka 683 Manner and Suresh Krishnan. The discussion about use of the value 684 field in the IPv4 Router Alert borrowed from a similar discussion in 685 [I-D.ietf-nsis-ntlp]. 687 10. References 689 10.1. Normative References 691 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 692 September 1981. 694 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 695 February 1997. 697 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 698 (IPv6) Specification", RFC 2460, December 1998. 700 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 701 RFC 2711, October 1999. 703 10.2. Informative References 705 [I-D.dasmith-mpls-ip-options] 706 Jaeger, W., Mullooly, J., Scholl, T., and D. Smith, 707 "Requirements for Label Edge Router Forwarding of IPv4 708 Option Packets", draft-dasmith-mpls-ip-options-01 (work in 709 progress), October 2008. 711 [I-D.ietf-nsis-ntlp] 712 Schulzrinne, H. and M. Stiemerling, "GIST: General 713 Internet Signalling Transport", draft-ietf-nsis-ntlp-20 714 (work in progress), June 2009. 716 [I-D.ietf-tsvwg-rsvp-l3vpn] 717 Davie, B., Faucheur, F., and A. Narayanan, "Support for 718 RSVP in Layer 3 VPNs", draft-ietf-tsvwg-rsvp-l3vpn-05 719 (work in progress), November 2009. 721 [I-D.krishnan-ipv6-hopbyhop] 722 Krishnan, S., "The case against Hop-by-Hop options", 723 draft-krishnan-ipv6-hopbyhop-03 (work in progress), 724 July 2009. 726 [I-D.narayanan-rtg-router-alert-extension] 727 Narayanan, A., Faucheur, F., Ward, D., and R. Rahman, "IP 728 Router Alert Option Extension", 729 draft-narayanan-rtg-router-alert-extension-00 (work in 730 progress), March 2009. 732 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 733 Requirement Levels", BCP 14, RFC 2119, March 1997. 735 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 736 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 737 Functional Specification", RFC 2205, September 1997. 739 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 740 Listener Discovery (MLD) for IPv6", RFC 2710, 741 October 1999. 743 [RFC2961] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., 744 and S. Molendini, "RSVP Refresh Overhead Reduction 745 Extensions", RFC 2961, April 2001. 747 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 748 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 749 RFC 3175, September 2001. 751 [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., 752 Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, 753 L., Tweedly, A., Bhaskar, N., Edmonstone, R., 754 Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport 755 Protocol Specification", RFC 3208, December 2001. 757 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 758 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 759 Tunnels", RFC 3209, December 2001. 761 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 762 Thyagarajan, "Internet Group Management Protocol, Version 763 3", RFC 3376, October 2002. 765 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 766 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 768 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 769 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 771 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 772 RFC 4286, December 2005. 774 [RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the 775 IPv4 and IPv6 Router Alert Options", RFC 5350, 776 September 2008. 778 Author's Address 780 Francois Le Faucheur (editor) 781 Cisco Systems 782 Greenside, 400 Avenue de Roumanille 783 Sophia Antipolis 06410 784 France 786 Phone: +33 4 97 23 26 19 787 Email: flefauch@cisco.com