draft-ietf-karp-routing-tcp-analysis-03.txt   draft-ietf-karp-routing-tcp-analysis-04.txt 
Routing Working Group M. Jethanandani Routing Working Group M. Jethanandani
Internet-Draft Ciena Corporation Internet-Draft Ciena Corporation
Intended status: Informational K. Patel Intended status: Informational K. Patel
Expires: January 7, 2013 Cisco Systems, Inc Expires: January 31, 2013 Cisco Systems, Inc
L. Zheng L. Zheng
Huawei Huawei
July 6, 2012 July 30, 2012
Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design Analysis of BGP, LDP, PCEP and MSDP Issues According to KARP Design
Guide Guide
draft-ietf-karp-routing-tcp-analysis-03.txt draft-ietf-karp-routing-tcp-analysis-04.txt
Abstract Abstract
This document analyzes BGP, LDP, PCEP and MSDP according to This document analyzes BGP, LDP, PCEP and MSDP according to
guidelines set forth in section 4.2 of Keying and Authentication for guidelines set forth in section 4.2 of Keying and Authentication for
Routing Protocols Design Guidelines [RFC6518]. Routing Protocols Design Guidelines [RFC6518].
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]..
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 January 7, 2013. This Internet-Draft will expire on January 31, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 2, line 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 3 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 3
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2. Current State of BGP, LDP, PCEP and MSDP . . . . . . . . . . . 5 2. Current State of BGP, LDP, PCEP and MSDP . . . . . . . . . . . 5
2.1. Transport layer . . . . . . . . . . . . . . . . . . . . . 5 2.1. Transport layer . . . . . . . . . . . . . . . . . . . . . 5
2.2. Keying mechanisms . . . . . . . . . . . . . . . . . . . . 6 2.2. Keying mechanisms . . . . . . . . . . . . . . . . . . . . 6
2.3. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1. Spoofing attacks . . . . . . . . . . . . . . . . . . . 7 2.3.1. Spoofing attacks . . . . . . . . . . . . . . . . . . . 6
2.3.2. Privacy Issues . . . . . . . . . . . . . . . . . . . . 8 2.3.2. Privacy Issues . . . . . . . . . . . . . . . . . . . . 7
2.3.3. Denial of Service Attacks . . . . . . . . . . . . . . 8 2.3.3. Denial of Service Attacks . . . . . . . . . . . . . . 8
2.4. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Optimal State for BGP, LDP, PCEP, and MSDP . . . . . . . . . . 10 3. Optimal State for BGP, LDP, PCEP, and MSDP . . . . . . . . . . 10
3.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Gap Analysis for BGP, LDP, PCEP and MSDP . . . . . . . . . . . 11 4. Gap Analysis for BGP, LDP, PCEP and MSDP . . . . . . . . . . . 11
4.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Transition and Deployment Considerations . . . . . . . . . . . 13 5. Transition and Deployment Considerations . . . . . . . . . . . 13
6. Security Requirements . . . . . . . . . . . . . . . . . . . . 14 6. Security Requirements . . . . . . . . . . . . . . . . . . . . 14
skipping to change at page 6, line 25 skipping to change at page 6, line 25
SP800-38B [NIST-SP800-38B]. Cryptographic research suggests that SP800-38B [NIST-SP800-38B]. Cryptographic research suggests that
both these MAC algorithms defined are fairly secure. TCP-AO allows both these MAC algorithms defined are fairly secure. TCP-AO allows
additional MACs to be added in the future. additional MACs to be added in the future.
2.2. Keying mechanisms 2.2. Keying mechanisms
For TCP-AO [RFC5925] there is no Key Management Protocol (KMP) used For TCP-AO [RFC5925] there is no Key Management Protocol (KMP) used
to manage the keys that are employed to generate the Message to manage the keys that are employed to generate the Message
Authentication Code (MAC). TCP-AO allows for a master key to be Authentication Code (MAC). TCP-AO allows for a master key to be
configured manually or for it to be managed via a out of band configured manually or for it to be managed via a out of band
mechanism. Most routers are configured with a static key that do not mechanism.
change over the life of a session, even if the session lasts for
days.
It should also be noted that most routers configured with static keys It should be noted that most routers configured with static keys have
have not seen the key changed ever. The common reason given for not not seen the key changed ever. The common reason given for not
changing the key is the difficulty in coordinating the change between changing the key is the difficulty in coordinating the change between
pairs of routers when using TCP MD5. It is well known that longer pairs of routers when using TCP MD5. It is well known that longer
the same key is used, higher is the chance that it can be guessed or the same key is used, higher is the chance that it can be guessed or
exposed e.g. when an administrator with knowledge of the keys leaves exposed e.g. when an administrator with knowledge of the keys leaves
the company. the company.
For point-to-point key management IKE [RFC2409] provides for For point-to-point key management IKEv2 [RFC5996] provides for
automated key exchange under a SA and can be used for a comprehensive automated key exchange under a SA and can be used for a comprehensive
Key Management Protocol (KMP) solution. Key Management Protocol (KMP) solution.
2.3. LDP 2.3. LDP
Section 5 of LDP [RFC5036] states that LDP is subject to two Section 5 of LDP [RFC5036] states that LDP is subject to two
different types of attacks: spoofing, and denial of service attacks. different types of attacks: spoofing, and denial of service attacks.
In addition, labels are distributed in the clear, enabling hackers to In addition, labels are distributed in the clear, enabling hackers to
see what labels are being exchanged that could then be used to launch see what labels are being exchanged that could then be used to launch
an attack. an attack.
skipping to change at page 11, line 47 skipping to change at page 11, line 47
There are two methods of automatic key rollover. Implicit key There are two methods of automatic key rollover. Implicit key
rollover can be initiated after certain volume of data gets exchanged rollover can be initiated after certain volume of data gets exchanged
or when a certain time has elapsed. This does not require explicit or when a certain time has elapsed. This does not require explicit
signaling nor should it result in a reset of the TCP connection in a signaling nor should it result in a reset of the TCP connection in a
way that the links/adjacencies are affected. On the other hand, way that the links/adjacencies are affected. On the other hand,
explicit key rollover requires a out of band key signaling mechanism. explicit key rollover requires a out of band key signaling mechanism.
It can be triggered by either side and can be done anytime a security It can be triggered by either side and can be done anytime a security
parameter changes e.g. an attack has happened, or a system parameter changes e.g. an attack has happened, or a system
administrator with access to the keys has left the company. An administrator with access to the keys has left the company. An
example of this is IKE [RFC2409] but it could be any other new example of this is IKEv2 [RFC5996] but it could be any other new
mechanisms also. mechanisms also.
As stated earlier TCP-AO [RFC5925] and its accompanying document As stated earlier TCP-AO [RFC5925] and its accompanying document
Crypto Algorithms for TCP-AO [RFC5926] suggest that two MAC Crypto Algorithms for TCP-AO [RFC5926] suggest that two MAC
algorithms that MUST be supported are HMAC-SHA-1-96 as specified in algorithms that MUST be supported are HMAC-SHA-1-96 as specified in
HMAC [RFC2104] and AES-128-CMAC-96 as specified in NIST-SP800-38B HMAC [RFC2104] and AES-128-CMAC-96 as specified in NIST-SP800-38B
[NIST-SP800-38B]. [NIST-SP800-38B].
There is a need to protect authenticity and validity of the routing/ There is a need to protect authenticity and validity of the routing/
label information that is carried in the payload of the sessions. label information that is carried in the payload of the sessions.
skipping to change at page 17, line 26 skipping to change at page 17, line 26
(PCE) Communication Protocol (PCEP)", RFC 5440, (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009. March 2009.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010. Authentication Option", RFC 5925, June 2010.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961, Robustness to Blind In-Window Attacks", RFC 5961,
August 2010. August 2010.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010.
[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, October 2010.
[draft-ietf-karp-ospf-analysis-03] [draft-ietf-karp-ospf-analysis-03]
Hartman, S., "Analysis of OSPF Security According to KARP Hartman, S., "Analysis of OSPF Security According to KARP
Design Guide", March 2012. Design Guide", March 2012.
[draft-zheng-mpls-ldp-hello-crypto-auth-04] [draft-zheng-mpls-ldp-hello-crypto-auth-04]
Zheng, "LDP Hello Cryptographic Authentication", May 2012. Zheng, "LDP Hello Cryptographic Authentication", May 2012.
 End of changes. 10 change blocks. 
13 lines changed or deleted 15 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/