<?xml version="1.0" encoding="UTF-8"?> <!--edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)[CS] updated byDaniel M Kohn (private)Chris 11/07/22 --> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYrfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="std" consensus="true" docName="draft-ietf-lsr-pce-discovery-security-support-13" number="9353" ipr="trust200902"updates="5088,5089,8231,8306">updates="5088,5089,8231,8306" obsoletes="" tocInclude="true" sortRefs="true" symRefs="true" xml:lang="en" version="3"> <!-- xml2rfc v2v3 conversion 3.15.0 --> <front> <title abbrev="IGPExt forExtension: PCEP SecurityDiscovery">IGP extensionin PCED">IGP Extension forPCEP security capability supportPath Computation Element Communication Protocol (PCEP) Security Capability Support in PCEdiscovery</title>Discovery (PCED)</title> <seriesInfo name="RFC" value="9353"/> <author fullname="Diego R. Lopez " initials="D" surname="Lopez"> <organization>Telefonica I+D</organization> <address> <postal><street/> <city/> <region/> <code/><country>Spain</country> </postal> <email>diego.r.lopez@telefonica.com</email> </address> </author> <author fullname="Qin Wu" initials="Q." surname="Wu"> <organization abbrev="Huawei">Huawei Technologies</organization> <address> <postal> <extaddr>Yuhua District</extaddr> <street>101 SoftwareAvenue, Yuhua District</street>Avenue</street> <city>Nanjing</city> <region>Jiangsu</region> <code>210012</code> <country>China</country> </postal> <email>bill.wu@huawei.com</email> </address> </author> <author fullname="Dhruv Dhody" initials="D." surname="Dhody"> <organization abbrev="Huawei">Huawei Technologies</organization> <address> <postal><street>Divyashree<extaddr>Divyashree Techno Park,Whitefield</street>Whitefield</extaddr> <city>Bangalore</city> <region>Karnataka</region> <code>560037</code> <country>India</country> </postal> <email>dhruv.ietf@gmail.com</email> </address> </author> <author fullname="Qiufang Ma" initials="Q." surname="Ma"><organization>Huawei</organization><organization abbrev="Huawei">Huawei Technologies</organization> <address> <postal> <extaddr>Yuhua District</extaddr> <street>101 SoftwareAvenue, Yuhua District</street>Avenue</street> <city>Nanjing</city> <region>Jiangsu</region> <code>210012</code> <country>China</country> </postal> <email>maqiufang1@huawei.com</email> </address> </author> <author fullname="Daniel King" initials="D" surname="King"> <organization>Old Dog Consulting</organization> <address> <postal><street/> <city/> <region/> <code/> <country>UK</country><country>United Kingdom</country> </postal> <email>daniel@olddog.co.uk</email> </address> </author> <dateyear="2022"/> <area>Routing Area</area> <workgroup>PCE working group</workgroup> <keyword>RFC</keyword> <keyword>Request for Comments</keyword> <keyword>I-D</keyword> <keyword>Internet-Draft</keyword>year="2023" month="January" /> <area>rtg</area> <workgroup>lsr</workgroup> <keyword>Path Computation Element</keyword> <abstract> <t>When a Path Computation Element (PCE) is a Label Switching Router (LSR) or a server participating in the Interior Gateway Protocol (IGP),or even a server participating in the IGP,its presence and path computation capabilities can be advertised using IGP flooding. The IGP extensions for PCEdiscovery (RFCDiscovery (PCED) (RFCs 5088 andRFC5089) define a method to advertise path computation capabilities using IGP flooding for OSPF andIS-ISIS-IS, respectively.HoweverHowever, these specifications lack a method to advertisePCEPath Computation Element Communication Protocol (PCEP) security (e.g., Transport Layer Security(TLS),(TLS) and TCP Authentication Option (TCP-AO)) support capability.</t> <t>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 updatesRFCRFCs 5088 andRFC5089 to allow advertisement of a Key ID orKey Chain Name Sub-TLVKEY-CHAIN-NAME sub-TLV to support TCP-AO security capability.Further, thisThis document also updatesRFCRFCs 8231 andRFC8306.</t> </abstract> </front> <middle> <section anchor="intro"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>As described in <xreftarget="RFC5440"/>, Path Computation Element Communication Protocol (PCEP) communicationtarget="RFC5440" format="default"/>, privacy and integrity are importantissues, asissues 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 andto knowwhether the message has been modified.</t> <t>Among the possible solutions mentioned inthat document,<xref target="RFC5440" format="default"/>, Transport Layer Security (TLS) <xreftarget="RFC8446"/>target="RFC8446" format="default"/> provides support for peer authentication,andmessageencryptionencryption, and integrity whileTCP Authentication Option (TCP-AO)TCP-AO) <xreftarget="RFC5925"/>target="RFC5925" format="default"/> and Cryptographic Algorithms for TCP-AO <xreftarget="RFC5926"/>target="RFC5926" format="default"/> offer significantly improved security for applications using TCP. As specified insection 4 of<xreftarget="RFC8253"/>,target="RFC8253" sectionFormat="of" section="4"/>, 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 orTCP-AO, the PCC needs to know whether PCE server supports TLS or TCP-AO as a secure transport.</t>TCP-AO.</t> <t><xreftarget="RFC5088"/>target="RFC5088" format="default"/> and <xreftarget="RFC5089"/>target="RFC5089" format="default"/> define a method to advertise path computation capabilities using IGP flooding for OSPF andIS-ISIS-IS, respectively. However, these specifications lack a method to advertise PCEP security (e.g.,TLS)TLS and TCP-AO) support capability.</t> <t>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 <xreftarget="RFC5088"/>target="RFC5088" format="default"/> and <xreftarget="RFC5089"/>target="RFC5089" format="default"/> to allow advertisement of aKey IDKeyID orKey Chain Name Sub-TLVKEY-CHAIN-NAME sub-TLV to support TCP-AO security capability.</t><t>As per <xref target="RFC5088"/>, the IANA<t>IANA created a top-levelOSPF registry, theregistry titled "Path Computation Element (PCE) Capability Flags"registry.per <xref target="RFC5088" format="default"/>. This document updates <xreftarget="RFC5088"/>target="RFC5088" format="default"/> and movesthe registryit to follow the heading of the "Interior Gateway Protocol (IGP)Parameters".Parameters" registry. <xreftarget="RFC5089"/>target="RFC5089" format="default"/> states that the IS-IS PCE-CAP-FLAGS sub-TLV uses the same registry as OSPF. This document updates <xreftarget="RFC5089"/>target="RFC5089" format="default"/> to refer to the new IGP registry. Further, this document updates <xreftarget="RFC8231"/>target="RFC8231" format="default"/> where it references the registry location as the "Open Shortest Path First(OSPF)v2 (OSPFv2) Parameters" registry to the "Interior Gateway Protocol (IGP) Parameters" registry. This document also updates[RFC8306] where it uses<xref target="RFC8306" format="default"/> by changing the term "OSPF PCE Capability Flag"and request assignment from OSPF Parameters registry with "PCEto read as "Path Computation Element (PCE) CapabilityFlag"Flags" and to note theIGP Parameterscorresponding registry now exists in the "Interior Gateway Protocol (IGP) Parameters" registry.</t> <aside> <t>Note that <xreftarget="RFC5557"/>target="RFC5557" format="default"/> uses the term "OSPF registry" instead of the "IGPregistry"registry", whereas <xreftarget="RFC8623"/>target="RFC8623" format="default"/> and <xreftarget="RFC9168"/> usestarget="RFC9168" format="default"/> use the term "OSPF Parameters" instead of "IGPParameters".</t>Parameters".</t></aside> <aside> <t>Note that the PCEP Open message exchange is another way to discover PCE capabilitiesinformation, butinformation; however, in this instance, theTCP security relatedTCP-security-related key parameters need to be known before the PCEP session is established and the PCEP Open messages are exchanged. Thus, theuse of theIGP advertisement and flooding mechanisms need to be leveraged for PCE discovery and capabilitiesadvertisement of the IGP needs to be leveraged.</t>advertisement. </t></aside> </section> <sectiontitle="Conventions usednumbered="true" toc="default"> <name>Conventions Used inthis document"> <t>TheThis Document</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <sectiontitle="IGP extensionnumbered="true" toc="default"> <name>IGP Extension for PCEPsecurity capability support">Security Capability Support</name> <t><xreftarget="RFC5088"/>target="RFC5088" format="default"/> defines a PCE Discovery (PCED) TLV carried in an OSPF Router Information Link State Advertisement (LSA) as defined in <xreftarget="RFC7770"/>target="RFC7770" format="default"/> to facilitatePCE discoveryPCED using OSPF. This document defines two capability flag bits in the OSPF PCE Capability Flags to indicateTCP Authentication Option (TCP-AO)TCP-AO support <xreftarget="RFC5925"/><xref target="RFC5926"/>target="RFC5925" format="default"/> <xref target="RFC5926" format="default"/> and PCEP over TLS support <xreftarget="RFC8253"/>target="RFC8253" format="default"/>, respectively.</t> <t>Similarly, <xreftarget="RFC5089"/>target="RFC5089" format="default"/> defines the PCED sub-TLV for use inPCE discoveryPCED using IS-IS. This document will use the same flag for the OSPF PCE Capability Flags sub-TLV to allow IS-IS to indicateTCP Authentication Option (TCP-AO) support,TCP-AO support and PCEP over TLSsupportsupport, respectively.</t> <t>The IANA assignments for shared OSPF and IS-IS Security Capability Flags are documented in <xreftarget="cap"/> ("PCE Capability Flags")target="cap" format="default"/> of this document.</t> <sectiontitle="Usenumbered="true" toc="default"> <name>Use of PCEPsecurity capability supportSecurity Capability Support forPCE discovery"> <t>TCP-AO,PCED</name> <t>TCP-AO and PCEP over TLS support flag bits are advertised using IGP flooding.<list style="symbols"> <t>PCE</t> <ul spacing="normal"> <li>PCE supports TCP-AO: IGP advertisementSHOULD<bcp14>SHOULD</bcp14> include a TCP-AO support flagbit.</t> <t>PCEbit.</li> <li>PCE supports TLS: IGP advertisementSHOULD<bcp14>SHOULD</bcp14> include PCEP over TLS support flagbit.</t> </list>Ifbit.</li> </ul> <t>If the PCE supports multiple security mechanisms, itSHOULD<bcp14>SHOULD</bcp14> include all corresponding flag bits in its IGP advertisement.</t> <t>A client's configurationMAY<bcp14>MAY</bcp14> 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 clientMUST<bcp14>MUST</bcp14> 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 clientMUST<bcp14>MUST</bcp14> 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.</t> </section> <section anchor="keyid"title="KEY-ID Sub-TLV">numbered="true" toc="default"> <name>KEY-ID Sub-TLV</name> <t>The KEY-ID sub-TLV specifies an identifier that can be used by the PCC to identify the TCP-AO key<xref target="RFC5925"/>(referred to asKeyID).</t>"KeyID" in <xref target="RFC5925" format="default"/>).</t> <section anchor="keyid-isis"title="IS-IS">numbered="true" toc="default"> <name>IS-IS</name> <t>The KEY-ID sub-TLVMAY<bcp14>MAY</bcp14> 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 indicateTCP Authentication Option (TCP-AO)TCP-AO support.</t> <t>The KEY-ID sub-TLV has the followingformat:<list> <t>Type: 6</t> <t>Length: 1</t> <t>KeyID: The one octet Key IDformat:</t> <dl newline="false" spacing="normal"> <dt>Type:</dt><dd>6</dd> <dt>Length:</dt><dd>1</dd> <dt>KeyID:</dt><dd>The one-octet KeyID as per <xreftarget="RFC5925"/>target="RFC5925" format="default"/> to uniquely identify the Master Key Tuple(MKT).</t> </list></t>(MKT).</dd> </dl> </section> <section anchor="keyid-ospf"title="OSPF">numbered="true" toc="default"> <name>OSPF</name> <t>Similarly, this sub-TLVMAY<bcp14>MAY</bcp14> 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.</t> <t>The format of the KEY-ID sub-TLV is asfollows:<figure> <artwork>follows:</t> <artwork name="" type="" align="left" alt=""><![CDATA[ 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 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure><list> <t>Type: 6</t> <t>Length: 4</t> <t>KeyID: The+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> <dl newline="false" spacing="normal"> <dt>Type:</dt><dd>6</dd> <dt>Length:</dt><dd>4</dd> <dt>KeyID:</dt><dd>The one octetKey IDKeyID as per <xreftarget="RFC5925"/>target="RFC5925" format="default"/> to uniquely identify theMaster Key Tuple (MKT).</t> <t>Reserved: MUSTMKT.</dd> <dt>Reserved:</dt><dd><bcp14>MUST</bcp14> be set to zero while sending and ignored onreceipt.</t> </list></t>receipt.</dd> </dl> </section> </section> <section anchor="keyname"title="KEY-CHAIN-NAME Sub-TLV">numbered="true" toc="default"> <name>KEY-CHAIN-NAME Sub-TLV</name> <t>The KEY-CHAIN-NAME sub-TLV specifies akeychainkey chain name that can be used by the PCC to identify thekeychain.key chain. Thekeychainkey chain name could be manually configured viaCLIcommand-line interface (CLI) or installed in the YANG datastore (see <xreftarget="RFC8177"/>)target="RFC8177" format="default"/>) at the PCC.</t> <section anchor="keyname-ISIS"title="IS-IS">numbered="true" toc="default"> <name>IS-IS</name> <t>The KEY-CHAIN-NAME sub-TLVMAY<bcp14>MAY</bcp14> 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 indicateTCP Authentication Option (TCP-AO)TCP-AO support.</t> <t>The KEY-CHAIN-NAME sub-TLV has the followingformat:<list> <t>Type: 7</t> <t>Length: Variable,format:</t> <dl newline="false" spacing="normal"> <dt>Type:</dt><dd>7</dd> <dt>Length:</dt><dd>Variable, encodes the length of the valuefield.</t> <t>Key Name: Thefield.</dd> <dt>Key Chain Name:</dt><dd>The Key Chain Name contains a string of 1 to 255 octets to be used to identify the key chain. ItMUST<bcp14>MUST</bcp14> be encoded using UTF-8. A receiving entityMUST NOT<bcp14>MUST NOT</bcp14> interpret invalid UTF-8 sequences and ignore them. This field is not NULL terminated. UTF-8 "Shortest Form" encoding isREQUIRED<bcp14>REQUIRED</bcp14> to guard against the technical issues outlined in <xreftarget="UTR36"/>.</t> </list></t>target="UTR36" format="default"/>.</dd> </dl> </section> <section anchor="keyname-ospf"title="OSPF">numbered="true" toc="default"> <name>OSPF</name> <t>Similarly, this sub-TLVMAY<bcp14>MAY</bcp14> 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-TLVMUST<bcp14>MUST</bcp14> be zero-padded so that the sub-TLV is 4-octet aligned.</t> <t>The format of KEY-CHAIN-NAME sub-TLV is asfollows:<figure> <artwork>follows:</t> <artwork name="" type="" align="left" alt=""><![CDATA[ 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 // | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ </artwork> </figure><list> <t>Type: 7</t> <t>Length: Variable,+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork> <dl newline="false" spacing="normal"> <dt>Type:</dt><dd>7</dd> <dt>Length:</dt><dd>Variable, padding is not included in the Lengthfield</t> <t>Key Name: Thefield.</dd> <dt>Key Chain Name:</dt><dd>The Key Chain Name contains a string of 1 to 255 octets to be used to identify the key chain. ItMUST<bcp14>MUST</bcp14> be encoded using UTF-8. A receiving entityMUST NOT<bcp14>MUST NOT</bcp14> interpret invalid UTF-8 sequences and ignore them. This field is not NULL terminated. UTF-8 "Shortest Form" encoding isREQUIRED<bcp14>REQUIRED</bcp14> to guard against the technical issues outlined in <xreftarget="UTR36"/>.target="UTR36" format="default"/>. The sub-TLVMUST<bcp14>MUST</bcp14> be zero-padded so that the sub-TLV is 4-octetaligned.</t> </list></t>aligned.</dd> </dl> </section> </section> </section> <sectiontitle="Updatenumbered="true" toc="default"> <name>Updates toRFCs"> <t>Section 4 of <xref target="RFC5088"/>RFCs</name> <t><xref target="RFC5088" sectionFormat="of" section="4"/> states that no new sub-TLVs will be added to the PCEDTLV,TLV and no new PCE information will be carried in the Router Information LSA. This document updates <xreftarget="RFC5088"/>target="RFC5088" format="default"/> by allowing the two sub-TLVs defined in this document to be carried in the PCED TLV advertised in the Router Information LSA.</t><t>Section 4 of <xref target="RFC5089"/><t><xref target="RFC5089" sectionFormat="of" section="4"/> states that no new sub-TLVs will be added to the PCEDTLV,TLV and no new PCE information will be carried in the RouterCAPABLITYCAPABILITY TLV. This document updates <xreftarget="RFC5089"/>target="RFC5089" format="default"/> by allowing the two sub-TLVs defined in this document to be carried in the PCED TLV advertised in the Router CAPABILITY TLV.</t> <t>This introduction of additional sub-TLVs should be viewed as an exception to the policies in <xreftarget="RFC5088"/><xref target="RFC5089"/> policy,target="RFC5088" format="default"/> and <xref target="RFC5089" format="default"/>, which is justified by the requirement to discover the PCEP security support prior to establishing a PCEP session. The restrictions defined in <xreftarget="RFC5088"/><xref target="RFC5089"/>target="RFC5088" format="default"/> and <xref target="RFC5089" format="default"/> should still be considered to be in place. Ifin the futurenew advertisements arerequired,required in the future, alternative mechanisms such as using <xreftarget="RFC6823"/>target="RFC6823" format="default"/> or <xreftarget="I-D.ietf-lsr-ospf-transport-instance"/>target="I-D.ietf-lsr-ospf-transport-instance" format="default"/> should be considered.</t> <t>The registry for the PCE Capability Flags assigned insection 8.3 of <xref target="RFC5557"/>, section 8.1 of <xref target="RFC8231"/>, section 6.9 of<xreftarget="RFC8306"/>, section 11.1 of <xref target="RFC8623"/>, and section 10.5 of <xref target="RFC9168"/>target="RFC5557" sectionFormat="of" section="8.3"/>, <xref target="RFC8231" sectionFormat="of" section="8.1"/>, <xref target="RFC8306" sectionFormat="of" section="6.9"/>, <xref target="RFC8623" sectionFormat="of" section="11.1"/>, and <xref target="RFC9168" sectionFormat="of" section="10.5"/> has changed to the IGP Parameters "Path Computation Element (PCE) Capability Flags" registry created in this document.</t> </section> <sectiontitle="Backwardnumbered="true" toc="default"> <name>Backward CompatibilityConsiderations">Considerations</name> <t>An LSR that does not support the IGP PCE capability bits specified in this document silently ignores those bits.</t> <t>An LSR that does not support the KEY-ID and KEY-CHAIN-NAME sub-TLVs specified in this document silently ignoresthesethose sub-TLVs.</t> <t>IGP extensions defined in this document do not introduce any new interoperability issues.</t> </section> <sectiontitle="Management Considerations">numbered="true" toc="default"> <name>Management Considerations</name> <t>Manageability considerations forPCE DiscoveryPCED are addressed inSection 4.10 of <xref target="RFC4674"/> and Section 9 of<xreftarget="RFC5088"/> <xref target="RFC5089"/>.</t> <section title="Controltarget="RFC4674" sectionFormat="of" section="4.10"/>, <xref target="RFC5088" sectionFormat="of" section="9"/>, and <xref target="RFC5089" sectionFormat="of" section="9"/>.</t> <section numbered="true" toc="default"> <name>Control of Policy andFunctions">Functions</name> <t>A PCE implementationSHOULD<bcp14>SHOULD</bcp14> allow the following parameters to be configured on the PCE:<list style="symbols"> <t>support</t> <ul spacing="normal"> <li>support forTCP-AO</t> <t>theTCP-AO</li> <li>the KeyID used byTCP-AO</t> <t>KeyTCP-AO</li> <li>Key ChainName</t> <t>supportName</li> <li>support forTLS</t> </list> </t>TLS</li> </ul> </section> <sectiontitle="Informationnumbered="true" toc="default"> <name>Information and DataModel">Model</name> <t>The YANGmodelmodule for PCEP <xreftarget="I-D.ietf-pce-pcep-yang"/>target="I-D.ietf-pce-pcep-yang" format="default"/> supports PCEP security parameters (key, key chain, and TLS).</t> </section> <sectiontitle="Livenessnumbered="true" toc="default"> <name>Liveness Detection andMonitoring">Monitoring</name> <t>Normal operations of the IGP meet the requirements for liveness detection and monitoring.</t> </section> <sectiontitle="Verifynumbered="true" toc="default"> <name>Verification of CorrectOperations">Operations</name> <t>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.</t> </section> <sectiontitle="Requirementsnumbered="true" toc="default"> <name>Requirements on Other Protocols and FunctionalComponents">Components</name> <t>There are no new requirements on other protocols.</t> </section> <sectiontitle="Impactnumbered="true" toc="default"> <name>Impact on NetworkOperations">Operations</name> <t>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 withPCE(s). Section 4.10.4 ofPCEs. <xreftarget="RFC4674"/> and Section 9.6 oftarget="RFC4674" sectionFormat="of" section="4.10.4"/>, <xreftarget="RFC5088"/>target="RFC5088" sectionFormat="of" section="9.6"/>, and <xreftarget="RFC5089"/>target="RFC5089" sectionFormat="of" section="9.6"/> list techniques that are applicable to this document as well.</t> </section> </section> <sectiontitle="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>Security considerations as specified by <xreftarget="RFC5088"/>target="RFC5088" format="default"/> and <xreftarget="RFC5089"/>target="RFC5089" format="default"/> are applicable to this document.</t> <t>As described inSection 10.2 of<xreftarget="RFC5440"/>, antarget="RFC5440" sectionFormat="of" section="10.2"/>, a PCEP speakerMUST<bcp14>MUST</bcp14> support TCP MD5 <xreftarget="RFC2385"/>,target="RFC2385" format="default"/>, so no capability advertisement is needed to indicate support. However, as noted in <xreftarget="RFC6952"/>,target="RFC6952" format="default"/>, TCP MD5 has been obsoleted by TCP-AO <xreftarget="RFC5925"/>target="RFC5925" format="default"/> because of security concerns.However,TCP-AO is not widelyimplemented and so it is,implemented; therefore,RECOMMENDED (per <xref target="RFC8253"/> which updates <xref target="RFC5440"/>)it is <bcp14>RECOMMENDED</bcp14> that PCEPisbe secured usingTLS.TLS per <xref target="RFC8253" format="default"/> (which updates <xref target="RFC5440" format="default"/>). An implementationSHOULD<bcp14>SHOULD</bcp14> offer at least one of the two security capabilities defined in this document.</t> <t>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 ofKey IDthe Key-ID orKey Chain Name Sub-TLVKEY-CHAIN-NAME sub-TLV can be altered to enable an on-path attack. Thus, before advertising the PCEP securityparameters,parameters by using the mechanism described in this document, the IGPMUST<bcp14>MUST</bcp14> be known to provide authentication and integrity for the PCED TLV using the mechanisms defined in <xreftarget="RFC5304"/>,target="RFC5304" format="default"/>, <xreftarget="RFC5310"/>target="RFC5310" format="default"/>, or <xreftarget="RFC5709"/>.</t>target="RFC5709" format="default"/>.</t> <t>Moreover, as stated in theSecurity Considerationssecurity considerations of <xreftarget="RFC5088"/>target="RFC5088" format="default"/> and <xreftarget="RFC5089"/>,target="RFC5089" format="default"/>, 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 theTLV, e.g.TLV. For example, the operator must ensure thatkey-idsKeyIDs orkey-chainkey chain names do not reveal sensitive information about the network.</t> </section> <sectiontitle="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <section anchor="cap"title="PCEnumbered="true" toc="default"> <name>PCE CapabilityFlags">Flags</name> <t>IANAis requested to movehas 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.</t> <t>IANAis requested to makehas made the following additional assignments from the "Path Computation Element (PCE) Capability Flags"registry.</t> <figure> <artwork> Bitregistry:</t> <table anchor="PCEFlags"> <name>Path Computation Element (PCE) CapabilityDescription Reference xx TCP-AO Support [This.I.D] xx PCEPFlags Registrations</name> <thead> <tr> <th>Bit</th> <th>Capability Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>17</td> <td>TCP-AO Support</td> <td>RFC 9353</td> </tr> <tr> <td>18</td> <td>PCEP over TLSsupport [This.I.D] </artwork> </figure>support</td> <td>RFC 9353</td> </tr> </tbody> </table> <t>The grouping is located at:https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml.</t><eref target="https://www.iana.org/assignments/igp-parameters/" brackets="angle"/>.</t> </section> <sectiontitle="PCED sub-TLVnumbered="true" toc="default"> <name>PCED Sub-TLV TypeIndicators">Indicators</name> <t>The PCED sub-TLVswereare defined in <xreftarget="RFC5088"/>target="RFC5088" format="default"/> and <xreftarget="RFC5089"/>,target="RFC5089" format="default"/>, butthey did not createa corresponding IANA registryfor it. This document requestswas not created. IANAto createhas created a new registry called"PCED sub-TLV type indicators""PCE Discovery (PCED) Sub-TLV Type Indicators" under the "Interior Gateway Protocol (IGP) Parameters"grouping.registry. The registration policy for this registry is "Standards Action" <xreftarget="RFC8126"/>.target="RFC8126" format="default"/>. Values in this registry come from the range 0-65535.</t> <t>This registryshould beis initially populatedwith:</t> <figure> <artwork> Value Description Reference 0 Reserved [This.I.D][RFC5088] 1 PCE-ADDRESS [This.I.D][RFC5088] 2 PATH-SCOPE [This.I.D][RFC5088] 3 PCE-DOMAIN [This.I.D][RFC5088] 4 NEIG-PCE-DOMAIN [This.I.D][RFC5088] 5 PCE-CAP-FLAGS [This.I.D][RFC5088] 6 KEY-ID [This.I.D] 7 KEY-CHAIN-NAME [This.I.D] </artwork> </figure>as follows:</t> <table anchor="PCEDIndicators"> <name>Initial Contents of the PCED Sub-TLV Type Indicators Registry</name> <thead> <tr> <th>Value</th> <th>Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>0</td> <td>Reserved</td> <td>RFC 9353, RFC 5088</td> </tr> <tr> <td>1</td> <td>PCE-ADDRESS</td> <td>RFC 9353, RFC 5088</td> </tr> <tr> <td>2</td> <td>PATH-SCOPE</td> <td>RFC 9353, RFC 5088</td> </tr> <tr> <td>3</td> <td>PCE-DOMAIN</td> <td>RFC 9353, RFC 5088</td> </tr> <tr> <td>4</td> <td>NEIG-PCE-DOMAIN</td> <td>RFC 9353, RFC 5088</td> </tr> <tr> <td>5</td> <td>PCE-CAP-FLAGS</td> <td>RFC 9353, RFC 5088</td> </tr> <tr> <td>6</td> <td>KEY-ID</td> <td>RFC 9353</td> </tr> <tr> <td>7</td> <td>KEY-CHAIN-NAME</td> <td>RFC 9353</td> </tr> </tbody> </table> <t>This registry is used by both the OSPF PCED TLV and the IS-IS PCED sub-TLV.</t> <t>This grouping is located at:https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml.</t><eref target="https://www.iana.org/assignments/igp-parameters/" brackets="angle"/>.</t> </section> </section> </middle> <back> <displayreference target="I-D.ietf-pce-pcep-yang" to="PCE-PCEP-YANG"/> <displayreference target="I-D.ietf-lsr-ospf-transport-instance" to="LSR-OSPF-TRANSPORT-INSTANCE"/> <!-- [rfced] RFC 2385 has been obsoleted by RFC 5925. Would the following update be agreeable? We note that RFC 5925 is already in the References section. Original: As described in Section 10.2 of [RFC5440], an PCEP speaker MUST support TCP MD5 [RFC2385], so no capability advertisement is needed to indicate support. Perhaps: As described in Section 10.2 of [RFC5440], a PCEP speaker MUST support TCP MD5 [RFC2385], so no capability advertisement is needed to indicate support. (Note that RFC 2385 has been obsoleted by RFC 5925.) --> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5088.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5089.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5557.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5925.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8253.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8177.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7770.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5304.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5310.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5709.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8231.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8306.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8623.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9168.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2385.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4674.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5440.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5926.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6823.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6952.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/> <!-- [I-D.ietf-pce-pcep-yang] IESG state I-D Exists --> <reference anchor="I-D.ietf-pce-pcep-yang"> <front> <title> A YANG Data Model for Path Computation Element Communications Protocol (PCEP) </title> <author initials="D." surname="Dhody" fullname="Dhruv Dhody" role="editor"> <organization>Huawei Technologies</organization> </author> <author initials="V." surname="Beeram" fullname="Vishnu Pavan Beeram"> <organization>Juniper Networks</organization> </author> <author initials="J." surname="Hardwick" fullname="Jonathan Hardwick"> <organization>Microsoft</organization> </author> <author initials="J." surname="Tantsura" fullname="Jeff Tantsura"> <organization>Microsoft</organization> </author> <date month="October" day="23" year="2022"/> </front> <seriesInfo name="Internet-Draft" value="draft-ietf-pce-pcep-yang-20"/> <format type="TXT" target="https://www.ietf.org/archive/id/draft-ietf-pce-pcep-yang-20.txt"/> </reference> <!-- [I-D.ietf-lsr-ospf-transport-instance] IESG state I-D Exists --> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-lsr-ospf-transport-instance.xml"/> <reference anchor="UTR36" target="https://www.unicode.org/unicode/reports/tr36/"> <front> <title>Unicode Security Considerations</title> <author fullname="Mark Davis" initials="M." surname="Davis" role="editor"> <organization/> </author> <author fullname="M. Suignard" initials="M." surname="Suignard" role="editor"> <organization/> </author> <date month="August" year="2010"/> </front> <refcontent>Unicode Technical Report #36</refcontent> </reference> </references> </references> <sectiontitle="Acknowledgments">numbered="false" toc="default"> <name>Acknowledgments</name> <t>The authors of this document wouldalsolike to thankAcee Lindem, Julien Meuric, Les Ginsberg, Ketan Talaulikar, Tom Petch, Aijun Wang, Adrian Farrel<contact fullname="Acee Lindem"/>, <contact fullname="Julien Meuric"/>, <contact fullname="Les Ginsberg"/>, <contact fullname="Ketan Talaulikar"/>, <contact fullname="Tom Petch"/>, <contact fullname="Aijun Wang"/>, and <contact fullname="Adrian Farrel"/> for the review and comments.</t> <t>The authors would also like to give specialthank Michale Wangthanks to <contact fullname="Michale Wang"/> for his major contributions to the initial draft version.</t> <t>Thanks toJohn Scudder<contact fullname="John Scudder"/> for providing an excellent AD review. Thanks toCarlos Pignataro, Yaron Sheffer, Ron Bonica,<contact fullname="Carlos Pignataro"/>, <contact fullname="Yaron Sheffer"/>, <contact fullname="Ron Bonica"/>, andWill<contact fullname="Will (Shucheng)LIULIU"/> for directorate reviews. </t> <t>Thanks toLars Eggert, Robert Wilton, Roman Danyliw, Eric Vyncke, Paul Wouters, Murray Kucherawy, and Warren Kumari<contact fullname="Lars Eggert"/>, <contact fullname="Robert Wilton"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Paul Wouters"/>, <contact fullname="Murray Kucherawy"/>, and <contact fullname="Warren Kumari"/> for IESG reviews.</t> </section></middle> <back> <references title="Normative References"> <?rfc include="reference.RFC.2119.xml"?> <?rfc include="reference.RFC.5088.xml"?> <?rfc include="reference.RFC.5089.xml"?> <?rfc include="reference.RFC.5557.xml"?> <?rfc include="reference.RFC.5925.xml"?> <?rfc include="reference.RFC.8253.xml"?> <?rfc include="reference.RFC.8177.xml"?> <!--<?rfc include="reference.RFC.7210.xml"?>--> <!--<?rfc include="reference.RFC.6823.xml"?>--> <?rfc include="reference.RFC.8174.xml"?> <?rfc include="reference.RFC.7770.xml"?> <?rfc include="reference.RFC.5304.xml"?> <?rfc include="reference.RFC.5310.xml"?> <?rfc include="reference.RFC.5709.xml"?> <?rfc include="reference.RFC.8126.xml"?> <?rfc include="reference.RFC.8231.xml"?> <?rfc include="reference.RFC.8306.xml"?> <?rfc include="reference.RFC.8623.xml"?> <?rfc include="reference.RFC.9168.xml"?> </references> <references title="Informative References"> <?rfc include="reference.RFC.2385.xml"?> <?rfc include="reference.RFC.4674.xml"?> <?rfc include="reference.RFC.5440.xml"?> <?rfc include="reference.RFC.5926.xml"?> <?rfc include="reference.RFC.6823.xml"?> <?rfc include="reference.RFC.6952.xml"?> <?rfc include="reference.RFC.8446.xml"?> <?rfc include="reference.I-D.ietf-pce-pcep-yang"?> <?rfc include="reference.I-D.ietf-lsr-ospf-transport-instance"?> <reference anchor="UTR36"> <front> <title>Unicode Technical Report #36, Character Encoding Model</title> <author fullname="M.Davis" initials="M." surname="Davis"> <organization/> </author> <date month="February" year="2005"/> </front> <seriesInfo name="UTR17" value="https://www.unicode.org/unicode/reports/tr36/"/> </reference> </references></back> </rfc>