idnits 2.17.1 draft-ietf-isis-wg-snp-checksum-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 3 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references (Cal90b], [ISO90,Cal90a,), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 49: '...The optional TLV MAY BE included in al...' RFC 2119 keyword, line 50: '...lements optional checksums MUST accept...' RFC 2119 keyword, line 52: '...um TLV and support it MUST discard the...' RFC 2119 keyword, line 54: '...tional checksums MAY accept a PDU that...' RFC 2119 keyword, line 56: '...DU than CSNP, PSNP or IIH MUST discard...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (1 Nov 1998) is 9308 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) == Unused Reference: 'Cal90a' is defined on line 98, but no explicit reference was found in the text == Unused Reference: 'Cal90b' is defined on line 102, but no explicit reference was found in the text == Unused Reference: 'ISO90' is defined on line 106, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Cal90a' -- Possible downref: Non-RFC (?) normative reference: ref. 'Cal90b' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO90' Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force T. Przygienda 2 INTERNET DRAFT Bell Labs 3 1 Nov 1998 5 Optional Checksums in ISIS 6 8 Status of This Memo 9 This document is an Internet Draft, and can be found as 10 draft-przygienda-snp-checksum-00.txt in any standard internet drafts 11 repository. Internet Drafts are working documents of the Internet 12 Engineering Task Force (IETF), its Areas, and its Working Groups. 13 Note that other groups may also distribute working documents as 14 Internet Drafts. 16 Internet Drafts are draft documents valid for a maximum of six 17 months. Internet Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet 19 Drafts as reference material, or to cite them other than as a 20 ``working draft'' or ``work in progress.'' 21 Please check the I-D abstract listing contained in each Internet 22 Draft directory to learn the current status of this or any other 23 Internet Draft. 25 Abstract 26 This draft describes an optional extension to IS-IS [ISO90, Cal90a, 27 Cal90b], used today by several ISPs for routing within their clouds. 28 IS-IS is an interior gateway routing protocol developed originally 29 by OSI and used with IP extensions as IGP. IS-IS originally doesn't 30 provide CSNP adn PSNP checksums, relying on the underlying layers 31 to verify the integrity of information provided. Experience with 32 the protocol shows that this precondition does not always hold and 33 scenarios can be imagined that impact protocol functionality. This 34 document introduces a new optional TLV providing checksums. 36 1. Introduction 37 IS-IS CSNPs and PSNPs and IIHs can be corrupted in case of faulty 38 implementations of L2 hardware or lack of checksuming on a specific 40 network technology. As a particularly ugly case, corruption of 42 ^L 43 length and/or TLV length fields may lead to generation of extensive 44 numbers of "empty" LSPs in the receiving node. Since we cannot rely 45 on authentication as checksum mechanism, this document proposes an 46 optional TLV to add checksums to the elements. 48 2. TLV Description 49 The optional TLV MAY BE included in all CSNP, PSNP and IIH packets 50 and an implementation that implements optional checksums MUST accept 51 PDUs if they do NOT contain the optional checksum. Implementations 52 that receive optional checksum TLV and support it MUST discard the 53 PDU if the checksum is incorrect. An implementation that does NOT 54 implement optional checksums MAY accept a PDU that contains the 55 checksum TLV. An implementation that supports optional checksums and 56 receives it within any other PDU than CSNP, PSNP or IIH MUST discard 57 the PDU. Such an implementation MAY discard the PDU as well if more 58 than one optional checksum TLVs are included within it. 60 3. Checksum Computation 61 The checksum is a fletcher checksum computed according to iso 8473 62 Annex C over the complete PDU. 64 4. Interaction with TLVs using PDU Data to Compute Signatures 65 Since other TLVs could be introduced that use PDU data as input 66 to a function that generates output to be included in the PDU, 67 authentication being a straight-forward example thereof, it is 68 important to specify the sequence at which the computation of 69 different signatures takes place. An implementation that implements 70 optional checksums must generate the TLV and fill the TLV Checksum 71 part with 0's. After all other signatures have been computed, the 72 checksum MUST BE filled in after all other signatures have been 73 generated. The implementation MAY choose to omit the optional 74 checksum if it is aware that other signatures are included in the PDU 75 that provide equivalent functionality. 77 5. TLV Format 78 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 79 +-----------------+-----------------+ 80 | TLV Type = 12 | TLV Length | 81 +-----------------+-----------------+ 83 ^L 84 | TLV Checksum (32 bits) | 85 | | 86 +-----------------------------------+ 88 6. Acknowledgments 89 Tony Li mentioned the original problem. Somehow related problems 90 with purging on LSP checksum errors have been observed by others 91 before. 93 7. Security Consideration 94 ISIS security applies to the work presented. No specific security 95 issues as to the new element are known. 97 References 98 [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. 99 INTERNET-RFC, Internet Engineering Task Force, February 100 1990. 102 [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual 103 Environments. INTERNET-RFC, Internet Engineering Task 104 Force, December 1990. 106 [ISO90] ISO. Information Technology - Telecommunications and 107 Information Exchange between Systems - Intermediate System 108 to Intermediate System Routing Exchange Protocol for 109 Use in Conjunction with the Protocol for Providing the 110 Connectionless-Mode Network Service. ISO, 1990. 112 Authors' Addresses 114 Tony Przygienda 115 Bell Labs, Lucent Technologies 116 101 Crawfords Corner Road 117 Holmdel, NJ 07733-3030 118 prz@dnrc.bell-labs.com