Invalid TLV Handling in IS-ISCisco Systemsginsberg@cisco.comCisco Systemspauwells@cisco.comArista Networks5453 Great America ParkwaySanta ClaraCA95054United States of Americatony.li@tony.liJuniper Networks, Inc.1194 N. Matilda AveSunnyvaleCA94089United States of Americaprz@juniper.netJuniper Networks, Inc.Embassy Business ParkBangaloreKA560093Indiashraddha@juniper.net
Routing
LSR Working GroupTLVIS-ISThe 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 that is
disallowed in a particular Protocol Data Unit (PDU) is received.This document discusses such cases and makes the correct behavior
explicit in order to ensure that interoperability is maximized.This document updates RFCs 5305 and 6232.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2020 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
() 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
. Introduction
. Requirements Language
. TLV Codepoints Registry
. TLV Acceptance in PDUs
. Handling of Disallowed TLVs in Received PDUs Other Than LSP
Purges
. Special Handling of Disallowed TLVs in Received LSP Purges
. Applicability to Sub-TLVs
. Correction to POI "TLV Codepoints Registry" Entry
. TLV Validation and LSP Acceptance
. IANA Considerations
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
IntroductionThe 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.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 that are valid must be accepted 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.).The set of TLVs (and sub-TLVs) that are allowed in each PDU type is
documented in the "TLV Codepoints Registry" established by and updated by and .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
(see ) and (see ).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
when, and only when, they appear in all capitals, as shown here.
TLV Codepoints Registry established the
IANA-managed "IS-IS TLV Codepoints Registry" for recording assigned TLV
codepoints . The
initial contents of this registry were based on .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 (LSPs)
SNP
TLV is allowed in Sequence Number PDUs (SNPs) (Partial Sequence
Number PDUs (PSNPs) and Complete Sequence Number PDUs (CSNPs))
Purge
TLV is allowed in LSP Purges
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.TLV Acceptance in PDUsThis section describes the correct behavior when a PDU
that contains a TLV that is specified as disallowed in the "TLV
Codepoints Registry" is received.Handling of Disallowed TLVs in Received PDUs Other Than LSP
Purges defines the behavior
required when a PDU is received containing a TLV that is "not
recognised". It states (see Sections 9.5 - 9.13):
Any codes in a received PDU that are not recognised shall be ignored.
This is the model to be followed when a TLV that is disallowed is
received. Therefore, TLVs in a PDU (other than LSP purges) that are
disallowed MUST be ignored and MUST NOT
cause the PDU itself to be rejected by the receiving IS.Special Handling of Disallowed TLVs in Received LSP PurgesWhen purging LSPs,
recommends (but does not require) the body of the LSP (i.e., all TLVs)
be removed before generating the purge. LSP purges that have TLVs in
the body are accepted, though any TLVs that are present are
ignored.When cryptographic authentication 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, 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 , which introduced the Purge Originator
Identification (POI) TLV, and ,
which added the "Purge" column to the "TLV Codepoints Registry" to
identify all the TLVs that are allowed in purges.The behavior specified in
is not backwards compatible with the behavior defined by ; therefore, it can only be safely
enabled when all nodes support cryptographic
authentication. Similarly, the extensions defined by are not compatible with the
behavior defined in ;
therefore, they can only be safely enabled when all nodes support the
extensions.When new protocol behaviors are specified that are not backwards
compatible, it is RECOMMENDED 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.Applicability to Sub-TLVs 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. is
updated by the following sentence:
As with TLVs, it is required that sub-TLVs that are disallowed
MUST be ignored on receipt.
The existing sentence in :
Unknown sub-TLVs are to be ignored and skipped upon receipt.
is replaced by:
Unknown sub-TLVs MUST be ignored and skipped upon receipt.
Correction to POI "TLV Codepoints Registry" EntryAn error was introduced by when specifying in which PDUs the POI TLV is
allowed.
states:
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 states:
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 updates by correcting that error.This document also updates the previously quoted text from to be:
The POI TLV SHOULD be sent in all purges and MUST NOT be sent in LSPs with a non-zero Remaining Lifetime.
TLV Validation and LSP AcceptanceThe correct format of a TLV and its associated sub-TLVs, if
applicable, is defined in the document(s) that introduces each
codepoint. The definition MUST 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 that 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
that will compromise the correct operation of the protocol.LSP Acceptance rules are specified in . Acceptance rules for LSP purges are extended by
and and are further extended by . 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.IANA ConsiderationsIANA has added this document as a reference for the "TLV
Codepoints Registry".IANA has also modified the entry for the Purge Originator
Identification TLV in the "TLV Codepoints Registry" to be IIH:n, LSP:n,
SNP:n, and Purge:y.The reference field of the Purge Originator Identification
TLV has been updated to point to this document.Security ConsiderationsAs 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 implementation.Security concerns for IS-IS are discussed in , , and .ReferencesNormative ReferencesInformation technology -- Telecommunications and information exchange between systems -- 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)International Organization for StandardizationKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Cooperative Agreement Between the ISOC/IETF and ISO/IEC Joint Technical Committee 1/Sub Committee 6 (JTC1/SC6) on IS-IS Routing Protocol DevelopmentThis document contains the text of the agreement signed between ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the IS-IS routing protocol. The agreement includes definitions of the related work scopes for the two organizations, request for creation and maintenance of an IS-IS registry by IANA, as well as collaboration guidelines. This memo provides information for the Internet community.IS-IS Cryptographic AuthenticationThis document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567.This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. [STANDARDS-TRACK]IS-IS Extensions for Traffic EngineeringThis document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for traffic engineering computations. [STANDARDS-TRACK]IS-IS Generic Cryptographic AuthenticationThis document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195.Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK]Purge Originator Identification TLV for IS-ISAt present, an IS-IS purge does not contain any information identifying the Intermediate System (IS) that generates the purge. This makes it difficult to locate the source IS.To address this issue, this document defines a TLV to be added to purges to record the system ID of the IS generating it. Since normal Link State Protocol Data Unit (LSP) flooding does not change LSP contents, this TLV should propagate with the purge.This document updates RFC 5301, RFC 5304, and RFC 5310. [STANDARDS-TRACK]IS-IS Registry Extension for PurgesIANA maintains the "IS-IS TLV Codepoints" registry. This registry documents which TLVs can appear in different types of IS-IS Protocol Data Units (PDUs), but does not document which TLVs can be found in zero Remaining Lifetime Link State PDUs (LSPs), a.k.a. purges. This document extends the existing registry to record the set of TLVs that are permissible in purges and updates the rules for generating and processing purges in the presence of authentication. This document updates RFC 3563, RFC 5304, and RFC 5310. [STANDARDS-TRACK]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.IS-IS TLV CodepointsIANAInformative ReferencesReserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate SystemIS-IS Flooding Scope Link State PDUs (LSPs)Intermediate System to Intermediate System (IS-IS) provides efficient and reliable flooding of information to its peers; however, the current flooding scopes are limited to either area scope or domain scope. There are existing use cases where support of other flooding scopes is desirable. This document defines new Protocol Data Units (PDUs) that provide support for new flooding scopes as well as additional space for advertising information targeted for the currently supported flooding scopes. This document also defines extended Type-Length-Values (TLVs) and sub-TLVs that are encoded using 16-bit fields for Type and Length.The protocol extensions defined in this document are not backwards compatible with existing implementations and so must be deployed with care.AcknowledgementsThe authors would like to thank .Authors' AddressesCisco Systemsginsberg@cisco.comCisco Systemspauwells@cisco.comArista Networks5453 Great America ParkwaySanta ClaraCA95054United States of Americatony.li@tony.liJuniper Networks, Inc.1194 N. Matilda AveSunnyvaleCA94089United States of Americaprz@juniper.netJuniper Networks, Inc.Embassy Business ParkBangaloreKA560093Indiashraddha@juniper.net