Network Working Group G. Daley
Internet-Draft NetStar Networks
Intended status: Standards Track S. Delord
Expires: April 29, 2010 R. Key
Telstra
S. Krishnan
Ericsson
October 26, 2009
Guidelines for Multiprotocol Traffic Selector Bindings in IPsec
draft-daley-mpsec-traffic-sel-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 29, 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.
Daley, et al. Expires April 29, 2010 [Page 1]
Internet-Draft Multiprotocol Traffic Selector Guidelines October 2009
Abstract
In IPsec, secure connectivity is provided for network layer entities.
Traffic Selectors which specify interesting traffic for security
association encapsulation are identified only by network and
transport layer addressing.
This document discusses extending traffic selectors to allow more
generic definitions of interesting traffic.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Description and Models . . . . . . . . . . . . . . . . . . . . 3
3. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Policy Database Considerations . . . . . . . . . . . 6
6. IKEv2 Considerations . . . . . . . . . . . . . . . . . . . . . 6
6.1. Selector Format Considerations . . . . . . . . . . . . . . 7
7. IPsec Mode Considerations . . . . . . . . . . . . . . . . . . 7
8. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 7
9. Discussion of Initiator/Responder Mappings . . . . . . . . . . 8
10. External Interface Considerations . . . . . . . . . . . . . . 9
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. Security Considerations . . . . . . . . . . . . . . . . . . . 10
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
14.1. Normative References . . . . . . . . . . . . . . . . . . . 11
14.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Daley, et al. Expires April 29, 2010 [Page 2]
Internet-Draft Multiprotocol Traffic Selector Guidelines October 2009
1. Introduction
IPsec is focused on providing tunnel and transport security for
network layer IP traffic based on IP address and port selectors. In
some circumstances, endpoints may wish to provide IPsec services
based on other distinguishing information from the traffic stream
[RFC4301].
This document discusses models, motivations, for multiprotocol
bindings for IPsec Traffic Selectors, their use in the Security
Policy Database (SPD) and their description within IKEv2
[RFC4306][I-D.ietf-ipsecme-roadmap].
2. Description and Models
Devices which may prefer to choose extended traffic selector syntax
may support non-IP protocols for packet delivery or may have non-
Address and port information used in traffic selection for IP layer
traffic.
Example 1 MPLS Label
Where an MPLS label either arrives from an interface, or is used to
encapsulate traffic, it may be useful to transport data carried
within that label across the network.
At this stage, advice is sought on how encapsulation would occur, and
whether the communications path connecting A and B would make use of
an MPLS label inside the ESP label.
Similar to Diffserv in Example 1,the Traffic Class field of the MPLS
label stack entry [RFC5462] may be used for traffic selectors.
TS: Label A TS: Label B
+---------+ +---------+
A | | | | B
-------|< - - - >|------------------------------|< - - - >|-------
----> | |=============================>| | ---->
+---------+ ESP SA +---------+
Example 2 Ethernet Pseudo Wire
Daley, et al. Expires April 29, 2010 [Page 3]
Internet-Draft Multiprotocol Traffic Selector Guidelines October 2009
For systems which do not contain IP addresses on the traffic side
(rather than the carriage side), there is currently no way to specify
IPsec connectivity across to a remote device. This may be the case
with Pseudo-wires which have shared identifiers, that are known at
provisioning time.
Allowing data associated with a particular interface group to be
encapsulated in protocols such as ESP, would provide a mechanism to
deliver secured pseudo wires.
wire ID wire ID
+---------+ +---------+
| | | |
-------|< - - - >|------------------------------|< - - - >|-------
----> | |=============================>| | ---->
+---------+ ESP SA +---------+
Example 3 Security Classification Option
It is necessary under some security regimes to ensure that traffic of
specific security classifications are encrypted before transportation
over media of a lower protection value [DSDISMu]. Explicit marking
the classifications packets is provided by IPSO in IPv4 [RFC1108] and
CALIPSO in IPv6 [RFC5570].
SECRET Level-Max=SECRET Level-Max=SECRET SECRET
Network Level-Min=CONFIDENTIAL Level-Min=CONFIDENTIAL Network
+---------+ +---------+
| | | |
-------|< - - - >|------------------------------|< - - - >|-------
----> | |=============================>| | ---->
+---------+ ESP SA +---------+
RESTRICTED Network
Use of classification levels in traffic selectors
The figure above shows the interconnection of two SECRET classified
networks over a lower security medium, using a negotiated encrypted
tunnel. It shows transmission of data classified in a range between
CLASSIFIED and SECRET, as shown within the Classification Level field
of the IPSO basic security option [RFC1108].
Use of the explicit labelling may provide a natural control point for
Daley, et al. Expires April 29, 2010 [Page 4]
Internet-Draft Multiprotocol Traffic Selector Guidelines October 2009
the encapsulation of data onto IPSec tunnels, or in filtering packets
arriving from such a tunnel.
3. Related work
An Informational specification is available which shows how
Fiberchannel Addressing can be used for traffic selectors in
[RFC4595]. In Section 4.4, it defines TS_FC_ADDR_RANGE, which uses
ranges of Fiberchannel addresses where other previously defined
methods have used IP addresses.
RFC 4595 also specifies transport of ESP (and AH) frames over
Fiberchannel encapsulation. Within this document discussion of
carriage of IKEv2, ESP and AH over non IP or IP/UDP transport is out-
of-scope.
Descriptions of challenges and mechanisms for provisioning security
on Pseudo-wires are available in [PWESECREQ][PWESEC]. This document
takes a different approach to previous pseudo-wire security
mechanisms in that it attempts to provide a more general key
derivation mechanism for data other than pseudo-wires. Additionally,
this document doesn't seek to provide a non-IP carriage for ESP and
ESP-like frames, as is the case in [PWESEC].
Ways of identifying security classifications within IKEv2 exchanges
are described within [I-D.jml-ipsec-ikev2-security-context]. This
mechanism proposes a Security Context Transform, which could instead
be expressed within a Traffic-Selector type.
It is notable that there exist link-layer encryption mechanisms
available via IEEE LAN/MAN 802.1 Working Group [DOT1ae][DOT1XREV].
This work doesn't seek to supplant existing link-layer security
mechanisms, but does seek to allow for use of secured transports for
non-IP data such as link-layer frames when used within the IPsec
framework.
4. Applicability
This document aims at identifying practices for defining extended
traffic selectors. It also explores alternative encoding mechanisms
and their impact on policy expression in IKEv2.
This document does not define encapsulation of ESP or AH protocols
over any new protocols, and only defines/discusses what may be
encapsulated by them.
Daley, et al. Expires April 29, 2010 [Page 5]
Internet-Draft Multiprotocol Traffic Selector Guidelines October 2009
5. Security Policy Database Considerations
Security Policy Databases provide expressions of the encryption and
authentication policy on IPsec hosts and gateways. SPDs are
referenced as part of packet delivery processes in order to match
packets either to a constructed SA, or to the key-deriving system
(such as IKEv2), based on interesting traffic matches.
Databases therefore require an interface for packet processes when
transmitting data [USAGIXFRM], configuration interfaces through which
to construct policy [RFC4807][IPSECSPOL][SETKEY], and key derivation
interfaces to ensure that policy is expressed through to the remote
peer during the key exchange.
At this stage, specification of inter device communication operations
using IKEv2 is necessary if support for extended traffic selectors is
to be provided.
6. IKEv2 Considerations
As a departure from IKE [RFC2407], IKEv2 specifies traffic selectors
separate to identifiers [RFC4306], including for IPv4 and IPv6.
In order to provide more general mapping for traffic selectors to
non-IP sources and destinations, Traffic Selector Type (TS Type)
allocation needs to be made. The existing TS Type space is
administered by IANA. As of April 2009 there are 230 allocatable
values within the space.
Along with a selector type allocation the format within IKEv2 and
interpretation of each traffic selector require specification. This
either requires a specific Traffic Selector option format, or a
general format which can express additional classes of information.
If a more expressive format were to be used, the syntax of this
format could be used for the IPSO, MPLS Labels, or Pseudo-wire
interchangeably. An endpoint which could understand the format, but
could not support a particular selector could down select or reject
the proposal.
RFC4807 Specifies an SNMP MIB for IPsec Security Policies [RFC4807].
Within the specification is a mechanism to describe in ASN.1 encoding
for IP Address and DSCP based traffic selectors [RFC3289]. Were the
same encoding used for IKEv2 as the MIB, new object identifiers would
need to be added, but the format would be predetermined.
Another alternative is to use an XML Schema, although the mechanism
Daley, et al. Expires April 29, 2010 [Page 6]
Internet-Draft Multiprotocol Traffic Selector Guidelines October 2009
would have to be able to present a single canonical syntax for a
specific policy.
6.1. Selector Format Considerations
IKE Version 2 discusses security association rule ordering issues
which arise when one traffic selection expression overlaps with
another (selector correlation) [RFC4306]. The decorrelation
algorithm provides a means to identify non-overlapping subsets of the
selected traffic.
Key to being able to express decorrelated selectors is that all
fields which may be selected need to be expressed as ranges.
As such all selectable subfields within an MPLS Label would require
expression as start and end-range values. Similarly, locally
significant Pseudo-Wire Identifiers (PWids) make use of two integer
based values, a fixed length Group ID and fixed length Pseudo Wire
Identfier (PWid) [RFC4447].
Conversely encoded within the LDP formats for Generalized Pseudowire
Identifiers have varying length bitstrings with data encoded within
them. Similarly, IPSO and CALIPSO have bit fields which are a
structured data representation within fixed fields.
These systems are not able to express these values easily as a range,
which allows for easy decorrelation.
7. IPsec Mode Considerations
When constructing more elaborate traffic selectors for IKEv2, it is
expected that the tunnel mode will be provided for traffic which
doesn't travel within IP-layer packets.
Traffic selectors for data carried within IP packets may still be
carried in Transport Mode, for example if DSCPs are used for
selectors. This requires further investigation.
8. Backward Compatibility
One advantage of IPsec is that traffic descriptors for IPv4 and IPv6
are available across the majority of existing implementations.
Introduction of multiple subsets of Traffic Selectors which are
optional to implement may cause compatibility issues.
Security Policy Database entries for IPsec devices support IPv4 and
Daley, et al. Expires April 29, 2010 [Page 7]
Internet-Draft Multiprotocol Traffic Selector Guidelines October 2009
IPv6 traffic selectors. Traffic Selectors are either associated with
static Security Associations, or are defined in conjunction with
IKEv2 policy [RFC4301][RFC4306].
Where keying and SA configuration are static, it is possible that
traffic sent on an SA from a device supporting (and using) extended
Traffic Selectors will be rejected upon reception at the far end SA.
The reverse case (with legacy implementation ingress and general
traffic selector egress) would have equivalent function, with only
the intersection of the traffic selectors being allowed through to
the remote site.
Without an IKEv2 control channel this is not easily remedied.
Similar issues regarding persistent differences in configuration are
described in [RFC4306]. In the case that IKEv2 is used for key
negotiation, a system which supports only IPv4, IPv6 or Fiber Channel
Traffic Selectors will not be able to choose a traffic selector from
the extended mechanisms.
This may lead to Security Associations to fail completely, in
conformance to the IKEv2 protocol [RFC4306].
9. Discussion of Initiator/Responder Mappings
Existing traffic selectors are for connectionless source and
destinations. Assignment of multiple selectors to each of the
initiator and responder is appropriate for such traffic. For systems
which provide connection oriented point-to-point service, multiple
sources and destinations are inappropriate. In such a case, there
needs to be a one-to-one mapping between initiator and responder
traffic selectors.
Expressed in existing IKEv2 syntax, it is not possible to describe
within a single CHILD_SA Security Association Initiator and Responder
Traffic Selectors elements which are mutually exclusive.
For example, if:
TSi is the set [ 192.0.2.0/26, 192.0.2.128/26 ]
and TSr set is [ 192.0.2.64/26, 192.0.2.192/26 ]
It is not possible to express in a single CHILD_SA or IKEv2 which has
the properties that only:
Daley, et al. Expires April 29, 2010 [Page 8]
Internet-Draft Multiprotocol Traffic Selector Guidelines October 2009
192.0.2.0/26 ===> 192.0.2.128/26 (A)
and
192.0.2.64/26 ===> 192.0.2.192/26 (B)
while
192.0.2.0/26 =/=> 192.0.2.192/26
and
192.0.2.64/26 =/=> 192.0.2.128/26
In order to allow only a single source and destination mapping within
IKEv2's syntax, the only way to specify mappings (A) and (B) are via
two separate SAs. For point-to-point circuit oriented connections
such as pseudo-wires, given RFC 4306 IKEv2 syntax, would require an
SA per source, destination pair.
As described in Section 4.4.1.2 of RFC4301, the structure of SPDs
identified within that system allows for multiple Selector Sets which
may be included into a single security association. As discussed
within that document, in order to provision selector sets
dynamically, changes need to be made within IKEv2.
At this stage, provisioning one circuit per SA is described, although
it is worth identifying if selector sets are viable under revision of
the specification.
10. External Interface Considerations
Referral of packets to the security policy database is typically
undertaken as a forwarding (routing) process in existing networks
[RFC4301]. Defining Traffic Selectors with non-IP address components
means that a different non-forwarding process may be invoked to refer
to the SPD.
When the forwarding process accesses the SPD, there is a transform on
a received packet which determines whether the traffic is interesting
to send over IPsec. This will either invoke the IKEv2 key
negotiation process, or assign the data to a security association (as
described in Section 2.9 of RFC 4306 [RFC4306]).
For forwarding and processes referring to the modified Security
Policy Database, there needs to be a mechanism which allows the match
new Traffic Selector attributes. This match process would then be
used as above, to invoke IKEv2 or to assign data for transmission.
If individual mechanisms are defined through the process described
below, each Traffic Selector Definition will require specification
not only of the type, and its expression within IKEv2, but also the
Daley, et al. Expires April 29, 2010 [Page 9]
Internet-Draft Multiprotocol Traffic Selector Guidelines October 2009
filtering and operational processes required to achieve effective
traffic protection [RFC4306].
Depending on the mechanisms defined for expressing extended traffic
selectors, a general filtering mechanism may be defined which allows
new selection filters to be applied to the SPD, and exchanged over
IKEv2 using the Traffic Selector Payload [RFC2819]. The
expressibility of the Traffic Selectors must then be matched by the
filter mechanism, and map from the presented packet information to a
PROTECT operation [RFC4301].
Existing interfaces between the Security Policy Database and the key
management process make implicit assumptions that the Traffic
Selectors are IP addresses [RFC2367]. Modifications to such
mechanisms may need to occur before existing APIs may be used with
new traffic selectors.
11. IANA Considerations
No new formats or messages are defined in this document.
In order to allocate a new traffic selector class, it is necessary to
receive a traffic selector type allocation from IANA
[RFC4306][IANAIKEV2]. This requires Expert Review by an IANA
identified resource, who would be able to understand the use case,
and whether the allocation should occur.
12. Security Considerations
Definition of new traffic selectors for non-IP traffic isn't a
significant departure from IKEv2's security model. The identity
associated with the communications, and the source and destination of
the tunnel headers do not change. Only the traffic identified for
transport changes.
Where non-IP datagrams are exchanged over ESP or AH tunnels, the
behavior may be different to IP. When providing connectivity through
the IPsec tunnels for physical or link-layer technologies, the tunnel
itself may establish alternative paths in the wider topology.
Where the tunneled lower layer traffic expands on an existing
infrastructure, there is a chance of loop creation. Unless tunnel
endpoints deploy mechanisms to prevent loops, data transfer through
the tunnel could be used to trivially deny service to devices on the
tunnel path, and the networks at either end.
Daley, et al. Expires April 29, 2010 [Page 10]
Internet-Draft Multiprotocol Traffic Selector Guidelines October 2009
Where more complex filter patterns are expressible within the Traffic
Selector IKEv2 payload, they may require decoding by an external
parser. Where an external parser for a language such as ASN.1 or XML
is in use, there are additional interfaces to exploit, and a more
complex structure to keep state about. The cost of this additional
risk needs to be balanced against the value in expressing more
complex policy.
13. Acknowledgments
Thanks to Dave Thaler for his discussion of Traffic Selector tuples,
and to Tero Kivinen and Stephen Kent for their contributions on
expression of ranges in traffic selectors.
14. References
14.1. Normative References
[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.
[RFC4807] Baer, M., Charlet, R., Hardaker, W., Story, R., and C.
Wang, "IPsec Security Policy Database Configuration MIB",
RFC 4807, March 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.
14.2. Informative References
[IANAIKEV2]
IANA, "http://www.iana.org/assignments/ikev2-parameters".
[IPSECSPOL]
"http://developer.apple.com/documentation/Darwin/
Reference/Manpages/man3/ipsec_set_policy.3.html".
[SETKEY] "http://linux.die.net/man/8/setkey".
[USAGIXFRM]
Kanda, M., Miyazawa, K., and H. Esaki, "IPsec Security
Policy Database Configuration MIB, USAGI IPv6 IPsec
Daley, et al. Expires April 29, 2010 [Page 11]
Internet-Draft Multiprotocol Traffic Selector Guidelines October 2009
development for Linux. Applications and the Internet
Workshops, 2004. SAINT 2004 Workshops".
[DOT1ae] "http://standards.ieee.org/getieee802/download/
802.1AE-2006.pdf".
[DOT1XREV]
"http://www.ieee802.org/1/pages/802.1x-rev.html".
[DSDISMu] "Australian Government Information Security Manual (ISM)",
Infosec policy The Australian Government Information and
Communications Technology Security Manual, September 2009.
[I-D.ietf-ipsecme-roadmap]
Frankel, S. and S. Krishnan, "IP Security (IPsec) and
Internet Key Exchange (IKE) Document Roadmap",
draft-ietf-ipsecme-roadmap-01 (work in progress),
March 2009.
[I-D.jml-ipsec-ikev2-security-context]
Latten, J., Wilson, G., Hallyn, S., and T. Jaeger,
"Security Context Addendum to IPsec",
draft-jml-ipsec-ikev2-security-context-01 (work in
progress), July 2009.
[PWESEC] Stein, Y(J)., "Pseudowire Security (PWsec)",
draft-stein-pwe3-pwsec-00 (work in progress),
October 2006.
[PWESECREQ]
Stein, Y(J)., "Requirements for PW Security",
draft-stein-pwe3-sec-req-01 (work in progress),
February 2007.
[RFC1108] Kent, S., "U.S", RFC 1108, November 1991.
[RFC2819] Waldbusser, S., "Remote Network Monitoring Management
Information Base", STD 59, RFC 2819, May 2000.
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, July 1998.
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information
Base for the Differentiated Services Architecture",
RFC 3289, May 2002.
Daley, et al. Expires April 29, 2010 [Page 12]
Internet-Draft Multiprotocol Traffic Selector Guidelines October 2009
[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
Heron, "Pseudowire Setup and Maintenance Using the Label
Distribution Protocol (LDP)", RFC 4447, April 2006.
[RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel
Security Association Management Protocol", RFC 4595,
July 2006.
[RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common
Architecture Label IPv6 Security Option (CALIPSO)",
RFC 5570, July 2009.
Authors' Addresses
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
Simon Delord
Telstra
242 Exhibition St
Melbourne, VIC 3000
Australia
Email: simon.a.delord@team.telstra.com
Raymond Key
Telstra
242 Exhibition St
Melbourne, VIC 3000
Australia
Email: raymond.key@team.telstra.com
Daley, et al. Expires April 29, 2010 [Page 13]
Internet-Draft Multiprotocol Traffic Selector Guidelines October 2009
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com
Daley, et al. Expires April 29, 2010 [Page 14]