idnits 2.17.1 draft-ietf-lsr-isis-invalid-tlv-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5305, updated by this document, for RFC5378 checks: 2005-09-06) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 22, 2020) is 1397 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' ** Downref: Normative reference to an Informational RFC: RFC 3563 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LSR Working Group L. Ginsberg 3 Internet-Draft P. Wells 4 Updates: 5305 6232 (if approved) Cisco Systems 5 Intended status: Standards Track T. Li 6 Expires: December 24, 2020 Arista Networks 7 T. Przygienda 8 S. Hegde 9 Juniper Networks, Inc. 10 June 22, 2020 12 Invalid TLV Handling in IS-IS 13 draft-ietf-lsr-isis-invalid-tlv-02 15 Abstract 17 Key to the extensibility of the Intermediate System to Intermediate 18 System (IS-IS) protocol has been the handling of unsupported and/or 19 invalid Type/Length/Value (TLV) tuples. Although there are explicit 20 statements in existing specifications, deployment experience has 21 shown that there are inconsistencies in the behavior when a TLV which 22 is disallowed in a particular Protocol Data Unit (PDU) is received. 24 This document discusses such cases and makes the correct behavior 25 explicit in order to insure that interoperability is maximized. 27 This document updates RFC5305 and RFC6232. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 33 "OPTIONAL" in this document are to be interpreted as described in BCP 34 14 [RFC2119] [RFC8174] when, and only when, they appear in all 35 capitals, as shown here. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on December 24, 2020. 54 Copyright Notice 56 Copyright (c) 2020 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. TLV Codepoints Registry . . . . . . . . . . . . . . . . . . . 3 73 3. TLV Acceptance in PDUs . . . . . . . . . . . . . . . . . . . 4 74 3.1. Handling of Disallowed TLVs in Received PDUs other than 75 LSP Purges . . . . . . . . . . . . . . . . . . . . . . . 4 76 3.2. Special Handling of Disallowed TLVs in Received LSP 77 Purges . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3.3. Applicability to sub-TLVs . . . . . . . . . . . . . . . . 5 79 3.4. Correction to POI TLV Registry Entry . . . . . . . . . . 5 80 4. TLV Validation and LSP Acceptance . . . . . . . . . . . . . . 5 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 85 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 86 8.2. Informative References . . . . . . . . . . . . . . . . . 8 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 89 1. Introduction 91 The Intermediate System to Intermediate System (IS-IS) protocol 92 [ISO10589] utilizes Type/Length/Value (TLV) encoding for all content 93 in the body of Protocol Data Units (PDUs). New extensions to the 94 protocol are supported by defining new TLVs. In order to allow 95 protocol extensions to be deployed in a backwards compatible way an 96 implementation is required to ignore TLVs that it does not 97 understand. This behavior is also applied to sub-TLVs [RFC5305], 98 which are contained within TLVs. 100 A corollary to ignoring unknown TLVs is having the validation of PDUs 101 be independent from the validation of the TLVs contained in the PDU. 102 PDUs which are valid must be accepted [ISO10589] even if an 103 individual TLV contained within that PDU is invalid in some way 104 (e.g., incorrect syntax, data value out of range, etc.). 106 The set of TLVs (and sub-TLVs) which are allowed in each PDU type is 107 documented in the TLV Codepoints Registry established by [RFC3563] 108 and updated by [RFC6233] and [RFC7356]. 110 This document is intended to clarify some aspects of existing 111 specifications and thereby reduce the occurrence of non-conformant 112 behavior seen in real world deployments. Although behaviors 113 specified in existing protocol specifications are not changed, the 114 clarifications contained in this document serve as updates to RFC 115 5305 (see Section 3.3) and RFC 6232 (see Section 3.4). 117 2. TLV Codepoints Registry 119 [RFC3563] established the IANA-managed IS-IS TLV Codepoints Registry 120 for recording assigned TLV code points [TLV_CODEPOINTS]. The initial 121 contents of this registry were based on [RFC3359]. 123 The registry includes a set of columns indicating in which PDU types 124 a given TLV is allowed: 126 IIH - TLV is allowed in Intermediate System to Intermediate System 127 Hello (IIH) PDUs (Point-to-point and LAN) 129 LSP - TLV is allowed in Link State PDUs (LSP) 131 SNP - TLV is allowed in Sequence Number PDUs (SNP) (Partial Sequence 132 Number PDUs (PSNP) and Complete Sequence Number PDUS (CSNP)) 134 Purge - TLV is allowed in LSP Purges [RFC6233] 136 If "Y" is entered in a column it means the TLV is allowed in the 137 corresponding PDU type. 139 If "N" is entered in a column it means the TLV is not allowed in the 140 corresponding PDU type. 142 3. TLV Acceptance in PDUs 144 This section describes the correct behavior when a PDU is received 145 which contains a TLV which is specified as disallowed in the TLV 146 Codepoints Registry. 148 3.1. Handling of Disallowed TLVs in Received PDUs other than LSP Purges 150 [ISO10589] defines the behavior required when a PDU is received 151 containing a TLV which is "not recognised". It states (see Sections 152 9.3 - 9.13): 154 "Any codes in a received PDU that are not 155 recognised shall be ignored." 157 This is the model to be followed when a TLV is received which is 158 disallowed. Therefore TLVs in a PDU (other than LSP purges) which 159 are disallowed MUST be ignored and MUST NOT cause the PDU itself to 160 be rejected by the receiving IS. 162 3.2. Special Handling of Disallowed TLVs in Received LSP Purges 164 When purging LSPs, [ISO10589] recommends (but does not require) the 165 body of the LSP (i.e., all TLVs) be removed before generating the 166 purge. LSP purges which have TLVs in the body are accepted though 167 any TLVs which are present are ignored. 169 When cryptographic authentication [RFC5304] was introduced, this 170 looseness when processing received purges had to be addressed in 171 order to prevent attackers from being able to initiate a purge 172 without having access to the authentication key. [RFC5304] therefore 173 imposed strict requirements on what TLVs were allowed in a purge 174 (authentication only) and specified that: 176 "ISes MUST NOT accept purges that contain TLVs 177 other than the authentication TLV". 179 This behavior was extended by [RFC6232] which introduced the Purge 180 Originator Identification (POI) TLV and [RFC6233] which added the 181 "Purge" column to the TLV Codepoints registry to identify all the 182 TLVs which are allowed in purges. 184 The behavior specified in [RFC5304] is not backwards compatible with 185 the behavior defined by [ISO10589] and therefore can only be safely 186 enabled when all nodes support cryptographic authentication. 187 Similarly, the extensions defined by [RFC6233] are not compatible 188 with the behavior defined in [RFC5304], therefore can only be safely 189 enabled when all nodes support the extensions. 191 It is RECOMMENDED that implementations provide controls for the 192 enablement of behaviors that are not backward compatible. 194 3.3. Applicability to sub-TLVs 196 [RFC5305] introduced sub-TLVs, which are TLV tuples advertised within 197 the body of a parent TLV. Registries associated with sub-TLVs are 198 associated with the TLV Codepoints Registry and specify in which TLVs 199 a given sub-TLV is allowed. Section 2 of [RFC5305] is updated by the 200 following sentence: 202 "As with TLVs, it is required that sub-TLVs which 203 are disallowed MUST be ignored on receipt.". 205 The existing sentence in Section 2 of [RFC5305] : 207 "Unknown sub-TLVs are to be ignored and skipped upon 208 receipt." 210 is replaced by: 212 "Unknown sub-TLVs MUST be ignored and skipped upon 213 receipt." 215 3.4. Correction to POI TLV Registry Entry 217 An error was introduced by [RFC6232] when specifying in which PDUs 218 the POI TLV is allowed. Section 3 of [RFC6232] stated: 220 "The POI TLV SHOULD be found in all purges and 221 MUST NOT be found in LSPs with a non-zero 222 Remaining Lifetime." 224 However, the IANA section of the same document stated: 226 "The additional values for this TLV should be 227 IIH:n, LSP:y, SNP:n, and Purge:y." 229 The correct setting for "LSP" is "n". This document updates 230 [RFC6232] by correcting that error. 232 4. TLV Validation and LSP Acceptance 234 The correct format of a TLV and its associated sub-TLVs, if 235 applicable, are defined in the document(s) which introduce each 236 codepoint. The definition MUST include what action to take when the 237 format/content of the TLV does not conform to the specification 238 (e.g., "MUST be ignored on receipt"). When making use of the 239 information encoded in a given TLV (or sub-TLV) receiving nodes MUST 240 verify that the TLV conforms to the standard definition. This 241 includes cases where the length of a TLV/sub-TLV is incorrect and/or 242 cases where the value field does not conform to the defined 243 restrictions. 245 However, the unit of flooding for the IS-IS Update process is an LSP. 246 The presence of a TLV (or sub-TLV) with content which does not 247 conform to the relevant specification MUST NOT cause the LSP itself 248 to be rejected. Failure to follow this requirement will result in 249 inconsistent LSP Databases on different nodes in the network which 250 will compromise the correct operation of the protocol. 252 LSP Acceptance rules are specified in [ISO10589] . Acceptance rules 253 for LSP purges are extended by [RFC5304] and [RFC5310] and are 254 further extended by [RFC6233]. 256 [ISO10589] also specifies the behavior when an LSP is not accepted. 257 This behavior is NOT altered by extensions to the LSP Acceptance 258 rules i.e., regardless of the reason for the rejection of an LSP the 259 Update process on the receiving router takes the same action. 261 5. IANA Considerations 263 IANA is requested to add this document as a reference for the TLV 264 Codepoints Registry. 266 IANA is also requested to modify the entry for the Purge Originator 267 Identification TLV in the TLV Codepoints Registry to be: 269 IIH:n, LSP:n, SNP:n, and Purge:y. 271 The reference field should be updated to point to this document. 273 6. Security Considerations 275 As this document makes no changes to the protocol there are no new 276 security issues introduced. 278 The clarifications discussed in this document are intended to make it 279 less likely that implementations will incorrectly process received 280 LSPs, thereby also making it less likely that a bad actor could 281 exploit a faulty implementation. 283 Security concerns for IS-IS are discussed in [ISO10589], [RFC5304], 284 and [RFC5310]. 286 7. Acknowledgements 288 The authors would like to thank Alvaro Retana. 290 8. References 292 8.1. Normative References 294 [ISO10589] 295 International Organization for Standardization, 296 "Intermediate system to Intermediate system intra-domain 297 routeing information exchange protocol for use in 298 conjunction with the protocol for providing the 299 connectionless-mode Network Service (ISO 8473)", ISO/ 300 IEC 10589:2002, Second Edition, Nov 2002. 302 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 303 Requirement Levels", BCP 14, RFC 2119, 304 DOI 10.17487/RFC2119, March 1997, 305 . 307 [RFC3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF 308 and ISO/IEC Joint Technical Committee 1/Sub Committee 6 309 (JTC1/SC6) on IS-IS Routing Protocol Development", 310 RFC 3563, DOI 10.17487/RFC3563, July 2003, 311 . 313 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 314 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 315 2008, . 317 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 318 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 319 2008, . 321 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 322 and M. Fanto, "IS-IS Generic Cryptographic 323 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 324 2009, . 326 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 327 Originator Identification TLV for IS-IS", RFC 6232, 328 DOI 10.17487/RFC6232, May 2011, 329 . 331 [RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for 332 Purges", RFC 6233, DOI 10.17487/RFC6233, May 2011, 333 . 335 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 336 Scope Link State PDUs (LSPs)", RFC 7356, 337 DOI 10.17487/RFC7356, September 2014, 338 . 340 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 341 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 342 May 2017, . 344 [TLV_CODEPOINTS] 345 IANA, "IS-IS TLV Codepoints web page 346 (https://www.iana.org/assignments/isis-tlv-codepoints/ 347 isis-tlv-codepoints.xhtml)". 349 8.2. Informative References 351 [RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV) 352 Codepoints in Intermediate System to Intermediate System", 353 RFC 3359, DOI 10.17487/RFC3359, August 2002, 354 . 356 Authors' Addresses 358 Les Ginsberg 359 Cisco Systems 361 Email: ginsberg@cisco.com 363 Paul Wells 364 Cisco Systems 366 Email: pauwells@cisco.com 368 Tony Li 369 Arista Networks 370 5453 Great America Parkway 371 Santa Clara, California 95054 372 USA 374 Email: tony.li@tony.li 375 Tony Przygienda 376 Juniper Networks, Inc. 377 1194 N. Matilda Ave 378 Sunnyvale, California 94089 379 USA 381 Email: prz@juniper.net 383 Shraddha Hegde 384 Juniper Networks, Inc. 385 Embassy Business Park 386 Bangalore, KA 560093 387 India 389 Email: shraddha@juniper.net