RFC 8306
Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
5. Security Considerations
As described in [RFC5862], P2MP path computation requests are more CPU-intensive and also utilize more link bandwidth. In the event of an unauthorized P2MP path computation request or a denial-of-service attack, the subsequent PCEP requests and processing may be disruptive to the network. Consequently, it is important that implementations conform to the relevant security requirements that specifically help to minimize or negate unauthorized P2MP path computation requests and denial-of-service attacks. These mechanisms include the following: o Securing the PCEP session requests and responses is RECOMMENDED using TCP security techniques such as the TCP Authentication Option (TCP-AO) [RFC5925] or using Transport Layer Security (TLS) [RFC8253], as per the recommendations and best current practices in [RFC7525]. o Authenticating the PCEP requests and responses to ensure that the message is intact and sent from an authorized node using the TCP-AO or TLS is RECOMMENDED. o Policy control could be provided by explicitly defining which PCCs are allowed to send P2MP path computation requests to the PCE via IP access lists. PCEP operates over TCP, so it is also important to secure the PCE and PCC against TCP denial-of-service attacks. As stated in [RFC6952], PCEP implementations SHOULD support the TCP-AO [RFC5925] and not use TCP MD5 because of TCP MD5's known vulnerabilities and weakness.
6. IANA Considerations
IANA maintains a registry of PCEP parameters. A number of IANA considerations have been highlighted in previous sections of this document. IANA made the allocations as per [RFC6006].6.1. PCEP TLV Type Indicators
As described in Section 3.1.2, the P2MP capability TLV allows the PCE to advertise its P2MP path computation capability. IANA had previously made an allocation from the "PCEP TLV Type Indicators" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document. Value Description Reference 6 P2MP capable RFC 83066.2. Request Parameter Bit Flags
As described in Section 3.3.1, three RP Object Flags have been defined. IANA had previously made allocations from the PCEP "RP Object Flag Field" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document. Bit Description Reference 18 Fragmentation (F-bit) RFC 8306 19 P2MP (N-bit) RFC 8306 20 ERO-compression (E-bit) RFC 83066.3. Objective Functions
As described in Section 3.6.1, this document defines two objective functions. IANA had previously made allocations from the PCEP "Objective Function" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document. Code Point Name Reference 7 SPT RFC 8306 8 MCT RFC 8306
6.4. METRIC Object-Type Values
As described in Section 3.6.2, three METRIC object T fields have been defined. IANA had previously made allocations from the PCEP "METRIC Object T Field" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document. Value Description Reference 8 P2MP IGP metric RFC 8306 9 P2MP TE metric RFC 8306 10 P2MP hop count metric RFC 83066.5. PCEP Objects
As discussed in Section 3.3.2, two END-POINTS Object-Type values are defined. IANA had previously made the Object-Type allocations from the "PCEP Objects" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document. Object-Class Value 4 Name END-POINTS Object-Type 3: IPv4 4: IPv6 5-15: Unassigned Reference RFC 8306 As described in Sections 3.2, 3.11.1, and 3.14, four PCEP Object-Class values and six PCEP Object-Type values have been defined. IANA had previously made allocations from the "PCEP Objects" subregistry, where RFC 6006 was the reference. IANA has updated the reference to point to this document.
Also, for the following four PCEP objects, codepoint 0 for the Object-Type field is marked "Reserved", as per Erratum ID 4956 for RFC 5440. IANA has updated the reference to point to this document. Object-Class Value 28 Name UNREACH-DESTINATION Object-Type 0: Reserved 1: IPv4 2: IPv6 3-15: Unassigned Reference RFC 8306 Object-Class Value 29 Name SERO Object-Type 0: Reserved 1: SERO 2-15: Unassigned Reference RFC 8306 Object-Class Value 30 Name SRRO Object-Type 0: Reserved 1: SRRO 2-15: Unassigned Reference RFC 8306 Object-Class Value 31 Name BNC Object-Type 0: Reserved 1: Branch node list 2: Non-branch node list 3-15: Unassigned Reference RFC 8306
6.6. PCEP-ERROR Objects and Types
As described in Section 3.15, a number of PCEP-ERROR Object Error-Types and Error-values have been defined. IANA had previously made allocations from the PCEP "PCEP-ERROR Object Error Types and Values" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document. Error Type Meaning Reference 5 Policy violation Error-value=7: RFC 8306 P2MP Path computation is not allowed 16 P2MP Capability Error Error-value=0: Unassigned RFC 8306 Error-value=1: RFC 8306 The PCE cannot satisfy the request due to insufficient memory Error-value=2: RFC 8306 The PCE is not capable of P2MP computation 17 P2MP END-POINTS Error Error-value=0: Unassigned RFC 8306 Error-value=1: RFC 8306 The PCE cannot satisfy the request due to no END-POINTS with leaf type 2 Error-value=2: RFC 8306 The PCE cannot satisfy the request due to no END-POINTS with leaf type 3 Error-value=3: RFC 8306 The PCE cannot satisfy the request due to no END-POINTS with leaf type 4 Error-value=4: RFC 8306 The PCE cannot satisfy the request due to inconsistent END-POINTS 18 P2MP Fragmentation Error Error-value=0: Unassigned RFC 8306 Error-value=1: RFC 8306 Fragmented request failure
6.7. PCEP NO-PATH Indicator
As discussed in Section 3.16, the NO-PATH-VECTOR TLV Flag Field has been defined. IANA had previously made an allocation from the PCEP "NO-PATH-VECTOR TLV Flag Field" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document. Bit Description Reference 24 P2MP Reachability Problem RFC 83066.8. SVEC Object Flag
As discussed in Section 3.12, two SVEC Object Flags are defined. IANA had previously made allocations from the PCEP "SVEC Object Flag Field" subregistry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document. Bit Description Reference 19 Partial Path Diverse RFC 8306 20 Link Direction Diverse RFC 83066.9. OSPF PCE Capability Flag
As discussed in Section 3.1.1, the OSPF Capability Flag is defined to indicate P2MP path computation capability. IANA had previously made an assignment from the OSPF Parameters "Path Computation Element (PCE) Capability Flags" registry, where RFC 6006 was the reference. IANA has updated the reference as follows to point to this document. Bit Description Reference 10 P2MP path computation RFC 8306
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>. [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC3473, January 2003, <https://www.rfc-editor.org/info/rfc3473>. [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, May 2007, <https://www.rfc-editor.org/info/rfc4873>. [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI 10.17487/RFC4875, May 2007, <https://www.rfc-editor.org/info/rfc4875>. [RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", RFC 5073, DOI 10.17487/RFC5073, December 2007, <https://www.rfc-editor.org/info/rfc5073>. [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, January 2008, <https://www.rfc-editor.org/info/rfc5088>. [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, January 2008, <https://www.rfc-editor.org/info/rfc5089>.
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>. [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <https://www.rfc-editor.org/info/rfc5511>. [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", RFC 5541, DOI 10.17487/RFC5541, June 2009, <https://www.rfc-editor.org/info/rfc5541>. [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, <https://www.rfc-editor.org/info/rfc7770>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.7.2. Informative References
[PCEP-YANG] Dhody, D., Ed., Hardwick, J., Beeram, V., and J. Tantsura, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, draft-ietf-pce-pcep-yang-05, July 2017. [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>. [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the Path Computation Element (PCE) to Point-to-Multipoint (P2MP) MPLS and GMPLS Traffic Engineering (TE)", RFC 5671, DOI 10.17487/RFC5671, October 2009, <https://www.rfc-editor.org/info/rfc5671>. [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE", RFC 5862, DOI 10.17487/RFC5862, June 2010, <https://www.rfc-editor.org/info/rfc5862>. [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010, <https://www.rfc-editor.org/info/rfc5925>. [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., Ali, Z., and J. Meuric, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, <https://www.rfc-editor.org/info/rfc6006>. [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, <https://www.rfc-editor.org/info/rfc6952>. [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014, <https://www.rfc-editor.org/info/rfc7420>. [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>. [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, "PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)", RFC 8253, DOI 10.17487/RFC8253, October 2017, <https://www.rfc-editor.org/info/rfc8253>.
Appendix A. Summary of Changes from RFC 6006
o Updated the text to use the term "PCC" instead of "user" while describing the encoding rules in Section 3.10. o Updated the example in Figure 7 to explicitly include the RP object. o Corrected the description of the F-bit in the RP object in Section 3.13, as per Erratum ID 3836. o Corrected the description of the fragmentation procedure for the response in Section 3.13.2, as per Erratum ID 3819. o Corrected the Error-Type for fragmentation in Section 3.15, as per Erratum ID 3830. o Updated the references for the OSPF Router Information Link State Advertisement (LSA) [RFC7770] and the PCEP MIB [RFC7420]. o Added current information and references for PCEP YANG [PCEP-YANG] and PCEPS [RFC8253]. o Updated the Security Considerations section to include the TCP-AO and TLS. o Updated the IANA Considerations section (Section 6.5) to mark codepoint 0 as "Reserved" for the Object-Type defined in this document, as per Erratum ID 4956 for [RFC5440]. IANA references have also been updated to point to this document.Appendix A.1. RBNF Changes from RFC 6006
o Updates to the RBNF for the request message format, per Erratum ID 4867: * Updated the request message to allow for the bundling of multiple path computation requests within a single PCReq message. * Added <svec-list> in PCReq messages. This object was missed in [RFC6006]. * Added the BNC object in PCReq messages. This object is required to support P2MP. The BNC object shares the same format as the IRO, but it only supports IPv4 and IPv6 prefix sub-objects.
* Updated the <RRO-List> format to also allow the SRRO. This
object was missed in [RFC6006].
* Removed the BANDWIDTH object followed by the RRO from
<RRO-List>. The BANDWIDTH object was included twice in
RFC 6006 -- once as part of <end-point-path-pair-list> and also
as part of <RRO-List>. The latter has been removed, and the
RBNF is backward compatible with [RFC5440].
* Updated the <end-point-rro-pair-list> to allow an optional
BANDWIDTH object only if <RRO-List> is included.
o Updates to the RBNF for the reply message format, per
Erratum ID 4868:
* Updated the reply message to allow for bundling of multiple
path computation replies within a single PCRep message.
* Added the UNREACH-DESTINATION object in PCRep messages. This
object was missed in [RFC6006].
Acknowledgements
The authors would like to thank Adrian Farrel, Young Lee, Dan Tappan, Autumn Liu, Huaimo Chen, Eiji Oki, Nic Neate, Suresh Babu K, Gaurav Agrawal, Vishwas Manral, Dan Romascanu, Tim Polk, Stewart Bryant, David Harrington, and Sean Turner for their valuable comments and input on this document. Thanks to Deborah Brungard for handling related errata for RFC 6006. The authors would like to thank Jonathan Hardwick and Adrian Farrel for providing review comments with suggested text for this document. Thanks to Jonathan Hardwick for being the document shepherd and for providing comments and guidance. Thanks to Ben Niven-Jenkins for RTGDIR reviews. Thanks to Roni Even for GENART reviews. Thanks to Fred Baker for the OPSDIR review. Thanks to Deborah Brungard for being the responsible AD and guiding the authors. Thanks to Mirja Kuehlewind, Alvaro Retana, Ben Campbell, Adam Roach, Benoit Claise, Suresh Krishnan, and Eric Rescorla for their IESG review and comments.
Contributors
Fabien Verhaeghe Thales Communication France 160 boulevard Valmy 92700 Colombes France Email: fabien.verhaeghe@gmail.com Tomonori Takeda NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Email: tomonori.takeda@ntt.com Zafar Ali Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada Email: zali@cisco.com Julien Meuric Orange 2, Avenue Pierre Marzin 22307 Lannion Cedex France Email: julien.meuric@orange.com Jean-Louis Le Roux Orange 2, Avenue Pierre Marzin 22307 Lannion Cedex France Email: jeanlouis.leroux@orange.com Mohamad Chaitou France Email: mohamad.chaitou@gmail.com Udayasree Palle Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: udayasreereddy@gmail.com
Authors' Addresses
Quintin Zhao Huawei Technologies 125 Nagog Technology Park Acton, MA 01719 United States of America Email: quintin.zhao@huawei.com Dhruv Dhody (editor) Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: dhruv.ietf@gmail.com Ramanjaneya Reddy Palleti Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: ramanjaneya.palleti@huawei.com Daniel King Old Dog Consulting United Kingdom Email: daniel@olddog.co.uk