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