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]