idnits 2.17.1 draft-ietf-isis-wg-snp-checksum-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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. ** There are 10 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** 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 51: '...The optional TLV MAY BE included in al...' RFC 2119 keyword, line 52: '...lements optional checksums MUST accept...' RFC 2119 keyword, line 54: '...um TLV and support it MUST discard the...' RFC 2119 keyword, line 56: '...tional checksums MAY accept a PDU that...' RFC 2119 keyword, line 58: '... other PDU than CSNP, PSNP or IIH MUST...' (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 Jul 2000) is 8692 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 103, but no explicit reference was found in the text == Unused Reference: 'Cal90b' is defined on line 107, but no explicit reference was found in the text == Unused Reference: 'ISO90' is defined on line 111, 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: 6 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Przygienda 3 INTERNET DRAFT Redback 4 1 Jul 2000 5 Optional Checksums in ISIS 6 8 Status of This Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at 18 any time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Abstract 29 This draft describes an optional extension to IS-IS [ISO90 , Cal90a , 30 Cal90b], used today by several ISPs for routing within their clouds. 31 IS-IS is an interior gateway routing protocol developed originally 32 by OSI and used with IP extensions as IGP. IS-IS originally doesn't 33 provide CSNP adn PSNP checksums, relying on the underlying layers 34 to verify the integrity of information provided. Experience with 35 the protocol shows that this precondition does not always hold and 36 scenarios can be imagined that impact protocol functionality. This 37 document introduces a new optional TLV providing checksums. 39 1. Introduction 41 IS-IS CSNPs and PSNPs and IIHs can be corrupted in case of faulty 42 implementations of L2 hardware or lack of checksuming on a specific 43 network technology. As a particularly ugly case, corruption of 44 length and/or TLV length fields may lead to generation of extensive 45 numbers of "empty" LSPs in the receiving node. Since we cannot rely 46 on authentication as checksum mechanism, this document proposes an 47 optional TLV to add checksums to the elements. 49 2. TLV Description 51 The optional TLV MAY BE included in all CSNP, PSNP and IIH packets 52 and an implementation that implements optional checksums MUST accept 53 PDUs if they do NOT contain the optional checksum. Implementations 54 that receive optional checksum TLV and support it MUST discard the 55 PDU if the checksum is incorrect. An implementation that does NOT 56 implement optional checksums MAY accept a PDU that contains the 57 checksum TLV. An implementation that supports optional checksums 58 and receives it within any other PDU than CSNP, PSNP or IIH MUST 59 discard the PDU. Such an implementation MUST discard the PDU as well 60 if more than one optional checksum TLVs are included within it. 61 Additionally, any implementation supporting optional checksums MUST 62 accept PDUs with an optional checksum with the value 0 and consider 63 such a checksum as correct. 65 3. Checksum Computation 67 The checksum is a fletcher checksum computed according to iso 8473 68 Annex C over the complete PDU. 70 4. Interaction with TLVs using PDU Data to Compute Signatures 72 The implementation MUST either omit the optional checksum on an 73 interface or send a 0 checksum value if it includes in the PDU 74 signatures that provide equivalent or stronger functionality, such as 75 HMAC or MD5, otherwise an implementation that handles such signatures 76 but not the optional checksums, may fail to compute the MD5 signature 77 on the packet due to the fact that MD5 is computed with checksum 78 value set to 0 and only as final step the checksum value is being 79 filled in. 81 5. TLV Format 83 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 84 +-----------------+-----------------+ 85 | TLV Type = 12 | TLV Length = 2 | 86 +-----------------+-----------------+ 87 | TLV Checksum (16 bits) | 88 +-----------------------------------+ 90 6. Acknowledgments 92 Tony Li mentioned the original problem. Mike Shand provided 93 comments. Somehow related problems with purging on LSP checksum 94 errors have been observed by others before. Nischal Sheth spelled 95 out the issues of interaction between MD5 and the optional checksums. 97 7. Security Consideration 99 ISIS security applies to the work presented. No specific security 100 issues as to the new element are known. 101 References 103 [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. 104 INTERNET-RFC, Internet Engineering Task Force, February 105 1990. 107 [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual 108 Environments. INTERNET-RFC, Internet Engineering Task 109 Force, December 1990. 111 [ISO90] ISO. Information Technology - Telecommunications and 112 Information Exchange between Systems - Intermediate System 113 to Intermediate System Routing Exchange Protocol for 114 Use in Conjunction with the Protocol for Providing the 115 Connectionless-Mode Network Service. ISO, 1990. 117 Authors' Addresses 119 Tony Przygienda 120 Redback 121 350 Holger Way 122 San Jose, CA 95134-1362 123 (408) 548 9416 124 prz@redback.com