idnits 2.17.1 draft-bradford-pce-path-key-02.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 556. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 581. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (January 3, 2007) is 6294 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) -- Possible downref: Normative reference to a draft: ref. 'PCEP' -- Possible downref: Normative reference to a draft: ref. 'RSVP-PKS' Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group Rich Bradford (Ed) 3 IETF Internet Draft JP Vasseur 4 Cisco Systems, Inc. 5 Adrian Farrel 6 Old Dog Consulting 8 Proposed Status: Standard 9 Expires: July 3, 2007 10 January 3, 2007 12 draft-bradford-pce-path-key-02.txt 14 Preserving Topology Confidentiality in Inter-Domain Path 15 Computation using a key based mechanism 17 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months 30 and may be updated, replaced, or obsoleted by other documents at 31 any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on July 3, 2007. 43 Bradford, Vasseur and Farrel 1 44 Copyright Notice 46 Copyright (C) The IETF Trust (2007). All rights reserved. 48 Abstract 50 Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) 51 Label Switched Paths (LSPs) may be computed by Path Computation 52 Elements (PCEs). Where the TE LSP crosses multiple domains, such 53 as Autonomous Systems (ASs), the path may be computed by multiple 54 PCEs that cooperate, with each responsible for computing a segment 55 of the path. However, in some cases (e.g. when ASs are 56 administered by separate Service Providers), it would break 57 confidentiality rules for a PCE to supply a path segment to a PCE 58 in another domain, thus disclosing internal topology information. 59 This issue may be circumvented by returning a loose hop and by 60 invoking a new path computation from the domain boundary LSR 61 during TE LSP setup as the LSP enters the second domain, but this 62 technique has several issues including the problem of maintaining 63 path diversity. 65 This document defines a mechanism to hide the contents of a 66 segment of a path, called the Confidential Path Segment (CPS). The 67 CPS may be replaced by a path-key that can be conveyed in the PCE 68 Communication Protocol (PCEP) and signaled within in a Resource 69 Reservation Protocol (RSVP) explicit route object. 71 Table of contents 72 1. Introduction.................................................3 73 2. Terminology..................................................4 74 3. Path-Key Solution............................................5 75 3.1. Mode of Operation...........................................5 76 4. PCEP Protocol Extensions.....................................6 77 4.1. PKS sub-object..............................................6 78 4.2. PKS bit.....................................................8 79 5. PCEP Mode of operation.......................................9 80 6. Security Considerations......................................9 81 7. Manageability Considerations................................10 82 8. IANA considerations.........................................10 83 9. Intellectual Property Considerations........................11 84 10. References.................................................11 85 10.1. Normative References.....................................11 86 10.2. Informational References.................................12 87 11. Authors' Addresses:........................................12 89 Bradford, Vasseur, and Farrel 2 90 Conventions used in this document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 93 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in 95 RFC-2119 [RFC2119]. 97 1. Introduction 99 Path computation techniques using the Path Computation Element 100 (PCE) have been described in [PCE-ARCH] and allow for path 101 computation of inter-domain Multiprotocol Label Switching (MPLS) 102 traffic engineering (TE) Label Switched Paths (LSPs). 104 An important element of inter-domain TE is that TE information is 105 not shared between domains for scalability and confidentiality 106 reasons ([RFC4105] and [RFC4216]). Therefore, a single PCE is 107 unlikely to be able to compute a full inter-domain path. 109 Two path computation scenarios can be used for inter-domain TE 110 LSPs: one using per-domain path computation (defined in [PD-PATH- 111 COMP]), and the other using a PCE-based path computation technique 112 with cooperation between PCEs (as described in [PCE-ARCH]). In 113 this second case, paths for inter-domain LSPs can be computed by 114 cooperation between PCEs each of which computes a segment of the 115 path across one domain. Such a path computation procedure is 116 described in [BRPC]. 118 If confidentiality is required between domains (such as would very 119 likely be the case between ASs belonging to different Service 120 Providers) then cooperating PCEs cannot exchange path segments or 121 else the receiving PCE and the Path Computation Client (PCC) will 122 be able to see the individual hops through another domain thus non 123 conforming to the confidentiality requirement stated in [RFC4105] 124 and [RFC4216]. We define the part of the path which we wish to 125 keep confidential as the Confidential Path Segment (CPS). 127 One mechanism for preserving the confidentiality of the CPS is for 128 the PCE to return a path containing a loose hop for the segment 129 internal to a domain that must be kept confidential. The concept 130 of loose hops for the route of a TE LSP is described in [RFC3209]. 132 Bradford, Vasseur, and Farrel 3 133 The Path Computation Element Communication Protocol (PCEP) defined 134 in [PCEP] supports the use of paths with loose hops, and it is a 135 local policy decision at a PCE whether it returns a full explicit 136 path or uses loose hops. Note that a Path computation Request may 137 request a loose or explicit path as detailed in [PCEP]. 139 One option may consist of returning loose hop without further 140 extensions: if loose hops are used, the TE LSPs are signaled as 141 normal ([RFC3209]), and when a loose hop is encountered in the 142 explicit route it is resolved by performing a secondary path 143 computation to reach the next loose hop. Given the nature of the 144 cooperation between PCEs in computing the original path, this 145 secondary computation occurs at a Label Switching Router (LSR) at 146 a domain boundary (i.e. an ABR or ASBR) and the path is expanded 147 as described in [PD-PATH-COMP]. 149 The PCE-based computation model is particularly useful for 150 determining mutually disjoint inter-domain paths such as might be 151 required for service protection. A single path computation request 152 is used. However, if loose hops are returned, the path of each TE 153 LSP must be recomputed at the domain boundaries as the TE LSPs are 154 signaled, and since the TE LSP signaling proceeds independently 155 for each TE LSP, disjoint paths cannot be guaranteed since the 156 LSRs in charge of expanding the EROs are not synchronized. 157 Therefore, using the loose hop technique without further 158 extensions, path segment confidentiality and path diversity are 159 mutually incompatible requirements. 161 This document defines the notion of a Path Key that is a token 162 that replaces a path segment in an explicit route. The Path Key is 163 encoded as a Path Key Sub-object (PKS) returned in the PCEP Path 164 Computation Reply message (PCReq) ([PCEP]). Upon receiving the 165 computed path, the PKS sub-object will be carried out in an RSVP- 166 TE Path message (RSVP-TE [RFC3209]) during signaling. The PKS may 167 also, optionally, be used in recorded routes in RSVP-TE. 169 2. Terminology 171 ASBR: border routers used to connect to another AS of a different 172 or the same Service Provider via one or more links inter- 173 connecting between ASs. 175 CPS: Confidential Path Segment. A segment of a path that contains 176 nodes and links that the AS policy requires to not be disclosed 177 outside the AS. 179 Bradford, Vasseur, and Farrel 4 180 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 182 LSR: Label Switching Router. 184 LSP: Label Switched Path. 186 PCC: Path Computation Client: any client application requesting a 187 path computation to be performed by a Path Computation Element. 189 PCE: Path Computation Element: an entity (component, application 190 or network node) that is capable of computing a network path or 191 route based on a network graph and applying computational 192 constraints. 194 TE LSP: Traffic Engineering Label Switched Path 196 3. Path-Key Solution 198 The Path-Key solution may be applied in the PCE-based path 199 computation context as follows. A PCE computes a path segment 200 related to a particular domain and replaces it in the path 201 reported to the requesting PCC (or another PCE) by one or more 202 sub-objects referred to as the PKS. The entry and boundary LSR of 203 each CPS SHOULD be specified as hops in the returned path 204 immediately preceding the PKS, but where two PKSs are supplied in 205 sequence the entry node to the second MAY be encoded within the 206 first. The exit node of a CPS MAY be present as a strict hop 207 immediately following the PKS, but MAY also be hidden as part of 208 the PKS. 210 3.1. Mode of Operation 212 During path computation, when local policy dictates that 213 confidentiality must be preserved for all or part of the path 214 segment being computed or if explicitly requested by the Path 215 Computation Request, the PCE associates a path-key with the 216 computed path for the CPS, places its own identifier (its PCE-ID 217 as defined in [PCE-MONITORING]) along with the path-key in a PKS, 218 and inserts the PKS object in the path returned to the requesting 219 PCC or PCE immediately after the IPv4 sub-object defined in 220 [RFC3209]sub-object that identifies the LSR that will expand the 221 PKS into a explicit path hops. This will usually be the LSR that 222 is the start point of the CPS. The PCE that generates a PKS MUST 223 store the computed path segment and the path-key for later 225 Bradford, Vasseur, and Farrel 5 226 retrieval. A local policy SHOULD be used to determine for how long 227 to retain such stored information, and whether to discard the 228 information after it has been queried using the procedures 229 described below. It is RECOMMENDED for a PCE to strore the PKS for 230 a period of 10 minutes. 232 TBD: Need to define the scope of the PKS and spell out the 233 restrictions on Path Key re-use. 235 A head-end LSR that is a PCC converts the path returned by a PCE 236 into an explicit route object (ERO) that it includes in the 237 Resource Reservation Protocol (RSVP) Path message. If the path 238 returned by the PCE contains PKSs these are included in the ERO. 239 Like any other sub-objects, the PKS is passed transparently from 240 hop to hop, until it becomes the first sub-object in the ERO. This 241 will occur at the start of the CPS which will usually be the 242 domain boundary. The PKS MUST be preceded by an ERO sub-object 243 that identifies the LSR that must expand the PKS, so the PKS will 244 not be encountered in ERO processing until the LSR that can 245 process it. 247 An LSR that encounters a PKS when trying to identify the next-hop 248 retrieves the PCE-ID from the PKS and sends a Path Computation 249 Request (PCReq) message as defined in [PCEP] to the PCE identified 250 by the PCE-ID that contains the path-key object . 252 Upon receiving the PCReq message, the PCE identifies the computed 253 path segment using the supplied path-key, and returns the 254 previously computed path segment in the form of explicit hops 255 using an ERO object contained in the Path Computation Reply 256 (PCReqp) as define in [PCEP] to the requesting node. The 257 requesting node inserts the explicit hops into the ERO and 258 continues to process the TE LSP setup as per [RFC3209]. 260 4. PCEP Protocol Extensions 262 4.1. PKS sub-object 264 The PKS object format is identical as in [RSVP-PKS] but redefined 265 in the context of this document since a PCEP codepoint is 266 required. 268 Bradford, Vasseur, and Farrel 6 269 The PKS is a fixed-length sub-object containing a Path-Key and a 270 PCE-ID. The Path Key is an identifier, or token used to represent 271 the CPS within the context of the PCE identified by the PCE-ID. 272 The PCE-ID identifies the PCE that can decode the Path Key using a 273 reachable IPv4 or IPv6 address of the PCE. 275 Because of the IPv4 and IPv6 variants, two sub-objects are defined 276 as follows. 278 PKS IPv4 sub-object 280 PKS Object-Class is to be assigned by IANA (recommended value=16) 282 PKS Object-Type is to be assigned by IANA (recommended value=1) 284 0 1 2 3 285 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 |L| Type | Length | Path Key | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | IPv4 address (4 bytes) | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 L 294 The L bit SHOULD NOT be set, so that the sub-object 295 represents a strict hop in the explicit route. 297 Type 299 TBD Path Key with IPv4 address 301 Length 303 The Length contains the total length of the subobject in 304 bytes, including the Type and Length fields. The Length is always 305 8. 307 IPv4 address 309 An IPv4 address of the PCE that can decode this key. The 310 address used SHOULD be an address of the PCE that is always 311 reachable, and MAY be an address that is restricted to the domain 312 in which the LSR that is called upon to expand the CPS lies. 314 PKS IPv6 sub-object 316 Bradford, Vasseur, and Farrel 7 317 PKS Object-Class is to be assigned by IANA (recommended value=16) 319 PKS Object-Type is to be assigned by IANA (recommended value=2) 321 0 1 2 3 322 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 |L| Type | Length | Path Key | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | IPv6 address (16 bytes) | 327 | | 328 | | 329 | | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 L 334 As above. 336 Type 338 TBD Path Key with IPv6 address 340 Length 342 The Length contains the total length of the subobject in 343 bytes, including the Type and Length fields. The Length is always 344 20. 346 IPv6 address 348 An IPv6 address of the PCE that can decode this key. The 349 address used SHOULD be an address of the PCE that is always 350 reachable, but MAY be an address that is restricted to the domain 351 in which the LSR that is called upon to expand the CPS lies. 353 4.2. PKS bit 354 [PCEP] specifies the RP object that is used to specify various 355 characteristics of the path computation request. 357 In this document we define a new bit named the PKS bit defined as 358 follow: 360 Bradford, Vasseur, and Farrel 8 361 PKS (PKS - 1 bit - Value=0x60): when set, the requesting PCC 362 requires the retrieval of a strict path segment that corresponds 363 to a PKS carried within the path computation request. The PKS bit 364 MUST be cleared when the path computation request is not related 365 to a CPS retrieval. 367 5. PCEP Mode of operation 369 The retrieval of the explicit path associated with a PKS by a PCC 370 is no different than any other path computation request with the 371 exception that the PCReq message MUST contain a PKS object and the 372 PKS bit of the RP object MUST the set. 374 If the receiving PCE cannot find any related strict path or the 375 retrieval of such strict path is not allowed by policy, the PCE 376 MUST send a PCRep message that contains a NO-PATH object. 378 Upon receipt of this negative reply, the requesting LSR MUST fail 379 the LSP setup and SHOULD use the procedures associated with loose 380 hop expansion failure [RFC3209]. 382 6. Security Considerations 384 This document proposes tunneling secure topology information 385 across an untrusted AS, so the security considerations are many 386 and apply to PCEP and RSVP-TE. 387 Issues include: 388 - Security of the CPS (can other network elements probe for 389 expansion of path-keys, possibly at random?). 390 - Authenticity of the path-key (resilience to alteration by 391 intermediaries, resilience to fake expansion of path-keys). 392 - Resilience from DNS attacks (insertion of spurious path-keys; 393 flooding of bogus path-key expansion requests). 395 Most of the interactions required by this extension are point to 396 point, can be authenticated and made secure. These interactions 397 include the: 398 - PCC->PCE request 399 - PCE->PCE request(s) 400 - PCE->PCE response(s) 401 - PCE->PCC response 403 Bradford, Vasseur, and Farrel 9 404 - LSR->LSR request and response (Note that a rogue LSR could 405 modify the ERO and insert or modify Path Keys. This would 406 result in an LSR (which is downstream in the ERO) sending 407 decode requests to a PCE. This is actually a larger problem 408 with RSVP. The rogue LSR is an existing issue with RSVP and 409 will not be addressed here. 410 - LSR->PCE request. Note that the PCE can check that the LSR 411 requesting the decode is the LSR at the head of the Path Key. 412 This largely contains the previous problem to DoS rather than 413 a security issue. A rogue LSR can issue random decode 414 requests, but these will amount only to DoS. 415 - PCE->LSR response. 417 Thus, the major security issues can be dealt with using standard 418 techniques for securing and authenticating pt-pt links. In 419 addition, it is recommended that the PCE providing a decode 420 response should check that the LSR that issued the decode request 421 is the head end of the decoded ERO segment. 423 7. Manageability Considerations 425 To be detailed in a further revision of this document. 427 8. IANA considerations 429 IANA assigns value to PCEP parameters. Each PCEP object has an 430 Object-Class and an Object-Type. 432 Two new PCEP objects are defined in this document: the IPv4 PKS 433 and the IPv6 PKS objects. 435 Object-Class Name 437 16 PKS IPv4 438 Object-Type 439 1 441 16 PKS IPv6 442 Object-Type 444 Bradford, Vasseur, and Farrel 10 445 2 447 9. Intellectual Property Considerations 449 The IETF takes no position regarding the validity or scope of any 450 Intellectual Property Rights or other rights that might be claimed 451 to pertain to the implementation or use of the technology 452 described in this document or the extent to which any license 453 under such rights might or might not be available; nor does it 454 represent that it has made any independent effort to identify any 455 such rights. Information on the procedures with respect to rights 456 in RFC documents can be found in BCP 78 and BCP 79. 458 Copies of IPR disclosures made to the IETF Secretariat and any 459 assurances of licenses to be made available, or the result of an 460 attempt made to obtain a general license or permission for the use 461 of such proprietary rights by implementers or users of this 462 specification can be obtained from the IETF on-line IPR repository 463 at http://www.ietf.org/ipr. 465 The IETF invites any interested party to bring to its attention 466 any copyrights, patents or patent applications, or other 467 proprietary rights that may cover technology that may be required 468 to implement this standard. Please address the information to the 469 IETF at ietf-ipr@ietf.org. 471 10. References 473 10.1. Normative References 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, March 1997. 478 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 479 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 480 3209, December 2001. 482 [PCEP] Vasseur, J.P., Le Roux, J.L., Ayyangar, A., Oki, E., 483 Ikejiri, A., Atlas, A., Dolganow, A., "Path Computation Element 484 (PCE) communication Protocol (PCEP)", draft-vasseur-pce-pcep, 485 work in progress. 487 Bradford, Vasseur, and Farrel 11 489 [RSVP-PKS] Bradford, R., Vasseur, J.P., Farrel, A., "RSVP 490 Extensions for Path Key Support", draft-bradford-ccamp-path-key- 491 ero, work in progress. 493 [PCE-MONITORING] Vasseur, J.P, "A set of monitoring tools for Path 494 Computation Element based Architecture", draft-vasseur-pce- 495 monitoring, work in progress. 497 10.2. Informational References 499 [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 500 Element (PCE) Architecture", RFC4655, September 2006. 502 [PD-PATH-COMP] Vasseur, J., et al "A Per-domain path computation 503 method for establishing Inter-domain Traffic Engineering (TE) 504 Label 505 Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-path- 506 comp, work in progress. 508 [BRPC] Vasseur, J., et al "A Backward Recursive PCE-based 509 Computation 510 (BRPC) procedure to compute shortest inter-domain Traffic 511 Engineering Label Switched Path", draft-ietf-pce-brpc, work in 512 progress. 514 [RFC4105] Le Roux, J., Vasseur, JP, Boyle, J., "Requirements 515 for Support of Inter-Area and Inter-AS MPLS Traffic Engineering", 516 RFC 4105, June 2005. 518 [RFC4216] Zhang, R., Vasseur, JP., et. al., "MPLS Inter-AS 519 Traffic Engineering requirements", RFC 4216, November 2005. 521 11. Authors' Addresses 523 Rich Bradford (Editor) 524 Cisco Systems, Inc. 525 1414 Massachusetts Avenue 526 Boxborough , MA - 01719 527 USA 528 Email: rbradfor@cisco.com 530 Bradford, Vasseur, and Farrel 12 531 J.-P Vasseur 532 Cisco Systems, Inc. 533 1414 Massachusetts Avenue 534 Boxborough , MA - 01719 535 USA 536 Email: jpv@cisco.com 538 Adrian Farrel 539 Old Dog Consulting 540 EMail: adrian@olddog.co.uk 542 Full Copyright Statement 544 Copyright (C) The IETF Trust (2007). 546 This document is subject to the rights, licenses and restrictions 547 contained in BCP 78, and except as set forth therein, the authors 548 retain all their rights. 550 This document and the information contained herein are provided on an 551 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 552 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 553 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 554 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 555 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 556 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 558 Bradford, Vasseur, and Farrel 13 559 Intellectual Property 561 The IETF takes no position regarding the validity or scope of any 562 Intellectual Property Rights or other rights that might be claimed to 563 pertain to the implementation or use of the technology described in 564 this document or the extent to which any license under such rights 565 might or might not be available; nor does it represent that it has 566 made any independent effort to identify any such rights. Information 567 on the procedures with respect to rights in RFC documents can be 568 found in BCP 78 and BCP 79. 570 Copies of IPR disclosures made to the IETF Secretariat and any 571 assurances of licenses to be made available, or the result of an 572 attempt made to obtain a general license or permission for the use of 573 such proprietary rights by implementers or users of this 574 specification can be obtained from the IETF on-line IPR repository at 575 http://www.ietf.org/ipr. 577 The IETF invites any interested party to bring to its attention any 578 copyrights, patents or patent applications, or other proprietary 579 rights that may cover technology that may be required to implement 580 this standard. Please address the information to the IETF at 581 ietf-ipr@ietf.org. 583 Bradford, Vasseur, and Farrel 14