rfc9353xml2.original.xml   rfc9353.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
by Daniel M Kohn (private) --> <!-- [CS] updated by Chris 11/07/22 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference. <!DOCTYPE rfc [
RFC.2119.xml"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<rfc category="std" docName="draft-ietf-lsr-pce-discovery-security-support-13" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category="
ipr="trust200902" updates="5088,5089,8231,8306"> std" consensus="true" docName="draft-ietf-lsr-pce-discovery-security-support-13"
number="9353" ipr="trust200902" updates="5088,5089,8231,8306" obsoletes="" tocI
nclude="true" sortRefs="true" symRefs="true" xml:lang="en" version="3">
<!-- xml2rfc v2v3 conversion 3.15.0 -->
<front> <front>
<title abbrev="IGP Ext for PCEP Security Discovery">IGP extension for PCEP
security capability support in PCE discovery</title>
<title abbrev="IGP Extension: PCEP Security in PCED">IGP Extension
for Path Computation Element Communication Protocol (PCEP) Security Capabili
ty Support in PCE Discovery (PCED)</title>
<seriesInfo name="RFC" value="9353"/>
<author fullname="Diego R. Lopez " initials="D" surname="Lopez"> <author fullname="Diego R. Lopez " initials="D" surname="Lopez">
<organization>Telefonica I+D</organization> <organization>Telefonica I+D</organization>
<address> <address>
<postal> <postal>
<street/>
<city/>
<region/>
<code/>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<email>diego.r.lopez@telefonica.com</email> <email>diego.r.lopez@telefonica.com</email>
</address> </address>
</author> </author>
<author fullname="Qin Wu" initials="Q." surname="Wu"> <author fullname="Qin Wu" initials="Q." surname="Wu">
<organization abbrev="Huawei">Huawei Technologies</organization> <organization abbrev="Huawei">Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>101 Software Avenue, Yuhua District</street> <extaddr>Yuhua District</extaddr>
<street>101 Software Avenue</street>
<city>Nanjing</city> <city>Nanjing</city>
<region>Jiangsu</region> <region>Jiangsu</region>
<code>210012</code> <code>210012</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>bill.wu@huawei.com</email> <email>bill.wu@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Dhruv Dhody" initials="D." surname="Dhody"> <author fullname="Dhruv Dhody" initials="D." surname="Dhody">
<organization abbrev="Huawei">Huawei Technologies</organization> <organization abbrev="Huawei">Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>Divyashree Techno Park, Whitefield</street> <extaddr>Divyashree Techno Park, Whitefield</extaddr>
<city>Bangalore</city> <city>Bangalore</city>
<region>Karnataka</region> <region>Karnataka</region>
<code>560037</code> <code>560037</code>
<country>India</country> <country>India</country>
</postal> </postal>
<email>dhruv.ietf@gmail.com</email> <email>dhruv.ietf@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Qiufang Ma" initials="Q." surname="Ma"> <author fullname="Qiufang Ma" initials="Q." surname="Ma">
<organization>Huawei</organization> <organization abbrev="Huawei">Huawei Technologies</organization>
<address> <address>
<postal> <postal>
<street>101 Software Avenue, Yuhua District</street> <extaddr>Yuhua District</extaddr>
<street>101 Software Avenue</street>
<city>Nanjing</city> <city>Nanjing</city>
<region>Jiangsu</region> <region>Jiangsu</region>
<code>210012</code> <code>210012</code>
<country>China</country> <country>China</country>
</postal> </postal>
<email>maqiufang1@huawei.com</email> <email>maqiufang1@huawei.com</email>
</address> </address>
</author> </author>
<author fullname="Daniel King" initials="D" surname="King"> <author fullname="Daniel King" initials="D" surname="King">
<organization>Old Dog Consulting</organization> <organization>Old Dog Consulting</organization>
<address> <address>
<postal> <postal>
<street/> <country>United Kingdom</country>
<city/>
<region/>
<code/>
<country>UK</country>
</postal> </postal>
<email>daniel@olddog.co.uk</email> <email>daniel@olddog.co.uk</email>
</address> </address>
</author> </author>
<date year="2023" month="January" />
<date year="2022"/> <area>rtg</area>
<workgroup>lsr</workgroup>
<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>
<keyword>Path Computation Element</keyword> <keyword>Path Computation Element</keyword>
<abstract> <abstract>
<t>When a Path Computation Element (PCE) is a Label Switching Router
(LSR) 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 PCE discovery (RFC 5088 and RFC 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
PCE Communication Protocol (PCEP) security (e.g., Transport Layer
Security (TLS), TCP Authentication Option (TCP-AO)) support
capability.</t>
<t>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.</t>
<t>This document defines capability flag bits for the PCE-CAP-FLAGS <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 sub-TLV that can be announced as an attribute in the IGP advertisement
to distribute PCEP security support information. In addition, this to distribute PCEP security support information. In addition, this
document updates RFC 5088 and RFC 5089 to allow advertisement of a Key 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. ID or KEY-CHAIN-NAME sub-TLV to support TCP-AO security capability.
Further, this document updates RFC 8231 and RFC 8306.</t> This document also updates RFCs 8231 and 8306.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro" numbered="true" toc="default">
<t>As described in <xref target="RFC5440"/>, Path Computation Element Comm <name>Introduction</name>
unication
Protocol (PCEP) communication privacy and integrity <t>As described in <xref target="RFC5440" format="default"/>, privacy and
are important issues, as an attacker that intercepts a PCEP message integrity are important issues for communication using the Path Computation Elem
ent Communication
Protocol (PCEP); an attacker that intercepts a PCEP message
could obtain sensitive information could obtain sensitive information
related to computed paths and resources. Authentication and integrity chec ks related to computed paths and resources. Authentication and integrity chec ks
allow the receiver of a PCEP allow the receiver of a PCEP
message to know that the message genuinely comes from the node that message to know that the message genuinely comes from the node that
purports to have sent it and to know whether the message has been purports to have sent it and whether the message has been
modified.</t> modified.</t>
<t>Among the possible solutions mentioned in <xref target="RFC5440"
<t>Among the possible solutions mentioned in that document, Transport format="default"/>, Transport Layer Security (TLS) <xref
Layer Security (TLS) <xref target="RFC8446"/> provides support for peer target="RFC8446" format="default"/> provides support for peer
authentication, and message encryption and integrity while TCP authentication, message encryption, and integrity while TCP-AO) <xref targ
Authentication Option (TCP-AO) <xref target="RFC5925"/> and et="RFC5925" format="default"/>
Cryptographic Algorithms for TCP-AO <xref target="RFC5926"/> offer and Cryptographic Algorithms for TCP-AO <xref target="RFC5926"
significantly improved security for applications using TCP. As specified format="default"/> offer significantly improved security for
in section 4 of <xref target="RFC8253"/>, in order for a Path applications using TCP. As specified in <xref 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 Computation Client (PCC) to establish a connection with a PCE server
using TLS or TCP-AO, the PCC needs to know whether PCE server supports using TLS or TCP-AO.</t>
TLS or TCP-AO as a secure transport.</t>
<t><xref target="RFC5088"/> and <xref target="RFC5089"/> define a method <t><xref target="RFC5088" format="default"/> and <xref target="RFC5089" format=" default"/> define a method
to advertise path computation capabilities using IGP flooding for OSPF to advertise path computation capabilities using IGP flooding for OSPF
and IS-IS respectively. However, these specifications lack a method to and IS-IS, respectively. However, these specifications lack a method to
advertise PCEP security (e.g., TLS) support capability.</t> advertise PCEP security (e.g., TLS and TCP-AO) support capability.</t>
<t>This document defines capability flag bits for the PCE-CAP-FLAGS <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 sub-TLV that can be announced as attributes in the IGP advertisement to
distribute PCEP security support information. In addition, this document distribute PCEP security support information. In addition, this document
updates <xref target="RFC5088"/> and <xref target="RFC5089"/> to allow adv updates <xref target="RFC5088" format="default"/> and <xref target="RFC508
ertisement of a Key ID or 9" format="default"/> to allow advertisement of a KeyID or
Key Chain Name Sub-TLV to support TCP-AO security capability.</t> KEY-CHAIN-NAME sub-TLV to support TCP-AO security capability.</t>
<t>IANA created a top-level registry titled "Path Computation Element (PCE
) Capability
Flags" per <xref target="RFC5088" format="default"/>. This document update
s <xref
target="RFC5088" format="default"/> and moves it to follow the heading of
the "Interior
Gateway Protocol (IGP) Parameters" registry.
<xref target="RFC5089"
format="default"/> states that the IS-IS PCE-CAP-FLAGS sub-TLV uses the
same registry as OSPF. This document updates <xref target="RFC5089" format="defa
ult"/> to
refer to the new IGP registry. Further, this document updates <xref
target="RFC8231" format="default"/> where it references the registry
location as the "Open Shortest Path First v2 (OSPFv2) Parameters" registry
to the
"Interior Gateway Protocol (IGP) Parameters" registry.
<t>As per <xref target="RFC5088"/>, the IANA created a top-level OSPF regi This document also
stry, the updates <xref target="RFC8306" format="default"/> by changing the term "OS
"Path Computation Element (PCE) Capability Flags" registry. This PF PCE
document updates <xref target="RFC5088"/> and moves the registry to "Inter Capability Flag" to read as "Path Computation Element (PCE) Capability
ior Gateway Flags" and to note the corresponding registry now exists in the
Protocol (IGP) Parameters". <xref target="RFC5089"/> states that the IS-IS "Interior Gateway Protocol (IGP) Parameters" registry.</t>
uses the
same registry as OSPF. This document updates <xref target="RFC5089"/> to r
efer to
the new IGP registry.
Further, this document updates <xref target="RFC8231"/>
where it references the registry location as "Open Shortest Path First
(OSPF) Parameters" registry to "Interior Gateway Protocol (IGP)
Parameters" registry. This document updates [RFC8306] where it uses the
term "OSPF PCE Capability Flag" and request assignment from OSPF
Parameters registry with "PCE Capability Flag" and the IGP Parameters
registry.</t>
<t>Note that <xref target="RFC5557"/> uses the term "OSPF registry" instea <aside> <t>Note that <xref target="RFC5557" format="default"/> uses the ter
d of the "IGP m
registry" whereas <xref target="RFC8623"/> and <xref target="RFC9168"/> us "OSPF registry" instead of the "IGP registry", whereas <xref
es the term "OSPF target="RFC8623" format="default"/> and <xref target="RFC9168"
Parameters" instead of "IGP Parameters".</t> format="default"/> use the term "OSPF Parameters" instead of "IGP
Parameters".</t></aside>
<t>Note that the PCEP Open message exchange is another way to discover <aside>
PCE capabilities information, but in this instance, the TCP security <t>Note that the PCEP Open message exchange is another way to discover
related key parameters need to be known before the PCEP session is PCE capabilities information; however, in this instance, the TCP-security-
established and the PCEP Open messages are exchanged. Thus, the use of related key parameters need to be known before the PCEP session is
the PCE discovery and capabilities advertisement of the IGP needs to be established and the PCEP Open messages are exchanged. Thus, the IGP adver
leveraged.</t> tisement and flooding mechanisms need to be
leveraged for PCE discovery and capabilities advertisement. </t></aside>
</section> </section>
<section numbered="true" toc="default">
<section title="Conventions used in this document"> <name>Conventions Used in This Document</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP 14 IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section numbered="true" toc="default">
<section title="IGP extension for PCEP security capability support"> <name>IGP Extension for PCEP Security Capability Support</name>
<t><xref target="RFC5088"/> defines a PCE Discovery (PCED) TLV carried <t><xref target="RFC5088" format="default"/> defines a PCE Discovery (PCED
) TLV carried
in an OSPF Router Information Link State Advertisement (LSA) as defined in an OSPF Router Information Link State Advertisement (LSA) as defined
in <xref target="RFC7770"/> to facilitate PCE discovery using OSPF. This in <xref target="RFC7770" format="default"/> to facilitate PCED using OSPF . This
document defines two capability flag bits in the OSPF PCE Capability document defines two capability flag bits in the OSPF PCE Capability
Flags to indicate TCP Authentication Option (TCP-AO) support <xref Flags to indicate TCP-AO support <xref target="RFC5925" format="default"/>
target="RFC5925"/><xref target="RFC5926"/> and PCEP over TLS support <xref target="RFC5926" format="default"/> and PCEP over TLS support
<xref target="RFC8253"/> respectively.</t> <xref target="RFC8253" format="default"/>, respectively.</t>
<t>Similarly, <xref target="RFC5089" format="default"/> defines the PCED s
<t>Similarly, <xref target="RFC5089"/> defines the PCED sub-TLV for use ub-TLV for use
in PCE discovery using IS-IS. This document will use the same flag for in PCED using IS-IS.
the OSPF PCE Capability Flags sub-TLV to allow IS-IS to indicate TCP This document will use the same flag for the OSPF PCE Capability Flags sub-TLV
Authentication Option (TCP-AO) support, PCEP over TLS support to allow IS-IS to indicate TCP-AO support and PCEP
respectively.</t> over TLS support, respectively.</t>
<t>The IANA assignments for shared OSPF and IS-IS Security Capability <t>The IANA assignments for shared OSPF and IS-IS Security Capability
Flags are documented in <xref target="cap"/> ("PCE Capability Flags") of Flags are documented in <xref target="cap" format="default"/> of this
this document.</t> document.</t>
<section numbered="true" toc="default">
<section title="Use of PCEP security capability support for PCE discovery" <name>Use of PCEP Security Capability Support for PCED</name>
> <t>TCP-AO and PCEP over TLS support flag bits are advertised using IGP
<t>TCP-AO, PCEP over TLS support flag bits are advertised using IGP flooding. </t>
flooding. <list style="symbols"> <ul spacing="normal">
<t>PCE supports TCP-AO: IGP advertisement SHOULD include TCP-AO <li>PCE supports TCP-AO: IGP advertisement <bcp14>SHOULD</bcp14> inclu
support flag bit.</t> de a TCP-AO
support flag bit.</li>
<t>PCE supports TLS: IGP advertisement SHOULD include PCEP over <li>PCE supports TLS: IGP advertisement <bcp14>SHOULD</bcp14> include
TLS support flag bit.</t> PCEP over
</list>If the PCE supports multiple security mechanisms, it SHOULD TLS support flag bit.</li>
</ul>
<t>If the PCE supports multiple security mechanisms, it <bcp14>SHOULD</b
cp14>
include all corresponding flag bits in its IGP advertisement.</t> include all corresponding flag bits in its IGP advertisement.</t>
<t>A client's configuration <bcp14>MAY</bcp14> indicate that support for
<t>A client's configuration MAY indicate that support for a given a given
security capability is required. If a client is configured to require security capability is required. If a client is configured to require
that its PCE server supports TCP-AO, the client MUST verify that the that its PCE server supports TCP-AO, the client <bcp14>MUST</bcp14> veri fy that the
TCP-AO flag bit in the PCE-CAP-FLAGS sub-TLV for a given server is set 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 before it opens a connection to that server. Similarly, if the client
is configured to require that its PCE server supports TLS, 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 <bcp14>MUST</bcp14> verify that the PCEP over TLS support flag bit in th e
PCE-CAP-FLAGS sub-TLV for a given server is set before it opens a PCE-CAP-FLAGS sub-TLV for a given server is set before it opens a
connection to that server.</t> connection to that server.</t>
</section> </section>
<section anchor="keyid" numbered="true" toc="default">
<section anchor="keyid" title="KEY-ID Sub-TLV"> <name>KEY-ID Sub-TLV</name>
<t>The KEY-ID sub-TLV specifies an identifier that can be used by the <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 as PCC to identify the TCP-AO key (referred to as "KeyID" in <xref target="
KeyID).</t> RFC5925" format="default"/>).</t>
<section anchor="keyid-isis" numbered="true" toc="default">
<section anchor="keyid-isis" title="IS-IS"> <name>IS-IS</name>
<t>The KEY-ID sub-TLV MAY be present in the PCED sub-TLV carried <t>The KEY-ID sub-TLV <bcp14>MAY</bcp14> be present in the PCED sub-TL
V carried
within the IS-IS Router CAPABILITY TLV when the capability flag bit within the IS-IS Router CAPABILITY TLV when the capability flag bit
of PCE-CAP-FLAGS sub-TLV in IS-IS is set to indicate TCP of the PCE-CAP-FLAGS sub-TLV in IS-IS is set to indicate TCP-AO suppor
Authentication Option (TCP-AO) support.</t> t.</t>
<t>The KEY-ID sub-TLV has the following format:</t>
<t>The KEY-ID sub-TLV has the following format:<list> <dl newline="false" spacing="normal">
<t>Type: 6</t> <dt>Type:</dt><dd>6</dd>
<dt>Length:</dt><dd>1</dd>
<t>Length: 1</t> <dt>KeyID:</dt><dd>The one-octet KeyID as per <xref
target="RFC5925" format="default"/> to uniquely identify the
<t>KeyID: The one octet Key ID as per <xref target="RFC5925"/> Master Key Tuple (MKT).</dd>
to uniquely identify the Master Key Tuple (MKT).</t> </dl>
</list></t>
</section> </section>
<section anchor="keyid-ospf" numbered="true" toc="default">
<section anchor="keyid-ospf" title="OSPF"> <name>OSPF</name>
<t>Similarly, this sub-TLV MAY be present in the PCED TLV carried <t>Similarly, this sub-TLV <bcp14>MAY</bcp14> be present in the PCED T
within OSPF Router Information LSA when the capability flag bit of LV carried
PCE-CAP-FLAGS sub-TLV in OSPF is set to indicate TCP-AO support.</t> 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>The format of KEY-ID sub-TLV is as follows:<figure> t>
<artwork> <t>The format of the KEY-ID sub-TLV is as follows:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
1 2 3 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 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 | | Type = 6 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KeyID | Reserved | | KeyID | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> <dl newline="false" spacing="normal">
</figure><list> <dt>Type:</dt><dd>6</dd>
<t>Type: 6</t> <dt>Length:</dt><dd>4</dd>
<dt>KeyID:</dt><dd>The one octet KeyID as per <xref target="RFC5925"
<t>Length: 4</t> format="default"/>
to uniquely identify the MKT.</dd>
<t>KeyID: The one octet Key ID as per <xref target="RFC5925"/> <dt>Reserved:</dt><dd><bcp14>MUST</bcp14> be set to zero while sendi
to uniquely identify the Master Key Tuple (MKT).</t> ng and ignored on
receipt.</dd>
<t>Reserved: MUST be set to zero while sending and ignored on </dl>
receipt.</t>
</list></t>
</section> </section>
</section> </section>
<section anchor="keyname" numbered="true" toc="default">
<section anchor="keyname" title="KEY-CHAIN-NAME Sub-TLV"> <name>KEY-CHAIN-NAME Sub-TLV</name>
<t>The KEY-CHAIN-NAME sub-TLV specifies a keychain name that can be <t>The KEY-CHAIN-NAME sub-TLV specifies a key chain name that can be
used by the PCC to identify the keychain. The keychain name could be man used by the PCC to identify the key chain.
ually configured The key chain name could be manually configured
via CLI or installed in the YANG datastore (see <xref target="RFC8177"/> via command-line interface (CLI) or installed in the YANG datastore (see
) at the PCC.</t> <xref target="RFC8177" format="default"/>) at the PCC.</t>
<section anchor="keyname-ISIS" numbered="true" toc="default">
<section anchor="keyname-ISIS" title="IS-IS"> <name>IS-IS</name>
<t>The KEY-CHAIN-NAME sub-TLV MAY be present in the PCED sub-TLV <t>The KEY-CHAIN-NAME sub-TLV <bcp14>MAY</bcp14> be present in the PCE
D sub-TLV
carried within the IS-IS Router CAPABILITY TLV when the capability 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 flag bit of the PCE-CAP-FLAGS sub-TLV in IS-IS is set to indicate
TCP Authentication Option (TCP-AO) support.</t> TCP-AO support.</t>
<t>The KEY-CHAIN-NAME sub-TLV has the following format:</t>
<t>The KEY-CHAIN-NAME sub-TLV has the following format:<list> <dl newline="false" spacing="normal">
<t>Type: 7</t> <dt>Type:</dt><dd>7</dd>
<dt>Length:</dt><dd>Variable, encodes the length of the value field.
<t>Length: Variable, encodes the length of the value field.</t> </dd>
<dt>Key Chain Name:</dt><dd>The Key Chain Name contains a string of
<t>Key Name: The Key Chain Name contains a string of 1 to 255 octe 1 to
ts 255 octets to be used to identify the key chain. It
to be used to <bcp14>MUST</bcp14> be encoded using UTF-8. A receiving entity
identify the key chain. It MUST be encoded using UTF-8. A <bcp14>MUST NOT</bcp14> interpret invalid UTF-8 sequences and
receiving entity MUST NOT interpret invalid UTF-8 sequences and ig ignore them. This field is not NULL terminated. UTF-8 "Shortest
nore them. Form" encoding is <bcp14>REQUIRED</bcp14> to guard against the
This field is not NULL terminated. UTF-8 "Shortest Form" technical issues outlined in <xref target="UTR36"
encoding is REQUIRED to guard against the technical issues format="default"/>.</dd>
outlined in <xref target="UTR36"/>.</t> </dl>
</list></t>
</section> </section>
<section anchor="keyname-ospf" numbered="true" toc="default">
<section anchor="keyname-ospf" title="OSPF"> <name>OSPF</name>
<t>Similarly, this sub-TLV MAY be present in the PCED TLV carried <t>Similarly, this sub-TLV <bcp14>MAY</bcp14> be present in the PCED T
LV carried
within the OSPF Router Information LSA when the capability flag bit within the OSPF Router Information LSA when the capability flag bit
of PCE-CAP-FLAGS sub-TLV in OSPF is set to indicate TCP-AO support. 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 .
The sub-TLV <bcp14>MUST</bcp14> be zero-padded so that the sub-TLV is
4-octet
aligned.</t> aligned.</t>
<t>The format of KEY-CHAIN-NAME sub-TLV is as follows:</t>
<t>The format of KEY-CHAIN-NAME sub-TLV is as follows:<figure> <artwork name="" type="" align="left" alt=""><![CDATA[
<artwork>
1 2 3 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 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 | | Type = 7 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Key Chain Name // // Key Chain Name //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</artwork> <dl newline="false" spacing="normal">
</figure><list> <dt>Type:</dt><dd>7</dd>
<t>Type: 7</t> <dt>Length:</dt><dd>Variable, padding is not included in the Length
field.</dd>
<t>Length: Variable, padding is not included in the Length <dt>Key Chain Name:</dt><dd>The Key Chain Name contains a string of
field</t> 1 to 255 octets
<t>Key Name: The Key Chain Name contains a string of 1 to 255 octe
ts
to be used to to be used to
identify the key chain. It MUST be encoded using UTF-8. A identify the key chain. It <bcp14>MUST</bcp14> be encoded using UT
receiving entity MUST NOT interpret invalid UTF-8 sequences and ig F-8. A
nore them. receiving entity <bcp14>MUST NOT</bcp14> interpret invalid UTF-8 s
equences and ignore them.
This field is not NULL terminated. UTF-8 "Shortest Form" This field is not NULL terminated. UTF-8 "Shortest Form"
encoding is REQUIRED to guard against the technical issues encoding is <bcp14>REQUIRED</bcp14> to guard against the technical
outlined in <xref target="UTR36"/>. The sub-TLV MUST be zero-padde issues
d so that the outlined in <xref target="UTR36" format="default"/>. The sub-TLV <
sub-TLV is 4-octet aligned.</t> bcp14>MUST</bcp14> be zero-padded so that the
</list></t> sub-TLV is 4-octet aligned.</dd>
</dl>
</section> </section>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Update to RFCs"> <name>Updates to RFCs</name>
<t>Section 4 of <xref target="RFC5088"/> states that no new sub-TLVs <t><xref target="RFC5088" sectionFormat="of" section="4"/> states that no
will be added to the PCED TLV, and no new PCE information will be new sub-TLVs
carried in the Router Information LSA. This document updates <xref will be added to the PCED TLV and no new PCE information will be
target="RFC5088"/> by allowing the two sub-TLVs defined in this document carried in the Router Information LSA. This document updates <xref target=
"RFC5088" format="default"/> by allowing the two sub-TLVs defined in this docume
nt
to be carried in the PCED TLV advertised in the Router Information to be carried in the PCED TLV advertised in the Router Information
LSA.</t> LSA.</t>
<t><xref target="RFC5089" sectionFormat="of" section="4"/> states that no
<t>Section 4 of <xref target="RFC5089"/> states that no new sub-TLVs new sub-TLVs
will be added to the PCED TLV, and no new PCE information will be will be added to the PCED TLV and no new PCE information will be
carried in the Router CAPABLITY TLV. This document updates <xref carried in the Router CAPABILITY TLV. This document updates <xref target="
target="RFC5089"/> by allowing the two sub-TLVs defined in this document RFC5089" format="default"/> by allowing the two sub-TLVs defined in this documen
t
to be carried in the PCED TLV advertised in the Router CAPABILITY to be carried in the PCED TLV advertised in the Router CAPABILITY
TLV.</t> TLV.</t>
<t>This introduction of additional sub-TLVs should be viewed as an <t>This introduction of additional sub-TLVs should be viewed as an
exception to the <xref target="RFC5088"/><xref target="RFC5089"/> policy, justified by the requirement exception to the policies in <xref target="RFC5088" format="default"/> and <xref target="RFC5089" format="default"/>, which is justified by the requiremen t
to discover the PCEP security support prior to establishing a PCEP to discover the PCEP security support prior to establishing a PCEP
session. The restrictions defined in <xref target="RFC5088"/><xref target= session. The restrictions defined in <xref target="RFC5088" format="defaul
"RFC5089"/> should still be t"/> and <xref target="RFC5089" format="default"/> should still be
considered to be in place. If in the future new advertisements are require considered to be in place. If new advertisements are required in the futur
d, e,
alternative mechanisms such as using <xref target="RFC6823"/> or alternative mechanisms such as using <xref target="RFC6823" format="defaul
<xref target="I-D.ietf-lsr-ospf-transport-instance"/> should be considered t"/> or
.</t> <xref target="I-D.ietf-lsr-ospf-transport-instance" format="default"/> sho
uld be considered.</t>
<t>The registry for the PCE Capability Flags assigned in section 8.3 of <t>The registry for the PCE Capability Flags assigned in <xref
<xref target="RFC5557"/>, section 8.1 of <xref target="RFC8231"/>, section target="RFC5557" sectionFormat="of" section="8.3"/>, <xref
6.9 of <xref target="RFC8306"/>, section target="RFC8231" sectionFormat="of" section="8.1"/>, <xref
11.1 of <xref target="RFC8623"/>, and section 10.5 of <xref target="RFC916 target="RFC8306" sectionFormat="of" section="6.9"/>, <xref
8"/> has changed to the IGP target="RFC8623" sectionFormat="of" section="11.1"/>, and <xref
Parameters "Path Computation Element (PCE) Capability Flags" registry target="RFC9168" sectionFormat="of" section="10.5"/> has changed to the
created in this document.</t> IGP Parameters "Path Computation Element (PCE) Capability Flags"
registry created in this document.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Backward Compatibility Considerations"> <name>Backward Compatibility Considerations</name>
<t>An LSR that does not support the IGP PCE capability bits specified in <t>An LSR that does not support the IGP PCE capability bits specified in
this document silently ignores those bits.</t> this document silently ignores those bits.</t>
<t>An LSR that does not support the KEY-ID and KEY-CHAIN-NAME sub-TLVs <t>An LSR that does not support the KEY-ID and KEY-CHAIN-NAME sub-TLVs
specified in this document silently ignores these sub-TLVs.</t> specified in this document silently ignores those sub-TLVs.</t>
<t>IGP extensions defined in this document do not introduce any new <t>IGP extensions defined in this document do not introduce any new
interoperability issues.</t> interoperability issues.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Management Considerations"> <name>Management Considerations</name>
<t>Manageability considerations for PCE Discovery are addressed in <t>Manageability considerations for PCED are addressed in <xref
Section 4.10 of <xref target="RFC4674"/> and Section 9 of <xref target="RFC50 target="RFC4674" sectionFormat="of" section="4.10"/>, <xref
88"/> <xref target="RFC5089"/>.</t> target="RFC5088" sectionFormat="of" section="9"/>, and <xref
<section title="Control of Policy and Functions"> target="RFC5089" sectionFormat="of" section="9"/>.</t>
<t>A PCE implementation SHOULD allow the following <section numbered="true" toc="default">
<name>Control of Policy and Functions</name>
<t>A PCE implementation <bcp14>SHOULD</bcp14> allow the following
parameters to be configured on the PCE: parameters to be configured on the PCE:
<list style="symbols"> </t>
<t>support for TCP-AO</t> <ul spacing="normal">
<t>the KeyID used by TCP-AO</t> <li>support for TCP-AO</li>
<t>Key Chain Name</t> <li>the KeyID used by TCP-AO</li>
<t>support for TLS</t> <li>Key Chain Name</li>
</list> <li>support for TLS</li>
</t> </ul>
</section> </section>
<section title="Information and Data Model"> <section numbered="true" toc="default">
<t>The YANG model for PCEP <xref target="I-D.ietf-pce-pcep-yang"/> supports <name>Information and Data Model</name>
PCEP security parameters (key, key chain, and TLS).</t>
</section> <t>The YANG module for PCEP <xref target="I-D.ietf-pce-pcep-yang" format
<section title="Liveness Detection and Monitoring"> ="default"/> supports PCEP security parameters (key, key chain, and TLS).</t>
<t>Normal operations of the IGP meet the requirements for liveness detection </section>
and monitoring.</t> <section numbered="true" toc="default">
</section> <name>Liveness Detection and Monitoring</name>
<section title="Verify Correct Operations"> <t>Normal operations of the IGP meet the requirements for liveness detec
<t>The correlation of PCEP security information advertised against informati tion and monitoring.</t>
on </section>
<section numbered="true" toc="default">
<name>Verification of Correct Operations</name>
<t>The correlation of PCEP security information advertised against information
received can be achieved by comparing the information in the PCED 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 sub-TLV received by the PCC with that stored at the PCE using the
PCEP YANG.</t> PCEP YANG.</t>
</section>
<section numbered="true" toc="default">
<name>Requirements on Other Protocols and Functional Components</name>
<t>There are no new requirements on other protocols.</t>
</section>
<section numbered="true" toc="default">
<name>Impact on Network 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 with PCEs. <xref target="RFC4674"
sectionFormat="of" section="4.10.4"/>, <xref target="RFC5088"
sectionFormat="of" section="9.6"/>, and <xref target="RFC5089"
sectionFormat="of" section="9.6"/> list techniques that are applicable t
o this
document as well.</t>
</section>
</section> </section>
<section title="Requirements on Other Protocols and Functional Components"> <section numbered="true" toc="default">
<t>There are no new requirements on other protocols.</t> <name>Security Considerations</name>
</section> <t>Security considerations as specified by <xref target="RFC5088" format="
<section title="Impact on Network Operations"> default"/> and
<t>Frequent changes in PCEP security information advertised in the PCED sub- <xref target="RFC5089" format="default"/> are applicable to this document.
TLV </t>
may have a significant impact on IGP and might destabilize the <t>As described in <xref target="RFC5440" sectionFormat="of" section="10.2
operation of the network by causing the PCCs to reconnect sessions with PCE(s "/>, a PCEP speaker <bcp14>MUST</bcp14>
). support TCP MD5 <xref target="RFC2385" format="default"/>, so no capabilit
Section 4.10.4 of <xref target="RFC4674"/> and Section 9.6 of <xref target="R y advertisement is needed to
FC5088"/> <xref target="RFC5089"/> list techniques that are applicable to this d indicate support. However, as noted in <xref target="RFC6952" format="defa
ocument as well.</t> ult"/>, TCP MD5 has been
</section> obsoleted by TCP-AO <xref target="RFC5925" format="default"/> because of s
</section> ecurity concerns. TCP-AO is not widely implemented; therefore, it is <bcp14>RECO
MMENDED</bcp14>
<section title="Security Considerations"> that PCEP be secured using TLS per <xref target="RFC8253" format="default"
<t>Security considerations as specified by <xref target="RFC5088"/> and /> (which updates <xref target="RFC5440" format="default"/>).
<xref target="RFC5089"/> are applicable to this document.</t> An implementation <bcp14>SHOULD</bcp14> offer at least one of the two
<t>As described in Section 10.2 of <xref target="RFC5440"/>, an PCEP speak
er MUST
support TCP MD5 <xref target="RFC2385"/>, so no capability advertisement i
s needed to
indicate support. However, as noted in <xref target="RFC6952"/>, TCP MD5 h
as been
obsoleted by TCP-AO <xref target="RFC5925"/> because of security concerns.
However,
TCP-AO is not widely implemented and so it is, therefore, RECOMMENDED
(per <xref target="RFC8253"/> which updates <xref target="RFC5440"/>) that
PCEP is secured using TLS.
An implementation SHOULD offer at least one of the two
security capabilities defined in this document.</t> security capabilities defined in this document.</t>
<t>The information related to PCEP security is sensitive and due care <t>The information related to PCEP security is sensitive and due care
needs to be taken by the operator. This document defines new capability 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. bits that are susceptible to a downgrade attack by setting them to zero.
The content of Key ID or Key Chain Name Sub-TLV can be altered to enable The content of the Key-ID or KEY-CHAIN-NAME sub-TLV can be altered to enab
an on-path attack. Thus, before advertising the PCEP security le
parameters, using the mechanism described in this document, the IGP MUST an on-path attack. Thus, before advertising the PCEP security parameters
be known to provide authentication and integrity for the PCED TLV using by using the
the mechanisms defined in <xref target="RFC5304"/>, <xref target="RFC5310" mechanism described in this document, the IGP <bcp14>MUST</bcp14> be known to pr
/> or <xref target="RFC5709"/>.</t> ovide
authentication and integrity for the PCED TLV using the mechanisms
defined in <xref target="RFC5304" format="default"/>, <xref target="RFC5310" for
mat="default"/>, or <xref target="RFC5709" format="default"/>.</t>
<t>Moreover, as stated in the security considerations of <xref target="RFC
5088" format="default"/> and
<xref target="RFC5089" format="default"/>, there are no mechanisms defined
in OSPF or IS-IS to protect
the confidentiality of the PCED TLV.
<t>Moreover, as stated in the Security Considerations of <xref target="RFC For this reason, the operator must
5088"/> and ensure that no private data is carried in the TLV. For example, the operat
<xref target="RFC5089"/>, there are no mechanisms defined in OSPF or IS-IS or must ensure that KeyIDs or
to protect key chain names do not reveal sensitive information about the
the confidentiality of the PCED TLV. For this reason, the operator must
ensure that no private data is carried in the TLV, e.g. that key-ids or
key-chain names do not reveal sensitive information about the
network.</t> network.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="IANA Considerations"> <name>IANA Considerations</name>
<section anchor="cap" title="PCE Capability Flags"> <section anchor="cap" numbered="true" toc="default">
<t>IANA is requested to move the "Path Computation Element (PCE) <name>PCE Capability Flags</name>
<t>IANA has moved the "Path Computation Element (PCE)
Capability Flags" registry from the "Open Shortest Path First v2 Capability Flags" registry from the "Open Shortest Path First v2
(OSPFv2) Parameters" grouping to the "Interior Gateway Protocol (IGP) (OSPFv2) Parameters" grouping to the "Interior Gateway Protocol (IGP)
Parameters" grouping.</t> Parameters" grouping.</t>
<t>IANA has made the following additional assignments from
the "Path Computation Element (PCE) Capability Flags" registry:</t>
<t>IANA is requested to make the following additional assignments from <table anchor="PCEFlags">
the "Path Computation Element (PCE) Capability Flags" registry.</t> <name>Path Computation Element (PCE) Capability Flags Registrations</name>
<thead>
<figure> <tr>
<artwork> <th>Bit</th>
Bit Capability Description Reference <th>Capability Description</th>
xx TCP-AO Support [This.I.D] <th>Reference</th>
xx PCEP over TLS support [This.I.D] </tr>
</artwork> </thead>
</figure> <tbody>
<tr>
<td>17</td>
<td>TCP-AO Support</td>
<td>RFC 9353</td>
</tr>
<tr>
<td>18</td>
<td>PCEP over TLS support</td>
<td>RFC 9353</td>
</tr>
</tbody>
</table>
<t>The grouping is located at: <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> </section>
<section numbered="true" toc="default">
<section title="PCED sub-TLV Type Indicators"> <name>PCED Sub-TLV Type Indicators</name>
<t>The PCED sub-TLVs were defined in <xref target="RFC5088"/> and <t>The PCED sub-TLVs are defined in <xref target="RFC5088" format="defau
<xref target="RFC5089"/>, but they did not create a registry for it. lt"/> and
This document requests IANA to create a new registry called "PCED <xref target="RFC5089" format="default"/>, but a corresponding IANA regi
sub-TLV type indicators" under the "Interior Gateway Protocol (IGP) stry was not created.
Parameters" grouping. The registration policy for this registry is IANA has created a new registry called "PCE Discovery (PCED)
"Standards Action" <xref target="RFC8126"/>. Values in this registry com Sub-TLV Type Indicators" under the "Interior Gateway Protocol (IGP)
e from the range Parameters" registry. The registration policy for this registry is
"Standards Action" <xref target="RFC8126" format="default"/>. Values in
this registry come from the range
0-65535.</t> 0-65535.</t>
<t>This registry is initially populated as follows:</t>
<t>This registry should be populated with:</t> <table anchor="PCEDIndicators">
<name>Initial Contents of the PCED Sub-TLV Type Indicators Registry</name>
<figure> <thead>
<artwork> <tr>
Value Description Reference <th>Value</th>
0 Reserved [This.I.D][RFC5088] <th>Description</th>
1 PCE-ADDRESS [This.I.D][RFC5088] <th>Reference</th>
2 PATH-SCOPE [This.I.D][RFC5088] </tr>
3 PCE-DOMAIN [This.I.D][RFC5088] </thead>
4 NEIG-PCE-DOMAIN [This.I.D][RFC5088] <tbody>
5 PCE-CAP-FLAGS [This.I.D][RFC5088] <tr>
6 KEY-ID [This.I.D] <td>0</td>
7 KEY-CHAIN-NAME [This.I.D] <td>Reserved</td>
</artwork> <td>RFC 9353, RFC 5088</td>
</figure> </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 <t>This registry is used by both the OSPF PCED TLV and the IS-IS PCED
sub-TLV.</t> sub-TLV.</t>
<t>This grouping is located at: <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>
</section> </section>
<section title="Acknowledgments">
<t>The authors of this document would also like to thank Acee Lindem,
Julien Meuric, Les Ginsberg, Ketan Talaulikar, Tom Petch,
Aijun Wang, Adrian Farrel for the review and comments.</t>
<t>The authors would also like to special thank Michale Wang for his
major contributions to the initial version.</t>
<t>Thanks to John Scudder for providing an excellent AD review. Thanks to
Carlos Pignataro, Yaron Sheffer, Ron Bonica, and Will (Shucheng) LIU for directo
rate reviews. </t>
<t>Thanks to Lars Eggert, Robert Wilton, Roman Danyliw, Eric Vyncke, Paul
Wouters, Murray Kucherawy, and Warren Kumari for IESG reviews.</t>
</section>
</middle> </middle>
<back> <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"?> <displayreference target="I-D.ietf-pce-pcep-yang" to="PCE-PCEP-YANG"/>
<displayreference target="I-D.ietf-lsr-ospf-transport-instance" to="LSR-OSPF-TRA
<?rfc include="reference.RFC.8253.xml"?> NSPORT-INSTANCE"/>
<?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"?> <!-- [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.
<?rfc include="reference.RFC.5304.xml"?> 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.
<?rfc include="reference.RFC.5310.xml"?> 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.)
-->
<?rfc include="reference.RFC.5709.xml"?> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
088.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
089.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
557.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
925.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
253.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
177.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
770.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
304.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
310.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
709.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
231.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
306.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
623.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
168.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
385.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
674.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
440.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
926.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
823.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
952.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<?rfc include="reference.RFC.8126.xml"?> <!-- [I-D.ietf-pce-pcep-yang] IESG state I-D Exists -->
<?rfc include="reference.RFC.8231.xml"?> <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-y
ang-20.txt"/>
</reference>
<?rfc include="reference.RFC.8306.xml"?> <!-- [I-D.ietf-lsr-ospf-transport-instance] IESG state I-D Exists -->
<?rfc include="reference.RFC.8623.xml"?> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D .ietf-lsr-ospf-transport-instance.xml"/>
<?rfc include="reference.RFC.9168.xml"?> <reference anchor="UTR36" target="https://www.unicode.org/unicode/report
s/tr36/">
<front>
<title>Unicode Security Considerations</title>
<author fullname="Mark Davis" initials="M." surname="Davis" role="ed
itor">
<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> </references>
<references title="Informative References"> <section numbered="false" toc="default">
<?rfc include="reference.RFC.2385.xml"?> <name>Acknowledgments</name>
<t>The authors of this document would like to thank <contact
<?rfc include="reference.RFC.4674.xml"?> fullname="Acee Lindem"/>, <contact fullname="Julien Meuric"/>, <contact
fullname="Les Ginsberg"/>, <contact fullname="Ketan Talaulikar"/>,
<?rfc include="reference.RFC.5440.xml"?> <contact fullname="Tom Petch"/>, <contact fullname="Aijun Wang"/>, and
<contact fullname="Adrian Farrel"/> for the review and comments.</t>
<?rfc include="reference.RFC.5926.xml"?> <t>The authors would also like to give special thanks to <contact
fullname="Michale Wang"/> for his major contributions to the initial
<?rfc include="reference.RFC.6823.xml"?> draft version.</t>
<t>Thanks to <contact fullname="John Scudder"/> for providing an
<?rfc include="reference.RFC.6952.xml"?> excellent AD review. Thanks to <contact fullname="Carlos Pignataro"/>,
<contact fullname="Yaron Sheffer"/>, <contact fullname="Ron Bonica"/>,
<?rfc include="reference.RFC.8446.xml"?> and <contact fullname="Will (Shucheng) LIU"/> for directorate reviews.
</t>
<?rfc include="reference.I-D.ietf-pce-pcep-yang"?> <t>Thanks to <contact fullname="Lars Eggert"/>, <contact
fullname="Robert Wilton"/>, <contact fullname="Roman Danyliw"/>,
<?rfc include="reference.I-D.ietf-lsr-ospf-transport-instance"?> <contact fullname="Éric Vyncke"/>, <contact fullname="Paul Wouters"/>,
<contact fullname="Murray Kucherawy"/>, and <contact fullname="Warren
<reference anchor="UTR36"> Kumari"/> for IESG reviews.</t>
<front> </section>
<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> </back>
</rfc> </rfc>
 End of changes. 106 change blocks. 
496 lines changed or deleted 586 lines changed or added

This html diff was produced by rfcdiff 1.48.