IGP Extension for Path Computation Element Communication Protocol (PCEP) Security Capability Support in PCE Discovery (PCED)Telefonica I+DSpaindiego.r.lopez@telefonica.comHuawei TechnologiesYuhua District101 Software AvenueNanjingJiangsu210012Chinabill.wu@huawei.comHuawei TechnologiesDivyashree Techno Park, WhitefieldBangaloreKarnataka560037Indiadhruv.ietf@gmail.comHuawei TechnologiesYuhua District101 Software AvenueNanjingJiangsu210012Chinamaqiufang1@huawei.comOld Dog ConsultingUnited Kingdomdaniel@olddog.co.uk
rtg
lsrPath Computation ElementWhen a Path Computation Element (PCE) is a Label Switching Router
(LSR) or a server participating in the Interior Gateway Protocol (IGP), its
presence and path computation capabilities can be advertised using IGP
flooding. The IGP extensions
for PCE Discovery (PCED) (RFCs 5088 and 5089) define a method to
advertise path computation capabilities using IGP flooding for OSPF and
IS-IS, respectively. However, these specifications lack a method to
advertise Path Computation Element Communication Protocol (PCEP)
security (e.g., Transport Layer Security (TLS) and TCP Authentication
Option (TCP-AO)) support capability.This document defines capability flag bits for the PCE-CAP-FLAGS
sub-TLV that can be announced as an attribute in the IGP advertisement
to distribute PCEP security support information. In addition, this
document updates RFCs 5088 and 5089 to allow advertisement of a Key
ID or KEY-CHAIN-NAME sub-TLV to support TCP-AO security capability.
This document also updates RFCs 8231 and 8306.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Conventions Used in This Document
. IGP Extension for PCEP Security Capability Support
. Use of PCEP Security Capability Support for PCED
. KEY-ID Sub-TLV
. IS-IS
. OSPF
. KEY-CHAIN-NAME Sub-TLV
. IS-IS
. OSPF
. Updates to RFCs
. Backward Compatibility Considerations
. Management Considerations
. Control of Policy and Functions
. Information and Data Model
. Liveness Detection and Monitoring
. Verification of Correct Operations
. Requirements on Other Protocols and Functional Components
. Impact on Network Operations
. Security Considerations
. IANA Considerations
. PCE Capability Flags
. PCED Sub-TLV Type Indicators
. References
. Normative References
. Informative References
Acknowledgments
Authors' Addresses
IntroductionAs described in , privacy and integrity are important issues for communication using the Path Computation Element Communication
Protocol (PCEP); an attacker that intercepts a PCEP message
could obtain sensitive information
related to computed paths and resources. Authentication and integrity checks
allow the receiver of a PCEP
message to know that the message genuinely comes from the node that
purports to have sent it and whether the message has been
modified.Among the possible solutions mentioned in , Transport Layer Security (TLS) provides support for peer
authentication, message encryption, and integrity while TCP-AO)
and Cryptographic Algorithms for TCP-AO offer significantly improved security for
applications using TCP. As specified in , the PCC needs to know whether the PCE
server supports TLS or TCP-AO as a secure transport in order for a Path
Computation Client (PCC) to establish a connection with a PCE server
using TLS or TCP-AO. and define a method
to advertise path computation capabilities using IGP flooding for OSPF
and IS-IS, respectively. However, these specifications lack a method to
advertise PCEP security (e.g., TLS and TCP-AO) support capability.This document defines capability flag bits for the PCE-CAP-FLAGS
sub-TLV that can be announced as attributes in the IGP advertisement to
distribute PCEP security support information. In addition, this document
updates and to allow advertisement of a KeyID or
KEY-CHAIN-NAME sub-TLV to support TCP-AO security capability.IANA created a top-level registry titled "Path Computation Element (PCE) Capability
Flags" per . This document updates and moves it to follow the heading of the "Interior
Gateway Protocol (IGP) Parameters" registry.
states that the IS-IS PCE-CAP-FLAGS sub-TLV uses the
same registry as OSPF. This document updates to
refer to the new IGP registry. Further, this document updates where it references the registry
location as the "Open Shortest Path First v2 (OSPFv2) Parameters" registry to the
"Interior Gateway Protocol (IGP) Parameters" registry.
This document also
updates by changing the term "OSPF PCE
Capability Flag" to read as "Path Computation Element (PCE) Capability
Flags" and to note the corresponding registry now exists in the
"Interior Gateway Protocol (IGP) Parameters" registry.Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
IGP Extension for PCEP Security Capability Support defines a PCE Discovery (PCED) TLV carried
in an OSPF Router Information Link State Advertisement (LSA) as defined
in to facilitate PCED using OSPF. This
document defines two capability flag bits in the OSPF PCE Capability
Flags to indicate TCP-AO support and PCEP over TLS support
, respectively.Similarly, defines the PCED sub-TLV for use
in PCED using IS-IS.
This document will use the same flag for the OSPF PCE Capability Flags sub-TLV
to allow IS-IS to indicate TCP-AO support and PCEP
over TLS support, respectively.The IANA assignments for shared OSPF and IS-IS Security Capability
Flags are documented in of this
document.Use of PCEP Security Capability Support for PCEDTCP-AO and PCEP over TLS support flag bits are advertised using IGP
flooding.
PCE supports TCP-AO: IGP advertisement SHOULD include a TCP-AO
support flag bit.
PCE supports TLS: IGP advertisement SHOULD include PCEP over
TLS support flag bit.
If the PCE supports multiple security mechanisms, it SHOULD
include all corresponding flag bits in its IGP advertisement.A client's configuration MAY indicate that support for a given
security capability is required. If a client is configured to require
that its PCE server supports TCP-AO, the client MUST verify that the
TCP-AO flag bit in the PCE-CAP-FLAGS sub-TLV for a given server is set
before it opens a connection to that server. Similarly, if the client
is configured to require that its PCE server supports TLS, the client
MUST verify that the PCEP over TLS support flag bit in the
PCE-CAP-FLAGS sub-TLV for a given server is set before it opens a
connection to that server.KEY-ID Sub-TLVThe KEY-ID sub-TLV specifies an identifier that can be used by the
PCC to identify the TCP-AO key (referred to as "KeyID" in ).IS-ISThe KEY-ID sub-TLV MAY be present in the PCED sub-TLV carried
within the IS-IS Router CAPABILITY TLV when the capability flag bit
of the PCE-CAP-FLAGS sub-TLV in IS-IS is set to indicate TCP-AO support.The KEY-ID sub-TLV has the following format:
Type:
6
Length:
1
KeyID:
The one-octet KeyID as per to uniquely identify the
Master Key Tuple (MKT).
OSPFSimilarly, this sub-TLV MAY be present in the PCED TLV carried
within the OSPF Router Information LSA when the capability flag bit of
the PCE-CAP-FLAGS sub-TLV in OSPF is set to indicate TCP-AO support.The format of the KEY-ID sub-TLV is as follows:
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KeyID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
6
Length:
4
KeyID:
The one octet KeyID as per
to uniquely identify the MKT.
Reserved:
MUST be set to zero while sending and ignored on
receipt.
KEY-CHAIN-NAME Sub-TLVThe KEY-CHAIN-NAME sub-TLV specifies a key chain name that can be
used by the PCC to identify the key chain.
The key chain name could be manually configured
via command-line interface (CLI) or installed in the YANG datastore (see ) at the PCC.IS-ISThe KEY-CHAIN-NAME sub-TLV MAY be present in the PCED sub-TLV
carried within the IS-IS Router CAPABILITY TLV when the capability
flag bit of the PCE-CAP-FLAGS sub-TLV in IS-IS is set to indicate
TCP-AO support.The KEY-CHAIN-NAME sub-TLV has the following format:
Type:
7
Length:
Variable, encodes the length of the value field.
Key Chain Name:
The Key Chain Name contains a string of 1 to
255 octets to be used to identify the key chain. It
MUST be encoded using UTF-8. A receiving entity
MUST NOT interpret invalid UTF-8 sequences and
ignore them. This field is not NULL terminated. UTF-8 "Shortest
Form" encoding is REQUIRED to guard against the
technical issues outlined in .
OSPFSimilarly, this sub-TLV MAY be present in the PCED TLV carried
within the OSPF Router Information LSA when the capability flag bit
of the PCE-CAP-FLAGS sub-TLV in OSPF is set to indicate TCP-AO support.
The sub-TLV MUST be zero-padded so that the sub-TLV is 4-octet
aligned.The format of KEY-CHAIN-NAME sub-TLV is as follows:
1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Key Chain Name //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
7
Length:
Variable, padding is not included in the Length
field.
Key Chain Name:
The Key Chain Name contains a string of 1 to 255 octets
to be used to
identify the key chain. It MUST be encoded using UTF-8. A
receiving entity MUST NOT interpret invalid UTF-8 sequences and ignore them.
This field is not NULL terminated. UTF-8 "Shortest Form"
encoding is REQUIRED to guard against the technical issues
outlined in . The sub-TLV MUST be zero-padded so that the
sub-TLV is 4-octet aligned.
Updates to RFCs states that no new sub-TLVs
will be added to the PCED TLV and no new PCE information will be
carried in the Router Information LSA. This document updates by allowing the two sub-TLVs defined in this document
to be carried in the PCED TLV advertised in the Router Information
LSA. states that no new sub-TLVs
will be added to the PCED TLV and no new PCE information will be
carried in the Router CAPABILITY TLV. This document updates by allowing the two sub-TLVs defined in this document
to be carried in the PCED TLV advertised in the Router CAPABILITY
TLV.This introduction of additional sub-TLVs should be viewed as an
exception to the policies in and , which is justified by the requirement
to discover the PCEP security support prior to establishing a PCEP
session. The restrictions defined in and should still be
considered to be in place. If new advertisements are required in the future,
alternative mechanisms such as using or
should be considered.The registry for the PCE Capability Flags assigned in , , , , and has changed to the
IGP Parameters "Path Computation Element (PCE) Capability Flags"
registry created in this document.Backward Compatibility ConsiderationsAn LSR that does not support the IGP PCE capability bits specified in
this document silently ignores those bits.An LSR that does not support the KEY-ID and KEY-CHAIN-NAME sub-TLVs
specified in this document silently ignores those sub-TLVs.IGP extensions defined in this document do not introduce any new
interoperability issues.Management ConsiderationsManageability considerations for PCED are addressed in , , and .Control of Policy and FunctionsA PCE implementation SHOULD allow the following
parameters to be configured on the PCE:
support for TCP-AO
the KeyID used by TCP-AO
Key Chain Name
support for TLS
Information and Data ModelThe YANG module for PCEP supports PCEP security parameters (key, key chain, and TLS).Liveness Detection and MonitoringNormal operations of the IGP meet the requirements for liveness detection and monitoring.Verification of Correct OperationsThe correlation of PCEP security information advertised against information
received can be achieved by comparing the information in the PCED
sub-TLV received by the PCC with that stored at the PCE using the
PCEP YANG.Requirements on Other Protocols and Functional ComponentsThere are no new requirements on other protocols.Impact on Network OperationsFrequent changes in PCEP security information advertised in the
PCED sub-TLV may have a significant impact on IGP and might
destabilize the operation of the network by causing the PCCs to
reconnect sessions with PCEs. , , and list techniques that are applicable to this
document as well.Security ConsiderationsSecurity considerations as specified by and
are applicable to this document.As described in , a PCEP speaker MUST
support TCP MD5 , so no capability advertisement is needed to
indicate support. However, as noted in , TCP MD5 has been
obsoleted by TCP-AO because of security concerns. TCP-AO is not widely implemented; therefore, it is RECOMMENDED
that PCEP be secured using TLS per (which updates ).
An implementation SHOULD offer at least one of the two
security capabilities defined in this document.The information related to PCEP security is sensitive and due care
needs to be taken by the operator. This document defines new capability
bits that are susceptible to a downgrade attack by setting them to zero.
The content of the Key-ID or KEY-CHAIN-NAME sub-TLV can be altered to enable
an on-path attack. Thus, before advertising the PCEP security parameters by using the
mechanism described in this document, the IGP MUST be known to provide
authentication and integrity for the PCED TLV using the mechanisms
defined in , , or .Moreover, as stated in the security considerations of and
, there are no mechanisms defined in OSPF or IS-IS to protect
the confidentiality of the PCED TLV.
For this reason, the operator must
ensure that no private data is carried in the TLV. For example, the operator must ensure that KeyIDs or
key chain names do not reveal sensitive information about the
network.IANA ConsiderationsPCE Capability FlagsIANA has moved the "Path Computation Element (PCE)
Capability Flags" registry from the "Open Shortest Path First v2
(OSPFv2) Parameters" grouping to the "Interior Gateway Protocol (IGP)
Parameters" grouping.IANA has made the following additional assignments from
the "Path Computation Element (PCE) Capability Flags" registry:
Path Computation Element (PCE) Capability Flags Registrations
Bit
Capability Description
Reference
17
TCP-AO Support
RFC 9353
18
PCEP over TLS support
RFC 9353
The grouping is located at:
.PCED Sub-TLV Type IndicatorsThe PCED sub-TLVs are defined in and
, but a corresponding IANA registry was not created.
IANA has created a new registry called "PCE Discovery (PCED)
Sub-TLV Type Indicators" under the "Interior Gateway Protocol (IGP)
Parameters" registry. The registration policy for this registry is
"Standards Action" . Values in this registry come from the range
0-65535.This registry is initially populated as follows:
Initial Contents of the PCED Sub-TLV Type Indicators Registry
Value
Description
Reference
0
Reserved
RFC 9353, RFC 5088
1
PCE-ADDRESS
RFC 9353, RFC 5088
2
PATH-SCOPE
RFC 9353, RFC 5088
3
PCE-DOMAIN
RFC 9353, RFC 5088
4
NEIG-PCE-DOMAIN
RFC 9353, RFC 5088
5
PCE-CAP-FLAGS
RFC 9353, RFC 5088
6
KEY-ID
RFC 9353
7
KEY-CHAIN-NAME
RFC 9353
This registry is used by both the OSPF PCED TLV and the IS-IS PCED
sub-TLV.This grouping is located at:
.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.OSPF Protocol Extensions for Path Computation Element (PCE) DiscoveryThere are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Open Shortest Path First (OSPF) routing protocol for the advertisement of PCE Discovery information within an OSPF area or within the entire OSPF routing domain. [STANDARDS-TRACK]IS-IS Protocol Extensions for Path Computation Element (PCE) DiscoveryThere are various circumstances where it is highly desirable for a Path Computation Client (PCC) to be able to dynamically and automatically discover a set of Path Computation Elements (PCEs), along with information that can be used by the PCC for PCE selection. When the PCE is a Label Switching Router (LSR) participating in the Interior Gateway Protocol (IGP), or even a server participating passively in the IGP, a simple and efficient way to announce PCEs consists of using IGP flooding. For that purpose, this document defines extensions to the Intermediate System to Intermediate System (IS-IS) routing protocol for the advertisement of PCE Discovery information within an IS-IS area or within the entire IS-IS routing domain. [STANDARDS-TRACK]IS-IS Cryptographic AuthenticationThis document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567.This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. [STANDARDS-TRACK]IS-IS Generic Cryptographic AuthenticationThis document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK]Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent OptimizationThe Path Computation Element Communication Protocol (PCEP) allows Path Computation Clients (PCCs) to request path computations from Path Computation Elements (PCEs), and lets the PCEs return responses. When computing or reoptimizing the routes of a set of Traffic Engineering Label Switched Paths (TE LSPs) through a network, it may be advantageous to perform bulk path computations in order to avoid blocking problems and to achieve more optimal network-wide solutions. Such bulk optimization is termed Global Concurrent Optimization (GCO). A GCO is able to simultaneously consider the entire topology of the network and the complete set of existing TE LSPs, and their respective constraints, and look to optimize or reoptimize the entire network to satisfy all constraints for all TE LSPs. A GCO may also be applied to some subset of the TE LSPs in a network. The GCO application is primarily a Network Management System (NMS) solution.This document provides application-specific requirements and the PCEP extensions in support of GCO applications. [STANDARDS-TRACK]OSPFv2 HMAC-SHA Cryptographic AuthenticationThis document describes how the National Institute of Standards and Technology (NIST) Secure Hash Standard family of algorithms can be used with OSPF version 2's built-in, cryptographic authentication mechanism. This updates, but does not supercede, the cryptographic authentication mechanism specified in RFC 2328. [STANDARDS-TRACK]The TCP Authentication OptionThis document specifies the TCP Authentication Option (TCP-AO), which obsoletes the TCP MD5 Signature option of RFC 2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs), protects against replays even for long-lived TCP connections, and provides more details on the association of security with TCP connections than TCP MD5. TCP-AO is compatible with either a static Master Key Tuple (MKT) configuration or an external, out-of-band MKT management mechanism; in either case, TCP-AO also protects connections when using the same MKT across repeated instances of a connection, using traffic keys derived from the MKT, and coordinates MKT changes between endpoints. The result is intended to support current infrastructure uses of TCP MD5, such as to protect long-lived connections (as used, e.g., in BGP and LDP), and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a different option identifier than TCP MD5, even though TCP-AO and TCP MD5 are never permitted to be used simultaneously. TCP-AO supports IPv6, and is fully compatible with the proposed requirements for the replacement of TCP MD5. [STANDARDS-TRACK]Extensions to OSPF for Advertising Optional Router CapabilitiesIt is useful for routers in an OSPFv2 or OSPFv3 routing domain to know the capabilities of their neighbors and other routers in the routing domain. This document proposes extensions to OSPFv2 and OSPFv3 for advertising optional router capabilities. The Router Information (RI) Link State Advertisement (LSA) is defined for this purpose. In OSPFv2, the RI LSA will be implemented with an Opaque LSA type ID. In OSPFv3, the RI LSA will be implemented with a unique LSA type function code. In both protocols, the RI LSA can be advertised at any of the defined flooding scopes (link, area, or autonomous system (AS)). This document obsoletes RFC 4970 by providing a revised specification that includes support for advertisement of multiple instances of the RI LSA and a TLV for functional capabilities.Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.This is the third edition of this document; it obsoletes RFC 5226.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.YANG Data Model for Key ChainsThis document describes the key chain YANG data model. Key chains are commonly used for routing protocol authentication and other applications requiring symmetric keys. A key chain is a list containing one or more elements containing a Key ID, key string, send/accept lifetimes, and the associated authentication or encryption algorithm. By properly overlapping the send and accept lifetimes of multiple key chain elements, key strings and algorithms may be gracefully updated. By representing them in a YANG data model, key distribution can be automated.Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCEThe Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests.Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP.PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP.This document updates RFC 5440 in regards to the PCEP initialization phase procedures.Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched PathsPoint-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first need to be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point-to-multipoint (P2MP) TE LSPs.This document describes extensions to the PCE Communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs.This document obsoletes RFC 6006.Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE Label Switched Paths (LSPs). This document provides extensions required for the Path Computation Element Communication Protocol (PCEP) so as to enable the usage of a stateful PCE capability in supporting P2MP TE LSPs.Path Computation Element Communication Protocol (PCEP) Extension for Flow SpecificationThe Path Computation Element (PCE) is a functional component capable of selecting paths through a traffic engineering (TE) network. These paths may be supplied in response to requests for computation or may be unsolicited requests issued by the PCE to network elements. Both approaches use the PCE Communication Protocol (PCEP) to convey the details of the computed path.Traffic flows may be categorized and described using "Flow Specifications". RFC 8955 defines the Flow Specification and describes how Flow Specification components are used to describe traffic flows. RFC 8955 also defines how Flow Specifications may be distributed in BGP to allow specific traffic flows to be associated with routes.This document specifies a set of extensions to PCEP to support dissemination of Flow Specifications. This allows a PCE to indicate what traffic should be placed on each path that it is aware of.The extensions defined in this document include the creation, update, and withdrawal of Flow Specifications via PCEP and can be applied to tunnels initiated by the PCE or to tunnels where control is delegated to the PCE by the Path Computation Client (PCC). Furthermore, a PCC requesting a new path can include Flow Specifications in the request to indicate the purpose of the tunnel allowing the PCE to factor this into the path computation.Informative ReferencesOSPF-GT (Generalized Transport)Cisco SystemsFutureweiArrcus, Inc.Cisco Systems OSPFv2 and OSPFv3 include a reliable flooding mechanism to
disseminate routing topology and Traffic Engineering (TE) information
within a routing domain. Given the effectiveness of these
mechanisms, it is advantageous to use the same mechanism for
dissemination of other types of information within the domain.
However, burdening OSPF with this additional information will impact
intra-domain routing convergence and possibly jeopardize the
stability of the OSPF routing domain. This document presents
mechanisms to advertise this non-routing information in separate OSPF
Generalized Transport (OSPF-GT) instances.
OSPF-GT is not constrained to the semantics as traditional OSPF.
OSPF-GT neighbors are not required to be directly attached since they
are never used to compute hop-by-hop routing. Consequently,
independent sparse topologies can be defined to dissemenate non-
routing information only to those OSPF-GT routers requiring it.
Work in ProgressA YANG Data Model for Path Computation Element Communications Protocol (PCEP)Huawei TechnologiesJuniper NetworksMicrosoftMicrosoftWork in ProgressProtection of BGP Sessions via the TCP MD5 Signature OptionThis memo describes a TCP extension to enhance security for BGP. [STANDARDS-TRACK]Requirements for Path Computation Element (PCE) DiscoveryThis document presents a set of requirements for a Path Computation Element (PCE) discovery mechanism that would allow a Path Computation Client (PCC) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection. It is intended that solutions that specify procedures and protocols or extensions to existing protocols for such PCE discovery satisfy these requirements. This memo provides information for the Internet community.Path Computation Element (PCE) Communication Protocol (PCEP)This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK]Cryptographic Algorithms for the TCP Authentication Option (TCP-AO)The TCP Authentication Option (TCP-AO) relies on security algorithms to provide authentication between two end-points. There are many such algorithms available, and two TCP-AO systems cannot interoperate unless they are using the same algorithms. This document specifies the algorithms and attributes that can be used in TCP-AO's current manual keying mechanism and provides the interface for future message authentication codes (MACs). [STANDARDS-TRACK]Advertising Generic Information in IS-ISThis document describes the manner in which generic application information (i.e., information not directly related to the operation of the Intermediate System to Intermediate System (IS-IS) protocol) should be advertised in IS-IS Link State Protocol Data Units (LSPs) and defines guidelines that should be used when flooding such information.Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design GuideThis document analyzes TCP-based routing protocols, the Border Gateway Protocol (BGP), the Label Distribution Protocol (LDP), the Path Computation Element Communication Protocol (PCEP), and the Multicast Source Distribution Protocol (MSDP), according to guidelines set forth in Section 4.2 of "Keying and Authentication for Routing Protocols Design Guidelines", RFC 6518.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Unicode Security ConsiderationsUnicode Technical Report #36AcknowledgmentsThe authors of this document would like to thank , , , ,
, , and
for the review and comments.The authors would also like to give special thanks to for his major contributions to the initial
draft version.Thanks to for providing an
excellent AD review. Thanks to ,
, ,
and for directorate reviews.
Thanks to , , ,
, ,
, and for IESG reviews.Authors' AddressesTelefonica I+DSpaindiego.r.lopez@telefonica.comHuawei TechnologiesYuhua District101 Software AvenueNanjingJiangsu210012Chinabill.wu@huawei.comHuawei TechnologiesDivyashree Techno Park, WhitefieldBangaloreKarnataka560037Indiadhruv.ietf@gmail.comHuawei TechnologiesYuhua District101 Software AvenueNanjingJiangsu210012Chinamaqiufang1@huawei.comOld Dog ConsultingUnited Kingdomdaniel@olddog.co.uk