idnits 2.17.1 draft-ietf-pim-lasthop-threats-04.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 551. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 557. 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 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 (May 8, 2008) is 5831 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-10) exists of draft-ietf-pim-sm-linklocal-03 -- Obsolete informational reference (is this intentional?): RFC 3547 (Obsoleted by RFC 6407) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM WG P. Savola 3 Internet-Draft CSC/FUNET 4 Intended status: Informational J. Lingard 5 Expires: November 9, 2008 Arastra 6 May 8, 2008 8 Host Threats to Protocol Independent Multicast (PIM) 9 draft-ietf-pim-lasthop-threats-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 9, 2008. 36 Abstract 38 This memo complements the list of multicast infrastructure security 39 threat analysis documents by describing Protocol Independent 40 Multicast (PIM) threats specific to router interfaces connecting 41 hosts. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Host-interface PIM Vulnerabilities . . . . . . . . . . . . . . 3 47 2.1. Nodes May Send Illegitimate PIM Register Messages . . . . 4 48 2.2. Nodes May Become Illegitimate PIM Neighbors . . . . . . . 4 49 2.3. Routers May Accept PIM Messages From Non-Neighbors . . . . 4 50 2.4. An Illegitimate Node May Be Elected as the PIM DR or DF . 4 51 2.4.1. PIM-SM Designated Router Election . . . . . . . . . . 4 52 2.4.2. BIDIR-PIM Designated Forwarder Election . . . . . . . 4 53 2.5. A Node May Become an Illegitimate PIM Asserted 54 Forwarder . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.6. BIDIR-PIM Does Not Use RPF Check . . . . . . . . . . . . . 5 56 3. On-link Threats . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1. Denial-of-Service Attack on the Link . . . . . . . . . . . 6 58 3.2. Denial-of-Service Attack on the Outside . . . . . . . . . 6 59 3.3. Confidentiality, Integrity or Authorization Violations . . 7 60 4. Mitigation Methods . . . . . . . . . . . . . . . . . . . . . . 8 61 4.1. Passive Mode for PIM . . . . . . . . . . . . . . . . . . . 8 62 4.2. Use of IPsec among PIM Routers . . . . . . . . . . . . . . 8 63 4.3. IP Filtering PIM Messages . . . . . . . . . . . . . . . . 8 64 4.4. Summary of Vulnerabilities and Mitigation Methods . . . . 9 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 72 Intellectual Property and Copyright Statements . . . . . . . . . . 13 74 1. Introduction 76 There has been some analysis of the security threats to the multicast 77 routing infrastructures [RFC4609], some work on implementing 78 confidentiality, integrity and authorization in the multicast payload 79 [RFC3740], and also some analysis of security threats in IGMP/MLD 80 [I-D.daley-magma-smld-prob], but no comprehensive analysis of 81 security threats to PIM at the host-connecting (typically "Local Area 82 Network") links. 84 We define these PIM host threats to include: 86 o Nodes using PIM to attack or deny service to hosts on the same 87 link, 89 o Nodes using PIM to attack or deny service to valid multicast 90 routers on the link, or 92 o Nodes using PIM (Register messages) to bypass the controls of 93 multicast routers on the link. 95 The attacking node is typically a host or a host acting as an 96 illegitimate router. 98 A node originating multicast data can disturb existing receivers of 99 the group on the same link, but this issue is not PIM-specific so it 100 is out of scope. Subverting legitimate routers is out of scope. 101 Security implications on multicast routing infrastructure are 102 described in [RFC4609]. 104 This document analyzes the PIM host-interface vulnerabilities, 105 formulates a few specific threats, proposes some potential ways to 106 mitigate these problems and analyzes how well those methods 107 accomplish fixing the issues. 109 It is assumed that the reader is familiar with the basic concepts of 110 PIM. 112 2. Host-interface PIM Vulnerabilities 114 This section describes briefly the main attacks against host- 115 interface PIM signalling, before we get to the actual threats and 116 mitigation methods in the next sections. 118 The attacking node may be either a malicious host or an illegitimate 119 router. 121 2.1. Nodes May Send Illegitimate PIM Register Messages 123 PIM Register messages are sent unicast, and contain encapsulated 124 multicast data packets. Malicious hosts or routers could also send 125 Register messages themselves, for example to get around rate-limits 126 or to interfere with foreign Rendezvous Points (RPs) as described in 127 [RFC4609]. 129 The Register message can be targeted to any IP address, whether in or 130 out of the local PIM domain. The source address may be spoofed 131 unless spoofing has been prevented [RFC3704], to create arbitrary 132 state at the RPs. 134 2.2. Nodes May Become Illegitimate PIM Neighbors 136 When PIM has been enabled on a router's host interface, any node can 137 also become a PIM neighbor using PIM Hello messages. Having become a 138 PIM neighbor in this way, the node is able to send other PIM messages 139 to the router and may use those messages to attack the router. 141 2.3. Routers May Accept PIM Messages From Non-Neighbors 143 The PIM-SM specification recommends that PIM messages other than 144 Hellos should not be accepted except from valid PIM neighbors. 145 BIDIR-PIM [RFC5015] specification (Section 5.2) specifies that 146 packets from non-neighbors "SHOULD NOT" be accepted. However, the 147 specification does not mandate this, and so some implementations may 148 be susceptible to attack from PIM messages sent by non-neighbors. 150 2.4. An Illegitimate Node May Be Elected as the PIM DR or DF 152 2.4.1. PIM-SM Designated Router Election 154 In PIM-SM, the Designated Router (DR) on a Local Area Network (LAN) 155 is responsible for Register-encapsulating data from new sources on 156 the LAN, and for generating PIM Join/Prune messages on behalf of 157 group members on the LAN. 159 A node which can become a PIM neighbor can also cause itself to be 160 elected DR, whether or not the DR Priority option is being used in 161 PIM Hello messages on the LAN. 163 2.4.2. BIDIR-PIM Designated Forwarder Election 165 In BIDIR-PIM [RFC5015] a Designated Forwarder (DF) is elected per 166 link. The DF is responsible for forwarding data downstream onto the 167 link, and also for forwarding data from its link upstream. 169 A node which can become a BIDIR-PIM neighbor (this is just like 170 becoming a PIM neighbor, except that the PIM Hello messages must 171 include the Bidirectional Capable PIM-Hello option) can cause itself 172 to be elected DF by sending DF Offer messages with a better metric 173 than its neighbors. 175 There are also some other BIDIR-PIM attacks related to DF election, 176 including spoofing DF Offer and DF Winner messages (e.g., using a 177 legitimate router's IP address), making all but the impersonated 178 router believe that router is the DF. Also an attacker might prevent 179 the DF election from converging by sending an infinite sequence of DF 180 Offer messages. 182 For further discussion of BIDIR-PIM threats we refer to the security 183 considerations section in [RFC5015]. 185 2.5. A Node May Become an Illegitimate PIM Asserted Forwarder 187 With a PIM Assert message, a router can be elected to be in charge of 188 forwarding all traffic for a particular (S,G) or (*,G) onto the LAN. 189 This overrides DR behaviour. 191 The specification says that Assert messages should only be accepted 192 from known PIM neighbors, and "SHOULD" be discarded otherwise. So, 193 either the node must be able to spoof an IP address of a current 194 neighbor, form a PIM adjacency first, or count on these checks being 195 disabled. 197 The Assert Timer, by default, is 3 minutes; the state must be 198 refreshed or it will be removed automatically. 200 As noted before, it is also possible to spoof an Assert (e.g., using 201 a legitimate router's IP address) to cause a temporary disruption on 202 the LAN. 204 2.6. BIDIR-PIM Does Not Use RPF Check 206 PIM protocols do not perform RPF check on the shared tree (e.g., in 207 PIM-SM from the RP to local receivers). On the other hand, RPF check 208 is performed e.g., on stub host interfaces. Because all forwarding 209 in BIDIR-PIM is based on the shared tree principle, it does not use 210 RPF check to verify that the forwarded packets are being received 211 from a "topologically correct" direction. This has two immediately 212 obvious implications: 214 1. A node may maintain a forwarding loop until the TTL runs out by 215 passing packets from interface A to B. This is not believed to 216 cause significant new risk as with a similar ease such a node 217 could generate original packets which would loop back to its 218 another interface. 220 2. A node may spoof source IP addresses in multicast packets it 221 sends. Other PIM protocols drop such packets when performing the 222 RPF check. BIDIR-PIM accepts such packets allowing easier DoS 223 attacks on the multicast delivery tree and making the attacker 224 less traceable. 226 3. On-link Threats 228 The previous section described some PIM vulnerabilities; this section 229 gives an overview of the more concrete threats exploiting those 230 vulnerabilities. 232 3.1. Denial-of-Service Attack on the Link 234 The easiest attack is to deny the multicast service on the link. 235 This could mean either not forwarding all (or parts of) multicast 236 traffic from upstream onto the link, or not registering or forwarding 237 upstream the multicast transmissions originated on the link. 239 These attacks can be done multiple ways: the most typical one would 240 be becoming the DR through becoming a neighbor with Hello messages 241 and winning the DR election. After that, one could for example: 243 o Not send any PIM Join/Prune messages based on the IGMP reports, or 245 o Not forward or register any sourced packets. 247 Sending PIM Prune messages may also be an effective attack vector 248 even if the attacking node is not elected DR, since PIM Prune 249 messages are accepted from downstream interfaces even if the router 250 is not a DR. 252 An alternative mechanism is to send a PIM Assert message, spoofed to 253 come from a valid PIM neighbor or non-spoofed if a PIM adjacency has 254 already been formed. For the particular (S,G) or (*,G) from the 255 Assert message, this creates the same result as getting elected as a 256 DR. With BIDIR-PIM similar attacks can be done by becoming the DF or 257 by preventing the DF election from converging. 259 3.2. Denial-of-Service Attack on the Outside 261 It is also possible to perform Denial-of-Service attacks on nodes 262 beyond the link, especially in environments where a multicast router 263 and/or a DR is considered to be a trusted node. 265 In particular, if DRs perform some form of rate-limiting, for example 266 on new Join/Prune messages, becoming a DR and sending those messages 267 yourself allows one to subvert these restrictions: therefore rate- 268 limiting functions need to be deployed at multiple layers as 269 described in [RFC4609]. 271 In addition, any host can send PIM Register messages on their own, to 272 whichever RP it wants; further, if unicast RPF (Reverse Path 273 Forwarding) mechanisms [RFC3704] have not been applied, the packet 274 may be spoofed. This can be done to get around rate-limits, and/or 275 to attack remote RPs and/or to interfere with the integrity of an ASM 276 group. This attack is also described in [RFC4609]. 278 Also, BIDIR-PIM does not prevent nodes from using topologically 279 incorrect addresses (source address spoofing) making such an attack 280 more difficulty to trace. 282 3.3. Confidentiality, Integrity or Authorization Violations 284 Contrary to unicast, any node is able to legitimately receive all 285 multicast transmission on the link by just adjusting the appropriate 286 link-layer multicast filters. Confidentiality (if needed) must be 287 obtained by cryptography. 289 If a node can become a DR, it is able to violate the integrity of any 290 data streams sent by sources on the LAN, by modifying (possibly in 291 subtle, unnoticeable ways) the packets sent by the sources before 292 Register-encapsulating them. 294 If a node can form a PIM neighbor adjacency or spoof the IP address 295 of a current neighbor, then if it has external connectivity by some 296 other means other than the LAN, the node is able to violate the 297 integrity of any data streams sent by external sources onto the LAN. 298 It would do this by sending an appropriate Assert message onto the 299 LAN to prevent the genuine PIM routers forwarding the valid data, 300 obtaining the multicast traffic via its other connection, and 301 modifying those data packets before forwarding them onto the LAN. 303 In either of the above two cases, the node could operate as normal 304 for some traffic, while violating integrity for some other traffic. 306 A more elaborate attack is on authorization. There are some very 307 questionable models [I-D.hayashi-igap] where the current multicast 308 architecture is used to provide paid multicast service, and where the 309 authorization/authentication is added to the group management 310 protocols such as IGMP. Needless to say, if a host would be able to 311 act as a router, it might be possible to perform all kinds of 312 attacks: subscribe to multicast service without using IGMP (i.e., 313 without having to pay for it), deny the service for the others on the 314 same link, etc. In short, to be able to ensure authorization, a 315 better architecture should be used instead (e.g., [RFC3740]). 317 4. Mitigation Methods 319 This section lists some ways to mitigate the vulnerabilities and 320 threats listed in previous sections. 322 4.1. Passive Mode for PIM 324 The current PIM specification seems to mandate running the PIM Hello 325 protocol on all PIM-enabled interfaces. Most implementations require 326 PIM to be enabled on an interface in order to send PIM Register 327 messages for data sent by sources on that interface or to do any 328 other PIM processing. 330 As described in [RFC4609], running full PIM, with Hello messages and 331 all, is unnecessary for those stub networks for which only one router 332 is providing multicast service. Therefore such implementations 333 should provide an option to specify that the interface is "passive" 334 with regard to PIM: no PIM packets are sent or processed (if 335 received), but hosts can still send and receive multicast on that 336 interface. 338 4.2. Use of IPsec among PIM Routers 340 Instead of passive mode, or when multiple PIM routers exist on a 341 single link, one could also use IPsec to secure the PIM messaging, to 342 prevent anyone from subverting it. The actual procedures have been 343 described in [RFC4601] and [I-D.ietf-pim-sm-linklocal]. 345 However, it is worth noting that setting up IPsec Security 346 Associations (SAs) manually can be a very tedious process, and the 347 routers might not even support IPsec; further automatic key 348 negotiation may not be feasible in these scenarios either. A Group 349 Domain of Interpretation (GDOI) [RFC3547] server might be able to 350 mitigate this negotiation. 352 4.3. IP Filtering PIM Messages 354 To eliminate both the unicast and multicast PIM messages, in similar 355 scenarios to those for which PIM passive mode is applicable, it might 356 be possible to block IP protocol 103 (all PIM messages) in an input 357 access-list. This is more effective than PIM passive mode, as this 358 also blocks Register messages. 360 This is also acceptable when there is more than one PIM router on the 361 link if IPsec is used (because the access-list processing sees the 362 valid PIM messages as IPsec AH/ESP packets). However, this presumes 363 that the link is not used to transit unicast packets between the PIM 364 routers, or that the Register messages are also being sent with 365 IPsec. 367 When multiple routers exist on a link, IPsec is not required if it is 368 possible to prevent hosts from sending PIM messages at Ethernet 369 switch (or equivalent) host ports. This could be accomplished in at 370 least two ways: 372 1. Use IP access lists on the stub routers to allow PIM messages 373 from the valid neighbor IP addresses only, and implement IP 374 spoofing prevention at Ethernet switch port level using 375 proprietary mechanisms, or 377 2. Filter out all PIM messages at configured host ports on Ethernet 378 switches instead of doing it on the routers. 380 The main benefit of this approach is that multiple stub routers can 381 still communicate through the LAN without IPsec but hosts are not 382 able to disturb the PIM protocol. The drawback is that Ethernet 383 switches need to implement much finer-grained IP layer filtering and 384 the operational requirements of carefully maintaining these filters 385 could be significant. 387 4.4. Summary of Vulnerabilities and Mitigation Methods 389 This section summarizes the vulnerabilities, and how well the 390 mitigation methods are able to cope with them. 392 Summary of vulnerabilities and mitigations: 394 +-----+---------------------+-----------------+-----------------+ 395 | Sec | Vulnerability | One stub router | >1 stub routers | 396 | | | PASV|IPsec|Filt | PASV|IPsec|Filt | 397 +-----+---------------------+-----+-----+-----+-----+-----+-----+ 398 | 2.1 | Hosts Registering | N | N+ | Y | N | N+ | Ysw | 399 +-----+---------------------+-----+-----+-----+-----+-----+-----+ 400 | 2.2 | Invalid Neighbor | Y | Y | Y | * | Y | Ysw | 401 +-----+---------------------+-----+-----+-----+-----+-----+-----+ 402 | 2.3 | Adjacency Not Reqd | Y | Y | Y | * | Y | Ysw | 403 +-----+---------------------+-----+-----+-----+-----+-----+-----+ 404 | 2.4 | Invalid DR /DF | Y | Y | Y | * | Y | Ysw | 405 +-----+---------------------+-----+-----+-----+-----+-----+-----+ 406 | 2.5 | Invalid Forwarder | Y | Y | Y | * | Y | Ysw | 407 +-----+---------------------+-----+-----+-----+-----+-----+-----+ 408 | 2.6 | No RPF Check (BIDIR)| x | x | x | x | x | x | 409 +-----+---------------------+-----+-----+-----+-----+-----+-----+ 411 Figure 1 413 "*" means Yes if IPsec is used in addition; No otherwise 415 "Ysw" means Yes if IPsec is used in addition or IP filtering is done 416 on Ethernet switches on all host ports; No otherwise. 418 "N+" means that the use of IPsec between the on-link routers does not 419 protect from this; IPsec would have to be used at RPs. 421 "x" means that with BIDIR-PIM, IP access lists or RPF mechanisms need 422 to be applied in stub interfaces to prevent originating packets with 423 topologically incorrect source addresses. This needs to be done in 424 addition to any other chosen approach. 426 To summarize, IP protocol filtering for all PIM messages appears to 427 be the most complete solution when coupled with the use of IPsec 428 between the real stub routers when there are more than one of them. 429 However, IPsec is not required if PIM message filtering or certain 430 kind of IP spoofing prevention is applied on all the host ports on 431 Ethernet switches. If hosts performing registering is not considered 432 a serious problem, IP protocol filtering and passive-mode PIM seem to 433 be equivalent approaches. Additionally if BIDIR-PIM is used, ingress 434 filtering will need to be applied in stub interfaces to multicast 435 packets as well as unicast to prevent hosts using wrong source 436 addresses. 438 5. Acknowledgements 440 Greg Daley and Gopi Durup wrote an excellent analysis of MLD security 441 issues [I-D.daley-magma-smld-prob], which gave inspiration in 442 exploring the on-link PIM threats problem space. 444 Ayan Roy-Chowdhury, Beau Williamson, Bharat Joshi, Dino Farinacci, 445 John Zwiebel, Stig Venaas, Yiqun Cai, and Eric Gray provided good 446 feedback for this memo. 448 6. IANA Considerations 450 This memo includes no request to IANA. 452 7. Security Considerations 454 This memo analyzes the threats to the PIM multicast routing protocol 455 on host interfaces and proposes some possible mitigation techniques. 457 8. References 459 8.1. Normative References 461 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 462 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 463 Protocol Specification (Revised)", RFC 4601, August 2006. 465 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 466 Independent Multicast - Sparse Mode (PIM-SM) Multicast 467 Routing Security Issues and Enhancements", RFC 4609, 468 October 2006. 470 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 471 "Bidirectional Protocol Independent Multicast (BIDIR- 472 PIM)", RFC 5015, October 2007. 474 8.2. Informative References 476 [I-D.daley-magma-smld-prob] 477 Daley, G. and G. Kurup, "Trust Models and Security in 478 Multicast Listener Discovery", 479 draft-daley-magma-smld-prob-00 (work in progress), 480 July 2004. 482 [I-D.hayashi-igap] 483 Hayashi, T., "Internet Group membership Authentication 484 Protocol (IGAP)", draft-hayashi-igap-03 (work in 485 progress), August 2003. 487 [I-D.ietf-pim-sm-linklocal] 488 Atwood, J., Islam, S., and M. Siami, "Authentication and 489 Confidentiality in PIM-SM Link-local Messages", 490 draft-ietf-pim-sm-linklocal-03 (work in progress), 491 February 2008. 493 [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The 494 Group Domain of Interpretation", RFC 3547, July 2003. 496 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 497 Networks", BCP 84, RFC 3704, March 2004. 499 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 500 Architecture", RFC 3740, March 2004. 502 Authors' Addresses 504 Pekka Savola 505 CSC - Scientific Computing Ltd. 506 Espoo 507 Finland 509 Email: psavola@funet.fi 511 James Lingard 512 Arastra, Inc. 513 P.O. Box 10905 514 Palo Alto, CA 94303 515 USA 517 Email: jchl@arastra.com 519 Full Copyright Statement 521 Copyright (C) The IETF Trust (2008). 523 This document is subject to the rights, licenses and restrictions 524 contained in BCP 78, and except as set forth therein, the authors 525 retain all their rights. 527 This document and the information contained herein are provided on an 528 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 529 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 530 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 531 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 532 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 533 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 535 Intellectual Property 537 The IETF takes no position regarding the validity or scope of any 538 Intellectual Property Rights or other rights that might be claimed to 539 pertain to the implementation or use of the technology described in 540 this document or the extent to which any license under such rights 541 might or might not be available; nor does it represent that it has 542 made any independent effort to identify any such rights. Information 543 on the procedures with respect to rights in RFC documents can be 544 found in BCP 78 and BCP 79. 546 Copies of IPR disclosures made to the IETF Secretariat and any 547 assurances of licenses to be made available, or the result of an 548 attempt made to obtain a general license or permission for the use of 549 such proprietary rights by implementers or users of this 550 specification can be obtained from the IETF on-line IPR repository at 551 http://www.ietf.org/ipr. 553 The IETF invites any interested party to bring to its attention any 554 copyrights, patents or patent applications, or other proprietary 555 rights that may cover technology that may be required to implement 556 this standard. Please address the information to the IETF at 557 ietf-ipr@ietf.org.