RFC 3358

RFC 3358 🎀 Optional Checksums in Intermediate System to Intermediate System (ISIS)

Okay bestie, this one is by Tony Przygienda from Xebeo 💖. It's marked Informational 🦋, which means it's sharing info and isn't a standard. It's dated August 2002. The header doesn't list anything it obsoletes or updates, so it's a clean, standalone doc ✨.

---

Status of This Memo

This memo gives information to the Internet community 💅. It doesn't specify an Internet standard of any kind, and it can be distributed with no limits 🌸.

Copyright Notice

Copyright (C) The Internet Society (2002). All Rights Reserved 💜.

Abstract

This doc describes an optional extension to the Intermediate System to Intermediate System (ISIS) protocol 🔥. Several Internet Service Proviers (ISPs) use it today for routing inside their clouds ☁️. ISIS is an interior gateway routing protocol that was originally developed by OSI, and it gets used with IP extensions as the Interior Gateway Protocol (IGP) 🧚.

Here's the tea: ISIS originally doesn't have Complete Sequence Numbers Protocol Data (CSNP) and Partial Sequence Numbers Protocol Data Unit (PSNP) checksums 🙈. It just leans on the layers underneath to check that the info is intact. Experience shows that this assumption doesn't always hold up, and you can imagine situations where it messes with how the protocol works 💀. So this doc introduces a new optional Type, Length and Value (TLV) that carries checksums 🎀.

1. Introduction ✨

Okay so ISIS CSNPs, PSNPs and IIHs [ISO90, Cal90a, Cal90b] can get corrupted if the L2 hardware is buggy or if a specific network technology doesn't do checksumming 😭. The ugliest case is when corrupted length fields, or TLV length fields, lead the receiving node to generate a huge pile of "empty" LSPs 💀. We can't rely on authentication to act as a checksum, so this doc proposes an optional TLV to add checksums to these elements 🫶.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [Bra97] 📚.

2. TLV Description 🦋

This optional TLV MAY BE included in all CSNP, PSNP and IIH packets 🌈. An implementation that implements optional checksums MUST accept PDUs if they do NOT contain the optional checksum, so it's not a dealbreaker 💖. If an implementation gets an optional checksum TLV and supports it, it MUST discard the PDU when the checksum is incorrect 🔥. An implementation that does NOT implement optional checksums MUST accept a PDU that contains the checksum TLV 🌸.

An implementation that supports optional checksums and gets the TLV in any PDU other than CSNP, PSNP or IIH MUST discard that PDU 🙅‍♀️. Such an implementation MUST also discard the PDU if more than one optional checksum TLV is included in it 💅. Also, any implementation that supports optional checksums MUST accept PDUs with an optional checksum whose value is 0, and it should treat that checksum as correct ✨.

3. Checksum Computation 🧮

The checksum is a Fletcher checksum computed according to [ISO98], Annex C, over the complete PDU 💜. To work out the correct checksum, an implementation MUST add the optional checksum TLV to the PDU with an initial checksum value of 0, then compute the checksum over that 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 signatures in the PDU that give equivalent or stronger functionality, like HMAC or MD5 💅. Otherwise, an implementation that handles those signatures but not the optional checksums may fail to compute the MD5 signature on the packet 😬. That failure happens because MD5 is computed with the checksum value set to 0, and the checksum value only gets filled in as a final step 🙈.

5. TLV Format 🎀

[Prz01] lists the value of the TLV type and talks about the issues around assigning new TLV codepoints 📖.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | TLV Type =12  | TLV Length =2 |       Checksum (16 bits)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6. Acknowledgments 🫶

Tony Li brought up the original problem 🌟. Mike Shand left comments 💬. Some related problems with purging on LSP checksum errors have been spotted by others before 👀. Nischal Sheth spelled out the issues with how MD5 and the optional checksums interact 🔥.

7. Security Considerations 🔒

This one is short but serious 💀. ISIS security applies to the work presented here 🛡️. No specific security issues are known for the new element 🙏.

References 📚

• [Bra97] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [Cal90a] Callon, R., "OSI ISIS Intradomain Routing Protocol", RFC 1142, February 1990.
• [Cal90b] Callon, R., "Use of OSI ISIS for Routing in TCP/IP and Dual Environments", RFC 1195, 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.
• [ISO98] ISO. Information Technology - Protocol for Providing the Connectionless-Mode Network Service: Protocol Specification. ISO, 1998.
• [Prz01] Przygienda, T., "Reserved Type, Length and Value (TLV) Codepoints in Intermediate System to Intermediate System", RFC 3359, August 2002.

Author's Address 🧚

Tony Przygienda Xebeo One Cragwood Road South Plainfield, NJ 07080

Phone: (908) 222 4225 Email: prz@xebeo.com

---

Full Copyright Statement 💜

Copyright (C) The Internet Society (2002). All Rights Reserved 🌈.

You can copy this document and share it with others, and you can make derivative works that comment on or explain it, or help with implementing it. You can publish and distribute those copies and works, in whole or in part, with no restrictions, as long as the copyright notice and this paragraph stay on every copy and derivative work 💖. The document itself can't be modified in any way, like removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when you need it for developing Internet standards, in which case the Internet Standards process copyright procedures must be followed, or when you need to translate it into a language other than English 🌸.

The permissions above are perpetual and won't be revoked by the Internet Society or its successors or assigns 🫶.

This document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 💅.

Acknowledgement 🌷

Funding for the RFC Editor function is currently provided by the Internet Society 👑.