<?xml version="1.0" encoding="UTF-8"?>

<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com) [CS] updated by Daniel M Kohn (private) Chris 11/07/22 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<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="IGP Ext for Extension: PCEP Security Discovery">IGP extension in PCED">IGP Extension
    for PCEP
    security capability support Path Computation Element Communication Protocol (PCEP) Security Capability Support in PCE discovery</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 Software Avenue, 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 Software Avenue, 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>
    <date year="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 PCE discovery (RFC Discovery (PCED) (RFCs 5088 and RFC 5089) define a method to
      advertise path computation capabilities using IGP flooding for OSPF and IS-IS
      IS-IS, respectively. However However, these specifications lack a method to
      advertise
      PCE Path 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 updates RFC RFCs 5088 and RFC 5089 to allow advertisement of a Key
      ID or Key Chain Name Sub-TLV KEY-CHAIN-NAME sub-TLV to support TCP-AO security capability.
      Further, this
      This document also updates RFC RFCs 8231 and RFC 8306.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>

      <t>As described in <xref target="RFC5440"/>, Path Computation Element Communication
      Protocol (PCEP) communication target="RFC5440" format="default"/>, privacy and integrity are important issues, as 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 to know whether the message has been
   modified.</t>
      <t>Among the possible solutions mentioned in that document, <xref target="RFC5440"
      format="default"/>, Transport Layer Security (TLS) <xref target="RFC8446"/>
      target="RFC8446" format="default"/> provides support for peer
      authentication, and message encryption encryption, and integrity while TCP
      Authentication Option (TCP-AO) TCP-AO) <xref target="RFC5925"/> target="RFC5925" format="default"/>
      and Cryptographic Algorithms for TCP-AO <xref target="RFC5926"/> target="RFC5926"
      format="default"/> offer significantly improved security for
      applications using TCP. As specified in section 4 of <xref target="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 or TCP-AO, the PCC needs to know whether PCE server supports
      TLS or TCP-AO as a secure transport.</t> TCP-AO.</t>

<t><xref target="RFC5088"/> target="RFC5088" format="default"/> and <xref target="RFC5089"/> target="RFC5089" format="default"/> define a method
      to advertise path computation capabilities using IGP flooding for OSPF
      and IS-IS IS-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 <xref target="RFC5088"/> target="RFC5088" format="default"/> and <xref target="RFC5089"/> target="RFC5089" format="default"/> to allow advertisement of a Key ID KeyID or
      Key Chain Name Sub-TLV
      KEY-CHAIN-NAME sub-TLV to support TCP-AO security capability.</t>

      <t>As per <xref target="RFC5088"/>, the IANA
      <t>IANA created a top-level OSPF registry, the registry titled "Path Computation Element (PCE) Capability
      Flags" registry. per <xref target="RFC5088" format="default"/>. This document updates <xref target="RFC5088"/>
      target="RFC5088" format="default"/> and moves the registry it to follow the heading of the "Interior
      Gateway Protocol (IGP) Parameters". Parameters" registry.
      <xref target="RFC5089"/> 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"/> target="RFC5089" format="default"/> to
      refer to the new IGP registry.  Further, this document updates <xref target="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 "PCE to read as "Path Computation Element (PCE) Capability Flag"
Flags" and to note the IGP Parameters corresponding registry now exists in the
"Interior Gateway Protocol (IGP) Parameters" registry.</t>

<aside>      <t>Note that <xref target="RFC5557"/> target="RFC5557" format="default"/> uses the term
      "OSPF registry" instead of the "IGP
      registry" registry", whereas <xref target="RFC8623"/>
      target="RFC8623" format="default"/> and <xref target="RFC9168"/> uses target="RFC9168"
      format="default"/> use the term "OSPF Parameters" instead of "IGP Parameters".</t>
      Parameters".</t></aside>

<aside>
<t>Note that the PCEP Open message exchange is another way to discover
      PCE capabilities information, but information; however, in this instance, the TCP security
      related TCP-security-related key parameters need to be known before the PCEP session is
      established and the PCEP Open messages are exchanged.  Thus, the use of
      the IGP advertisement and flooding mechanisms need to be
     leveraged for PCE discovery and capabilities advertisement of the IGP needs to be
      leveraged.</t> advertisement. </t></aside>
    </section>
    <section title="Conventions used numbered="true" toc="default">
      <name>Conventions Used in this document">
      <t>The This 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 in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
    </section>
    <section title="IGP extension numbered="true" toc="default">
      <name>IGP Extension for PCEP security capability support"> Security Capability Support</name>
      <t><xref target="RFC5088"/> target="RFC5088" format="default"/> defines a PCE Discovery (PCED) TLV carried
      in an OSPF Router Information Link State Advertisement (LSA) as defined
      in <xref target="RFC7770"/> target="RFC7770" format="default"/> to facilitate PCE discovery PCED using OSPF. This
      document defines two capability flag bits in the OSPF PCE Capability
      Flags to indicate TCP Authentication Option (TCP-AO) TCP-AO support <xref
      target="RFC5925"/><xref target="RFC5926"/> target="RFC5925" format="default"/> <xref target="RFC5926" format="default"/> and PCEP over TLS support
      <xref target="RFC8253"/> target="RFC8253" format="default"/>, respectively.</t>
      <t>Similarly, <xref target="RFC5089"/> target="RFC5089" format="default"/> defines the PCED sub-TLV for use
      in PCE discovery 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
      Authentication Option (TCP-AO) support, TCP-AO support and PCEP
over TLS support support, respectively.</t>
      <t>The IANA assignments for shared OSPF and IS-IS Security Capability
      Flags are documented in <xref target="cap"/> ("PCE Capability Flags") target="cap" format="default"/> of this
      document.</t>
      <section title="Use numbered="true" toc="default">
        <name>Use of PCEP security capability support Security Capability Support for PCE 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 advertisement SHOULD <bcp14>SHOULD</bcp14> include a TCP-AO
            support flag bit.</t>

            <t>PCE bit.</li>
          <li>PCE supports TLS: IGP advertisement SHOULD <bcp14>SHOULD</bcp14> include PCEP over
            TLS support flag bit.</t>
          </list>If bit.</li>
        </ul>
        <t>If the PCE supports multiple security mechanisms, it SHOULD <bcp14>SHOULD</bcp14>
        include all corresponding flag bits in its IGP advertisement.</t>
        <t>A client's configuration MAY <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 client MUST <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 client
        MUST
        <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 as KeyID).</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-TLV MAY <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 indicate TCP
          Authentication Option (TCP-AO) TCP-AO support.</t>
          <t>The KEY-ID sub-TLV has the following format:<list>
              <t>Type: 6</t>

              <t>Length: 1</t>

              <t>KeyID: The one octet Key ID format:</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 <xref target="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-TLV MAY <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 as follows:<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 octet Key ID KeyID as per <xref target="RFC5925"/> target="RFC5925" format="default"/>
              to uniquely identify the Master Key Tuple (MKT).</t>

              <t>Reserved: MUST MKT.</dd>
            <dt>Reserved:</dt><dd><bcp14>MUST</bcp14> be set to zero while sending and ignored on
              receipt.</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 a keychain key chain name that can be
        used by the PCC to identify the keychain. key chain.
The keychain key chain name could be manually configured
        via CLI command-line interface (CLI) or installed in the YANG datastore (see <xref target="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-TLV MAY <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 indicate
          TCP Authentication Option (TCP-AO)
          TCP-AO support.</t>
          <t>The KEY-CHAIN-NAME sub-TLV has the following format:<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 value field.</t>

              <t>Key Name: The field.</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. It MUST
            <bcp14>MUST</bcp14> be encoded using UTF-8. A receiving entity MUST NOT
            <bcp14>MUST NOT</bcp14> interpret invalid UTF-8 sequences and
            ignore them.  This field is not NULL terminated. UTF-8 "Shortest
            Form" encoding is REQUIRED <bcp14>REQUIRED</bcp14> to guard against the
            technical issues outlined in <xref target="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-TLV MAY <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-TLV MUST <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 as follows:<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 Length
              field</t>

              <t>Key Name: The
              field.</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. It MUST <bcp14>MUST</bcp14> be encoded using UTF-8. A
              receiving entity MUST NOT <bcp14>MUST NOT</bcp14> interpret invalid UTF-8 sequences and ignore them.
              This field is not NULL terminated. UTF-8 "Shortest Form"
              encoding is REQUIRED <bcp14>REQUIRED</bcp14> to guard against the technical issues
              outlined in <xref target="UTR36"/>. target="UTR36" format="default"/>. The sub-TLV MUST <bcp14>MUST</bcp14> be zero-padded so that the
              sub-TLV is 4-octet aligned.</t>
            </list></t> aligned.</dd>
          </dl>
        </section>
      </section>
    </section>
    <section title="Update numbered="true" toc="default">
      <name>Updates to RFCs">
      <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 PCED TLV, TLV and no new PCE information will be
      carried in the Router Information LSA. This document updates <xref
      target="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 PCED TLV, TLV and no new PCE information will be
      carried in the Router CAPABLITY CAPABILITY TLV. This document updates <xref
      target="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 <xref target="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 <xref target="RFC5088"/><xref target="RFC5089"/> target="RFC5088" format="default"/> and <xref target="RFC5089" format="default"/> should still be
      considered to be in place. If in the future new advertisements are required, required in the future,
      alternative mechanisms such as using <xref target="RFC6823"/> target="RFC6823" format="default"/> or
      <xref target="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 in section 8.3 of
      <xref target="RFC5557"/>, section 8.1 of <xref target="RFC8231"/>, section 6.9 of <xref target="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>
    <section title="Backward numbered="true" toc="default">
      <name>Backward Compatibility Considerations"> 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 ignores these those sub-TLVs.</t>
      <t>IGP extensions defined in this document do not introduce any new
      interoperability issues.</t>
    </section>
    <section title="Management Considerations"> numbered="true" toc="default">
      <name>Management Considerations</name>
      <t>Manageability considerations for PCE Discovery PCED are addressed in
   Section 4.10 of <xref target="RFC4674"/> and Section 9 of <xref target="RFC5088"/> <xref target="RFC5089"/>.</t>
      <section title="Control
      target="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 and Functions"> Functions</name>
        <t>A PCE implementation SHOULD <bcp14>SHOULD</bcp14> allow the following
   parameters to be configured on the PCE:
   <list style="symbols">
   <t>support
        </t>
        <ul spacing="normal">
          <li>support for TCP-AO</t>
   <t>the TCP-AO</li>
          <li>the KeyID used by TCP-AO</t>
   <t>Key TCP-AO</li>
          <li>Key Chain Name</t>
   <t>support Name</li>
          <li>support for TLS</t>
   </list>
   </t> TLS</li>
        </ul>
      </section>
      <section title="Information numbered="true" toc="default">
        <name>Information and Data Model"> Model</name>

        <t>The YANG model module for PCEP <xref target="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>
      <section title="Liveness numbered="true" toc="default">
        <name>Liveness Detection and Monitoring"> Monitoring</name>
        <t>Normal operations of the IGP meet the requirements for liveness detection and monitoring.</t>
      </section>
      <section title="Verify numbered="true" toc="default">
        <name>Verification of Correct Operations"> 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>
      <section title="Requirements numbered="true" toc="default">
        <name>Requirements on Other Protocols and Functional Components"> Components</name>
        <t>There are no new requirements on other protocols.</t>
      </section>
      <section title="Impact numbered="true" toc="default">
        <name>Impact on Network Operations"> 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 PCE(s).
   Section 4.10.4 of PCEs.  <xref target="RFC4674"/> and Section 9.6 of target="RFC4674"
        sectionFormat="of" section="4.10.4"/>, <xref target="RFC5088"/> target="RFC5088"
        sectionFormat="of" section="9.6"/>, and <xref target="RFC5089"/> target="RFC5089"
        sectionFormat="of" section="9.6"/> list techniques that are applicable to this
        document as well.</t>
      </section>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Security considerations as specified by <xref target="RFC5088"/> target="RFC5088" format="default"/> and
      <xref target="RFC5089"/> target="RFC5089" format="default"/> are applicable to this document.</t>
      <t>As described in Section 10.2 of <xref target="RFC5440"/>, an target="RFC5440" sectionFormat="of" section="10.2"/>, a PCEP speaker MUST <bcp14>MUST</bcp14>
      support TCP MD5 <xref target="RFC2385"/>, target="RFC2385" format="default"/>, so no capability advertisement is needed to
      indicate support. However, as noted in <xref target="RFC6952"/>, target="RFC6952" format="default"/>, TCP MD5 has been
      obsoleted by TCP-AO <xref target="RFC5925"/> target="RFC5925" format="default"/> because of security concerns. However, TCP-AO is not widely implemented and so it is, implemented; therefore, RECOMMENDED
      (per <xref target="RFC8253"/> which updates <xref target="RFC5440"/>) it is <bcp14>RECOMMENDED</bcp14>
      that PCEP is be secured using TLS. TLS per <xref target="RFC8253" format="default"/> (which updates <xref target="RFC5440" format="default"/>).
      An implementation SHOULD <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 of Key ID the Key-ID or Key Chain Name Sub-TLV KEY-CHAIN-NAME sub-TLV can be altered to enable
      an on-path attack.  Thus, before advertising the PCEP security
      parameters, parameters by using the
mechanism described in this document, the IGP MUST <bcp14>MUST</bcp14> be known to provide
authentication and integrity for the PCED TLV using the mechanisms
defined in <xref target="RFC5304"/>, target="RFC5304" format="default"/>, <xref target="RFC5310"/> target="RFC5310" format="default"/>, or <xref target="RFC5709"/>.</t> target="RFC5709" format="default"/>.</t>
      <t>Moreover, as stated in the Security Considerations security considerations of <xref target="RFC5088"/> target="RFC5088" format="default"/> and
      <xref target="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 the TLV, e.g. TLV. For example, the operator must ensure that key-ids KeyIDs or
      key-chain
      key chain names do not reveal sensitive information about the
      network.</t>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section anchor="cap" title="PCE numbered="true" toc="default">
        <name>PCE Capability Flags"> Flags</name>
        <t>IANA is requested to move 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.</t>
        <t>IANA is requested to make has made the following additional assignments from
        the "Path Computation Element (PCE) Capability Flags" registry.</t>

        <figure>
          <artwork>
     Bit registry:</t>

<table anchor="PCEFlags">
  <name>Path Computation Element (PCE) Capability Description  Reference
     xx            TCP-AO Support          [This.I.D]
     xx            PCEP Flags 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 TLS support   [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>
      <section title="PCED sub-TLV numbered="true" toc="default">
        <name>PCED Sub-TLV Type Indicators"> Indicators</name>
        <t>The PCED sub-TLVs were are defined in <xref target="RFC5088"/> target="RFC5088" format="default"/> and
        <xref target="RFC5089"/>, target="RFC5089" format="default"/>, but they did not create a corresponding IANA registry for it.
        This document requests was not created.
        IANA to create has 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" <xref target="RFC8126"/>. target="RFC8126" format="default"/>. Values in this registry come from the range
        0-65535.</t>
        <t>This registry should be is initially populated with:</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>

    <section title="Acknowledgments"> numbered="false" toc="default">
      <name>Acknowledgments</name>
      <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 <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 special thank Michale Wang thanks to <contact
      fullname="Michale Wang"/> for his major contributions to the initial
      draft version.</t>
      <t>Thanks to John Scudder <contact fullname="John Scudder"/> for providing an
      excellent AD review. Thanks to Carlos Pignataro, Yaron Sheffer, Ron Bonica, <contact fullname="Carlos Pignataro"/>,
      <contact fullname="Yaron Sheffer"/>, <contact fullname="Ron Bonica"/>,
      and Will <contact fullname="Will (Shucheng) LIU LIU"/> for directorate reviews.
      </t>
      <t>Thanks to Lars 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>