One document matched: draft-daley-mpsec-traffic-sel-ps-00.txt
Network Working Group G. Daley
Internet-Draft NetStar Networks
Intended status: Standards Track S. Delord
Expires: January 4, 2010 R. Key
Telstra
S. Krishnan
Ericsson
July 3, 2009
Multiprotocol Traffic Selector Bindings for IPsec
draft-daley-mpsec-traffic-sel-ps-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 January 4, 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 January 4, 2010 [Page 1]
Internet-Draft Multiprotocol Traffic Selectors July 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 extends 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
7. IPsec Mode Considerations . . . . . . . . . . . . . . . . . . 7
8. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 7
9. Discussion of Initiator/Responder Mappings . . . . . . . . . . 8
10. External Interface Considerations . . . . . . . . . . . . . . 9
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
12. Security Considerations . . . . . . . . . . . . . . . . . . . 10
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
14.1. Normative References . . . . . . . . . . . . . . . . . . 10
14.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Daley, et al. Expires January 4, 2010 [Page 2]
Internet-Draft Multiprotocol Traffic Selectors July 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 Diffserv
Packets Classified using Diffserv may lose packets and reorder data
based on their traffic classification. Where different queuing
mechanisms are available for different Diffserv Codepoints (DSCPs),
anti-replay issues may arise for packets which are reordered within
an SA. This is described in Section 4.1 of [RFC4301].
A mechanism which defines an SA for each of the path's queues would
assist in this. For a system with three different queues, dividing
the traffic into three separate SAs may avoid this impact, as
displayed below:
TS: DSCP:46=>SA1 TS: DSCP:46=>SA1
DSCP:30-35=>SA2 DSCP:30-35=>SA2
DSCP:*=>SA3 DSCP:*=>SA3
+---------+ +---------+
| 46| |46 |
| /-->|------------------------------|<--\ |
| / |=============================>| \ |
| /30-35| ESP SA1 |30-35\ |
-------|< - - - >|------------------------------|> - - - >|-------
----> | \ |=============================>| / | ---->
| \ | ESP SA2 | / |
| \-->|------------------------------|<--/ |
| * |=============================>| * |
Daley, et al. Expires January 4, 2010 [Page 3]
Internet-Draft Multiprotocol Traffic Selectors July 2009
+---------+ ESP SA3 +---------+
Packet loss or delay of any packet in a queue will not cause out of
order reception in any of the Security Associations. This allows
packets which would have been discarded due to anti-replay windows to
pass through to applications.
Example 2 Ethernet Pseudo Wire
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 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
-------|< - - - >|------------------------------|< - - - >|-------
----> | |=============================>| | ---->
Daley, et al. Expires January 4, 2010 [Page 4]
Internet-Draft Multiprotocol Traffic Selectors July 2009
+---------+ ESP SA +---------+
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].
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 developing/exploring a canonical and extensible
format which can be used by IKEv2 peers to define interesting
traffic, and a means to define traffic match patterns for Security
Policy Databases beyond the existing IP based means.
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 January 4, 2010 [Page 5]
Internet-Draft Multiprotocol Traffic Selectors July 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 DSCP, 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 January 4, 2010 [Page 6]
Internet-Draft Multiprotocol Traffic Selectors July 2009
would have to be able to present a single canonical syntax for a
specific policy.
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
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].
Daley, et al. Expires January 4, 2010 [Page 7]
Internet-Draft Multiprotocol Traffic Selectors July 2009
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:
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.
Daley, et al. Expires January 4, 2010 [Page 8]
Internet-Draft Multiprotocol Traffic Selectors July 2009
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
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
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.
Daley, et al. Expires January 4, 2010 [Page 9]
Internet-Draft Multiprotocol Traffic Selectors July 2009
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.
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
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
Daley, et al. Expires January 4, 2010 [Page 10]
Internet-Draft Multiprotocol Traffic Selectors July 2009
(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
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".
[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.
[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.
[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
Daley, et al. Expires January 4, 2010 [Page 11]
Internet-Draft Multiprotocol Traffic Selectors July 2009
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.
[RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel
Security Association Management Protocol", RFC 4595,
July 2006.
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 January 4, 2010 [Page 12]
Internet-Draft Multiprotocol Traffic Selectors July 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 January 4, 2010 [Page 13]
| PAFTECH AB 2003-2026 | 2026-04-24 01:32:18 |