idnits 2.17.1 draft-rahman-rtg-router-alert-considerations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 586. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 593. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 599. 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 Copyright Line does not match the current year -- The document date (November 14, 2008) is 5635 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Rahman, Ed. 3 Internet-Draft Cisco 4 Intended status: BCP November 14, 2008 5 Expires: May 18, 2009 7 IP Router Alert Considerations and Usage 8 draft-rahman-rtg-router-alert-considerations-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of 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 May 18, 2009. 35 Abstract 37 The IP Router Alert Option is an IP option that alerts transit 38 routers to more closely examine the contents of an IP packet. RSVP, 39 PGM and IGMP are some of the protocols which make use of the IP 40 Router Alert option. This document discusses security aspects and 41 common practices around the use of router alert and discusses 42 consequences on the use of router alert by existing or new 43 applications. Common practices in router alert implementation 44 facilitating router protection are also discussed. Finally a 45 possible enhancement to the current specification of Router Alert is 46 presented for feedback. 48 Table of Contents 50 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.1. Conventions Used in This Document . . . . . . . . . . . . 5 53 3. Guidelines for use of Router Alert . . . . . . . . . . . . . . 6 54 3.1. Reliance on Router Alert by Applications . . . . . . . . . 6 55 3.2. When Consenting Adults Exchange IP Router Alert Packets . 6 56 4. Example Protection Mechanisms in a Router Alert 57 Implementation . . . . . . . . . . . . . . . . . . . . . . . . 9 58 4.1. Handling Packets Carrying the Router Alert Option . . . . 9 59 4.2. Applying Rate Limiting . . . . . . . . . . . . . . . . . . 9 60 4.3. Router Alert in Congested Systems . . . . . . . . . . . . 10 61 4.4. Handling Unknown Payload Protocols . . . . . . . . . . . . 10 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 64 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13 65 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 66 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 67 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 68 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 69 Appendix A. A New Filtering Mechanism to Select IP RAO 70 Packets of Interest . . . . . . . . . . . . . . . . . 17 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 72 Intellectual Property and Copyright Statements . . . . . . . . . . 21 74 1. Terminology 76 For readability, this document uses the following loosely defined 77 terms: 79 o Slow path : Software processing path for packets 81 o Fast path : ASIC/Hardware processing path for packets 83 2. Introduction 85 [RFC2113] and [RFC2711] respectively define the IPv4 and IPv6 Router 86 Alert Option. In this document, we collectively refer to those as 87 the IP Router Alert option. RSVP ([RFC2205], [RFC3209]), PGM 88 ([RFC3208]) and IGMP ([RFC3376]) are some of the protocols which make 89 use of the IP Router Alert option. Those protocols are used to 90 support critical elements of the Internet infrastructure (e.g. 91 RSVP-TE for traffic engineering within a service provider network) 92 and as such they need to be protected. 94 IP datagrams carrying the IP Router Alert option are usually examined 95 in a router's "slow path" and an excess of such datagrams can cause 96 performance degradation or packet drops in a router's "slow path". 97 (Note that a router's "slow path" can also be attacked with IP 98 packets destined to one of the router's local IP addresses.) 100 [RFC4081] and [RFC2711] mention the security risks associated with 101 the use of the IP Router Alert option: flooding a router with bogus 102 IP datagrams which contain the IP Router Alert option would cause a 103 performance degradation of the router's "slow path" and can also lead 104 to packet drops in the "slow path". 106 [RFC2711] mentions that limiting, by rate or some other means, the 107 use of Router Alert option is a way of protecting against a potential 108 attack. However, if rate limiting is used as a protection mechanism 109 but if the granularity of the rate limiting is not fine enough to 110 distinguish among router alert packet of interest from unwanted 111 router alert packet, a router alert attack could still severely 112 degrade operation of protocols of interest that depend on the use of 113 IP Router Alert. Section 4 discusses examples of protection 114 mechanisms that may be available from a router implementation of the 115 IP router alert. 117 In some environments where it was not possible to accurately and 118 reliably distinguish between router alert packet of interest and 119 unwanted router alert packets, operators have resorted to actively 120 protecting themselves against externally generated router alert 121 packets in ways that result in end to end router alert packets being 122 (occasionally or systematically) dropped and/or ignored on a segment. 123 The consequences of such practises on the use of router alert by 124 existing or new applications are discussed in Section 3 of the 125 present document. This section also discusses environments where IP 126 router alert can be used effectively. 128 This document also discusses in Appendix A a possible enhancements to 129 the current specification of Router Alert to ensure that risks 130 associated with unintentional interception of packets that are not of 131 real interest to a given router are minimized (if not eliminated) by 132 facilitating identification in the fast path of the subset of packets 133 with router alert that are of interest to the router. The objective 134 of this appendix is to solicit feedback on the question of whether an 135 enhancement to the current router alert specification is justified, 136 and if yes, how to enhance it. 138 2.1. Conventions Used in This Document 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 3. Guidelines for use of Router Alert 146 3.1. Reliance on Router Alert by Applications 148 As mentioned earlier, some networks actively protect themselves 149 against externally generated router alert packets. This may be by 150 tunneling router alert packets [I-D.dasmith-mpls-ip-options] so that 151 the router alert option is hidden through that network or it may be 152 via mechanisms resulting in occasional (e.g. rate limiting) or 153 systematic drop of router alert packets. 155 Also, application protocols are usually carried within IP by a 156 transport protocol such as UDP, TCP, or SCTP. In these cases, the 157 application protocol is not visible in the IP header and could not be 158 determined without further "deep packet" inspection. In the event of 159 the Router Alert option being used for an application protocol 160 carried in a transport protocol, the intercepted IP packet would be 161 delivered to the transport protocol for processing in accordance with 162 [RFC2113]. However, the behavior of the transport protocol in these 163 circumstances is not defined, and may cause rejection of the packet 164 for various reasons. 166 As a consequence, in the general case of open networks, applications 167 can not safely rely on router alert packets being visible to all 168 nodes on the path today, and importantly can not even rely on router 169 alert packets being transported end to end. 171 [RFC2113] implies that the router may examine other fields of a 172 received packet that contains the IP Router Alert option to decide 173 whether that packet needs further processing, but no further advice 174 is given. Examination of other fields of the received IP packet that 175 carries the Router Alert to help determine what to do with the packet 176 would result in implementation-specific behavior that is 177 unpredictable to the sender of the packet. Therefore applications 178 cannot depend on router alert interception involving inspection of 179 fields in the packet outside the IP header. 181 Thus, creating an application or end-to-end protocol that uses the IP 182 Router Alert is currently considered harmful and is strongly 183 discouraged. A different mechanism should be used to decrease the 184 risk of impacting existing protocols that use the IP Router Alert 185 option. 187 3.2. When Consenting Adults Exchange IP Router Alert Packets 189 In some controlled environments, the network administrator can 190 determine that IP router alert packets will only be received from 191 trusted well-behaved devices or can establish that the protection 192 mechanisms discussed in the present document against the plausible 193 RAO- based DoS attacks (e.g. RAO filtering and rate-limiting) are 194 sufficient. In that case, an application relying on exchange and 195 handling of RAO packets (e.g. RSVP) may be safely deployed within 196 the controlled network. In other words, a network that feels 197 appropriately protected against the risks associated with his 198 environment, may decide to freely and openly partake in router alert 199 message exchange with consenting entities. A private enterprise 200 network firewalled from the Internet may be an example of such 201 controlled environment. 203 In some environments, the network administrator can reliably ensure 204 that IP router alert packets from any untrusted device (e.g. from 205 external routers) are prevented from entering a trusted area (e.g. 206 the internal routers). For example, this may be achieved by ensuring 207 that routers straddling the trust boundary (e.g. edge routers) always 208 encapsulate those packets (without Router Alert) through the trusted 209 area (as discussed in [I-D.dasmith-mpls-ip-options]). In such 210 environments, the risks of DOS attacks through the IP router alert 211 vector is removed in the trusted area (or greatly reduced) even if IP 212 router alert is used inside the trusted area (say for RSVP). Thus an 213 application relying on Router Alert may be safely deployed within the 214 trusted area. In other words, the network protects itself from the 215 risks of partaking in IP Router-Alert exchange with strangers but 216 feels free to exchange router alert messages among trusted parties. 217 A Service Provider running RSVP-TE in his network may be an example 218 of such protected environment. 220 When a controlled environment requires RAO packet exchange across his 221 routers for some application (e.g. RSVP) and transits via a Service 222 Provider network (that is not part of the controlled environment), 223 the administrator of the controlled environment needs to ensure with 224 the Service Provider that the router alert messages will not be 225 dropped when transiting the Service Provider network. In other 226 words, the network ought to ensure that another network that needs to 227 be involved in exchange of router alert packet is consenting. 229 Since some existing applications would benefit from end-to-end 230 transport of router alert packets, it is desirable that a Service 231 Provider protects his network from attacks based on router alert 232 using mechanisms that minimize dropping of end to end router alert 233 packets. For example, using protection mechanisms such as those 234 described in Section 4 a Service Provider can safely protect 235 operation of a protocol depending on router alert within his network 236 (e.g. RSVP-TE) while at the same time safely transporting router 237 alert packets carrying another protocol that may be used end to end. 238 As another example, using mechanisms such as those discussed in 239 [I-D.dasmith-mpls-ip-options] a Service Provider can safely protect 240 operation of a protocol depending on router alert within his network 241 (e.g. RSVP-TE) while at the same time safely transporting router 242 alert packets carrying another protocol that may be used end to end 243 (e.g. RSVP IPv4/6). 245 Where the Service Provider cannot transport end to end router alert 246 packets over his network (i.e. they choose to drop them), it is 247 desirable that the Service Provider carry these packets through their 248 network and remove the IP router alert option from the IP header on 249 ingress/receipt of the packet. This ensures that at least the packet 250 will make it through the Service Provider network allowing the packet 251 to be intercepted via other means than the IP router alert. 253 Where the Service Provider does not ensure transport of router alert 254 packets for an end to end protocol of interest to a Service Provider 255 user, the user may remove the IP router alert option from the IP 256 header before sending the packet to the Service Provider and may then 257 intercept the packet on the other side using some other interception 258 technique (and then possibly restore the IP Router alert option). 260 The authors of this document are seeking feedback on whether some of 261 the practices discussed in this section ought to be elevated to BCP 262 requirements or recommendations. 264 4. Example Protection Mechanisms in a Router Alert Implementation 266 Implementations of Router Alert on routers generally include 267 mechanisms for protection against the associated security risk. This 268 section provides examples of behaviors that may be supported by 269 router implementations to help protect the router. The authors are 270 seeking feedback about whether such mechanisms (or a subset/superset 271 of those) ought to be elevated to BCP requirements and 272 recommendations instead of simply described as examples. 274 4.1. Handling Packets Carrying the Router Alert Option 276 o a router implementation may elect to perform packet inspection to 277 see whether they carry the Router Alert option in the "fast path". 278 This avoids punting all packets to the slow path when the router 279 is interested in some router alert packets. 281 o a router implementation may elect to not send to the "slow path" 282 IP packets carrying the Router Alert option unless router alert 283 interception is explicitly enabled on the router (or interface). 284 This avoids punting any router alert packet when the router is not 285 interested in any of those. 287 o a router implementation may elect to not send to the "slow path" 288 IP packets carrying the Router Alert option unless there is at 289 least one protocol explicitly enabled on the router (or interface) 290 which is defined to use the IP Router Alert option. This avoids 291 punting any router alert packet when the router is not interested 292 in any of those. 294 o a router implementation may elect to allow configuration of which 295 protocol is "of interest" for the Router Alert option interception 296 (on router or interface level). The router implementation may 297 then elect to not send packets carrying the Router Alert option to 298 the "slow path" unless the payload protocol carried in the packet 299 is configured as "protocol of interest". This avoids punting 300 router alert packet carrying a protocol in which the router is not 301 interested. 303 4.2. Applying Rate Limiting 305 o a router implementation may elect to support (in the fast path) 306 rate limiting of the number of Router Alert IP datagrams (e.g. at 307 router or interface level) which go to the "slow path". The 308 benefits of rate limiting is described in [RFC2711]. 310 o a router implementation may elect to support (in the fast path) 311 separate rate limiting per payload protocol. This allows one 312 protocol relying on router alert to be protected from DOS attacks 313 using router alert with a different protocol. 315 4.3. Router Alert in Congested Systems 317 o a router implementation may elect to support selective dropping of 318 packets carrying the Router Alert option (rather than pass them to 319 the "slow path") in preference to dropping other control plane 320 packets, in the face of control plane congestion. This protects 321 other control plane protocols from router alert attacks. 323 4.4. Handling Unknown Payload Protocols 325 If an IP packet contains the Router Alert option, but the payload 326 protocol is not explicitly identified as a Payload of interest by the 327 router examining the packet, the behavior is not defined by 328 [RFC2113]. However, the definition of RSVP in [RFC2205] assumes that 329 the packet will be forwarded using normal forwarding based on the 330 destination IP address. 332 o a router implementation may elect to forward within the "fast 333 path" (subject to all normal policies and forwarding rules) a 334 packet carrying the Router Alert option containing a payload that 335 is not a payload of interest to that router. The "not passing" 336 behavior protects the router from DOS attacks using router alert 337 packets of a protocol unknown to the router. The "forwarding" 338 behavior contributes to transparent end to end transport of router 339 alert packets (e.g. to facilitate their use by end to end 340 application). 342 5. Security Considerations 344 This document discusses security risks associated with current usage 345 of the IP Router Alert Option and associated practices. 347 6. IANA Considerations 349 None. 351 7. Contributors 353 The contributors to this document (in addition to the editors) are: 355 o David Ward: 357 * Cisco Systems 359 * wardd@cisco.com 361 o Francois Le Faucheur: 363 * Cisco Systems 365 * flefauch@cisco.com 367 o Ashok Narayanan: 369 * Cisco Systems 371 * ashokn@cisco.com 373 o Adrian Farrell: 375 * OldDog Consulting 377 * adrian@olddog.co.uk 379 o Tony Li: 381 * tony.li@tony.li 383 8. Acknowledgments 385 We would like to thank Dave Oran, Magnus Westerlund, John Scudder, 386 Ron Bonica and Ross Callon for their comments. 388 9. References 390 9.1. Normative References 392 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 393 September 1981. 395 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 396 February 1997. 398 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 399 RFC 2711, October 1999. 401 9.2. Informative References 403 [I-D.dasmith-mpls-ip-options] 404 Jaeger, W., Mullooly, J., Scholl, T., and D. Smith, 405 "Requirements for Label Edge Router Forwarding of IPv4 406 Option Packets", draft-dasmith-mpls-ip-options-01 (work in 407 progress), October 2008. 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, March 1997. 412 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 413 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 414 Functional Specification", RFC 2205, September 1997. 416 [RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, 417 "Aggregation of RSVP for IPv4 and IPv6 Reservations", 418 RFC 3175, September 2001. 420 [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., 421 Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, 422 L., Tweedly, A., Bhaskar, N., Edmonstone, R., 423 Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport 424 Protocol Specification", RFC 3208, December 2001. 426 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 427 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 428 Tunnels", RFC 3209, December 2001. 430 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 431 Thyagarajan, "Internet Group Management Protocol, Version 432 3", RFC 3376, October 2002. 434 [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for 435 Next Steps in Signaling (NSIS)", RFC 4081, June 2005. 437 [RFC5350] Manner, J. and A. McDonald, "IANA Considerations for the 438 IPv4 and IPv6 Router Alert Options", RFC 5350, 439 September 2008. 441 Appendix A. A New Filtering Mechanism to Select IP RAO Packets of 442 Interest 444 This appendix discusses a possible enhancement to the current 445 specification of Router Alert to ensure that risks associated with 446 unintentional interception of packets that are not of real interest 447 to a given router are minimized (if not eliminated) by facilitating 448 identification in the fast path of the subset of packets with router 449 alert that are of interest to the router. A key aspect of the 450 proposal is to facilitate finer grain identification of router alert 451 packets of interest versus unwanted router alert packets while only 452 requiring inspection of the router alert header. In particular: 454 o the proposal allows router alert packets from different 455 application protocols to be easily distinguished even if they 456 share the same transport protocol (i.e. the have the same IP PID). 458 o the proposal allows router alert packets for the same application 459 protocol but associated with different contexts (e.g. end to end 460 RSVP vs internal RSVP-TE) to be easily distinguished. 462 The objective of this appendix is to solicit feedback on the question 463 of whether an enhancement to the current router alert specification 464 is justified, and if yes, how to enhance it. 466 [RFC2113] specifies no mechanism for identifying different users of 467 IP RAO, with the result that many fast switching implementations punt 468 most/all packets marked with IP RAO into the slow path. It is 469 desirable for fast switching implementations to easily identify which 470 packets marked with IP RAO are actually of interest to local 471 protocols, so that other packets marked with IP RAO may be 472 efficiently forwarded. In the past, router alert implementations 473 have also looked at the IP PID [RFC0791] as a discriminator for 474 different protocols using IP RAO. However, this has two drawbacks. 475 The first is that messages with the same IP PID may represent 476 different protocol operations for IP RAO processing (e.g. RSVP vs. 477 RSVP-TE), or even different contexts (e.g. different levels of RSVP 478 aggregation [RFC3175]), and it is desirable to distinguish these in 479 the fast path. The second drawback is that IP PID values are a 480 scarce resource, and it is likely that new IP datagram protocols will 481 be assigned UDP port numbers rather than IP PIDs. Any such future 482 protocol which desires to use IP RAO would require additional checks 483 in the fast path to select out the correct packets for local 484 processing. To solve these problems, we propose an extension to the 485 specification and processing behaviour of the IP RAO header. 487 [RFC2113] specifies a 2-octet value in the IP RAO option field. 488 [RFC5350] specifies creation of an IANA registry for managing this 489 2-octet value, and proposes a unified IPv4/IPv6 usage as follows: 490 +-------------+--------------------------------------+-----------+ 491 | Value | Description | Reference | 492 +-------------+--------------------------------------+-----------+ 493 | 0 | Router shall examine packet | [RFC2113] | 494 | 1-32 | Aggregated Reservation Nesting Level | [RFC3175] | 495 | 33-65502 | Available for assignment by the IANA | | 496 | 65503-65534 | Available for experimental use | | 497 | 65535 | Reserved | | 498 +-------------+--------------------------------------+-----------+ 500 We propose the following change to IP RAO processing: 502 o The following 2-octet field will now be used to identify the 503 protocol and context from an IP RAO perspective. For IANA 504 assignment purposes, this field will be split into two octets 505 +----------+----------+ 506 + protocol + context + 507 + selector + selector + 508 + (8 bits) + (8 bits) + 509 +----------+----------+ 511 The protocol selector will be assigned for major protocols by IANA 512 and the context selector will be specific to the protocol. 513 Protocol selector 0 is reserved for backward compatibility and 514 protocol selector 255 is reserved for experimental use. New 515 protocol using IP RAO MUST allocate and use new protocol selector 516 and context selector values. For protocol selector 1-254, the 517 value of the protocol and context selector fields MUST be assigned 518 in a manner such that the content of the IP RAO option is 519 sufficient to determine whether a packet is of interest to a node, 520 with a reasonable level of granularity. For example, having the 521 [RFC3175] aggregate reservation nesting level in the context 522 selector allows P routers to quickly separate out RSVP messages 523 for aggregate vs. end-to-end flows. Or, a separate context 524 selector for RSVP-IPv4 vs. RSVP-TE sessions allows nodes to 525 efficiently ignore one session type while processing another. 527 o Fast path switching implementations SHOULD use this field to 528 determine whether they wish to select a packet with IP RAO for 529 local processing. A table of in-use protocol/context selector 530 values can be looked up during packet switching to determine 531 whether the packet is to be locally processed. For packets marked 532 with protocol selectors 1-254, the value of the IP RAO value field 533 is sufficient to rapidly determine whether the packet may be 534 forwarded unmodified or whether it should be punted to the "slow 535 path" for local processing. 537 o The protocol selector 0 is reserved for backwards compatibility. 538 For packets marked with protocol selector 0, the packet MUST be 539 examined further to determine whether it is of local interest, in 540 compliance with current protocol requirements. 542 o All the requirements regarding protecting router control plane 543 resources from attacks based on IP RAO, and protecting different 544 protocols using IP RAO from each other, continue to apply in this 545 context. The protocol selector and context selector fields MAY be 546 used to differentiate between these protocols. 548 o Protocol and context selector values will be allocated for 549 existing users of IP RAO as well (e.g. RSVP, IGMPv2 and PGM). 551 Author's Address 553 Reshad Rahman (editor) 554 Cisco Systems 555 2000 Innovation Dr. 556 Kanata, Ontario K2K 3E8 557 Canada 559 Email: rrahman@cisco.com 561 Full Copyright Statement 563 Copyright (C) The IETF Trust (2008). 565 This document is subject to the rights, licenses and restrictions 566 contained in BCP 78, and except as set forth therein, the authors 567 retain all their rights. 569 This document and the information contained herein are provided on an 570 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 571 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 572 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 573 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 574 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 575 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 577 Intellectual Property 579 The IETF takes no position regarding the validity or scope of any 580 Intellectual Property Rights or other rights that might be claimed to 581 pertain to the implementation or use of the technology described in 582 this document or the extent to which any license under such rights 583 might or might not be available; nor does it represent that it has 584 made any independent effort to identify any such rights. Information 585 on the procedures with respect to rights in RFC documents can be 586 found in BCP 78 and BCP 79. 588 Copies of IPR disclosures made to the IETF Secretariat and any 589 assurances of licenses to be made available, or the result of an 590 attempt made to obtain a general license or permission for the use of 591 such proprietary rights by implementers or users of this 592 specification can be obtained from the IETF on-line IPR repository at 593 http://www.ietf.org/ipr. 595 The IETF invites any interested party to bring to its attention any 596 copyrights, patents or patent applications, or other proprietary 597 rights that may cover technology that may be required to implement 598 this standard. Please address the information to the IETF at 599 ietf-ipr@ietf.org.