One document matched: draft-daley-mpsec-secure-lsp-ps-01.txt
Differences from draft-daley-mpsec-secure-lsp-ps-00.txt
Network Working Group G. Daley
Internet-Draft NetStar Networks
Intended status: Standards Track October 20, 2009
Expires: April 23, 2010
Secured Label Switch Path Problem Statement
draft-daley-mpsec-secure-lsp-ps-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 23, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
Delivering cryptographic security over MPLS networks currently
requires insertion of extra IP Packet headers in the label stack.
Daley Expires April 23, 2010 [Page 1]
Internet-Draft Secured LSP Problem Statement October 2009
This document discusses encryption and authentication of datagrams by
carriage of Encapsulating Security Payload directly inside a label
header.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Comparable Technologies . . . . . . . . . . . . . . . . . . . . 3
4. Existing deployment models . . . . . . . . . . . . . . . . . . 4
5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Secure Label Switch Path Request . . . . . . . . . . . . . 6
5.2. IKEv2 Negotiation of Security Associations . . . . . . . . 6
5.3. Encapsulating packets at Provider Edge . . . . . . . . . . 7
5.4. Decapsulating packets at Provider Edge . . . . . . . . . . 7
5.5. Session Tear-Down . . . . . . . . . . . . . . . . . . . . . 7
6. IKEv2 Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Daley Expires April 23, 2010 [Page 2]
Internet-Draft Secured LSP Problem Statement October 2009
1. Introduction
VPNs implemented using MPLS gain the advantage of simplified
switching, and communication segregation, but do not typically gain
encryption and authentication. While procedures exist which define
encryption for sub-IP transport, these are not typically able to use
the standard key exchange protocols.
Issues which would impact specification of carriage and secured
encapsulation of data over MPLS networks are discussed in this
document.
2. Applicability
Use of IPSec based protocols for non-IP environments precludes use of
IP Authentication Header (AH) for protection of the data payload
[RFC4302]. This is because AH performs authenticity calculations
across an IP Pseudo Header containing the IP Source and Destination
addresses from the exterior IPv4 or IPv6 packet.
Authenticity operations for carriage in MPLS environments may be
performed instead by using the Encapsulating Security Payload, which
also allows payload encryption [RFC4303].
At this stage, while data plane communications are intended not to
require IP packet encapsulation, communications for initial key
exchange and peer-to-peer Label signalling may require IP addressing
in the control plane. Considerations for ssytems without IP
addressing on the control plane are out-of-scope for this document.
3. Comparable Technologies
Provision of secured transport at sub-IP layers has been specified
using IP or GRE for transport of MPLS Labels [RFC4023], but this
specification requires carriage of MPLS Labels over IP. To allow
Label switched transport and traffic engineering, this requires
insertion of IP and ESP or AH headers between the two stacked labels
[RFC3209].
802.1AE provides an encryption mechanism for Link-Layer
communications in IEEE LAN/MAN environments [DOT1AE]. The initial
specification does not contain key derivation mechanisms, although
these are being specified in revisions to the 802.1X specification
[DOT1XREV].
PWsec is a specification of security for pseudo-wires between
Daley Expires April 23, 2010 [Page 3]
Internet-Draft Secured LSP Problem Statement October 2009
attachment circuits, making use of modern encryption and
authentication algorithms, without specification of a key derivation
and algorithm extensible packet format [PWSEC][PWSECREQ].
In comparison with the above three technologies, the mechanism
discussed here aims to require no data plane IP Headers before the
carried payload. It also intends to make use of Internet Key
Exchange (IKEv2) rather than IEEE key derivation protocols, and uses
existing pseudo-wire transport secured over Encapsulating Security
Payload [RFC4448][RFC4303].
4. Existing deployment models
Several different security association models may be applicable,
depending on the MPLS VPN architecture. It remains to be determined
which of these should be supported, and which should be explicitly
signalled (for example with Route Descriptors for VRF aware
associations.
PE1 P PE2
Ingress Egress
+-----+--------+ | +--------+-----+
|VRF A| | | |VRF A|
CUST A | | | | | | | CUST A
-------| | | | | |-------
| | | | | | |
| | | | | |
+-----+ | | | +-----+
| /-Label555------------------------\ |
+-----+ / |========ESP=SA10=======| \ +-----+
| | / |--Label22--|--Label33--| \ | |
-------| |/ | | \| |-------
CUST B | | | | | | | CUST B
| | | | | |
|VRF B| | | | |VRF B|
+-----+--------+ +--------+-----+
Common Security Association
Using a common ESP Security association between PE pairs, a secured
LSP can be provided for all communications with the same Forwarding
Equivalence Class. By using IPSec traffic selectors that reflect
Label semantics, it is possible to provide VPN/VRF associated inner
label encapsulation for each customer over the same SA.
Daley Expires April 23, 2010 [Page 4]
Internet-Draft Secured LSP Problem Statement October 2009
PE1 P PE2
Ingress Egress
+-----+--------+ | +--------+-----+
|VRF A| | | |VRF A|
CUST A | | | | | | | CUST A
-------| | | | | |-------
| | | | | |
| | | | | | |
+-----+ | | +-----+
| | | | |
+-----+ | | +-----+
| | | | | | |
-------| |==ESP=SA9================================| |-------
CUST B | |--Label324-------------------------------| | CUST B
| | |--Label22--|--Label33--| | |
|VRF B| | | |VRF B|
+-----+--------+ | +--------+-----+
Label Tunnelled Security Association
As shown above, it is plausible to carry upper-layer datagrams over a
VRF associated LSP. This would potentially allow VRF to VRF
signalling as well, although this is not explicitly investigated.
PE1 P PE2
Ingress Egress
+-----+--------+ | +--------+-----+
|VRF A| | | |VRF A|
CUST A | | | | | | | CUST A
-------| | | | | |-------
| |=ESP=SA2=================================| |
| | |--Label22--|--Label33--| | |
+-----+ | | +-----+
| | | | |
+-----+ | | +-----+
| | | | | | |
-------| | | | | |-------
CUST B | |=ESP=SA5=================================| | CUST B
| | |--Label22--|--Label33--| | |
|VRF B| | | |VRF B|
+-----+--------+ | +--------+-----+
VRF Aware Security Associations
Daley Expires April 23, 2010 [Page 5]
Internet-Draft Secured LSP Problem Statement October 2009
With in a specific Label switched path, it may be necessary to
maintain a particular label mapping solely for encapsulating ESP
payloads. This would allow communications to be VRF aware,
presenting Traffic multiplexed based on its security parameters
index.
Similarly with previous scenarios, the ESP SA may itself encapsulate
MPLS Labels, or pseudo-wires [I-D.daley-mpsec-label-ts].
5. Operations
Five primary operations occur specific to life span of a secured LSP.
These are outlined below.
5.1. Secure Label Switch Path Request
In order to set up a secured Label switch path, it is necessary to
perform PE to PE signalling, which requests binding of an LSP to a
future security association.
It is expected that no Provider routers other than participating PE
routers will require knowledge of the secured LSP. As such, while a
VPN route may exist between PE devices, requests for secured LSP
signalling are performed using Targetted LDP signalling [RFC3036].
Where the Secured Label switch path is associated with a Virtual
Routing Function, this requires that the Tunnelled LSP is established
using a targetted LDP request with information elements representing
the tunnel Label.
For environments where no inner tunnel is constructed, and encryption
is required over the base label, the targetted LDP may specify an
implicit-NULL in label request signalling. This would have the
effect of running the IPSec packets directly over the exterior LSP.
This creates challenges for service multiplexing though, so a single
LSP would need to be dedicated to SA Multiplexing.
Finally, it may be valuable for the LDP session itself to be
protected using IPSec protocols.
5.2. IKEv2 Negotiation of Security Associations
Negotiation of the Security Association Parameters makes use of
IKEv2, and at this stage requires the implementation to be able to
infer from the Targetted LDP and IKE exchange, where Encapsulating
Security Payload packets should be encapsulated onto and decapsulated
from.
Daley Expires April 23, 2010 [Page 6]
Internet-Draft Secured LSP Problem Statement October 2009
5.3. Encapsulating packets at Provider Edge
Encapsulation of packets over a secured LSP at the Provider Edge
relies upon the correct construction of the Security Association Data
Base (SADB), and the ability to forward transported packet payloads
onto Tunnel pseudo interfaces or apply security transformations on
packets.
5.4. Decapsulating packets at Provider Edge
Decapsulation of packets at the provider edge requires the same
checks as is typical for an ESP SA. Upon decapsulation of the
contents at the provider edge, packet forwarding depends on the
function of the upper-layer protocol, as in any other MPLS operation.
Since it is not possible to strip the ESP encapsulation on the prior
hop though using penultimate hop popping, it may be necessary to
perform two operations, the decryption associated with the ESP header
removal, and the end forwarding instance's task.
5.5. Session Tear-Down
Unlike typical LDP operations, sending a Shutdown message is not
sufficient to remove a secured LSP, unless the LDP exchange itself
was protected via IPSec. Local tear-down procedures will affect the
IKE session though, which will identify that the session is
terminating via a DELETE Exchange.
6. IKEv2 Considerations
MPLS labels typically can contain one of many upper layer protocol
elements, including IPv4 or IPv6 headers, Further stacked labels, or
Pseudo-wires [RFC4798][I-D.daley-mpsec-label-ts]. It is envisioned
that in order to support secured versions of MPLS LSPs, IKEv2 traffic
selectors will have to be constructed for all of the above elements.
7. IANA Considerations
No IANA actions are currently described in thsi document.
8. Security Considerations
Identities based on IP Addressing are not necessarily valid when
applied in Sub-IP networks, such as MPLS. As such, identifiers of
the form ID_IPV4_ADDR, ID_IPV6_ADDR may not be consequently validated
Daley Expires April 23, 2010 [Page 7]
Internet-Draft Secured LSP Problem Statement October 2009
by out-of-band communications.
9. Acknowledgments
Thanks to Simon DeLord and Raymond Key for their contributions and
discussions on the concepts underlying this document.
10. References
10.1. Normative References
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and
B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, "Encapsulating
MPLS in IP or Generic Routing Encapsulation (GRE)",
RFC 4023, March 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, February 2009.
10.2. Informative References
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[IANAIKEV2]
IANA, "http://www.iana.org/assignments/ikev2-parameters".
Daley Expires April 23, 2010 [Page 8]
Internet-Draft Secured LSP Problem Statement October 2009
[DOT1AE] "http://standards.ieee.org/getieee802/download/
802.1AE-2006.pdf".
[DOT1XREV]
"http://www.ieee802.org/1/pages/802.1x-rev.html".
[PWSEC] Stein, Y(J)., "Pseudowire Security (PWsec)",
draft-stein-pwe3-pwsec-00 (work in progress),
October 2006.
[PWSECREQ]
Stein, Y(J)., "Requirements for PW Security",
draft-stein-pwe3-sec-req-01 (work in progress),
February 2007.
[I-D.daley-mpsec-label-ts]
Daley, G., "MPLS Label Traffic Selectors for Internet Key
Exchange Version 2", draft-daley-mpsec-label-ts-00.txt
(work in progress), October 2009.
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, April 2006.
[RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel
Security Association Management Protocol", RFC 4595,
July 2006.
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
"Connecting IPv6 Islands over IPv4 MPLS Using IPv6
Provider Edge Routers (6PE)", RFC 4798, February 2007.
Author's Address
Greg Daley
NetStar Australia Pty Ltd
Lvl 9/636 St Kilda Rd
Melbourne, Victoria 3004
Australia
Phone: +61 401 772 770
Email: gdaley@netstarnetworks.com
Daley Expires April 23, 2010 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 01:28:58 |