Internet Engineering Task Force                          Jamie Jason
   INTERNET DRAFT                                    Intel Coroporation
   9-March-2000



                     IPsec Configuration Policy Model
                draft-jason-ipsp-config-policy-model-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."

   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 presents an object-oriented model of low-level IPsec
   policy designed to:
   o    facilitate agreement about the content and semantics of IPsec
        policy
   o    enable derivations of task-specific representations of IPsec
        policy such as storage schema, distribution representations,
        and policy specification languages used to configure IPsec-
        enabled endpoints
   The schema described in this document models the IKE phase one
   parameters as described in [1] and the IKE phase two parameters for
   the IPsec Domain of Interpretation as described in [2, 3, 4, 5].














Jason                                                         [Page 1]


Internet Draft     IPsec Configuration Policy Model         March 2000


Table of Contents

   Status of this Memo................................................1
   Abstract...........................................................1
   Table of Contents..................................................2
   1. Introduction....................................................4
   2. UML Conventions.................................................4
   3. Endpoint Classes................................................6
   3.1. The Class Endpoint............................................6
   3.2. The Class FQDNEndpoint........................................6
   3.3. The Class IPv4Endpoint........................................6
   3.4. The Class IPv6Endpoint........................................7
   4. IPsec Policy Classes............................................8
   4.1. The Class IPsecPolicyList.....................................9
   4.2. The Class IPsecPolicy.........................................9
   4.3. The Class IPInterface.........................................9
   5. IPsec Rule Classes.............................................10
   5.1. The Class SecurityAssociationRule............................10
   6. IPSec Condition Classes........................................11
   6.1. The Class SecurityAssociationCondition.......................11
   6.2. The Class SecurityAssociationConditionExpression.............12
   7. IPSec Filter Classes...........................................13
   7.1. The Class SecurityAssociationFilter..........................13
   7.2. The Class PortFilter.........................................14
   7.3. The Class PortRangeFilter....................................14
   7.4. The Class ProtocolFilter.....................................14
   7.5. The Class AddressFilter......................................15
   7.6. The Class EndpointFilter.....................................15
   7.7. The Class IPv4RangeFilter....................................15
   7.8. The Class IPv6RangeFilter....................................16
   8. IKE and IPsec Action Classes...................................17
   8.1. The Class SecurityAssociationAction..........................18
   8.2. The Class IKEAction..........................................19
   8.3. The Class IPsecAction........................................20
   8.4. The Class IPsecTransportAction...............................20
   8.5. The Class IPsecTunnelAction..................................21
   8.6. The Class IPsecBypassAction..................................21
   8.6. The Class IPsecDiscardAction.................................21
   9. IKE and IPsec Proposal Classes.................................21
   9.1. The Class SecurityAssociationProposal........................22
   9.2. The Class IKEProposal........................................22
   9.3. The Class IPsecProposal......................................23
   9.4. The Class IPsecTransform.....................................24
   9.5. The Class ESPTransform.......................................24
   9.6. The Class AHTransform........................................25
   9.7. The Class IPCompTransform....................................25
   10. Diffie-Hellman Classes........................................26
   10.1. The Class DiffieHellmanGroup................................27
   10.2. The Class NewGroupInfo......................................27
   10.3. The Class NewMODPGroupInfo..................................27
   10.4. The Class NewECGroupInfo....................................27
   10.5. The Class NewEC2NGroupInfo..................................28
   10.6. The Class NewECPGroupInfo...................................28

Jason                   Expires September 2000                [Page 2]


Internet Draft     IPsec Configuration Policy Model         March 2000


   11. Security Considerations.......................................28
   12. Intellectual Property.........................................28
   13. Acknowledgments...............................................29
   14. References....................................................29
   15. Disclaimer....................................................30
   16. Author's Address..............................................30
   17. Full Copyright Statement......................................30















































Jason                   Expires September 2000                [Page 3]


Internet Draft     IPsec Configuration Policy Model         March 2000


1. Introduction

   Internet Protocol security (IPsec) policy may assume a variety of
   forms as it travels from storage to distribution point to decision
   point.  At each step, it needs to be represented in a way that is
   convenient for the current task.  For example, the policy could
   exist as, but is not limited to:

   o   a Lightweight Directory Access Protocol (LDAP) [6] schema in a
       directory
   o   an on-the-wire representation over a transport protocol like the
       Common Object Policy Service (COPS) [7]
   o   a text-based policy specification language [8] suitable for
       editing by an administrator
   o   an Extensible Markup Language (XML) document

   Each of these task-specific representations should be derived from a
   canonical representation that precisely specifies the content and
   semantics of the IPsec policy.  The purpose of this document is to
   abstract IPsec policy into a task-independent representation that is
   not constrained by any particular task-dependent representation.

   This document is organized as follows:

   o   Section 2 provides a quick introduction to the Unified Modeling
       Language (UML) graphical notation conventions used in this
       document.

   o   Section 3 defines the endpoint class, a utility class that is
       used as a building block for other classes.

   o   Section 4 defines the IPsec policy and associated classes.

   o   Section 5 defines the rule class.

   o   Section 6 defines the condition and condition expression
       classes.

   o   Section 7 defines the filter classes.

   o   Section 8 defines the IKE and IPsec action classes.

   o   Section 9 defines the IKE and IPsec proposal classes.

   o   Section 10 defines the Diffie-Hellman group class.

   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 [9].

2. UML Conventions



Jason                   Expires September 2000                [Page 4]


Internet Draft     IPsec Configuration Policy Model         March 2000


   For this document, a UML static class diagram was chosen as the
   canonical representation for the IPsec policy model.  The reason
   behind this decision is that UML provides a task-independent way to
   model systems.  A treatise on the graphical notation used in UML is
   beyond the scope of this paper.  However, given the use of ASCII
   drawing for UML static class diagrams, a description of the
   notational conventions used in this document is in order:

   o   Boxes represent classes, with class names in brackets ([])
       representing a virtual class.  For example, in the action
       classes diagram, IKEAction is a concrete class while
       SecurityAssociationAction is a virtual class.
   o   A line that terminates with a "o" denotes aggregation.
       Aggregation denotes classes with independent lifetimes.  An
       aggregated object exists independently of the object that
       references it.  For example, in the action classes diagram a
       SecurityAssocationProposal object exists independently of the
       SecurityAssociationAction object which references it.
   o   A line that terminates with an "x" denotes composition.
       Composition denotes classes with coincident lifetimes.  This
       implies that the lifetime of the contained object is the same as
       the object that contains it.
   o   Next to a line appears a multiplicity.  Multiplicities indicate
       the number of objects contained (or referenced) as well as the
       number of object that can contain (or reference) a particular
       object.  The multiplicity may be:
       - a range in the form "lower bound..upper bound" indicating the
       minimum and maximum number of objects.  For example, in the
       action classes diagram, an IPsecAction may contain either 0 or 1
       DiffieHellmanGroup objects(essentially noting that the
       DiffieHellmanGroup is optional).
       - a number that indicates the exact number of objects.  For
       example, in the proposal classes diagram, an IKEProposal has 1
       and only 1 DiffieHellmanGroup.  Using a number is equivalent to
       number..number.
       - an asterisk indicating any number of objects, including zero.
       For example, in the action classes diagram, a
       SecurityAssociationProposal object may be referenced by 0 to n
       SecurityAssociationAction objects.  Using an asterisk is
       equivalent to 0..n.
       - the letter n indicating from 1 to many.  For example, in the
       action classes diagram, a SecurityAssociationAction references 1
       to many SecurityAssociationProposals.  Using the letter n is
       equivalent to 1..n.
   o   A line that terminates with an arrow (<, >, ^, v) denotes
       generalization (inheritance) with the arrow pointing to the
       parent class.  For example, in the action classes diagram the
       SecurityAssociationAction class is a generalization of the
       IKEAction class (or said another way, the IKEAction class
       derives from the SecurityAssociationAction class).
   o   Occasionally there may be some text, or a reference to some
       text, enclosed by braces ({}).  This indicates a constraint.
       Constraints are used to constrain the meaning of diagram so that

Jason                   Expires September 2000                [Page 5]


Internet Draft     IPsec Configuration Policy Model         March 2000


       a diagram does not provide the ability to define something that
       does not make sense.  For example, in the action classes diagram
       there is a constraint placed upon the DiffieHellmanGroup class
       such that it is only used if the IPsecAction specifies the user
       of Perfect Forward Secrecy.

   It should be noted that the UML static class diagram presented is a
   conceptual view of IPsec policy designed to aid in understanding.
   It does not necessarily get translated class for class into another
   representation.  For example, an LDAP implementation may flatten out
   the representation to fewer classes (because of the inefficiency of
   following references).

3. Endpoint Classes

   An endpoint is an abstraction used to represent an IP address or
   hostname.  This class is used as a building block in further
   classes.

                               +----------+
                               |          |
                               |[Endpoint]|
                               |          |
                               +----------+
                                     ^
                                     |
         +---------------------------+--------------------------+
         |                           |                          |
   +------------+              +------------+            +------------+
   |            |              |            |            |            |
   |FQDNEndpoint|              |IPv4Endpoint|            |IPv6Endpoint|
   |            |              |            |            |            |
   +------------+              +------------+            +------------+

3.1. The Class Endpoint

   The Endpoint class is used as an abstract base class from which
   concrete endpoint classes are expected to derive from.

3.2. The Class FQDNEndpoint

   The FQDNEndpoint class is used to represent endpoints that can be
   expressed using a DNS name.  It contains the following attribute:

   NAME         name
   DESCRIPTION  Either a fully-qualified or wild-carded (partially or
                fully) domain name.
   TYPE         string
   VALUE        MAY either be fully-qualified (for example,
                runner.jf.intel.com) or wild-carded (for example,
                *.intel.com).

3.3. The Class IPv4Endpoint

Jason                   Expires September 2000                [Page 6]


Internet Draft     IPsec Configuration Policy Model         March 2000



   The IPv4Endpoint class is used to represent endpoints that can be
   expressed using an IPv4 address.  It contains the following
   attribute:

   NAME         address
   DESCRIPTION  The IPv4 address.
   TYPE         unsigned 32-bit integer
   VALUE        0x00000000 (i.e., 0.0.0.0) - used to specify any IP
                address (i.e., a totally wild-carded address or "*").
                Any other value specifies an IPv4 address.

3.4. The Class IPv6Endpoint
   The IPv6Endpoint class is used to represent endpoints that can be
   expressed using an IPv6 address.  It contains the following
   attribute:

   NAME         address
   DESCRIPTION  The IPv6 address.
   TYPE         octet[16]
   VALUE        all zero's (i.e., 0:0:0:0:0:0:0:0) - used to specify
                any IP address (i.e., a totally wild-carded address or
                "*").  Any other value specifies an IPv6 address.































Jason                   Expires September 2000                [Page 7]


Internet Draft     IPsec Configuration Policy Model         March 2000


4. IPsec Policy Classes

   The IPsec policy classes represent the set of policies that are
   contained on a system.  In addition, they indicate the active
   policies as well as associate a policy with a particular interface
   on a system

                           +---------------+
                           |               |
                           |IPsecPolicyList|
                           |               |
                           +---------------+
                                 * o
                                   |
                                (a)|
                                   |
                                 * |
                              +-----------+            +-----------+
                              |           |*    (b)   *|           |
                              |IPsecPolicy|o-----------|IPInterface|
                              |           |     {1}    |           |
                              +-----------+            +-----------+
                              1 x       x 1                1 x
                                |       |                    |
                             (c)|{2} {3}|(d)              (e)|{4}
                                |       |                    |
                              * |       | *                1 |
                         +----------------------+       +----------+
                         |                      |       |          |
                         |SecurityAssocationRule|       |[Endpoint]|
                         |                      |       |          |
                         +----------------------+       +----------+

   (a)  Policies
   (b)  TargetedInterface
   (c)  IKERules
   (d)  IPsecRules
   (e)  Identity

   {1}  1.  If the policy is marked as enabled, then the IPsecPolicy
        object MUST reference an IPInterface object.
        2.  For each interface, there is only one IPsec policy marked
        as enabled.
   {2}  IKE rules are ordered and are considered logically ORed.  Rule
        search will stop once a rule that matches the input criteria is
        found.
   {3}  IPsec rules are ordered and are considered logically ORed.
        Rule search will stop once a rule that matches the input
        criteria is found.
   {4}  If the endpoint type is an FQDN, then the DNS name MUST be
        fully-qualifed (i.e., no wild-card values allowed).
        If the endpoint type is an IPv4 or IPv6 address, then the
        address value MUST NOT be the wild-card address.

Jason                   Expires September 2000                [Page 8]


Internet Draft     IPsec Configuration Policy Model         March 2000



4.1. The Class IPsecPolicyList

   The IPsecPolicyList class is a container for all of the policies on
   a particular system.  It contains the following reference:

   NAME         Policies
   DESCRIPTION  The policies installed on a particular system.  Note
                that there is a distinction between a policy being
                installed on a system and actually being actively
                enforced (see the IPsecPolicy class).

   Note:  an IPsecPolicyList MAY contain no policies.  Additionally, a
   policy MAY be defined which is not in any policy list.  The latter
   case is only relevant for a management station - in other words, an
   IPsec policy has been created but it has not yet been targeted to a
   system.

4.2. The Class IPsecPolicy

   The IPsecPolicy class is a container for all of the rules used to
   enforce the policy.  It contains the following attribute/references:

   NAME         enabled
   DESCRIPTION  Indicates whether or not the policy is enabled (i.e.,
                is actively being enforced).  As stated in the
                constraint {1}, if the policy is enabled, it MUST be
                associated with a particular interface on the system.
                This allows for different policies to be enforced on
                different interfaces.
   TYPE         boolean
   VALUE        true - policy is currently enabled
                false - policy is currently disabled

   NAME         TargetedInterface
   DESCRIPTION  The interface on the system for which this policy is to
                be enforced. As stated in the constraint {1}, for each
                interface there is only one policy enabled at any one
                given time.

   NAME         IKERules
   DESCRIPTION  The rules which govern when and how to perform IKE
                phase 1 negotiation.  These rules are an ordered list
                and are logically ORed.  When processing the rules, the
                first rule matched is the one used.

   NAME         IPsecRules
   DESCRIPTION  The rules which govern when and how to perform IKE
                phase 2 negotiation.  These rules are an ordered list
                and are logically ORed.  When processing the rules, the
                first rule matched is the one used.

4.3. The Class IPInterface

Jason                   Expires September 2000                [Page 9]


Internet Draft     IPsec Configuration Policy Model         March 2000


   The IPInterface class is used to represent an interface on the
   system.  It contains the following reference:

   NAME         Identity
   DESCRIPTION  Indicates the IP address or DNS name assigned to the
                interface.  No wild-card values are allowed for the
                endpoint object.

5. IPsec Rule Classes

   The IPsec rule class is used to associate a condition with the
   action which is to be performed when the condition evaluates to
   true.

                         +-----------------------+
                         |                       |
                         |SecurityAssociationRule|
                         |                       |
                         +-----------------------+
                            * o             o *
                              |             |
                   +----------+             +-----------+
                   |   (a)                       (b)    |
                 1 |                                    | 1
      +----------------------------+     +---------------------------+
      |                            |     |                           |
      |SecurityAssociationCondition|     |[SecurityAssociationAction]|
      |                            |     |                           |
      +----------------------------+     +---------------------------+

   (a)  Condition
   (b)  Action

5.1. The Class SecurityAssociationRule

   The SecurityAssociationRule class is used to associate a condition
   with the IKE/IPsec action information that is to be used during the
   negotiation.  It contains the following attribute/references:

   NAME         enabled
   DESCRIPTION  Indicates whether or not the rule is enabled.
   TYPE         boolean
   VALUE        true - rule is currently enabled
                false - rule is currently disabled

   NAME         Condition
   DESCRIPTION  The condition, when evaluated against the given input,
                that MUST evaluate to true in order for the associated
                action to be performed.

   NAME         Action
   DESCRIPTION  The security association negotiation parameters to use
                when the associated condition evaluates to true.

Jason                   Expires September 2000               [Page 10]


Internet Draft     IPsec Configuration Policy Model         March 2000



6. IPSec Condition Classes

   The condition class is used to determine when the associated IKE or
   IPsec action is to be performed.

                      +----------------------------+
                      |                            |
                      |SecurityAssociationCondition|
                      |                            |
                      +----------------------------+
                                   1 x
                                     |
                                  {1}|(a)
                                     |
                                   * |
                  +--------------------------------------+
                  |                                      |
                  |SecurityAssociationConditionExpression|
                  |                                      |
                  +--------------------------------------+
                                   1 |
                                     |
                                  {2}|(b)
                                     |
                                   * |
                       +---------------------------+
                       |                           |
                       |[SecurityAssociationFilter]|
                       |                           |
                       +---------------------------+

   (a)  Expressions
   (b)  Filters

   {1}  If using disjunctive normal form (DNF), each expression is
        logically ORed.  If using conjunctive normal form (CNF), each
        expression is logically ANDed.
   {2}  If using DNF, each filter is logically ANDed.  If using CNF,
        each filter is logically ORed.

6.1. The Class SecurityAssociationCondition

   The SecurityAssociationCondition class specifies the criteria that
   is applied to the input information to determine if a particular
   condition is met.  It contains the following attributes/references:

   NAME         negated
   DESCRIPTION  Indicates whether or not the result of the rule
                evaluation is to be negated.
   TYPE         boolean
   VALUE        true - condition evaluation result is to be negated


Jason                   Expires September 2000               [Page 11]


Internet Draft     IPsec Configuration Policy Model         March 2000


                false - condition evaluation result is not to be
                negated

   NAME         useDNF
   DESCRIPTION  Indicates whether or not the rule is specified in DNF
                or CNF form.
   TYPE         boolean
   VALUE        true - condition is expressed as DNF.  The expressions
                within the condition are logically ORed.  The filters
                within an expression are logically ANDed.
                false - condition is expressed as CNF.  The expressions
                within the condition are logically ANDed.  The filters
                within an expression are logically ORed.

6.2. The Class SecurityAssociationConditionExpression

   The SecurityAssociationConditionExpression class is used to combine
   several filters, which together constitute one logical expression.
   It contains the following reference:

   NAME         Filters
   DESCRIPTION  The set of filters, which combined, are used to
                represent the expression.  When using DNF, these
                filters are logically ANDed.  When using CNF, these
                filters are logically ORed.





























Jason                   Expires September 2000               [Page 12]


Internet Draft     IPsec Configuration Policy Model         March 2000


7. IPSec Filter Classes

   The filter classes are used to specify individual criteria which
   MUST be met before a condition will evaluate to true.

                       +---------------------------+
                       |                           |
                       |[SecurityAssociationFilter]|
                       |                           |
                       +---------------------------+
                                    ^
                                    |
         +----------------+---------+-------+-----------------+
      {1}|                |                 |                 |
   +-------------+   +----------+   +---------------+  +--------------+
   |             |   |          |   |               |  |              |
   |AddressFilter|   |PortFilter|   |PortRangeFilter|  |ProtocolFilter|
   |             |   |          |   |               |  |              |
   +-------------+   +----------+   +---------------+  +--------------+
         ^
         |
         +----------------------+---------------------+
         |                      |                     |
   +--------------+     +---------------+     +---------------+
   |              |     |               |     |               |
   |EndpointFilter|     |IPv4RangeFilter|     |IPv6RangeFilter|
   |              |     |               |     |               |
   +--------------+     +---------------+     +---------------+
       1 x
         |
      (a)|
         |
       1 |
   +----------+
   |          |
   |[Endpoint]|
   |          |
   +----------+

   (a)  Identity

   {1}  When the rule is for an IKE phase one negotiation, the
        AddressFilter is the only type of filter allowed.

7.1. The Class SecurityAssociationFilter

   The SecurityAssociationFilter class is used as an abstract base
   class from which all concrete filter class are expected to derive
   from.  It contains the following attribute:

   NAME         negated
   DESCRIPTION  Indicates whether or not the result of the filter
                evaluation is to be negated.

Jason                   Expires September 2000               [Page 13]


Internet Draft     IPsec Configuration Policy Model         March 2000


   TYPE         boolean
   VALUE        true - filter evaluation is to be negated
                false - filter evaluation is not to be negated

7.2. The Class PortFilter

   The PortFilter class specifies a filter that is based upon a single
   port value.  It contains the following attributes:

   NAME         applyToSource
   DESCRIPTION  Indicates whether or not the port specified is to be
                interpreted as a source port or a destination port.
   TYPE         boolean
   VALUE        true - the port specified is to be interpreted as a
                source port
                false - the port specified is to be interpreted as a
                destination port

   NAME         port
   DESCRIPTION  Specifies the port value.
   TYPE         unsigned 16-bit integer
   VALUE        0 - wild-card port (i.e., any port matches).  Any other
                value specifies a specific port.

7.3. The Class PortRangeFilter

   The PortRangeFilter class specifies a filter that is based upon a
   range of port values.  The port range is to be interpreted as
   inclusive.  It contains the following attributes:

   NAME         applyToSource
   DESCRIPTION  Indicates whether or not the port specified is to be
                interpreted as a source port range or a destination
                port range.
   TYPE         boolean
   VALUE        true - the port range specified is to be interpreted as
                a source port range
                false - the port range specified is to be interpreted
                as a destination port range

   NAME         firstPort
   DESCRIPTION  Specifies the first port in the range.
   TYPE         unsigned 16-bit integer

   NAME         lastPort
   DESCRIPTION  Specifies the last port in the range.
   TYPE         unsigned 16-bit integer
   VALUE        The lastPort attribute value MUST be greater than or
                equal to the firstPort attribute value.

7.4. The Class ProtocolFilter



Jason                   Expires September 2000               [Page 14]


Internet Draft     IPsec Configuration Policy Model         March 2000


   The ProtocolFilter class specifies a filter that is based upon the
   IP protocol.  It contains the following attribute:

   NAME         protocol
   DESCRIPTION  Specifies the IP protocol value.
   TYPE         unsigned 8-bit integer
   VALUE        0 - wild-card protocol (i.e., any protocol).  Any other
                value specifies a specific protocol.

   Note:  if using DNF, it does not make sense to use a PortFilter or
   PortRangeFilter when using a ProtocolFilter that is not either UDP
   or TCP.

7.5. The Class AddressFilter

   The AddressFilter class is used to represent filters which use a
   system's address or DNS name as a filter.  It is used as an abstract
   base class from which specific address-based filters will be
   derived.  The address filters are always used to specify the
   address/hostname of the destination machine.  The reason is that the
   association of a policy with a particular interface implies the
   source address/hostname - one could look at the policy to interface
   mapping as another type of filter.

   Note:  for IKE rules, these are the only filter type allowed.

7.6. The Class EndpointFilter

   The EndpointFilter class is used to represent a filter that
   specifies an individual interface on one system.  It is used to
   specify an FQDN, an IPv4 address, or an IPv6 address.  It contains
   the following reference:

   NAME         Identity
   DESCRIPTION  Specifies the FQDN or IP address to use for the filter.
                The value MAY be wild-carded (see the Endpoint class
                description).

7.7. The Class IPv4RangeFilter

   The IPv4RangeFilter is used to represent a filter that specifies a
   range of IPv4 address.  The range is to be interpreted as inclusive.
   It contains the following attributes:

   NAME         firstAddress
   DESCRIPTION  Specifies the first address in the range.
   TYPE         unsigned 32-bit value

   NAME         lastAddress
   DESCRIPTION  Specifies the last address in the range.
   TYPE         unsigned 32-bit value
   VALUE        The lastAddress attribute value MUST be greater than or
                equal to the firstAddress attribute value.

Jason                   Expires September 2000               [Page 15]


Internet Draft     IPsec Configuration Policy Model         March 2000



7.8. The Class IPv6RangeFilter

   The IPv6RangeFilter is used to represent a filter that specifies a
   range of IPv6 address.  The range is to be interpreted as inclusive.
   It contains the following attributes:

   NAME         firstAddress
   DESCRIPTION  Specifies the first address in the range.
   TYPE         octet[16]

   NAME         lastAddress
   DESCRIPTION  Specifies the last address in the range.
   TYPE         octet[16]
   VALUE        The lastAddress attribute value MUST be greater than or
                equal to the firstAddress attribute value.






































Jason                   Expires September 2000               [Page 16]


Internet Draft     IPsec Configuration Policy Model         March 2000


8. IKE and IPsec Action Classes

   An action is a set of proposals combined with the security
   association level information that is used to protect a particular
   flow.

                    +---------------------------+
                    |                           |
                    |[SecurityAssociationAction]|
                    |                           |o---+
                    +---------------------------+*   |
                                ^                 (a)|{1}
                                |                   n|
                                |       +-----------------------------+
                                |       |                             |
                                |       |[SecurityAssociationProposal]|
                                |       |                             |
                                |       +-----------------------------+
                                |
                  +---------+   |
                  |         |   |
                  |IKEAction|---+
                  |         |   |
                  +---------+   |
                                |
                +-----------+   |           +------------------+
                |           |---+           |                  |
                |IPsecAction|      (b)  0..1|DiffieHellmanGroup|
                |           |o--------------|                  |
                +-----------+*     {2}      +------------------+
                      ^
                      |
             +--------+------------+-----------+------------+
             |                     |           |            |
   +--------------------+ +-----------------+  |   +-----------------+
   |                    | |                 |  |   |                 |
   |IPsecTransportAction| |IPsecTunnelAction|  |   |IPsecBypassAction|
   |                    | |                 |  |   |                 |
   +--------------------+ +-----------------+  |   +-----------------+
                                 1 x           |
                                   |           |
                                (c)|{3}        +------------+
                                   |                        |
                             +----------+          +------------------+
                             |          |          |                  |
                             |[Endpoint]|          |IPsecDiscardAction|
                             |          |          |                  |
                             +----------+          +------------------+

   (a)  Proposals
   (b)  IPsecGroup
   (c)  RemoteGateway


Jason                   Expires September 2000               [Page 17]


Internet Draft     IPsec Configuration Policy Model         March 2000


   {1}  1.  For an IKEAction object, these MUST be IKEPropsal objects.
        For an IPsecAction object, these MUST be IPsec Action objects.
        2.  SecurityAssociationProposal objects are ordered from most
        preferable to least preferable and are logically ORed.  The
        mechanism by which ordering is accomplished is dependent upon
        the specific derivation of the IPsec schema.
   {2}  If not using Perfect Forward Secrecy (PFS), then the
        DiffieHellmanGroup object either does not exist or is ignored.
        Otherwise (PFS is used) if the DiffieHellmanGroup object is not
        present, then the Diffie-Hellman Group from Phase 1 will be
        used for Phase 2.  Otherwise, use the DiffieHellmanGroup
        object.
   {3}  If the endpoint type is an FQDN, then the DNS name MUST be
        fully-qualifed (i.e., no wild-card values allowed).
        If the endpoint type is an IPv4 or IPv6 address, then the
        address MUST NOT be the wild-card value.

8.1. The Class SecurityAssociationAction

   The SecurityAssociationAction class contains the parameters that are
   common between the IKE and IPsec action classes.  It contains the
   following attributes/references:

   NAME         refreshThresholdSeconds
   DESCRIPTION  Specifies the percentage of expiration (in other words,
                the refresh threshold) of an established SA's seconds
                lifetime at which to begin renegotiation of the SA.
   TYPE         integer
   VALUE        Valid values are in the range 1 to 100 inclusive.  A
                value of 100 means that renegotiation does not occur
                until the seconds lifetime value has expired.

   refreshThresholdSeconds is not a negotiated parameter.

   NAME         refreshThresholdKilobytes
   DESCRIPTION  Specifies the percentage of expiration of an
                established SA's kilobyte lifetime at which to begin
                renegotiation of the SA.
   TYPE         integer
   VALUE        Valid values are in the range 1 to 100 inclusive.  A
                value of 100 means that renegotiation does not occur
                until the kilobyte lifetime value has expired.

   refreshThresholdKilobytes is not a negotiated parameter.

   NAME         minLifetimeSeconds
   DESCRIPTION  Specifies the minimum SA seconds lifetime that will be
                accepted from a peer while negotiating an SA based upon
                this action.  The purpose of this value is to prevent
                denial-of-service attacks in which a peer can select an
                arbitrarily low seconds lifetime, causing the IKE
                server to perform renegotiations with correspondingly
                expensive Diffie-Hellman calculations.

Jason                   Expires September 2000               [Page 18]


Internet Draft     IPsec Configuration Policy Model         March 2000


   TYPE         unsigned 32-bit integer
   VALUE        0 - indicates that there is no minimum lifetime
                enforced.
                Any other value specifies a required minimum seconds
                lifetime.

   minLifetimeSeconds is not a negotiated parameter.

   NAME         minLifetimeKilobytes
   DESCRIPTION  Specifies the minimum kilobyte lifetime that will be
                accepted from a negotiating peer while negotiating an
                SA based upon this action.  The purpose of this value
                is to prevent denial-of-service attacks in which a peer
                can select an arbitrarily low kilobyte lifetime,
                causing the IKE server to perform renegotiations with
                correspondingly expensive Diffie-Hellman calculations.
   TYPE         unsigned 32-bit integer
   VALUE        0 - indicates that there is no minimum lifetime
                enforced.
                Any other value specifies a required minimum kilobyte
                lifetime.

   minLifetimeKilobytes is not a negotiated parameter.

   NAME         trafficIdleTime
   DESCRIPTION  Specifies the amount of time in seconds an SA,
                negotiated using the containing action object, may
                remain idle (in other words, no traffic protected by
                the SA) before it is deleted.
   TYPE         unsigned 32-bit integer
   VALUE        0 - there is no idle time detection.  In other words,
                the expiration of the SA is solely dependent upon the
                expiration of one of the lifetime values.
                Any other value specifies the number of seconds the SA
                may remain idle before it can be forcibly expired.

   trafficIdleTime is not a negotiated parameter.

   NAME         Proposals
   DESCRIPTION  Specifies a logically ORed set of proposals, ORDERED
                from most preferable to least prefereable, which are
                used during negotiation of the SA.  If the action is an
                IKEAction, then the set will contain IKEProposal
                objects.  If the action is an IPsecAction, then the set
                will contain IPsecProposal objects.  A
                SecurityAssociationAction object will reference one to
                many SecurityAssociationProposal objects.  A
                SecurityAssociationProposal object MAY be referenced by
                zero to many SecurityAssociationAction objects.  See
                section 9 for a description of the
                SecurityAssociationProposal and derived classes.

8.2. The Class IKEAction

Jason                   Expires September 2000               [Page 19]


Internet Draft     IPsec Configuration Policy Model         March 2000



   IKEAction is a specialization of the SecurityAssociationAction class
   and specifies the parameters unique to an IKE action.  It contains
   the following attributes:

   NAME         exchangeMode
   DESCRIPTION  Specifies the negotiation mode that the IKE server will
                use for phase one.
   TYPE         unsigned 16-bit integer
   VALUE        1 - base mode
                2 - main mode
                4 - aggressive mode

   NAME         refreshThresholdDerivedKeys
   DESCRIPTION  Specifies the percentage of expiration of an
                established IKE SA's derived keys lifetime at which to
                begin renegotiation of the SA.
   TYPE         integer
   VALUE        Valid values are in the range 1 to 100 inclusive.  A
                value of 100 means that renegotiation does not occur
                until the derived key lifetime value has expired.

   refreshThresholdDerivedKeys is not a negotiated parameter.

8.3. The Class IPsecAction

   IPsecAction is a specialization of the SecurityAssociationAction
   class and specifies the parameters unique to an IPsec action.  It
   contains the following attributes/references:

   NAME         usePfs
   DESCRIPTION  Specifies whether or not PFS should be used when
                negotiating the phase two IPsec SA.
   TYPE         boolean
   VALUE        true
                false

   NAME         IPsecGroup
   DESCRIPTION  If PFS should be used during IKE phase two, this
                specifies the Diffie-Hellman group to use.  The
                DiffieHellmanGroup class is described in section 10.
   DEFAULT      Since an IPsecAction object MAY optionally contain a
                IPsecGroup object, absence of one when using PFS
                indicates that the IKE phase two negotiation should use
                the same Diffie-Hellman group that was agreed upon
                during the IKE phase one negotiation.

8.4. The Class IPsecTransportAction

   IPsecTransportAction is a specialization of IPsecAction, but does
   not add any attributes.  It is used to signify that the phase two
   action will be for the negotiation of an IPsec transport mode SA.


Jason                   Expires September 2000               [Page 20]


Internet Draft     IPsec Configuration Policy Model         March 2000


8.5. The Class IPsecTunnelAction

   IPsecTunnelAction is a specialization of IPsecAction that is used to
   signify that the phase two action will be for the negotiation of an
   IPsec tunnel mode SA.  It contains the following reference:

   NAME         RemoteGateway
   DESCRIPTION  The identity of the point where the tunnel terminates
                on the remote gateway.

   Note:  since a particular IPsec policy is directly associated with a
   particular interface in the system, the local gateway identity can
   be implicitly determined from this information.

8.6. The Class IPsecBypassAction

   IPsecBypassAction is a specialization of IPsecAction, but does not
   add any attributes.  It is used to signify that the traffic is to be
   allowed to pass in the clear.

8.6. The Class IPsecDiscardAction

   IPsecDiscardAction is a specialization of IPsecAction, but does not
   add any attributes.  It is used to signify that the traffic should
   be denied.

9. IKE and IPsec Proposal Classes

   A proposal contains the security parameters that will be used during
   the IKE phase one and two negotiations.

                      +-----------------------------+
                      |                             |
                      |[SecurityAssociationProposal]|
                      |                             |
                      +-----------------------------+
                                     ^
                                     |
                       +---------------------------+
                       |                           |
                 +-------------+             +-----------+
                 |             |             |           |
                 |IPsecProposal|             |IKEProposal|
                 |             |             |           |
                 +-------------+             +-----------+
                     * o                         * o
                       |(a)                        |(b)
                     n |                         1 |
                +----------------+        +------------------+
                |                |        |                  |
                |[IPsecTransform]|        |DiffieHellmanGroup|
                |                |        |                  |
                +----------------+        +------------------+

Jason                   Expires September 2000               [Page 21]


Internet Draft     IPsec Configuration Policy Model         March 2000


                       ^
                       |
         +-------------+------------------+
         |             |                  |
   +------------+  +-----------+  +---------------+
   |            |  |           |  |               |
   |ESPTransform|  |AHTransform|  |IPCompTransform|
   |            |  |           |  |               |
   +------------+  +-----------+  +---------------+

   (a) Transforms
   (b) IkeDhGroup

9.1. The Class SecurityAssociationProposal

   The SecurityAssociationProposal class contains the parameters that
   are common between the IKE and IPsec proposal classes.  It contains
   the following attributes:

   NAME         lifetimeSeconds
   DESCRIPTION  Specifies the seconds lifetime for this particular
                proposal.  This value is used when sending this
                proposal to the negotiating peer.  Additionally, it may
                be used, possibly in conjunction with the minimum
                seconds lifetime value, when selecting a proposal from
                the negotiating peer.
   TYPE         unsigned 32-bit integer
   VALUE        0 - indicates that the lifetime value defaults to 8
                hours (28,800 seconds).

   NAME         lifetimeKilobytes
   DESCRIPTION  Specifies the kilobyte lifetime for this particular
                proposal.  This value is used when sending this
                proposal to the negotiating peer.  Additionally, it may
                be used, possibly in conjunction with the minimum
                kilobyte lifetime value, when selecting a proposal from
                the negotiating peer.
   TYPE         unsigned 32-bit integer
   VALUE        0 - indicates that there is no kilobyte lifetime.

9.2. The Class IKEProposal

   IKEProposal is a specialization of the SecurityAssociationProposal
   class and specifies the parameters unique to the IKE proposal.  It
   contains the following attributes/references:

   NAME         cipherAlgorithm
   DESCRIPTION  Specifies the encryption algorithm the IKE server will
                propose.
   TYPE         unsigned 16-bit integer
   VALUE        1 - DES-CBC
                2 - IDEA-CBC
                3 - Blowfish-CBC

Jason                   Expires September 2000               [Page 22]


Internet Draft     IPsec Configuration Policy Model         March 2000


                4 - RC5-R16-B64-CBC
                5 - 3DES-CBC
                6 - CAST-CBC

   NAME         hashAlgorithm
   DESCRIPTION  Specifies the hash algorithm the IKE server will
                propose.
   TYPE         unsigned 16-bit integer
   VALUE        1 - MD5
                2 - SHA-1
                3 - Tiger

   NAME         authenticationMethod
   DESCRIPTION  Specifies the authentication method the IKE server will
                propose.
   TYPE         unsigned 16-bit integer
   VALUE        1 - Preshared Key
                2 - DSS Signatures
                3 - RSA Signatures
                4 - RSA Encryption
                5 - Revised RSA Encryption
                6 - El-Gamal Encryption
                7 - Revised El-Gamal Encyrption
                65001 - Kerberos

   NAME         lifetimeDerivedKeys
   DESCRIPTION  Specifies the number of times the IKE phase one key may
                be used to derive an IKE phase two key.
   TYPE         unsigned 32-bit integer
   VALUE        0 - indicates that the number of times a IKE phase one
                key may be used to derive an IKE phase two key is
                limited by the seconds and/or kilobyte lifetimes.

   lifetimeDerivedKeys is not a negotiated parameter.  Although this
   value is not negotiated, it is included with the proposal
   information as the value is dependent upon the strength of the
   security parameters in the proposal.

   NAME         prfAlgorithm
   DESCRIPTION  Specifies the Psuedo-Random Function (PRF) the IKE
                server will propose.
   TYPE         unsigned 16-bit integer
   VALUE        At this time, there are no negotiable PRFs defined.

   NAME         IkeDhGroup
   DESCRIPTION  Specifies the Diffie-Hellman group that the IKE server
                will propose.  The DiffieHellmanGroup class is defined
                in section 10.

9.3. The Class IPsecProposal




Jason                   Expires September 2000               [Page 23]


Internet Draft     IPsec Configuration Policy Model         March 2000


   IPsecProposal is a specialization of the SecurityAssociationProposal
   class and specifies the parameters unique to the IPsec proposal.  It
   contains the following reference:

   NAME         Transforms
   DESCRIPTION  Specifies a set of IPsecTransform objects that
                represent the Encapsulating Security Payload (ESP),
                Authentication Header (AH), and IP Payload Compression
                Protocol (IPComp) parameters that are to used to create
                an IPsec proposal.  Transforms of the same type are to
                be grouped together and logically ORed and the order of
                the transforms of the same type MUST be preserved.  The
                transform groups are to be logically ANDed.  For
                example, if the proposal had the following set of
                transforms {ESP=DES,AH=MD5,ESP=3-DES,ESP=RC5,AH=SHA-1},
                the proposal would be ((ESP = DES or 3-DES or RC5) and
                (AH = MD5 or SHA-1)).  An IPsecProposal object MAY
                reference one to many IPsecTransform objects.  An
                IPsecTransform object MAY be referenced by zero to many
                IPsecProposal objects.

9.4. The Class IPsecTransform

   The IPsecTransform class contains no properties and exists only for
   the purpose of modeling the is-a-kind-of relationship for IPsec
   transforms.  For example, an ESPTransform is a kind of
   IPsecTransform.

9.5. The Class ESPTransform

   ESPTransform is a specialization of an IPsecTransform.  It specifies
   the parameters for one IPSec ESP transform within an IPsec proposal.
   It contains the following attributes:

   NAME         integrityTransformId
   DESCRIPTION  Specifies the ESP integrity algorithm to propose.
   TYPE         unsigned 16-bit integer
   VALUE        1 - HMAC MD5
                2 - HMAC SHA-1
                3 - HMAC DES
                4 - KPDK

   NAME         cipherTransformId
   DESCRIPTION  Specifies the ESP cipher/encryption algorithm to
                propose.
   TYPE         unsigned 16-bit integer
   VALUE        1 - DES IV64
                2 - DES
                3 - 3-DES
                4 - RC5
                5 - IDEA
                6 - CAST
                7 - Blowfish

Jason                   Expires September 2000               [Page 24]


Internet Draft     IPsec Configuration Policy Model         March 2000


                8 - 3-IDEA
                9 - DES IV32
                10 - RC4
                11 - NULL

   NAME         cipherKeyRounds
   DESCRIPTION  Specifies the number of key rounds for the ESP cipher
                algorithm specified by the attribute cipherTransformId.
   TYPE         unsigned 16-bit integer
   VALUE        At this time, there are no cipher key rounds defined
                for any IPsec ESP algorithms.

   NAME         cipherKeyLength
   DESCRIPTION  Specifies the length of the ESP cipher key, in bits.
                If cipherTansformId specifies a cipher with a fixed-
                length key, cipherKeyLength is ignored.
   TYPE         unsigned 16-bit integer
   VALUE        0 - the cipher algorithm specified by the
                cipherTransformId attribute implies the key length.
                Any other value specifies a key length, in bits.

9.6. The Class AHTransform

   AHTransform is a specialization of an IPsecTransform.  It specifies
   the parameters for one AH transform within an IPsec proposal.  It
   contains the following property:

   NAME         transformId
   DESCRIPTION  Specifies the AH hash algorithm to propose.
   TYPE         unsigned 16-bit integer
   VALUE        2 - MD5
                3 - SHA-1
                4 - DES

9.7. The Class IPCompTransform

   IPCompTransform is a specialization of an IPsecTransform.  It
   specifies the parameters for one IPComp transform within an IPsec
   proposal.  It contains the following properties:

   NAME         algorithm
   DESCRIPTION  Specifies the IPComp compression algorithm to propose.
   TYPE         unsigned 16-bit integer
   VALUE        1 - OUI (privateAlgorithm MUST contain a valid value)
                2 - Deflate
                3 - LZS

   NAME         dictionarySize
   DESCRIPTION  Specifies the dictionary size for the compression
                algorithm.
   TYPE         unsigned 16-bit integer
   VALUE        0 - the compression algorithm specified by the
                algorithm attribute dictates the dictionary size.

Jason                   Expires September 2000               [Page 25]


Internet Draft     IPsec Configuration Policy Model         March 2000


                Any other value is to be interpreted in the context of
                the compression algorithm.

   NAME         privateAlgorithm
   DESCRIPTION  If the algorithm attribute specifies the use of a
                proprietary compression transform (OUI = 1), then this
                specifies the specific vendor algorithm that will be
                used.  Otherwise, this value is ignored.
   TYPE         unsigned 32-bit integer

10. Diffie-Hellman Classes

   The Diffie-Hellman classes are used to define the Diffie-Hellman
   attributes that are used during phase one (and possibly phase two)
   of the IKE negotiation.

                       +------------------+
                       |                  |
                       |DiffieHellmanGroup|
                       |                  |
                       +------------------+
                              * o
                            (a) | {1}
                           0..1 |
                         +--------------+
                         |              |
                         |[NewGroupInfo]|
                         |              |
                         +--------------+
                                ^
                                |
               +----------------+----------------+
               |                                 |
       +----------------+                +----------------+
       |                |                |                |
       |NewMODPGroupInfo|                |[NewECGroupInfo]|
       |                |                |                |
       +----------------+                +----------------+
                                                 ^
                                                 |
                                     +-----------+----------+
                                     |                      |
                             +----------------+     +---------------+
                             |                |     |               |
                             |NewEC2NGroupInfo|     |NewECPGroupInfo|
                             |                |     |               |
                             +----------------+     +---------------+

   (a) ExplicitGroupInfo

   {1} If the Diffie-Hellman Group is a well-known group (or previously
       agreed upon private group), then the NewGroupInfo object doesn't
       exist (or is ignored).

Jason                   Expires September 2000               [Page 26]


Internet Draft     IPsec Configuration Policy Model         March 2000



10.1. The Class DiffieHellmanGroup

   DiffieHellmanGroup describes the specific Diffie-Hellman Group that
   will be proposed.  It contains the following properties:

   NAME         groupDescription
   DESCRIPTION  Specifies the Diffie-Hellman Group to propose.
   TYPE         unsigned 16-bit integer
   VALUE        1 - 768-bit MODP group
                2 - 1024-bit MODP group
                3 - EC2N group on GP[2^155]
                4 - EC2N group on GP[2^185]
                5 - 1536-bit MODP group

   NAME         ExplicitGroupInfo
   DESCRIPTION  Specifies Diffie-Hellman Group information if
                groupDescription is not one of the well-known values or
                a previously agreed upon private group.  If
                groupDescription is one of the well-known values or a
                previously agreed upon private group, the NewGroupInfo
                object will not exist or it is ignored.

10.2. The Class NewGroupInfo

   NewGroupInfo is the abstract base class for the concrete new group
   information classes.  The specific derived class implies the group
   type value.

10.3. The Class NewMODPGroupInfo

   NewMODPGroupInfo specifies the Diffie-Hellman group information for
   a MODP group that is proposed during new group mode.  It contains
   the following properties:

   NAME         prime
   DESCRIPTION  Specifies the prime for the MODP group.
   TYPE         byte string

   NAME         generator
   DESCRIPTION  Specifies the generator for the MODP group.
   TYPE         byte string

10.4. The Class NewECGroupInfo

   NewECGroupInfo is an abstract class that specifies the Diffie-
   Hellman group information for an elliptic curve group that is
   proposed during new group mode.  It contains the following
   properties:

   NAME         polynomial
   DESCRIPTION  Specifies the polynomial for the elliptic curve group.
   TYPE         byte string

Jason                   Expires September 2000               [Page 27]


Internet Draft     IPsec Configuration Policy Model         March 2000



   NAME         fieldSize
   DESCRIPTION  Specifies the field size for the elliptic curve group.
   TYPE         unsigned 32-bit integer

   NAME         order
   DESCRIPTION  Specifies the order for the elliptic curve group.
   TYPE         unsigned 32-bit integer

   NAME         generatorOne
   DESCRIPTION  Specifies generator one for the elliptic curve group.
   TYPE         byte string

   NAME         generatorTwo
   DESCRIPTION  Specifies generator two for the elliptic curve group.
   TYPE         byte string

   NAME         curveA
   DESCRIPTION  Specifies curve A for the elliptic curve group.
   TYPE         byte string

   NAME         curveB
   DESCRIPTION  Specifies curve B for the elliptic curve group.
   TYPE         byte string

10.5. The Class NewEC2NGroupInfo

   NewEC2NGroupInfo is a class that represents a new EC2N group.  It
   contains no properties and exists only to imply the group type.

10.6. The Class NewECPGroupInfo

   NewECPGroupInfo is a class that represents a new ECP group.  It
   contains no properties and exists only to imply the group type.

11. Security Considerations

   This document describes a schema for IPsec policy.  It does not
   detail security requirements for storage or delivery of said schema.
   Storage and delivery security requirements should be detailed in a
   comprehensive security policy architecture document.

12. Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.


Jason                   Expires September 2000               [Page 28]


Internet Draft     IPsec Configuration Policy Model         March 2000


   Copies of claims of rights made available for publication and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

13. Acknowledgments

   The author would like to thank Mike Jeronimo, Ylian Saint-Hilaire,
   Vic Lortz, and William Dixon for their contributions to this IPsec
   policy model.

   Additionally, this draft would not have been possible without the
   preceding IPsec schema drafts.  For that, thanks go out to Rob
   Adams, Partha Bhattacharya, William Dixon, Roy Pereira, and Raju
   Rajan.

14. References

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

   [2] Shacham, A., and R. Monsour, R. Pereira, M. Thomas, "IP Payload
   Compression Protocol (IPComp)", RFC 2393, August 1998.

   [3] Kent, S., and R. Atkinson, "IP Encapsulating Security Payload
   (ESP)", RFC 2406, November 1998.

   [4] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402,
   November 1998.

   [5] Piper, D., "The Internet IP Security Domain of Interpretation
   for ISAKMP", RFC 2407, November 1998.

   [6] Wahl, M., and T. Howes, S. Kille, "Lightweight Directory Access
   Protocol (v3)", RFC 2251, December 1997.

   [7] Boyle, J., and R. Cohen, D. Durham, S. Herzog, R. Rajan, A.
   Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748,
   January 2000.  Internet-Draft work in progress.

   [8] Condell, M., and C. Lynn, J. Zao, "Security Policy Specification
   Language", draft-ietf-ipsec-spsl-01.txt, July 1999.  Internet-Draft
   work in progress.

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

Jason                   Expires September 2000               [Page 29]


Internet Draft     IPsec Configuration Policy Model         March 2000



15. Disclaimer

   The views and specification herein are those of the authors and are
   not necessarily those of their employer.  The authors and their
   employer specifically disclaim responsibility for any problems
   arising from correct or incorrect implementation or use of this
   specification.

16. Author's Address

   Jamie Jason
      Intel Corporation
      MS JF3-206
      2111 NE 25th Ave.
      Hillsboro, OR 97124
      Phone: +1-503-264-9531
      Fax: +1-503-264-9428
      E-Mail: jamie.jason@intel.com

17. Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it maybe copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other then
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THEINTERNET ENGINEERING
   TASK FORCE DISCLIAMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMAITON
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTEIS OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.







Jason                   Expires September 2000               [Page 30]