HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 10:54:00 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 23 Nov 1998 14:49:00 GMT ETag: "361ebc-16d1-365975dc" Accept-Ranges: bytes Content-Length: 5841 Connection: close Content-Type: text/plain Internet Engineering Task Force T. Przygienda INTERNET DRAFT Bell Labs 1 Nov 1998 Optional Checksums in ISIS Status of This Memo This document is an Internet Draft, and can be found as draft-przygienda-snp-checksum-00.txt in any standard internet drafts repository. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract This draft describes an optional extension to IS-IS [ISO90, Cal90a, Cal90b], used today by several ISPs for routing within their clouds. IS-IS is an interior gateway routing protocol developed originally by OSI and used with IP extensions as IGP. IS-IS originally doesn't provide CSNP adn PSNP checksums, relying on the underlying layers to verify the integrity of information provided. Experience with the protocol shows that this precondition does not always hold and scenarios can be imagined that impact protocol functionality. This document introduces a new optional TLV providing checksums. 1. Introduction IS-IS CSNPs and PSNPs and IIHs can be corrupted in case of faulty implementations of L2 hardware or lack of checksuming on a specific network technology. As a particularly ugly case, corruption of Przygienda et al. Expires 1 May 1999 [Page 1] ^L Internet Draft SNP Checksums 1 Nov 1998 length and/or TLV length fields may lead to generation of extensive numbers of "empty" LSPs in the receiving node. Since we cannot rely on authentication as checksum mechanism, this document proposes an optional TLV to add checksums to the elements. 2. TLV Description The optional TLV MAY BE included in all CSNP, PSNP and IIH packets and an implementation that implements optional checksums MUST accept PDUs if they do NOT contain the optional checksum. Implementations that receive optional checksum TLV and support it MUST discard the PDU if the checksum is incorrect. An implementation that does NOT implement optional checksums MAY accept a PDU that contains the checksum TLV. An implementation that supports optional checksums and receives it within any other PDU than CSNP, PSNP or IIH MUST discard the PDU. Such an implementation MAY discard the PDU as well if more than one optional checksum TLVs are included within it. 3. Checksum Computation The checksum is a fletcher checksum computed according to iso 8473 Annex C over the complete PDU. 4. Interaction with TLVs using PDU Data to Compute Signatures Since other TLVs could be introduced that use PDU data as input to a function that generates output to be included in the PDU, authentication being a straight-forward example thereof, it is important to specify the sequence at which the computation of different signatures takes place. An implementation that implements optional checksums must generate the TLV and fill the TLV Checksum part with 0's. After all other signatures have been computed, the checksum MUST BE filled in after all other signatures have been generated. The implementation MAY choose to omit the optional checksum if it is aware that other signatures are included in the PDU that provide equivalent functionality. 5. TLV Format 0 1 2 3 4 5 6 7 8 0 1 2 3 4 5 6 7 8 +-----------------+-----------------+ | TLV Type = 12 | TLV Length | +-----------------+-----------------+ Przygienda et al. Expires 1 May 1999 [Page 2] ^L Internet Draft SNP Checksums 1 Nov 1998 | TLV Checksum (32 bits) | | | +-----------------------------------+ 6. Acknowledgments Tony Li mentioned the original problem. Somehow related problems with purging on LSP checksum errors have been observed by others before. 7. Security Consideration ISIS security applies to the work presented. No specific security issues as to the new element are known. References [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol. INTERNET-RFC, Internet Engineering Task Force, February 1990. [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual Environments. INTERNET-RFC, Internet Engineering Task Force, December 1990. [ISO90] ISO. Information Technology - Telecommunications and Information Exchange between Systems - Intermediate System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for Providing the Connectionless-Mode Network Service. ISO, 1990. Authors' Addresses Tony Przygienda Bell Labs, Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733-3030 prz@dnrc.bell-labs.com Przygienda et al. Expires 1 May 1999 [Page 3]