Subject: [Ietf-not43] draft-hall-ldap-whois-00.txt

From: [email-masked] (Eric A. Hall)
Date: Fri, 30 Nov 2001 22:27:44 -0600

Hi Stig,

Thanks for the detailed reading.

Stig Venaas wrote:

> 3.2.    Objectives
>         *   Distributed management. As part of the above, this document
>             also defines a delegated administrative model whereby data
>             that relates to a specific entity is managed and maintained
>             by that entity. A delegation body can provide delegation
>             data about a resource, while an operational body can
>             provide operational data about that resource, and the two
>             views are independently maintained as independent entries.
>             Moreover, organizations can leverage common security
>             mechanisms for the purpose of inter-organizational resource
>             management, such that a delegation entity can choose to
>             allow the operational entity to change the delegation data
>             independently, as required by the operational entity.
> 
> Sounds good, but can we really assume that all organizations that own
> domain names, will participate in this? Maybe registrars can provide
> necessary data on behalf of non-participating organizations?

The short answer to the question is: we don't assume the end-users will
operate their own servers, but we let them do so and provide ways to hook
into the data if it is known to be available.

There is an assumption that SOME organizations will want to manage entries
for the resources that they operate, but there is no assumption that
everybody will manage the resources they operate, and the bottom-up query
even has a disclaimer which says that most people probably will not do so.

> Using LDAP and server records, one could first look for server records
> in the relevant domain, and if non-existant look in the parent domain
> and so on; and require that each TLD has a service record.

The query-processing section defines different ways to do this.

The bottom-up model works as you describe the scenario above: queries
start at the leaf and work their way through the labels until they find a
server, and then follow any LDAP referrals that are received (the LDAP
referrals can redirect the client to servers outside the DNS hierarchy).

Conversely, the top-down model just starts at the TLD -- under the
assumption that a TLD has a server -- and then follows any LDAP referrals
that are received. This can take the client outside of the DNS hieararchy
to a registration server, or take the client to a user's server, or
whatever the referrals want.

> The server
> for the TLD could also have referrals to LDAP servers for delegated
> domain owners or provide the data directly for those domain owners that
> do not have their own LDAP service.

Yes, that's exactly what happens once a server is found.

>      DIT: dc=example,dc=com
>        +-cn=inetResources,dc=example,dc=com
>           +-cn=example.com,cn=inetResources,dc=example,dc=com

> I think I got this, but let me ask to make sure. The information
> for a given domain "labeln. ... .label2.label1." should always
> be located below
> dc=inetResources,dc=labeln,...,dc=label2,dc=label1
> right?

Every domain name that exists as a managed resource, yes.

> Should a DNS SRV record in the zone "labeln. ... .label2.label1."
> be required?

It depends on the query model in use. The default is for top-down queries
which always start at the TLD and then follow referrals. If the user wants
to run a server and provide information about leaf node objects then a
bottom-up query would start by looking for an SRV associated with the
named resource (and then start chopping off left-edge labels). As was
discussed above, this is not something we expect people to do anytime
soon, so it is not the default.

>   4.2.    The domainComponent LDAP hierarchy.
> 
> An organization that owns the domain "labeln. ... .label2.label1.",
> should in my opinion be authoritative for the DIT
> dc=inetResources,dc=labeln,...,dc=label2,dc=label1

Yes, that's the way it works, since "authority" comes from DNS itself. If
the protocol is followed, nobody can hijack a DIT for your domain name;
you have to give authority from within your DNS zone.

While all of the above is 100% accurate and true, it is also important to
reiterate that it will probably be irrelevant for most operations, since
most orgs probably will not be running DITs anytime soon, and therefore
most queries which are issued for leaf-nodes will fail to resolve at the
leaf-node level (they won't resovle until they get higher in the
delegation tree).

> And ideally a given DN should be universally unique. Agree?

All DNs include the DIT, and the DIT reflects the zone. So even though a
resource can exist in the namespace multiple times, each occurrance will
have a unique DIT and thus a unique DN.

EG, the entry for example.com. in the com. DIT is:

    cn=example.com,cn=inetResources,dc=com

while the entry for example.com. in the example.com. DIT is:

    cn=example.com,cn=inetResources,dc=example,dc=com

Different views on the same resource, with each view probably having
different data (but not necessarily).

> If an organization does not have an LDAP server of its own and
> does not buy LDAP services from someone else, should a registry
> then maintain contact data in some other LDAP server, and should
> the naming then be the same as if it was stored in a server that
> belongs to the organization?

The DN of the entry managed by the registry could be something like:

   cn=example.com,cn=inetResources,dc=uninett,dc=no

Which is different from what the operating or delegating entries would be
named. They can all exist, and they can all point to each other.

If a registrar chooses to do so, they can provide added-value by way of a
"managed DIT" service, perhaps providing an authenticated web form that
lets the user keep the database information updated, or which lets the
user add referrals to another DN, for example. This is all beyond the
spec, of course, but the multiple-view model allows for it and encourages
this kind of cooperative behavior.

> Why do you insist on using cn here? Because of buggy clients?

Actually, I didn't have time to think of something better. I thought about
this a little bit, and I would still like to use a more specific naming
attribute, but I didn't come up with anything better. There are a lot of
dependencies in the extensibleMatch filters, so its not something that can
be done without a fair amount of thought.

In the end, cn= was good enough for the first draft. Probably use
something like inetRes= or iR= in the second.

> I don't think one can assume everyone to have DNS SRV records, it
> would be useful to look up contacts when nameservers for the zone
> can not be reached, and it would slow down the performance. So, I'm
> a bit sceptic to this. The advantage I guess, is that the owner of
> the domain can switch to another server without updating referrals
> in servers administrated by others.

Again, much of this will depend on the query model in use.

But apart from that, these are also some of the reasons for using SRV. The
primary reason is that it encourages load distribution, so we are kind of
hoping that people will have multiple servers. Secondarily, the top-down
model puts the majority of the work on the delegation bodies, and they
REALLY SHOULD have multiple servers. So in that regard, using SRV with a
top-down query means that you have a really good chance of getting at
least a delegation answer, and if everything is operational then you will
get the same answers faster (no failover), plus you will get more answers
from the end-users servers too.

> IPv4 and IPv6 are mostly similar. Why don't you use a common object-
> class? The few attributes that are not common could either be optional
> or you can have different classes for 4 and 6 that both inherit a common
> inetIPNetwork class.

The search syntax is dramatically different. There are also issues with
delegations and specific attributes.

>         *   inetIpv6Network entries will likely benefit from
>             certificate-related data, although the extent and nature of
>             this information (minimum requirements, preferred
>             attributes, pre-existing schema, etcetera) is currently
>             unknown by the authors.
> 
> I think inetIPv4Network entries could benefit from that as well.
> Why are you thinking of IPv6 in particular? Because IPsec is mandated?

Yes. It probably makes sense to look at the same kind of attributes for
IPv4 networks.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: [email-masked] (Stig Venaas)
Date: Sat, 1 Dec 2001 10:27:04 +0100

>From you comments below, it seems I should read it even more

> into the data if it is known to be available.

Okay, I got that wrong, and it was the basis for some of my other
comments. I will read it again, especially the query-processing
section.

> named. They can all exist, and they can all point to each other.

Good, this is what I hoped for.

> something like inetRes= or iR= in the second.

Good

> delegations and specific attributes.

This is a minor nit (it really doesn't matter), but I still think it
could be good to take out the common part. Anyway, this really doesn't
matter, this is more implementation, the important thing now is the
framework of course.

Looks like we are well aligned. I'll read it again and give some
comments. I didn't read all the details, sorry about that.

Stig

---

From: [email-masked] (Andrew Newton)
Date: Mon, 3 Dec 2001 16:46:57 -0500

On Fri, Nov 30, 2001 at 08:45:08PM +0100, Stig Venaas wrote:
> 
>   14.4.   Open Issues 
>       
>      The following issues require additional analysis: 
>       

Just digging around, the following draft, 
draft-ietf-ipsp-config-policy-model-04.txt, would seem to define
the background needed to construct an LDAP schema for this.
In addition, draft-ietf-ipsec-vpn-policy-schema-00.txt would
also seem to apply, but it appears to have expired (does anyone
have it?).

On a related note, network entries might also benefit from this:
draft-ietf-policy-core-schema-13.txt

-andy

-- 
Andrew Newton
VeriSign Applied Research
[email-masked]

---

From: [email-masked] (Eric A. Hall)
Date: Tue, 04 Dec 2001 00:45:46 -0600

This is a multi-part message in MIME format.
--------------003DB5CCB782876EA3D47789
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> also seem to apply, but it appears to have expired (does anyone

found a copy, see attached

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
--------------003DB5CCB782876EA3D47789
Content-Type: text/plain; charset=iso-8859-1;
 name="draft-ietf-ipsec-policy-schema-00.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="draft-ietf-ipsec-policy-schema-00.txt"

   Internet Engineering Task Force                          Jamie Jason
   INTERNET DRAFT                                      Michael Jeronimo
   24 March 1999                                      Intel Corporation

                            IPsec Policy Schema
                   draft-ietf-ipsec-policy-schema-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 IPsec policy in
   order to facilitate agreement about the content and semantics of
   IPsec policy and to enable derivations of task-specific
   representations of IPsec policy such as storage schema, distribution
   representations, and policy specification languages.

Jason and Jeronimo                                            [Page 1]

Internet Draft           IPsec Policy Schema               April 1999

Table of Contents

   Status of this Memo................................................1
   Abstract...........................................................1
   Table of Contents..................................................2
   1. Introduction....................................................3
   2. Overview of the classes.........................................3
   2.1 Endpoint.......................................................3
   2.2 Protocol.......................................................4
   2.3 Condition......................................................4
   2.4 Action.........................................................4
   2.5 Rule...........................................................4
   2.6 Policy.........................................................4
   3. Class Hierarchy.................................................5
   4. Class Diagram...................................................5
   5. Class Definitions...............................................7
   5.1 Unique Objects.................................................7
   5.2 Endpoints......................................................7
   5.3 Protocols......................................................9
   5.4 Conditions.....................................................9
   5.5 IKE Actions...................................................10
   5.6 IPsec Actions.................................................10
   5.7 Rules.........................................................11
   5.8 Policies......................................................11
   6. Security Considerations........................................12
   7. Intellectual Property..........................................12
   8. Acknowledgments................................................12
   9. References.....................................................12
   10. Disclaimer....................................................13
   11. Authors' Address..............................................13

Jason and Jeronimo      Expires November 1999                [Page 2]

Internet Draft           IPsec Policy Schema               April 1999

1. Introduction

   IPsec policy may assume a variety of forms as it travels from
   storage to distribution point to decision point.  At each step, it
   may be represented in a way convenient for the current task.  For
   example, the policy could exist as an LDAP schema in a directory, or
   as an on-the-wire representation over a transport protocol, or in a
   text-based policy specification language suitable for editing by an
   administrator.  Each of these task-specific representations should
   be derived from a canonical representation that exactly specifies
   the content and semantics of IPsec policy.  The purpose of this
   document is to abstract IPsec policy into a task-independent
   representation.  The document is organized as follows:

   o Section 2 provides an informal description of the classes defined
     in the IPsec policy schema to give a framework for understanding
     subsequent sections.

   o Section 3 lists the IPsec policy schema class hierarchy,
     displaying the derived-from relationships contained in the schema.

   o Section 4 presents a detailed class diagram for the IPsec policy
     schema.  This view shows the static relationship between the
     various classes in the schema.

   o Section 5 informally describes the semantics of each of the
     classes in the policy schema.

2. Overview of the classes

   The IPsec policy schema is a model for IPsec policy that provides
   the structure to express when IPsec is to be applied and what
   specific IPsec settings are to be used.  This section will give an
   informal description for each of the classes in the IPsec policy
   schema and describe their relationships.

   When modeling IPsec policy, it is appropriate to answer the
   following questions:

   o WHO is sending/receiving the traffic?
   o WHAT are they sending/receiving?
   o WHEN should traffic be protected?
   o HOW should the traffic be treated?

2.1 Endpoint

   An Endpoint is meant to model a single communication endpoint - in
   other words, a sender or receiver of IP traffic.  An endpoint should
   not be confused with a single host - while a single host is a type
   of endpoint, an endpoint is not necessarily a single host.  An
   endpoint is an abstraction upon which concrete specializations are

Jason and Jeronimo      Expires November 1999                [Page 3]

Internet Draft           IPsec Policy Schema               April 1999

   derived.  The endpoint answers the first question above - who is
   sending/receiving data.

2.2 Protocol

   A Protocol is a specification that characterizes the type of
   traffic.  As with the endpoint, a protocol is an abstraction upon
   which are derived concrete specializations that specify protocol and
   possibly ports.  The Protocol class is used to separate out the
   communication protocol that an endpoint is using from the endpoint
   itself.  The protocol answers the second question above - what is
   being sent/received.

2.3 Condition

   A condition element is a condition type (endpoints and protocols are
   examples of condition types) along with its associated value.

   A condition is defined as a predicate that is evaluated against the
   information provided to determine if there is a match (in other
   words, a true evaluation).  The predicate is a logical expression of
   one or more condition elements, combined using binary logical
   operators (AND, OR), and possibly grouped using precedence operators
   (parentheses).  Any part of a condition can be further modified
   using a unary negation (NOT) operator. The condition answers the
   third question - when should traffic be protected.

2.4 Action

   An Action is a group of Network Service-specific settings (in our
   example, IPsec) that are to be enforced when its related Condition
   evaluates to true.  The Action answers the fourth question - how
   should the traffic be treated.

2.5 Rule

   A Rule is an ordered sequence Conditions, ideally mutually
   exclusive, paired with a  set of Actions.  The Conditions are
   evaluated in order until either the sequence is exhausted or a
   condition evaluates to TRUE.  If a condition evaluates to TRUE, then
   the corresponding Actions are performed.

2.6 Policy

   A policy is an ordered sequence of rules defined to achieve a
   specific purpose û for example, one policy might be appropriate for
   a server while another policy contains rules more appropriate for a
   client.

Jason and Jeronimo      Expires November 1999                [Page 4]

Internet Draft           IPsec Policy Schema               April 1999

3. Class Hierarchy

   The following illustrates the class hierarchy for the IPsec policy
   classes.

      Top
       |
       +---Policy
       +---Rule
       +---Condition
       +---ConditionElement
       |       |
       |       +---EndPoint
       |       |       |
       |       |       +---IPv4
       |       |       +---IPv4Range
       |       |       +---IPv4Subnet
       |       |       +---IPv6
       |       |       +---IPv6Range
       |       |       +---IPv6Subnet
       |       |       +---FQDN
       |       |       +---EndpointGroup
       |       +---Protocol
       |               |
       |               +---GenericProtocol
       |               +---TCPProtocol
       |               +---UDPProtocol
       |               +---ProtocolGroup
       +---Action
       |       |
       |       +---IKEAction
       |       +---IPsecAction
       |               |
       |               +---IPsecTransportAction
       |               +---IPsecTunnelAction
       +---IKEProposal
       +---IPsecProposal

4. Class Diagram

   The following is a high-level representation of policy.  A Unified
   Modeling Language (UML) class diagram is used to represent the
   objects.

   In the following class diagram:

   o  Each box represent class with the class name provided.
   o  Class names in brackets ([]) denotes a virtual class.
   o  A line terminated by a "o" represents aggregation.  For example,
      a Policy contains 1 to n rules and a Rule may be contained in 0
      to n policies.  In aggregation, the class being aggregated has a
      lifetime that is independent of the class that contains it.

Jason and Jeronimo      Expires November 1999                [Page 5]

Internet Draft           IPsec Policy Schema               April 1999

   o  A line terminated by an asterisk (*) represents composition.  For
      example, a Condition contains 1 to n Condition Elements and a
      Condition Element is contained in one and only one Condition.
      Composition differs from aggregation in that a contained object
      only exists as long as the containing object.
   o  A line terminated by a arrow (^, <, or >), denotes inheritance,
      with the arrow pointing to the parent class.

                            +-----------+
                            |           |
                            |  Policy   |
                            |           |
                            +-----+-----+
                                  o 0..n
                                  |
                                  | 1..n
          +-----------+     +-----+-----+     +-----------+
          |           |1..n |           |0..n |           |
          | Condition +----o|   Rule    |o----|  [Action] |
          |           | 1..1|           | 1..n|           |
          +-----+-----+     +-----------+     +-----------+
                * 1..1                              ^
                |                                   |
                | 1..n                +-------------+
          +-----+-----+         +-----+-----+ +-----+-----+
          |[Condition |         |           | |           |
          |  Element] |         |    IKE    | |  [IPsec   |<--+
          +-----------+         |   Action  | |  Action]  |   |
                ^               +-----------+ +-----------+   |
                |                     * 1..1        * 1..1    |
         +------+------+              |             |         |
         |             |              | 1..n        | 1..n    |
   +-----+-----+ +-----+-----+  +-----+-----+ +-----+-----+   |
   |           | |           |  |           | |           |   |
   |[Endpoint] | |[Protocol] |  |   IPsec   | |   IPsec   |   |
   |           | |           |  |  Proposal | |  Proposal |   |
   +-----------+ +-----------+  +-----------+ +-----------+   |
         | 2                                                  |
         |                                                    |
         |                                      +-------------+
         |                                      |             |
         |                                +-----+-----+ +-----+-----+
         |                                |   IPsec   | |   IPsec   |
         |                                | Transport | |   Tunnel  |
         |                                |  Action   | |   Action  |
         |                                +-----------+ +-----+-----+
         |                                                    | 1..1
         |                                                    |
         +----------------------------------------------------+

Jason and Jeronimo      Expires November 1999                [Page 6]

Internet Draft           IPsec Policy Schema               April 1999

5. Class Definitions

5.1 Unique Objects

   Something that is not conveyed in the preceeding class diagram is
   the notion of a unique object.  A unique object is an object that is
   used as a building block in the policy system.  Unique objects can
   exist independently of all other objects.  Each unique object has
   associated with it a universally unique identifier (UUID).  This
   UUID lives with the object for the existence of the object.  In
   addition to a UUID, a unique object also has associated with it a
   more user-friendly display name.  The following objects are unique
   objects in our system:

   o  Policies
   o  Rules
   o  Conditions
   o  Actions (IKE, IPSEC Transport, and IPSEC Tunnel)
   o  Endpoint Groups (described later)
   o  Protocol Groups (described later)

5.2 Endpoints

   An Endpoint identifies a sender or receiver of IP traffic.  An
   endpoint condition element can be specialized to be one of the
   following types:

   o  IPv4 Address
   o  IPv4 Address Range
   o  IPv4 Subnet/Mask
   o  IPv6 Address
   o  IPv6 Address Range
   o  IPv6 Subnet/Mask
   o  Fully Qualified Domain Name (FQDN)
   o  Endpoint Group

   The following is the class diagram for an endpoint.

                   +---------------------+
                   * 1..1            1..n|
             +-----+-----+         +-----+-----+         +-----------+
             |           |         |           |         |           |
             |  Endpoint +-------->+ [Endpoint]|<--------+   FQDN    |
             |   Group   |         |           |         |           |
             +-----------+         +-----------+         +-----------+
                                         ^
             +-----------+               |               +-----------+
             |           |               |               |           |
             |    IPv4   +---------------+---------------+    IPv6   |
             |  Address  |               |               |  Address  |
             +-----------+               |               +-----------+
                                         |
                                         |

Jason and Jeronimo      Expires November 1999                [Page 7]

Internet Draft           IPsec Policy Schema               April 1999

             +-----------+               |               +-----------+
             |    IPv4   |               |               |    Ipv6   |
             |  Address  +---------------+---------------+  Address  |
             |   Range   |               |               |   Range   |
             +-----------+               |               +-----------+
                                         |
             +-----------+               |               +-----------+
             |    IPv4   |               |               |    Ipv6   |
             |  Subnet/  +---------------+---------------+  Subnet/  |
             |    Mask   |                               |    Mask   |
             +-----------+                               +-----------+

   The only endpoint specialization that may require explanation is the
   endpoint group.  An endpoint group is a named, ordered sequence of
   (possibly) heterogeneous endpoints.  Endpoint groups are used to
   group together endpoints which are to be treated the same.  For
   example, there may exist an endpoint group named "Marketing" that
   contains the FQDNs of the systems in the Marketing department.

   Since an endpoint group is a unique object, a condition only
   contains a reference to it.  This makes it possible to have the same
   endpoint group appear in multiple conditions without duplication of
   the entire group.  More importantly, changes to an endpoint group
   are automatically reflected in the condition(s) in which it is
   referenced.  For example, say that a new machine in the Marketing
   department is added to the network.  By adding the system to the
   "Marketing" endpoint group, the system will be provided the same
   IPsec services as the other Marketing systems.

   Note that in the above class diagram an endpoint group not only
   contains endpoint objects, but also derives from an endpoint (in
   Design Pattern nomenclature, this is a Composite pattern).  The net
   result is that an endpoint group may contain one or more endpoint
   groups.  The only restriction is that circular references are not
   allowed - for example, an endpoint group may not contain a reference
   to itself or by following its endpoint group references recursively
   may not find a reference to itself.

Jason and Jeronimo      Expires November 1999                [Page 8]

Internet Draft           IPsec Policy Schema               April 1999

5.3 Protocols

   A protocol object is used to specify the information about what two
   communicating host are "saying" to each other.  This information
   includes the IP protocol and in the case of UDP or TCP, the source
   and destination port ranges.  The following is a class diagram for a
   protocol.

                                   +-----------+
                               1..n| [Protocol]|
                   +---------------+           |
                   |               +-----------+
               1..1*                     ^
             +-----------+               |               +-----------+
             |  Protocol +---------------+---------------+    UDP    |
             |   Group   |               |               |  Protocol |
             +-----------+               |               +-----------+
                                         |
             +-----------+               |               +-----------+
             |  Generic  +---------------+---------------+    TCP    |
             |  Protocol |                               |  Protocol |
             +-----------+                               +-----------+

   It would be simple enough to have only one class that covers all
   protocols, however a non-UDP/TCP protocol does not need the port
   fields.  As with endpoints, there is a named, ordered sequence of
   protocols - protocol groups.

   Since a protocol group is a unique object, it exhibits the same
   properties as an endpoint group.  For example, assume there is a
   protocol group named "Essential Services".  If it is later
   determined that another protocol needs to be added to "Essential
   Services", this can be done by modifying the "Essential Services"
   protocol group instead of modifying all conditions which reference
   the protocol group.

   A protocol group, like an endpoint group, is restricted by the
   "circular reference" limitation.

5.4 Conditions

   In the case of IPSEC, we chose to simplify the condition to contain
   the following three components:

   o  a source endpoint group, SourceGroup
   o  a destination endpoint group, DestinationGroup
   o  a protocol group, ProtocolGroup

   The condition would be specified as:

   IF (SourceGroup AND DestinationGroup AND ProtocolGroup)

   In English, the condition could be phrased as:

Jason and Jeronimo      Expires November 1999                [Page 9]

Internet Draft           IPsec Policy Schema               April 1999

   "When communicating from SourceGroup to DestinationGroup using
        ProtocolGroup"

   It is also important to note that even though this was designed in
   the context of IPsec, the Condition is actually domain-independent.
   That is, the same Condition used to specify an IPsec Action could
   also be used for other domains such as Bandwidth and Access.
   However, this should not be taken to mean that Conditions may only
   contain domain-independent Condition Elements.  If appropriate, a
   Condition may contain domain-dependent Condition Elements.  For
   example, if we cared about CPU utilization and wanted to restrict a
   host to using 3-DES for only 5 active streams, a Condition Element
   that states this could be used.
   While we restricted ourselves to the traditional 5-tuple, there is
   nothing that restricts the use of other condition elements (for
   example, time-of-day).

5.5 IKE Actions

   An IKE Action contains the information necessary to perform the IKE
   Phase 1 negotiation:

   o  the IKE mode (main or aggressive)
   o  the SA kilobyte lifetime
   o  the SA seconds lifetime
   o  the credential type expected/provided (for example, preshared
      key)
   o  if the credential type is preshared key, the preshared key
   o  an ordered sequence of IKE proposals

   Each IKE proposal contains the following information:

   o  an ordered sequence of authentication methods
   o  an ordered sequence of encryption algorithms
   o  an ordered sequence of hash algorithms
   o  a Diffie-Hellman group

5.6 IPsec Actions

   An IPsecAction is an abstract class that contains settings that are
   common to both transport and tunnel actions:

   o  whether or not to employ IPsec replay detection
   o  the SA kilobyte lifetime
   o  the SA seconds lifetime
   o  the Diffie-Hellman group
   o  an ordered list of IPsec proposals

Jason and Jeronimo      Expires November 1999               [Page 10]

Internet Draft           IPsec Policy Schema               April 1999

   An IPsecTransportAction does not further specialize the IPsecAction.
   The IPsecTunnelAction adds the following:

   o  the local gateway - an IPv4/6 or FQDN endpoint
   o  the remote gateway - an IPv4/6 or FQDN endpoint

   Each IPsec proposal contains the following information:

   o  an ordered sequence of AH authentication algorithms
   o  an ordered sequence of ESP encryption algorithms
   o  an ordered sequence of ESP authentication algorithms

   Although not in the policy class diagram, there are also two more
   IPsec transport actions:

   o  IPsecPermitAction - allows traffic to be sent/received in the
      clear
   o  IPsecDenyAction - causes traffic that matches the parameters to
      be dropped

5.7 Rules

   As stated earlier, a rule is an ordered sequence of Conditions
   paired with a set of Actions:

   IF (Condition OR Condition ...) THEN (Action AND Action ...)

   For simplification, our system restricts a rule to being a
   condition/action pair.  This unfortunately does sometimes require
   duplication (of which we tried to avoid at all cost).  For example,
   assume host S is talking to host D and it is desirable to not only
   have end-to-end security, but also to use an encrypted tunnel
   between the two sites.  In our model, two rules will need to be
   specified - one for transport mode and one for tunnel mode (we will
   discuss later the evaluation process to make sure that tunnel mode
   rules are acted upon first).

   A rule is a unique object in the system and as such, may appear in
   more than one policy.  Updates to a rule are automatically reflected
   in the affected policies.

5.8 Policies
   In our system, a policy is a named, ordered sequence of rules.  The
   ordering of the rules within a policy is beyond the scope of this
   draft.  The rules in the policy are evaluated sequentially until
   either one of the rules evaluates to true or the sequence is
   exhausted.  On a host, there may be several policies, however, at
   any given time only one policy may be tagged as the active policy
   (in other words, the one that is consulted when a decision is to be
   made).

Jason and Jeronimo      Expires November 1999               [Page 11]

Internet Draft           IPsec Policy Schema               April 1999

6. Security Considerations

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

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

   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.

8. Acknowledgments

   The authors would like to thank Baiju Patel, Ganesh Krishnan, and
   Ylian Saint-Hilaire for their discussions and contributions to this
   policy model.  We would also like to thank Allison Angus for her
   efforts in user-interface design and usability feedback.

9. References

   [1]  J. Strassner and E. Ellesson, ôTerminology for describing
   network policy and servicesö, draft-strassner-policy-terms-01.txt,
   February 1999.

   [2]  J. Strassner, E. Ellesson, B. Moore, ôPolicy Framework Core
   Information Modelö, draft-ietf-policy-core-schema-02.txt, February
   1999.

   [3]  R. Pereira, P. Bhattacharya, ôIPsec Policy Data Modelö, draft-
   ietf-ipsec-policy-model-00.txt, February 1998.

Jason and Jeronimo      Expires November 1999               [Page 12]

Internet Draft           IPsec Policy Schema               April 1999

   [4]  P. Bhattacharya, R. Adams, W. Dixon, R. Pereira, R. Rajan, ôAn
   LDAP Schema for Configuration and Administration of IPsec based
   Virtual Private Networks (VPNs)ö, draft-ietf-ipsec-vpn-policy-
   schema-00.txt, October 1998.

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

11. Authors' 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: [email-masked]

   Michael Jeronimo
      Intel Corporation
      MS JF3-206
      2111 NE 25th Ave.
      Hillsboro, OR 97124
      Phone: +1-503-264-5970
      Fax: +1-503-264-9428
      E-Mail: [email-masked]

Jason and Jeronimo      Expires November 1999               [Page 13]


--------------003DB5CCB782876EA3D47789--

---

From: [email-masked] (Eric A. Hall)
Date: Tue, 04 Dec 2001 00:47:55 -0600

> > In addition, draft-ietf-ipsec-vpn-policy-schema-00.txt would
                                  ^^^

>                    draft-ietf-ipsec-policy-schema-00.txt

                                           ???

Ack, lied to by google

---

From: [email-masked] (Stig Venaas)
Date: Tue, 4 Dec 2001 17:58:44 +0100

> >                    draft-ietf-ipsec-policy-schema-00.txt

The draft can be found at
ftp://ftp.venaas.no/pub/internet-drafts/old/draft-ietf-ipsec-vpn-policy-schema-00.txt

Stig