diff options
Diffstat (limited to 'doc/rfc/rfc8918.txt')
| -rw-r--r-- | doc/rfc/rfc8918.txt | 404 |
1 files changed, 404 insertions, 0 deletions
diff --git a/doc/rfc/rfc8918.txt b/doc/rfc/rfc8918.txt new file mode 100644 index 0000000..196ec6d --- /dev/null +++ b/doc/rfc/rfc8918.txt @@ -0,0 +1,404 @@ + + + + +Internet Engineering Task Force (IETF) L. Ginsberg +Request for Comments: 8918 P. Wells +Updates: 5305, 6232 Cisco Systems +Category: Standards Track T. Li +ISSN: 2070-1721 Arista Networks + T. Przygienda + S. Hegde + Juniper Networks, Inc. + September 2020 + + + Invalid TLV Handling in IS-IS + +Abstract + + The 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 + https://www.rfc-editor.org/info/rfc8918. + +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 + 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 + + 1. Introduction + 1.1. Requirements Language + 2. TLV Codepoints Registry + 3. TLV Acceptance in PDUs + 3.1. Handling of Disallowed TLVs in Received PDUs Other Than LSP + Purges + 3.2. Special Handling of Disallowed TLVs in Received LSP Purges + 3.3. Applicability to Sub-TLVs + 3.4. Correction to POI "TLV Codepoints Registry" Entry + 4. TLV Validation and LSP Acceptance + 5. IANA Considerations + 6. Security Considerations + 7. References + 7.1. Normative References + 7.2. Informative References + Acknowledgements + Authors' Addresses + +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. + + 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 + [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) that 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 + [RFC5305] (see Section 3.3) and [RFC6232] (see Section 3.4). + +1.1. 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. + +2. TLV Codepoints Registry + + [RFC3563] established the IANA-managed "IS-IS TLV Codepoints + Registry" for recording assigned TLV codepoints [TLV_CODEPOINTS]. + 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 (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 [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. + +3. TLV Acceptance in PDUs + + This section describes the correct behavior when a PDU that contains + a TLV that is specified as disallowed in the "TLV Codepoints + Registry" is received. + +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 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. + +3.2. Special Handling of Disallowed TLVs in Received LSP Purges + + 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 that have TLVs in the body are accepted, though + any TLVs that are present are 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. Therefore, + [RFC5304] 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 [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 that are allowed in purges. + + The behavior specified in [RFC5304] is not backwards compatible with + the behavior defined by [ISO10589]; therefore, it can only be safely + enabled when all nodes support cryptographic authentication. + Similarly, the extensions defined by [RFC6232] are not compatible + with the behavior defined in [RFC5304]; 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. + +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 that are disallowed + | MUST be ignored on receipt. + + The existing sentence in Section 2 of [RFC5305]: + + | Unknown sub-TLVs are to be ignored and skipped upon receipt. + + is replaced by: + + | Unknown sub-TLVs MUST be ignored and skipped upon receipt. + +3.4. Correction to POI "TLV Codepoints Registry" Entry + + An error was introduced by [RFC6232] when specifying in which PDUs + the POI TLV is allowed. Section 3 of [RFC6232] 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 + [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, 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 [ISO10589]. Acceptance rules + for LSP purges are extended by [RFC5304] and [RFC5310] and are + 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. + +5. IANA Considerations + + IANA 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. + +6. Security Considerations + + 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 [ISO10589], [RFC5304], + and [RFC5310]. + +7. References + +7.1. Normative References + + [ISO10589] International Organization for Standardization, + "Information 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)", ISO/IEC 10589:2002, Second Edition, + November 2002. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF + and ISO/IEC Joint Technical Committee 1/Sub Committee 6 + (JTC1/SC6) on IS-IS Routing Protocol Development", + RFC 3563, DOI 10.17487/RFC3563, July 2003, + <https://www.rfc-editor.org/info/rfc3563>. + + [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic + Authentication", RFC 5304, DOI 10.17487/RFC5304, October + 2008, <https://www.rfc-editor.org/info/rfc5304>. + + [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic + Engineering", RFC 5305, DOI 10.17487/RFC5305, October + 2008, <https://www.rfc-editor.org/info/rfc5305>. + + [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., + and M. Fanto, "IS-IS Generic Cryptographic + Authentication", RFC 5310, DOI 10.17487/RFC5310, February + 2009, <https://www.rfc-editor.org/info/rfc5310>. + + [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, + <https://www.rfc-editor.org/info/rfc6232>. + + [RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for + Purges", RFC 6233, DOI 10.17487/RFC6233, May 2011, + <https://www.rfc-editor.org/info/rfc6233>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [TLV_CODEPOINTS] + IANA, "IS-IS TLV Codepoints", + <https://www.iana.org/assignments/isis-tlv-codepoints/>. + +7.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, + <https://www.rfc-editor.org/info/rfc3359>. + + [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding + Scope Link State PDUs (LSPs)", RFC 7356, + DOI 10.17487/RFC7356, September 2014, + <https://www.rfc-editor.org/info/rfc7356>. + +Acknowledgements + + The authors would like to thank Alvaro Retana. + +Authors' Addresses + + Les Ginsberg + Cisco Systems + + Email: ginsberg@cisco.com + + + Paul Wells + Cisco Systems + + Email: pauwells@cisco.com + + + Tony Li + Arista Networks + 5453 Great America Parkway + Santa Clara, CA 95054 + United States of America + + Email: tony.li@tony.li + + + Tony Przygienda + Juniper Networks, Inc. + 1194 N. Matilda Ave + Sunnyvale, CA 94089 + United States of America + + Email: prz@juniper.net + + + Shraddha Hegde + Juniper Networks, Inc. + Embassy Business Park + Bangalore 560093 + KA + India + + Email: shraddha@juniper.net |