draft-ietf-karp-isis-analysis-02.txt   draft-ietf-karp-isis-analysis-03.txt 
Routing Working Group U. Chunduri
KARP Working Group U. Chunduri
Internet-Draft A. Tian Internet-Draft A. Tian
Intended status: Informational W. Lu Intended status: Informational W. Lu
Expires: August 9, 2014 Ericsson Inc., Expires: March 12, 2015 Ericsson Inc.,
February 5, 2014 September 8, 2014
KARP IS-IS security analysis KARP IS-IS security analysis
draft-ietf-karp-isis-analysis-02 draft-ietf-karp-isis-analysis-03
Abstract Abstract
This document analyzes the threats applicable for Intermediate system This document analyzes the threats applicable for Intermediate system
to Intermediate system (IS-IS) routing protocol and security gaps to Intermediate system (IS-IS) routing protocol and security gaps
according to the KARP Design Guide. This document also provides according to the KARP Design Guide. This document also provides
specific requirements to address the gaps with both manual and auto specific requirements to address the gaps with both manual and auto
key management protocols. key management protocols.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six 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 any
time. It is inappropriate to use Internet-Drafts as reference 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."
This Internet-Draft will expire on August 9, 2014. This Internet-Draft will expire on March 12, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 3, line 21 skipping to change at page 3, line 21
keying and for auto key management mechanisms. keying and for auto 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.
IGP - Interior Gateway Protocol. IGP - Interior Gateway Protocol.
IIH - IS-IS HELLO PDU. IIH - IS-IS HELLO PDU.
IPv4 - Internet Protocol version 4. IPv4 - Internet Protocol version 4.
KMP - Key Management Protocol (auto key management). KMP - Key Management Protocol (auto key management).
LSP - IS-IS Link State PDU. LSP - IS-IS Link State PDU.
skipping to change at page 5, line 41 skipping to change at page 5, line 41
2.3. Security Issues 2.3. Security Issues
The following section analyzes various security threats possible, in The following section analyzes various security threats possible, in
the current state for IS-IS protocol. the current state for 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 can not 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, most of the IGP deployments use
P2P-over-lan [RFC5309], which makes an adversary replay 'easier' than P2P-over-lan [RFC5309], which makes an adversary replay 'easier' than
the traditional P2P networks 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 is replayed, can cause damage, if there is no other
mechanism to confirm this is a replay packet. In inter-session mechanism to confirm this is a replay packet. In inter-session
replay attacks, captured packet from one of the previous session can replay attacks, captured packet from one of the previous session can
be replayed to cause the damage. IS-IS packets are vulnerable to be replayed to cause the damage. IS-IS packets are vulnerable to
skipping to change at page 9, line 41 skipping to change at page 9, line 41
deployable with key management protocols. deployable 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,
similar to as described in [I-D.weis-gdoi-mac-tek] can be used to similar to as described in [I-D.weis-gdoi-mac-tek] can be used to
distribute group keys to a group of ISes in Level-1 area or Level-2 distribute group keys to a group of ISes in Level-1 area or Level-2
domain, using GDOI as specified in [RFC6407]. There are also similar domain, using GDOI as specified in [RFC6407]. There are also similar
approaches with IKEv2 based group key management solutions, to approaches with IKEv2 based group key management solutions, to
routing protocols as described in [I-D.yeung-g-ikev2] and [I-D routing protocols as described in [I-D.yeung-g-ikev2] and [I-
.hartman-karp-mrkmp]. 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.
Group key management protocol deployed SHOULD be capable of Group key management protocol deployed SHOULD be capable of
supporting rekeying support. 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, sub network dependent messages (IIHs) can use
a different key shared between the two point-to-point peers, while a different key shared between the two point-to-point peers, while
all other messages use a group key. When group keying mechanism is all other messages use a group key. When group keying mechanism is
skipping to change at page 10, line 20 skipping to change at page 10, line 20
instance/topology for LSPs and SNPs as specified in the [RFC6822]. instance/topology for LSPs and SNPs as specified in the [RFC6822].
Effective key change capability with in the routing protocol which Effective key change capability with in the routing protocol which
allows key roll over without impacting the routing protocol allows key roll over without impacting the routing protocol
operation, is one of the requirements for deploying any group key operation, is one of the requirements for deploying any group key
mechanism. Once such mechanism is in place with deployment of group mechanism. Once such mechanism is in place with deployment of group
key management protocol, IS-IS can be protected from various threats key management protocol, IS-IS can be protected from various threats
not limited to intra and inter session replay attacks and spoofing not limited to intra and inter session replay attacks and spoofing
attacks. attacks.
Specific use of crypto tables [I-D.ietf-karp-crypto-key-table] should Specific use of crypto tables [RFC7210] should be defined for IS-IS
be defined for IS-IS protocol. protocol.
4. IANA Considerations 4. IANA Considerations
This document defines no new namespaces. This document defines no new namespaces.
5. Security Considerations 5. Security Considerations
This document is mostly about security considerations of IS-IS This document is mostly about security considerations of IS-IS
protocol, lists potential threats and security requirements for protocol, lists potential threats and security requirements for
solving those threats. This document does not introduce any new solving those threats. This document does not introduce any new
skipping to change at page 11, line 22 skipping to change at page 11, line 22
and M. Fanto, "IS-IS Generic Cryptographic and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, February 2009. Authentication", RFC 5310, February 2009.
7.2. Informative References 7.2. Informative References
[I-D.hartman-karp-mrkmp] [I-D.hartman-karp-mrkmp]
Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router Hartman, S., Zhang, D., and G. Lebovitz, "Multicast Router
Key Management Protocol (MaRK)", draft-hartman-karp- Key Management Protocol (MaRK)", draft-hartman-karp-
mrkmp-05 (work in progress), September 2012. mrkmp-05 (work in progress), September 2012.
[I-D.ietf-karp-crypto-key-table]
Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys",
draft-ietf-karp-crypto-key-table-10 (work in progress),
December 2013.
[I-D.weis-gdoi-mac-tek] [I-D.weis-gdoi-mac-tek]
Weis, B. and S. Rowles, "GDOI Generic Message Weis, B. and S. Rowles, "GDOI Generic Message
Authentication Code Policy", draft-weis-gdoi-mac-tek-03 Authentication Code Policy", draft-weis-gdoi-mac-tek-03
(work in progress), September 2011. (work in progress), September 2011.
[I-D.yeung-g-ikev2] [I-D.yeung-g-ikev2]
Rowles, S., Yeung, A., Tran, P., and Y. Nir, "Group Key Rowles, S., Yeung, A., Tran, P., and Y. Nir, "Group Key
Management using IKEv2", draft-yeung-g-ikev2-07 (work in Management using IKEv2", draft-yeung-g-ikev2-07 (work in
progress), November 2013. progress), November 2013.
skipping to change at page 12, line 16 skipping to change at page 12, line 12
Routing Protocols (KARP) Design Guidelines", RFC 6518, Routing Protocols (KARP) Design Guidelines", RFC 6518,
February 2012. February 2012.
[RFC6822] Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D. [RFC6822] Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D.
Ward, "IS-IS Multi-Instance", RFC 6822, December 2012. Ward, "IS-IS Multi-Instance", RFC 6822, December 2012.
[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, March 2013.
[RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys", RFC
7210, April 2014.
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 USA
Phone: 408 750-5678 Phone: 408 750-5678
Email: uma.chunduri@ericsson.com Email: uma.chunduri@ericsson.com
 End of changes. 10 change blocks. 
17 lines changed or deleted 16 lines changed or added

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