--- 1/draft-ietf-lsr-isis-invalid-tlv-02.txt 2020-07-26 18:13:10.582031223 -0700 +++ 2/draft-ietf-lsr-isis-invalid-tlv-03.txt 2020-07-26 18:13:10.606031834 -0700 @@ -1,35 +1,35 @@ LSR Working Group L. Ginsberg Internet-Draft P. Wells Updates: 5305 6232 (if approved) Cisco Systems Intended status: Standards Track T. Li -Expires: December 24, 2020 Arista Networks +Expires: January 27, 2021 Arista Networks T. Przygienda S. Hegde Juniper Networks, Inc. - June 22, 2020 + July 26, 2020 Invalid TLV Handling in IS-IS - draft-ietf-lsr-isis-invalid-tlv-02 + draft-ietf-lsr-isis-invalid-tlv-03 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, 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 insure that interoperability is maximized. + explicit in order to ensure that interoperability is maximized. This document updates RFC5305 and RFC6232. 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. @@ -42,21 +42,21 @@ 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 December 24, 2020. + This Internet-Draft will expire on January 27, 2021. 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -70,45 +70,46 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. TLV Codepoints Registry . . . . . . . . . . . . . . . . . . . 3 3. TLV Acceptance in PDUs . . . . . . . . . . . . . . . . . . . 4 3.1. Handling of Disallowed TLVs in Received PDUs other than LSP Purges . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Special Handling of Disallowed TLVs in Received LSP 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 + 4. TLV Validation and LSP Acceptance . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The Intermediate System to Intermediate System (IS-IS) protocol [ISO10589] 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 [RFC5305], 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 [ISO10589] even if an - individual TLV contained within that PDU is invalid in some way - (e.g., incorrect syntax, data value out of range, etc.). + 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 + [ISO10589] 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 [RFC3563] and updated by [RFC6233] and [RFC7356]. 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 @@ -142,21 +143,21 @@ 3. TLV Acceptance in PDUs 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. 3.1. Handling of Disallowed TLVs in Received PDUs other than LSP Purges [ISO10589] defines the behavior required when a PDU is received containing a TLV which is "not recognised". It states (see Sections - 9.3 - 9.13): + 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 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. 3.2. Special Handling of Disallowed TLVs in Received LSP Purges @@ -177,26 +178,29 @@ 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 + Similarly, the extensions defined by [RFC6232] are not compatible with the behavior defined in [RFC5304], therefore can only be safely enabled when all nodes support the extensions. - It is RECOMMENDED that implementations provide controls for the - enablement of behaviors that are not backward compatible. + 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. 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. Section 2 of [RFC5305] is updated by the following sentence: "As with TLVs, it is required that sub-TLVs which @@ -222,20 +226,27 @@ 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 updates [RFC6232] by correcting that error. + This document also updates the previously quoted text from Section 3 + of [RFC6232] to be: + + "The POI TLV SHOULD be sent in all purges and + MUST NOT be sent in LSPs with a non-zero + Remaining Lifetime." + 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 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 @@ -325,41 +336,41 @@ [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, . [RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for Purges", RFC 6233, DOI 10.17487/RFC6233, May 2011, . - [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding - Scope Link State PDUs (LSPs)", RFC 7356, - DOI 10.17487/RFC7356, September 2014, - . - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [TLV_CODEPOINTS] IANA, "IS-IS TLV Codepoints web page (https://www.iana.org/assignments/isis-tlv-codepoints/ isis-tlv-codepoints.xhtml)". 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, . + [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding + Scope Link State PDUs (LSPs)", RFC 7356, + DOI 10.17487/RFC7356, September 2014, + . + Authors' Addresses Les Ginsberg Cisco Systems Email: ginsberg@cisco.com Paul Wells Cisco Systems