Invalid TLV Handling
in IS-IS
Cisco Systems
ginsberg@cisco.com
Cisco Systems
pauwells@cisco.com
Routing
LSR Working Group
Internet-Draft
TLV
IS-IS
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, and
RFC6233.
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.
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 and . 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 and updated by and .
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).
established the IANA managed IS-IS TLV
Codepoints Registry for recording assigned TLV code points. The registry
can be found at
https://www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml
. 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 NOT allowed in the TLV
Codepoints Registry.
When a PDU is received and it contains a TLV which is NOT allowed
in that PDU the expected behavior is defined in 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.
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 "MUST" be 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 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.
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.
The correct format of a TLV and its associated sub-TLVs if applicable
are defined in the document(s) which introduce each codepoint.
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) the content of 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 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 update the TLV Codepoints Registry to reference
this document.
As this document makes no changes to the protocol there are no
security issues introduced.
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
Standardization