idnits 2.17.1 draft-ginsberg-lsr-isis-invalid-tlv-01.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6233, but the abstract doesn't seem to directly say this. It does mention RFC6233 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3563, updated by this document, for RFC5378 checks: 2002-10-24) -- 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 (December 2, 2018) is 1972 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 (==), 4 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: 3563 5305 6232 6233 (if Cisco Systems 5 approved) T. Li 6 Intended status: Standards Track Arista Networks 7 Expires: June 5, 2019 T. Przygienda 8 S. Hegde 9 Juniper Networks, Inc. 10 December 2, 2018 12 Invalid TLV Handling in IS-IS 13 draft-ginsberg-lsr-isis-invalid-tlv-01 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, in some cases the expected 21 behavior is "well known" but not explicitly stated. 23 This document discusses the "well known behaviors" and makes them 24 explicit in order to insure that interoperability is maximized. 26 This document when approved updates RFC3563, RFC5305, RFC6232, and 27 RFC6233. 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 June 5, 2019. 54 Copyright Notice 56 Copyright (c) 2018 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 . . . . . . 4 75 3.2. Special Handling of Disallowed TLVs in Received Purges . 4 76 3.3. Applicability to sub-TLVs . . . . . . . . . . . . . . . . 5 77 3.4. Correction to POI TLV Registry Entry . . . . . . . . . . 5 78 4. TLV Validation and LSP Acceptance . . . . . . . . . . . . . . 5 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 83 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 84 8.2. Informative References . . . . . . . . . . . . . . . . . 8 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 87 1. Introduction 89 The Intermediate System to Intermediate System (IS-IS) protocol 90 utilizes Type/Length/Value (TLV) encoding for all content in the body 91 of Protocol Data Units (PDUs). New extensions to the protocol are 92 supported by defining new TLVs. In order to allow protocol 93 extensions to be deployed in a backwards compatible way an 94 implementation is required to ignore TLVs that it does not 95 understand. This behavior is also applied to sub-TLVs, which are 96 contained within TLVs. 98 A corollary to ignoring unknown TLVs is having the validation of PDUs 99 be independent from the validation of the TLVs contained in the PDU. 100 PDUs which are valid MUST be accepted even if an individual TLV 101 contained within that PDU is invalid in some way. 103 These behaviors are specified in existing protocol documents - 104 principally [ISO10589] and [RFC5305]. In addition, the set of TLVs 105 (and sub-TLVs) which are allowed in each PDU type is documented in 106 the TLV Codepoints Registry ( https://www.iana.org/assignments/isis- 107 tlv-codepoints/isis-tlv-codepoints.xhtml ) established by [RFC3563] 108 and updated by [RFC6233] and [RFC7356]. 110 Nevertheless, a certain degree of "common knowledge" is assumed on 111 the part of implementors in regards to these behaviors. 113 This document serves to make explicit what is expected. While it 114 does not alter any existing protocol behavior or specifications, it 115 is intended to close any gaps between what is explicitly stated and 116 what has been "commonly understood". Although existing protocol 117 behavior is not changed, the clarifications contained in this 118 document serve as updates to RFC 3563 (see Section 2), RFC 5304, and 119 RFC 6233 (see Section 3). 121 2. TLV Codepoints Registry 123 [RFC3563] established the IANA managed IS-IS TLV Codepoints Registry 124 for recording assigned TLV code points [TLV_CODEPOINTS]. The initial 125 contents of this registry were based on [RFC3359]. 127 The registry includes a set of columns indicating in which PDU types 128 a given TLV is allowed: 130 IIH - TLV is allowed in Intermediate System to Intermediate System 131 Hello (IIH) PDUs (Point-to-point and LAN) 133 LSP - TLV is allowed in Link State PDUs (LSP) 135 SNP - TLV is allowed in Sequence Number PDUs (SNP) (Partial Sequence 136 Number PDUs (PSNP) and Complete Sequence Number PDUS (CSNP)) 138 Purge - TLV is allowed in LSP Purges [RFC6233] 140 If "Y" is entered in a column it means the TLV is allowed in the 141 corresponding PDU type. 143 If "N" is entered in a column it means the TLV is NOT allowed in the 144 corresponding PDU type. 146 3. TLV Acceptance in PDUs 148 This section describes the correct behavior when a PDU is received 149 which contains a TLV which is specified as NOT allowed in the TLV 150 Codepoints Registry. 152 3.1. Handling of Disallowed TLVs in Received PDUs 154 When a PDU is received and it contains a TLV which is NOT allowed in 155 that PDU the expected behavior is defined in [ISO10589] which states 156 (see Sections 9.3 - 9.13): 158 "Any codes in a received PDU that are not recognised shall be 159 ignored." 161 Therefore the presence of TLVs in a PDU which are not allowed MUST 162 NOT cause the PDU itself to be rejected by the receiving IS. 164 3.2. Special Handling of Disallowed TLVs in Received Purges 166 When purging LSPs [ISO10589] recommends (but does not require) the 167 body of the LSP (i.e., all TLVs) be removed before generating the 168 purge. LSP purges which have TLVs in the body are accepted though 169 any TLVs which are present "MUST" be ignored. 171 When cryptographic authentication [RFC5304] was introduced, this 172 looseness when processing received purges had to be addressed in 173 order to prevent attackers from being able to initiate a purge 174 without having access to the authentication key. [RFC5304] therefore 175 imposed strict requirements on what TLVs were allowed in a purge 176 (authentication only) and specified that: 178 "ISes MUST NOT accept purges that contain TLVs other than the 179 authentication TLV". 181 This behavior was extended by [RFC6232] which introduced the Purge 182 Originator Identification (POI) TLV and [RFC6233] which added the 183 "Purge" column to the TLV Codepoints registry to identify all the 184 TLVs which are allowed in purges. 186 The behavior specified in [RFC5304] is not backwards compatible with 187 the behavior defined by [ISO10589] and therefore can only be safely 188 enabled when all nodes support cryptographic authentication. 189 Similarly, the extensions defined by [RFC6233] are not compatible 190 with the behavior defined in [RFC5304], therefore can only be safely 191 enabled when all nodes support the extensions. 193 It is recommended that implementations provide controls for the 194 enablement of behaviors that are not backward compatible. 196 3.3. Applicability to sub-TLVs 198 [RFC5305] introduced sub-TLVs, which are TLV tuples advertised within 199 the body of a parent TLV. Registries associated with sub-TLVs are 200 associated with the TLV Codepoints Registry and specify in which TLVs 201 a given sub-TLV is allowed. As with TLVs, it is required that sub- 202 TLVs which are NOT allowed MUST be ignored on receipt. 204 3.4. Correction to POI TLV Registry Entry 206 An error was introduced by [RFC6232] when specifying in which PDUs 207 the POI TLV is allowed. Section 3 of [RFC6232] stated: 209 "The POI TLV SHOULD be found in all purges and MUST NOT be found in 210 LSPs with a non-zero Remaining Lifetime." 212 However, the IANA section of the same document stated: 214 "The additional values for this TLV should be IIH:n, LSP:y, SNP:n, 215 and Purge:y. " 217 The correct setting for "LSP" is "n". This document corrects that 218 error. 220 4. TLV Validation and LSP Acceptance 222 The correct format of a TLV and its associated sub-TLVs if applicable 223 are defined in the document(s) which introduce each codepoint. The 224 definition SHOULD include what action to take when the format/content 225 of the TLV does not conform to the specification (e.g., "MUST be 226 ignored on receipt"). When making use of the information encoded in 227 a given TLV (or sub-TLV) receiving nodes MUST verify that the TLV 228 conforms to the standard definition. This includes cases where the 229 length of a TLV/sub-TLV is incorrect and/or cases where the value 230 field does not conform to the defined restrictions. 232 However, the unit of flooding for the IS-IS Update process is an LSP. 233 The presence of a TLV (or sub-TLV) with content which does not 234 conform to the relevant specification MUST NOT cause the LSP itself 235 to be rejected. Failure to follow this requirement will result in 236 inconsistent LSP Databases on different nodes in the network which 237 will compromise the correct operation of the protocol. 239 LSP Acceptance rules are specified in [ISO10589] . Acceptance rules 240 for LSP purges are extended by [RFC5304] [RFC5310] and further 241 extended by [RFC6233]. 243 [ISO10589] also specifies the behavior when an LSP is not accepted. 244 This behavior is NOT altered by extensions to the LSP Acceptance 245 rules i.e., regardless of the reason for the rejection of an LSP the 246 Update process on the receiving router takes the same action. 248 5. IANA Considerations 250 IANA is requested to update the TLV Codepoints Registry to reference 251 this document. 253 IANA is also requested to modify the entry for the POI TLV in the TLV 254 Codepoints Registry to be: 256 IIH:n, LSP:n, SNP:n, and Purge:y. 258 6. Security Considerations 260 As this document makes no changes to the protocol there are no new 261 security issues introduced. 263 The clarifications discussed in this document are intended to make it 264 less likely that implementations will incorrectly process received 265 LSPs, thereby also making it less likely that a bad actor could 266 exploit a faulty implementaion. 268 Security concerns for IS-IS are discussed in [ISO10589], [RFC5304], 269 and [RFC5310]. 271 7. Acknowledgements 273 The authors would like to thank Alvaro Retana. 275 8. References 277 8.1. Normative References 279 [ISO10589] 280 International Organization for Standardization, 281 "Intermediate system to Intermediate system intra-domain 282 routeing information exchange protocol for use in 283 conjunction with the protocol for providing the 284 connectionless-mode Network Service (ISO 8473)", ISO/ 285 IEC 10589:2002, Second Edition, Nov 2002. 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, 289 DOI 10.17487/RFC2119, March 1997, 290 . 292 [RFC3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF 293 and ISO/IEC Joint Technical Committee 1/Sub Committee 6 294 (JTC1/SC6) on IS-IS Routing Protocol Development", 295 RFC 3563, DOI 10.17487/RFC3563, July 2003, 296 . 298 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 299 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 300 2008, . 302 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 303 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 304 2008, . 306 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 307 and M. Fanto, "IS-IS Generic Cryptographic 308 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 309 2009, . 311 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 312 Originator Identification TLV for IS-IS", RFC 6232, 313 DOI 10.17487/RFC6232, May 2011, 314 . 316 [RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for 317 Purges", RFC 6233, DOI 10.17487/RFC6233, May 2011, 318 . 320 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 321 Scope Link State PDUs (LSPs)", RFC 7356, 322 DOI 10.17487/RFC7356, September 2014, 323 . 325 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 326 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 327 May 2017, . 329 [TLV_CODEPOINTS] 330 IANA, "IS-IS TLV Codepoints web page 331 (https://www.iana.org/assignments/isis-tlv-codepoints/ 332 isis-tlv-codepoints.xhtml)". 334 8.2. Informative References 336 [RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV) 337 Codepoints in Intermediate System to Intermediate System", 338 RFC 3359, DOI 10.17487/RFC3359, August 2002, 339 . 341 Authors' Addresses 343 Les Ginsberg 344 Cisco Systems 346 Email: ginsberg@cisco.com 348 Paul Wells 349 Cisco Systems 351 Email: pauwells@cisco.com 353 Tony Li 354 Arista Networks 355 5453 Great America Parkway 356 Santa Clara, California 95054 357 USA 359 Email: tony.li@tony.li 361 Tony Przygienda 362 Juniper Networks, Inc. 363 1194 N. Matilda Ave 364 Sunnyvale, California 94089 365 USA 367 Email: prz@juniper.net 369 Shraddha Hegde 370 Juniper Networks, Inc. 371 Embassy Business Park 372 Bangalore, KA 560093 373 India 375 Email: shraddha@juniper.net