< draft-ietf-isis-wg-snp-checksum-01.txt   draft-ietf-isis-wg-snp-checksum-02.txt >
Internet Engineering Task Force T. Przygienda Internet Engineering Task Force T. Przygienda
INTERNET DRAFT Redback INTERNET DRAFT Redback
Apr 2000 1 Jul 2000
Optional Checksums in ISIS
Optional Checksums in ISIS <draft-ietf-isis-wg-snp-checksum-02.txt>
<draft-ietf-isis-wg-snp-checksum-01.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC-2026. This document is a all provisions of Section 10 of RFC2026. Internet-Drafts are working
submission to the IETF IS-IS Working Group. documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
Internet-Drafts are working documents of the Internet Engineering working documents as Internet-Drafts.
Task Force (IETF) 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 6 months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at
time. It is inappropriate to use Internet-Drafts as reference any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/ietf/shadow.html http://www.ietf.org/shadow.html.
Abstract 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 This draft describes an optional extension to IS-IS [ISO90 , Cal90a ,
IS-IS CSNPs and PSNPs and IIHs can be corrupted in case of faulty Cal90b], used today by several ISPs for routing within their clouds.
implementations of L2 hardware or lack of checksuming on a specific 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.
network technology. As a particularly ugly case, corruption of 1. Introduction
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 IS-IS CSNPs and PSNPs and IIHs can be corrupted in case of faulty
The optional TLV MAY BE included in all CSNP, PSNP and IIH packets implementations of L2 hardware or lack of checksuming on a specific
and an implementation that implements optional checksums MUST accept network technology. As a particularly ugly case, corruption of
PDUs if they do NOT contain the optional checksum. Implementations length and/or TLV length fields may lead to generation of extensive
that receive optional checksum TLV and support it MUST discard the numbers of "empty" LSPs in the receiving node. Since we cannot rely
PDU if the checksum is incorrect. An implementation that does NOT on authentication as checksum mechanism, this document proposes an
implement optional checksums MAY accept a PDU that contains the optional TLV to add checksums to the elements.
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
discard PDUs with an optional checksum with the value 0.
3. Checksum Computation 2. TLV Description
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 optional TLV MAY BE included in all CSNP, PSNP and IIH packets
Since other TLVs could be introduced that use PDU data as input and an implementation that implements optional checksums MUST accept
to a function that generates output to be included in the PDU, PDUs if they do NOT contain the optional checksum. Implementations
authentication being a straight-forward example thereof, it is that receive optional checksum TLV and support it MUST discard the
important to specify the sequence at which the computation of PDU if the checksum is incorrect. An implementation that does NOT
different signatures takes place. An implementation that implements implement optional checksums MAY accept a PDU that contains the
optional checksums must generate the TLV and fill the TLV Checksum checksum TLV. An implementation that supports optional checksums
part with 0's. After all other signatures have been computed, the and receives it within any other PDU than CSNP, PSNP or IIH MUST
checksum MUST BE filled in after all other signatures have been discard the PDU. Such an implementation MUST discard the PDU as well
generated. The implementation MAY choose to omit the optional if more than one optional checksum TLVs are included within it.
checksum if it is aware that other signatures are included in the PDU Additionally, any implementation supporting optional checksums MUST
that provide equivalent functionality. accept PDUs with an optional checksum with the value 0 and consider
such a checksum as correct.
5. TLV Format 3. Checksum Computation
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) |
+-----------------------------------+
6. Acknowledgments The checksum is a fletcher checksum computed according to iso 8473
Tony Li mentioned the original problem. Mike Shand provided Annex C over the complete PDU.
comments. Somehow related problems with purging on LSP checksum
errors have been observed by others before.
7. Security Consideration 4. Interaction with TLVs using PDU Data to Compute Signatures
ISIS security applies to the work presented. No specific security
issues as to the new element are known. 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) |
+-----------------------------------+
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 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 [Cal90a] R. Callon. OSI ISIS Intradomain Routing Protocol.
Environments. INTERNET-RFC, Internet Engineering Task INTERNET-RFC, Internet Engineering Task Force, February
Force, December 1990. 1990.
[ISO90] ISO. Information Technology - Telecommunications and [Cal90b] R. Callon. Use of OSI ISIS for Routing in TCP/IP and Dual
Information Exchange between Systems - Intermediate System Environments. INTERNET-RFC, Internet Engineering Task
to Intermediate System Routing Exchange Protocol for Force, December 1990.
Use in Conjunction with the Protocol for Providing the
Connectionless-Mode Network Service. ISO, 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 Authors' Addresses
Tony Przygienda Tony Przygienda
Redback Redback
1195 Borregas Av 350 Holger Way
Sunnyvale, CA 94089, USA San Jose, CA 95134-1362
(408) 571 5478 (408) 548 9416
prz@redback.com prz@redback.com
 End of changes. 19 change blocks. 
94 lines changed or deleted 97 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/