Skip to main content

Invalid TLV Handling in IS-IS
draft-ginsberg-lsr-isis-invalid-tlv-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Les Ginsberg , Paul Wells , Tony Li , Tony Przygienda , Shraddha Hegde
Last updated 2018-12-02
Replaced by draft-ietf-lsr-isis-invalid-tlv, RFC 8918
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ginsberg-lsr-isis-invalid-tlv-01
LSR Working Group                                            L. Ginsberg
Internet-Draft                                                  P. Wells
Updates: 3563 5305 6232 6233 (if                           Cisco Systems
         approved)                                                 T. Li
Intended status: Standards Track                         Arista Networks
Expires: June 5, 2019                                      T. Przygienda
                                                                S. Hegde
                                                  Juniper Networks, Inc.
                                                        December 2, 2018

                     Invalid TLV Handling in IS-IS
                 draft-ginsberg-lsr-isis-invalid-tlv-01

Abstract

   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, in some cases the expected
   behavior is "well known" but not explicitly stated.

   This document discusses the "well known behaviors" and makes them
   explicit in order to insure that interoperability is maximized.

   This document when approved updates RFC3563, RFC5305, RFC6232, and
   RFC6233.

Requirements Language

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any

Ginsberg, et al.          Expires June 5, 2019                  [Page 1]
Internet-Draft     draft-ginsberg-lsr-isis-invalid-tlv     December 2018

   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 5, 2019.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  TLV Codepoints Registry . . . . . . . . . . . . . . . . . . .   3
   3.  TLV Acceptance in PDUs  . . . . . . . . . . . . . . . . . . .   4
     3.1.  Handling of Disallowed TLVs in Received PDUs  . . . . . .   4
     3.2.  Special Handling of  Disallowed TLVs in Received Purges .   4
     3.3.  Applicability to sub-TLVs . . . . . . . . . . . . . . . .   5
     3.4.  Correction to POI TLV Registry Entry  . . . . . . . . . .   5
   4.  TLV Validation and LSP Acceptance . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   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.

Ginsberg, et al.          Expires June 5, 2019                  [Page 2]
Internet-Draft     draft-ginsberg-lsr-isis-invalid-tlv     December 2018

   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.

   These behaviors are specified in existing protocol documents -
   principally [ISO10589] and [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 [RFC3563]
   and updated by [RFC6233] and [RFC7356].

   Nevertheless, a certain degree of "common knowledge" is assumed on
   the part of implementors in regards to these behaviors.

   This document serves to make explicit what is expected.  While it
   does not alter any existing protocol behavior or specifications, it
   is intended to close any gaps between what is explicitly stated and
   what has been "commonly understood".  Although existing protocol
   behavior is 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).

2.  TLV Codepoints Registry

   [RFC3563] established the IANA managed IS-IS TLV Codepoints Registry
   for recording assigned TLV code points [TLV_CODEPOINTS].  The initial
   contents of this registry were based on [RFC3359].

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

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

   LSP - TLV is allowed in Link State PDUs (LSP)

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

   Purge - TLV is allowed in LSP Purges [RFC6233]

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

   If "N" is entered in a column it means the TLV is NOT allowed in the
   corresponding PDU type.

Ginsberg, et al.          Expires June 5, 2019                  [Page 3]
Internet-Draft     draft-ginsberg-lsr-isis-invalid-tlv     December 2018

3.  TLV Acceptance in PDUs

   This section describes the correct behavior when a PDU is received
   which contains a TLV which is specified as NOT allowed in the TLV
   Codepoints Registry.

3.1.  Handling of Disallowed TLVs in Received PDUs

   When a PDU is received and it contains a TLV which is NOT allowed in
   that PDU the expected behavior is defined in [ISO10589] which states
   (see Sections 9.3 - 9.13):

   "Any codes in a received PDU that are not recognised shall be
   ignored."

   Therefore the presence of TLVs in a PDU which are not allowed MUST
   NOT cause the PDU itself to be rejected by the receiving IS.

3.2.  Special Handling of Disallowed TLVs in Received Purges

   When purging LSPs [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.

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

   "ISes MUST NOT accept purges that contain TLVs other than the
   authentication TLV".

   This behavior was extended by [RFC6232] which introduced the Purge
   Originator Identification (POI) TLV and [RFC6233] which added the
   "Purge" column to the TLV Codepoints registry to identify all the
   TLVs which are allowed in purges.

   The behavior specified in [RFC5304] is not backwards compatible with
   the behavior defined by [ISO10589] and therefore can only be safely
   enabled when all nodes support cryptographic authentication.
   Similarly, the extensions defined by [RFC6233] are not compatible
   with the behavior defined in [RFC5304], therefore can only be safely
   enabled when all nodes support the extensions.

Ginsberg, et al.          Expires June 5, 2019                  [Page 4]
Internet-Draft     draft-ginsberg-lsr-isis-invalid-tlv     December 2018

   It is recommended that implementations provide controls for the
   enablement of behaviors that are not backward compatible.

3.3.  Applicability to sub-TLVs

   [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 NOT allowed MUST be ignored on receipt.

3.4.  Correction to POI TLV Registry Entry

   An error was introduced by [RFC6232] when specifying in which PDUs
   the POI TLV is allowed.  Section 3 of [RFC6232] stated:

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

   However, the IANA section of the same document stated:

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

   The correct setting for "LSP" is "n".  This document corrects that
   error.

4.  TLV Validation and LSP Acceptance

   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.

   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.

Ginsberg, et al.          Expires June 5, 2019                  [Page 5]
Internet-Draft     draft-ginsberg-lsr-isis-invalid-tlv     December 2018

   LSP Acceptance rules are specified in [ISO10589] .  Acceptance rules
   for LSP purges are extended by [RFC5304] [RFC5310] and further
   extended by [RFC6233].

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

5.  IANA Considerations

   IANA is requested to update the TLV Codepoints Registry to reference
   this document.

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

   IIH:n, LSP:n, SNP:n, and Purge:y.

6.  Security Considerations

   As this document makes no changes to the protocol there are no new
   security issues introduced.

   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.

   Security concerns for IS-IS are discussed in [ISO10589], [RFC5304],
   and [RFC5310].

7.  Acknowledgements

   The authors would like to thank Alvaro Retana.

8.  References

8.1.  Normative References

   [ISO10589]
              International Organization for Standardization,
              "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)", ISO/
              IEC 10589:2002, Second Edition, Nov 2002.

Ginsberg, et al.          Expires June 5, 2019                  [Page 6]
Internet-Draft     draft-ginsberg-lsr-isis-invalid-tlv     December 2018

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3563]  Zinin, A., "Cooperative Agreement Between the ISOC/IETF
              and ISO/IEC Joint Technical Committee 1/Sub Committee 6
              (JTC1/SC6) on IS-IS Routing Protocol Development",
              RFC 3563, DOI 10.17487/RFC3563, July 2003,
              <https://www.rfc-editor.org/info/rfc3563>.

   [RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
              Authentication", RFC 5304, DOI 10.17487/RFC5304, October
              2008, <https://www.rfc-editor.org/info/rfc5304>.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, DOI 10.17487/RFC5305, October
              2008, <https://www.rfc-editor.org/info/rfc5305>.

   [RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
              and M. Fanto, "IS-IS Generic Cryptographic
              Authentication", RFC 5310, DOI 10.17487/RFC5310, February
              2009, <https://www.rfc-editor.org/info/rfc5310>.

   [RFC6232]  Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge
              Originator Identification TLV for IS-IS", RFC 6232,
              DOI 10.17487/RFC6232, May 2011,
              <https://www.rfc-editor.org/info/rfc6232>.

   [RFC6233]  Li, T. and L. Ginsberg, "IS-IS Registry Extension for
              Purges", RFC 6233, DOI 10.17487/RFC6233, May 2011,
              <https://www.rfc-editor.org/info/rfc6233>.

   [RFC7356]  Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
              Scope Link State PDUs (LSPs)", RFC 7356,
              DOI 10.17487/RFC7356, September 2014,
              <https://www.rfc-editor.org/info/rfc7356>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [TLV_CODEPOINTS]
              IANA, "IS-IS TLV Codepoints web page
              (https://www.iana.org/assignments/isis-tlv-codepoints/
              isis-tlv-codepoints.xhtml)".

Ginsberg, et al.          Expires June 5, 2019                  [Page 7]
Internet-Draft     draft-ginsberg-lsr-isis-invalid-tlv     December 2018

8.2.  Informative References

   [RFC3359]  Przygienda, T., "Reserved Type, Length and Value (TLV)
              Codepoints in Intermediate System to Intermediate System",
              RFC 3359, DOI 10.17487/RFC3359, August 2002,
              <https://www.rfc-editor.org/info/rfc3359>.

Authors' Addresses

   Les Ginsberg
   Cisco Systems

   Email: ginsberg@cisco.com

   Paul Wells
   Cisco Systems

   Email: pauwells@cisco.com

   Tony Li
   Arista Networks
   5453 Great America Parkway
   Santa Clara, California  95054
   USA

   Email: tony.li@tony.li

   Tony Przygienda
   Juniper Networks, Inc.
   1194 N. Matilda Ave
   Sunnyvale, California  94089
   USA

   Email: prz@juniper.net

   Shraddha Hegde
   Juniper Networks, Inc.
   Embassy Business Park
   Bangalore, KA  560093
   India

   Email: shraddha@juniper.net

Ginsberg, et al.          Expires June 5, 2019                  [Page 8]