Invalid TLV Handling in
IS-ISCisco Systemsginsberg@cisco.comCisco Systemspauwells@cisco.comArista Networks5453 Great America ParkwaySanta ClaraCalifornia95054USAtony.li@tony.liJuniper Networks, Inc.1194 N. Matilda AveSunnyvaleCalifornia94089USAprz@juniper.netJuniper Networks, Inc.Embassy Business ParkBangaloreKA560093Indiashraddha@juniper.net
Routing
LSR Working GroupInternet-DraftTLVIS-ISKey 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.This document discusses such cases and makes the correct behavior
explicit in order to ensure that interoperability is maximized.This document updates RFC5305 and RFC6232.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.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.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 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) which 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 RFC 5305 (see Section
3.3) and RFC 6232 (see Section 3.4). established the IANA-managed IS-IS TLV
Codepoints Registry for recording assigned TLV code points . 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 (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 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.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. defines the behavior required when a PDU
is received containing a TLV which is "not recognised". It states (see
Sections 9.5 - 9.13):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.When purging LSPs, 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 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: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 which are allowed in
purges.The behavior specified in is not backwards
compatible with the behavior defined by and
therefore 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 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. 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. Section 2 of is updated by the following sentence:The existing sentence in Section 2 of
:is replaced by:An error was introduced by when specifying
in which PDUs the POI TLV is allowed. Section 3 of stated:However, the IANA section of the same document stated:The correct setting for "LSP" is "n". This document updates by correcting that error.This document also updates the previously quoted text from Section
3 of to be: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 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 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.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 is requested to add this document as a reference for the TLV
Codepoints Registry.IANA is also requested to modify 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 should be updated to point to this document.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 implementation.Security concerns for IS-IS are discussed in , , and .The authors would like to thank Alvaro Retana.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
StandardizationIS-IS TLV Codepoints web page
(https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml)IANA