IPSec Working Group P. Srisuresh INTERNET-DRAFT Lucent Technologies Expire in August, 1999 L.A. Sanchez BBN Technologies February 1999 Policy Framework for IP Security Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract As policy based networking has become a common place across the Internet with the advent of IPsec, firewalls and other initiatives, it is important for peering end nodes to understand where and why packets enroute are black-holed. End-to-end networking mandates that end nodes be cognizant of the impact policies along various points on the network will have on their packets. The objective of this document is to lay out a framework of policy requirements for end nodes. While the framework is focussed on IPSec based policies, it may be applicable across a wider policy base. Srisuresh & Sanchez [Page 1] Internet Draft IP packet based Policy framework February 1999 1. Introduction and Overview IP packets are subject to a variety of policies enroute by intermediate systems. These systems are in general policy enforcement points. Some of the policies enforced are specific to local administration, and end-nodes do not need to be notified of them. However, there are others that impact packets and traffic flow, which end-nodes need to be aware of. Policy criteria discussed in this document is limited to packet direction and packet contents, including IP and transport headers. Policy actions considered are assumed to be limited to packet transformation and packet flow. In particular, the document does not address application specific policies that are end-to-end transparent. In addition, the document assumes that packets cross administrative boundaries. For a single administrative domain, it may be reasonable to assume a proprietary solution, where a central policy management station could control policies for all the enforcement points within the domain and end-nodes may be able to query such a central management station to find policies enforced within the domain. By default, when no packet based policies are applied, an IP packet is expected to remain unchanged and delivered to the target node, as identified by the destination address in IP header. Typically, end-nodes can identify a possible route taken by packets destined to an address by running "traceroute" for the destination address. Default Packet traversal route is unchanged by the protocol of the packet. Historically, packet traversal has been determined solely by the destination address in the IP header and sometimes by optional extensions (such as source route option) to the header. Packets may be dropped randomly by intermediate nodes due to traffic congestion or other resource constraints, not directly tied to packet specifics. With the advent of packet-filters and security gateways, deviations from this behavior are likely to occur due to the enforcement of specific policies at various nodes during packet traversal. This document will (a) illustrate applications where packet based policies enroute can cause deviations to default traffic processing, and (b) identify requirements for both intermediate and end nodes in understanding policy based routing. The objective of the document is to provide a framework of reference for those contemplating solutions in this area. 1.1 Terms and Technical Definitions 1.1.1 Requirements Terminology Srisuresh & Sanchez [Page 2] Internet Draft IP packet based Policy framework February 1999 Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [Ref 1]. 1.1.2 Technical Definitions Security Gateway A security gateway refers to an intermediate system that implements IPSec protocols. For example, a router or a firewall implementing IPSec is a security gateway. Security Domain A set of communicating entities and resources that share a common security policy enforced at one or more enforcement agents or at an individual host. The definition of security domain applies to networks protected by security gateways as well as to single hosts, since a host may be the enforcer of its own policies. Security domains could exist inside other security domains. 2. Impact of policies enroute We will consider the following diagram to illustrate some of the undesirable effects of policy enforcement (without knowledge to end-nodes), as packets traverse through such enforcement devices. Specifically we will discuss the impact of firewalls (packet-filters/bastion hosts) and security gateways. In the context of this document a security gateway is an intermidiate system implementing IPSec. An application on Host-A that needed to communicate with Host-B, in a different administrative domain would typically cross a minimum of two policy enforcement devices - one local to the administrative domain and another local to the peer node's administrative domain. The policy enforcement devices enroute could be firewalls, security gateways or a node enforcing some other policy initiative (such as QOS) or a combination of these. Figure 1 below depicts a plausible scenario to illustrate policy enforcement by intermediate systems on end-to-end communications. Figure 1 is meant to be an example and does not cover the various configurations in which administrative domains may be connected to each other. In practice, there may be multiple policy enforcement devices within or outside an administrative domain. However, the diagram does provide the necessary base to address policy specific issues. Srisuresh & Sanchez [Page 3] Internet Draft IP packet based Policy framework February 1999 ________________ ( ) +--+ ( Administrative ) |__|------( Boundary - B ) /____\ ( ) Host-B (________________) | +--------------------+ | Policy-Enforcement | | Device - GW-B | +--------------------+ __________ | ( ) | +-----------------+ ( ) +-----------------+ | Border Router-A |--( Internet )--| Border Router-B | +-----------------+ ( ) +-----------------+ | (__________) | +--------------------+ | Policy-Enforcement | | Device - GW-A | +--------------------+ | ---------------- ( ) +--+ ( Administrative ) |__|------( Boundary - A ) /____\ ( ) Host-A (________________) Figure 1: Policy Enforcement Devices within administrative domains A security gateway operating in tunnel mode may encrypt and/or authenticate a packet and forward it through a tunnel destined to peer security gateway. The peer gateway in turn, de-tunnels the IP packet from the tunnel and reverse-transforms it to extract the original packet. It then forwards it to the destination, as specified in the original packet. [Ref 8] A packet is subject to IPsec tunneling only as it matches the secure packet selection policies for the gateway. The tunnel peers must ensure that only packets that meet the mutually agreed upon policies for the tunnel are transmitted over the tunnel. These packet selection policies may be set manually by the administrators on either end or may be exchanged using Internet key Enchange (IKE) protocol in the ID payload of Quick mode ([Ref 11], [Ref 12]). Srisuresh & Sanchez [Page 4] Internet Draft IP packet based Policy framework February 1999 When a packet is selected for secure tunneling, the routing path of the packet is altered to traverse through the peer gateway node. Note, however, this is not to suggest that IPsec policies alter the routing protocols. Below are some of the pitfalls applications may be subject to as a result of Security Gateway policy enforcement. 1. If the peering Security Gateways do not have matching policies, packets could be tunneled by the local Gateway device and yet, dropped by the peering device. The offended Gateway device may optionally issue an ICMP-Reject packet to the packet originator. Typically, if this happens during session establishment period, the end-node may choose not to pursue the application. However, many a times, the gateway nodes do not send a notification, and the applications are left to using timeouts to drop a session. It is important for the end-node to know if a packet is dropped due to enforcement of a policy or due to congestion and random drop. In the former case, it is fruitless to retry. However, if the application were to be aware of the policy that failed the session it could potentially pursue alternate approaches. 2. Even as peering gateways have matching policies and the associated SAs, there could be security breaches when the policies have overlap and the order is different on the peering gateways. Ex: In Figure 1, GW-A could have 2 policies, with associated SAs as follows: 1. Enforce 3DES for all TCP packets between GW-A and GW-B 2. Authenticate HTTP packets between GW-A and GW-B GW-B could have the same policies in reverse, as follows: 1. Authenticate HTTP packets between GW-A and GW-B 2. Enforce 3DES for all TCP packets between GW-A and GW-B You will notice that GW-A will use 3DES to send HTTP packets, whereas GW-B would simply authenticate the HTTP packets. This could be a potential cause for security breeches. 3. Even when the policies on the peering gateway nodes match exactly, there is no guarantee that Packets are secured using the same policy in both directions. Policies at an IPSec Gateway device will determine the route a packet would take on the way Srisuresh & Sanchez [Page 5] Internet Draft IP packet based Policy framework February 1999 out. But, there is no guarantee that the response packet would follow the same route in reverse. In particular, there is no guarantee that the response packet would traverse the same peer gateway device in the return path. This could result in security breaches. e.g., a packet may traverse securely in one direction and the response might come back in the clear in the opposite direction. 4. An application comprised of a session bundle may work only partially. For example, A security Gateway cannot create an SA (one or more) to support FTP-only sessions(i.e., FTP control and data sessions), unless your policy is to preserve all of TCP. Here is why. You could have a policy that preserves FTP control session by selecting src or Dest TCP port to be 21. But, the data session parameters set by, say PASV response, will decide the port number used by the ensuing data session. Only the end-nodes know the data session port numbers. Dynamically selected ports in a session cannot not be known to the security gateways, unless they have application specific knowledge to examine the payload, or applications notify them of the sessions specific to themselves. 3. Policy requirements In this section, we try to assess the requirements of end nodes with regard to policies that impact the packets originated from or directed to such a node. It is assumed that communication is not limited to a single administrative boundary and could span multiple boundaries. It is hoped that the requirements outlined here will provide a guideline to the various solutions that attempt to address Policy transparency to applications. The solution proposed must not require changes, additions or modifications to the algorithms or the IPsec protocols that use it. The solution may optionally be independent of any particular key management or key exchange protocol. 3.1. A flexible, Vendor-independent representation of Policies. As we move to the realm of end-to-end communication, we need to ascertain that end nodes are capable of learning the policies applied to their packets, as they traverse a network, spanning multiple administrative boundaries. Such a policy description must be vendor neutral, so the peering IPsec nodes can understand and enforce the policies on either end (tunnel or transport mode) for a security Association. Srisuresh & Sanchez [Page 6] Internet Draft IP packet based Policy framework February 1999 A Policy must be flexible and should not be constrained to the form of a single rule per SA. A policy should be able to accomodate a variety of rules, allowing for specification of a range of addresses, transport ports, protocols and other paramaters, while also permitting selective exclusion. 3.2. Provide a mechanism for policy discovery End nodes must be able to query and find out the policies their packets will be subjected to. A mechanism that can fulfill such a requirement would be beneficial. A protocol may be devised for client nodes to query and discover policies relevant to the application. A traceroute-like facility for identifying the routers enroute and policies applied for secure traversal of a packet would also be useful. The deficiency with the existing traceroute program is that Traceroute is ICMP based and assumes that routing is based purely on the destination IP address. It doesnt take into account policy-based networking. In a policy-based environment, packets could traverse different routes, using different tunnels, based on packet protocol and session characteristics. 3.3. Provide a mechanism for Policy Exchange and Query information The principal focus of IKE is to securely exchange session keys dynamically. However, there exists a need for peering security gateway nodes to exchange policies and for end nodes and intermediate nodes alike to make queries of policy specific information. 3.4. Provide Policy Negotiation When IPsec peers exchange policy information using IKE. It is mandatory that the peering nodes agree upon the values of a set of selectors for transmitting packets over any security association. Also, there may be several SA proposals within an SA payload allowing hosts to select a mutually agreeable set of parameters to protect the communication. However, it is not reasonable to assume that the peering nodes will have exactly matching policies on either end. Hence, it is a requirement for the peering nodes to carve out intersections of policies exchanged between both parties. Such a methodology would ensure that peering nodes can agree upon a common set of policies, which they could in turn enforce strictly on either end. 3.5. Provide Policy resolution Srisuresh & Sanchez [Page 7] Internet Draft IP packet based Policy framework February 1999 In some cases hosts and security gateways may agree upon the set of selectors describing the communication but not on the set of SA parameters required to protect such communication. Consider the case where a host insists on using ESP in transport mode with DES to reach a final destination while its security gateway explicitly prohibits this. The security gateway may have such policy because it does not allow forwarding of encrypted traffic into its domain. In this case it could be possible that the host may want to establish a security association with its gateway and allow its gateway to establish a security association with the intended final destination on behalf of the host. With such policy is available at the security gateway, the host may choose to agree to implement this rather than not communicating at all with the final destination. 3.6. Provide Dynamic Policy Updates(Add/Delete) to Enforcement Points. For IPsec, the end nodes should be able to influence policies associated with an IPsec SA dynamically. This is independent of whether the SA was between the peers directly or between 2 gateway nodes in between. An end node should be able to add/delete policies dynamically from an SA. Without this, application specific policies are hard to enforce on an SA. Ex: For an FTP SA, the end nodes ought to be able to (a) add/delete newer policies (describing the parameters of ensuing FTP data sessions) to the existing FTP control session SA, or (b) create newer SAs dynamically confirming to dynamically generated policy parameters. 3.7. Provide Policy bundling for SA bundles. A policy bundling mechanism by which a single policy may be associated with multiple SAs is required for SA bundles. Ex: Say, you have 2 policies on GW1: 1. Authenticate HTTP packets between GW1 and GW2 2. Enforce 3DES for all TCP packets between GW1 and GW3. The above association between policy and security Action may be restated as follows, upon policy Sequencing. The ESP SA may or may not be shared, based on the selector specified in rule 2. 1. For HTTP packets - Authenticate between GW1 and GW2 - Apply 3DES between GW1 and GW3. Srisuresh & Sanchez [Page 8] Internet Draft IP packet based Policy framework February 1999 2. For non-HTTP, TCP packets - Apply 3DES between GW1 and GW3. So, GW1 is able to apply SA bundles on outgoing HTTP packets. Upon return, the inbound HTTP are subject to detunneling on 2 SAs, but a single policy verification. 3.8. Provide Error notification to end nodes failing policies. When a packet is dropped at any node across the network due to enforcement of a certain policy, it would be beneficial for the application to know the policy that caused the packets to drop. Standardization of reject notification for such a purpose is desirable. Such a message should not only contain the packet that failed a policy, but also the policy and the ID of the policy enforcement device. 4. Security Considerations The document provides a framework for applications to identify the relevant policies in place across the network. Policies must be communicated in a secure way so as not to jeopardize the ability of the application to run. It is also important to ensure that the policies that are communicated statically or dynamically to the Policy Enforcement device are doen so, securely. Not doing so could compromise the security of the entire network. REFERENCES [1] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", RFC2119, March 1997. [2] R. Braden, "Requirements for Internet Hosts -- Communication Layers", RFC 1122 [3] R. Braden, "Requirements for Internet Hosts -- Application and Support", RFC 1123 [4] F. Baker, "Requirements for IP Version 4 Routers", RFC 1812 [5] "TRANSMISSION CONTROL PROTOCOL (TCP) SPECIFICATION", RFC 793 [6] J. Postel, "INTERNET CONTROL MESSAGE PROTOCOL SPECIFICATION", RFC 792 [7] J. Postel, "User Datagram Protocol (UDP)", RFC 768 Srisuresh & Sanchez [Page 9] Internet Draft IP packet based Policy framework February 1999 [8] S. Kent, R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401. [9] S. Kent, R. Atkinson, "IP Authentication Header", RFC 2402 [10] S. Kent, R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406. [11] D. Piper, "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407. [12] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409. Authors' Addresses Pyda Srisuresh Lucent technologies 4464 Willow Road Pleasanton, CA 94588-8519 U.S.A. Voice: (925) 737-2153 Fax: (925) 737-2110 EMail: suresh@ra.lucent.com Luis A. Sanchez BBN Technologies GTE Internetworking 10 Moulton Street Cambridge, MA 02140 Voice: (617) 873-3351 EMail: lsanchez@bbn.com Srisuresh & Sanchez [Page 10]