| LSR Working Group | L. Ginsberg |
| Internet-Draft | P. Wells |
| Updates: 3563 5305 6233 (if approved) | Cisco Systems |
| Intended status: Standards Track | October 19, 2018 |
| Expires: April 22, 2019 |
Invalid TLV Handling in IS-IS
draft-ginsberg-lsr-isis-invalid-tlv-00
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
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 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 April 22, 2019.
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.
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 [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).
[RFC3563] 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 [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.
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 [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.
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 [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.
[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.
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 [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.
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 [ISO10589], [RFC5304], and [RFC5310].
The authors would like to thank Alvaro Retana.
| [RFC3359] | Przygienda, T., "Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System", RFC 3359, DOI 10.17487/RFC3359, August 2002. |