idnits 2.17.1 draft-narayanan-rtg-router-alert-extension-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 3, 2009) is 5526 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC0791' is defined on line 330, but no explicit reference was found in the text == Unused Reference: 'I-D.dasmith-mpls-ip-options' is defined on line 341, but no explicit reference was found in the text == Unused Reference: 'RFC4782' is defined on line 393, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-rahman-rtg-router-alert-considerations-00 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Narayanan 3 Internet-Draft F. Le Faucheur 4 Intended status: Standards Track D. Ward 5 Expires: September 4, 2009 R. Rahman 6 Cisco 7 March 3, 2009 9 IP Router Alert Option Extension 10 draft-narayanan-rtg-router-alert-extension-00 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 4, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 The IP Router Alert Option is an IP option that alerts transit 49 routers to more closely examine the contents of an IP packet. RSVP, 50 PGM and IGMP are some of the protocols which make use of the IP 51 Router Alert option. The current specification for the IP Router 52 Alert Option does not define mechanisms to facilitate discriminating 53 across different users of Router Alert. As a result, networks using 54 router Alert may have more secuity exposure than necessary and/or may 55 unnecessarily block some transit Router Alert packets. This document 56 describes new rules for the IP Router-Alert Option that aid routers 57 to process these packets more selectively. 59 Table of Contents 61 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. IP Router Alert Option Enhancement . . . . . . . . . . . . . . 6 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 73 1. Terminology 75 For readability, this document uses the following loosely defined 76 terms: 78 o Slow path : Software processing path for packets 80 o Fast path : ASIC/Hardware processing path for packets 82 1.1. Conventions Used in This Document 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 2. Introduction 90 [RFC2113] and [RFC2711] respectively define the IPv4 and IPv6 Router 91 Alert Option. In this document, we collectively refer to those as 92 the IP Router Alert. RSVP ([RFC2205], [RFC3209]), PGM ([RFC3208]) 93 and IGMP ([RFC3376]) are but some of the protocols which make use of 94 the IP Router Alert. Those protocols are used to support critical 95 elements of the Internet infrastructure (e.g. RSVP-TE for traffic 96 engineering within a service provider network) and as such they need 97 to be protected. 99 IP datagrams carrying the IP Router Alert are usually examined in a 100 router's "slow path" and an excess of such datagrams can cause 101 performance degradation or packet drops in a router's "slow path". 102 (Note that a router's "slow path" can potentially also be attacked 103 with IP packets destined to one of the router's local IP addresses 104 and requires corresponding security protection.) 106 [RFC4081] and [RFC2711] mention the security risks associated with 107 the use of the IP Router Alert: flooding a router with bogus IP 108 datagrams which contain the IP Router Alert would cause a performance 109 degradation of the router's "slow path" and can also lead to packet 110 drops in the "slow path". 112 [RFC2113] specifies no mechanism for identifying different users of 113 IP Router Alert. As a result, many fast switching implementations of 114 IP Router Alert punt most/all packets marked with IP Router Alert 115 into the slow path. To protect against overloading routers which 116 receive a large number of IP Router Alert packets that they do not 117 need to process, many router implementations limit the rate of 118 packets punted into the slow path, but once again the lack of 119 discrimination of different protocols may hamper the smooth 120 functioning of protocols that depend on IP Router Alert. Further, 121 some network operators actively protect routers from IP Router Alert 122 packets by discarding these packets at the edge, which is undesirable 123 for end-to-end operation of protocols carrying this option. Details 124 on these issues and some recommendations on best practices are 125 described in [I-D.rahman-rtg-router-alert-considerations]. The 126 specification of an efficient, general-purpose, protocol-independent 127 mechanism for discriminating between different applications would aid 128 router implementations to more efficiently select the protocol 129 messages they need to punt and locally process, while ignoring and 130 forwarding in the fast path the messages that they do not need to 131 see. 133 This document enhances the current specification of Router Alert to 134 ensure that risks associated with unintentional interception of 135 packets that are not of real interest to a given router are minimized 136 (if not eliminated) by facilitating identification in the fast path 137 of the subset of packets with router alert that are of interest to 138 the router. A key aspect of the proposal is to facilitate finer 139 grain identification of router alert packets of interest versus 140 unwanted router alert packets while only requiring inspection of the 141 router alert header. In particular: 143 o the enhancement allows the router to identify the application of 144 packets marked with IP Router-Alert by simply examining the IP 145 header, independent of any application packet format. 147 o the enhancement allows router alert packets from different 148 application protocols to be easily distinguished even if they 149 share the same transport protocol (i.e. the have the same IP PID). 151 o the enhancement allows router alert packets for the same 152 application protocol but associated with different contexts (e.g. 153 end to end RSVP vs internal RSVP-TE) to be easily distinguished. 155 Note that this mechanism does not prevent attacks of the form of 156 bogus protocol messages which may be of interest to the router. More 157 details on this are presented in Section 4. 159 3. IP Router Alert Option Enhancement 161 We propose an extension to the specification and processing behaviour 162 of the IP RAO header. [RFC2113] specifies a 2-octet value in the IP 163 RAO option field. [RFC5350] specifies creation of an IANA registry 164 for managing this 2-octet value, and proposes IPv4 RAO usage as 165 follows: 167 +-------------+--------------------------------------+-----------+ 168 | Value | Description | Reference | 169 +-------------+--------------------------------------+-----------+ 170 | 0 | Router Shall Examine Packet | RFC2113 | 171 | | | | 172 | 1-32 | Aggregated Reservation Nesting Level | RFC3175 | 173 | | | | 174 | 33-65502 | Available for assignment by the IANA | RFC5350 | 175 | | | | 176 | 65503-65534 | Available for experimental use | RFC5350 | 177 | | | | 178 | 65535 | Reserved | RFC5350 | 179 +-------------+--------------------------------------+-----------+ 181 An IANA-maintained IPv6 RAO registry is specified in [RFC2711] and 182 clarified in [RFC5350]. The current IPv6 RAO usage is: 184 +----------+--------------------------------------+-----------+ 185 | Value | Description | Reference | 186 +----------+--------------------------------------+-----------+ 187 | 0 | Multicast Listener Discovery | RFC2711 | 188 | | | | 189 | 1 | RSVP | RFC2711 | 190 | | | | 191 | 2 | Active Networks | RFC2711 | 192 | | | | 193 | 3 | Reserved | RFC5350 | 194 | | | | 195 | 4-35 | RSVP Aggregation | RFC3175 | 196 | | | | 197 | 36-65535 | Available for assignment by the IANA | RFC2711 | 198 +----------+--------------------------------------+-----------+ 200 We propose to extend the definition of IP Router-Alert Option values. 201 The 2-octet Option Value field will now be used to identify the 202 protocol and context from an IP RAO perspective. For IANA assignment 203 purposes, this value will be split into two fields as follows: 205 +----------------------------+---------------------------+ 206 | service selector (10 bits) | context selector (6 bits) | 207 +----------------------------+---------------------------+ 209 The service selector will be assigned to different applications by 210 IANA and the context selector will be specific to the application 211 protocol. Service selector 0 is reserved for backward compatibility 212 and service selector 1023 is reserved for experimental use. 213 Depending on requirements, a single protocol or application may be 214 assigned multiple service selectors. All currently assigned option 215 values of IPv4 and IPv6 RAO have service selector 0. The 216 experimental use range is extended to be 65472-65534. 218 All new protocols using IP RAO MUST request allocations of new 219 service and context selector values, and MUST follow this format for 220 the Option Value in the IP header. Additionally, new service and 221 context selector values will be allocated for legacy protocols using 222 IP RAO. Existing implementations of these legacy protocols SHOULD be 223 updated to use the new selector values. The use of new option values 224 for legacy protocols SHOULD be configurable by the user, and SHOULD 225 be on by default. However, extensions to legacy protocols that 226 require new option values MUST follow the new option format. For the 227 purposes of this requirement, "legacy protocols" are defined as those 228 already standardized in the IETF as using IP Router-Alert - 229 specifically: 231 o RSVP - IPv4: 0-32, IPv6: 1, 4-35 ([RFC2205],[RFC3175]) 233 o RSVP/TE - IPv4: 0, IPv6: 1 ([RFC3209]) 235 o IGMPv2 - IPv4: 0 ([RFC2236]) 237 o IGMPv3 - IPv4: 0 ([RFC3376]) 239 o MLDv1 - IPv6: 0 ([RFC2710]) 241 o MLDv2 - IPv6: 0 ([RFC3810]) 243 o Multicast Router Discovery - IPv4: 0, IPv6: unspecified 244 ([RFC4286]) 246 o PGM - IPv4: 0 ([RFC3208]) 248 o Active Network - IPv6: 2 (cited in [RFC2711]) 250 Correspondingly, "new protocols" are those for which the use of IP 251 Router-Alert has not yet been standardized. 253 For service selector 1-1022, the value of the service and context 254 selector fields MUST be assigned in a manner such that the content of 255 the IP RAO option is sufficient to determine whether a packet is of 256 interest to a node, with a reasonable level of granularity. For 257 example, having the [RFC3175] aggregate reservation nesting level in 258 the context selector allows P routers to quickly separate out RSVP 259 messages for aggregate vs. end-to-end flows. Or, a separate context 260 (or service) selector for RSVP-IPv4 vs. RSVP-TE sessions allows nodes 261 to efficiently ignore one session type while processing another. 262 Also, service and context selectors SHOULD be assigned the same for 263 IPv4 and IPv6 versions of the same application. 265 Fast path switching implementations SHOULD first look at the service 266 selector and context selector fields to determine whether they wish 267 to select a packet with IP RAO for local processing. A table of in- 268 use service and context selector values can be looked up during 269 packet switching to determine whether the packet is to be locally 270 processed. Thus, for packets marked with service selectors 1-1022, 271 the value of the IP RAO value field is sufficient to rapidly 272 determine whether the packet may be forwarded unmodified or whether 273 it should be examined further for local processing. If the protocol/ 274 context selector of the packet does not match those that are of 275 interest to currently running protocols, the router SHOULD forward 276 these packets unmodified in the fast path. By extension, if no 277 applications that use IP Router-Alert are currently running on the 278 router, the router SHOULD forward all packets with IP Router-Alert 279 Option in the fast path, unmodified. 281 The service selector 0 is reserved for backwards compatibility. For 282 packets marked with service selector 0, the packet MUST be examined 283 further to determine whether it is of local interest, in compliance 284 with current protocol requirements. The context selector may be 285 ignored for these packets. 287 All the practices described in 288 [I-D.rahman-rtg-router-alert-considerations] regarding protecting 289 router control plane resources from attacks based on IP RAO, and 290 protecting different protocols using IP RAO from each other, continue 291 to apply in this context. 293 4. Security Considerations 295 This document describes an efficient mechanism for router 296 implementations to identify packets marked with the IP Router-Alert 297 Option but which are not of interest to this router, and forward them 298 unprocessed. 300 It is important to note that the use of this extension does not 301 change in any way the security properties of the IP Router-Alert 302 Option. Specifically, no claim is made of enhancing the security of 303 IP Router-Alert Option usage. An attacker can always consume excess 304 resources on a router's control plane and/or slow path by sending it 305 bogus packets with IP RAO protocol/context selector values that are 306 of interest to the router. However, the network operator now has the 307 option to selectively suppress incoming IP RAO packets at the edge 308 for protocols they are using in their network, while still permitting 309 other applications with IP RAO to transit efficiently across their 310 network. For example, a network operator could choose to suppress 311 incoming IP RAO packets at the edge corresponding to RSVP/TE if they 312 are using RSVP/TE in their network, but still transit end-to-end IPv4 313 RSVP sessions efficiently. 315 5. IANA Considerations 317 This document requires an extension to the IP RAO IANA registry 318 established in [RFC5350]. IP Router-Alert Option values will be 319 assigned as described in Section 3. 321 6. Acknowledgments 323 We would like to thank Dave Oran, Magnus Westerlund, John Scudder, 324 Ron Bonica, Ross Callon, and Alfred Hines for their comments. 326 7. References 328 7.1. Normative References 330 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 331 September 1981. 333 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 334 February 1997. 336 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 337 RFC 2711, October 1999. 339 7.2. Informative References 341 [I-D.dasmith-mpls-ip-options] 342 Jaeger, W., Mullooly, J., Scholl, T., and D. Smith, 343 "Requirements for Label Edge Router Forwarding of IPv4 344 Option Packets", draft-dasmith-mpls-ip-options-01 (work in 345 progress), October 2008. 347 [I-D.rahman-rtg-router-alert-considerations] 348 Rahman, R., "IP Router Alert Considerations and Usage", 349 draft-rahman-rtg-router-alert-considerations-00 (work in 350 progress), November 2008. 352 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 353 Requirement Levels", BCP 14, RFC 2119, March 1997. 355 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 356 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 357 Functional Specification", RFC 2205, September 1997. 359 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 360 2", RFC 2236, November 1997. 362 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 363 Listener Discovery (MLD) for IPv6", RFC 2710, 364 October 1999. 366 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 367 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 368 RFC 3175, September 2001. 370 [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., 371 Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, 372 L., Tweedly, A., Bhaskar, N., Edmonstone, R., 373 Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport 374 Protocol Specification", RFC 3208, December 2001. 376 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 377 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 378 Tunnels", RFC 3209, December 2001. 380 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 381 Thyagarajan, "Internet Group Management Protocol, Version 382 3", RFC 3376, October 2002. 384 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 385 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 387 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 388 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 390 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 391 RFC 4286, December 2005. 393 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 394 Start for TCP and IP", RFC 4782, January 2007. 396 [RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the 397 IPv4 and IPv6 Router Alert Options", RFC 5350, 398 September 2008. 400 Authors' Addresses 402 Ashok Narayanan 403 Cisco Systems 404 1414 Mass Ave 405 Boxborough, MA 01719 406 USA 408 Email: ashokn@cisco.com 410 Francois Le Faucheur 411 Cisco Systems 412 Greenside, 400 Avenue de Roumanille 413 Sophia Antipolis, 06410 414 France 416 Email: flefauch@cisco.com 418 David Ward 419 Cisco Systems 421 Email: dward@cisco.com 423 Reshad Rahman 424 Cisco Systems 425 2000 Innovation Dr. 426 Kanata, Ontario K2K 3E8 427 Canada 429 Email: rrahman@cisco.com