<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
]>
<rfc category="std" docName="draft-ietf-lsr-pce-discovery-security-support-00"
     ipr="trust200902" updates="5088,5089">
  <front>
    <title abbrev="IGP discovery for PCEP Security">IGP extension for PCEP
    security capability support in the PCE discovery</title>

    <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>
          <street>12 Mozhou East Road, Jiangning District</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 Techno Park, Whitefield</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560037</code>

          <country>India</country>
        </postal>

        <email>dhruv.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Michael Wang" initials="Z." surname="Wang">
      <organization>Huawei</organization>

      <address>
        <postal>
          <street>12 Mozhou East Road, Jiangning District</street>

          <city>Nanjing</city>

          <region>Jiangsu</region>

          <code>210012</code>

          <country>China</country>
        </postal>

        <email>wangzitao@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>
        </postal>

        <email>daniel@olddog.co.uk</email>
      </address>
    </author>

    <date year="2018"/>

    <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>

    <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 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
      PCEP security (e.g., Transport Layer Security(TLS), TCP Authentication
      Option (TCP-AO)) support capability.</t>

      <t>This document proposes new capability flag bits for PCE-CAP-FLAGS
      sub-TLV that can be announced as attribute in the IGP advertisement to
      distribute PCEP security support information. In addition, this document
      updates RFC 5088 and RFC 5089 to allow advertisement of Key ID or Key
      Chain Name Sub-TLV to support TCP AO security capability.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>As described in <xref target="RFC5440"/>, PCEP communication privacy
      is one importance issue, as an attacker that intercepts a Path
      Computation Element (PCE) message could obtain sensitive information
      related to computed paths and resources.</t>

      <t>Among the possible solutions mentioned in these documents, Transport
      Layer Security (TLS) <xref target="RFC8446"/> provides support for peer
      authentication, and message encryption and integrity while TCP
      Authentication Option (TCP-AO) <xref target="RFC5925"/> and
      Cryptographic Algorithms for TCP-AO <xref target="RFC5926"/> offer
      significantly improved security for applications using TCP. As specified
      in section 4 of <xref target="RFC8253"/>, in order for a Path
      Computation Client (PCC) to begin a connection with a PCE server using
      TLS or TCP-AO, PCC needs to know whether PCE server supports TLS or
      TCP-AO as a secure transport.</t>

      <t><xref target="RFC5088"/> and <xref target="RFC5089"/> define a method
      to advertise path computation capabilities using IGP flooding for OSPF
      and IS-IS respectively. However these specifications lack a method to
      advertise PCEP security (e.g., TLS) support capability.</t>

      <t>This document proposes new capability flag bits for 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 RFC5088 and RFC5089 to allow advertisement of Key ID or Key
      Chain Name Sub-TLV to support TCP AO security capability.</t>
    </section>

    <section title="Conventions used in this document">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in BCP 14
      <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
      they appear in all capitals, as shown here.</t>
    </section>

    <section title="IGP extension for PCEP security capability support">
      <t><xref target="RFC5088"/> defines a PCE Discovery (PCED) TLV carried
      in an OSPF Router Information Link State Advertisement (LSA) as defined
      in <xref target="RFC7770"/> to facilitate PCE discovery using OSPF. This
      document defines two new capability flag bits in the OSPF PCE Capability
      Flags to indicate TCP Authentication Option (TCP-AO) support <xref
      target="RFC5925"/><xref target="RFC5926"/>, PCEP over TLS support <xref
      target="RFC8253"/> respectively.</t>

      <t>Similarly, <xref target="RFC5089"/> defines the PCED sub-TLV for use
      in PCE discovery 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, PCEP over TLS support
      respectively.</t>

      <t>The IANA assignments for shared OSPF and IS-IS Security Capability
      Flags are documented in <xref target="cap"/> ("OSPF PCE Capability
      Flag") of this document.</t>

      <section title="Use of PCEP security capability support for PCE discovery">
        <t>TCP-AO, PCEP over TLS support flag bits are advertised using IGP
        flooding. <list style="symbols">
            <t>PCE supports TCP-AO: IGP advertisement SHOULD include TCP-AO
            support flag bit.</t>

            <t>PCE supports TLS: IGP advertisement SHOULD include PCEP over
            TLS support flag bit.</t>
          </list>If PCE supports multiple security mechanisms, it SHOULD
        include all corresponding flag bits in IGP advertisement.</t>

        <t>If the client is looking for connecting with PCE server with TCP-AO
        support, the client MUST check if TCP-AO support flag bit in the PCE-
        CAP-FLAGS sub-TLV is set. If not, the client SHOULD NOT consider this
        PCE. If the client is looking for connecting with PCE server using
        TLS, the client MUST check if PCEP over TLS support flag bit in the
        PCE-CAP-FLAGS sub-TLV is set. If not, the client SHOULD NOT consider
        this PCE. Note that this can be overridden based on a local policy at
        the PCC.</t>
      </section>

      <section title="KEY-ID Sub-TLV">
        <t>The KEY-ID sub-TLV specifies a key that can be used by the PCC to
        identify the TCP-AO key <xref target="RFC5925"/>.</t>

        <t>The KEY-ID sub-TLV MAY be present in the PCED sub-TLV carried
        within the IS-IS Router Information Capability TLV when the capability
        flag bit of PCE-CAP-FLAGS sub-TLV in IS-IS is set to indicate TCP
        Authentication Option (TCP-AO) support. Similarly, this sub-TLV MAY be
        present in the PCED TLV carried within OSPF Router Information LSA
        when the capability flag bit of 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:</t>

        <figure>
          <artwork>
    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 = 4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    KeyID      |                 Reserved                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        KEY-ID sub-TLV format
                        </artwork>
        </figure>

        <t>Type: 6</t>

        <t>Length: 4</t>

        <t>KeyID: The one octed Key ID as per <xref target="RFC5925"/> to
        uniquely identify the Master Key Tuple (MKT).</t>

        <t>Reserved: MUST be set to zero while sending and ignored on
        receipt.</t>
      </section>

      <section title="KEY-CHAIN-NAME Sub-TLV">
        <t>The KEY-CHAIN-NAME sub-TLV specifies a keychain name that can be
        used by the PCC to identify the keychain <xref target="RFC8177"/>.</t>

        <t>The KEY-CHAIN-NAME sub-TLV MAY be present in the PCED sub-TLV
        carried within the IS-IS Router Information Capability TLV when the
        capability flag bit of PCE-CAP-FLAGS sub-TLV in IS-IS is set to
        indicate TCP Authentication Option (TCP-AO) support. Similarly, this
        sub-TLV MAY be present in the PCED TLV carried within OSPF Router
        Information LSA when the capability flag bit of PCE-CAP-FLAGS sub-TLV
        in OSPF is set to indicate TCP-AO support.</t>

        <t>The format of the KEY-CHAIN-NAME sub-TLV is as follows:</t>

        <figure>
          <artwork>
    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                         //
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                        KEY-CHAIN-NAME sub-TLV format
                        </artwork>
        </figure>

        <t>Type: 7</t>

        <t>Length: Variable</t>

        <t>Key Name: The Key Chain Name contains a string to be used to
        identify the key chain. It SHOULD be a string of printable ASCII
        characters, without a NULL terminator. The TLV MUST be zero-padded so
        that the TLV is 4-octet aligned.</t>
      </section>
    </section>

    <section title="Update to RFC5088 and RFC5089">
      <t>Section 4 of <xref target="RFC5088"/> needs to be updated to allow
      advertisement of additional PCE information carried in the Router
      Information LSA. The following is proposed text for this change.</t>

      <t>Replace the following paragraph from section 4:</t>

      <t>"No additional sub-TLVs will be added to the PCED TLV in the future.
      If a future application requires the advertisement of additional PCE
      information in OSPF/ISIS, this will not be carried in the Router
      Information LSA."</t>

      <t>with</t>

      <t>"If a future application requires the advertisement of additional PCE
      information in OSPF, e.g., to facilitate key distribution and
      cryptographic authentication and message integrity verification,
      additional sub-TLVs could be added to the PCED TLV and carried in the
      Router Information LSA."</t>

      <t>Section 4 of <xref target="RFC5089"/> needs to be updated to allow
      advertisement of additional PCE information carried in the Router
      CAPABILITY TLV. The following is proposed text for this change.</t>

      <t>Replace the following paragraph from section 4:</t>

      <t>"No additional sub-TLVs will be added to the PCED TLV in the future.
      If a future application requires the advertisement of additional PCE
      information in IS-IS, this will not be carried in the CAPABILITY
      TLV."</t>

      <t>with</t>

      <t>"If a future application requires the advertisement of additional PCE
      information in IS-IS, e.g., to facilitate key distribution and
      cryptographic authentication and message integrity verification,
      additional sub-TLVs could be added to the PCED sub-TLV and carried in
      the CAPABILITY TLV."</t>

      <t>At a time of publication of <xref target="RFC5088"/> and <xref
      target="RFC5089"/> there were concerns about advertising non-IGP
      specific information in OSPF(v3) Router Information LSAs and IS-IS
      router capability TLV. <xref target="RFC7770"/> added the functionality
      of advertising multiple instances of the OSPF(v3) Router Information LSA
      and IS-IS support multiple CAPABILITY TLV <xref target="RFC7981"/>.</t>
    </section>

    <section title="Backward Compatibility Consideration">
      <t>An LSR that does not support the new IGP PCE capability bits
      specified in this document silently ignores those bits.</t>

      <t>An LSR that does not support the new KEYNAME sub-TLV specified in
      this document silently ignores the sub-TLV.</t>

      <t>IGP extensions defined in this document do not introduce any new
      interoperability issues.</t>
    </section>

    <section title="Management Considerations">
      <t>A configuration option may be provided for advertising and
      withdrawing PCE security capability via IGP.</t>
    </section>

    <section title="Security Considerations">
      <t>This document raises no new security issues beyond those described in
      <xref target="RFC5088"/> and <xref target="RFC5089"/>.</t>
    </section>

    <section title="IANA Considerations">
      <section anchor="cap" title="OSPF PCE Capability Flag">
        <t>IANA is requested to allocate new bits assignments for the OSPF
        Parameters "Path Computation Element (PCE) Capability Flags"
        registry.</t>

        <figure>
          <artwork>
     Bit           Meaning                 Reference 
     xx            TCP-AO Support          [This.I.D] 
     xx            PCEP over TLS support   [This.I.D] 
</artwork>
        </figure>

        <t>The registry is located at:
        https://www.iana.org/assignments/ospfv2-parameters/ospfv2-parameters.xml#ospfv2-parameters-14.xml</t>
      </section>

      <section title="PCED sub-TLV Type Indicators">
        <t>The PCED sub-TLVs were defined in <xref target="RFC5088"/> and
        <xref target="RFC5089"/>, but they did not create a registry for it.
        This document requests IANA to create a new top-level OSPF registry,
        the "PCED sub-TLV type indicators" registry. This registry should be
        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]  
     6             KEY-ID                  [This.I.D] 
     7             KEY-CHAIN-NAME          [This.I.D]    
</artwork>
        </figure>

        <t>This registry is also used by IS-IS PCED sub-TLV.</t>
      </section>
    </section>

    <section title="Acknowledgments">
      <t>The authors of this document would also like to thank Acee Lindem,
      Julien Meuric for the review and comments.</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.5925.xml"?>

      <?rfc include="reference.RFC.5926.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.7981.xml"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.5440.xml"?>

      <?rfc include="reference.RFC.8446.xml"?>
    </references>

    <section title="No MD5 Capability Support">
      <t>To be compliant with Section 10.2 of RFC5440, this document doesn't
      consider to add capability for TCP-MD5. Therefore by default, PCEP
      Speaker in communication supports capability for TCP-MD5 (See section
      10.2, <xref target="RFC5440"/>). A method to advertise TCP-MD5
      Capability support using IGP flooding is not required. If the client is
      looking for connecting with PCE server with other Security capability
      support (e.g., TLS support) than TCP-MD5, the client MUST check if flag
      bit in the PCE- CAP-FLAGS sub-TLV for specific capability is set (See
      section 3.1).</t>
    </section>
  </back>
</rfc>
