<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>

<rfc ipr="full2026" docName="draft-ietf-ipsp-requirements-XX.txt">

<front>
  <area>Security</area>
  <workgroup>IPsec Security Policy</workgroup>
  <title abbrev="ipspdiscoveryrequirements">
    IPsec Policy Discovery Protocol requirements
  </title>

  <author initials="M." surname="Richardson" fullname="Michael C. Richardson">
    <organization abbrev="SSW">Sandelman Software Works</organization>
    <address>
      <postal>   
        <street>470 Dawson Avenue</street>
        <city>Ottawa</city>
        <region>ON</region>
        <code>K1Z 5V7</code>
        <country>CA</country>
      </postal>
      <email>mcr@sandelman.ottawa.on.ca</email>
      <uri>http://www.sandelman.ottawa.on.ca/</uri>
    </address>
  </author>

  <author initials="L.A." surname="Sanchez"
          fullname="Luis A. Sanchez">
    <organization abbrev="Megisto">Megisto</organization>
    <address>
      <postal>   
        <city></city>
        <region>Puerto Rico</region>
        <country>USA</country>
      </postal>
      <email>lsanchez@megisto.com</email>
    </address>
  </author>

  <author initials="A.D." surname="Keromytis"
          fullname="Angelos D. Keromytis">
    <organization abbrev="Columbia">Columbia University</organization>
    <address>
      <postal>   
        <city>New York City</city>
        <region>NY</region>
        <country>USA</country>
      </postal>
      <email>angelos@keromytis.org</email>
    </address>
  </author>

  <date month="December" year="2001"></date>
</front>

<abstract>
  <t>
  This document describes the problem and solution requirements for
  an IPsec Policy Discovery protocol.
  </t>
</abstract>

<middle>

<section title="Introduction">

<section title="Definition of terminology">

<t>
Network security technologies are quickly being deployed over the
Internet these days; in particular, two categories enjoy widespread
usage:

<section title="security enforcement agents">
<t>
   Security gateways (commonly known as firewalls) are being installed
   along the perimeter of private internets to enforce access control
   and protect confidentiality of network traffic; these upper-layer
   gateways along with traditional link encryptors make up a scattered
   and uncoordinated set of security enforcement agents attempting to
   protect the Internet traffic.
</t>
</section>

<section title="secure communication protocols">
<t>
   Cryptographic algorithms are being incorporated into secure
   communication protocols such as IPSec, SSL and SOCKS in order to
   support strong data integrity, authentication, and confidentiality
   services.
</t>
</section>
</t>

<t>
On one hand, these technologies provide the much needed security
protection over the open Internet; on the other hand, they create a
complex management task that beg for scalable solutions.
</t>

<t>
The deployment of security gateways divides the Internet into
heterogeneous regions upholding different security policies, and the use
of different cryptographic mechanisms at multiple protocol layers
creates the need for negotiating the security mechanism and the key
parameters. As a result, in order to support a secure communication-
between two or more end-points, all the end-points and the security
enforcement agents on the communication's route must work together to
determine the suite of security services that can satisfy the security
policies, and negotiate a common set of security mechanisms to implement
these security services. While the negotiation of security mechanisms
and key parameters may be supported by key management protocols such as
ISAKMP [RFC-2408], a general and efficient process for managing the
security policies and deducing the security services for this
multi-party multi-layer security enforcement strategy is still
unavailable.
</t>

<t>
A IPsec Policy Discovery Protocol (IPDP) must provide the
essential infrastructure and the protocols necessary for conducting
this process. An IPDP must provide
IPSec with the scalability and management needed to become fully
deployable in operational environments.
</t>

</section>
</section>

<section title="Problem Description">

<t>
The security management problem can be restated in the form of the
following four questions:

<list>
<t> How does one manage the process of creating and modifying security
policies so as to maintain their mutual consistency?</t>

<t> How does one deduce the security requirements of an inter-domain
communication based on the security policies of network domains?</t>

<t> How to select the choices of security services and enforcement
agents in order to satisfy the security requirements?</t>

<t> How to orchestrate the negotiation of security mechanisms and
cryptographic parameters in order to provide seamless support of
security services? </t>
</list>
</t>

<t>
The security management and scalability problems found in IPSec are
captured in the following example:
</t>

<t>
In order to pass IP datagrams through several layers of IPSec-based
firewalls, both the source and the destination of the datagrams must
establish security associations with all or some of these firewalls
encountered en-route.
</t>

<t>
However, neither the source nor the destination may know of the
existence of all intermediate firewalls a priori, due to either their
lack of knowledge about the network topology or the dynamics of the
routing algorithms.
</t>

<t>
Consequently, negotiations must be conducted in sequence, on a
trial-and-error basis. For instance, the source may become aware of the
presence of a firewall if it receives ICMP messages from the firewall as
it discards the packets for which it doesn't have a security
association.
</t>

<t>
The source must then negotiate a security association with the firewall,
use session keys to authenticate and/or encrypt the packets and
retransmit them to the firewall.
</t>

<t>
This process could be repeated until no more ICMP messages are received
from any firewall and the source is certain that the packets have
successfully arrived at their destination.
</t>

<t>
This clumsy process can be further complicated by the fact that many
firewalls may drop the packets without sending back any ICMP
messages. Also, long-term security associations may have been arranged
between some of the firewalls if technologies such as virtual private
networks (VPNs) are used in part of the Internet. As a result, the tasks
of finding existing security associations while negotiating for
necessary new ones can be difficult, time consuming, and probably
impossible to complete.
</t>

<section title="Basic Terminology">

<list style="hanging">
<t hangText="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.
</t>

<t hangText="Security Domain">
	A set of communicating entities and resources that share a
	common security policy enforced at a security gateway or
	host. The definition of security domain applies to networks
	protected by security gateways as well as to single
	hosts since a host could be the enforcer of its own
	policies. Security domains could exist inside other security
	domains.
</t>

<t hangText="Security Association">
	A simplex "connection" that affords security services to the
	traffic carried by it.  Two types of securiy associations
	(SAs) are defined: transport mode and mode.  A transport
	mode SA is a security association between two hosts.  A
	tunnel mode SA is essentially an SA applied to an IP tunnel.
	Whenever either end of a security association is a security
	gateway, the SA MUST be tunnel mode.
</t>

<t hangText="Security Association Bundle">
	A group of security associations that are used for
	communications that share a common endpoint.  For example,
	all the SAs that a particular host needs to use to
	communicate with another host, including any SAs that host
	itself needs with intermediate gateways.
</t>
</list>

</section>

</section>

<section title="IPDP feature requirements">

<t>
A IPsec Policy Discovery Protocol must be a distributed system
which provides hosts and security gateways with the policy information
required to establish a secure communication end-to-end. The goal of
a policy discovery protocol is to provide the following services to
hosts and security gateways:

<list style="numbers">
<t>Discovery of security gateways</t>
<t>Management of dynamic security associations.</t>
<t>Resolution of security requirements for inter-domain communication</t>
<t>Consistency checking of local security policies.</t>
</list>
</t>

<t>
As part of this, a Policy Discovery Protocol should provide a language
that allows one to specify security policies in terms of primitives such
as user identity or role, source and destination machine address and
port number, encryption and authentication algorithms.
</t>

<t>
A host should be able to discover any remote security gateways relevant
in an end-to-end communication.  The host must be able to validate the
identities of (local and remote) security policy agents and security
gateways. It must be able to verify that the gateways in question are
entitled to represent a destination host.
</t>

<t>
A related service required by the IPsec Policy Discovery Protocol is a
mechanism to express security policies and to populate a security server
with the policies for a given security domain. The mechanism should
follow an object-oriented approach, where one can declare various
configuration objects within a security domain as part of an overall
hierarchy supporting inheritance.
</t>

<t>
Attributes of the objects should be mandatory or optional. A mandatory
attribute has to be defined for all objects of the class; optional
attributes can be skipped. Attributes can also be single or multiple
valued.
</t>
</section>

<section title="IPDP architecture requirements">
<t>
The architectural requirements of the IPsec Policy Discovery Protocol
are as follows:
</t>

<section title="Discover Gateways">
<t>
        IPDP must be able to determine a set of necessary security
        gateways through which a message must travel to complete a
        communication on a single path between two hosts.
</t>
</section>

<section title="Verify Identities">
<t>
	IPDP must allow hosts to verify the identities of gateways
	and other hosts with which they are communicating.  It must
	also be able to verify that a gateway that claims to represent
	a particular host actually does have the authority to represent
	that host.
</t>
</section>

<section title="Manage Bundles of Security Associations">
<t>
	IPDP must be able to effectively manage bundles of security
	associations.  It must be able to create bundles from policy
	information, determine if existing security associations or
	bundles may be used when creating new bundles, create new
	security associations as needed for new bundles, and keep
	security associations in existing bundles up-to-date.
</t>
</section>

<section title="Require no changes to security protocols">
<t>
	IPDP must not require changes, additions or modifications to the
	algorithms or protocols of the security protocols that use it.
</t>
</section>

<section title="Key Management Protocol Independence">
<t>
	IPDP must be independent of any particular key management
	protocol.
</t>
</section>

<section title="No Exterior Infrastructure Dependency">
<t>
	IPDP must not depend upon an exterior infrastructure, although
	implementations may use an exterior infrastructure. For example,
	public keys may be distributed using the existing DNS
	infrastructure.  IPDP must not prohibit other means for
	distributing keys.  Particular implementations may, however,
	rely on the DNS for key distribution, though they may not be as
	robust as implementations that provide several key distribution
	mechanisms.
</t>
<t>
	It is necessary, however, that the routing infrastructure be in
	place so IPDP servers may be contacted.  This is not a difficult
	requirement, since that infrastructure must be in place to send
	the communications that require the use of IPDP.
</t>
</section>
</section>

</middle>

<back>
<references>
<!-- COPS -->
%include.reference.RFC.2748;
<!-- NAT -->
%include.reference.RFC.2663;
</references>
</back>
</rfc>
<!--
  $Id: ietf-ipsp-requirements.xml,v 1.1 2001/12/14 00:25:56 mcr Exp $

  $Log: ietf-ipsp-requirements.xml,v $
  Revision 1.1  2001/12/14 00:25:56  mcr
      rev-01 of ipsp requirements document


!>

<!--

[RFC-1825]
R. Atkinson, "Security Architecture for the Internet Protocol",
RFC-1825, August 1995.

[RFC-1191]
J. Mogul, S. Deering, "Path MTU Discovery", RFC-1191, November 1990.

[RFC-1812]
F. Baker, "Reqirements for IP Version 4 Routers", RFC-1812, June 1995

   Its file name is draft-richardson-ipsec-icmp-filter-01.txt

-->


