Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8306

Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths

Pages: 43
Proposed Standard
Errata
Obsoletes:  6006
Part 3 of 3 – Pages 30 to 43
First   Prev   None

Top   ToC   RFC8306 - Page 30   prevText

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.
Top   ToC   RFC8306 - Page 31

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 8306

6.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 8306

6.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
Top   ToC   RFC8306 - Page 32

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 8306

6.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.
Top   ToC   RFC8306 - Page 33
   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
Top   ToC   RFC8306 - Page 34

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
Top   ToC   RFC8306 - Page 35

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 8306

6.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 8306

6.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
Top   ToC   RFC8306 - Page 36

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>.
Top   ToC   RFC8306 - Page 37
   [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>.
Top   ToC   RFC8306 - Page 38
   [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>.
Top   ToC   RFC8306 - Page 39

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.
Top   ToC   RFC8306 - Page 40
      *  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].
Top   ToC   RFC8306 - Page 41

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.
Top   ToC   RFC8306 - Page 42

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
Top   ToC   RFC8306 - Page 43

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