Analysis of RSVP-TE Security According to KARP Design Guide
draft-mahesh-karp-rsvp-te-analysis-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Mahesh Jethanandani , Dacheng Zhang | ||
| Last updated | 2012-12-16 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mahesh-karp-rsvp-te-analysis-00
Routing Working Group M. Jethanandani
Internet-Draft Ciena Corporation
Intended status: Informational D. Zhang
Expires: June 19, 2013 Huawei Technologies co., LTD.
December 16, 2012
Analysis of RSVP-TE Security According to KARP Design Guide
draft-mahesh-karp-rsvp-te-analysis-00.txt
Abstract
This document analyzes RSVP-TE according to guidelines set forth in
section 4.2 of KARP Design Guidelines [RFC6518].
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 June 19, 2013.
Copyright Notice
Copyright (c) 2012 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 & Zhang Expires June 19, 2013 [Page 1]
Internet-Draft RSVP-TE Analysis December 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
2. Current Security State of RSVP-TE . . . . . . . . . . . . . . 5
3. Gap Analysis for RSVP-TE . . . . . . . . . . . . . . . . . . . 7
4. IANA Requirements . . . . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Jethanandani & Zhang Expires June 19, 2013 [Page 2]
Internet-Draft RSVP-TE Analysis December 2012
1. Introduction
In March 2006, the Internet Architecture Board (IAB) described an
attack on core routing infrastructure as an ideal attack that would
inflict the greatest amount of damage, in their Report from the IAB
workshop on Unwanted Traffic March 9-10, 2006 [RFC4948], and suggests
steps to tighten the infrastructure against the attack.
This document performs the initial analysis of the current state of
RSVP-TE according to the requirements of KARP Design Guidelines
[RFC6518]. This draft builds on several previous analysis efforts
into routing security. The OPSEC working group put together Issues
with existing Cryptographic Protection Methods for Routing Protocols
[RFC6039] an analysis of cryptographic issues with routing protocols
and Analysis of BGP, LDP, PCEP, and MSDP Issues According to KARP
Design Guide [draft-ietf-karp-routing-tcp-analysis] which is a
analysis of the four routing protocols.
Section 2 looks at the current security state of RSVP-TE. Section 3
does a analysis of the gap between the existing and the optimal
security state of the protocol and suggest some areas where we need
to improve.
1.1. Abbreviations
BGP - Border Gateway Protocol
DoS - Denial of Service
KARP - Key and Authentication for Routing Protocols
KDF - Key Derivation Function
KEK - Key Encrypting Key
KMP - Key Management Protocol
LDP - Label Distribution Protocol
LSP - Label Switch Path
MAC - Message Authentication Code
MKT - Master Key Tuple
MPLS - Multi Protocol Label Switching
MSDP - Multicast Source Distribution Protocol
Jethanandani & Zhang Expires June 19, 2013 [Page 3]
Internet-Draft RSVP-TE Analysis December 2012
MD5 - Message Digest algorithm 5
PCEP - Path Computation Element Protocol
RSVP - Resource reSerVation Protocol
TCP - Transmission Control Protocol
UDP - User Datagram Protocol
Jethanandani & Zhang Expires June 19, 2013 [Page 4]
Internet-Draft RSVP-TE Analysis December 2012
2. Current Security State of RSVP-TE
This section looks at RSVP-TE and the underlying transport protocol
and key mechanisms built for the protocol.
RSVP-TE is an extension of the RSVP protocol for traffic engineering.
It supports the reservation of resources across IP networks and is
used for establishing Multi Protocol Label Switching (MPLS) Label
Switch Paths (LSPs). RSVP-TE signaling is used to establish both
intra- and inter-domain TE LSPs. It is RSVP Cryptographic
Authentication [RFC2747] that describes the format and use of RSVP's
INTEGRITY objects to provide hop-by-hop integrity and authentication
of RSVP messages. RSVP-TE which uses some of the same formats
therefore can make use of some of the same authentication mechanisms.
The rest of the document will therefore focus on current state of
security for RSVP. Currently, there is no security approach
specified for RSVP-TE particularly. However, the security mechanisms
for RSVP RSVP Cryptographic Authentication [RFC2747] can be taken
advantage of to provide the security protection for the RSVP-TE
message transportation.
There is a requirement that RSVP-TE headers and payload be
authenticated. There is no requirement that they be encrypted and
that work is outside the scope of KARP WG. RSVP Cryptographic
Authentication [RFC2747] outlines the use HMAC-MD5. When using HMAC-
MD5, the length of the keyed digests is 128 bits. In these cases
RSVP checksum can be disabled in lieu of message digest.
RSVP uses 64 bit monotonically increasing sequence numbers to prevent
against replay attacks. The sequence number space is large enough to
guarantee that a sequence number will never reach its maximum and
roll back within a reasonable long period.
To address the issue of out-of-order message delivery, the solution
allows administrators to specify a sequence number window
corresponding to the worst case reordering behavior. Instead of
requiring the sequence number of an incoming packet to be strictly
larger than the ones previously received, a packet will be accepted
if its sequence number is within the window. The solution provides
three approaches to generate unique monotonically increasing sequence
numbers across a failure or a restart. The solutions include:
1. Maintaining sequence numbers in stable memory
2. Introducing the data from a local time clock into the generation
of sequence numbers after a restart
Jethanandani & Zhang Expires June 19, 2013 [Page 5]
Internet-Draft RSVP-TE Analysis December 2012
3. Introducing the timing information from a Network Recovered Clock
into the generation of sequence numbers after a restart.
In addition, a handshake is defined for a receiver to get the latest
value of a sequence number. Therefore, this solution is effective in
addressing the issues caused by the rollback of sequence numbers
across a system restart or failure. However, when a router uses the
approach to generating sequence numbers with the time information
from NTP, an attacker may try to deceive the router to generate a
sequence number which is less than the sequence numbers it used to
have, by sending replayed or foiled NTP information.
The protocol states that manual keying should be supported and states
the need for a key management protocol to distribute keys. It even
states that the Key Identifier be the hook between RSVP and the key
management protocol. But it deliberately excludes defining a
integrated key management protocol technique in the draft. However,
it does define a key lifetime that should be recorded for all systems
using values such as KeyStartValid and KeyEndValid. It even advises
that the keys should be changed on a regular basis and that multiple
keys should be used to transition from one key to another.
RSVP does not explicitly mention Denial of Service (DoS) attacks and
how to prevent against it. However, RSVP-TE does know the peers that
it should be communicating with and can therefore accept packets from
known hosts only.
Jethanandani & Zhang Expires June 19, 2013 [Page 6]
Internet-Draft RSVP-TE Analysis December 2012
3. Gap Analysis for RSVP-TE
This section outlines the differences between the current state of
RSVP-TE and the desired state as outlined in sections 4.1 and 4.2 of
KARP Design Guidelines [RFC6518].
In RSVP Cryptographic Authentication [RFC2747], only the usage of MD5
to generate digests for RSVP-TE messages is mentioned. In order to
fulfill the requirement of supporting strong algorithms, at least the
support of SHA-2 needs to be provided.
In addition, in RSVP Cryptographic Authentication [RFC2747], three
approaches to generating unique monotonically increasing sequence
numbers across a failure and restart are introduced, but no approach
is mandated. However, as mentioned above, when using Network
Recovered Clocks into the generation of sequence numbers, the
capability of RSVP-TE in tolerating inter-connection replay attacks
will largely rely on the security of network timing protocols.
Therefore, in future this approach should not be recommended.
Jethanandani & Zhang Expires June 19, 2013 [Page 7]
Internet-Draft RSVP-TE Analysis December 2012
4. IANA Requirements
None
Jethanandani & Zhang Expires June 19, 2013 [Page 8]
Internet-Draft RSVP-TE Analysis December 2012
5. Acknowledgements
Jethanandani & Zhang Expires June 19, 2013 [Page 9]
Internet-Draft RSVP-TE Analysis December 2012
6. References
6.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.
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", RFC 6518,
February 2012.
6.2. Informative References
[I-D.ietf-karp-threats-reqs]
Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Overview, Threats, and
Requirements", draft-ietf-karp-threats-reqs-06 (work in
progress), September 2012.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
Group Domain of Interpretation", RFC 3547, July 2003.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the
IAB workshop on Unwanted Traffic March 9-10, 2006",
RFC 4948, August 2007.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
Jethanandani & Zhang Expires June 19, 2013 [Page 10]
Internet-Draft RSVP-TE Analysis December 2012
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C.
Pignataro, "The Generalized TTL Security Mechanism
(GTSM)", RFC 5082, October 2007.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961,
August 2010.
[RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues
with Existing Cryptographic Protection Methods for Routing
Protocols", RFC 6039, October 2010.
[draft-ietf-karp-routing-tcp-analysis]
Jethanandani, MJ., "Analysis of BGP, LDP, PCEP, MSDP
Issues According to KARP Design Guide", July 2012.
Jethanandani & Zhang Expires June 19, 2013 [Page 11]
Internet-Draft RSVP-TE Analysis December 2012
Authors' Addresses
Mahesh Jethanandani
Ciena Corporation
1741 Technology Drive
San Jose, CA 95110
USA
Phone: +1 (408) 436-3313
Email: mjethanandani@gmail.com
Dacheng Zhang
Huawei Technologies co., LTD.
Beijing,
China
Phone:
Fax:
Email: zhangdacheng@huawei.com
URI:
Jethanandani & Zhang Expires June 19, 2013 [Page 12]