draft-ietf-karp-isis-analysis-01.txt   draft-ietf-karp-isis-analysis-02.txt 
KARP 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: April 23, 2014 Ericsson Inc., Expires: August 9, 2014 Ericsson Inc.,
October 20, 2013 February 5, 2014
KARP IS-IS security analysis KARP IS-IS security analysis
draft-ietf-karp-isis-analysis-01 draft-ietf-karp-isis-analysis-02
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 35
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 April 23, 2014. This Internet-Draft will expire on August 9, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
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
skipping to change at page 2, line 27 skipping to change at page 2, line 19
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. Sub network Independent . . . . . . . . . . . . . . . 4
2.1.2. Sub network dependent . . . . . . . . . . . . . . . . 4 2.1.2. Sub network 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 . . . . . . . 7 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11 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 Intermediate system to
Intermediate system (IS-IS) protocol according to the requirements Intermediate system (IS-IS) protocol according to the requirements
set forth in [RFC6518] for both manual and auto key management set forth in [RFC6518] for both manual and auto key management
protocols. protocols.
skipping to change at page 6, line 33 skipping to change at page 6, line 30
2. Today LSPs have intra-session replay protection as LSP header 2. Today LSPs have intra-session replay protection as LSP header
contains 32-bit sequence number which is verified for every contains 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 the network is out of service (is undergoing some sort of high in 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-session replay attacks in the network. If the key is not inter-session replay attacks in the network. If the key is not
changed in the above circumstances, attack can be launched by changed in the above circumstances, attack can be launched by
replaying a old LSP with higher sequence number and fewer replaying an old LSP with higher sequence number and fewer
prefixes or fewer adjacencies. This may force the receiver to prefixes or fewer adjacencies. This may force the receiver to
accept and remove the routes from the routing table, which accept and remove the routes from the routing table, which
eventually causes traffic disruption to those prefixes. However, eventually causes traffic disruption to those prefixes. However,
as per the IS-IS specification there is a built-in recovery as per the IS-IS specification there is a built-in recovery
mechanism for LSPs from inter-session replay attacks and it is mechanism for LSPs from inter-session replay attacks and it is
further discussed in Section 2.3.1.1. further discussed in Section 2.3.1.1.
3. In any IS-IS network (broadcast or otherwise), if a 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 network. broadcast 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 LSP
with higher sequence number gets accepted, it also gets propagated with higher sequence number gets accepted, it also gets propagated
until it reaches the originating node of the LSP. The originator until it reaches the originating node of the LSP. The originator
skipping to change at page 7, line 40 skipping to change at page 7, line 31
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 it self is used as authentication Currently possession of the key itself is used as 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 as a means for
launching various types of attacks. For example: launching various types 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 having access to the common key used to protect
skipping to change at page 11, line 29 skipping to change at page 11, line 25
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] [I-D.ietf-karp-crypto-key-table]
Housley, R., Polk, T., Hartman, S., and D. Zhang, Housley, R., Polk, T., Hartman, S., and D. Zhang,
"Database of Long-Lived Symmetric Cryptographic Keys", "Database of Long-Lived Symmetric Cryptographic Keys",
draft-ietf-karp-crypto-key-table-08 (work in progress), draft-ietf-karp-crypto-key-table-10 (work in progress),
July 2013. 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-06 (work in Management using IKEv2", draft-yeung-g-ikev2-07 (work in
progress), April 2013. progress), November 2013.
[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, June 1997.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, June 2005. Key Management", BCP 107, RFC 4107, June 2005.
[RFC5309] Shen, N. and A. Zinin, "Point-to-Point Operation over LAN [RFC5309] Shen, N. and A. Zinin, "Point-to-Point Operation over LAN
in Link State Routing Protocols", RFC 5309, October 2008. in Link State Routing Protocols", RFC 5309, October 2008.
 End of changes. 11 change blocks. 
14 lines changed or deleted 14 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/