RFC 7645

The Keying and Authentication for Routing Protocol (KARP) IS-IS Security Analysis

📅 published September 2015, from ietf

RFC 7645 🎀 is The Keying and Authentication for Routing Protocol (KARP) IS-IS Security Analysis 💅

It was written by U. Chunduri, A. Tian, and W. Lu from Ericsson Inc. 💜 It's dated September 2015 and marked as Informational, so it's a published analysis, not a Standards Track spec 🌸 Its ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates ✨

Abstract

okay so this doc checks where IS-IS stands against the requirements in RFC 6518 🔐 It covers both manual and automated key management protocols, and it's giving thorough 🫶

Status of This Memo

This document is not an Internet Standards Track specification 🌸 It's published for informational purposes only.

This is an IETF product 💅 It reflects the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard. See Section 2 of RFC 5741 for that.

For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc7645 🦋

Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the publication date. Please read these carefully, because they spell out your rights and restrictions for this document 📜 Any Code Components pulled from this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License.

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
  1.2.  Acronyms  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Current State . . . . . . . . . . . . . . . . . . . . . . . .   3
  2.1.  Key Usage . . . . . . . . . . . . . . . . . . . . . . . .   4
    2.1.1.  Subnetwork Independent  . . . . . . . . . . . . . . .   4
    2.1.2.  Subnetwork dependent  . . . . . . . . . . . . . . . .   4
  2.2.  Key Agility . . . . . . . . . . . . . . . . . . . . . . .   5
  2.3.  Security Issues . . . . . . . . . . . . . . . . . . . . .   5
    2.3.1.  Replay Attacks  . . . . . . . . . . . . . . . . . . .   5
      2.3.1.1.  Current Recovery Mechanism for LSPs . . . . . . .   6
    2.3.2.  Spoofing Attacks  . . . . . . . . . . . . . . . . . .   7
    2.3.3.  DoS Attacks . . . . . . . . . . . . . . . . . . . . .   8
3.  Gap Analysis and Security Requirements  . . . . . . . . . . .   8
  3.1.  Manual Key Management . . . . . . . . . . . . . . . . . .   8
  3.2.  Key Management Protocols  . . . . . . . . . . . . . . . .   9
4.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
  5.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
  5.2.  Informative References  . . . . . . . . . . . . . . . . .  11
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1. Introduction ✨

This doc checks IS-IS against the requirements from RFC 6518 [RFC6518], for both manual and automated key management protocols 🫶

IS-IS already hits some of the requirements you'd expect from a manually keyed routing protocol 💖 Integrity protection got an upgrade by allowing more cryptographic algorithms [RFC5310]. Even so, algorithm agility is still limited to the HMAC-SHA family 🥺 [RFC5310] does make a basic form of intra-connection rekeying possible, but there are gaps, and Section 3 of this document digs into them 🔍

This doc also sums up where cryptographic key usage in IS-IS stands, plus earlier efforts that analyzed IS-IS security. That includes the base IS-IS specs: [RFC1195], [RFC5304], [RFC5310], and [RFC6039] 📚

It further looks at the threats to IS-IS described in [RFC6862], lists the security gaps, and gives specific recommendations to stop those threats, for both manual keying and automated key management 🛡️

1.1. Requirements Language

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 RFC 2119 [RFC2119] 📏

1.2. Acronyms

Here's the acronym list, so no one gets lost 🗂️

DoS     -  Denial of Service

GDOI    -  Group Domain of Interpretation

IGP     -  Interior Gateway Protocol

IIH     -  IS-IS HELLO

IPv4    -  Internet Protocol version 4

KMP     -  Key Management Protocol (automated key management)

LSP     -  Link State PDU

MKM     -  Manual Key Management

NONCE   -  Number Once

PDU     -  Protocol Data Unit

SA      -  Security Association

SNP     -  Sequence Number PDU

2. Current State 💅

IS-IS is specified in International Standards Organization (ISO) 10589 [ISO10589]. Its IPv4 extensions are in [RFC1195]. The base spec has an authentication mechanism that allows any authentication algorithm, and it also defines the algorithm for clear text passwords 🔓 Then [RFC5304] extends that mechanism to work with HMAC-MD5 and tweaks the base protocol to be more effective 🔧 [RFC5310] brings algorithm agility with a new generic cryptographic authentication mechanism, CRYPTO_AUTH, for IS-IS 🦋

CRYPTO_AUTH also adds a Key ID mechanism that maps to unique IS-IS SAs 🗝️

The next sections cover the current authentication key usage for the various IS-IS messages, how keys get changed today, and the potential security threats 👀

2.1. Key Usage

IS-IS can be set up with a per-interface, peer-to-peer key for IIH PDUs, plus a group key for LSPs and SNPs 🎀 If that's provisioned, IIH packets can potentially use the same group key as LSPs and SNPs.

2.1.1. Subnetwork Independent

LSPs, and complete and partial Sequence Number PDUs, all fall under Subnetwork Independent messages 🌈 To protect Level-1 SNPs and Level-1 LSPs, the provisioned Area Authentication key is used. Level-2 SNPs and Level-2 LSPs use the provisioned domain authentication key.

Authentication happens on the LSPs an IS transmits, not on the LSPs sent to one specific neighbor. So it's implied that every IS in a single flooding domain must be configured with the same key for authentication to work correctly 🤝 This goes for SNPs too, though in broadcast networks they're limited to link-local scope 🌸

If multiple instances share circuits as specified in [RFC6822], instance-specific authentication credentials can be used to protect the LSPs and SNPs within an area or domain 💖 It's also worth noting that [RFC6822] lets you use topology-specific authentication credentials within an instance for LSPs and SNPs 🧚

2.1.2. Subnetwork dependent

IIH PDUs use the Link Level Authentication key, which may be different from the one for LSPs and SNPs 🦋 That's especially likely on point-to-point links. In broadcast networks, you can provision the same common key used for LSPs and SNPs to protect IIH messages too. That makes neighbor discovery and adjacency formation with more than one neighbor on the same physical interface possible 🫶 If multiple instances share circuits as specified in [RFC6822], instance-specific authentication credentials can be used to protect Hello messages 💜

2.2. Key Agility

Rolling keys over without affecting routing protocol operation, IS-IS included, is necessary for good key management protocol integration 🔄

The current HMAC-MD5 cryptographic authentication from [RFC5304] suggests a transition mode, so ISes can use a set of keys when verifying the authentication value and change keys smoothly 🌊 That lets you change the authentication key manually without taking the adjacency down or dropping any control packet. BUT (and this is a big but 😭), it piles extra load on the control plane during the transition, since each control packet might have to be verified by more than one key. It also opens a potential DoS attack during that window 💀

The Key ID mechanism from [RFC5310] makes this better 🎉 The receiver figures out the active SA by looking at the Key ID field in the incoming PDU, so it doesn't need to try other keys when the integrity check or digest verification fails. Still, [RFC5310] doesn't clearly define key coordination across the group or an exact key change mechanism 🙈 It says:

Normally, an implementation would allow the network operator to configure a set of keys in a key chain, with each key in the chain having a fixed lifetime. The actual operation of these mechanisms is outside the scope of this document.

2.3. Security Issues

This section looks at the possible security threats in the current state of the IS-IS protocol 🚨 Part 2 gets into the details, so stay tuned, bestie 🫶

2.3.1. Replay Attacks ✨

okay bestie, replaying a captured protocol packet to cause damage is a classic threat for literally any protocol 💀. Signing a packet with cryptographic authentication info alone can't stop it completely 🙈. This is even more of a problem on broadcast networks, but ngl most IGP deployments use P2P-over-lan circuits [RFC5309], which makes it way easier for an adversary to replay an IS-IS PDU than on traditional P2P networks 😭.

Intra-session replay is when a secured packet from the current session gets replayed and causes damage, if there's no other mechanism to confirm it's a replay. Inter-session replay is when a captured packet from a previous session gets replayed to cause damage. IS-IS packets are vulnerable to both of these, because there's no sequence number verification for IIH and SNP packets 💅. Also, with current manual key management, periodic key changes across the group are rarely done 🥀. So the intra-connection and inter-connection replay requirements are not met. Not it 💔.

IS-IS specifies the use of the HMAC-MD5 [RFC5304] and HMAC-SHA-1 family in [RFC5310] to protect IS-IS packets. An adversary could replay old IIHs or replay old SNPs, which would cause churn in the network or bring down the adjacencies 🌪️.

  1. At the time of adjacency bring up, an IS sends an IIH packet with an empty neighbor list (TLV 6) and with the authentication information as per the provisioned authentication mechanism. If this packet is replayed later on the broadcast network, all ISes in the broadcast network can bounce the adjacency, creating a huge churn in the network 😵‍💫.
  2. Today, LSPs have intra-session replay protection, because the LSP header contains a 32-bit sequence number, which is verified for every received packet against the local LSP database 🧠. But, if a node in the network is out of service (is undergoing some sort of high availability condition or an upgrade) for more than LSP refresh time, and the rest of the network ages out the LSPs of that node, an adversary can potentially plunge in inter-session replay attacks in the network 🕵️‍♀️. If the key is not changed in the above circumstances, the attack can be launched by replaying an old LSP with a higher sequence number and fewer prefixes or fewer adjacencies. This may force the receiver to accept and remove the routes from the routing table, which eventually causes traffic disruption to those prefixes 📉. However, as per the IS-IS specification, there is a built-in recovery mechanism for LSPs from inter-session replay attacks, and it is further discussed in Section 2.3.1.1 🦋.
  3. In any IS-IS network (broadcast or otherwise), if an old and empty Complete Sequence Number Packet (CSNP) is replayed, this can cause an LSP flood in the network 🌊. Similarly, a replayed Partial Sequence Number Packet (PSNP) can cause an LSP flood in the broadcast network 🌊.

2.3.1.1. Current Recovery Mechanism for LSPs 🔁

okay so in the event of an inter-session replay attack, an LSP with a higher sequence number gets accepted, and it also gets propagated until it reaches the originating node of the LSP 🚀. The originator recognizes the LSP is "newer" than what's in its local database, which prompts the originator to flood a newer version of the LSP with a higher sequence number than the one received. This newer version can potentially replace any versions of the replayed LSP that may exist in the network 💖.

However, in the above process, the damage caused by the replayed LSP depends on three things: where in the network the replay is initiated, how quickly the nodes in the network react to the replayed LSP, and how different the content in the accepted LSP is 🤔.

2.3.2. Spoofing Attacks 🎭

IS-IS shares the same key between all neighbors in an area or in a domain to protect the LSP and SNP packets, and in broadcast networks even IIH packets 🔑. False advertisement by a router is not within the scope of the KARP work. However, given the wide sharing of keys as described above, there is a significant risk that an attacker can compromise a key from one device and use it to falsely participate in the routing, possibly even in a very separate part of the network 😱.

If the same underlying topology is shared across multiple instances to transport routing/application information as defined in [RFC6822], it is necessary to use different authentication credentials for different instances 🧩. In this connection, based on the deployment considerations, if certain topologies in a particular IS-IS instance require more protection from spoofing attacks and less exposure, topology-specific authentication credentials can be used for LSPs and SNPs, as facilitated in [RFC6822] ✨.

Currently, possession of the key itself is used as an authentication check, and there is no identity check done separately. Spoofing occurs when an illegitimate device assumes the identity of a legitimate one 👀. An attacker can use spoofing to launch various types of attacks, for example:

  1. The attacker can send out unrealistic routing information that might cause the disruption of network services, such as block holes 🕳️.
  2. A rogue system that has access to the common key used to protect the LSP can flood an LSP by setting the Remaining Lifetime field to zero, thereby initiating a purge. Subsequently, this can cause the sequence number of all the LSPs to increase quickly, to max out the sequence number space, which can cause an IS to shut down for MaxAge + ZeroAgeLifetime period to allow the old LSPs to age out in other ISes of the same flooding domain 😭.

2.3.3. DoS Attacks 🌊

DoS attacks using the authentication mechanism are possible, and an attacker can send packets that overwhelm the security mechanism itself 🥵. An example is initiating an overwhelming load of spoofed but integrity-protected protocol packets, so that the receiver needs to process the integrity check, only to discard the packet. This can cause significant CPU usage 🔥. DoS attacks are not generally preventable within the routing protocol. As the attackers are often remote, DoS attacks are more damaging to area-scoped or domain-scoped packet receivers than link-local-scoped packet receivers 🌍.

3. Gap Analysis and Security Requirements 🔍

This section lays out the differences between the current state of the IS-IS routing protocol and the desired state, as specified in the KARP Design Guidelines [RFC6518] 🗺️. It focuses on where the IS-IS protocol fails to meet the general requirements specified in the threats and requirements document [RFC6862] 🧐.

This section also describes security requirements that should be met by IS-IS implementations that are secured by manual as well as automated key management protocols 💜.

3.1. Manual Key Management 🔑

  1. With the CRYPTO_AUTH specification [RFC5310], IS-IS packets can be protected with the HMAC-SHA family of cryptographic algorithms. The specification provides limited algorithm agility (SHA family). By using Key IDs, it also conceals the algorithm information from the protected control messages 🫣.
  2. Even though both intra- and inter-session replay attacks are best prevented by deploying key management protocols with frequent key change capability, basic constructs for the sequence number should be in the protocol messages. So, some basic or extended sequence number mechanism should be in place to protect IIH packets and SNP packets. The sequence number should be increased for each protocol packet. This allows mitigation of some of the replay threats as mentioned in Section 2.3.1 🔢.
  3. Any common key mechanism with keys shared across a group of routers is susceptible to spoofing attacks caused by a malicious router 😈. A separate authentication check (apart from the integrity check to verify the digest), with digital signatures as described in [RFC2154], can effectively nullify this attack. But this approach was never deployed, which we assume is due to operational considerations at that time 🤷‍♀️. The alternative approach to thwart this threat would be to use the keys from the group key management protocol. As the group key(s) are generated by authenticating the member ISes in the group first, and are then periodically rekeyed, per-packet identity or authentication checks may not be needed 🎀.
  4. In general, DoS attacks may not be preventable with the mechanism from the routing protocol itself. But some form of admin-controlled lists at the forwarding plane can reduce the damage 🛡️. There are some other forms of DoS attacks common to any protocol that are not in scope per Section 3.3 of [RFC6862] 🙅‍♀️.

As discussed in Section 2.2, though the Key ID mechanism described in [RFC5310] helps, a better key coordination mechanism for key roll over is desirable even with manual key management 🔄. But [RFC5310] does not specify the exact mechanism, other than requiring use of key chains. The specific requirements are as follows:

a. Keys SHOULD be able to change without effecting the established adjacency, ideally without any control packet loss 🫶.

b. Keys SHOULD be able to change without effecting the protocol operations; for example, LSP flooding should not be held for a specific Key ID availability 🌸.

c. Any proposed mechanism SHOULD also be incrementally deployable with key management protocols 🌱.

3.2. Key Management Protocols 🗝️

In broadcast deployments, the keys used for protecting IS-IS protocol messages can, in particular, be group keys 👯‍♀️. A mechanism is needed to distribute group keys to a group of ISes in a Level-1 area or Level-2 domain, using the Group Domain of Interpretation (GDOI) protocol as specified in [RFC6407]. An example policy and payload format is described in [GDOI] 📜.

If a group key is used, the authentication granularity becomes group membership of devices, not peer authentication between devices 🤝. The deployed group key management protocol SHOULD support rekeying 🔁.

In some deployments, where IS-IS point-to-point (P2P) mode is used for adjacency bring-up, subnetwork-dependent messages (e.g., IIHs) can use a different key shared between the two P2P peers, while all other messages use a group key. When a group keying mechanism is deployed, even the P2P IIHs can be protected with the common group keys. This approach facilitates one key management mechanism, instead of both pair-wise keying and group keying protocols being deployed together 💅. If the same circuits are shared across multiple instances, the granularity of the group can become per instance for IIHs and per instance/topology for LSPs and SNPs, as specified in [RFC6822] 🧩.

Effective key change capability within the routing protocol, one that allows key roll over without impacting the routing protocol operation, is one of the requirements for deploying any group key mechanism 🔐. Once such a mechanism is in place with the deployment of a group key management protocol, IS-IS can be protected from various threats, and is not limited to intra- and inter-session replay attacks and spoofing attacks 👑.

Specific use of cryptographic tables [RFC7210] should be defined for the IS-IS protocol 📋.

4. Security Considerations ✨

okay bestie, this part is all about security, and it's giving serious responsibility 🔒💖 This doc is mostly about the security considerations of the IS-IS protocol. It lists the potential threats and the security requirements for mitigating them 🛡️ It does not introduce any new security threats for IS-IS, which is a big relief ✨

Now, attack methods are openly published, and Section 1 of [RFC5310] talks about the HMAC-MD5 cryptographic authentication mechanism. So IS-IS deployments SHOULD use the HMAC-SHA family [RFC5310] instead of HMAC-MD5 [RFC5304] to protect IS-IS PDUs 🔐 MD5 is giving "old and vulnerable" energy, so upgrade, periodt 💅

If you want the full security tea, check out the Security Considerations section of the IS-IS Generic Cryptographic Authentication [RFC5310], the KARP Design Guide [RFC6518], and the KARP threat document [RFC6862] 📚🦋

5. References

5.1. Normative References

[RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
           dual environments", RFC 1195, DOI 10.17487/RFC1195,
           December 1990, <http://www.rfc-editor.org/info/rfc1195>.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
           Authentication", RFC 5304, DOI 10.17487/RFC5304, October
           2008, <http://www.rfc-editor.org/info/rfc5304>.

[RFC5310]  Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
           and M. Fanto, "IS-IS Generic Cryptographic
           Authentication", RFC 5310, DOI 10.17487/RFC5310, February
           2009, <http://www.rfc-editor.org/info/rfc5310>.

5.2. Informative References

[GDOI]     Weis, B. and S. Rowles, "GDOI Generic Message
           Authentication Code Policy", Work in Progress,
           draft-weis-gdoi-mac-tek-03, September 2011.

[ISO10589] International Organization for Standardization,
           "Intermediate System to Intermediate System intra-domain
           routeing information exchange protocol for use in
           conjunction with the protocol for providing the
           connectionless-mode network service (ISO 8473)", ISO/IEC
           10589:2002, Second Edition, November 2002.

[RFC2154]  Murphy, S., Badger, M., and B. Wellington, "OSPF with
           Digital Signatures", RFC 2154, DOI 10.17487/RFC2154, June
           1997, <http://www.rfc-editor.org/info/rfc2154>.

[RFC5309]  Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point
           Operation over LAN in Link State Routing Protocols",
           RFC 5309, DOI 10.17487/RFC5309, October 2008,
           <http://www.rfc-editor.org/info/rfc5309>.

[RFC6039]  Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
           with Existing Cryptographic Protection Methods for Routing
           Protocols", RFC 6039, DOI 10.17487/RFC6039, October 2010,
           <http://www.rfc-editor.org/info/rfc6039>.

[RFC6407]  Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
           of Interpretation", RFC 6407, DOI 10.17487/RFC6407,
           October 2011, <http://www.rfc-editor.org/info/rfc6407>.

[RFC6518]  Lebovitz, G. and M. Bhatia, "Keying and Authentication for
           Routing Protocols (KARP) Design Guidelines", RFC 6518,
           DOI 10.17487/RFC6518, February 2012,
           <http://www.rfc-editor.org/info/rfc6518>.

[RFC6822]  Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and
           D. Ward, "IS-IS Multi-Instance", RFC 6822,
           DOI 10.17487/RFC6822, December 2012,
           <http://www.rfc-editor.org/info/rfc6822>.

[RFC6862]  Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
           Authentication for Routing Protocols (KARP) Overview,
           Threats, and Requirements", RFC 6862,
           DOI 10.17487/RFC6862, March 2013,
           <http://www.rfc-editor.org/info/rfc6862>.

[RFC7210]  Housley, R., Polk, T., Hartman, S., and D. Zhang,
           "Database of Long-Lived Symmetric Cryptographic Keys",
           RFC 7210, DOI 10.17487/RFC7210, April 2014,
           <http://www.rfc-editor.org/info/rfc7210>.

Acknowledgements 🫶

The authors want to give a huge shoutout to Joel Halpern for the early chats about this document and for his super valuable review comments 💜 Naiming Shen also gets a big thank-you for reviewing and giving feedback 🌸 And thanks to Russ White, Brian Carpenter, and Amanda Barber for reviewing the document during the IESG review process 🎀✨

Authors' Addresses 🧚

Uma Chunduri
Ericsson Inc.
300 Holger Way,
San Jose, California  95134
United States
Phone: 408 750-5678
Email: uma.chunduri@ericsson.com


Albert Tian
Ericsson Inc.
300 Holger Way,
San Jose, California  95134
United States
Phone: 408 750-5210
Email: albert.tian@ericsson.com


Wenhu Lu
Ericsson Inc.
300 Holger Way,
San Jose, California  95134
United States
Email: wenhu.lu@ericsson.com
📦 where this page comes from