idnits 2.17.1 draft-ietf-lsr-isis-invalid-tlv-03.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 (July 26, 2020) is 1362 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: January 27, 2021 Arista Networks 7 T. Przygienda 8 S. Hegde 9 Juniper Networks, Inc. 10 July 26, 2020 12 Invalid TLV Handling in IS-IS 13 draft-ietf-lsr-isis-invalid-tlv-03 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 ensure 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 January 27, 2021. 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 . . . . . . . . . . . . . . 6 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 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 Also essential to the correct operation of the protocol is having the 101 validation of PDUs be independent from the validation of the TLVs 102 contained in the PDU. PDUs which are valid must be accepted 103 [ISO10589] even if an individual TLV contained within that PDU is not 104 understood or is invalid in some way (e.g., incorrect syntax, data 105 value out of range, etc.). 107 The set of TLVs (and sub-TLVs) which are allowed in each PDU type is 108 documented in the TLV Codepoints Registry established by [RFC3563] 109 and updated by [RFC6233] and [RFC7356]. 111 This document is intended to clarify some aspects of existing 112 specifications and thereby reduce the occurrence of non-conformant 113 behavior seen in real world deployments. Although behaviors 114 specified in existing protocol specifications are not changed, the 115 clarifications contained in this document serve as updates to RFC 116 5305 (see Section 3.3) and RFC 6232 (see Section 3.4). 118 2. TLV Codepoints Registry 120 [RFC3563] established the IANA-managed IS-IS TLV Codepoints Registry 121 for recording assigned TLV code points [TLV_CODEPOINTS]. The initial 122 contents of this registry were based on [RFC3359]. 124 The registry includes a set of columns indicating in which PDU types 125 a given TLV is allowed: 127 IIH - TLV is allowed in Intermediate System to Intermediate System 128 Hello (IIH) PDUs (Point-to-point and LAN) 130 LSP - TLV is allowed in Link State PDUs (LSP) 132 SNP - TLV is allowed in Sequence Number PDUs (SNP) (Partial Sequence 133 Number PDUs (PSNP) and Complete Sequence Number PDUS (CSNP)) 135 Purge - TLV is allowed in LSP Purges [RFC6233] 137 If "Y" is entered in a column it means the TLV is allowed in the 138 corresponding PDU type. 140 If "N" is entered in a column it means the TLV is not allowed in the 141 corresponding PDU type. 143 3. TLV Acceptance in PDUs 145 This section describes the correct behavior when a PDU is received 146 which contains a TLV which is specified as disallowed in the TLV 147 Codepoints Registry. 149 3.1. Handling of Disallowed TLVs in Received PDUs other than LSP Purges 151 [ISO10589] defines the behavior required when a PDU is received 152 containing a TLV which is "not recognised". It states (see Sections 153 9.5 - 9.13): 155 "Any codes in a received PDU that are not 156 recognised shall be ignored." 158 This is the model to be followed when a TLV is received which is 159 disallowed. Therefore TLVs in a PDU (other than LSP purges) which 160 are disallowed MUST be ignored and MUST NOT cause the PDU itself to 161 be rejected by the receiving IS. 163 3.2. Special Handling of Disallowed TLVs in Received LSP Purges 165 When purging LSPs, [ISO10589] recommends (but does not require) the 166 body of the LSP (i.e., all TLVs) be removed before generating the 167 purge. LSP purges which have TLVs in the body are accepted though 168 any TLVs which are present are ignored. 170 When cryptographic authentication [RFC5304] was introduced, this 171 looseness when processing received purges had to be addressed in 172 order to prevent attackers from being able to initiate a purge 173 without having access to the authentication key. [RFC5304] therefore 174 imposed strict requirements on what TLVs were allowed in a purge 175 (authentication only) and specified that: 177 "ISes MUST NOT accept purges that contain TLVs 178 other than the authentication TLV". 180 This behavior was extended by [RFC6232] which introduced the Purge 181 Originator Identification (POI) TLV and [RFC6233] which added the 182 "Purge" column to the TLV Codepoints registry to identify all the 183 TLVs which are allowed in purges. 185 The behavior specified in [RFC5304] is not backwards compatible with 186 the behavior defined by [ISO10589] and therefore can only be safely 187 enabled when all nodes support cryptographic authentication. 188 Similarly, the extensions defined by [RFC6232] are not compatible 189 with the behavior defined in [RFC5304], therefore can only be safely 190 enabled when all nodes support the extensions. 192 When new protocol behaviors are specified that are not backwards 193 compatible, it is RECOMMENDED that implementations provide controls 194 for their enablement. This serves to prevent interoperability issues 195 and allow for non-disruptive introduction of the new functionality 196 into an existing network. 198 3.3. Applicability to sub-TLVs 200 [RFC5305] introduced sub-TLVs, which are TLV tuples advertised within 201 the body of a parent TLV. Registries associated with sub-TLVs are 202 associated with the TLV Codepoints Registry and specify in which TLVs 203 a given sub-TLV is allowed. Section 2 of [RFC5305] is updated by the 204 following sentence: 206 "As with TLVs, it is required that sub-TLVs which 207 are disallowed MUST be ignored on receipt.". 209 The existing sentence in Section 2 of [RFC5305] : 211 "Unknown sub-TLVs are to be ignored and skipped upon 212 receipt." 214 is replaced by: 216 "Unknown sub-TLVs MUST be ignored and skipped upon 217 receipt." 219 3.4. Correction to POI TLV Registry Entry 221 An error was introduced by [RFC6232] when specifying in which PDUs 222 the POI TLV is allowed. Section 3 of [RFC6232] stated: 224 "The POI TLV SHOULD be found in all purges and 225 MUST NOT be found in LSPs with a non-zero 226 Remaining Lifetime." 228 However, the IANA section of the same document stated: 230 "The additional values for this TLV should be 231 IIH:n, LSP:y, SNP:n, and Purge:y." 233 The correct setting for "LSP" is "n". This document updates 234 [RFC6232] by correcting that error. 236 This document also updates the previously quoted text from Section 3 237 of [RFC6232] to be: 239 "The POI TLV SHOULD be sent in all purges and 240 MUST NOT be sent in LSPs with a non-zero 241 Remaining Lifetime." 243 4. TLV Validation and LSP Acceptance 245 The correct format of a TLV and its associated sub-TLVs, if 246 applicable, are defined in the document(s) which introduce each 247 codepoint. The definition MUST include what action to take when the 248 format/content of the TLV does not conform to the specification 249 (e.g., "MUST be ignored on receipt"). When making use of the 250 information encoded in a given TLV (or sub-TLV) receiving nodes MUST 251 verify that the TLV conforms to the standard definition. This 252 includes cases where the length of a TLV/sub-TLV is incorrect and/or 253 cases where the value field does not conform to the defined 254 restrictions. 256 However, the unit of flooding for the IS-IS Update process is an LSP. 257 The presence of a TLV (or sub-TLV) with content which does not 258 conform to the relevant specification MUST NOT cause the LSP itself 259 to be rejected. Failure to follow this requirement will result in 260 inconsistent LSP Databases on different nodes in the network which 261 will compromise the correct operation of the protocol. 263 LSP Acceptance rules are specified in [ISO10589] . Acceptance rules 264 for LSP purges are extended by [RFC5304] and [RFC5310] and are 265 further extended by [RFC6233]. 267 [ISO10589] also specifies the behavior when an LSP is not accepted. 268 This behavior is NOT altered by extensions to the LSP Acceptance 269 rules i.e., regardless of the reason for the rejection of an LSP the 270 Update process on the receiving router takes the same action. 272 5. IANA Considerations 274 IANA is requested to add this document as a reference for the TLV 275 Codepoints Registry. 277 IANA is also requested to modify the entry for the Purge Originator 278 Identification TLV in the TLV Codepoints Registry to be: 280 IIH:n, LSP:n, SNP:n, and Purge:y. 282 The reference field should be updated to point to this document. 284 6. Security Considerations 286 As this document makes no changes to the protocol there are no new 287 security issues introduced. 289 The clarifications discussed in this document are intended to make it 290 less likely that implementations will incorrectly process received 291 LSPs, thereby also making it less likely that a bad actor could 292 exploit a faulty implementation. 294 Security concerns for IS-IS are discussed in [ISO10589], [RFC5304], 295 and [RFC5310]. 297 7. Acknowledgements 299 The authors would like to thank Alvaro Retana. 301 8. References 303 8.1. Normative References 305 [ISO10589] 306 International Organization for Standardization, 307 "Intermediate system to Intermediate system intra-domain 308 routeing information exchange protocol for use in 309 conjunction with the protocol for providing the 310 connectionless-mode Network Service (ISO 8473)", ISO/ 311 IEC 10589:2002, Second Edition, Nov 2002. 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, 315 DOI 10.17487/RFC2119, March 1997, 316 . 318 [RFC3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF 319 and ISO/IEC Joint Technical Committee 1/Sub Committee 6 320 (JTC1/SC6) on IS-IS Routing Protocol Development", 321 RFC 3563, DOI 10.17487/RFC3563, July 2003, 322 . 324 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 325 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 326 2008, . 328 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 329 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 330 2008, . 332 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 333 and M. Fanto, "IS-IS Generic Cryptographic 334 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 335 2009, . 337 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 338 Originator Identification TLV for IS-IS", RFC 6232, 339 DOI 10.17487/RFC6232, May 2011, 340 . 342 [RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for 343 Purges", RFC 6233, DOI 10.17487/RFC6233, May 2011, 344 . 346 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 347 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 348 May 2017, . 350 [TLV_CODEPOINTS] 351 IANA, "IS-IS TLV Codepoints web page 352 (https://www.iana.org/assignments/isis-tlv-codepoints/ 353 isis-tlv-codepoints.xhtml)". 355 8.2. Informative References 357 [RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV) 358 Codepoints in Intermediate System to Intermediate System", 359 RFC 3359, DOI 10.17487/RFC3359, August 2002, 360 . 362 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 363 Scope Link State PDUs (LSPs)", RFC 7356, 364 DOI 10.17487/RFC7356, September 2014, 365 . 367 Authors' Addresses 369 Les Ginsberg 370 Cisco Systems 372 Email: ginsberg@cisco.com 374 Paul Wells 375 Cisco Systems 377 Email: pauwells@cisco.com 378 Tony Li 379 Arista Networks 380 5453 Great America Parkway 381 Santa Clara, California 95054 382 USA 384 Email: tony.li@tony.li 386 Tony Przygienda 387 Juniper Networks, Inc. 388 1194 N. Matilda Ave 389 Sunnyvale, California 94089 390 USA 392 Email: prz@juniper.net 394 Shraddha Hegde 395 Juniper Networks, Inc. 396 Embassy Business Park 397 Bangalore, KA 560093 398 India 400 Email: shraddha@juniper.net