IPSP Working Group                                         A.  Keromytis
Internet Draft                                        U. of Pennsylvania
                                                           M. Richardson
                                                Sandelman Software Works
                                                              L. Sanchez
                                                                BBN/GTEI
                                                            October 1999
draft-keromytis-ipsp-arch-00.txt


                   IPsec Policy Discovery Architecture

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 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.


Abstract

   This document describes an IP Security Policy architecture that
   conforms to the requirements set forth in [IPSP-REQ].  The
   architecture defines the mechanisms and protocols needed for
   discovering, accessing, and processing security policy information
   of varying granularity.  The architecture accommodates topology and
   policy changes without need of manual reconfiguration of clients
   and security gateways.


1.  Introduction

   The Security Policy System (SPS) defines a distributed database of
   security policy information.  It provides the mechanisms needed for
   discovering, accessing, and processing security policy information
   of hosts, subnets, or networks.

   In the SPS architecture there are two types of systems, Policy
   Servers and Policy Clients.  Policy Servers provide a security
   policy repository that Policy Clients (end hosts and security
   gateways) may consult to determine what the security parameters for
   a particular communication should be.

   Policy Clients must be configured to know their Policy Server(s).
   This configuration may be manual or through some automated
   discovery mechanism.

   Policy Servers must be provided with the security policy for the
   systems it is responsible for.  How the policy is determined and
   stored in the Policy Server itself is outside the scope of this
   specification.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].

1.1  Terminology

   See [IPSP-REQ] for the terminology used throughout this document.


2.  Architecture Overview

   A host (H1) that wishes to communicate with a remote host (H2)
   first needs to decide what the end-to-end security parameters of
   that communication should be.  These may be stored or otherwise
   determined locally (e.g., an application required some specific
   form of traffic protection, through some OS-specific mechanism), or
   may be retrieved from its appointed Policy Server.  The Policy
   Server may also know exactly what SAs need to be negotiated, either
   because it was configured with that information or because it has
   cached the result of a previous lookup.

   If the Policy Server does not have such cached information, the
   host enters a discovery phase, wherein it tries to establish what
   security gateways lie in the path to the remote endpoint.  This is
   achieved through a special discovery message that is sent to the
   remote endpoint.

   A security gateway that intercepts this message consults with its
   Policy Server to determine what security parameters are required
   for the packets from H1 to H2.  The Policy Server may have cached
   information from previous runs of the discovery process, in which
   case it is returned to the security gateway (and from there, to the
   origin of the discovery process).  If not, the security gateway
   forwards the discovery message to H2, along with its security
   requirements for packets from H2 to H1 (the reverse path).  Each
   subsequent security gateway that intercepts this message repeats
   this step.  If at any point a Policy Server does have cached
   information relevant to this discovery process, it may provide it
   and cause the discovery process to end.

   Eventually, the discovery message reaches the Security Gateway
   "closest" to host H2, which consults its Policy Server.  If the
   Policy Server has not been configured to provide Security Policy
   information for host H2, the Security Gateway will forward the
   discovery message to host H2.  In that case, host H2 determines the
   security policy for the end-to-end communication (possibly by
   querying its Policy Server).  H2 then sends a message to that last
   security gateway, describing the security requirements for packets
   from H1 to H2.

   That security gateway adds to these requirements its own (that is,
   the requirements for packets from H1 to that security gateway).
   This step is repeated until H1 receives a message from its closest
   security gateway that contains the security requirements of all the
   security gateways along the path to H2, as well as H2's
   requirements.  At the end of this process, both H1 and H2 have a
   list of security requirements of all the security gateways along
   the path between them.  If H2 is not satisfied with these
   requirements, it may initiate a discovery process to H1 on its own.

   Furthermore, at each step where a host or security gateway receives
   policy information, it MAY forward such information to its Policy
   Server for caching, and it may cache the policy information
   locally.


3.  Security Gateway Discovery Protocol

   This section gives a brief overview of the Security Gateway
   Discovery Protocol.  A separate document will describe the protocol
   in more detail.

   The Security Gateway Discovery Protocol (SGDP) is implemented as a
   transport protocol over IP.

   The SGDP allows the initiator of the discovery process to determine
   the security policy of all Security Gateways between itself and the
   remote end-host, as well as the security policy of the end-host
   itself.  The origin end-host or Security Gateway would then
   establish the necessary SAs (or reuse existing SAs where
   applicable/feasible) with the Security Gateways and remote
   end-host, using some automated SA-negotiation protocol, such as IKE
   [RFC-2409] or Photuris [Photuris].

   The security policy information acquired through the discovery
   process includes parameters for the SAs that should be established
   with a particular SG or end-host, security credentials (e.g.,
   certificates) that should be used by the SA-negotiation protocol,
   as well as other (as yet undefined) information.

   To compensate for topology changes, the discovery process may be
   instructed to discard cached information, forcing a complete path
   traversal to occur.


4.  Security Policy Server Operation

   The following sections discuss the operational requirements of a
   Policy Server in the IPSP architecture.

4.1  Security Policy Server Query Protocol

   This section gives a brief overview of the Security Policy Server
   Query Protocol (SPSQP).  A separate document will describe the
   protocol in more detail.

   The SPSQP supports the following primitives:

   * Client registration (and de-registration).

   * Client download of their security policy.

   * Client download of cached security policy.

   * Client upload of their security policy.

   * Client upload of security policy found in a received SGDP
     Discovery Message for caching purposes.

   * Server push of (updated) security policy to registered clients.

   A Policy Server MUST verify the legitimacy of clients downloading
   or uploading security policy information.  Clients MUST verify the
   identity of the Policy Server.

   All communications over SPSQP MUST be secured.  IPsec MUST be used
   to secure all communications between Policy Servers and clients
   (end-hosts and Security Gateways), and verify the legitimacy of
   Policy Servers and clients.

4.2  Security Policy Caching

   A Policy Server, SG, or end-host MAY choose to cache policy (and
   policy-related, such as credentials) information acquired through
   the discovery process.  Policy information MUST have an indication
   as to what its cache lifetime is.  Policy Servers, SGs, and
   end-hosts that cache policy information MUST remove expired policy
   entries from their caches.

   Note that some policy objects MAY specify other types of expiration
   mechanisms (e.g., online validity checks).  There are two classes
   of such objects:

   * Policy information that is verified by SGs and end-hosts (e.g.,
     certificates and other types of credentials).  Policy Servers,
     SGs, and end-hosts MAY periodically verify the validity of such
     information in their caches.  Invalid entries MUST be discarded.

   * Policy information that is used-as is by SGs and end-hosts.
     Policy Servers, SGs, and end-hosts that cache such objects MUST
     periodically verify the validity of such information in their
     caches.  Invalid entries MUST be discarded.

4.3  Security Policy Decorrelation

   Security Policies MUST be decorrelated.  More text will be added in
   this section, explaining the necessity and mechanics of
   decorrelation.  A separate document will describe the decorrelation
   algorithm in more detail.

4.4  Policy Server Discovery

   An end-host or Security Gateway MUST be configured so that it can
   contact its Policy Server.  Such information may include network
   addresses, security credentials (for IPsec), etc.

   Some automated mechanism for discovering a Policy Server MAY be
   defined as part of this architecture.  It is not yet known what
   form this mechanism may take.

4.5  Where to Place a Policy Server

   A Policy Server may co-exist with a Security Gateway, an end-host,
   or may reside on a system by itself.

   More text is needed here, explaining the tradeoffs and issues
   involved with the different placements.


5.  End-host Requirements

   An end-host that complies with the IPSP architecture MUST be able
   to initiate a Security Gateway discovery process (see Section 3).
   If the end-host is expected to operate inside a Security Domain, it
   MUST implement the client side of the Security Policy Server Query
   Protocol (see Section 4.1).  Implementation of the server side of
   the SPSQ protocol is optional.


6.  Legacy End-hosts

   This section describes IPSP operation when either or both of the
   end-hosts (origin and/or destination end-hosts) are not IPSP-aware.

6.1  Legacy Origin End-host

   When an origin end-host operating inside a Security Domain does not
   implement the Security Gateway Discovery Protocol, coordination
   between Security Gateways and the end-host is not possible.

   A Security Gateway that intercepts a packet from such a host MAY
   initiate a Security Gateway discovery process, specifying that it
   will be proxying traffic for the end-host.  This will allow the
   Security Gateway to establish IPsec tunnels with other Security
   Gateways (and potentially the destination end-host itself) that
   protects the origin end-host's traffic.  The "reverse channel"
   policy added to the discovery packet assumes that the destination
   end-host implements SGDP (and can thus take advantage of this
   information).  If that is not true, a Security Gateway discovery
   process will have to be initiated in the reverse direction by the
   last Security Gateway (see section 6.2).

6.2  Legacy Destination End-host

   When a destination end-host does not implement the SGDP, it is the
   responsibility of the Policy Server of its Security Domain to
   specify the end-to-end security parameters (if any).  This means
   that a Policy Server MUST be aware of which hosts it is responsible
   for.

   The Policy Server responsible for a legacy destination end-host MAY
   initiate a Security Gateway discovery process in the reverse
   direction if the origin end-host does not implement SGDP (i.e., the
   discovery process was a proxy one).  However, some mechanism needs
   to be employed to avoid an endless loop of Security Gateway
   discovery.


7.  Legacy Security Gateways

   Legacy Security Gateways do not participate in the discovery
   process, since they do not implement the SGDP.  Such a system, upon
   receipt of a discovery packet may drop it (which will cause the
   discovery process to time-out), forward it with no further
   processing, or initiate an IPsec exchange with some remote host or
   Security Gateway, based on its local (non-IPSP-conforming) security
   policy.  In the latter two cases, no further action is required by
   any IPSP-compliant system, as the legacy Security Gateway is
   transparent to the discovery process.

   If the legacy Security Gateway drops the discovery packets and
   sends back an appropriate ICMP message, the recipient of such a
   message (another SG or the origin end-host) MAY establish the
   necessary IPsec SAs with the legacy SG to allow traffic to flow
   through the legacy SG.  The legitimacy of the ICMP message MUST be
   verified through cryptographic (or other) means.

   Alternatively, the Security Gateway or origin end-host MUST
   terminate the discovery process and notify the Policy Servers, SGs,
   and origin end-host involved in the discovery process.

   No solution as yet exists if the legacy Security Gateway silently
   discards packets.


8.  Security Considerations

   This section has not been completed.  It will be in future versions
   of this draft.


9.  IANA Considerations

   A new transport protocol number for the SGDP needs to be assigned
   by IANA.  No further actions by IANA are required (yet).


References:

   [RFC-2119]    Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", RFC-2119, March 1997.

   [RFC-2401]    S. Kent, R. Atkinson, RFC2401: "Security Architecture
                 for the Internet Protocol", November 1998.

   [IPSP-REQ]    M. Richardson, A. Keromytis, L. Sanchez,
                 draft-ietf-ipsp-requirements-00.txt: "IPsec Policy
                 Discovery Protocol Requirements", October 1999

   [RFC-2409]    Harkins, D., and D. Carrel, "The Internet Key Exchange
                 (IKE)", RFC 2409, November 1998. Authors' Address

   [Photuris]    Karn, P., and B. Simpson, Photuris: Session Key
                 Management Protocol, Work in Progress.


Authors' addresses:

   Angelos D. Keromytis
   Distributed Systems Lab
   CIS Department, University of Pennsylvania
   200 S. 33rd Street
   Philadelphia, Pennsylvania  19104-6389

   Telephone:   +1 215 573 3639
   Email:       angelos@dsl.cis.upenn.edu

   Michael C. Richardson
   Sandelman Software Works Corp.
   152 Rochester Street
   Ottawa, ON K1R 7M4
   Canada

   Telephone:   +1 613 276-6809
   Email:       mcr@sandelman.ottawa.on.ca

   Luis A. Sanchez
   BBN Technologies
   GTE Internetworking
   10 Moulton Street
   Cambridge, MA  02140
   USA

   Telephone: +1 (617) 873-3351
   Email:     lsanchez@bbn.com


Expiration and File Name

   This draft expires April 1, 2000

   Its file name is draft-keromytis-ipsp-arch-00.txt