RFC 3567

Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication

πŸ“… published July 2003, from ietf

Okay bestie, let's get into RFC 3567 πŸ¦‹ It's called Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication, dated July 2003. T. Li (Procket Networks) and R. Atkinson (Extreme Networks) wrote it, and it's marked Category: Informational, so it's giving "here's some info" rather than a binding standard πŸ’… Its header doesn't list anything it obsoletes or updates, so it's a standalone main character ✨

Status of this Memo 🌸

So this memo is here to give the Internet community some information. It does not specify an Internet standard of any kind, and distribution of it is unlimited πŸ’–

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

Abstract ✨

This document is all about authenticating Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm from RFC 2104 πŸ” IS-IS is specified in International Standards Organization (ISO) 10589, with extensions for Internet Protocol version 4 (IPv4) described in RFC 1195. The base spec already has an authentication mechanism that can handle multiple authentication algorithms, but it only actually specifies the algorithm for cleartext passwords πŸ™ˆ

So this doc proposes an extension that lets HMAC-MD5 be used alongside those existing authentication mechanisms. It's the glow-up we needed πŸ’œ

1. Introduction 🧚

The IS-IS protocol, as specified in ISO 10589 [1], authenticates Link State PDUs (LSPs) by including authentication information as part of the LSP. That authentication information is encoded as a Type-Length-Value (TLV) tuple. IS-IS for IPv4 networks is described in [3] πŸ“

The type of the TLV is 10, and its length is variable. The value depends on the authentication algorithm and the related secrets being used. The first octet of the value specifies the authentication type: 0 is reserved, 1 means a cleartext password, and 255 is for routing domain private authentication methods. Whatever's left of the TLV value is called the Authentication Value 🫢

This document extends that setup by allocating a brand new authentication type for HMAC-MD5 and specifying how the Authentication Value gets computed. It also describes changes to the base protocol so the authentication mechanisms in this document actually work πŸ”₯

This document is a publication of the IS-IS Working Group within the IETF, and it's a contribution to ISO IEC JTC1/SC6, for eventual inclusion in ISO 10589 πŸ‘‘

2. Authentication Procedures πŸ’…

The authentication type for HMAC-MD5 is 54 (0x36). The Authentication Value for HMAC-MD5 is 16 octets long, and the length field in the TLV is 17 πŸ“

The HMAC-MD5 algorithm takes a key K and text T as input [2]. The key K is the password for the PDU type, as specified in ISO 10589. The text T is the IS-IS PDU being authenticated, with the Authentication Value field inside the Authentication Information TLV set to zero. Before authentication is computed, the Authentication Type gets set to 54 and the TLV length gets set to 17. When LSPs are authenticated, the Checksum and Remaining Lifetime fields are set to zero (0) first. The result of the algorithm goes into the Authentication Value field πŸ¦‹

When calculating the HMAC-MD5 result for Sequence Number PDUs, Level 1 Sequence Number PDUs SHALL use the Area Authentication string, the same one used in Level 1 Link State PDUs. Level 2 Sequence Number PDUs shall use the domain authentication string, as in Level 2 Link State PDUs. IS-IS HELLO PDUs SHALL use the Link Level Authentication String, which MAY be different from the one used for Link State PDUs. The HMAC-MD5 result for the IS-IS HELLO PDUs SHALL be calculated after the packet is padded to the MTU size, as long as padding isn't disabled. Implementations that support the optional checksum for Sequence Number PDUs and IS-IS HELLO PDUs MUST NOT include the Checksum TLV 🌷

To authenticate an incoming PDU, a system should save the values of the Authentication Value field, the Checksum, and the Remaining Lifetime field, set those fields to zero, compute the authentication, and then restore the values of those fields ✨

An implementation that implements HMAC-MD5 authentication and receives HMAC-MD5 Authentication Information MUST discard the PDU if the Authentication Value is incorrect. Not optional, bestie 🚫

An implementation MAY have a transition mode where it includes HMAC-MD5 Authentication Information in PDUs but does not verify that information. This is a transition aid for networks that are in the process of deploying authentication 🌈

An implementation MAY check a set of passwords when verifying the Authentication Value. This gives you a way to change passwords across a network little by little πŸŽ€

An implementation that does not implement HMAC-MD5 authentication MAY accept a PDU that contains the HMAC-MD5 Authentication Type. ISes (routers) that implement HMAC-MD5 authentication and initiate LSP purges MUST remove the body of the LSP and add the authentication TLV. ISes implementing HMAC-MD5 authentication MUST NOT accept unauthenticated purges. ISes MUST NOT accept purges that contain TLVs other than the authentication TLV. These restrictions are necessary to stop a hostile system from receiving an LSP, setting the Remaining Lifetime field to zero, and flooding it, which would start a purge without knowing the authentication password. Major protection energy πŸ›‘οΈπŸ’€

2.1 Implementation Considerations πŸ“

There's an implementation issue just after password rollover on an IS-IS router that's worth a little extra commentary πŸ™ˆ Right after the rollover, the router or IS-IS process may restart. When that happens, the LSP Sequence Number restarts from 1 using the new password. The neighbors then reject those new LSPs, because the Sequence Number is smaller. The router can't increase its own LSP Sequence Number, since it fails to authenticate its own old LSP that the neighbors keep sending back to it. So the router can't update its LSP Sequence Number to its neighbors until all of them time out the original LSPs 😭

One possible fix is for the IS-IS process to detect whether any inbound LSP with an authentication failure has the local System ID and also has a higher Sequence Number than the IS-IS process currently has. In that case, the IS-IS process SHOULD increase its own LSP Sequence Number accordingly and re-flood the LSPs πŸ” However, this scenario could also be triggered by an active attack from an adversary, so it is recommended that a counter also be kept for this case to mitigate the risk from such an attack πŸ‘€

Copyright (C) The Internet Society (2003). All Rights Reserved. πŸ’œ Okay bestie, the legal bit is short but it matters, so read it with me.

Anyone can copy this document and hand it out, and that includes translations. You can also write derivative works that comment on or explain it, or help people implement it, and publish and distribute those too, in whole or in part, with no restriction at all. πŸ¦‹ The one condition is that the copyright notice and this paragraph stay on every copy and every derivative work.

The document itself is a different story. You can't modify it in any way. No deleting the copyright notice, no scrubbing out the references to the Internet Society or other Internet organizations. πŸ™…β€β™€οΈ There are two exceptions: you can change it when that's needed to develop Internet standards (and then the Internet Standards process copyright procedures apply), or you can change it to translate it into languages other than English. 🌍

These permissions are perpetual. The Internet Society and its successors or assignees will never revoke them. πŸ’–

THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN IS 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 🫢

The RFC Editor function is currently funded by the Internet Society. 🌸 So the people who keep these documents organized and published get their paychecks from them, which is honestly a sweet little detail. ✨

πŸ“¦ where this page comes from