Telefonica I+D

Spain diego.r.lopez@telefonica.com

Huawei Technologies

Yuhua District 101 Software Avenue Nanjing Jiangsu 210012 China bill.wu@huawei.com

Huawei Technologies

Divyashree Techno Park, Whitefield Bangalore Karnataka 560037 India dhruv.ietf@gmail.com

Huawei Technologies

Yuhua District 101 Software Avenue Nanjing Jiangsu 210012 China maqiufang1@huawei.com

Old Dog Consulting

United Kingdom daniel@olddog.co.uk

rtg lsr Path Computation Element When 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

Introduction As 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 PCED TCP-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-TLV The 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-IS The 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).

OSPF Similarly, 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-TLV The 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-IS The 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 .

OSPF Similarly, 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 Considerations An 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 Considerations Manageability considerations for PCED are addressed in , , and .

Control of Policy and Functions A 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 Model The YANG module for PCEP supports PCEP security parameters (key, key chain, and TLS).

Liveness Detection and Monitoring Normal operations of the IGP meet the requirements for liveness detection and monitoring.

Verification of Correct Operations The 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 Components There are no new requirements on other protocols.

Impact on Network Operations Frequent 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 Considerations Security 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 Considerations

PCE Capability Flags IANA 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 Indicators The 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: .

References Normative References In 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. There 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] There 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] This 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] This 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] The 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] This 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] This 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] It 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. Many 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. RFC 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. This 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. The 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. 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. Point-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. 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. The 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 References Cisco Systems Futurewei Arrcus, 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 Progress Huawei Technologies Juniper Networks Microsoft Microsoft Work in Progress This memo describes a TCP extension to enhance security for BGP. [STANDARDS-TRACK] This 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. 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] 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] This 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. This 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. This 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 Technical Report #36

Acknowledgments The 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' Addresses Telefonica I+D

Spain diego.r.lopez@telefonica.com

Huawei Technologies

Yuhua District 101 Software Avenue Nanjing Jiangsu 210012 China bill.wu@huawei.com

Huawei Technologies

Divyashree Techno Park, Whitefield Bangalore Karnataka 560037 India dhruv.ietf@gmail.com

Huawei Technologies

Yuhua District 101 Software Avenue Nanjing Jiangsu 210012 China maqiufang1@huawei.com

Old Dog Consulting

United Kingdom daniel@olddog.co.uk