Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFsWorld Map

RFC 8306

 
 
 

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

Part 3 of 3, p. 30 to 43
Prev Section

 


prevText      Top      ToC       Page 30 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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