<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. --> encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
    please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
    (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
    (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions --> "rfc2629-xhtml.ent">

<rfc category="std" xmlns:xi="http://www.w3.org/2001/XInclude"
     docName="draft-ietf-lsr-isis-invalid-tlv-03" number="8918"
     ipr="trust200902" updates="5305 6232"> 6232" obsoletes="" submissionType="IETF"
     category="std" consensus="true" xml:lang="en" tocInclude="true"
     tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 2.47.0 -->
  <front>
    <title abbrev="draft-ietf-lsr-isis-invalid-tlv">Invalid abbrev="Invalid TLV Handling in IS-IS">Invalid TLV Handling in
    IS-IS</title>
    <seriesInfo name="RFC" value="8918"/>
    <author fullname="Les Ginsberg" initials="L." surname="Ginsberg">
      <organization>Cisco Systems</organization>
      <address>
        <email>ginsberg@cisco.com</email>
      </address>
    </author>
    <author fullname="Paul Wells" initials="P." surname="Wells">
      <organization>Cisco Systems</organization>
      <address>
        <postal>
          <street/>
          <city/>
          <region/>
          <code/>
          <country/>
        </postal>
        <phone/>

        <facsimile/>
        <email>pauwells@cisco.com</email>
        <uri/>
      </address>
    </author>
    <author fullname="Tony Li" initials="T" surname="Li">
      <organization>Arista Networks</organization>
      <address>
        <postal>
          <street>5453 Great America Parkway</street>
          <city>Santa Clara</city>

          <region>California</region>
          <region>CA</region>
          <code>95054</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <phone/>

        <facsimile/>
        <email>tony.li@tony.li</email>
        <uri/>
      </address>
    </author>
    <author fullname="Tony Przygienda" initials="T" surname="Przygienda">
      <organization>Juniper Networks, Inc.</organization>
      <address>
        <postal>
          <street>1194 N. Matilda Ave</street>
          <city>Sunnyvale</city>

          <region>California</region>
          <region>CA</region>
          <code>94089</code>

          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <phone/>

        <facsimile/>
        <email>prz@juniper.net</email>
        <uri/>
      </address>
    </author>
    <author fullname="Shraddha Hegde" initials="S" surname="Hegde">
      <organization>Juniper Networks, Inc.</organization>
      <address>
        <postal>
          <street>Embassy Business Park</street>
          <city>Bangalore</city>
          <region>KA</region>
          <code>560093</code>
          <country>India</country>
        </postal>
        <phone/>

        <facsimile/>
        <email>shraddha@juniper.net</email>
        <uri/>
      </address>
    </author>
    <date year="2020"/> year="2020" month="September"/>
    <area>Routing</area>
    <workgroup>LSR Working Group</workgroup>

    <keyword>Internet-Draft</keyword>
    <keyword>TLV</keyword>
    <keyword>IS-IS</keyword>
    <abstract>
      <t>Key
      <t>The key to the extensibility of the Intermediate System to Intermediate
      System (IS-IS) protocol has been the handling of unsupported and/or
      invalid Type/Length/Value Type-Length-Value (TLV) tuples. Although there are explicit
      statements in existing specifications, deployment experience has shown
      that there are inconsistencies in the behavior when a TLV which that is
      disallowed in a particular Protocol Data Unit (PDU) is received.</t>
      <t>This document discusses such cases and makes the correct behavior
      explicit in order to ensure that interoperability is maximized.</t>
      <t>This document updates RFC5305 RFCs 5305 and RFC6232.</t> 6232.</t>
    </abstract>

    <note title="Requirements Language">
      <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>
    </note>
  </front>
  <middle>
    <section title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Intermediate System to Intermediate System (IS-IS) protocol <xref
      target="ISO10589"/>
      target="ISO10589" format="default"/> utilizes Type/Length/Value Type-Length-Value (TLV)
      encoding for all content in the body of Protocol Data Units (PDUs). New
      extensions to the protocol are supported by defining new TLVs. In order
      to allow protocol extensions to be deployed in a backwards compatible way
      way, an implementation is required to ignore TLVs that it does not
      understand. This behavior is also applied to sub-TLVs <xref target="RFC5305"/>,
      target="RFC5305" format="default"/>, which are contained within
      TLVs.</t>
      <t>Also essential to the correct operation of the protocol is having the
      validation of PDUs be independent from the validation of the TLVs
      contained in the PDU. PDUs which that are valid must be accepted <xref
      target="ISO10589"/>
      target="ISO10589" format="default"/> even if an individual TLV contained
      within that PDU is not understood or is invalid in some way (e.g.,
      incorrect syntax, data value out of range, etc.).</t>
      <t>The set of TLVs (and sub-TLVs) which that are allowed in each PDU type is
      documented in the TLV "TLV Codepoints Registry Registry" established by <xref
      target="RFC3563"/>
      target="RFC3563" format="default"/> and updated by <xref target="RFC6233"/>
      target="RFC6233" format="default"/> and <xref
      target="RFC7356"/>.</t> target="RFC7356"
      format="default"/>.</t>
      <t>This document is intended to clarify some aspects of existing
      specifications and thereby and, thereby, reduce the occurrence of non-conformant
      behavior seen in real world real-world deployments. Although behaviors specified in
      existing protocol specifications are not changed, the clarifications
      contained in this document serve as updates to RFC 5305 <xref target="RFC5305"/>
      (see Section
      3.3) <xref target="app-sub-tlv" format="default"/>) and RFC 6232 <xref
      target="RFC6232" format="default"/> (see Section 3.4).</t> <xref
      target="correct-poi"/>).</t>
    <section numbered="true" toc="default">
            <name>Requirements Language</name>
        <t>
    The key words "<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 "<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 title="TLV numbered="true" toc="default">
      <name>TLV Codepoints Registry"> Registry</name>
      <t><xref target="RFC3563"/> target="RFC3563" format="default"/> established the
      IANA-managed IS-IS "IS-IS TLV Codepoints Registry Registry" for recording assigned TLV code points
      codepoints <xref
      target="TLV_CODEPOINTS"/>. target="TLV_CODEPOINTS" format="default"/>. The
      initial contents of this registry were based on <xref target="RFC3359"/>.</t> target="RFC3359"
      format="default"/>.</t>
      <t>The registry includes a set of columns indicating in which PDU types
      a given TLV is allowed:</t>

      <t>IIH - TLV
      <dl newline="false" spacing="normal" indent="8">
      <dt>IIH</dt>
      <dd>TLV is allowed in Intermediate System to Intermediate System
      Hello (IIH) PDUs (Point-to-point and LAN)</t>

      <t>LSP - TLV LAN)</dd>
      <dt>LSP</dt>
      <dd>TLV is allowed in Link State PDUs (LSP)</t>

      <t>SNP - TLV (LSPs)</dd>
      <dt>SNP</dt>
      <dd>TLV is allowed in Sequence Number PDUs (SNP) (SNPs) (Partial Sequence
      Number PDUs (PSNP) (PSNPs) and Complete Sequence Number PDUS (CSNP))</t>

      <t>Purge - TLV PDUs (CSNPs))</dd>
      <dt>Purge</dt>
      <dd>TLV is allowed in LSP Purges <xref target="RFC6233"/></t> target="RFC6233"
      format="default"/></dd>
      </dl>
      <t>If "Y" is entered in a column column, it means the TLV is allowed in the
      corresponding PDU type.</t>
      <t>If "N" is entered in a column column, it means the TLV is not allowed in the
      corresponding PDU type.</t>
    </section>
    <section anchor="TLV-Acceptance" title="TLV numbered="true" toc="default">
      <name>TLV Acceptance in PDUs "> PDUs</name>
      <t>This section describes the correct behavior when a PDU is received
      which
      that contains a TLV which that is specified as disallowed in the TLV "TLV
      Codepoints Registry.</t> Registry" is received.</t>
      <section title="Handling numbered="true" toc="default">
        <name>Handling of Disallowed TLVs in Received PDUs other than Other Than LSP Purges">
	Purges</name>
        <t><xref target="ISO10589"/> target="ISO10589" format="default"/> defines the behavior
	required when a PDU is received containing a TLV which that is "not
	recognised". It states (see Sections 9.5 - 9.13):</t>

        <t><figure>
            <artwork><![CDATA[   "Any
<blockquote>
  Any codes in a received PDU that are not recognised shall be ignored."]]></artwork>
          </figure></t> ignored.
</blockquote>
        <t>This is the model to be followed when a TLV that is received which disallowed is
        disallowed. Therefore
	received. Therefore, TLVs in a PDU (other than LSP purges) which that are
        disallowed MUST <bcp14>MUST</bcp14> be ignored and MUST NOT <bcp14>MUST NOT</bcp14>
	cause the PDU itself to be rejected by the receiving IS.</t>
      </section>
      <section title="Special numbered="true" toc="default">
        <name>Special Handling of  Disallowed TLVs in Received LSP Purges"> Purges</name>
        <t>When purging LSPs, <xref target="ISO10589"/> target="ISO10589" format="default"/>
	recommends (but does not require) the body of the LSP (i.e., all TLVs)
	be removed before generating the purge. LSP purges which that have TLVs in
	the body are
        accepted accepted, though any TLVs which that are present are
	ignored.</t>
        <t>When cryptographic authentication <xref target="RFC5304"/> target="RFC5304"
	format="default"/> was introduced, this looseness when processing
	received purges had to be addressed in order to prevent attackers from
	being able to initiate a purge without having access to the
	authentication key. Therefore, <xref
        target="RFC5304"/> therefore target="RFC5304"
	format="default"/> imposed strict requirements on what TLVs were allowed in a
	purge (authentication only) and specified that:</t>

        <t><figure>
            <artwork><![CDATA[   "ISes MUST NOT
<blockquote>
  ISes <bcp14>MUST NOT</bcp14> accept purges that contain TLVs other than the
  authentication TLV".]]></artwork>
          </figure></t> TLV.
</blockquote>
        <t>This behavior was extended by <xref target="RFC6232"/> target="RFC6232"
	format="default"/>, which introduced the Purge Originator
	Identification (POI) TLV TLV, and <xref
        target="RFC6233"/> target="RFC6233" format="default"/>,
	which added the "Purge" column to the TLV "TLV Codepoints registry Registry" to
	identify all the TLVs which that are allowed in purges.</t>
        <t>The behavior specified in <xref target="RFC5304"/> target="RFC5304" format="default"/>
	is not backwards compatible with the behavior defined by <xref target="ISO10589"/> and
        therefore
	target="ISO10589" format="default"/>; therefore, it can only be safely
	enabled when all nodes support cryptographic
	authentication. Similarly, the extensions defined by <xref target="RFC6232"/>
	target="RFC6232" format="default"/> are not compatible with the
	behavior defined in <xref target="RFC5304"/>, therefore target="RFC5304" format="default"/>;
	therefore, they can only be safely enabled when all nodes support the
	extensions.</t>
        <t>When new protocol behaviors are specified that are not backwards
	compatible, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that implementations
	provide controls for their enablement. This serves to prevent
	interoperability issues and allow for non-disruptive introduction of
	the new functionality into an existing network.</t>
      </section>
      <section title="Applicability anchor="app-sub-tlv" numbered="true" toc="default">
        <name>Applicability to sub-TLVs"> Sub-TLVs</name>
        <t><xref target="RFC5305"/> target="RFC5305" format="default"/> introduced sub-TLVs,
	which are TLV tuples advertised within the body of a parent
	TLV. Registries associated with sub-TLVs are associated with the TLV "TLV
	Codepoints Registry Registry" and specify in which TLVs a given sub-TLV is
	allowed. Section 2 of <xref
        target="RFC5305"/> target="RFC5305" sectionFormat="of" section="2"/> is
	updated by the following sentence:</t>

        <t><figure>
            <artwork><![CDATA[   "As
<blockquote>
  As with TLVs, it is required that sub-TLVs which that are disallowed MUST
  <bcp14>MUST</bcp14> be ignored on receipt.".]]></artwork>
          </figure></t> receipt.
</blockquote>
        <t>The existing sentence in Section 2 of <xref target="RFC5305"/>
        :</t>

        <t><figure>
            <artwork><![CDATA[   "Unknown target="RFC5305"
	sectionFormat="of" section="2"/>:</t>
<blockquote>
  Unknown sub-TLVs are to be ignored and skipped upon
    receipt."]]></artwork>
          </figure></t> receipt.
</blockquote>
        <t>is replaced by:</t>

        <t><figure>
            <artwork><![CDATA[   "Unknown
<blockquote>
  Unknown sub-TLVs MUST <bcp14>MUST</bcp14> be ignored and skipped upon
    receipt."]]></artwork>
          </figure></t> receipt.
</blockquote>
      </section>
      <section title="Correction anchor="correct-poi" numbered="true" toc="default">
        <name>Correction to POI TLV Registry Entry"> &quot;TLV Codepoints Registry&quot; Entry</name>
        <t>An error was introduced by <xref target="RFC6232"/> target="RFC6232"
	format="default"/> when specifying in which PDUs the POI TLV is
	allowed. Section 3 of <xref
        target="RFC6232"/> stated:</t>

        <t><figure>
            <artwork><![CDATA[   "The target="RFC6232" sectionFormat="of" section="3"/>
	states:</t>
<blockquote>
  The POI TLV SHOULD <bcp14>SHOULD</bcp14> be found in all purges and
    MUST NOT <bcp14>MUST
  NOT</bcp14> be found in LSPs with a non-zero Remaining Lifetime."]]></artwork>
          </figure></t> Lifetime.
</blockquote>
        <t>However, the IANA section of the same document stated:</t>

        <t><figure>
            <artwork><![CDATA[   "The states:</t>
<blockquote>
  The additional values for this TLV should be IIH:n, LSP:y, SNP:n, and Purge:y."]]></artwork>
          </figure></t>
  Purge:y.
</blockquote>
        <t>The correct setting for "LSP" is "n". This document updates <xref
        target="RFC6232"/>
	target="RFC6232" format="default"/> by correcting that error.</t>
        <t>This document also updates the previously quoted text from Section
        3 of <xref target="RFC6232"/>
	target="RFC6232" sectionFormat="of" section="3"/> to be:</t>

        <t><figure>
            <artwork><![CDATA[   "The
<blockquote>
  The POI TLV SHOULD <bcp14>SHOULD</bcp14> be sent in all purges and
    MUST NOT <bcp14>MUST
  NOT</bcp14> be sent in LSPs with a non-zero Remaining Lifetime."]]></artwork>
          </figure></t> Lifetime.
</blockquote>
      </section>
    </section>
    <section anchor="LSP_ACCEPTANCE"
             title="TLV numbered="true" toc="default">
      <name>TLV Validation and LSP Acceptance "> Acceptance</name>
      <t>The correct format of a TLV and its associated sub-TLVs, if
      applicable, are is defined in the document(s) which introduce that introduces each
      codepoint. The definition MUST <bcp14>MUST</bcp14> include what action to
      take when the format/content of the TLV does not conform to the
      specification (e.g.,
      "MUST "<bcp14>MUST</bcp14> be ignored on receipt"). When
      making use of the information encoded in a given TLV (or sub-TLV) sub-TLV),
      receiving nodes MUST <bcp14>MUST</bcp14> verify that the TLV conforms to the
      standard definition. This includes cases where the length of a
      TLV/sub-TLV is incorrect and/or cases where the value field does not
      conform to the defined restrictions.</t>
      <t>However, the unit of flooding for the IS-IS Update process is an
      LSP. The presence of a TLV (or sub-TLV) with content which that does not
      conform to the relevant specification MUST NOT <bcp14>MUST NOT</bcp14> cause the
      LSP itself to be rejected. Failure to follow this requirement will
      result in inconsistent LSP Databases on different nodes in the network which
      that will compromise the correct operation of the protocol.</t>
      <t>LSP Acceptance rules are specified in <xref target="ISO10589"/> . target="ISO10589"
      format="default"/>. Acceptance rules for LSP purges are extended by
      <xref target="RFC5304"/>
      <xref target="RFC5310"> target="RFC5304" format="default"/> and </xref> <xref target="RFC5310"
      format="default"/> and are further extended by <xref
      target="RFC6233"/>.</t>
      target="RFC6233" format="default"/>.</t>
      <t><xref target="ISO10589"/> target="ISO10589" format="default"/> also specifies the
      behavior when an LSP is not accepted.

      This behavior is NOT *not* altered by
      extensions to the LSP Acceptance rules rules, i.e., regardless of the reason
      for the rejection of an
      LSP LSP, the Update process on the receiving router
      takes the same action.</t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>IANA is requested to add has added this document as a reference for the TLV "TLV
      Codepoints Registry.</t> Registry".</t>
      <t>IANA is has also requested to modify modified the entry for the Purge Originator
      Identification TLV in the TLV "TLV Codepoints Registry Registry" to be:</t>

      <t>IIH:n, be IIH:n, LSP:n,
      SNP:n, and Purge:y.</t>
      <t>The reference field should be of the Purge Originator Identification
      TLV has been updated to point to this document.</t>
    </section>
    <section anchor="Security" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>As this document makes no changes to the protocol protocol, there are no new
      security issues introduced.</t>
      <t>The clarifications discussed in this document are intended to make it
      less likely that implementations will incorrectly process received LSPs,
      thereby also making it less likely that a bad actor could exploit a
      faulty implementation.</t>
      <t>Security concerns for IS-IS are discussed in <xref
      target="ISO10589"/>, target="ISO10589"
      format="default"/>, <xref target="RFC5304"/>, target="RFC5304" format="default"/>, and <xref
      target="RFC5310"/>.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>The authors would like to thank Alvaro Retana.</t>

      <!---->
      target="RFC5310" format="default"/>.</t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>

        <reference anchor="ISO10589">
          <front>
          <title>Intermediate system
            <title>Information technology -- Telecommunications and
              information exchange between systems -- Intermediate
              System to Intermediate system System intra-domain routeing
              information exchange protocol for use in conjunction with
              the protocol for providing the connectionless-mode Network Service network
              service (ISO 8473)</title>
            <seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>
            <author>
              <organization abbrev="ISO">International Organization for
            Standardization</organization>
            </author>
            <date month="Nov" month="November" year="2002"/>
          </front>

        <seriesInfo name="ISO/IEC" value="10589:2002, Second Edition"/>
        </reference>

      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.3563"?>

      <?rfc include="reference.RFC.5304"?>

      <?rfc include="reference.RFC.5305"?>

      <?rfc include="reference.RFC.5310"?>

      <?rfc include="reference.RFC.6232"?>

      <?rfc include="reference.RFC.6233"?>

      <?rfc include="reference.RFC.8174"?>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3563.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5304.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5305.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5310.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6232.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6233.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

        <reference anchor="TLV_CODEPOINTS"> anchor="TLV_CODEPOINTS"
		   target="https://www.iana.org/assignments/isis-tlv-codepoints/">
          <front>
            <title>IS-IS TLV Codepoints web page
          (https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml)</title> Codepoints</title>
            <author>
              <organization>IANA</organization>
            </author>

          <date/>
          </front>
        </reference>
      </references>

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

      <?rfc include="reference.RFC.7356"?>

      <?rfc ?>
      <references>
        <name>Informative References</name>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3359.xml"/>
        <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7356.xml"/>
      </references>
    </references>
    <section anchor="Acknowledgements" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank <contact fullname="Alvaro
      Retana"/>.</t>

    </section>
  </back>
</rfc>