Internet Engineering Task Force                               T. Przygienda
INTERNET DRAFT                                                         Redback
                                                                     1 Jul 2000
                          Optional Checksums in ISIS
                  <draft-ietf-isis-wg-snp-checksum-02.txt>



Status of This Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.  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
    and may be updated, replaced, or obsoleted by other documents at
    any time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.



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
    length and/or TLV length fields may lead to generation of extensive

Przygienda et al.                Expires 1 Feb 2001                [Page 1]

Internet Draft                    SNP Checksums                     1 Jul 2000

    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 MUST discard the PDU as well
    if more than one optional checksum TLVs are included within it.
    Additionally, any implementation supporting optional checksums MUST
    accept PDUs with an optional checksum with the value 0 and consider
    such a checksum as correct.



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

    The implementation MUST either omit the optional checksum on an
    interface or send a 0 checksum value if it includes in the PDU
    signatures that provide equivalent or stronger functionality, such as
    HMAC or MD5, otherwise an implementation that handles such signatures
    but not the optional checksums, may fail to compute the MD5 signature
    on the packet due to the fact that MD5 is computed with checksum
    value set to 0 and only as final step the checksum value is being
    filled in.



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 = 2 |
                  +-----------------+-----------------+
                  |        TLV Checksum (16 bits)       |

Przygienda et al.                Expires 1 Feb 2001                  [Page 2]

Internet Draft                    SNP Checksums                     1 Jul 2000

                  +-----------------------------------+



6.  Acknowledgments

    Tony Li mentioned the original problem.  Mike Shand provided
    comments.  Somehow related problems with purging on LSP checksum
    errors have been observed by others before.  Nischal Sheth spelled
    out the issues of interaction between MD5 and the optional checksums.



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
Redback
350 Holger Way
San Jose, CA 95134-1362
(408) 548 9416
prz@redback.com


Przygienda et al.                Expires 1 Feb 2001                  [Page 3]