draft-ietf-karp-routing-tcp-analysis-02.txt   draft-ietf-karp-routing-tcp-analysis-03.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: December 25, 2012 Cisco Systems, Inc Expires: January 7, 2013 Cisco Systems, Inc
L. Zheng L. Zheng
Huawei Huawei
June 23, 2012 July 6, 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-02.txt draft-ietf-karp-routing-tcp-analysis-03.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 December 25, 2012. This Internet-Draft will expire on January 7, 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 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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 level . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 6 2.3.1. Spoofing attacks . . . . . . . . . . . . . . . . . . . 7
2.3.2. Privacy Issues . . . . . . . . . . . . . . . . . . . . 7 2.3.2. Privacy Issues . . . . . . . . . . . . . . . . . . . . 8
2.3.3. Denial of Service Attacks . . . . . . . . . . . . . . 7 2.3.3. Denial of Service Attacks . . . . . . . . . . . . . . 8
2.4. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.5. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Optimal State for BGP, LDP, PCEP, and MSDP . . . . . . . . . . 9 3. Optimal State for BGP, LDP, PCEP, and MSDP . . . . . . . . . . 10
3.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. Gap Analysis for BGP, LDP, PCEP and MSDP . . . . . . . . . . . 10 4. Gap Analysis for BGP, LDP, PCEP and MSDP . . . . . . . . . . . 11
4.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. LDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. PCEP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Transition and Deployment Considerations . . . . . . . . . . . 12 5. Transition and Deployment Considerations . . . . . . . . . . . 13
6. Security Requirements . . . . . . . . . . . . . . . . . . . . 13 6. Security Requirements . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
In March 2006 the Internet Architecture Board (IAB) in its "Unwanted In March 2006 the Internet Architecture Board (IAB) in its "Unwanted
Internet Traffic" workshop documented in Report from the IAB workshop Internet Traffic" workshop documented in Report from the IAB workshop
on Unwanted Traffic March 9-10, 2006 [RFC4948] described an attack on on Unwanted Traffic March 9-10, 2006 [RFC4948] described an attack on
core routing infrastructure as an ideal attack with the most amount core routing infrastructure as an ideal attack with the most amount
of damage. Four main steps were identified for that tightening: of damage. Four main steps were identified for that tightening:
1. Create secure mechanisms and practices for operating routers. 1. Create secure mechanisms and practices for operating routers.
2. Clean up the Internet Routing Registry [IRR] repository, and 2. Clean up the Internet Routing Registry [IRR] repository, and
securing both the database and the access, so that it can be used securing both the database and the access, so that it can be used
for routing verifications. for routing verifications.
3. Create specifications for cryptographic validation of routing 3. Create specifications for cryptographic validation of routing
message content. message content.
4. Secure the routing protocols' packets on the wire. 4. Secure the routing protocols' packets on the wire.
This document looking at the last bullet performs the initial This document looking at the last bullet performs an initial analysis
analysis of the current state of BGP, LDP, PCEP and MSDP according to of the current state of BGP, LDP, PCEP and MSDP according to the
the requirements of KARP Design Guidelines [RFC6518]. This draft requirements of KARP Design Guidelines [RFC6518]. This draft builds
builds on several previous analysis efforts into routing security. on several previous analysis efforts into routing security. The
The OPSEC working group put together Issues with existing OPSEC working group published Issues with existing Cryptographic
Cryptographic Protection Methods for Routing Protocols [RFC6039] an Protection Methods for Routing Protocols [RFC6039] an analysis of
analysis of cryptographic issues with routing protocols and Analysis cryptographic issues with routing protocols and Analysis of OSPF
of OSPF Security According to KARP Design Guide Security According to KARP Design Guide
[draft-ietf-karp-ospf-analysis-03]. [draft-ietf-karp-ospf-analysis-03].
Section 2 looks at the current state of the four routing protocols. Section 2 of this document looks at the current state of security for
Section 3 goes into what the optimal state would be for the three the four routing protocols. Section 3 examines what the optimal
routing protocols according to KARP Design Guidelines [RFC6518] and state would be for the four routing protocols according to KARP
Section 4 does a analysis of the gap between the existing state and Design Guidelines [RFC6518] and Section 4 does a analysis of the gap
the optimal state of the protocols and suggest some areas where we between the existing state and the optimal state of the protocols and
need to improve. suggests some areas where improvement is needed.
1.1. Contributing Authors 1.1. Contributing Authors
Anantha Ramaiah, Mach Chen Anantha Ramaiah, Mach Chen
1.2. Abbreviations 1.2. Abbreviations
BGP - Border Gateway Protocol BGP - Border Gateway Protocol
DoS - Denial of Service DoS - Denial of Service
skipping to change at page 5, line 7 skipping to change at page 5, line 7
OSPF - OPen Shortest Path First OSPF - OPen Shortest Path First
PCEP - Path Computation Element Protocol PCEP - Path Computation Element Protocol
TCP - Transmission Control Protocol TCP - Transmission Control Protocol
UDP - User Datagram Protocol UDP - User Datagram Protocol
2. Current State of BGP, LDP, PCEP and MSDP 2. Current State of BGP, LDP, PCEP and MSDP
This section looks at the underlying transport protocol and key This section looks at the current state of transport protocol and any
mechanisms built for the protocol. It describes the security authentication mechanisms used by the protocol. It describes the
mechanisms built into BGP, LDP, PCEP and MSDP. current security mechanisms if any used by BGP, LDP, PCEP and MSDP.
2.1. Transport level 2.1. Transport layer
At a transport level, routing protocols are subject to a variety of At a transport layer, routing protocols are subject to a variety of
DoS attacks. Such attacks can cause the routing protocol to become DoS attacks as outlined in Internet Denial-of-Service Considerations
[RFC4732]. Such attacks can cause the routing protocol to become
congested with the result that routing updates are supplied too congested with the result that routing updates are supplied too
slowly to be useful or in extreme case prevent route convergence slowly to be useful. In extreme cases, these attacks prevent routes
after a change. from converging after a change.
Routing protocols use several methods to protect themselves. Those Routing protocols use several methods to protect themselves. Those
that run use TCP as a transport protocol use access list to permit that use TCP as a transport protocol use access lists to accept
packets from know sources only. These access lists also help edge packets only from known sources. These access lists also help
routers from attacks originating from outside the protected cloud. protect edge routers from attacks originating from outside the
In addition for edge routers running eBGP, TCP LISTEN is run only on protected domain. In addition for edge routers running eBGP, TCP
interfaces on which its peers have been discovered or that are LISTEN is run only on interfaces on which its peers have been
configured to expect routing sessions on. discovered or via which routing sessions are expected (as specified
in router configuration databases).
GTSM [RFC5082] describes a generalized Time to Live (TTL) security GTSM [RFC5082] describes a generalized Time to Live (TTL) security
mechanism to protect a protocol stack from CPU-utilization based mechanism to protect a protocol stack from CPU-utilization based
attacks.TCP Robustness [RFC5961] recommends some TCP level attacks.TCP Robustness [RFC5961] recommends some TCP level
mitigations against spoofing attacks targeted towards long lived mitigations against spoofing attacks targeted towards long-lived
routing protocol sessions. routing protocol sessions.
Even when BGP, LDP, PCEP and MSDP sessions use access list they are Even when BGP, LDP, PCEP and MSDP sessions use access lists they are
subject to spoofing and man in the middle attacks. Authentication subject to spoofing and man in the middle attacks. Authentication
and integrity checks allow the receiver of a routing protocol update and integrity checks allow the receiver of a routing protocol update
to know that the message genuinely comes from the node that purports to know that the message genuinely comes from the node that purports
to have sent it and to know whether the message has been modified. to have sent it, and to know whether the message has been modified.
Sometimes routers can be subjected to a large number of Sometimes routers can be subjected to a large number of
authentication and integrity checks which can result in genuine authentication and integrity requests, exhausting connection
requests failing. resources on the router in a way that deny genuine requests.
TCP MD5 [RFC2385] specifies a mechanism to protect BGP and other TCP TCP MD5 [RFC2385] deprecated, but widely used, specifies a mechanism
based routing protocols via the TCP MD5 option. TCP MD5 option to protect BGP and other TCP based routing protocols via the TCP MD5
provides a way for carrying an MD5 digest in a TCP segment. This option. TCP MD5 option provides a way for carrying an MD5 digest in
digest acts like a signature for that segment, incorporating a TCP segment. This digest acts like a signature for that segment,
information known only to the connection end points. The MD5 key computed using information known only to the connection end points.
used to compute the digest is stored locally on the router. This The MD5 key used to compute the digest is stored locally on the
option is used by routing protocols to provide for session level router. This option is used by routing protocols to provide for
protection against the introduction of spoofed TCP segments into any session level protection against the introduction of spoofed TCP
existing TCP streams, in particular TCP Reset segments. TCP MD5 does segments into any existing TCP streams, in particular TCP Reset
not provide a generic mechanism to support key roll-over. segments. TCP MD5 does not provide a generic mechanism to support
key roll-over.
However, the Message Authentication Codes (MACs) used by MD5 to The Message Authentication Codes (MACs) used by the TCP MD5 option is
compute the signature are considered to be too weak. TCP-AO considered too weak both because of the use of the hash function and
because of the way the secret key used by TCP MD5 is managed. TCP-AO
[RFC5925] and its companion document Crypto Algorithms for TCP-AO [RFC5925] and its companion document Crypto Algorithms for TCP-AO
[RFC5926] describe steps towards correcting both the MAC weakness and [RFC5926] describe steps towards correcting both the MAC weakness and
KMP. For MAC it specifies two MAC algorithms that MUST be supported. the management of secret keys. For MAC it specifies two MAC
They are HMAC-SHA-1-96 as specified in HMAC [RFC2104] and AES-128- algorithms that MUST be supported. They are HMAC-SHA-1-96 as
CMAC-96 as specified in NIST-SP800-38B [NIST-SP800-38B]. specified in HMAC [RFC2104] and AES-128-CMAC-96 as specified in NIST-
Cryptographic research suggests that both these MAC algorithms SP800-38B [NIST-SP800-38B]. Cryptographic research suggests that
defined are fairly secure and are not known to be broken in any ways. both these MAC algorithms defined are fairly secure. TCP-AO allows
It also provides for 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 used for generating the Message to manage the keys that are employed to generate the Message
Authentication Code (MAC). It 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 from 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 does mechanism. Most routers are configured with a static key that do not
not change over the life of the session. change over the life of a session, even if the session lasts for
days.
It should also be mentioned that those routers that have been It should also be noted that most routers configured with static keys
configured with static keys have not seen the key changed. The have not seen the key changed ever. The common reason given for not
common reason given for not changing the key is the difficulty in changing the key is the difficulty in coordinating the change between
coordinating the change, at least with TCP MD5. It is well known pairs of routers when using TCP MD5. It is well known that longer
that longer the same key is used, higher is the chance that it can be the same key is used, higher is the chance that it can be guessed or
guessed, particularly if it is not a strong key. exposed e.g. when an administrator with knowledge of the keys leaves
the company.
For point-to-point key management IKE [RFC2409] tries to solve the For point-to-point key management IKE [RFC2409] provides for
issue of key exchange under a SA. automated key exchange under a SA and can be used for a comprehensive
Key Management Protocol (KMP) solution.
2.3. LDP 2.3. LDP
Section 5 of LDP [RFC5036] states that LDP is subject to three Section 5 of LDP [RFC5036] states that LDP is subject to two
different types of attacks. These are spoofing, protection of different types of attacks: spoofing, and denial of service attacks.
privacy of label distribution and denial of service attacks. In addition, labels are distributed in the clear, enabling hackers to
see what labels are being exchanged that could then be used to launch
an attack.
2.3.1. Spoofing attacks 2.3.1. Spoofing attacks
Spoofing attack for LDP occur both during the discovery phase and A spoofing attack against LDP can occur both during the discovery
during the session communication phase. phase and during the session communication phase.
2.3.1.1. Discovery exchanges using UDP 2.3.1.1. Discovery exchanges using UDP
Label Switching Routers (LSRs) indicate their willingness to Label Switching Routers (LSRs) indicate their willingness to
establish and maintain LDP sessions by periodically sending Hello establish and maintain LDP sessions by periodically sending Hello
messages. Receipt of a Hello message serves to create a new "Hello messages. Receipt of a Hello message serves to create a new "Hello
adjacency", if one does not already exist, or to refresh an existing adjacency", if one does not already exist, or to refresh an existing
one. one.
Unlike all other LDP messages, the Hello messages are sent using UDP Unlike all other LDP messages, the Hello messages are sent using UDP.
not TCP. This means that they cannot benefit from the security This means that they cannot benefit from the security mechanisms
mechanisms available with TCP. LDP [RFC5036] does not provide any available with TCP. LDP [RFC5036] does not provide any security
security mechanisms for use with Hello messages except to note that mechanisms for use with Hello messages except for some configuration
some configuration may help protect against bogus discovery events. which may help protect against bogus discovery events. These
configurations include directly connected links and interfaces.
Routers that do not use directly connected links have to use Extended
Hello messages.
Spoofing a Hello packet for an existing adjacency can cause the Spoofing a Hello packet for an existing adjacency can cause the
adjacency to time out and that can result in termination of the adjacency to time out and result in termination of the associated
associated session. This can occur when the spoofed Hello message session. This can occur when the spoofed Hello message specifies a
specifies a small Hold Time, causing the receiver to expect Hello small Hold Time, causing the receiver to expect Hello messages within
messages within this interval, while the true neighbor continues this interval, while the true neighbor continues sending Hello
sending Hello messages at the lower, previously agreed to, frequency. messages at the lower, previously agreed to frequency.
Spoofing a Hello packet can also cause the LDP session to be Spoofing a Hello packet can also cause the LDP session to be
terminated directly. This can occur when the spoofed Hello specifies terminated. This can occur when the spoofed Hello specifies a
a different Transport Address from the previously agreed one between different Transport Address from the previously agreed one between
neighbors. Spoofed Hello messages are observed and reported as real neighbors. Spoofed Hello messages are observed and reported as real
problem in production networks. problem in production networks.
2.3.1.2. Session communication using TCP 2.3.1.2. Session communication using TCP
LDP like other TCP based routing protocols specifies use of the TCP LDP like other TCP based routing protocols specifies use of the TCP
MD5 Signature Option to provide for the authenticity and integrity of MD5 Signature Option to provide for the authenticity and integrity of
session messages. As stated above, some assert that MD5 session messages. As stated above, MD5 authentication is considered
authentication is now considered by some to be too weak for this too weak for this application. A stronger hashing algorithm e.g
application. A stronger hashing algorithm e.g SHA1, could be SHA1, which is supported by TCP-AO [RFC5925] could be deployed to
deployed to take care of the weakness. take care of the weakness.
Alternatively, one could move to using TCP-AO which provides for Alternatively, one could move to using TCP-AO which provides for
stronger MACs and protects against replays. stronger MACs, makes it easier to setup manual keys and protects
against replays.
2.3.2. Privacy Issues 2.3.2. Privacy Issues
LDP provides no mechanism for protecting the privacy of label LDP provides no mechanism for protecting the privacy of label
distribution. The security requirements of label distribution are distribution. The security requirements of label distribution are
similar to other routing protocols that need to distribute routing similar to other routing protocols that need to distribute routing
information. information and as such LDP is vulnerable to the same extent as other
routing protocols that distribute their routing information in the
clear.
2.3.3. Denial of Service Attacks 2.3.3. Denial of Service Attacks
LDP is subject to Denial of Service (DoS) attacks both in its LDP is subject to Denial of Service (DoS) attacks both in its
discovery mode as well as during the session mode. discovery mode and in session mode.
The discovery mode attack is similar to the spoofing attack except The discovery mode attack is similar to the spoofing attack except
that when the spoofed Hello messages are sent with a high enough that when the spoofed Hello messages are sent with a high enough
frequency can cause the adjacency to time out. frequency, it can cause the adjacency to time out.
2.4. PCEP 2.4. PCEP
Attacks on PCEP [RFC5440] may result in damage to active networks. Attacks on PCEP [RFC5440] may result in damage to active networks.
This may include computation responses, which if changed can cause These include computation responses, which if changed can cause
protocols like LDP to setup sub-optimal or inappropriate LSPs. In protocols like LDP to setup sub-optimal or inappropriate LSPs. In
addition, PCE itself can be attacked by a variety of DoS attacks. addition, PCE itself can be attacked by a variety of DoS attacks.
Such attacks can cause path computations to be supplied too slowly to Such attacks can cause path computations to be supplied too slowly to
be of any value particularly as it relates to recovery or be of any value particularly as it relates to recovery or
establishment of LSPs. establishment of LSPs.
As the RFC states, PCEP could be the target of the following attacks. As the RFC states, PCEP could be the target of the following attacks.
o Spoofing (PCC or PCE implementation) o Spoofing (PCC or PCE implementation)
skipping to change at page 8, line 30 skipping to change at page 8, line 48
o Falsification o Falsification
o Denial of Service o Denial of Service
According to the RFC, inter-AS scenarios when PCE-to-PCE According to the RFC, inter-AS scenarios when PCE-to-PCE
communication is required, attacks may be particularly significant communication is required, attacks may be particularly significant
with commercial as well as service-level implications. with commercial as well as service-level implications.
Additionally, snooping of PCEP requests and responses may give an Additionally, snooping of PCEP requests and responses may give an
attacker information about the operation of the network. Simply by attacker information about the operation of the network. By viewing
viewing the PCEP messages someone can determine the pattern of the PCEP messages an attacker can determine the pattern of service
service establishment in the network and can know where traffic is establishment in the network and can know where traffic is being
being routed, thereby making the network susceptible to targeted routed, thereby making the network susceptible to targeted attacks
attacks and the data within specific LSPs vulnerable. and the data within specific LSPs vulnerable.
Ensuring PCEP communication privacy is of key importance, especially Ensuring PCEP communication privacy is of key importance, especially
in an inter-AS context, where PCEP communication end-points do not in an inter-AS context, where PCEP communication end-points do not
reside in the same AS, as an attacker that intercepts a PCE message reside in the same AS. An attacker that intercepts a PCE message
could obtain sensitive information related to computed paths and could obtain sensitive information related to computed paths and
resources. resources.
2.5. MSDP 2.5. MSDP
Similar to BGP and LDP, TCP MD5 [RFC2385] specifies a mechanism to Similar to BGP and LDP, MSDP uses TCP MD5 [RFC2385] to protect TCP
protect TCP sessions via the TCP MD5 option. But with a weak MD5 sessions via the TCP MD5 option. But with a weak MD5 authentication,
authentication, TCP MD5 is not considered strong enough for this TCP MD5 is not considered strong enough for this application.
application.
MSDP also advocates imposing a limit on number of source address and MSDP also advocates imposing a limit on number of source address and
group addresses (S,G) that can be stored within the protocol and group addresses (S,G) that can be stored within the protocol and
thereby mitigate state explosion due to any denial of service and thereby mitigate state explosion due to any denial of service and
other attacks. other attacks.
3. Optimal State for BGP, LDP, PCEP, and MSDP 3. Optimal State for BGP, LDP, PCEP, and MSDP
The ideal state for BGP, LDP and MSDP protocols are when they can The ideal state for BGP, LDP, PCEP and MSDP protocols are when they
withstand any of the known types of attacks. can withstand any of the known types of attacks.
Additionally, Key Management Protocol (KMP) for the routing sessions Additionally, Key Management Protocol (KMP) for the routing sessions
should help negotiate unique, pair wise random keys without should help negotiate unique, pair wise random keys without
administrator involvement. It should also negotiate Security administrator involvement. It should also negotiate Security
Association (SA) parameter required for the session connection, Association (SA) parameter required for the session connection,
including key life times. It should keep track of those lifetimes including key life times. It should keep track of those lifetimes
and negotiate new keys and parameters before they expire and do so and negotiate new keys and parameters before they expire and do so
without administrator involvement. In the event of a breach, without administrator involvement. In the event of a breach,
including when an administrator with knowledge of the keys leaves the including when an administrator with knowledge of the keys leaves the
company, the keys should be changed immediately. company, the keys should be changed immediately.
The DoS attacks for BGP, LDP, PCEP and MSDP are attacks to the The DoS attacks for BGP, LDP, PCEP and MSDP are attacks to the
transport protocol, TCP in this case. TCP should be able to transport protocol, TCP for the most part and UDP in case of
withstand any of DoS scenarios by dropping packets that are attack discovery phase of LDP. TCP and UDP should be able to withstand any
packets in a way that does not impact legitimate packets. of DoS scenarios by dropping packets that are attack packets in a way
that does not impact legitimate packets.
The routing protocols should provide a mechanism to determine The routing protocols should provide a mechanism to authenticate the
authenticate and validate the routing information carried within the routing information carried within the payload.
payload.
3.1. LDP 3.1. LDP
For the spoofing kind of attacks that LDP is vulnerable to during the For spoofing attacks that LDP is vulnerable to during the discovery
discovery phase, it should be able to determine the authenticity of phase, LDP should be able to determine the authenticity of the
the neighbors sending the Hello message. neighbors sending the Hello message.
There is currently no requirement to protect the privacy of label There is currently no requirement to protect the privacy of label
distribution as labels are carried in the clear like other routing distribution as labels are carried in the clear like other routing
information. information.
4. Gap Analysis for BGP, LDP, PCEP and MSDP 4. Gap Analysis for BGP, LDP, PCEP and MSDP
This section outlines the differences between the current state of This section outlines the differences between the current state of
the routing protocol and the desired state as outlined in section 4.2 the routing protocol and the desired state as outlined in section 4.2
of KARP Design Guidelines [RFC6518]. As that document states, these of KARP Design Guidelines [RFC6518]. As that document states, these
routing protocols fall into the category of the one-to-one peering routing protocols fall into the category of one-to-one peering
messages and will use peer keying protocol. It covers issues that messages and will use peer keying protocol. It covers issues that
are common to the four protocols leaving protocol specific issues to are common to the four protocols in this section, leaving protocol
sub-sections. specific issues to sub-sections.
At a transport level the routing protocols are subject to some of the At a transport level the routing protocols are subject to some of the
same attacks that TCP applications are subject to. These include but same attacks that TCP applications are subject to. These include DoS
are not limited to DoS attacks. Defending TCP Against Spoofing and spoofing attacks. Internet Denial-of-Service Considerations
Attacks [RFC4953] recommends ways to do just that. In addition [RFC4732] outlines some solutions. Defending TCP Against Spoofing
Improving TCP's Robustness to Blind In-Window Attacks. [RFC5961] Attacks [RFC4953] recommends ways to prevent spoofing attacks. In
should also be followed and implemented. addition Improving TCP's Robustness to Blind In-Window Attacks.
[RFC5961] should also be followed and implemented to strengthen TCP.
From a security perspective there is a lack of comprehensive KMP. As From a security perspective there is lack of comprehensive KMP. As
an example TCP-AO [RFC5925] talks about coordinating keys derived an example TCP-AO [RFC5925], talks about coordinating keys derived
from MKT between endpoints, but the MKT itself has to be configured from MKT between endpoints, but the MKT itself has to be configured
manually or through a out of band mechanism. Even when keys are manually or through a out of band mechanism. Also TCP-AO does not
configured manually, a method for when to start using the new keys or address the issue of connectionless reset, as it applies to routers
stop using old keys has not been defined. This leads to keys not that do not store MKT across reboots.
being updated regularly which in itself increases the security risk.
Also TCP-AO does not address the issue of connectionless reset, as it
applies to routers that do not store MKT across reboots.
Authentication, tamper protection, and encryption all require the use Authentication, tamper protection, and encryption all require the use
of keys by sender and receiver. An automated KMP therefore has to of keys by sender and receiver. An automated KMP therefore has to
include a way to distribute MKT between two end points with little or include a way to distribute MKT between two end points with little or
no administration overhead. It has to cover automatic key rollover. no administration overhead. It has to cover automatic key rollover.
It is expected that authentication will cover the packet, i.e. the It is expected that authentication will cover the packet, i.e. the
payload and the TCP header and will not cover the frame i.e. the link payload and the TCP header and will not cover the frame i.e. the link
layer 2 header. layer 2 header.
There are two methods of automatic key rollover. Implicit key There are two methods of automatic key rollover. Implicit key
skipping to change at page 11, line 11 skipping to change at page 12, line 9
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.
However, we believe that is outside the scope of this document at However, that is outside the scope of this document at this time and
this time and is being addressed by SIDR WG. Similar mechanisms is being addressed by SIDR WG. Similar mechanisms could be used for
could be used for intra-domain protocols. intra-domain protocols.
4.1. LDP 4.1. LDP
As described in LDP [RFC5036], the threat of spoofed Basic Hellos can As described in LDP [RFC5036], the threat of spoofed Basic Hellos can
be reduced by accepting Basic Hellos on interfaces that LSRs trust, be reduced by accepting Basic Hellos on interfaces that LSRs trust,
employing GTSM [RFC5082] and ignoring Basic Hellos not addressed to employing GTSM [RFC5082] and ignoring Basic Hellos not addressed to
the "all routers on this subnet" multicast group. Spoofing attacks the "all routers on this subnet" multicast group. Spoofing attacks
via Extended Hellos are potentially a more serious threat. An LSR via Extended Hellos are potentially a more serious threat. An LSR
can reduce the threat of spoofed Extended Hellos by filtering them can reduce the threat of spoofed Extended Hellos by filtering them
and accepting Hellos from sources permitted by an access list. and accepting Hellos from sources permitted by an access lists.
However, performing the filtering using access lists requires LSR However, performing the filtering using access lists requires LSR
resource, and the LSR is still vulnerable to the IP source address resource, and the LSR is still vulnerable to the IP source address
spoofing. Spoofing attacks can be solved by being able to spoofing. Spoofing attacks can be solved by being able to
authenticate the Hello messages, and an LSR can be configured to only authenticate the Hello messages, and an LSR can be configured to only
accept Hello messages from specific peers when authentication is in accept Hello messages from specific peers when authentication is in
use. use.
LDP Hello Cryptographic Authentication LDP Hello Cryptographic Authentication
[draft-zheng-mpls-ldp-hello-crypto-auth-01] suggest a new [draft-zheng-mpls-ldp-hello-crypto-auth-04] suggest a new
Cryptographic Authentication TLV that can be used as an Cryptographic Authentication TLV that can be used as an
authentication mechanism to secure Hello messages. authentication mechanism to secure Hello messages.
4.2. PCEP 4.2. PCEP
PCE discovery according to its RFC is a significant feature for the PCE discovery according to its RFC is a significant feature for the
successful deployment of PCEP in large networks. This mechanism successful deployment of PCEP in large networks. This mechanism
allows a PCC to discover the existence of suitable PCEs within the allows a PCC to discover the existence of suitable PCEs within the
network without the necessity of configuration. It should be obvious network without the necessity of configuration. It should be obvious
that, where PCEs are discovered and not configured, the PCC cannot that, where PCEs are discovered and not configured, the PCC cannot
know the correct key to use. There are different approaches to know the correct key to use. There are different approaches to
retain some aspect of security, but all of them require use of a keys retain some aspect of security, but all of them require use of a keys
and a keying mechanism, the need for which has been discussed above. and a keying mechanism, the need for which has been discussed above.
5. Transition and Deployment Considerations 5. Transition and Deployment Considerations
As stated in KARP Design Guidelines [RFC6518] it is imperative that As stated in KARP Design Guidelines [RFC6518] it is imperative that
the new authentication and security mechanisms defined support the new authentication and security mechanisms defined support
incremental deployment, as it is not feasible to deploy the new incremental deployment, as it is not feasible to deploy the new
routing protocol authentication mechansim overnight. routing protocol authentication mechanism overnight.
Typically authentication and security in a peer-to-peer protocol Typically authentication and security in a peer-to-peer protocol
requires that both parties agree to the mechanisms that will be used. requires that both parties agree to the mechanisms that will be used.
If an agreement is not reached the setup of the new mechanism will If an agreement is not reached the setup of the new mechanism will
fail or will be deferred. Upon failure, the routing protocols can fail or will be deferred. Upon failure, the routing protocols can
fallback to the mechanisms that were already in place e.g. use static fallback to the mechanisms that were already in place e.g. use static
keys if that was the mechanism in place. It is usually not possible keys if that was the mechanism in place. It is usually not possible
for one end to use the new mechanism while the other end uses the for one end to use the new mechanism while the other end uses the
old. Policies can be put in place to retry upgrading after a said old. Policies can be put in place to retry upgrading after a said
period of time, so a manual coordiantion is not required. period of time, so a manual coordination is not required.
If the automatic KMP requires use of public/private keys to exchange If the automatic KMP requires use of public/private keys to exchange
key material, the required CA root certificates may need to be key material, the required CA root certificates may need to be
installed to verify authenticity of requests initiated by a peer. installed to verify authenticity of requests initiated by a peer.
Such a step does not require coordination with the peer except to Such a step does not require coordination with the peer except to
decide what CA authority will be used. decide what CA authority will be used.
6. Security Requirements 6. Security Requirements
This section describes requirements for BGP, LDP, PCEP and MSDP This section describes requirements for BGP, LDP, PCEP and MSDP
skipping to change at page 15, line 46 skipping to change at page 16, line 46
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The [RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003. Group Domain of Interpretation", RFC 3547, July 2003.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
Service Considerations", RFC 4732, December 2006.
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the
IAB workshop on Unwanted Traffic March 9-10, 2006", IAB workshop on Unwanted Traffic March 9-10, 2006",
RFC 4948, August 2007. RFC 4948, August 2007.
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks",
RFC 4953, July 2007. RFC 4953, July 2007.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
skipping to change at page 16, line 31 skipping to change at page 17, line 34
August 2010. August 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-01] [draft-zheng-mpls-ldp-hello-crypto-auth-04]
Zheng, "LDP Hello Cryptographic Authentication", Zheng, "LDP Hello Cryptographic Authentication", May 2012.
March 2011.
Authors' Addresses Authors' Addresses
Mahesh Jethanandani Mahesh Jethanandani
Ciena Corporation Ciena Corporation
1741 Technology Drive 1741 Technology Drive
San Jose, CA 95110 San Jose, CA 95110
USA USA
Phone: + (408) 436-3313 Phone: + (408) 436-3313
 End of changes. 54 change blocks. 
158 lines changed or deleted 172 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/