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]