[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

Routing Working Group                                    M. Jethanandani
Internet-Draft                                                  K. Patel
Intended status: Informational                        Cisco Systems, Inc
Expires: August 29, 2011                                        L. Zheng
                                                                  Huawei
                                                       February 25, 2011


 Analysis of BGP, LDP and MSDP Security According to KARP Design Guide
               draft-mahesh-bgp-ldp-msdp-analysis-00.txt

Abstract

   This document analyzes BGP, LDP and MSDP according to guidelines set
   forth in section 4.2 of [draft-ietf-karp-design-guide].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 29, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Jethanandani, et al.     Expires August 29, 2011                [Page 1]


Internet-Draft         BGP, LDP and MSDP Analysis          February 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Contributing Authors . . . . . . . . . . . . . . . . . . .  3
     1.2.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Current State of BGP, LDP and MSDP . . . . . . . . . . . . . .  4
     2.1.  LDP  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
       2.1.1.  Spoofing attacks . . . . . . . . . . . . . . . . . . .  5
       2.1.2.  Privacy Issues . . . . . . . . . . . . . . . . . . . .  5
       2.1.3.  Denial of Service Attacks  . . . . . . . . . . . . . .  6
     2.2.  MSDP . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Optimal State for BGP, LDP and MSDP  . . . . . . . . . . . . .  7
     3.1.  LDP  . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.  Gap Analysis for BGP, LDP and MSDP . . . . . . . . . . . . . .  8
     4.1.  LDP  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Security Requirements  . . . . . . . . . . . . . . . . . . . . 10
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13






























Jethanandani, et al.     Expires August 29, 2011                [Page 2]


Internet-Draft         BGP, LDP and MSDP Analysis          February 2011


1.  Introduction

   In March 2006 the Internet Architecture Board (IAB) in its "Unwanted
   Internet Traffic" workshop described an attack on core routing
   infrastructure as an ideal attack with the most amount of damage.  It
   called for the tightening the security of the core routing
   infrastructure.

   This document performs the initial analysis of the current state of
   BGP, LDP and MSDP according to the requirements of
   [draft-ietf-karp-design-guide].  This draft builds on several
   previous analysis efforts into routing security.  The OPSEC working
   group put together [draft-ietf-opsec-routing-protocols-crypto-issues]
   an analysis of cryptographic issues with routing protocols and
   draft-hartman-ospf-analysis-01 which has a analysis for OSPF.

1.1.  Contributing Authors

   Anantha Ramaiah, Mach Chen

1.2.  Abbreviations

   BGP - Border Gateway Protocol

   DoS - Denial of Service

   KARP - Key and Authentication for Routing Protocols

   KDF - Key Derivation Function

   KMP - Key Management Protocol

   LDP - Label Distribution Protocol

   LSR - Label Switch Routers

   MAC - Message Authentication Code

   MSDP - Multicast Source Distribution Protocol

   MD5 - Message Digest algorithm 5

   OSPF - OPen Shortest Path First

   TCP - Tranmission Control Protocol

   UDP - User Datagram Protocol




Jethanandani, et al.     Expires August 29, 2011                [Page 3]


Internet-Draft         BGP, LDP and MSDP Analysis          February 2011


2.  Current State of BGP, LDP and MSDP

   This section describes the security mechanisms built into BGP, LDP
   and MSDP or in the underlying transport protocol.

   GTSM [RFC3682] describes a generalized Time to Live (TTL) security
   mechanism to protect a protocol stack from CPU-utilization based
   attacks.  In addition, most vendors have their TCP based routing
   protocols do a access list check to permit packets only from known
   sources.  These help preventing DoS attacks from unknown sources.

   TCP Robustness [RFC5961] recommends some TCP level mitigations
   against spoofing attacks targeted towards long lived routing protocol
   sessions.

   Session mode DoS attacks for LDP are the same attacks that TCP is
   vulnerable to such as SYN attacks.  [To be updated]

   TCP MD5 [RFC2385] specifies a mechanism to protect BGP and other TCP
   sessions 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.  MD5 does not provide a generic
   mechanism to support Key roll-over.  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.

   However, the Message Authentication Codes (MACs) used by MD5 to
   compute the signature are considered to be too weak.  TCP-AO
   [RFC5926] specifies a mechamism to protect BGP sessions and its data
   integrity using cryptographic authentication.  In order to accomplish
   this funtion, it defines two MAC algorithms.  It also defines two Key
   Derivation Functions (KDFs) used to create the traffic keys used by
   the newly defined and any future specified MACs.  Cryptographic
   research suggests that both these MAC algorithms defined are fairly
   secured and are not known to be broken in any ways.

   In addition, there is no Key Management Protocol (KMP) used to manage
   the keys that are used for generating the Message Authentication Code
   (MAC).  Most routers are configured with a static key that does not
   change over the life of the session.

2.1.  LDP

   Section 5 of LDP [RFC5036] states that LDP is subject to three
   different types of attacks.  It talks about spoofing, protection of



Jethanandani, et al.     Expires August 29, 2011                [Page 4]


Internet-Draft         BGP, LDP and MSDP Analysis          February 2011


   privacy of label distribution and denial of service attacks.

2.1.1.  Spoofing attacks

   Spoofing attack occur both during the discover phase and during the
   session communication phase.

2.1.1.1.  Discovery exchanges using UDP

   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.

   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.  LDP [RFC5036] does not provide any
   security mechanisms for use with Hello messages except to note that
   some configuration may help protect against bogus discovery events.

   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.

   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.

2.1.1.2.  Session communication using TCP

   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.

2.1.2.  Privacy Issues

   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



Jethanandani, et al.     Expires August 29, 2011                [Page 5]


Internet-Draft         BGP, LDP and MSDP Analysis          February 2011


   information.

2.1.3.  Denial of Service Attacks

   LDP is subject to Denial of Service (DoS) attacks both in its
   discovery mode as well as during the session mode.

   The discovery mode attack is similar to the spoofing attack except
   that when the spoofed Hello messages are sent with a high enough
   frequency, they can cause the adjacency to time out.

2.2.  MSDP

   Similar to BGP and LDP, TCP MD5 [RFC2385] 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.

   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.






























Jethanandani, et al.     Expires August 29, 2011                [Page 6]


Internet-Draft         BGP, LDP and MSDP Analysis          February 2011


3.  Optimal State for BGP, LDP and MSDP

   The ideal state for BGP, LDP and MSDP protocols are when they can
   withstand any of the known types of attacks.

   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.

   The DoS attacks for BGP, LDP 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.

   The routing protocols should provide a mechanism to authenticate and
   validate the routing information carried within the payload.

3.1.  LDP

   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.

   There is currently no requirement to protect the privacy of label
   distribution as labels are carried in the clear like other routing
   information.




















Jethanandani, et al.     Expires August 29, 2011                [Page 7]


Internet-Draft         BGP, LDP and MSDP Analysis          February 2011


4.  Gap Analysis for BGP, LDP and MSDP

   This section outlines the differences between the current state of
   the routing protocol and the desired state as outlined in section 4.2
   of [draft-ietf-karp-design-guide].  It covers issues that are common
   to the three protocols leaving protocol specific issues to sub-
   sections.

   The session layer that runs on TCP needs to protect itself by running
   TCP LISTEN only on interfaces on which its peers have been discovered
   or that are configured to expect sessions on.  Also the use of access
   list can help protect the edge routers from attacks originating from
   outside the protected cloud.

   Inspite of this BGP, LDP and MDSP sessions are subject to spoofing
   and man in the middle attacks.  While the MD5 option helps somewhat,
   without a KMP and a stronger MAC, these sessions are still vulnerable
   to attacks.

   TCP-AO [RFC5926]is a step towards correcting both the MAC weakness
   and KMP.  For MAC it specifies two MAC algorithms that MUST be
   supported.  Additional MACs can be added in the future.  They are
   HMAC-SHA-1-96 as specified in HMAC [RFC2104] and AES-128-CMAC-96 as
   specified in [NIST-SP800-38B].  For KMP it requires that a Key
   Derivation Function (KDF) MUST be supported.  They are KDF_HMAC-SHA1
   and KDF_AES_128_CMAC.  But this does not address the question of
   connectionless reset.

   [Need to add details about key rollover for manual keys and strategy
   for automatic keys here]

   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.

4.1.  LDP

   As described in LDP [RFC5036], the threat of spoofed Basic Hellos can
   be reduced by accepting Basic Hellos on interfaces that LSRs trust,
   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



Jethanandani, et al.     Expires August 29, 2011                [Page 8]


Internet-Draft         BGP, LDP and MSDP Analysis          February 2011


   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.
















































Jethanandani, et al.     Expires August 29, 2011                [Page 9]


Internet-Draft         BGP, LDP and MSDP Analysis          February 2011


5.  Security Requirements

   This section describes requirements for BGP, LDP and MSFP security
   that should be met within the routing protocol.

   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.

   Mechanisms are required in order 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.

   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.






























Jethanandani, et al.     Expires August 29, 2011               [Page 10]


Internet-Draft         BGP, LDP and MSDP Analysis          February 2011


6.  Acknowledgements


















































Jethanandani, et al.     Expires August 29, 2011               [Page 11]


Internet-Draft         BGP, LDP and MSDP Analysis          February 2011


7.  References

7.1.  Normative References

   [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
              Signature Option", RFC 2385, August 1998.

   [RFC5926]  Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms
              for the TCP Authentication Option (TCP-AO)", RFC 5926,
              June 2010.

   [draft-ietf-karp-design-guide]
              Lebovitz, G., "KARP Desgin Guidelines", September 2010.

7.2.  Informative References

   [NIST-SP800-38B]
              Dworking, "Recommendation for Block Cipher Modes of
              Operation: The CMAC Mode for Authentication", May 2005.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

   [RFC3682]  Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
              Security Mechanism (GTSM)", RFC 3682, February 2004.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

   [RFC5961]  Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
              Robustness to Blind In-Window Attacks", RFC 5961,
              August 2010.

   [draft-ietf-opsec-routing-protocols-crypto-issues]
              Manral, "Issues with existing Cryptographic Protection
              Methods for Routing Protocols", September 2010.











Jethanandani, et al.     Expires August 29, 2011               [Page 12]


Internet-Draft         BGP, LDP and MSDP Analysis          February 2011


Authors' Addresses

   Mahesh Jethanandani
   Cisco Systems, Inc
   170 Tasman Drive
   San Jose, CA  95134
   USA

   Phone: +1 (408) 527-8230
   Email: mahesh@cisco.com


   Keyur Patel
   Cisco Systems, Inc
   170 Tasman Drive
   San Jose, CA  95134
   USA

   Phone: +1 (408) 526-7183
   Email: keyupate@cisco.com


   Lianshu Zheng
   Huawei
   No. 3 Xinxi Road
   Beijing,   100085
   China

   Phone: +86 (10) 82882008
   Fax:
   Email: verozheng@huawei.com
   URI:



















Jethanandani, et al.     Expires August 29, 2011               [Page 13]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/