idnits 2.17.1 draft-ietf-isis-wg-snp-checksum-01.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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 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 (Apr 2000) is 8778 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 99, but no explicit reference was found in the text == Unused Reference: 'Cal90b' is defined on line 103, but no explicit reference was found in the text == Unused Reference: 'ISO90' is defined on line 107, 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: 8 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 Redback 3 Apr 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 RFC-2026. This document is a 12 submission to the IETF IS-IS Working Group. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF) and its working groups. Note that other groups may 16 also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of 6 months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress". 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/ietf/shadow.html 29 Abstract 30 This draft describes an optional extension to IS-IS [ISO90, Cal90a, 31 Cal90b], used today by several ISPs for routing within their clouds. 32 IS-IS is an interior gateway routing protocol developed originally 33 by OSI and used with IP extensions as IGP. IS-IS originally doesn't 34 provide CSNP adn PSNP checksums, relying on the underlying layers 35 to verify the integrity of information provided. Experience with 36 the protocol shows that this precondition does not always hold and 37 scenarios can be imagined that impact protocol functionality. This 38 document introduces a new optional TLV providing checksums. 40 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 44 network technology. As a particularly ugly case, corruption of 45 length and/or TLV length fields may lead to generation of extensive 46 numbers of "empty" LSPs in the receiving node. Since we cannot rely 47 on authentication as checksum mechanism, this document proposes an 48 optional TLV to add checksums to the elements. 50 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 discard PDUs with an optional checksum with the value 0. 64 3. Checksum Computation 65 The checksum is a fletcher checksum computed according to iso 8473 66 Annex C over the complete PDU. 68 4. Interaction with TLVs using PDU Data to Compute Signatures 69 Since other TLVs could be introduced that use PDU data as input 70 to a function that generates output to be included in the PDU, 71 authentication being a straight-forward example thereof, it is 72 important to specify the sequence at which the computation of 73 different signatures takes place. An implementation that implements 74 optional checksums must generate the TLV and fill the TLV Checksum 75 part with 0's. After all other signatures have been computed, the 76 checksum MUST BE filled in after all other signatures have been 77 generated. The implementation MAY choose to omit the optional 78 checksum if it is aware that other signatures are included in the PDU 79 that provide equivalent functionality. 81 5. TLV Format 82 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 83 +-----------------+-----------------+ 84 | TLV Type = 12 | TLV Length = 2 | 85 +-----------------+-----------------+ 86 | TLV Checksum (16 bits) | 87 +-----------------------------------+ 89 6. Acknowledgments 90 Tony Li mentioned the original problem. Mike Shand provided 91 comments. Somehow related problems with purging on LSP checksum 92 errors have been observed by others before. 94 7. Security Consideration 95 ISIS security applies to the work presented. No specific security 96 issues as to the new element are known. 98 References 99 [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. 100 INTERNET-RFC, Internet Engineering Task Force, February 101 1990. 103 [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual 104 Environments. INTERNET-RFC, Internet Engineering Task 105 Force, December 1990. 107 [ISO90] ISO. Information Technology - Telecommunications and 108 Information Exchange between Systems - Intermediate System 109 to Intermediate System Routing Exchange Protocol for 110 Use in Conjunction with the Protocol for Providing the 111 Connectionless-Mode Network Service. ISO, 1990. 113 Authors' Addresses 115 Tony Przygienda 116 Redback 117 1195 Borregas Av 118 Sunnyvale, CA 94089, USA 119 (408) 571 5478 120 prz@redback.com