idnits 2.17.1 draft-ietf-lsr-isis-invalid-tlv-00.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 (July 22, 2019) is 1733 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: January 23, 2020 T. Przygienda 8 S. Hegde 9 Juniper Networks, Inc. 10 July 22, 2019 12 Invalid TLV Handling in IS-IS 13 draft-ietf-lsr-isis-invalid-tlv-00 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 when approved updates RFC3563, RFC5305, RFC6232, and 28 RFC6233. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 34 "OPTIONAL" in this document are to be interpreted as described in BCP 35 14 [RFC2119] [RFC8174] when, and only when, they appear in all 36 capitals, as shown here. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on January 23, 2020. 55 Copyright Notice 57 Copyright (c) 2019 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 2. TLV Codepoints Registry . . . . . . . . . . . . . . . . . . . 3 74 3. TLV Acceptance in PDUs . . . . . . . . . . . . . . . . . . . 4 75 3.1. Handling of Disallowed TLVs in Received PDUs other than 76 LSP Purges . . . . . . . . . . . . . . . . . . . . . . . 4 77 3.2. Special Handling of Disallowed TLVs in Received LSP 78 Purges . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 3.3. Applicability to sub-TLVs . . . . . . . . . . . . . . . . 5 80 3.4. Correction to POI TLV Registry Entry . . . . . . . . . . 5 81 4. TLV Validation and LSP Acceptance . . . . . . . . . . . . . . 5 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 87 8.2. Informative References . . . . . . . . . . . . . . . . . 8 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 90 1. Introduction 92 The Intermediate System to Intermediate System (IS-IS) protocol 93 utilizes Type/Length/Value (TLV) encoding for all content in the body 94 of Protocol Data Units (PDUs). New extensions to the protocol are 95 supported by defining new TLVs. In order to allow protocol 96 extensions to be deployed in a backwards compatible way an 97 implementation is required to ignore TLVs that it does not 98 understand. This behavior is also applied to sub-TLVs, which are 99 contained within TLVs. 101 A corollary to ignoring unknown TLVs is having the validation of PDUs 102 be independent from the validation of the TLVs contained in the PDU. 103 PDUs which are valid MUST be accepted even if an individual TLV 104 contained within that PDU is invalid in some way. 106 These behaviors are specified in existing protocol documents - 107 principally [ISO10589] and [RFC5305]. In addition, the set of TLVs 108 (and sub-TLVs) which are allowed in each PDU type is documented in 109 the TLV Codepoints Registry ( https://www.iana.org/assignments/isis- 110 tlv-codepoints/isis-tlv-codepoints.xhtml ) established by [RFC3563] 111 and updated by [RFC6233] and [RFC7356]. 113 This document is intended to clarify some aspects of existing 114 specifications and thereby reduce the occurrence of non-conformant 115 behavior seen in real world deployments. Although behaviors 116 specified in existing protocol specifications are not changed, the 117 clarifications contained in this document serve as updates to RFC 118 3563 (see Section 2), RFC 5304, and RFC 6233 (see Section 3). 120 2. TLV Codepoints Registry 122 [RFC3563] established the IANA managed IS-IS TLV Codepoints Registry 123 for recording assigned TLV code points [TLV_CODEPOINTS]. The initial 124 contents of this registry were based on [RFC3359]. 126 The registry includes a set of columns indicating in which PDU types 127 a given TLV is allowed: 129 IIH - TLV is allowed in Intermediate System to Intermediate System 130 Hello (IIH) PDUs (Point-to-point and LAN) 132 LSP - TLV is allowed in Link State PDUs (LSP) 134 SNP - TLV is allowed in Sequence Number PDUs (SNP) (Partial Sequence 135 Number PDUs (PSNP) and Complete Sequence Number PDUS (CSNP)) 137 Purge - TLV is allowed in LSP Purges [RFC6233] 139 If "Y" is entered in a column it means the TLV is allowed in the 140 corresponding PDU type. 142 If "N" is entered in a column it means the TLV is NOT allowed in the 143 corresponding PDU type. 145 3. TLV Acceptance in PDUs 147 This section describes the correct behavior when a PDU is received 148 which contains a TLV which is specified as disallowed in the TLV 149 Codepoints Registry. 151 3.1. Handling of Disallowed TLVs in Received PDUs other than LSP Purges 153 [ISO10589] defines the behavior required when a PDU is received 154 containing a TLV which is "not recognised". It states (see Sections 155 9.3 - 9.13): 157 "Any codes in a received PDU that are not recognised shall be 158 ignored." 160 This is the model to be followed when a TLV is received which is 161 disallowed. Therefore TLVs in a PDU (other than LSP purges) which 162 are disallowed MUST be ignored and MUST NOT cause the PDU itself to 163 be rejected by the receiving IS. 165 3.2. Special Handling of Disallowed TLVs in Received LSP Purges 167 When purging LSPs [ISO10589] recommends (but does not require) the 168 body of the LSP (i.e., all TLVs) be removed before generating the 169 purge. LSP purges which have TLVs in the body are accepted though 170 any TLVs which are present "MUST" be ignored. 172 When cryptographic authentication [RFC5304] was introduced, this 173 looseness when processing received purges had to be addressed in 174 order to prevent attackers from being able to initiate a purge 175 without having access to the authentication key. [RFC5304] therefore 176 imposed strict requirements on what TLVs were allowed in a purge 177 (authentication only) and specified that: 179 "ISes MUST NOT accept purges that contain TLVs other than the 180 authentication TLV". 182 This behavior was extended by [RFC6232] which introduced the Purge 183 Originator Identification (POI) TLV and [RFC6233] which added the 184 "Purge" column to the TLV Codepoints registry to identify all the 185 TLVs which are allowed in purges. 187 The behavior specified in [RFC5304] is not backwards compatible with 188 the behavior defined by [ISO10589] and therefore can only be safely 189 enabled when all nodes support cryptographic authentication. 190 Similarly, the extensions defined by [RFC6233] are not compatible 191 with the behavior defined in [RFC5304], therefore can only be safely 192 enabled when all nodes support the extensions. 194 It is recommended that implementations provide controls for the 195 enablement of behaviors that are not backward compatible. 197 3.3. Applicability to sub-TLVs 199 [RFC5305] introduced sub-TLVs, which are TLV tuples advertised within 200 the body of a parent TLV. Registries associated with sub-TLVs are 201 associated with the TLV Codepoints Registry and specify in which TLVs 202 a given sub-TLV is allowed. As with TLVs, it is required that sub- 203 TLVs which are disallowed MUST be ignored on receipt. 205 3.4. Correction to POI TLV Registry Entry 207 An error was introduced by [RFC6232] when specifying in which PDUs 208 the POI TLV is allowed. Section 3 of [RFC6232] stated: 210 "The POI TLV SHOULD be found in all purges and MUST NOT be found in 211 LSPs with a non-zero Remaining Lifetime." 213 However, the IANA section of the same document stated: 215 "The additional values for this TLV should be IIH:n, LSP:y, SNP:n, 216 and Purge:y. " 218 The correct setting for "LSP" is "n". This document corrects that 219 error. 221 4. TLV Validation and LSP Acceptance 223 The correct format of a TLV and its associated sub-TLVs if applicable 224 are defined in the document(s) which introduce each codepoint. The 225 definition SHOULD include what action to take when the format/content 226 of the TLV does not conform to the specification (e.g., "MUST be 227 ignored on receipt"). When making use of the information encoded in 228 a given TLV (or sub-TLV) receiving nodes MUST verify that the TLV 229 conforms to the standard definition. This includes cases where the 230 length of a TLV/sub-TLV is incorrect and/or cases where the value 231 field does not conform to the defined restrictions. 233 However, the unit of flooding for the IS-IS Update process is an LSP. 234 The presence of a TLV (or sub-TLV) with content which does not 235 conform to the relevant specification MUST NOT cause the LSP itself 236 to be rejected. Failure to follow this requirement will result in 237 inconsistent LSP Databases on different nodes in the network which 238 will compromise the correct operation of the protocol. 240 LSP Acceptance rules are specified in [ISO10589] . Acceptance rules 241 for LSP purges are extended by [RFC5304] [RFC5310] and further 242 extended by [RFC6233]. 244 [ISO10589] also specifies the behavior when an LSP is not accepted. 245 This behavior is NOT altered by extensions to the LSP Acceptance 246 rules i.e., regardless of the reason for the rejection of an LSP the 247 Update process on the receiving router takes the same action. 249 5. IANA Considerations 251 IANA is requested to update the TLV Codepoints Registry to reference 252 this document. 254 IANA is also requested to modify the entry for the POI TLV in the TLV 255 Codepoints Registry to be: 257 IIH:n, LSP:n, SNP:n, and Purge:y. 259 6. Security Considerations 261 As this document makes no changes to the protocol there are no new 262 security issues introduced. 264 The clarifications discussed in this document are intended to make it 265 less likely that implementations will incorrectly process received 266 LSPs, thereby also making it less likely that a bad actor could 267 exploit a faulty implementaion. 269 Security concerns for IS-IS are discussed in [ISO10589], [RFC5304], 270 and [RFC5310]. 272 7. Acknowledgements 274 The authors would like to thank Alvaro Retana. 276 8. References 278 8.1. Normative References 280 [ISO10589] 281 International Organization for Standardization, 282 "Intermediate system to Intermediate system intra-domain 283 routeing information exchange protocol for use in 284 conjunction with the protocol for providing the 285 connectionless-mode Network Service (ISO 8473)", ISO/ 286 IEC 10589:2002, Second Edition, Nov 2002. 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, 290 DOI 10.17487/RFC2119, March 1997, 291 . 293 [RFC3563] Zinin, A., "Cooperative Agreement Between the ISOC/IETF 294 and ISO/IEC Joint Technical Committee 1/Sub Committee 6 295 (JTC1/SC6) on IS-IS Routing Protocol Development", 296 RFC 3563, DOI 10.17487/RFC3563, July 2003, 297 . 299 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 300 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 301 2008, . 303 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 304 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 305 2008, . 307 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 308 and M. Fanto, "IS-IS Generic Cryptographic 309 Authentication", RFC 5310, DOI 10.17487/RFC5310, February 310 2009, . 312 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 313 Originator Identification TLV for IS-IS", RFC 6232, 314 DOI 10.17487/RFC6232, May 2011, 315 . 317 [RFC6233] Li, T. and L. Ginsberg, "IS-IS Registry Extension for 318 Purges", RFC 6233, DOI 10.17487/RFC6233, May 2011, 319 . 321 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 322 Scope Link State PDUs (LSPs)", RFC 7356, 323 DOI 10.17487/RFC7356, September 2014, 324 . 326 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 327 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 328 May 2017, . 330 [TLV_CODEPOINTS] 331 IANA, "IS-IS TLV Codepoints web page 332 (https://www.iana.org/assignments/isis-tlv-codepoints/ 333 isis-tlv-codepoints.xhtml)". 335 8.2. Informative References 337 [RFC3359] Przygienda, T., "Reserved Type, Length and Value (TLV) 338 Codepoints in Intermediate System to Intermediate System", 339 RFC 3359, DOI 10.17487/RFC3359, August 2002, 340 . 342 Authors' Addresses 344 Les Ginsberg 345 Cisco Systems 347 Email: ginsberg@cisco.com 349 Paul Wells 350 Cisco Systems 352 Email: pauwells@cisco.com 354 Tony Li 355 Arista Networks 356 5453 Great America Parkway 357 Santa Clara, California 95054 358 USA 360 Email: tony.li@tony.li 362 Tony Przygienda 363 Juniper Networks, Inc. 364 1194 N. Matilda Ave 365 Sunnyvale, California 94089 366 USA 368 Email: prz@juniper.net 370 Shraddha Hegde 371 Juniper Networks, Inc. 372 Embassy Business Park 373 Bangalore, KA 560093 374 India 376 Email: shraddha@juniper.net