draft-ietf-karp-isis-analysis-03.txt   rfc7645.txt 
Routing Working Group U. Chunduri
Internet-Draft A. Tian
Intended status: Informational W. Lu
Expires: March 12, 2015 Ericsson Inc.,
September 8, 2014
KARP IS-IS security analysis Internet Engineering Task Force (IETF) U. Chunduri
draft-ietf-karp-isis-analysis-03 Request for Comments: 7645 A. Tian
Category: Informational W. Lu
ISSN: 2070-1721 Ericsson Inc.
September 2015
The Keying and Authentication for Routing Protocol (KARP)
IS-IS Security Analysis
Abstract Abstract
This document analyzes the threats applicable for Intermediate system This document analyzes the current state of the Intermediate System
to Intermediate system (IS-IS) routing protocol and security gaps to Intermediate System (IS-IS) protocol according to the requirements
according to the KARP Design Guide. This document also provides set forth in "Keying and Authentication for Routing Protocols (KARP)
specific requirements to address the gaps with both manual and auto Design Guidelines" (RFC 6518) for both manual and automated key
key management protocols. management protocols.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on March 12, 2015. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7645.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Current State . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Current State . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Key Usage . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Key Usage . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Sub network Independent . . . . . . . . . . . . . . . 4 2.1.1. Subnetwork Independent . . . . . . . . . . . . . . . 4
2.1.2. Sub network dependent . . . . . . . . . . . . . . . . 4 2.1.2. Subnetwork dependent . . . . . . . . . . . . . . . . 4
2.2. Key Agility . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Key Agility . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Security Issues . . . . . . . . . . . . . . . . . . . . . 5 2.3. Security Issues . . . . . . . . . . . . . . . . . . . . . 5
2.3.1. Replay Attacks . . . . . . . . . . . . . . . . . . . 5 2.3.1. Replay Attacks . . . . . . . . . . . . . . . . . . . 5
2.3.1.1. Current Recovery mechanism for LSPs . . . . . . . 6 2.3.1.1. Current Recovery Mechanism for LSPs . . . . . . . 6
2.3.2. Spoofing Attacks . . . . . . . . . . . . . . . . . . 7 2.3.2. Spoofing Attacks . . . . . . . . . . . . . . . . . . 7
2.3.3. DoS Attacks . . . . . . . . . . . . . . . . . . . . . 8 2.3.3. DoS Attacks . . . . . . . . . . . . . . . . . . . . . 8
3. Gap Analysis and Security Requirements . . . . . . . . . . . 8 3. Gap Analysis and Security Requirements . . . . . . . . . . . 8
3.1. Manual Key Management . . . . . . . . . . . . . . . . . . 8 3.1. Manual Key Management . . . . . . . . . . . . . . . . . . 8
3.2. Key Management Protocols . . . . . . . . . . . . . . . . 9 3.2. Key Management Protocols . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Normative References . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Informative References . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This document analyzes the current state of Intermediate system to This document analyzes the current state of the Intermediate System
Intermediate system (IS-IS) protocol according to the requirements to Intermediate System (IS-IS) protocol according to the requirements
set forth in [RFC6518] for both manual and auto key management set forth in "Keying and Authentication for Routing Protocols (KARP)
protocols. Design Guidelines" [RFC6518] for both manual and automated key
management protocols.
With currently published work, IS-IS meets some of the requirements With currently published work, IS-IS meets some of the requirements
expected from a manually keyed routing protocol. Integrity expected from a manually keyed routing protocol. Integrity
protection is expanded with more cryptographic algorithms and also protection is expanded by allowing more cryptographic algorithms to
limited algorithm agility (HMAC-SHA family) is provided with be used [RFC5310]. However, even with this expanded protection, only
[RFC5310]. Basic form of Intra-connection re-keying capability is limited algorithm agility (HMAC-SHA family) is possible. [RFC5310]
provided by the specification [RFC5310] with some gaps as explained makes possible a basic form of intra-connection rekeying, but with
in Section 3. some gaps as analyzed in Section 3 of this document.
This draft summarizes the current state of cryptographic key usage in
IS-IS protocol and several previous efforts to analyze IS-IS
security. This includes base IS-IS specification [RFC1195],
[RFC5304], [RFC5310] and the OPSEC working group document [RFC6039].
Authors would like to acknowledge all the previous work done in the This document summarizes the current state of cryptographic key usage
above documents. in the IS-IS protocol and several previous efforts that analyze IS-IS
security. This includes the base IS-IS specifications: [RFC1195],
[RFC5304], [RFC5310], and [RFC6039].
This document also analyzes applicability of various threats as This document also analyzes various threats to IS-IS (as described in
described in [RFC6862] to IS-IS, lists gaps and provide specific [RFC6862]), lists security gaps, and provides specific
recommendations to thwart the applicable threats for both manual recommendations to thwart the threats for both manual keying and
keying and for auto key management mechanisms. automated key management mechanisms.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Acronyms 1.2. Acronyms
DoS - Denial of Service. DoS - Denial of Service
IGP - Interior Gateway Protocol. GDOI - Group Domain of Interpretation
IIH - IS-IS HELLO PDU. IGP - Interior Gateway Protocol
IPv4 - Internet Protocol version 4. IIH - IS-IS HELLO
KMP - Key Management Protocol (auto key management). IPv4 - Internet Protocol version 4
LSP - IS-IS Link State PDU. KMP - Key Management Protocol (automated key management)
MKM - Manual Key management Protocols. LSP - Link State PDU
NONCE - Number Once. MKM - Manual Key Management
SA - Security Association. NONCE - Number Once
SNP - Sequence number PDU. PDU - Protocol Data Unit
SA - Security Association
SNP - Sequence Number PDU
2. Current State 2. Current State
IS-IS is specified in International Standards Organization (ISO) IS-IS is specified in International Standards Organization (ISO)
10589, with extensions to support Internet Protocol version 4 (IPv4) 10589 [ISO10589], with extensions to support Internet Protocol
described in [RFC1195]. The specification includes an authentication version 4 (IPv4) described in [RFC1195]. The specification includes
mechanism that allows for any authentication algorithm and also an authentication mechanism that allows for any authentication
specifies the algorithm for clear text passwords. Further [RFC5304] algorithm and also specifies the algorithm for clear text passwords.
extends the authentication mechanism to work with HMAC-MD5 and also Further, [RFC5304] extends the authentication mechanism to work with
modifies the base protocol for more effectiveness. [RFC5310] HMAC-MD5 and also modifies the base protocol for more effectiveness.
provides algorithm agility, with new generic crypto authentication [RFC5310] provides algorithm agility, with a new generic
mechanism (CRYPTO_AUTH) for IS-IS. The CRYPTO_AUTH also introduces cryptographic authentication mechanism (CRYPTO_AUTH) for IS-IS.
Key ID mechanism that map to unique IS-IS Security Associations
(SAs). CRYPTO_AUTH also introduces a Key ID mechanism that maps to unique
IS-IS SAs.
The following sections describe the current authentication key usage The following sections describe the current authentication key usage
for various IS-IS messages, current key change methodologies and the for various IS-IS messages, current key change methodologies, and the
various potential security threats. various potential security threats.
2.1. Key Usage 2.1. Key Usage
IS-IS can be provisioned with a per interface, peer-to-peer key for IS-IS can be provisioned with a per-interface, peer-to-peer key for
IS-IS HELLO PDUs (IIH) and a group key for Link State PDUs (LSPs) and IIH PDUs and a group key for LSPs and SNPs. If provisioned, IIH
Sequence number PDUs (SNPs). If provisioned, IIH packets potentially packets can potentially use the same group key used for LSPs and
can use the same group key used for LSPs and SNPs. SNPs.
2.1.1. Sub network Independent 2.1.1. Subnetwork Independent
Link State PDUs, Complete and partial Sequence Number PDUs come under Link State PDUs, Complete and partial Sequence Number PDUs come under
Sub network Independent messages. For protecting Level-1 SNPs and Sub network Independent messages. For protecting Level-1 SNPs and
Level-1 LSPs, provisioned Area Authentication key is used. Level-2 Level-1 LSPs, provisioned Area Authentication key is used. Level-2
SNPs as well as Level-2 LSPs use the provisioned domain SNPs as well as Level-2 LSPs use the provisioned domain
authentication key. authentication key.
Since authentication is performed on the LSPs transmitted by an IS, Because authentication is performed on the LSPs transmitted by an IS,
rather than on the LSP packets transmitted to a specific neighbor, it rather than on the LSP packets transmitted to a specific neighbor, it
is implied that all the ISes within a single flooding domain must be is implied that all the ISes within a single flooding domain must be
configured with the same key in order for authentication to work configured with the same key in order for authentication to work
correctly. This is also true for SNP packets, though they are correctly. This is also true for SNP packets, though they are
limited to link local scope in broadcast networks. limited to link-local scope in broadcast networks.
If multiple instances share the circuits as specified in [RFC6822], If multiple instances share the circuits as specified in [RFC6822],
instance specific authentication credentials can be used to protect instance-specific authentication credentials can be used to protect
the LSPs and SNPs with in an area or domain. It is important to the LSPs and SNPs within an area or domain. It is important to note
note, [RFC6822] also allows usage of topology specific authentication that [RFC6822] also allows usage of topology-specific authentication
credentials with in an instance for the LSPs and SNPs. credentials within an instance for the LSPs and SNPs.
2.1.2. Sub network dependent 2.1.2. Subnetwork Dependent
IS-IS HELLO PDUs use the Link Level Authentication key, which may be IIH PDUs use the Link Level Authentication key, which may be
different from that of LSPs and SNPs. This could be particularly different from that of LSPs and SNPs. This could be particularly
true for point-to-point links. In broadcast networks it is possible true for point-to-point links. In broadcast networks, it is possible
to provision the same common key used for LSPs and SNPs, to protect to provision the same common key used for LSPs and SNPs to protect
IIH messages. This allows neighbor discovery and adjacency formation IIH messages. This allows neighbor discovery and adjacency formation
with more than one neighbor on the same physical interface. If with more than one neighbor on the same physical interface. If
multiple instances share the circuits as specified in [RFC6822], multiple instances share the circuits as specified in [RFC6822],
instance specific authentication credentials can be used to protect instance-specific authentication credentials can be used to protect
Hello messages. Hello messages.
2.2. Key Agility 2.2. Key Agility
Key roll over without effecting the routing protocols operation in Key roll over without effecting the routing protocols operation in
general and IS-IS in particular, is necessary for effective key general and IS-IS in particular is necessary for effective key
management protocol integration. management protocol integration.
Current HMAC-MD5 crypto authentication as defined in [RFC5304], Current HMAC-MD5 cryptographic authentication as defined in
suggests a transition mode, so that ISes use a set of keys when [RFC5304], suggests a transition mode so that ISes use a set of keys
verifying the authentication value, to allow key changes. This when verifying the authentication value to allow key changes. This
approach will allow changing the authentication key manually without approach will allow changing the authentication key manually without
bringing down the adjacency and without dropping any control packet. bringing down the adjacency and without dropping any control packet.
But, this can increase the load on control plane for the key But, this can increase the load on the control plane for the key
transition duration as each control packet may have to be verified by transition duration, as each control packet may have to be verified
more than one key and also allows to mount a potential Denial of by more than one key, and it also allows a potential DoS attack in
Service (DoS) attack in the transition duration. the transition duration.
The above situation is improved with the introduction of Key ID The above situation is improved with the introduction of the Key ID
mechanism as defined in [RFC5310]. With this, the receiver mechanism as defined in [RFC5310]. With this, the receiver
determines the active security association (SA) by looking at the Key determines the active SA by looking at the Key ID field in the
ID field in the incoming PDU and need not try with other keys, when incoming PDU and need not try with other keys when the integrity
the integrity check or digest verification fails. But, neither Key check or digest verification fails. But, neither key coordination
co-ordination across the group nor exact key change mechanism is across the group nor an exact key change mechanism is clearly
clearly defined. [RFC5310] says: " Normally, an implementation would defined. [RFC5310] says:
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 Normally, an implementation would allow the network operator to
operation of these mechanisms is outside the scope of this document." 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 2.3. Security Issues
The following section analyzes various security threats possible, in The following section analyzes various possible security threats in
the current state for IS-IS protocol. the current state of the IS-IS protocol.
2.3.1. Replay Attacks 2.3.1. Replay Attacks
Replaying a captured protocol packet to cause damage is a common Replaying a captured protocol packet to cause damage is a common
threat for any protocol. Securing the packet with cryptographic threat for any protocol. Securing the packet with cryptographic
authentication information alone cannot mitigate this threat authentication information alone cannot mitigate this threat
completely. Though this problem is more prevalent in broadcast completely. Though this problem is more prevalent in broadcast
networks it is important to note, most of the IGP deployments use networks, it is important to note that most of the IGP deployments
P2P-over-lan [RFC5309], which makes an adversary replay 'easier' than use P2P-over-lan circuits [RFC5309], which makes it possible for an
the traditional P2P networks adversary to replay an IS-IS PDU more easily than the traditional P2P
networks.
In intra-session replay attacks a secured protocol packet of the In intra-session replay attacks, a secured protocol packet of the
current session is replayed, can cause damage, if there is no other current session that is replayed can cause damage, if there is no
mechanism to confirm this is a replay packet. In inter-session other mechanism to confirm this is a replay packet. In inter-session
replay attacks, captured packet from one of the previous session can replay attacks, a captured packet from one of the previous sessions
be replayed to cause the damage. IS-IS packets are vulnerable to can be replayed to cause damage. IS-IS packets are vulnerable to
both these attacks, as there is no sequence number verification for both of these attacks, as there is no sequence number verification
IIH packets and SNP packets. Also with current manual key management for IIH and SNP packets. Also with current manual key management,
periodic key changes across the group are done rarely. Thus the periodic key changes across the group are rarely done. Thus, the
intra-connection and inter-connection replay requirements are not intra-connection and inter-connection replay requirements are not
met. met.
IS-IS specifies the use of the HMAC-MD5 [RFC5304] and HMAC-SHA-1 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 family in [RFC5310] to protect IS-IS packets. An adversary could
replay old IIHs or replay old SNPs that would cause churn in the replay old IIHs or replay old SNPs that would cause churn in the
network or bring down the adjacencies. network or bring down the adjacencies.
1. At the time of adjacency bring up an IS sends IIH packet with 1. At the time of adjacency bring up an IS sends IIH packet with
empty neighbor list (TLV 6) and with the authentication empty neighbor list (TLV 6) and with the authentication
information as per provisioned authentication mechanism. If this information as per the provisioned authentication mechanism. If
packet is replayed later on the broadcast network, all ISes in this packet is replayed later on the broadcast network, all ISes
the broadcast network can bounce the adjacency to create a huge in the broadcast network can bounce the adjacency to create a huge
churn in the network. churn in the network.
2. Today LSPs have intra-session replay protection as LSP header 2. Today, LSPs have intra-session replay protection as the LSP header
contains 32-bit sequence number which is verified for every contains a 32-bit sequence number, which is verified for every
received packet against the local LSP database. But, if a node received packet against the local LSP database. But, if a node in
in the network is out of service (is undergoing some sort of high the network is out of service (is undergoing some sort of high
availability condition, or an upgrade) for more than LSP refresh availability condition or an upgrade) for more than LSP refresh
time and the rest of the network ages out the LSPs of the node time and the rest of the network ages out the LSPs of the node
under consideration, an adversary can potentially plunge in under consideration, an adversary can potentially plunge in inter-
inter-session replay attacks in the network. If the key is not session replay attacks in the network. If the key is not changed
changed in the above circumstances, attack can be launched by in the above circumstances, attack can be launched by replaying an
replaying an old LSP with higher sequence number and fewer old LSP with a higher sequence number and fewer prefixes or fewer
prefixes or fewer adjacencies. This may force the receiver to adjacencies. This may force the receiver to accept and remove the
accept and remove the routes from the routing table, which routes from the routing table, which eventually causes traffic
eventually causes traffic disruption to those prefixes. However, disruption to those prefixes. However, as per the IS-IS
as per the IS-IS specification there is a built-in recovery specification, there is a built-in recovery mechanism for LSPs
mechanism for LSPs from inter-session replay attacks and it is from inter-session replay attacks and it is further discussed in
further discussed in Section 2.3.1.1. Section 2.3.1.1.
3. In any IS-IS network (broadcast or otherwise), if an old and an 3. In any IS-IS network (broadcast or otherwise), if an old and an
empty Complete Sequence Number packet (CSNP) is replayed this can empty Complete Sequence Number Packet (CSNP) is replayed, this can
cause LSP flood in the network. Similarly a replayed Partial cause LSP flood in the network. Similarly, a replayed Partial
Sequence Number packet (PSNP) can cause LSP flood in the Sequence Number Packet (PSNP) can cause LSP flood in the broadcast
broadcast network. network.
2.3.1.1. Current Recovery mechanism for LSPs 2.3.1.1. Current Recovery Mechanism for LSPs
In the event of inter-session replay attack by an adversary, as LSP In the event of inter-session replay attack by an adversary, as an
with higher sequence number gets accepted, it also gets propagated LSP with a higher sequence number gets accepted, it also gets
until it reaches the originating node of the LSP. The originator propagated until it reaches the originating node of the LSP. The
recognizes the LSP is "newer" than in the local database and this originator recognizes the LSP is "newer" than in the local database,
prompts the originator to flood a newer version of the LSP with which prompts the originator to flood a newer version of the LSP with
higher sequence number than the received. This newer version can a higher sequence number than that received. This newer version can
potentially replace any versions of the replayed LSP which may exist potentially replace any versions of the replayed LSP that may exist
in the network. in the network.
But in the above process, depending on where in the network the However, in the above process, depending on where in the network the
replay is initiated, how quick the nodes in the network react to the replay is initiated, how quickly the nodes in the network react to
replayed LSP and also how different the content in the accepted LSP the replayed LSP, and how different the content in the accepted LSP
determines the damage caused by the replayed LSP. is determines the damage caused by the replayed LSP.
2.3.2. Spoofing Attacks 2.3.2. Spoofing Attacks
IS-IS shares the same key between all neighbors in an area or in a IS-IS shares the same key between all neighbors in an area or in a
domain to protect the LSP, SNP packets and in broadcast networks even domain to protect the LSP, SNP packets, and in broadcast networks
IIH packets. False advertisement by a router is not within scope of even IIH packets. False advertisement by a router is not within the
the KARP work. However, given the wide sharing of keys as described scope of the KARP work. However, given the wide sharing of keys as
above, there is a significant risk that an attacker can compromise a described above, there is a significant risk that an attacker can
key from one device, and use it to falsely participate in the compromise a key from one device and use it to falsely participate in
routing, possibly even in a very separate part of the network. the routing, possibly even in a very separate part of the network.
If the same underlying topology is shared across multiple instances If the same underlying topology is shared across multiple instances
to transport routing/application information as defined in [RFC6822], to transport routing/application information as defined in [RFC6822],
it is necessary to use different authentication credentials for it is necessary to use different authentication credentials for
different instances. In this connection, based on the deployment different instances. In this connection, based on the deployment
considerations, if certain topologies in a particular IS-IS instance considerations, if certain topologies in a particular IS-IS instance
require more protection from spoofing attacks and less exposure, require more protection from spoofing attacks and less exposure,
topology specific authentication credentials can be used for LSPs and topology-specific authentication credentials can be used for LSPs and
SNPs as facilitated in [RFC6822]. SNPs as facilitated in [RFC6822].
Currently possession of the key itself is used as authentication Currently, possession of the key itself is used as an authentication
check and there is no identity check done separately. Spoofing check and there is no identity check done separately. Spoofing
occurs when an illegitimate device assumes the identity of a occurs when an illegitimate device assumes the identity of a
legitimate one. An attacker can use spoofing as a means for legitimate one. An attacker can use spoofing to launch various types
launching various types of attacks. For example: of attacks, for example:
1. The attacker can send out unrealistic routing information that 1. The attacker can send out unrealistic routing information that
might cause the disruption of network services such as block might cause the disruption of network services, such as block
holes. holes.
2. A rogue system having access to the common key used to protect 2. A rogue system that has access to the common key used to protect
the LSP, can send an LSP, setting the Remaining Lifetime field to the LSP can flood an LSP by setting the Remaining Lifetime field
zero, and flooding it thereby initiating a purge. Subsequently, to zero, thereby initiating a purge. Subsequently, this can cause
this also can cause the sequence number of all the LSPs to the sequence number of all the LSPs to increase quickly to max out
increase quickly to max out the sequence number space, which can the sequence number space, which can cause an IS to shut down for
cause an IS to shut down for MaxAge + ZeroAgeLifetime period to MaxAge + ZeroAgeLifetime period to allow the old LSPs to age out
allow the old LSPs to age out in other ISes of the same flooding in other ISes of the same flooding domain.
domain.
2.3.3. DoS Attacks 2.3.3. DoS Attacks
Denial-of-service (DoS) attacks using the authentication mechanism is DoS attacks using the authentication mechanism is possible and an
possible and an attacker can send packets which can overwhelm the attacker can send packets that can overwhelm the security mechanism
security mechanism itself. An example is initiating an overwhelming itself. An example is initiating an overwhelming load of spoofed but
load of spoofed but integrity protected protocol packets, so that the integrity-protected protocol packets, so that the receiver needs to
receiver needs to process the integrity check, only to discard the process the integrity check, only to discard the packet. This can
packet. This can cause significant CPU usage. DoS attacks are not cause significant CPU usage. DoS attacks are not generally
generally preventable with in the routing protocol. As the attackers preventable within the routing protocol. As the attackers are often
are often remote, the DoS attacks are more damaging to area-scoped or remote, the DoS attacks are more damaging to area-scoped or domain-
domain-scoped packet receivers than link-local scoped packet scoped packet receivers than link-local-scoped packet receivers.
receivers.
3. Gap Analysis and Security Requirements 3. Gap Analysis and Security Requirements
This section outlines the differences between the current state of This section outlines the differences between the current state of
the IS-IS routing protocol and the desired state as specified in KARP the IS-IS routing protocol and the desired state as specified in the
Design Guidelines [RFC6518]. The section focuses on where IS-IS KARP Design Guidelines [RFC6518]. This section focuses on where the
protocol fails to meet general requirements as specified in the IS-IS protocol fails to meet general requirements as specified in the
threats and requirements document. threats and requirements document [RFC6862].
This section also describes security requirements that should be met This section also describes security requirements that should be met
by IS-IS implementations that are secured by manual as well as auto by IS-IS implementations that are secured by manual as well as
key management protocols. automated key management protocols.
3.1. Manual Key Management 3.1. Manual Key Management
1. With CRYPTO_AUTH specification [RFC5310], IS-IS packets can be 1. With CRYPTO_AUTH specification [RFC5310], IS-IS packets can be
protected with HMAC-SHA family of cryptographic algorithms. The protected with the HMAC-SHA family of cryptographic algorithms.
specification provides the limited algorithm agility (SHA The specification provides limited algorithm agility (SHA family).
family). By using Key IDs, it also conceals the algorithm By using Key IDs, it also conceals the algorithm information from
information from the protected control messages. the protected control messages.
2. Even though both intra and inter session replay attacks are best 2. Even though both intra- and inter-session replay attacks are best
prevented by deploying key management protocols with frequent key prevented by deploying key management protocols with frequent key
change capability, basic constructs for sequence number should be change capability, basic constructs for the sequence number should
there in the protocol messages. So, some basic or extended be in the protocol messages. So, some basic or extended sequence
sequence number mechanism should be in place to protect IIH number mechanism should be in place to protect IIH packets and SNP
packets and SNP packets. The sequence number should be increased packets. The sequence number should be increased for each
for each protocol packet. This allows mitigation of some of the protocol packet. This allows mitigation of some of the replay
replay threats as mentioned in Section 2.3.1. threats as mentioned in Section 2.3.1.
3. Any common key mechanism with keys shared across a group of 3. Any common key mechanism with keys shared across a group of
routers is susceptible to spoofing attacks caused by a malicious routers is susceptible to spoofing attacks caused by a malicious
router. Separate authentication check (apart from the integrity router. A separate authentication check (apart from the integrity
check to verify the digest) with digital signatures as described check to verify the digest) with digital signatures as described
in [RFC2154], can effectively nullify this attack. But this in [RFC2154] can effectively nullify this attack. But this
approach was never deployed and one can only assume due to approach was never deployed, which we assume is due to operational
operational considerations at that time. The alternative considerations at that time. The alternative approach to thwart
approach to thwart this threat would be by using the keys from this threat would be to use the keys from the group key management
the group key management protocol. As the group key(s) are protocol. As the group key(s) are generated by authenticating the
generated by authenticating the member ISes in the group first, member ISes in the group first and are then periodically rekeyed,
and then periodically rekeyed, per packet identity or per-packet identity or authentication checks may not be needed.
authentication check may not be needed.
4. In general DoS attacks may not be preventable with mechanism from 4. In general, DoS attacks may not be preventable with the mechanism
routing protocols itself. But some form of Admin controlled from the routing protocol itself. But some form of admin-
lists (ACLs) at the forwarding plane can reduce the damage. controlled lists at the forwarding plane can reduce the damage.
There are some other forms the DoS attacks common to any protocol There are some other forms of DoS attacks common to any protocol
are not in scope as per the section 3.3 in [RFC6862]. that are not in scope per Section 3.3 of [RFC6862].
As discussed in Section 2.2, though Key ID mechanism in [RFC5310] As discussed in Section 2.2, though the Key ID mechanism described in
helps, better key co-ordination mechanism for key roll over is [RFC5310] helps, a better key coordination mechanism for key roll
desirable even with manual key management. But, it fell short of over is desirable even with manual key management. But, [RFC5310]
specifying exact mechanism other than using key chains. The specific does not specify the exact mechanism other than requiring use of key
requirements: chains. The specific requirements are as follows:
a. Keys SHOULD be able to change without affecting the established a. Keys SHOULD be able to change without effecting the established
adjacency and even better without any control packet loss. adjacency, ideally without any control packet loss.
b. Keys SHOULD be able to change without effecting the protocol b. Keys SHOULD be able to change without effecting the protocol
operations, for example, LSP flooding should not be held for a operations; for example, LSP flooding should not be held for a
specific Key ID availability. specific Key ID availability.
c. Any proposed mechanism SHOULD also be further incrementally c. Any proposed mechanism SHOULD also be incrementally deployable
deployable with key management protocols. with key management protocols.
3.2. Key Management Protocols 3.2. Key Management Protocols
In broadcast deployments, the keys used for protecting IS-IS In broadcast deployments, the keys used for protecting IS-IS
protocols messages can, in particular, be group keys. A mechanism, protocols messages can, in particular, be group keys. A mechanism is
similar to as described in [I-D.weis-gdoi-mac-tek] can be used to needed to distribute group keys to a group of ISes in a Level-1 area
distribute group keys to a group of ISes in Level-1 area or Level-2 or Level-2 domain, using the Group Domain of Interpretation (GDOI)
domain, using GDOI as specified in [RFC6407]. There are also similar protocol as specified in [RFC6407]. An example policy and payload
approaches with IKEv2 based group key management solutions, to format is described in [GDOI].
routing protocols as described in [I-D.yeung-g-ikev2] and [I-
D.hartman-karp-mrkmp].
If a group key is used, the authentication granularity becomes group If a group key is used, the authentication granularity becomes group
membership of devices, not peer authentication between devices. membership of devices, not peer authentication between devices. The
Group key management protocol deployed SHOULD be capable of deployed group key management protocol SHOULD support rekeying.
supporting rekeying support.
In some deployments, where IS-IS point-to-point (P2P) mode is used In some deployments, where IS-IS point-to-point (P2P) mode is used
for adjacency bring-up, sub network dependent messages (IIHs) can use for adjacency bring-up, subnetwork-dependent messages (e.g., IIHs)
a different key shared between the two point-to-point peers, while can use a different key shared between the two P2P peers, while all
all other messages use a group key. When group keying mechanism is other messages use a group key. When a group keying mechanism is
deployed, even the P2P IIHs can be protected with the common group deployed, even the P2P IIHs can be protected with the common group
keys. This approach facilitates one key management mechanism instead keys. This approach facilitates one key management mechanism instead
of both pair-wise keying and group keying protocols to be deployed of both pair-wise keying and group keying protocols being deployed
together. If same circuits are shared across multiple instances, the together. If the same circuits are shared across multiple instances,
granularity of the group can become per instance for IIHs and per the granularity of the group can become per instance for IIHs and per
instance/topology for LSPs and SNPs as specified in the [RFC6822]. instance/topology for LSPs and SNPs as specified in [RFC6822].
Effective key change capability with in the routing protocol which
allows key roll over without impacting the routing protocol
operation, is one of the requirements for deploying any group key
mechanism. Once such mechanism is in place with deployment of group
key management protocol, IS-IS can be protected from various threats
not limited to intra and inter session replay attacks and spoofing
attacks.
Specific use of crypto tables [RFC7210] should be defined for IS-IS
protocol.
4. IANA Considerations
This document defines no new namespaces.
5. Security Considerations Effective key change capability within the routing protocol that
allows key roll over without impacting the routing protocol operation
is one of the requirements for deploying any group key mechanism.
Once such mechanism is in place with the deployment of 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.
This document is mostly about security considerations of IS-IS Specific use of cryptographic tables [RFC7210] should be defined for
protocol, lists potential threats and security requirements for the IS-IS protocol.
solving those threats. This document does not introduce any new
security threats for IS-IS protocol. For more detailed security
considerations please refer the Security Considerations section of
the KARP Design Guide [RFC6518] document as well as KARP threat
document [RFC6862].
6. Acknowledgements 4. Security Considerations
Authors would like to thank Joel Halpern for initial discussions on This document is mostly about security considerations of the IS-IS
this document and giving valuable review comments. Authors would protocol, and it lists potential threats and security requirements
like to acknowledge Naiming Shen for reviewing and providing feedback for mitigating these threats. This document does not introduce any
on this document. new security threats for the IS-IS protocol. In view of openly
published attack vectors, as noted in Section 1 of [RFC5310] on HMAC-
MD5 cryptographic authentication mechanism, IS-IS deployments SHOULD
use the HMAC-SHA family [RFC5310] instead of HMAC-MD5 [RFC5304] to
protect IS-IS PDUs. For more detailed security considerations,
please refer the Security Considerations section of the IS-IS Generic
Cryptographic Authentication [RFC5310], the KARP Design Guide
[RFC6518] document, as well as the KARP threat document [RFC6862].
7. References 5. References
7.1. Normative References 5.1. Normative References
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. 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 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, October 2008. 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., [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, February 2009. Authentication", RFC 5310, DOI 10.17487/RFC5310, February
2009, <http://www.rfc-editor.org/info/rfc5310>.
7.2. Informative References
[I-D.hartman-karp-mrkmp] 5.2. Informative References
Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router
Key Management Protocol (MaRK)", draft-hartman-karp-
mrkmp-05 (work in progress), September 2012.
[I-D.weis-gdoi-mac-tek] [GDOI] Weis, B. and S. Rowles, "GDOI Generic Message
Weis, B. and S. Rowles, "GDOI Generic Message Authentication Code Policy", Work in Progress,
Authentication Code Policy", draft-weis-gdoi-mac-tek-03 draft-weis-gdoi-mac-tek-03, September 2011.
(work in progress), September 2011.
[I-D.yeung-g-ikev2] [ISO10589] International Organization for Standardization,
Rowles, S., Yeung, A., Tran, P., and Y. Nir, "Group Key "Intermediate System to Intermediate System intra-domain
Management using IKEv2", draft-yeung-g-ikev2-07 (work in routeing information exchange protocol for use in
progress), November 2013. 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 [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997. Digital Signatures", RFC 2154, DOI 10.17487/RFC2154, June
1997, <http://www.rfc-editor.org/info/rfc2154>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005.
[RFC5309] Shen, N. and A. Zinin, "Point-to-Point Operation over LAN [RFC5309] Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point
in Link State Routing Protocols", RFC 5309, October 2008. 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 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
with Existing Cryptographic Protection Methods for Routing with Existing Cryptographic Protection Methods for Routing
Protocols", RFC 6039, October 2010. 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 [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, October 2011. 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 [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", RFC 6518, Routing Protocols (KARP) Design Guidelines", RFC 6518,
February 2012. DOI 10.17487/RFC6518, February 2012,
<http://www.rfc-editor.org/info/rfc6518>.
[RFC6822] Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D. [RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and
Ward, "IS-IS Multi-Instance", RFC 6822, December 2012. 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 [RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and
Authentication for Routing Protocols (KARP) Overview, Authentication for Routing Protocols (KARP) Overview,
Threats, and Requirements", RFC 6862, March 2013. 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, [RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys", RFC "Database of Long-Lived Symmetric Cryptographic Keys",
7210, April 2014. RFC 7210, DOI 10.17487/RFC7210, April 2014,
<http://www.rfc-editor.org/info/rfc7210>.
Acknowledgements
Authors would like to thank Joel Halpern for initial discussions on
this document and for giving valuable review comments. The authors
would like to acknowledge Naiming Shen for reviewing and providing
feedback on this document. Thanks to Russ White, Brian Carpenter,
and Amanda Barber for reviewing the document during the IESG review
process.
Authors' Addresses Authors' Addresses
Uma Chunduri Uma Chunduri
Ericsson Inc., Ericsson Inc.
300 Holger Way, 300 Holger Way,
San Jose, California 95134 San Jose, California 95134
USA United States
Phone: 408 750-5678 Phone: 408 750-5678
Email: uma.chunduri@ericsson.com Email: uma.chunduri@ericsson.com
Albert Tian Albert Tian
Ericsson Inc., Ericsson Inc.
300 Holger Way, 300 Holger Way,
San Jose, California 95134 San Jose, California 95134
USA United States
Phone: 408 750-5210 Phone: 408 750-5210
Email: albert.tian@ericsson.com Email: albert.tian@ericsson.com
Wenhu Lu Wenhu Lu
Ericsson Inc., Ericsson Inc.
300 Holger Way, 300 Holger Way,
San Jose, California 95134 San Jose, California 95134
USA United States
Email: wenhu.lu@ericsson.com Email: wenhu.lu@ericsson.com
 End of changes. 98 change blocks. 
328 lines changed or deleted 335 lines changed or added

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