<?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. -->
<!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 -->
<rfc category="std" docName="draft-ginsberg-lsr-isis-invalid-tlv-03"
     ipr="trust200902" updates="3563 5305 6232 6233">
  <front>
    <title abbrev="draft-ginsberg-lsr-isis-invalid-tlv">Invalid TLV Handling
    in IS-IS</title>

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

          <code>95054</code>

          <country>USA</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>

          <code>94089</code>

          <country>USA</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 day="3" month="April" year="2019"/>

    <area>Routing</area>

    <workgroup>LSR Working Group</workgroup>

    <keyword>Internet-Draft</keyword>

    <keyword>TLV</keyword>

    <keyword>IS-IS</keyword>

    <abstract>
      <t>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 (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 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 insure that interoperability is maximized.</t>

      <t>This document when approved updates RFC3563, RFC5305, RFC6232, and
      RFC6233.</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">
      <t>The Intermediate System to Intermediate System (IS-IS) protocol
      utilizes 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 an implementation is required to
      ignore TLVs that it does not understand. This behavior is also applied
      to sub-TLVs, which are contained within TLVs.</t>

      <t>A corollary to ignoring unknown TLVs is having the validation of PDUs
      be independent from the validation of the TLVs contained in the PDU.
      PDUs which are valid MUST be accepted even if an individual TLV
      contained within that PDU is invalid in some way.</t>

      <t>These behaviors are specified in existing protocol documents -
      principally <xref target="ISO10589"/> and <xref target="RFC5305"/>. In
      addition, the set of TLVs (and sub-TLVs) which are allowed in each PDU
      type is documented in the TLV Codepoints Registry (
      https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml
      ) established by <xref target="RFC3563"/> and updated by <xref
      target="RFC6233"/> and <xref target="RFC7356"/>.</t>

      <t>This document is intended to clarify some aspects of existing
      specifications and thereby reduce the occurrence of non-conformant
      behavior seen in real world deployments. Although behaviors specified in
      existing protocol specifications are not changed, the clarifications
      contained in this document serve as updates to RFC 3563 (see Section 2),
      RFC 5304, and RFC 6233 (see Section 3).</t>
    </section>

    <section title="TLV Codepoints Registry">
      <t><xref target="RFC3563"/> established the IANA managed IS-IS TLV
      Codepoints Registry for recording assigned TLV code points <xref
      target="TLV_CODEPOINTS"/>. The initial contents of this registry were
      based on <xref target="RFC3359"/>.</t>

      <t>The registry includes a set of columns indicating in which PDU types
      a given TLV is allowed:</t>

      <t>IIH - TLV is allowed in Intermediate System to Intermediate System
      Hello (IIH) PDUs (Point-to-point and LAN)</t>

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

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

      <t>Purge - TLV is allowed in LSP Purges <xref target="RFC6233"/></t>

      <t>If "Y" is entered in a column it means the TLV is allowed in the
      corresponding PDU type.</t>

      <t>If "N" is entered in a column it means the TLV is NOT allowed in the
      corresponding PDU type.</t>
    </section>

    <section anchor="TLV-Acceptance" title="TLV Acceptance in PDUs ">
      <t>This section describes the correct behavior when a PDU is received
      which contains a TLV which is specified as disallowed in the TLV
      Codepoints Registry.</t>

      <section title="Handling of Disallowed TLVs in Received PDUs other than LSP Purges">
        <t><xref target="ISO10589"/> defines the behavior required when a PDU
        is received containing a TLV which is "not recognised". It states (see
        Sections 9.3 - 9.13):</t>

        <t>"Any codes in a received PDU that are not recognised shall be
        ignored."</t>

        <t>This is the model to be followed when a TLV is received which is
        disallowed. Therefore TLVs in a PDU (other than LSP purges) which are
        disallowed MUST be ignored and MUST NOT cause the PDU itself to be
        rejected by the receiving IS.</t>
      </section>

      <section title="Special Handling of  Disallowed TLVs in Received LSP Purges">
        <t>When purging LSPs <xref target="ISO10589"/> recommends (but does
        not require) the body of the LSP (i.e., all TLVs) be removed before
        generating the purge. LSP purges which have TLVs in the body are
        accepted though any TLVs which are present "MUST" be ignored.</t>

        <t>When cryptographic authentication <xref target="RFC5304"/> 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. <xref
        target="RFC5304"/> therefore imposed strict requirements on what TLVs
        were allowed in a purge (authentication only) and specified that:</t>

        <t>"ISes MUST NOT accept purges that contain TLVs other than the
        authentication TLV".</t>

        <t>This behavior was extended by <xref target="RFC6232"/> which
        introduced the Purge Originator Identification (POI) TLV and <xref
        target="RFC6233"/> which added the "Purge" column to the TLV
        Codepoints registry to identify all the TLVs which are allowed in
        purges.</t>

        <t>The behavior specified in <xref target="RFC5304"/> is not backwards
        compatible with the behavior defined by <xref target="ISO10589"/> and
        therefore can only be safely enabled when all nodes support
        cryptographic authentication. Similarly, the extensions defined by
        <xref target="RFC6233"/> are not compatible with the behavior defined
        in <xref target="RFC5304"/>, therefore can only be safely enabled when
        all nodes support the extensions.</t>

        <t>It is recommended that implementations provide controls for the
        enablement of behaviors that are not backward compatible.</t>
      </section>

      <section title="Applicability to sub-TLVs">
        <t><xref target="RFC5305"/> 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 Codepoints Registry and specify
        in which TLVs a given sub-TLV is allowed. As with TLVs, it is required
        that sub-TLVs which are disallowed MUST be ignored on receipt.</t>
      </section>

      <section title="Correction to POI TLV Registry Entry">
        <t>An error was introduced by <xref target="RFC6232"/> when specifying
        in which PDUs the POI TLV is allowed. Section 3 of <xref
        target="RFC6232"/> stated:</t>

        <t>"The POI TLV SHOULD be found in all purges and MUST NOT be found in
        LSPs with a non-zero Remaining Lifetime."</t>

        <t>However, the IANA section of the same document stated:</t>

        <t>"The additional values for this TLV should be IIH:n, LSP:y, SNP:n,
        and Purge:y. "</t>

        <t>The correct setting for "LSP" is "n". This document corrects that
        error.</t>
      </section>
    </section>

    <section anchor="LSP_ACCEPTANCE"
             title="TLV Validation and LSP Acceptance ">
      <t>The correct format of a TLV and its associated sub-TLVs if applicable
      are defined in the document(s) which introduce each codepoint. The
      definition SHOULD include what action to take when the format/content of
      the TLV does not conform to the specification (e.g., "MUST be ignored on
      receipt"). When making use of the information encoded in a given TLV (or
      sub-TLV) receiving nodes MUST 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 does not conform
      to the relevant specification MUST NOT 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 will compromise
      the correct operation of the protocol.</t>

      <t>LSP Acceptance rules are specified in <xref target="ISO10589"/> .
      Acceptance rules for LSP purges are extended by <xref target="RFC5304"/>
      <xref target="RFC5310"/> and further extended by <xref
      target="RFC6233"/>.</t>

      <t><xref target="ISO10589"/> also specifies the behavior when an LSP is
      not accepted. This behavior is NOT altered by extensions to the LSP
      Acceptance rules i.e., regardless of the reason for the rejection of an
      LSP the Update process on the receiving router takes the same
      action.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>IANA is requested to update the TLV Codepoints Registry to reference
      this document.</t>

      <t>IANA is also requested to modify the entry for the POI TLV in the TLV
      Codepoints Registry to be:</t>

      <t>IIH:n, LSP:n, SNP:n, and Purge:y.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>As this document makes no changes to the 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 implementaion.</t>

      <t>Security concerns for IS-IS are discussed in <xref
      target="ISO10589"/>, <xref target="RFC5304"/>, and <xref
      target="RFC5310"/>.</t>
    </section>

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

      <!---->
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <reference anchor="ISO10589">
        <front>
          <title>Intermediate system to Intermediate system intra-domain
          routeing information exchange protocol for use in conjunction with
          the protocol for providing the connectionless-mode Network Service
          (ISO 8473)</title>

          <author>
            <organization abbrev="ISO">International Organization for
            Standardization</organization>
          </author>

          <date month="Nov" 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.7356"?>

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

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

          <author>
            <organization>IANA</organization>
          </author>

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

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

      <?rfc ?>
    </references>
  </back>
</rfc>
