Network Working Group G. Daley
Internet-Draft NetStar Networks
Intended status: Standards Track October 19, 2009
Expires: April 22, 2010
MPLS Label Traffic Selectors for Internet Key Exchange Version 2
draft-daley-mpsec-label-ts-00.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 22, 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
Existing mechanisms for encapsulating MPLS labels in ESP or AH
payloads lack the ability to specify which Labels are to be
transported.
Daley Expires April 22, 2010 [Page 1]
Internet-Draft IKEv2 Label Traffic Selectors October 2009
This document provides new traffic selector format for IKEv2 in which
MPLS label fields and parameters can be selected.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Traffic Selector Format . . . . . . . . . . . . . . . . . . . . 3
3. Security Policy Database Considerations . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Daley Expires April 22, 2010 [Page 2]
Internet-Draft IKEv2 Label Traffic Selectors October 2009
1. Introduction
Carrying MPLS Label payloads in IPsec requires a mapping between the
ingress interface and Label carriage which is typically determined by
a label distribution protocol. While this is the case, it is
important to specify the label to IPSec Security Association mappings
especially where data encapsulated by one label requires different
protection to that encapsulated by another.
One IETF Standards Track RFC currently specifies carriage of MPLS
Labels in ESP or AH payloads [RFC4023]. The specification for
"Encapsulating MPLS in IP or GRE" [RFC4023] identifies that labels
are to be carried in Transport Mode by specifiying the source and
destination addresses as well as the protocol field being set to 137
with IKEv1 or IKEv2 [RFC2409][RFC4306]. It does not specify which
labels receive protection by an SA.
At this stage, additional specification of label header fields is not
feasible with IKEv1, but IKEv2 allows specification of new traffic
selector types. This document specifies a new format for traffic
selectors in IKEv2, to be used in conjunction with existing uses of
MPLS and IPSec.
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 RFC 2119 [RFC2119].
2. Traffic Selector Format
In order to allow for efficient expression of decorrelated selectors,
each element from the MPLS Label are expressed in the traffic
selector as ranges [RFC3032][RFC5462].
Each of these values parameters may be expressed as a single value, a
range, or the symbolic values ANY or OPAQUE, as specified in
[RFC4301].
The traffic selector format follows the IKE version 2 specification,
and is presented below:
Daley Expires April 22, 2010 [Page 3]
Internet-Draft IKEv2 Label Traffic Selectors October 2009
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Type | Reserved | Selector Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Label |St TC|S| Start TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| End Label |EndTC|T| End TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Label Traffic Selector
The TS Type for this traffic selector is TBD. The Selector Length is
12. TS Type specific fields are detailed below.
Start Label, End Label: The selected Label range is specified by the
Start and End Label fields.
Size : 20 bits
MINIMUM: 0
MAXIMUM: 1048575
ANY : Start Label=0, End Label=1048575
OPAQUE : Start Label=1048575, End Label=0
St TC, EndTC: The selected Quality of Service Traffic class is
specified by the St TC (Start Traffic Class) and EndTC (End
Traffic Class) fields.
Size : 3 bits
MINIMUM: 0
MAXIMUM: 7
ANY : St TC=0, EndTC=7
OPAQUE : St TC=7, End TC=0
S, T: The selected Top of Stack identified is specified by the 'S'
(Start Top of Stack) and 'T' (End Top of Stack) fields.
Daley Expires April 22, 2010 [Page 4]
Internet-Draft IKEv2 Label Traffic Selectors October 2009
Size : 1 bit
MINIMUM: 0
MAXIMUM: 1
ANY : S=0, T=1
OPAQUE : S=1, T=0
Start TTL, End TTL: The selected Time-To-Live values for the next
MPLS Label are specifies in the Start TTL and End TTL fields.
Size : 8 bits
MINIMUM: 0
MAXIMUM: 255
ANY : Start TTL=0, End TTL=255
OPAQUE : Start TTL=255, End TTL=0
Behaviour of the ANY and OPAQUE Values as specified here operate as
specified in [RFC4301]. When specifying a traffic selector, all sub
fields (except Reserved) must be specifically set. For fields where
the value doesn't matter, the pair of fields should be set to specify
ANY.
Where a packet is to be transmitted or recived upon an SA derived
from traffic selection using this TS Type, the encapsulated Label's
fields MUST match the accepted policy as specified in the IKEv2
negotiation. Packets which do not match specification MUST be
discarded in accordance with [RFC4301].
Where multiple fields (for example Label Value and Traffic Class),
are set as specified ranges, the recipient MUST check that both
constraints are met by incoming labels.
3. Security Policy Database Considerations
In order to express the Label which is required for protection, it
may be necessary to augment Security Policy Database elements. This
would allow initiation of negotiation of an SA upon reception of an
interesting packet, or upon reception of a Label signalling message
that specified a label matching the policy.
Daley Expires April 22, 2010 [Page 5]
Internet-Draft IKEv2 Label Traffic Selectors October 2009
4. IANA Considerations
This document describes a new traffic selector payload for IKEv2 and
its use.
Traffic selectors are defined by IANA Expert Review. This document
will be submitted for expert review and selector allocation upon a
subsequent draft submission.
Until submission implementations should use one of the Private Use
selectors. The suggested value is 250. Please note that
implementations would have to update to a new value when allocated
under IANA.
5. Security Considerations
The traffic selector format defined in this document omits the source
and destination IP addresses, which are used within ingress packet
checks within IPSec. This is less expressive than in traditional
IPSec.
This is probably acceptable for the following reasons:
o Source and Destination IP addresses may be inferred from the Key
Exchange conversation itself.
o Label exchanges are typically performed by another protocol which
itself presents the endpoint IP addresses.
As previously described [RFC4023], external MPLS Label exchange
mechanisms MUST use authentication mechanisms. For targetted Label
Distribution Protocol, it is suggested that SAs are established using
IKE to protect the LDP signalling (on TCP and UDP port 646)
[RFC5036].
6. Acknowledgments
Simon De Lord and Raymond Key contributed to the development of the
Traffic Selection problem statement which motivated this
specification. Thanks to Tero Kivinen who provided initial input on
the format of the field ranges.
7. References
Daley Expires April 22, 2010 [Page 6]
Internet-Draft IKEv2 Label Traffic Selectors October 2009
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, 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.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching
(MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic
Class" Field", RFC 5462, February 2009.
7.2. Informative References
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
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 22, 2010 [Page 7]