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
<draft-ietf-ipsec-policy-framework-00.txt>
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]