One document matched: draft-ietf-karp-routing-tcp-analysis-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc category="info" docName="draft-ietf-karp-routing-tcp-analysis-01.txt"
ipr="trust200902">
<front>
<title abbrev="BGP, LDP, PCEP and MSDP Analysis">Analysis of BGP, LDP,
PCEP, and MSDP Security According to KARP Design Guide</title>
<author fullname="Mahesh Jethanandani" initials="M."
surname="Jethanandani">
<organization>Private</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>USA</country>
</postal>
<phone></phone>
<email>mjethanandani@gmail.com</email>
</address>
</author>
<author fullname="Keyur Patel" initials="K." surname="Patel">
<organization>Cisco Systems, Inc</organization>
<address>
<postal>
<street>170 Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 (408) 526-7183</phone>
<email>keyupate@cisco.com</email>
</address>
</author>
<author fullname="Lianshu Zheng" initials="L." surname="Zheng">
<organization>Huawei</organization>
<address>
<postal>
<street>No. 3 Xinxi Road, Hai-Dian District</street>
<city>Beijing</city>
<region></region>
<code>100085</code>
<country>China</country>
</postal>
<phone>+86 (10) 82882008</phone>
<facsimile></facsimile>
<email>verozheng@huawei.com</email>
<uri></uri>
</address>
</author>
<date day="26" month="March" year="2012" />
<area>Network</area>
<workgroup>Routing Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document analyzes BGP, LDP, PCEP and MSDP according to
guidelines set forth in section 4.2 of <xref target="RFC6518">Keying and
Authentication for Routing Protocols Design Guidelines </xref>.</t>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>..</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In March 2006 the Internet Architecture Board (IAB) in its "Unwanted
Internet Traffic" workshop documented in <xref target="RFC4948">Report
from the IAB workship on Unwanted Traffic March 9-10, 2006</xref>
described an attack on core routing infrastructure as an ideal attack
with the most amount of damage. Four main steps were identified for that
tightening:</t>
<t><list style="numbers">
<t>Create secure mechanisms and practices for operating routers.</t>
<t>Clean up the Internet Routing Registry [IRR] repository, and
securing both the database and the access, so that it can be used
for routing verifications.</t>
<t>Create specifications for cryptographic validation of routing
message content.</t>
<t>Secure the routing protocols' packets on the wire.</t>
</list></t>
<t>This document looking at the last bullet performs the initial
analysis of the current state of BGP, LDP, PCEP and MSDP according to
the requirements of <xref target="RFC6518">KARP Design Guidelines
</xref>. This draft builds on several previous analysis efforts into
routing security. The OPSEC working group put together <xref
target="draft-ietf-opsec-routing-protocols-crypto-issues-07">Issues with
existing Cryptographic Protection Methods for Routing Protocols </xref>
an analysis of cryptographic issues with routing protocols and <xref
target="draft-ietf-karp-ospf-analysis-03">Analysis of OSPF Security
According to KARP Design Guide</xref>.</t>
<t>Section 2 looks at the current state of the four routing protocols.
Section 3 goes into what the optimal state would be for the three
routing protocols according to <xref target="RFC6518">KARP Design
Guidelines </xref> and Section 4 does a analysis of the gap between the
existing state and the optimal state of the protocols and suggest some
areas where we need to improve.</t>
<section title="Contributing Authors">
<t>Anantha Ramaiah, Mach Chen</t>
</section>
<section title="Abbreviations">
<t>BGP - Border Gateway Protocol</t>
<t>DoS - Denial of Service</t>
<t>KARP - Key and Authentication for Routing Protocols</t>
<t>KDF - Key Derivation Function</t>
<t>KEK - Key Encrypting Key</t>
<t>KMP - Key Management Protocol</t>
<t>LDP - Label Distribution Protocol</t>
<t>LSR - Label Switch Routers</t>
<t>MAC - Message Authentication Code</t>
<t>MKT - Master Key Tuple</t>
<t>MSDP - Multicast Source Distribution Protocol</t>
<t>MD5 - Message Digest algorithm 5</t>
<t>OSPF - OPen Shortest Path First</t>
<t>PCEP - Path Computation Element Protocol</t>
<t>TCP - Transmission Control Protocol</t>
<t>UDP - User Datagram Protocol</t>
</section>
</section>
<section title="Current State of BGP, LDP, PCEP and MSDP">
<t>This section looks at the underlying transport protocol and key
mechanisms built for the protocol. It describes the security mechanisms
built into BGP, LDP, PCEP and MSDP.</t>
<section title="Transport level">
<t>At a transport level, routing protocols are subject to a variety of
DoS attacks. Such attacks can cause the routing protocol to become
congested with the result that routing updates are supplied too slowly
to be useful or in extreme case prevent route convergence after a
change.</t>
<t>Routing protocols use several methods to protect themselves. Those
that run on TCP use access list to permit packets only from know
sources. These access lists also help edge routers from attacks
originating from outside the protected cloud. In addition for edge
routers running eBGP, TCP LISTEN is run only on interfaces on which
its peers have been discovered or that are configured to expect
sessions on.</t>
<t><xref target="RFC5082">GTSM</xref> describes a generalized Time to
Live (TTL) security mechanism to protect a protocol stack from
CPU-utilization based attacks.<xref target="RFC5961"> TCP
Robustness</xref> recommends some TCP level mitigations against
spoofing attacks targeted towards long lived routing protocol
sessions.</t>
<t>Even when BGP, LDP, PCEP and MSDP sessions use access list they are
subject to spoofing and man in the middle attacks. Authentication and
integrity checks allow the receiver of a routing protocol update 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.
Sometimes routers can be subjected to a large number of authentication
and integrity checks which can result in genuine requests failing.</t>
<t><xref target="RFC2385">TCP MD5</xref> specifies a mechanism to
protect BGP and other TCP based routing protocols via the TCP MD5
option. TCP MD5 option provides a way for carrying an MD5 digest in a
TCP segment. This digest acts like a signature for that segment,
incorporating information known only to the connection end points. The
MD5 key used to compute the digest is stored locally on the router.
This option is used by routing protocols to provide for session level
protection against the introduction of spoofed TCP segments into any
existing TCP streams, in particular TCP Reset segments. TCP MD5 does
not provide a generic mechanism to support key roll-over.</t>
<t>However, the Message Authentication Codes (MACs) used by MD5 to
compute the signature are considered to be too weak. <xref
target="RFC5925">TCP-AO </xref> and its companion document <xref
target="RFC5926">Crypto Algorithms for TCP-AO</xref> is a step towards
correcting both the MAC weakness and KMP. For MAC it specifies two MAC
algorithms that MUST be supported. They are HMAC-SHA-1-96 as specified
in <xref target="RFC2104">HMAC</xref> and AES-128-CMAC-96 as specified
in <xref target="NIST-SP800-38B">NIST-SP800-38B</xref>. Cryptographic
research suggests that both these MAC algorithms defined are fairly
secure and are not known to be broken in any ways. It also provides
for additional MACs to be added in the future.</t>
</section>
<section title="Keying mechanisms">
<t>For <xref target="RFC5925">TCP-AO</xref> there is no Key Management
Protocol (KMP) used to manage the keys that are used for generating
the Message Authentication Code (MAC). It allows for a master key to
be configured manually or for it to be managed from a out of band
mechanism. Most routers are configured with a static key that does not
change over the life of the session.</t>
<t>It should also be mentioned that those routers that have been
configured with static keys have not seen the key changed. The common
reason given for not changing the key is because it triggers a TCP
reset, and thus bounces links/adjacencies thus undermining Service
Level Agreements (SLAs). It is well known that longer the same key is
used, higher is the chance that it can be guessed, particularly if it
is not a strong key.</t>
<t>For point-to-point key management <xref target="RFC2409">IKE</xref>
tries to solve the issue of key exchange under a SA.</t>
</section>
<section title="LDP">
<t>Section 5 of <xref target="RFC5036">LDP</xref> states that LDP is
subject to three different types of attacks. These are spoofing,
protection of privacy of label distribution and denial of service
attacks.</t>
<section title="Spoofing attacks">
<t>Spoofing attack for LDP occur both during the discovery phase and
during the session communication phase.</t>
<section title="Discovery exchanges using UDP">
<t>Label Switching Routers (LSRs) indicate their willingness to
establish and maintain LDP sessions by periodically sending 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 one.</t>
<t>Unlike all other LDP messages, the Hello messages are sent
using UDP not TCP. This means that they cannot benefit from the
security mechanisms available with TCP. <xref
target="RFC5036">LDP</xref> does not provide any security
mechanisms for use with Hello messages except to note that some
configuration may help protect against bogus discovery events.</t>
<t>Spoofing a Hello packet for an existing adjacency can cause the
adjacency to time out and that can result in termination of the
associated session. This can occur when the spoofed Hello message
specifies a small Hold Time, causing the receiver to expect Hello
messages within this interval, while the true neighbor continues
sending Hello messages at the lower, previously agreed to,
frequency.</t>
<t>Spoofing a Hello packet can also cause the LDP session to be
terminated directly. This can occur when the spoofed Hello
specifies a different Transport Address from the previously agreed
one between neighbors. Spoofed Hello messages are observed and
reported as real problem in production networks.</t>
</section>
<section title="Session communication using TCP">
<t>LDP like other TCP based routing protocols specifies use of the
TCP MD5 Signature Option to provide for the authenticity and
integrity of session messages. As stated above, some assert that
MD5 authentication is now considered by some to be too weak for
this application. A stronger hashing algorithm e.g SHA1, could be
deployed to take care of the weakness.</t>
</section>
</section>
<section title="Privacy Issues">
<t>LDP provides no mechanism for protecting the privacy of label
distribution. The security requirements of label distribution are
similar to other routing protocols that need to distribute routing
information.</t>
</section>
<section title="Denial of Service Attacks">
<t>LDP is subject to Denial of Service (DoS) attacks both in its
discovery mode as well as during the session mode.</t>
<t>The discovery mode attack is similar to the spoofing attack
except that when the spoofed Hello messages are sent with a high
enough frequency can cause the adjacency to time out.</t>
</section>
</section>
<section title="PCEP">
<t>Attacks on <xref target="RFC5440">PCEP</xref> may result in damage
to active networks. This may include computation responses, which if
changed can cause protocols like LDP to setup sub-optimal or
inappropriate LSPs. In addition, PCE itself can be attacked by a
variety of DoS attacks. Such attacks can cause path computations to be
supplied too slowly to be of any value particularly as it relates to
recovery or establishment of LSPs.</t>
<t>As the RFC states, PCEP could be the target of the following
attacks.</t>
<t><list style="symbols">
<t>Spoofing (PCC or PCE implementation)</t>
<t>Snooping (message interception)</t>
<t>Falsification</t>
<t>Denial of Service</t>
</list>According to the RFC, inter-AS scenarios when PCE-to-PCE
communication is required, attacks may be particularly significant
with commercial as well as service-level implications.</t>
<t>Additionally, snooping of PCEP requests and responses may give an
attacker information about the operation of the network. Simply by
viewing the PCEP messages someone can determine the pattern of service
establishment in the network and can know where traffic is being
routed, thereby making the network susceptible to targeted attacks and
the data within specific LSPs vulnerable.</t>
<t>Ensuring PCEP communication privacy is of key importance,
especially 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 could obtain sensitive information related to computed paths
and resources.</t>
</section>
<section title="MSDP">
<t>Similar to BGP and LDP, <xref target="RFC2385">TCP MD5</xref>
specifies a mechanism to protect TCP sessions via the TCP MD5 option.
But with a weak MD5 authentication, TCP MD5 is considered too weak for
this application.</t>
<t>MSDP also advocates imposing a limit on number of source address
and group addresses (S,G) that can be stored within the protocol and
thereby mitigate state explosion due to any denial of service and
other attacks.</t>
</section>
</section>
<section title="Optimal State for BGP, LDP, PCEP, and MSDP">
<t>The ideal state for BGP, LDP and MSDP protocols are when they can
withstand any of the known types of attacks.</t>
<t>Additionally, Key Management Protocol (KMP) for the routing sessions
should help negotiate unique, pair wise random keys without
administrator involvement. It should also negotiate Security Association
(SA) parameter required for the session connection, including key life
times. It should keep track of those lifetimes and negotiate new keys
and parameters before they expire and do so without administrator
involvement. In the event of a breach, the keys should be changed
immediately.</t>
<t>The DoS attacks for BGP, LDP, PCEP and MSDP are attacks to the
transport protocol, TCP in this case. TCP should be able to withstand
any of DoS scenarios by dropping packets that are attack packets in a
way that does not impact legitimate packets.</t>
<t>The routing protocols should provide a mechanism to determine
authenticate and validate the routing information carried within the
payload.</t>
<section title="LDP">
<t>For the spoofing kind of attacks that LDP is vulnerable to during
the discovery phase, it should be able to determine the authenticity
of the neighbors sending the Hello message.</t>
<t>There is currently no requirement to protect the privacy of label
distribution as labels are carried in the clear like other routing
information.</t>
</section>
</section>
<section title="Gap Analysis for BGP, LDP, PCEP and MSDP">
<t>This section outlines the differences between the current state of
the routing protocol and the desired state as outlined in section 4.2 of
<xref target="RFC6518">KARP Design Guidelines </xref>. As that document
states, these routing protocols fall into the category of the one-to-one
peering messages and will use peer keying protocol. It covers issues
that are common to the four protocols leaving protocol specific issues
to sub-sections.</t>
<t>At a transport level the routing protocols are subject to some of the
same attacks that TCP applications are subject to. These include but are
not limited to DoS attacks. Recommendations to make the transport
protocol should be followed and implemented. An example of such a draft
is <xref target="RFC5961"> Improving TCP's Robustness to Blind In-Window
Attacks.</xref></t>
<t>From a security perspective there is a lack of comprehensive KMP. As
an example <xref target="RFC5925">TCP-AO</xref> talks about coordinating
keys derived from MKT between endpoints, but the MKT itself has to be
configured manually or through a out of band mechanism. Even when keys
are configured manually, a method for their rollover has not been
defined. This leads to keys not being updated regularly which in itself
increases the security risk. Also TCP-AO does not address the issue of
connectionless reset.</t>
<t>Authentication, tamper protection, and encryption all require the use
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 no
administration overhead. It has to cover automatic key rollover. 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 layer 2
header.</t>
<t>There are two methods of automatic key rollover. Implicit key
rollover can be initiated after certain volume of data gets exchanged 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 way
that the links/adjacencies are affected. On the other hand, 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 parameter
changes e.g. an attack has happened, or a system administrator with
access to the keys has left the company. An example of this is <xref
target="RFC2409">IKE</xref> but it could be any other new mechanisms
also.</t>
<t>As stated earlier <xref target="RFC5925">TCP-AO</xref> and its
accompanying document <xref target="RFC5926">Crypto Algorithms for
TCP-AO </xref> suggest that two MAC algorithms that MUST be supported
are HMAC-SHA-1-96 as specified in <xref target="RFC2104">HMAC</xref> and
AES-128-CMAC-96 as specified in <xref
target="NIST-SP800-38B">NIST-SP800-38B</xref>.</t>
<t>There is a need to protect authenticity and validity of the
routing/label information that is carried in the payload of the
sessions. However, we believe that is outside the scope of this document
at this time and is being addressed by SIDR WG. Similar mechanisms could
be used for intra-domain protocols.</t>
<section title="LDP">
<t>As described in <xref target="RFC5036">LDP</xref>, the threat of
spoofed Basic Hellos can be reduced by accepting Basic Hellos on
interfaces that LSRs trust, employing <xref
target="RFC5082">GTSM</xref> and ignoring Basic Hellos not addressed
to the "all routers on this subnet" multicast group. Spoofing attacks
via Extended Hellos are potentially a more serious threat. An LSR can
reduce the threat of spoofed Extended Hellos by filtering them and
accepting Hellos from sources permitted by an access list. However,
performing the filtering using access lists requires LSR resource, and
the LSR is still vulnerable to the IP source address spoofing.
Spoofing attacks can be solved by being able to authenticate the Hello
messages, and an LSR can be configured to only accept Hello messages
from specific peers when authentication is in use.</t>
<t><xref target="draft-zheng-mpls-ldp-hello-crypto-auth-01">LDP Hello
Cryptographic Authentication</xref> suggest a new Cryptographic
Authentication TLV that can be used as an authentication mechanism to
secure Hello messages.</t>
</section>
<section title="PCEP">
<t>PCE discovery according to its RFC is a significant feature for the
successful deployment of PCEP in large networks. This mechanism allows
a PCC to discover the existence of suitable PCEs within the network
without the necessity of configuration. It should be obvious that,
where PCEs are discovered and not configured, the PCC cannot 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 and a keying
mechanism, the need for which has been discussed above.</t>
</section>
</section>
<section title="Transition and Deployment Considerations">
<t>As stated in <xref target="RFC6518">KARP Design Guidelines</xref> it
is imperative that the new authentication and security mechanisms
defined support incremental deployment, as it is not feasible to deploy
the new routing protocol authentication mechansim overnight.</t>
<t>Typically authentication and security in a peer-to-peer protocol
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 fail.
Upon failure, the routing protocols can 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 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 period of time, so a manual coordiantion is not
required.</t>
<t>If the automatic KMP requires use of public/private keys to exchange
key material, the required CA root certificates may need to be installed
to verify authenticity of requests initiated by a peer. Such a step does
not require coordination with the peer except to agree on what CA
authority will be used.</t>
</section>
<section title="Security Requirements">
<t>This section describes requirements for BGP, LDP, PCEP and MSDP
security that should be met within the routing protocol.</t>
<t>As with all routing protocols, they need protection from both on-path
and off-path blind attacks. A better way to protect them would be with
per-packet protection using a cryptographic MAC. In order to provide for
the MAC, keys are needed.</t>
<t>Once keys are used, mechanisms are required to support key rollover.
This should cover both manual and automatic key rollover. Multiple
approaches could be used. However since the existing mechanisms provide
a protocol field to identify the key as well as management mechanisms to
introduce and retire new keys, focusing on the existing mechanism as a
starting point is prudent.</t>
<t>Finally, replay protection is required. The replay mechanism needs to
be sufficient to prevent an attacker from creating a denial of service
or disrupting the integrity of the routing protocol by replaying
packets. It is important that an attacker not be able to disrupt service
by capturing packets and waiting for replay state to be lost.</t>
</section>
<section title="Acknowledgements">
<t>We would like to thank Brian Weis for encouraging us to write this
draft and providing comments on it.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="draft-ietf-karp-threats-reqs">
<front>
<title>KARP Threats and Requirements</title>
<author fullname="Gregory M. Lebovitz" initials="G"
surname="Lebovitz">
<organization>Juniper Networks, Inc</organization>
</author>
<author fullname="Manav Bhatia" initials="M" surname="Bhatia">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date day="09" month="March" year="2012" />
</front>
</reference>
<?rfc include='reference.RFC.6518'?>
<?rfc include="reference.RFC.2385"?>
<?rfc include='reference.RFC.5926'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2104'
?>
<?rfc include='reference.RFC.2119'
?>
<?rfc include='reference.RFC.2409'?>
<?rfc include='reference.RFC.3547'?>
<?rfc include="reference.RFC.4271"
?>
<?rfc include='reference.RFC.4948'?>
<?rfc include="reference.RFC.5036"
?>
<?rfc include='reference.RFC.5082'?>
<?rfc include='reference.RFC.5440'?>
<?rfc include='reference.RFC.5925'?>
<?rfc include='reference.RFC.5961'?>
<reference anchor="draft-ietf-opsec-routing-protocols-crypto-issues-07">
<front>
<title>Issues with Existing Cryptographic Protection Methods for
Routing Protocols</title>
<author fullname="Manav Bhatia" initials="M" surname="Bhatia">
<organization>Alcatel-Lucent</organization>
</author>
<date day="31" month="October" year="2010" />
</front>
</reference>
<reference anchor="draft-ietf-karp-ospf-analysis-03">
<front>
<title>Analysis of OSPF Security According to KARP Design
Guide</title>
<author fullname="Sam Hartman" initials="S" surname="Hartman">
<organization></organization>
</author>
<date day="12" month="March" year="2012" />
</front>
</reference>
<reference anchor="NIST-SP800-38B">
<front>
<title>Recommendation for Block Cipher Modes of Operation: The CMAC
Mode for Authentication</title>
<author fullname="Morris Dworking" surname="Dworking">
<organization>National Institute of Standards and
Technology</organization>
</author>
<date month="May" year="2005" />
</front>
</reference>
<reference anchor="draft-zheng-mpls-ldp-hello-crypto-auth-01">
<front>
<title>LDP Hello Cryptographic Authentication</title>
<author fullname="Lianshu Zheng" surname="Zheng">
<organization>Huawei Technologies, Ltd</organization>
</author>
<date day="14" month="March" year="2011" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 23:09:01 |