RFC 8231
Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE
8. IANA Considerations
The code points described below have been allocated for the protocol elements defined in this document.8.1. PCE Capabilities in IGP Advertisements
The following bits have been registered in the "Path Computation Element (PCE) Capability Flags" subregistry of the "Open Shortest Path First (OSPF) Parameters" registry: Bit Description Reference --- ------------------------------- ------------- 11 Active stateful PCE capability This document 12 Passive stateful PCE capability This document
8.2. PCEP Messages
The following message types have been allocated within the "PCEP Messages" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry: Value Description Reference ----- ------------ ------------- 10 Report This document 11 Update This document8.3. PCEP Objects
The following object-class values and object types have been allocated within the "PCEP Objects" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry: Object-Class Value Name Reference ------------------ ---------------- ------------- 32 LSP This document Object-Type 0: Reserved 1: LSP 33 SRP This document Object-Type 0: Reserved 1: SRP
8.4. LSP Object
A new subregistry, named "LSP Object Flag Field", has been created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field of the LSP object. New values are assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability description o Defining RFC The following values are defined in this document: Bit Description Reference --- -------------------- ------------- 0-4 Unassigned This document 5-7 Operational (3 bits) This document 8 Administrative This document 9 Remove This document 10 SYNC This document 11 Delegate This document
8.5. PCEP-Error Object
The following error types and error values have been registered within the "PCEP-ERROR Object Error Types and Values" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry: Error-Type Meaning ---------- ------------------------------------------------------- 6 Mandatory Object missing Error-value 8: LSP object missing 9: ERO object missing 10: SRP object missing 11: LSP-IDENTIFIERS TLV missing 19 Invalid Operation Error-value 1: Attempted LSP Update Request for a non-delegated LSP. The PCEP-ERROR object is followed by the LSP object that identifies the LSP. 2: Attempted LSP Update Request if the stateful PCE capability was not advertised. 3: Attempted LSP Update Request for an LSP identified by an unknown PLSP-ID. 5: Attempted LSP State Report if stateful PCE capability was not advertised. 20 LSP State Synchronization Error Error-value 1: A PCE indicates to a PCC that it cannot process (an otherwise valid) LSP State Report. The PCEP-ERROR object is followed by the LSP object that identifies the LSP. 5: A PCC indicates to a PCE that it cannot complete the State Synchronization.
8.6. Notification Object
The following Notification Types and Notification Values have been allocated within the "Notification Object" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry: Notification-Type Name 4 Stateful PCE resource limit exceeded Notification-value 1: Entering resource limit exceeded state 2: Deprecated Note that the early allocation included an additional Notification Value 2 for "Exiting resource limit exceeded state". This Notification Value is no longer required and has been marked as "Deprecated".8.7. PCEP TLV Type Indicators
The following TLV Type Indicator values have been registered within the "PCEP TLV Type Indicators" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry: Value Description Reference ----- ----------------------- ------------- 16 STATEFUL-PCE-CAPABILITY This document 17 SYMBOLIC-PATH-NAME This document 18 IPV4-LSP-IDENTIFIERS This document 19 IPV6-LSP-IDENTIFIERS This document 20 LSP-ERROR-CODE This document 21 RSVP-ERROR-SPEC This document
8.8. STATEFUL-PCE-CAPABILITY TLV
A new subregistry, named "STATEFUL-PCE-CAPABILITY TLV Flag Field", has been created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field in the STATEFUL-PCE- CAPABILITY TLV of the PCEP OPEN object (class = 1). New values are assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability description o Defining RFC The following values are defined in this document: Value Description Reference ----- --------------------- ------------- 31 LSP-UPDATE-CAPABILITY This document8.9. LSP-ERROR-CODE TLV
A new subregistry, named "LSP-ERROR-CODE TLV Error Code Field", has been created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the LSP Error Code field of the LSP- ERROR-CODE TLV. This field specifies the reason for failure to update the LSP. New values are assigned by Standards Action [RFC8126]. Each value should be tracked with the following qualities: value, meaning, and defining RFC. The following values are defined in this document: Value Meaning --- ------------------------------------- 0 Reserved 1 Unknown reason 2 Limit reached for PCE-controlled LSPs 3 Too many pending LSP Update Requests 4 Unacceptable parameters 5 Internal error 6 LSP administratively brought down 7 LSP preempted 8 RSVP signaling error
9. Manageability Considerations
All manageability requirements and considerations listed in [RFC5440] apply to the PCEP extensions defined in this document. In addition, requirements and considerations listed in this section apply.9.1. Control Function and Policy
In addition to configuring specific PCEP session parameters, as specified in [RFC5440], Section 8.1, a PCE or PCC implementation MUST allow configuring the stateful PCEP capability and the LSP Update capability. A PCC implementation SHOULD allow the operator to specify multiple candidate PCEs for and a delegation preference for each candidate PCE. A PCC SHOULD allow the operator to specify an LSP delegation policy where LSPs are delegated to the most-preferred online PCE. A PCC MAY allow the operator to specify different LSP delegation policies. A PCC implementation that allows concurrent connections to multiple PCEs SHOULD allow the operator to group the PCEs by administrative domains, and it MUST NOT advertise LSP existence and state to a PCE if the LSP is delegated to a PCE in a different group. A PCC implementation SHOULD allow the operator to specify whether the PCC will advertise LSP existence and state for LSPs that are not controlled by any PCE (for example, LSPs that are statically configured at the PCC). A PCC implementation SHOULD allow the operator to specify both the Redelegation Timeout Interval and the State Timeout Interval. The default value of the Redelegation Timeout Interval SHOULD be set to 30 seconds. An operator MAY also configure a policy that will dynamically adjust the Redelegation Timeout Interval, for example setting it to zero when the PCC has an established session to a backup PCE. The default value for the State Timeout Interval SHOULD be set to 60 seconds. After the expiration of the State Timeout Interval, the LSP reverts to operator-defined default parameters. A PCC implementation MUST allow the operator to specify the default LSP parameters. To achieve a behavior where the LSP retains the parameters set by the PCE until such time that the PCC makes a change to them, a State Timeout Interval of infinity SHOULD be used. Any changes to LSP parameters SHOULD be done in a make-before-break fashion. LSP delegation is controlled by operator-defined policies on a PCC. LSPs are delegated individually -- different LSPs may be delegated to different PCEs. An LSP is delegated to at most one PCE at any given
point in time. A PCC implementation SHOULD support the delegation policy, when all PCC's LSPs are delegated to a single PCE at any given time. Conversely, the policy revoking the delegation for all PCC's LSPs SHOULD also be supported. A PCC implementation SHOULD allow the operator to specify delegation priority for PCEs. This effectively defines the primary PCE and one or more backup PCEs to which a primary PCE's LSPs can be delegated when the primary PCE fails. Policies defined for stateful PCEs and PCCs should eventually fit in the policy-enabled path computation framework defined in [RFC5394], and the framework should be extended to support stateful PCEs.9.2. Information and Data Models
The PCEP YANG module [PCEP-YANG] should include: o advertised stateful capabilities and synchronization status per PCEP session. o the delegation status of each configured LSP. The PCEP MIB [RFC7420] could also be updated to include this information.9.3. Liveness Detection and Monitoring
PCEP extensions defined in this document do not require any new mechanisms beyond those already defined in [RFC5440], Section 8.3.9.4. Verifying Correct Operation
Mechanisms defined in [RFC5440], Section 8.4 also apply to PCEP extensions defined in this document. In addition to monitoring parameters defined in [RFC5440], a stateful PCC-side PCEP implementation SHOULD provide the following parameters: o Total number of LSP Updates o Number of successful LSP Updates o Number of dropped LSP Updates o Number of LSP Updates where LSP setup failed A PCC implementation SHOULD provide a command to show for each LSP whether it is delegated, and if so, to which PCE.
A PCC implementation SHOULD allow the operator to manually revoke LSP delegation.9.5. Requirements on Other Protocols and Functional Components
PCEP extensions defined in this document do not put new requirements on other protocols.9.6. Impact on Network Operation
Mechanisms defined in [RFC5440], Section 8.6 also apply to PCEP extensions defined in this document. Additionally, a PCEP implementation SHOULD allow a limit to be placed on the number of LSPs delegated to the PCE and on the rate of PCUpd and PCRpt messages sent by a PCEP speaker and processed from a peer. It SHOULD also allow sending a notification when a rate threshold is reached. A PCC implementation SHOULD allow a limit to be placed on the rate of LSP Updates to the same LSP to avoid signaling overload discussed in Section 10.3.10. Security Considerations
10.1. Vulnerability
This document defines extensions to PCEP to enable stateful PCEs. The nature of these extensions and the delegation of path control to PCEs results in more information being available for a hypothetical adversary and a number of additional attack surfaces that must be protected. The security provisions described in [RFC5440] remain applicable to these extensions. However, because the protocol modifications outlined in this document allow the PCE to control path computation timing and sequence, the PCE defense mechanisms described in [RFC5440], Section 7.2 are also now applicable to PCC security. As a general precaution, it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [PCEPS], as per the recommendations and best current practices in [RFC7525].
The following sections identify specific security concerns that may result from the PCEP extensions outlined in this document along with recommended mechanisms to protect PCEP infrastructure against related attacks.10.2. LSP State Snooping
The stateful nature of this extension explicitly requires LSP status updates to be sent from PCC to PCE. While this gives the PCE the ability to provide more optimal computations to the PCC, it also provides an adversary with the opportunity to eavesdrop on decisions made by network systems external to PCE. This is especially true if the PCC delegates LSPs to multiple PCEs simultaneously. Adversaries may gain access to this information by eavesdropping on unsecured PCEP sessions and might then use this information in various ways to target or optimize attacks on network infrastructure, for example, by flexibly countering anti-DDoS measures being taken to protect the network or by determining choke points in the network where the greatest harm might be caused. PCC implementations that allow concurrent connections to multiple PCEs SHOULD allow the operator to group the PCEs by administrative domains, and they MUST NOT advertise LSP existence and state to a PCE if the LSP is delegated to a PCE in a different group.10.3. Malicious PCE
The LSP delegation mechanism described in this document allows a PCC to grant effective control of an LSP to the PCE for the duration of a PCEP session. While this enables PCE control of the timing and sequence of path computations within and across PCEP sessions, it also introduces a new attack vector: an attacker may flood the PCC with PCUpd messages at a rate that exceeds either the PCC's ability to process them or the network's ability to signal the changes, by either spoofing messages or compromising the PCE itself. A PCC is free to revoke an LSP delegation at any time without needing any justification. A defending PCC can do this by enqueueing the appropriate PCRpt message. As soon as that message is enqueued in the session, the PCC is free to drop any incoming PCUpd messages without additional processing.
10.4. Malicious PCC
A stateful session also results in an increased attack surface by placing a requirement for the PCE to keep an LSP state replica for each PCC. It is RECOMMENDED that PCE implementations provide a limit on resources a single PCC can occupy. A PCE implementing such a limit MUST send a PCNtf message with notification-type 4 (Stateful PCE resource limit exceeded) and notification-value 1 (Entering resource limit exceeded state) upon receiving an LSP State Report causing it to exceed this threshold. Delegation of LSPs can create further strain on PCE resources and a PCE implementation MAY preemptively give back delegations if it finds itself lacking the resources needed to effectively manage the delegation. Since the delegation state is ultimately controlled by the PCC, PCE implementations SHOULD provide throttling mechanisms to prevent strain created by flaps of either a PCEP session or an LSP delegation.11. References
11.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>. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>. [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>. [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>.
[RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP", RFC 5284, DOI 10.17487/RFC5284, August 2008, <https://www.rfc-editor.org/info/rfc5284>. [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>. [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, <https://www.rfc-editor.org/info/rfc8051>. [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>.11.2. Informative References
[MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE LSP Path Computation using Preemption", Global Information Infrastructure Symposium, DOI 10.1109/GIIS.2007.4404195, July 2007. [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "A practical algorithm for balancing the max-min fairness and throughput objectives in traffic engineering", INFOCOM, 2012 Proceedings IEEE, pp. 846-854, DOI 10.1109/INFCOM.2012.6195833, March 2012. [PCE-Init-LSP] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", Work in Progress, draft-ietf-pce-pce-initiated-lsp-10, June 2017. [PCEP-GMPLS] Margaria, C., de Dios, O., and F. Zhang, "PCEP extensions for GMPLS", Work in Progress, draft-ietf-pce-gmpls-pcep-extensions-11, October 2015.
[PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and j. jefftant@gmail.com, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, draft-ietf-pce-pcep-yang-05, June 2017. [PCEPS] Lopez, D., de Dios, O., Wu, Q., and D. Dhody, "Secure Transport for PCEP", Work in Progress, draft-ietf-pce-pceps-18, September 2017. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, DOI 10.17487/RFC2702, September 1999, <https://www.rfc-editor.org/info/rfc2702>. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>. [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., Christian, B., and W. Lai, "Applicability Statement for Traffic Engineering with MPLS", RFC 3346, DOI 10.17487/RFC3346, August 2002, <https://www.rfc-editor.org/info/rfc3346>. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>. [RFC4655] Farrel, A., Vasseur, J., 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>. [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.
[RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, DOI 10.17487/RFC5394, December 2008, <https://www.rfc-editor.org/info/rfc5394>. [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>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., and D. Dhody, "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", RFC 8232, DOI 10.17487/RFC8232, September 2017, <http://www.rfc-editor.org/info/rfc8232>.Acknowledgements
We would like to thank Adrian Farrel, Cyril Margaria, and Ramon Casellas for their contributions to this document. We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto, Paul Schultz, and Raveendra Torvi for their comments and suggestions. Thanks also to Jon Hardwick, Oscar Gonzales de Dios, Tomas Janciga, Stefan Kobza, Kexin Tang, Matej Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin Sampath, Calvin Ying, Mustapha Aissaoui, Stephane Litkowski, and Olivier Dugeon for helpful comments and discussions.
Contributors
The following people contributed substantially to the content of this document and should be considered coauthors: Xian Zhang Huawei Technology F3-5-B R&D Center Huawei Industrial Base, Bantian, Longgang District Shenzhen, Guangdong 518129 China Email: zhang.xian@huawei.com Dhruv Dhody Huawei Technology Leela Palace Bangalore, Karnataka 560008 INDIA Email: dhruv.dhody@huawei.com Siva Sivabalan Cisco Systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada Email: msiva@cisco.com
Authors' Addresses
Edward Crabbe Oracle 1501 4th Ave, suite 1800 Seattle, WA 98101 United States of America Email: edward.crabbe@oracle.com Ina Minei Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 United States of America Email: inaminei@google.com Jan Medved Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 United States of America Email: jmedved@cisco.com Robert Varga Pantheon Technologies SRO Mlynske Nivy 56 Bratislava 821 05 Slovakia Email: robert.varga@pantheon.tech