From ???@??? Thu May 13 17:21:13 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id RAA10653
        for <paul.hoffman@vpnc.org>; Thu, 13 May 1999 17:11:55 -0700 (PDT)
Received: from relay.gw.tislabs.com [192.94.214.100] by mail.timestep.com [209.
47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Thu, 13 M
ay 1999 20:01:08 -0400
Received: by relay.gw.tislabs.com; id UAA03242; Thu, 13 May 1999 20:13:02 -0400
 (EDT)
Received: from clipper.gw.tislabs.com(10.33.1.2) by relay.gw.tislabs.com via sm
ap (4.1)
        id xma003218; Thu, 13 May 99 20:12:32 -0400
Received: from balenson.gw.tislabs.com (balenson.gw.tislabs.com [10.33.80.11])
        by clipper.gw.tislabs.com (8.9.1/8.9.1) with SMTP id TAA11651;
        Thu, 13 May 1999 19:57:16 -0400 (EDT)
Message-ID: <MDAEMON-F199905132001.AA010846MD16712@mail.timestep.com>
X-Sender: balenson@pop.gw.tislabs.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Date: Thu, 13 May 1999 19:56:57 -0400
To: rpereira@TimeStep.com, lsanchez@bbn.com
From: "David M. Balenson" <balenson@tislabs.com>
Subject: RE: test
Cc: ipsec-policy@mail.timestep.com
In-Reply-To: <MDAEMON-F199903261605.AA055598MD06716@mail.timestep.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: balenson@tislabs.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 46426f0cdfce394b6950d169b19a74f4

At 04:05 PM 3/26/99 -0500, Roy Pereira wrote:
>As for lack of content, Luis and I will be posting the proposed charter very
>soon.

Roy, Luis-

How are you guys making out with the IPSP proposed charter??

Thanks,

-DB


----------------------------------------David M. Balenson, Cryptographic Techno
logies Group
NAI Labs, The Security Research Division of Network Associates, Inc.
3060 Washington Road, Glenwood, MD 21738  USA
David_Balenson@nai.com; 443_259.2358; fax 301_854.4731
PGP fingerprint FD53 918E 097A 2579 C1A8 34F8 E05D E74F AC1D E184




From ???@??? Fri May 14 14:37:00 1999
Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15])
        by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id NAA12657
        for <paul.hoffman@vpnc.org>; Fri, 14 May 1999 13:11:14 -0700 (PDT)
Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i
d <55637-17937>; Fri, 14 May 1999 16:12:31 -0400
Received: from ganymede.or.intel.com [134.134.248.3] by mail.timestep.com [209.
47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Fri, 14 M
ay 1999 16:00:13 -0400
Received: from orsmsx29.jf.intel.com (orsmsx29.jf.intel.com [192.168.65.29])
        by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24
22:10:56 iwep Exp iwep $) with ESMTP id TAA28370;
        Fri, 14 May 1999 19:58:59 GMT
Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2448.0)
        id <KJQ8MSLY>; Fri, 14 May 1999 12:58:59 -0700
Message-ID: <MDAEMON-F199905141600.AA001339MD17089@mail.timestep.com>
From: "Jason, Jamie" <jamie.jason@intel.com>
To: "'Ricky Charlet'" <rcharlet@redcreek.com>,
        ".MailList, ipsec" <ipsec@lists.tislabs.com>,
        "Jeronimo, Michael" <michael.jeronimo@intel.com>,
        ipsec-policy@mail.timestep.com
Subject: RE: draft-ietf-ipsec-policy-schema-00.txt
Date: Fri, 14 May 1999 15:58:57 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: jamie.jason@intel.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: eafa2babc0ef85de1048d57d7aa0afa8

> Architectural Question:
>       Where should "action" fit into the class hierarchy? My expectation
is
> that the general IETF Policy WG (different from the IPSec Policy WG)
> will be forming a generalized condition <-> action schema. Under that,
> IPSec would fit in as a particular instantiation of an
> action.

Agreed.  It is our expectation that the policy WG will develop the core
schema necessary.  Other working groups would deveolop domain-dependent
conditions and actions as necessary.  In our particular schema, we don't
have any domain specific conditions, but obviously we have domain-specific
actions.

> Have you thought about merging your polices, rules, and conditions
> work into the policy working group and then forming a draft to detail out
an
> instantiation of a particular (IPSec) policy action.

That is the direction we would like to see this go.  The reason for our
presenation at Minneapolis IETF and this draft is to stimulate discussion
about policy in general as well as policy for IPSEC.  It is our belief that
what you state is what will eventually transpire.

>       What an IPSec proposal contains seems to have left out
> compression...oversight?

Yes.  Our particular work didn't include compression, but to be complete it
should indeed include compression.

> In your draft you seem to imply that the absence of a Permit
> or Deny means Secure.

At this time, we have 4 unique IPSEC actions: (1) deny (or block), (2)
permit (or bypass), (3) tunnel action, or (4) transport action.  I agree
that there may be some ambiguity with the terms (as you may be able to tell,
my first experience in the industry was with firewalls) and will make a note
of it.  In our current system, there is a requirement that there be an
action object associated with the condition - so the absence of a permit or
deny action means that there is a transport or tunnel action (i.e., secure
action).  We could have been clearer about it, but if I were to draw the
permit and deny actions in the class diagram, they would derive from the
IPSecAction (in other words, peers to the secure actions).  I will make a
note for the next rev of the draft.

Jamie



From ???@??? Mon Jun 07 09:02:55 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id EAA02269
        for <paul.hoffman@vpnc.org>; Mon, 7 Jun 1999 04:45:46 -0700 (PDT)
Received: from wolfe.bbn.com [128.89.2.232] by mail.timestep.com [209.47.58.12]
 with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Mon, 07 Jun 1999 0
7:35:42 -0400
Received: (from mcondell@localhost)
        by wolfe.bbn.com (8.8.8/8.8.6) id HAA22396;
        Mon, 7 Jun 1999 07:34:32 -0400 (EDT)
Date: Mon, 7 Jun 1999 07:34:32 -0400 (EDT)
Message-ID: <MDAEMON-F199906070735.AA354227MD18222@mail.timestep.com>
From: Matthew Condell <mcondell@bbn.com>
To: ipsec-policy@mail.timestep.com
Subject: Proposed IPSP Charter
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: mcondell@bbn.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: c35ff30f50980e57c98dd76631789556


[Sent for Luis]

Here is a proposed charter for the IPsec Policy WG. Comments,
suggestions and flames are welcome.

Luis



Description of Working Group
----------------------------

The rapid growth of the Internet and the need to control access to
network resources (bandwidth, routers, hosts, etc.) has quickly
generated the need for representing, discovering, exchanging and
managing the policies that control access to these resources in a
scalable, secured and reliable fashion.

Current IP security protocols and algorithms [RFCs 2401-2412, 2085,
2104 and 2451] can exchange keying material using IKE [RFC2409] and
protect data flows using the AH [RFC2402] and/or ESP protocols
[RFC2406]. The scope of IKE limits the protocol to the authenticated
exchange of keying material and associated policy information between
the end-points of a security association.

However, along the path of a communication, there may be
administrative entities that need to impose policy constraints on
entities such as security gateways and router filters.  There also is
a need for end-points of a security association and/or, for their
respective administrative entities, to securely discover and negotiate
access control information for the end hosts and for the policy
enforcement points (security gateways, routers, etc.) along the path
of the communication. Finally, there also is a need for establishing
security associations efficiently (i.e., minimize public-key
operations, payload exchanges, round-trips, etc.) across multiple
intermediaries to support iterated tunneling.

To address these problems the IPSP Working Group will:

        1) Specify a data model for supporting IP security policies,

        2) adopt an extensible IPsec policy specification language,

        3) adopt or develop a policy exchange and negotiation
           protocol. The protocol must be capable of discovering,
           distributing and resolving policy conflicts in both
           intra/inter domain environments. The protocol must be
           independent of any security protocol suite and key
           management protocol,

        4) provide guidelines for secure storage and handling of
           security policies, and;

        5) develop IKE extensions to support efficient SA
           establishment for iterated tunneling.


The proposed work item for this group would yield standards that are
compatible with the existing IPsec architecture [RFC 2401] and IKE
[RFC 2409], complementing the standards work achieved by the IPsec
Working Group. The data model, specification language and exchange
protocol will evolve from some of the work previously published in the
following documents:

        draft-ietf-ipsec-policy-model-00.txt
        draft-ietf-ipsec-vpn-policy-schema-00.txt
        draft-ietf-ipsec-spsl-00.txt
        draft-ietf-ipsec-sps-00.txt
        draft-ietf-ipsec-secconf-00.txt

This group will look at existing IETF standard work in the area of
policy distribution. In particular, the group will look at the
possibility of using/enhancing existing intra-domain policy
distribution protocols such as the one developed in the RAP WG, if
feasible.  This group will also coordinate with other IETF working
groups working on specifying policies and policies schemas in order to
maintain compatibility and interoperability. In particular, this
working group will work closely with the Policy Framework WG to ensure
that the IPsec data model fits and can be supported within the general
Policy Framework.



From ???@??? Mon Jun 07 15:15:10 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id NAA03006
        for <paul.hoffman@vpnc.org>; Mon, 7 Jun 1999 13:41:17 -0700 (PDT)
Received: from adk.gr [158.130.6.141] by mail.timestep.com [209.47.58.12] with
SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Mon, 07 Jun 1999 16:31:1
0 -0400
Received: from dsl.cis.upenn.edu (localhost [127.0.0.1])
        by adk.gr (8.9.3/8.9.1) with ESMTP id QAA20548
        for <ipsec-policy@mail.timestep.com>; Mon, 7 Jun 1999 16:30:20 -0400 (E
DT)
Message-ID: <MDAEMON-F199906071631.AA311071MD19024@mail.timestep.com>
To: ipsec-policy@mail.timestep.com
Subject: Re: Proposed Charter
Date: Mon, 07 Jun 1999 16:30:20 -0400
From: "Angelos D. Keromytis" <angelos@dsl.cis.upenn.edu>
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: angelos@dsl.cis.upenn.edu
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 543a6fca7bae36f6b4a2c9397c5fa510

-----BEGIN PGP SIGNED MESSAGE-----

To: ipsec-policy@mail.timestep.com
Subject: Re: Proposed Charter
Cc:
Date: 06/07/99, 16:30:18


I think the proposed charter is too ambitious, unless we really want
to have an IPsec-WG-like saga again. A data model and a policy
handling mechanism is clearly needed, along with a method of
discovering security endpoints/gateways. That should be enough for a
first pass, IMNSHO.
- -Angelos

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQEVAwUBN1wr23crsxJuc7vBAQHc6Af/Qfl6SiNGjkk1k79pplaVw20h1E5CM1dF
lt685QksVM6p/rEQ9oHr5x0IE7pujLSbIO+vO6LNtdwzSOVmW1GHdvoMS6JSDfgh
mAzMJxe1jBXU6Tv5rRdJHYDi8HblopKugnV7dDmnfhm2XkogB8iMcHUJdSuarxSh
mYeAV3je8xNAco/MeD4tICkjr7nF2GB0oqErWQJnU0Kj3fzhajrgOsoMqj2JhyFE
jlE7FbfK/P7wE3AzJ5PL7dGfniSEyGEIsWM5gEDM1TePMOYIHFG4WKdFrJXPqkX4
UWSn6kR7CYWdNu0QUg+Eb3a4fBO8TXyg2mxdRJ6Uh2VRk3BpCBIttw==
=PiNI
-----END PGP SIGNATURE-----



From ???@??? Mon Jun 07 15:15:10 1999
Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15])
        by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id OAA03078
        for <paul.hoffman@vpnc.org>; Mon, 7 Jun 1999 14:47:24 -0700 (PDT)
Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i
d <49968-7112>; Mon, 7 Jun 1999 17:50:42 -0400
Received: from thalia.fm.intel.com [132.233.247.11] by mail.timestep.com [209.4
7.58.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Mon, 07 Ju
n 1999 17:39:09 -0400
Received: from fmsmsx29.FM.INTEL.COM (fmsmsx29.fm.intel.com [132.233.42.29])
        by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22
:10:56 iwep Exp iwep $) with ESMTP id OAA09615
        for <ipsec-policy@mail.timestep.com>; Mon, 7 Jun 1999 14:38:00 -0700 (P
DT)
Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2448.0)
        id <M1XM0XL4>; Mon, 7 Jun 1999 14:37:59 -0700
Message-ID: <MDAEMON-F199906071739.AA390966MD19403@mail.timestep.com>
From: "Jeronimo, Michael" <michael.jeronimo@intel.com>
To: ipsec-policy@mail.timestep.com
Subject: RE: Proposed IPSP Charter
Date: Mon, 7 Jun 1999 17:37:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: michael.jeronimo@intel.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 5508a16163a96bdc804eef0703470682

I suggest first defining the IPsec policy data model in the abstract,
then deriving from that the representations for specification (policy
specification language), storage (LDAP schema), and distribution (COPS).

I think that policy negotiation (assuming I'm even willing to adjust
my policy given information about another's policy) is separate from
policy distribution.

As for the rest of #3, I'm not clear on:

           "The protocol must be capable of discovering,
           distributing and resolving policy conflicts in both
           intra/inter domain environments."

Does this mean
        discovering conflicts
        distributing conflicts
        resolving conflicts
or
        discovering policy servers
        distributing policy
        resolving policy conflicts
or
        discovering policy conflicts
        distributing policy
        resolving policy conflicts

-Mike



From ???@??? Tue Jun 08 08:38:39 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id HAA05176
        for <paul.hoffman@vpnc.org>; Tue, 8 Jun 1999 07:20:14 -0700 (PDT)
Received: from wolfe.bbn.com [128.89.2.232] by mail.timestep.com [209.47.58.12]
 with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Tue, 08 Jun 1999 1
0:09:52 -0400
Received: (from mcondell@localhost)
        by wolfe.bbn.com (8.8.8/8.8.6) id KAA02800;
        Tue, 8 Jun 1999 10:08:48 -0400 (EDT)
Date: Tue, 8 Jun 1999 10:08:48 -0400 (EDT)
Message-ID: <MDAEMON-F199906081009.AA095234MD19782@mail.timestep.com>
From: Matthew Condell <mcondell@bbn.com>
To: ipsec-policy@mail.timestep.com
Subject: RE: Proposed IPSP Charter
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: mcondell@bbn.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 773c2b03f1238f9c38d087fce3286cbf


Michael Jeronimo said:
>I suggest first defining the IPsec policy data model in the abstract,
>then deriving from that the representations for specification (policy
>specification language), storage (LDAP schema), and distribution (COPS).

I have a question about using COPS as the distrubution method. As I
read COPS, it seems well designed for intra-domain policy distribution
but does not seem to have the server discovery, server-to-server
communication, enforcement point signalling, and policy negotiation
mechanisms needed to support inter-domain policy negotiation.

>I think that policy negotiation (assuming I'm even willing to adjust
>my policy given information about another's policy) is separate from
>policy distribution.

Policy negotiation isn't about adjusting your policy, it's about
determining where your policy overlaps another policy and determining
if that overlap will allow or deny a communication and what
security services that overlap allows.

It also includes a more complicated resolution process since the
communication that will be passing though an enforcement point
may not be the same as the policy requested.  For example, two
hosts H1 and H2 would like to commuicate on port 79, so H1 needs
to negotiate the policies for this communication.  If, for example,
H2 requires ESP to be used for the communication (and H1's policy
allows it), the policy negotiated with a gateway GW1 between
H1 and H2, not only has to include whether or not H1 and H2 can
be allowed to communicate on port 79, but whether or not they
can use ESP.  This becomes even more complex when there are more
nested gateways.

It may be possible to separate this processing from the distribution
of the policies.  My initial feeling is that doing so would
increase the processing required for the negotiation since every
entitity involved would have to do it.  However, it would probably
be useful to investigate the pros and cons of separating the
processing and distribution and keeping them together as is
proposed in draft-ietf-ipsec-sps-00.txt

>As for the rest of #3, I'm not clear on:
>
>           "The protocol must be capable of discovering,
>           distributing and resolving policy conflicts in both
>           intra/inter domain environments."
>
>Does this mean
[...]
>       discovering policy servers
discovering policy and policy servers
>       distributing policy
>       resolving policy conflicts

I think this is what was meant.

Matt Condell
BBN Technologies
(speaking for himself this time.)


From ???@??? Tue Jun 08 11:57:11 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id LAA05415
        for <paul.hoffman@vpnc.org>; Tue, 8 Jun 1999 11:57:12 -0700 (PDT)
Received: from thalia.fm.intel.com [132.233.247.11] by mail.timestep.com [209.4
7.58.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Tue, 08 Ju
n 1999 14:47:01 -0400
Received: from fmsmsx18.intel.com (fmsmsx18.fm.intel.com [132.233.233.232])
        by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24 22
:10:56 iwep Exp iwep $) with ESMTP id LAA07069
        for <ipsec-policy@mail.timestep.com>; Tue, 8 Jun 1999 11:45:58 -0700 (P
DT)
Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2448.0)
        id <MQ80QD69>; Tue, 8 Jun 1999 11:45:58 -0700
Message-ID: <MDAEMON-F199906081447.AA470111MD20162@mail.timestep.com>
From: "Jeronimo, Michael" <michael.jeronimo@intel.com>
To: ipsec-policy@mail.timestep.com
Subject: RE: Proposed IPSP Charter
Date: Tue, 8 Jun 1999 11:45:57 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
        charset="ISO-8859-1"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: michael.jeronimo@intel.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 9bfc6b565822428d9e2c009c183b193c

>I have a question about using COPS as the distrubution method. As I
>read COPS, it seems well designed for intra-domain policy distribution
>but does not seem to have the server discovery, server-to-server
>communication, enforcement point signalling, and policy negotiation
>mechanisms needed to support inter-domain policy negotiation.

Yes, you're right - it currently does intra-domain policy distribution.
It also allows asynchronous policy updates as well as reports from the
enforcement point.  It doesn't handle server discovery, but I don't
think a distribution protocol necessarily should.  I also think the
inter-domain policy issues should be tackled separately.  But, I didn't
mean to necessarily advocate any particular protocol.  My point was that
we should just define IPsec policy in the abstract, then derive
the task-specific representations - policy definition languages, LDAP
schema, COPS objects, etc.

>It also includes a more complicated resolution process since the
>communication that will be passing though an enforcement point
>may not be the same as the policy requested.  For example, two
>hosts H1 and H2 would like to commuicate on port 79, so H1 needs
>to negotiate the policies for this communication.  If, for example,
>H2 requires ESP to be used for the communication (and H1's policy
>allows it), the policy negotiated with a gateway GW1 between
>H1 and H2, not only has to include whether or not H1 and H2 can
>be allowed to communicate on port 79, but whether or not they
>can use ESP.  This becomes even more complex when there are more
>nested gateways.

So, you're finding out if H1 is going to be able to communicate
with H2, given the intermediate security requirements (policy), before
the actual IKE negotiation takes place and communication is attempted.
How is this information going to be used?  Is H1 going to adjust its
proposal based on the feedback?

-Mike





From ???@??? Wed Jun 09 08:01:47 1999
Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15])
        by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id GAA06835
        for <paul.hoffman@vpnc.org>; Wed, 9 Jun 1999 06:35:13 -0700 (PDT)
Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i
d <50969-16460>; Wed, 9 Jun 1999 09:38:29 -0400
Received: from wolfe.bbn.com [128.89.2.232] by mail.timestep.com [209.47.58.12]
 with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Wed, 09 Jun 1999 0
9:30:47 -0400
Received: (from mcondell@localhost)
        by wolfe.bbn.com (8.8.8/8.8.6) id JAA07397;
        Wed, 9 Jun 1999 09:29:14 -0400 (EDT)
Date: Wed, 9 Jun 1999 09:29:14 -0400
Message-ID: <MDAEMON-F199906090930.AA304713MD20544@mail.timestep.com>
From: Matthew Condell <mcondell@bbn.com>
To: ipsec-policy@mail.timestep.com
Subject: RE: Proposed IPSP Charter
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: mcondell@bbn.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 64848173762fa52336fd9708853b0555


>>It also includes a more complicated resolution process since the
>>communication that will be passing though an enforcement point
>>may not be the same as the policy requested.  For example, two
>>hosts H1 and H2 would like to commuicate on port 79, so H1 needs
>>to negotiate the policies for this communication.  If, for example,
>>H2 requires ESP to be used for the communication (and H1's policy
>>allows it), the policy negotiated with a gateway GW1 between
>>H1 and H2, not only has to include whether or not H1 and H2 can
>>be allowed to communicate on port 79, but whether or not they
>>can use ESP.  This becomes even more complex when there are more
>>nested gateways.
>
>So, you're finding out if H1 is going to be able to communicate
>with H2, given the intermediate security requirements (policy), before
>the actual IKE negotiation takes place and communication is attempted.
>How is this information going to be used?  Is H1 going to adjust its
>proposal based on the feedback?

Yes and yes.  Policy discovery and negotiation must occur before the
IKE negotiation to determine with which gateways H1 will have to set
up SAs.  It will also inform intermediate gateways which SAs they
will need to support the communication.  So, only after the policy
negotiation occurs will H1 know with which entities it will have
to do IKE negotiations.  Now that the policy negotiations have
occurred, H1 should use the policy information to adjust its
proposal, since it has that additional information.  This process
is explained in draft-ietf-ipsec-sps-00.txt.

Matt Condell
BBN Technologies



From ???@??? Wed Jun 09 15:45:57 1999
Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15])
        by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id LAA07132
        for <paul.hoffman@vpnc.org>; Wed, 9 Jun 1999 11:15:02 -0700 (PDT)
Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i
d <55643-28600>; Wed, 9 Jun 1999 14:18:15 -0400
Received: from po1.bbn.com [192.1.50.38] by mail.timestep.com [209.47.58.12] wi
th SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Wed, 09 Jun 1999 13:4
5:33 -0400
Received: from jzao.bbn.com (DHCP030-187.BBN.COM [171.78.30.187])
        by po1.bbn.com (8.9.1/8.9.1) with SMTP id NAA22900
        for <ipsec-policy@mail.timestep.com>; Wed, 9 Jun 1999 13:44:00 -0400 (E
DT)
Message-ID: <MDAEMON-F199906091345.AA453322MD21855@mail.timestep.com>
X-Sender: jzao@po1.bbn.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Wed, 9 Jun 1999 13:38:45 -0400
To: ipsec-policy@mail.timestep.com
From: "John K. Zao" <jzao@bbn.com>
Subject: Re: Proposed IPSP Charter
In-Reply-To: <MDAEMON-F199906070735.AA353800MD18152@mail.timestep.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: jzao@bbn.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: c77ff682cdd356d8a67febad6bf686bb

At 07:34 AM 6/7/99 -0400, Matthew Condell wrote:
>
>Description of Working Group
>----------------------------
> ...
>To address these problems the IPSP Working Group will:
> ...
>       4) provide guidelines for secure storage and handling of
>           security policies, and;
>

(4) is rather vague. I suggest we replace the word "handling" with the
actual issues we should be concerned with, such as:

   + authentication (proof to policy consumers of policy origin and
integrity),
   + access control (granting policy consumers of read and/or modify rights),
   + authorization (determining the relevance of policies to policy consumers)

where policy consumers include both policy management agents and
enforcement agents.

In my opinion, some or all of these issues should be addressed, and their
mechanisms will be closely related to the policy management architectures
(hierarchical domain vs group based) and the policy distribution mechanisms
(protocol vs directory based) we choose to adopt.

>       5) develop IKE extensions to support efficient SA
>           establishment for iterated tunneling.
>

This is more an IKE design issue than a policy management issue. I won't
object if we decide that this working group is the proper place for
discussing future work of IKE, but I wonder if there are plans to stand up
other IP Second BOFs in the near future.

John




From ???@??? Wed Jun 09 15:45:57 1999
Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15])
        by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id PAA07347
        for <paul.hoffman@vpnc.org>; Wed, 9 Jun 1999 15:19:52 -0700 (PDT)
Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i
d <53155-2545>; Wed, 9 Jun 1999 18:23:03 -0400
Received: from nutmeg.bbn.com [128.89.1.112] by mail.timestep.com [209.47.58.12
] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Wed, 09 Jun 1999
18:20:41 -0400
Received: (from lsanchez@localhost)
        by nutmeg.bbn.com (8.8.8/8.8.7) id SAA01533
        for ipsec-policy@mail.timestep.com; Wed, 9 Jun 1999 18:19:12 -0400 (EDT
)
        (envelope-from lsanchez)
From: "Luis A. Sanchez" <lsanchez@bbn.com>
Message-ID: <MDAEMON-F199906091820.AA204143MD22242@mail.timestep.com>
Subject: Re: Proposed IPSP Charter
To: ipsec-policy@mail.timestep.com
Date: Wed, 9 Jun 1999 18:19:12 -0400
Reply-To: ipsec-policy@mail.timestep.com
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: lsanchez@nutmeg.bbn.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
X-UIDL: c1882e5a449231185d3c53df62a26a67

Mike,

        > As for the rest of #3, I'm not clear on:
>
>            "The protocol must be capable of discovering,
>            distributing and resolving policy conflicts in both
>            intra/inter domain environments."
>

Thank you for pointing this out. The previous sentence should have read:

>            "The protocol must be capable of: 1) discovering policy
>            servers, 2) distributing and negotiating security
>            policies, and; 3) resolving policy conflicts in both
>            intra/inter domain environments."


Luis



From ???@??? Thu Jun 10 10:26:18 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id HAA08610
        for <paul.hoffman@vpnc.org>; Thu, 10 Jun 1999 07:18:41 -0700 (PDT)
Received: from nutmeg.bbn.com [128.89.1.112] by mail.timestep.com [209.47.58.12
] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Thu, 10 Jun 1999
10:05:41 -0400
Received: (from lsanchez@localhost)
        by nutmeg.bbn.com (8.8.8/8.8.7) id KAA00404
        for ipsec-policy@mail.timestep.com; Thu, 10 Jun 1999 10:04:17 -0400 (ED
T)
        (envelope-from lsanchez)
From: "Luis A. Sanchez" <lsanchez@bbn.com>
Message-ID: <MDAEMON-F199906101005.AA054177MD22624@mail.timestep.com>
Subject: Re: Proposed IPSP Charter
To: ipsec-policy@mail.timestep.com
Date: Thu, 10 Jun 1999 10:04:17 -0400 (EDT)
Reply-To: ipsec-policy@mail.timestep.com
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: lsanchez@nutmeg.bbn.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
X-UIDL: 42c3c686b856d38ba3e35daa531e72ca

Mike,

> inter-domain policy issues should be tackled separately.  But, I didn't
> mean to necessarily advocate any particular protocol.  My point was that
> we should just define IPsec policy in the abstract, then derive
> the task-specific representations - policy definition languages, LDAP
> schema, COPS objects, etc.

I think most of us agree that this soon-to-be WG should define an
IPsec data model and adopt a Policy Specification Language. However, I
don't think we should state in the charter that this group will define
COPS Objects if it implies that this group will use COPS for policy
distribution. Especially, when we know that COPS as it stands today
doesn't meet the requirements. Unless, there is strong opposition I
prefer using the following text in the charter:

"This group will look at existing IETF standard work in the area of
policy distribution. In particular, the group will look at the
possibility of using/enhancing existing intra-domain policy
distribution protocols such as the one developed in the RAP WG, if
feasible."

The goal is to do a _fair_ evaluation of what COPS has to offer and
_then_ determine if it could be used to distribute/negotiate
inter-domain security policies and to resolve policy conflicts.

Also, why should this WG dictate one specific format (LDAP Schema) for
storing security policies? Why can't we allow several storage formats
provided we define a policy data model, adopt a language to represent
such policies and specify how such policies will look on the wire?

Luis


From ???@??? Thu Jun 10 10:26:18 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id JAA08763
        for <paul.hoffman@vpnc.org>; Thu, 10 Jun 1999 09:53:14 -0700 (PDT)
Received: from ganymede.or.intel.com [134.134.248.3] by mail.timestep.com [209.
47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Thu, 10 J
un 1999 12:42:42 -0400
Received: from orsmsx28.jf.intel.com (orsmsx28.jf.intel.com [192.168.65.28])
        by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24
22:10:56 iwep Exp iwep $) with ESMTP id JAA02781
        for <ipsec-policy@mail.timestep.com>; Thu, 10 Jun 1999 09:41:15 -0700 (
PDT)
Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2448.0)
        id <M1XH5GAD>; Thu, 10 Jun 1999 09:41:15 -0700
Message-ID: <MDAEMON-F199906101242.AA424236MD23005@mail.timestep.com>
From: "Jeronimo, Michael" <michael.jeronimo@intel.com>
To: "'ipsec-policy@mail.timestep.com'" <ipsec-policy@mail.timestep.com>
Subject: RE: Proposed IPSP Charter
Date: Thu, 10 Jun 1999 09:41:13 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
        charset="iso-8859-1"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: michael.jeronimo@intel.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 7831c6b71493818eb328dd204a417fd8


>I think most of us agree that this soon-to-be WG should define an
>IPsec data model and adopt a Policy Specification Language. However, I
>don't think we should state in the charter that this group will define
>COPS Objects if it implies that this group will use COPS for policy
>distribution. Especially, when we know that COPS as it stands today
>doesn't meet the requirements. Unless, there is strong opposition I
>prefer using the following text in the charter:
>
>"This group will look at existing IETF standard work in the area of
>policy distribution. In particular, the group will look at the
>possibility of using/enhancing existing intra-domain policy
>distribution protocols such as the one developed in the RAP WG, if
>feasible."
>
>The goal is to do a _fair_ evaluation of what COPS has to offer and
>_then_ determine if it could be used to distribute/negotiate
>inter-domain security policies and to resolve policy conflicts.
>
>Also, why should this WG dictate one specific format (LDAP Schema) for
>storing security policies? Why can't we allow several storage formats
>provided we define a policy data model, adopt a language to represent
>such policies and specify how such policies will look on the wire?

Luis,

I see a policy system consisting of at least:

        - Authoring
        - Storage
        - Distribution
        - Enforcement
        - Feedback

Each of these tasks are relative to a cannonical form (the core model), that
describes the semantics of the policy.  I don't see a policy specification
language as any more important than a storage schema or a distribution
method.
I think each of these representations should be well-defined for purposes of
interoperability.  I may choose to implement my policy authoring tool as a
whiz-bang GUI that doesn't even use a policy specification language, but
outputs a storage schema that the downstream tools can understand.

Perhaps you see a multi-purpose policy specification language used for
authoring
and then also storage (store the text of the specification).  I was thinking
of a
PSL used for authoring, but another representation for storage (as in a
directory).

I agree completely about doing a fair evaluation of existing protocols.

-Mike




From ???@??? Fri Jun 11 16:23:26 1999
Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15])
        by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id QAA11049
        for <paul.hoffman@vpnc.org>; Fri, 11 Jun 1999 16:14:11 -0700 (PDT)
Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i
d <50131-19906>; Fri, 11 Jun 1999 19:17:47 -0400
Received: from nutmeg.bbn.com [128.89.1.112] by mail.timestep.com [209.47.58.12
] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Fri, 11 Jun 1999
19:04:51 -0400
Received: (from lsanchez@localhost)
        by nutmeg.bbn.com (8.8.8/8.8.7) id TAA01126
        for ipsec-policy@mail.timestep.com; Fri, 11 Jun 1999 19:03:29 -0400 (ED
T)
        (envelope-from lsanchez)
From: "Luis A. Sanchez" <lsanchez@bbn.com>
Message-ID: <MDAEMON-F199906111904.AA045145MD23393@mail.timestep.com>
Subject: Re: Proposed IPSP Charter
In-Reply-To: <MDAEMON-F199906101242.AA425000MD23136@mail.timestep.com> from "Je
ronimo, Michael" at "Jun 10, 99 09:41:13 am"
To: ipsec-policy@mail.timestep.com
Date: Fri, 11 Jun 1999 19:03:29 -0400
Reply-To: ipsec-policy@mail.timestep.com
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: lsanchez@nutmeg.bbn.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
X-UIDL: 6dd6c02c11e085fd254c49010ca441ee

Mike,

        Like you, I was thinking more along the lines of a PSL
separate from any of the several possible representation schemes for
storage. On the other hand, Angelos brought up a good point: the
original proposed charter might be to extensive. Taking this into
consideration and for the sake of time it might be better if the WG
begins working on:

1) specifying a data model for supporting IP security policies,

2) adopting an extensible IPsec policy specification language,

3) developing a protocol capable of:
        o discovering policy servers
        o distributing and negotiating security policies
        o resolving policy conflicts in both intra/inter domain
          environments

Once we *show* some progress we can attack issues such as storage, IKE
mods, etc. We can fine tune how the charter is executed as we move
along. Is this reasonable for starters? If so, Roy and I will submit
the charter to the Sec Area directors for their revision and approval.

Luis




>
> Luis,
>
> I see a policy system consisting of at least:
>
>       - Authoring
>       - Storage
>       - Distribution
>       - Enforcement
>       - Feedback
>
> Each of these tasks are relative to a cannonical form (the core model), that
> describes the semantics of the policy.  I don't see a policy specification
> language as any more important than a storage schema or a distribution
> method.
> I think each of these representations should be well-defined for purposes of
> interoperability.  I may choose to implement my policy authoring tool as a
> whiz-bang GUI that doesn't even use a policy specification language, but
> outputs a storage schema that the downstream tools can understand.
>
> Perhaps you see a multi-purpose policy specification language used for
> authoring
> and then also storage (store the text of the specification).  I was thinking
> of a
> PSL used for authoring, but another representation for storage (as in a
> directory).
>
> I agree completely about doing a fair evaluation of existing protocols.
>
> -Mike
>
>
>
>



From ???@??? Fri Jun 11 17:01:41 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id QAA11070
        for <paul.hoffman@vpnc.org>; Fri, 11 Jun 1999 16:46:09 -0700 (PDT)
Received: from research.solidum.com [216.13.130.242] by mail.timestep.com [209.
47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Fri, 11 J
un 1999 19:35:51 -0400
Received: from venus.solidum.com (venus.solidum.com [192.168.1.1])
          by research.solidum.com (8.8.4/8.8.4) with ESMTP
          id TAA25239 for <ipsec-policy@mail.timestep.com>; Fri, 11 Jun 1999 19
:27:27 -0400
Received: from phobos.solidum.com (mcr@phobos.solidum.com [192.168.1.13])
        by venus.solidum.com (8.8.7/8.8.7) with ESMTP id TAA03633
        for <ipsec-policy@mail.timestep.com>; Fri, 11 Jun 1999 19:34:33 -0400
Message-ID: <MDAEMON-F199906111935.AA355196MD23771@mail.timestep.com>
To: ipsec-policy@mail.timestep.com
Subject: Re: Proposed IPSP Charter
In-reply-to: Your message of "Fri, 11 Jun 1999 19:03:29 EDT."
             <MDAEMON-F199906111904.AA044943MD23356@mail.timestep.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Fri, 11 Jun 1999 19:34:33 -0400
From: Michael Richardson <mcr@solidum.com>
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: mcr@solidum.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: b532ea9ef11dbb3036bfb7d5bb06e6fb


>>>>> "Luis" == Luis A Sanchez <lsanchez@bbn.com> writes:
    Luis>       Like you, I was thinking more along the lines of a PSL
    Luis> separate from any of the several possible representation schemes for
    Luis> storage. On the other hand, Angelos brought up a good point: the
    Luis> original proposed charter might be to extensive. Taking this into
    Luis> consideration and for the sake of time it might be better if the WG
    Luis> begins working on:

  I would suggest that if it is important that the charter list it, but make
it clear in the charter that these issues come later.

   :!mcr!:            |  Solidum Systems Corporation, http://www.solidum.com
   Michael Richardson |For a better connected world,where data flows faster<tm>
 Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson
/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
 Corporate: <A HREF="mailto:mcr@solidum.com">mcr@solidum.com</A>.



From ???@??? Mon Jun 14 08:08:49 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id HAA16955
        for <paul.hoffman@vpnc.org>; Mon, 14 Jun 1999 07:51:17 -0700 (PDT)
Received: from ganymede.or.intel.com [134.134.248.3] by mail.timestep.com [209.
47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Mon, 14 J
un 1999 10:41:11 -0400
Received: from orsmsx29.jf.intel.com (orsmsx29.jf.intel.com [192.168.65.29])
        by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24
22:10:56 iwep Exp iwep $) with ESMTP id HAA23013
        for <ipsec-policy@mail.timestep.com>; Mon, 14 Jun 1999 07:40:04 -0700 (
PDT)
Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2448.0)
        id <M720DPD4>; Mon, 14 Jun 1999 07:40:02 -0700
Message-ID: <MDAEMON-F199906141041.AA411112MD24150@mail.timestep.com>
From: "Jeronimo, Michael" <michael.jeronimo@intel.com>
To: "'ipsec-policy@mail.timestep.com'" <ipsec-policy@mail.timestep.com>
Subject: RE: Proposed IPSP Charter
Date: Mon, 14 Jun 1999 07:39:54 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
        charset="iso-8859-1"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: michael.jeronimo@intel.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 2fe6077a2418aeb6168c64809ecfe7d1

Luis,

I think this is a good list to start with.  In the interest
of forward progress, we should stay focused.

-Mike

-----Original Message-----
From: Luis A. Sanchez [mailto:lsanchez@bbn.com]
Sent: Friday, June 11, 1999 4:03 PM
To: ipsec-policy@mail.timestep.com
Subject: Re: Proposed IPSP Charter


Mike,

        Like you, I was thinking more along the lines of a PSL
separate from any of the several possible representation schemes for
storage. On the other hand, Angelos brought up a good point: the
original proposed charter might be to extensive. Taking this into
consideration and for the sake of time it might be better if the WG
begins working on:

1) specifying a data model for supporting IP security policies,

2) adopting an extensible IPsec policy specification language,

3) developing a protocol capable of:
        o discovering policy servers
        o distributing and negotiating security policies
        o resolving policy conflicts in both intra/inter domain
          environments

Once we *show* some progress we can attack issues such as storage, IKE
mods, etc. We can fine tune how the charter is executed as we move
along. Is this reasonable for starters? If so, Roy and I will submit
the charter to the Sec Area directors for their revision and approval.

Luis




>
> Luis,
>
> I see a policy system consisting of at least:
>
>       - Authoring
>       - Storage
>       - Distribution
>       - Enforcement
>       - Feedback
>
> Each of these tasks are relative to a cannonical form (the core model),
that
> describes the semantics of the policy.  I don't see a policy specification

> language as any more important than a storage schema or a distribution
> method.
> I think each of these representations should be well-defined for purposes
of
> interoperability.  I may choose to implement my policy authoring tool as a

> whiz-bang GUI that doesn't even use a policy specification language, but
> outputs a storage schema that the downstream tools can understand.
>
> Perhaps you see a multi-purpose policy specification language used for
> authoring
> and then also storage (store the text of the specification).  I was
thinking
> of a
> PSL used for authoring, but another representation for storage (as in a
> directory).
>
> I agree completely about doing a fair evaluation of existing protocols.
>
> -Mike
>
>
>
>




From ???@??? Mon Jun 14 09:39:39 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id JAA17067
        for <paul.hoffman@vpnc.org>; Mon, 14 Jun 1999 09:30:52 -0700 (PDT)
Received: from calliope1.fm.intel.com [132.233.247.10] by mail.timestep.com [20
9.47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Mon, 14
 Jun 1999 12:20:50 -0400
Received: from fmsmsx19.fm.intel.com (fmsmsx19.fm.intel.com [132.233.222.210])
        by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24
 22:10:56 iwep Exp iwep $) with ESMTP id JAA01059
        for <ipsec-policy@mail.timestep.com>; Mon, 14 Jun 1999 09:19:45 -0700 (
PDT)
Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2448.0)
        id <MQ9AJGK8>; Mon, 14 Jun 1999 09:19:44 -0700
Message-ID: <MDAEMON-F199906141220.AA205018MD24529@mail.timestep.com>
From: "Jason, Jamie" <jamie.jason@intel.com>
To: "'ipsec-policy@mail.timestep.com'" <ipsec-policy@mail.timestep.com>
Subject: RE: Proposed IPSP Charter
Date: Mon, 14 Jun 1999 09:19:43 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
        charset="iso-8859-1"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: jamie.jason@intel.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: d51244b16bfb2ab003541913762374d3

> Also, why should this WG dictate one specific format (LDAP Schema) for
> storing security policies? Why can't we allow several storage formats
> provided we define a policy data model, adopt a language to represent
> such policies and specify how such policies will look on the wire?

I have been out of town for a few days, so haven't had a chance to read all
of my email, but I believe that Mike was only giving examples of what you
can derive from an IPSEC policy model.  I don't think that he was advocating
one storage or distribution mechanism over another.  I think that the point
is that the IPSEC policy model should be derived completely independent of
any storage or distribution mechanism.  This is the same thing that the
policy WG is now going through - they are going over their charter again.
They are going to develop an storage independent policy information model
and then they will use that to develop LDAP schema, etc.  By doing this,
they will always have the core policy information model, whereas if they had
continued on with just defining an LDAP schema, going back to the core
policy information model would have been impossible and other storage
mechanisms would have had to jump through hoops to represent policy
information because they would be hamstrung by the way in which LDAP works.

Jamie



From ???@??? Mon Jun 14 10:07:26 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id KAA17095
        for <paul.hoffman@vpnc.org>; Mon, 14 Jun 1999 10:03:49 -0700 (PDT)
Received: from calliope1.fm.intel.com [132.233.247.10] by mail.timestep.com [20
9.47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Mon, 14
 Jun 1999 12:52:29 -0400
Received: from fmsmsx17.intel.com (fmsmsx17.fm.intel.com [132.233.58.209])
        by calliope1.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.6 1998/11/24
 22:10:56 iwep Exp iwep $) with ESMTP id JAA09490
        for <ipsec-policy@mail.timestep.com>; Mon, 14 Jun 1999 09:51:23 -0700 (
PDT)
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2448.0)
        id <MQ87Z73Y>; Mon, 14 Jun 1999 09:51:22 -0700
Message-ID: <MDAEMON-F199906141252.AA522936MD24908@mail.timestep.com>
From: "Jason, Jamie" <jamie.jason@intel.com>
To: "'ipsec-policy@mail.timestep.com'" <ipsec-policy@mail.timestep.com>
Subject: RE: Proposed IPSP Charter
Date: Mon, 14 Jun 1999 09:51:14 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
        charset="iso-8859-1"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: jamie.jason@intel.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: bb39128ff837825494dec4224df84e07

Agreed.  I would much rather see this group start with a smaller task and be
successful.  I do agree with M. Richardson that we should still keep the
other tasks in the back of our minds.

Jamie

> -----Original Message-----
> From: Jeronimo, Michael [mailto:michael.jeronimo@intel.com]
> Sent: Monday, June 14, 1999 7:40 AM
> To: 'ipsec-policy@mail.timestep.com'
> Subject: RE: Proposed IPSP Charter
>
>
> Luis,
>
> I think this is a good list to start with.  In the interest
> of forward progress, we should stay focused.
>
> -Mike
>
> -----Original Message-----
> From: Luis A. Sanchez [mailto:lsanchez@bbn.com]
> Sent: Friday, June 11, 1999 4:03 PM
> To: ipsec-policy@mail.timestep.com
> Subject: Re: Proposed IPSP Charter
>
>
> Mike,
>
>       Like you, I was thinking more along the lines of a PSL
> separate from any of the several possible representation schemes for
> storage. On the other hand, Angelos brought up a good point: the
> original proposed charter might be to extensive. Taking this into
> consideration and for the sake of time it might be better if the WG
> begins working on:
>
> 1) specifying a data model for supporting IP security policies,
>
> 2) adopting an extensible IPsec policy specification language,
>
> 3) developing a protocol capable of:
>       o discovering policy servers
>       o distributing and negotiating security policies
>       o resolving policy conflicts in both intra/inter domain
>           environments
>
> Once we *show* some progress we can attack issues such as storage, IKE
> mods, etc. We can fine tune how the charter is executed as we move
> along. Is this reasonable for starters? If so, Roy and I will submit
> the charter to the Sec Area directors for their revision and approval.
>
> Luis
>
>
>
>
> >
> > Luis,
> >
> > I see a policy system consisting of at least:
> >
> >     - Authoring
> >     - Storage
> >     - Distribution
> >     - Enforcement
> >     - Feedback
> >
> > Each of these tasks are relative to a cannonical form (the
> core model),
> that
> > describes the semantics of the policy.  I don't see a
> policy specification
>
> > language as any more important than a storage schema or a
> distribution
> > method.
> > I think each of these representations should be
> well-defined for purposes
> of
> > interoperability.  I may choose to implement my policy
> authoring tool as a
>
> > whiz-bang GUI that doesn't even use a policy specification
> language, but
> > outputs a storage schema that the downstream tools can understand.
> >
> > Perhaps you see a multi-purpose policy specification
> language used for
> > authoring
> > and then also storage (store the text of the specification).  I was
> thinking
> > of a
> > PSL used for authoring, but another representation for
> storage (as in a
> > directory).
> >
> > I agree completely about doing a fair evaluation of
> existing protocols.
> >
> > -Mike
> >
> >
> >
> >
>
>
>



From ???@??? Tue Jun 15 07:04:58 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id XAA17784
        for <paul.hoffman@vpnc.org>; Mon, 14 Jun 1999 23:19:43 -0700 (PDT)
Received: from sm9ul021.aircanada.ca [209.89.122.37] by mail.timestep.com [209.
47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Tue, 15 J
un 1999 02:10:55 -0400
Received: from aircanada.ca ([159.206.100.95]) by sm9ul021.aircanada.ca
          (Post.Office MTA v3.1.2 release (PO205-101c) ID# 0-0U10L2S100)
          with SMTP id AAA242 for <ipsec-policy@mail.timestep.com>;
          Tue, 15 Jun 1999 02:14:15 -0400
Received: from ccMail by aircanada.ca (ccMail Link to SMTP R8.00.01)
    id AA929426966; Tue, 15 Jun 99 02:09:33 -0500
Message-ID: <MDAEMON-F199906150210.AA105541MD25287@mail.timestep.com>
X-Mailer: ccMail Link to SMTP R8.00.01
Date: Tue, 15 Jun 99 01:00:49 -0500
From: "Benoit Hotte"<bhotte@aircanada.ca>
To: <ipsec-policy@mail.timestep.com>
Subject: Benoit Hotte est absent/is in vacation
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: bhotte@aircanada.ca
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from Quoted-Printable to 8bit by mail.vpnc.org id XAA1778
4
X-UIDL: b7279eb9e75808727693e0673b1738bb




  I will be out of the office from 12/06/99 until 21/06/99.

  I will respond to your message when I return.


  I case of emergency please contact my manager Laurent Hébert


  Je répondrai à mes messages à mon retour.

  En cas d'urgence svp contacter Laurent Hébert



From ???@??? Fri Jun 25 09:10:53 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id GAA15202
        for <paul.hoffman@vpnc.org>; Fri, 25 Jun 1999 06:41:17 -0700 (PDT)
Received: from nutmeg.bbn.com [128.89.1.112] by mail.timestep.com [209.47.58.12
] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Fri, 25 Jun 1999
09:32:51 -0400
Received: (from lsanchez@localhost)
        by nutmeg.bbn.com (8.8.8/8.8.7) id JAA00589
        for ipsec-policy@mail.timestep.com; Fri, 25 Jun 1999 09:31:36 -0400 (ED
T)
        (envelope-from lsanchez)
From: "Luis A. Sanchez" <lsanchez@bbn.com>
Message-ID: <MDAEMON-F199906250932.AA325101MD26292@mail.timestep.com>
Subject: 45th IETF: IPSP Meeting
To: ipsec-policy@mail.timestep.com
Date: Fri, 25 Jun 1999 09:31:36 -0400 (EDT)
Reply-To: ipsec-policy@mail.timestep.com
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: lsanchez@nutmeg.bbn.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
X-UIDL: 620f05cfe459b7bd17d06ee5517234ac

Folks,

        IPSP will be meeting in Oslo Wednesday, July 14 at
1530-1730. If you would like to present during the meeting send email
to Roy and myself. Include a _short_ description of your presentation
and time needed. The deadline for submitting the agenda is July 1 at
1200 ET so we need your input by no later than June 30th.

Luis



From ???@??? Tue Jun 29 09:48:36 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id GAA23856
        for <paul.hoffman@vpnc.org>; Tue, 29 Jun 1999 06:54:48 -0700 (PDT)
Received: from po1.bbn.com [192.1.50.38] by mail.timestep.com [209.47.58.12] wi
th SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Tue, 29 Jun 1999 09:4
6:57 -0400
Received: from jzao.bbn.com (DHCP030-187.BBN.COM [171.78.30.187])
        by po1.bbn.com (8.9.1/8.9.1) with SMTP id JAA24657;
        Tue, 29 Jun 1999 09:45:49 -0400 (EDT)
Message-ID: <MDAEMON-F199906290946.AA465767MD26705@mail.timestep.com>
X-Sender: jzao@po1.bbn.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Tue, 29 Jun 1999 09:37:57 -0400
To: "Luis A. Sanchez" <lsanchez@bbn.com>,
        "Roy Pereira" <rpereira@timestep.com>
From: "John K. Zao" <jzao@bbn.com>
Subject: Presentation proposal for IPSP WG Meeting at 45th IETF
Cc: ipsec-policy@mail.timestep.com
In-Reply-To: <MDAEMON-F199906250932.AA324684MD26222@mail.timestep.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: jzao@bbn.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 98cb588d1bf7b33515a3f30049e8a62c

At 09:31 AM 6/25/99 -0400, Luis A. Sanchez wrote:
>Folks,
>
>       IPSP will be meeting in Oslo Wednesday, July 14 at
>1530-1730. If you would like to present during the meeting send email
>to Roy and myself. Include a _short_ description of your presentation
>and time needed. The deadline for submitting the agenda is July 1 at
>1200 ET so we need your input by no later than June 30th.
>
>Luis
>

Luis and Roy,

I would like to have 20 minutes in IPSP WG meeting to present a Semantic
Model of IPSec Policy. Following is a brief description of the presentation.

-----
A semantic model of IPSec policies is needed to specify ways that two or
more IPSec policies -- enforced by same or different devices -- may
interact with one another. The representation will focus on the following
three types of policy interactions:

1. decorrelation of IPSec policies of same enforcement device with
overlapping selector values,

2. composition of IPSec policies of peer communicating devices,

3. inference of sequences of packet header transformations caused by
en-route enforcement of IPSec policies.

A semantic algebra based on the IPSec Policy Data Model proposed by Pereira
and Bhattacharya will be introduced and its algebra in determining the
effects of the three interactions will be explained in the presentation.
-----

An Internet-Draft of the same title was submitted to IPSec Working Group. A
revised version will be posted to the IPSP mailing list.

Thanks for your attention and looking forward to your reply.

John

John K. Zao
GTE / BBN Technologies
10 Fawcett St., Cambridge, MA, USA 02139
Tel: (617) 873-2438
Fax: (617) 873-4086
Email: jzao@bbn.com



From ???@??? Wed Jun 30 17:32:07 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id PAA27621
        for <paul.hoffman@vpnc.org>; Wed, 30 Jun 1999 15:23:39 -0700 (PDT)
Received: from nutmeg.bbn.com [128.89.1.112] by mail.timestep.com [209.47.58.12
] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Wed, 30 Jun 1999
18:16:24 -0400
Received: (from lsanchez@localhost)
        by nutmeg.bbn.com (8.8.8/8.8.7) id SAA01055;
        Wed, 30 Jun 1999 18:15:40 -0400 (EDT)
        (envelope-from lsanchez)
From: "Luis A. Sanchez" <lsanchez@bbn.com>
Message-ID: <MDAEMON-F199906301816.AA162408MD27085@mail.timestep.com>
Subject: Re: Presentation proposal for IPSP WG Meeting at 45th IETF
In-Reply-To: <MDAEMON-F199906290947.AA470768MD26834@mail.timestep.com> from "Jo
hn K. Zao" at "Jun 29, 99 09:37:57 am"
To: ipsec-policy@mail.timestep.com
Date: Wed, 30 Jun 1999 18:15:40 -0400 (EDT)
Cc: lsanchez@bbn.com, rpereira@timestep.com
Reply-To: ipsec-policy@mail.timestep.com
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: lsanchez@nutmeg.bbn.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
X-UIDL: 145cbcbc0f5437c6550fe651052ce136

John,
        Please plan for 15 mins.
Luis

> At 09:31 AM 6/25/99 -0400, Luis A. Sanchez wrote:
> >Folks,
> >
> >     IPSP will be meeting in Oslo Wednesday, July 14 at
> >1530-1730. If you would like to present during the meeting send email
> >to Roy and myself. Include a _short_ description of your presentation
> >and time needed. The deadline for submitting the agenda is July 1 at
> >1200 ET so we need your input by no later than June 30th.
> >
> >Luis
> >
>
> Luis and Roy,
>
> I would like to have 20 minutes in IPSP WG meeting to present a Semantic
> Model of IPSec Policy. Following is a brief description of the presentation.
>
> -----
> A semantic model of IPSec policies is needed to specify ways that two or
> more IPSec policies -- enforced by same or different devices -- may
> interact with one another. The representation will focus on the following
> three types of policy interactions:
>
> 1. decorrelation of IPSec policies of same enforcement device with
> overlapping selector values,
>
> 2. composition of IPSec policies of peer communicating devices,
>
> 3. inference of sequences of packet header transformations caused by
> en-route enforcement of IPSec policies.
>
> A semantic algebra based on the IPSec Policy Data Model proposed by Pereira
> and Bhattacharya will be introduced and its algebra in determining the
> effects of the three interactions will be explained in the presentation.
> -----
>
> An Internet-Draft of the same title was submitted to IPSec Working Group. A
> revised version will be posted to the IPSP mailing list.
>
> Thanks for your attention and looking forward to your reply.
>
> John
>
> John K. Zao
> GTE / BBN Technologies
> 10 Fawcett St., Cambridge, MA, USA 02139
> Tel: (617) 873-2438
> Fax: (617) 873-4086
> Email: jzao@bbn.com
>
>
>



From ???@??? Tue Jul 06 07:49:47 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id HAA06265
        for <paul.hoffman@vpnc.org>; Tue, 6 Jul 1999 07:41:36 -0700 (PDT)
Received: from mail.mi.verio.com [209.69.6.110] by mail.timestep.com [209.47.58
.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Tue, 06 Jul 19
99 10:19:19 -0400
Received: from netx1.nei.com (netx1.nei.com [209.69.28.17])
        by mail.mi.verio.com (8.9.1/8.9.1) with SMTP id KAA13958
        for <ipsec-policy@mail.timestep.com>; Tue, 6 Jul 1999 10:04:00 -0400 (E
DT)
From: ron_carter@netx1.nei.com
Received: from ccMail by netx1.nei.com (ccMail Link to SMTP R8.00.00)
    id AA931270235; Tue, 06 Jul 99 10:10:36 -0500
Message-ID: <MDAEMON-F199907061019.AA191966MD27845@mail.timestep.com>
X-Mailer: ccMail Link to SMTP R8.00.00
Date: Tue, 06 Jul 99 10:10:35 -0500
To: <ipsec-policy@mail.timestep.com>
Subject: cc:Mail Link to SMTP Undeliverable Message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="simple boundary"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: ron_carter@netx1.nei.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 9a3a337b3dfd6777579903751b79599c

Message is undeliverable.
Reason: User "rpluth@nei.com" is not found in the cc:Mail Directory.
Original text follows:
---------------------

Received: from mail.timestep.com by netx1.nei.com (ccMail Link to SMTP R8.00.00
)
        ; Tue, 06 Jul 99 10:10:30 -0500
Return-Path: <>
Received: from stax05.cubis.de [194.112.101.49] by mail.timestep.com [209.47.58
.12] with SMTP (MDaemon.v2.7.SP4.R) for <rpluth@nei.com>; Tue, 06 Jul 1999 09:5
9:31 -0400
Received: from sn-dd003 ([10.182.4.161]) by stax05.cubis.de (8.7.5/8.7.3) with
SMTP id PAA06774; Tue, 6 Jul 1999 15:56:22 +0200 (MET DST)
Message-ID: <MDAEMON-F199907060959.AA593185MD27503@mail.timestep.com>
X-Sender: martius@stmail01.cubis.de
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Tue, 06 Jul 1999 15:56:47 +0200
To: ipsec@lists.tislabs.com
From: Kai Martius <kai@secunet.de>
Subject: New Internet Draft - MIKE
Cc: ipsec-policy@mail.timestep.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MDaemon-Deliver-To: rpluth@nei.com
X-Return-Path: kai@secunet.de
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com

Greetings,

[Due to submission deadline I can only make my new Draft available this way for
 now - submission to internet-drafts registry follows]

Abstract

   This document describes a protocol which allows to authenticate
   systems and establish Security Associations in networks with
   different domains of security. The protocol is not only end-to-end,
   but it involves all participating systems in a single exchange.
   Further it allows security gateways to derive sub-policies for
   crossing (encrypted) IPSec-traffic from "conventional" packet
   filtering rules in a trusted manner.

The draft does not only specify a protocol, but it also describes the requireme
nts in complex network environments for a surrounding security policy managemen
t.

Feel free to get a copy from

http://www.imib.med.tu-dresden.de/imib/Internet/ike/draft-martius-ipsec-mike-00
.txt
(if you have problems reaching this site, I'll send you a copy directly)

The draft comes (late ;-) after a presentation in Minneapolis at the IPSec Poli
cy BoF
http://www.ietf.org/proceedings/99mar/44th-99mar-ietf-118.html

Kai


------------------------------------      Kai Martius
      secunet Security Networks AG, Dresden
      (previous) homepage, IPSec-related stuff and PGP keys under:
      http://www.imib.med.tu-dresden.de/imib/personal/kai.html




From ???@??? Tue Jul 06 09:27:25 1999
Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15])
        by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id IAA06339
        for <paul.hoffman@vpnc.org>; Tue, 6 Jul 1999 08:09:18 -0700 (PDT)
Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i
d <49766-10317>; Tue, 6 Jul 1999 11:09:59 -0400
Received: from mail.mi.verio.com [209.69.6.110] by mail.timestep.com [209.47.58
.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Tue, 06 Jul 19
99 10:45:39 -0400
Received: from netx1.nei.com (netx1.nei.com [209.69.28.17])
        by mail.mi.verio.com (8.9.1/8.9.1) with SMTP id KAA17680
        for <ipsec-policy@mail.timestep.com>; Tue, 6 Jul 1999 10:30:19 -0400 (E
DT)
From: ron_carter@netx1.nei.com
Received: from ccMail by netx1.nei.com (ccMail Link to SMTP R8.00.00)
    id AA931271812; Tue, 06 Jul 99 10:36:56 -0500
Message-ID: <MDAEMON-F199907061045.AA453988MD28224@mail.timestep.com>
X-Mailer: ccMail Link to SMTP R8.00.00
Date: Tue, 6 Jul 1999 11:36:52 -0400
To: <ipsec-policy@mail.timestep.com>
Subject: cc:Mail Link to SMTP Undeliverable Message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="simple boundary"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: ron_carter@netx1.nei.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: fcbe94aef5a4c0615e0715c86bfcd7d0

Message is undeliverable.
Reason: User "rpluth@nei.com" is not found in the cc:Mail Directory.
Original text follows:
---------------------

Received: from mail.timestep.com by netx1.nei.com (ccMail Link to SMTP R8.00.00
)
        ; Tue, 06 Jul 99 10:36:49 -0500
Return-Path: <>
Received: from mail.mi.verio.com [209.69.6.110] by mail.timestep.com [209.47.58
.12] with SMTP (MDaemon.v2.7.SP4.R) for <rpluth@nei.com>; Tue, 06 Jul 1999 10:1
9:22 -0400
Received: from netx1.nei.com (netx1.nei.com [209.69.28.17])
        by mail.mi.verio.com (8.9.1/8.9.1) with SMTP id KAA13958
        for <ipsec-policy@mail.timestep.com>; Tue, 6 Jul 1999 10:04:00 -0400 (E
DT)
From: ron_carter@netx1.nei.com
Received: from ccMail by netx1.nei.com (ccMail Link to SMTP R8.00.00)
    id AA931270235; Tue, 06 Jul 99 10:10:36 -0500
Message-ID: <MDAEMON-F199907061019.AA192205MD27882@mail.timestep.com>
X-Mailer: ccMail Link to SMTP R8.00.00
Date: Tue, 06 Jul 99 10:10:35 -0500
To: <ipsec-policy@mail.timestep.com>
Subject: cc:Mail Link to SMTP Undeliverable Message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="simple boundary"
X-MDaemon-Deliver-To: rpluth@nei.com
X-Return-Path: ron_carter@netx1.nei.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com

Message is undeliverable.
Reason: User "rpluth@nei.com" is not found in the cc:Mail Directory.
Original text follows:
---------------------

Received: from mail.timestep.com by netx1.nei.com (ccMail Link to SMTP R8.00.00
)
        ; Tue, 06 Jul 99 10:10:30 -0500
Return-Path: <>
Received: from stax05.cubis.de [194.112.101.49] by mail.timestep.com [209.47.58
.12] with SMTP (MDaemon.v2.7.SP4.R) for <rpluth@nei.com>; Tue, 06 Jul 1999 09:5
9:31 -0400
Received: from sn-dd003 ([10.182.4.161]) by stax05.cubis.de (8.7.5/8.7.3) with
SMTP id PAA06774; Tue, 6 Jul 1999 15:56:22 +0200 (MET DST)
Message-ID: <MDAEMON-F199907060959.AA593185MD27503@mail.timestep.com>
X-Sender: martius@stmail01.cubis.de
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32)
Date: Tue, 06 Jul 1999 15:56:47 +0200
To: ipsec@lists.tislabs.com
From: Kai Martius <kai@secunet.de>
Subject: New Internet Draft - MIKE
Cc: ipsec-policy@mail.timestep.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MDaemon-Deliver-To: rpluth@nei.com
X-Return-Path: kai@secunet.de
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com

Greetings,

[Due to submission deadline I can only make my new Draft available this way for
 now - submission to internet-drafts registry follows]

Abstract

   This document describes a protocol which allows to authenticate
   systems and establish Security Associations in networks with
   different domains of security. The protocol is not only end-to-end,
   but it involves all participating systems in a single exchange.
   Further it allows security gateways to derive sub-policies for
   crossing (encrypted) IPSec-traffic from "conventional" packet
   filtering rules in a trusted manner.

The draft does not only specify a protocol, but it also describes the requireme
nts in complex network environments for a surrounding security policy managemen
t.

Feel free to get a copy from

http://www.imib.med.tu-dresden.de/imib/Internet/ike/draft-martius-ipsec-mike-00
.txt
(if you have problems reaching this site, I'll send you a copy directly)

The draft comes (late ;-) after a presentation in Minneapolis at the IPSec Poli
cy BoF
http://www.ietf.org/proceedings/99mar/44th-99mar-ietf-118.html

Kai


------------------------------------      Kai Martius
      secunet Security Networks AG, Dresden
      (previous) homepage, IPSec-related stuff and PGP keys under:
      http://www.imib.med.tu-dresden.de/imib/personal/kai.html




From ???@??? Sun Jul 11 16:07:30 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id QAA13096
        for <paul.hoffman@vpnc.org>; Fri, 9 Jul 1999 16:45:14 -0700 (PDT)
Received: from nutmeg.bbn.com [128.89.1.112] by mail.timestep.com [209.47.58.12
] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Fri, 09 Jul 1999
19:33:51 -0400
Received: (from lsanchez@localhost)
        by nutmeg.bbn.com (8.8.8/8.8.7) id TAA01414
        for ipsec-policy@mail.timestep.com; Fri, 9 Jul 1999 19:32:49 -0400 (EDT
)
        (envelope-from lsanchez)
From: "Luis A. Sanchez" <lsanchez@bbn.com>
Message-ID: <MDAEMON-F199907091933.AA335183MD28604@mail.timestep.com>
Subject: IPSP Agenda (fwd)
To: ipsec-policy@mail.timestep.com
Date: Fri, 9 Jul 1999 19:32:49 -0400 (EDT)
Reply-To: ipsec-policy@mail.timestep.com
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: lsanchez@nutmeg.bbn.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
X-UIDL: a591a1f122272d852a0592cc9f8186ba

----- Forwarded message from Luis A. Sanchez -----

>From POPmail Thu Jul  1 16:55:43 1999
From: "Luis A. Sanchez" <lsanchez@bbn.com>
Message-Id: <199907012054.QAA02568@nutmeg.bbn.com>
Subject: IPSP Agenda
To: agenda@ietf.org
Date: Thu, 1 Jul 1999 16:54:34 -0400 (EDT)
Cc: rpereira@timestep.com, lsanchez@bbn.com
Reply-to: lsanchez@bbn.com
X-Mailer: ELM [version 2.4ME+ PL32 (25)]

Enclosed you will find the preliminary agenda for IPSP. Thanks!

Luis


Preliminary Agenda
------------------

- Agenda Bashing                                               5 mins

o Unified IPsec policy model                                  15 mins
o Semantic Model of IPsec Policy                              15 mins
o Multi-Domain IKE                                            15 mins

- Charter Discussions                                         30 mins
- Collect feedback and modify charter                         15 mins
- Adjourn


----- End of forwarded message from Luis A. Sanchez -----



From ???@??? Sun Jul 11 16:07:30 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id RAA13112
        for <paul.hoffman@vpnc.org>; Fri, 9 Jul 1999 17:05:17 -0700 (PDT)
Received: from mail.mi.verio.com [209.69.6.110] by mail.timestep.com [209.47.58
.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Fri, 09 Jul 19
99 19:48:47 -0400
Received: from netx1.nei.com (netx1.nei.com [209.69.28.17])
        by mail.mi.verio.com (8.9.1/8.9.1) with SMTP id TAA14955
        for <ipsec-policy@mail.timestep.com>; Fri, 9 Jul 1999 19:33:38 -0400 (E
DT)
From: ron_carter@netx1.nei.com
Received: from ccMail by netx1.nei.com (ccMail Link to SMTP R8.00.00)
    id AA931563619; Fri, 09 Jul 99 19:40:22 -0500
Message-ID: <MDAEMON-F199907091948.AA484784MD28983@mail.timestep.com>
X-Mailer: ccMail Link to SMTP R8.00.00
Date: Fri, 09 Jul 99 19:40:19 -0500
To: <ipsec-policy@mail.timestep.com>
Subject: cc:Mail Link to SMTP Undeliverable Message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="simple boundary"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: ron_carter@netx1.nei.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 1036f143c707a3f0b3b649a52dbef451

Message is undeliverable.
Reason: User "rpluth@nei.com" is not found in the cc:Mail Directory.
Original text follows:
---------------------

Received: from mail.timestep.com by netx1.nei.com (ccMail Link to SMTP R8.00.00
)
        ; Fri, 09 Jul 99 19:40:15 -0500
Return-Path: <>
Received: from nutmeg.bbn.com [128.89.1.112] by mail.timestep.com [209.47.58.12
] with SMTP (MDaemon.v2.7.SP4.R) for <rpluth@nei.com>; Fri, 09 Jul 1999 19:33:5
4 -0400
Received: (from lsanchez@localhost)
        by nutmeg.bbn.com (8.8.8/8.8.7) id TAA01414
        for ipsec-policy@mail.timestep.com; Fri, 9 Jul 1999 19:32:49 -0400 (EDT
)
        (envelope-from lsanchez)
From: "Luis A. Sanchez" <lsanchez@bbn.com>
Message-ID: <MDAEMON-F199907091933.AA335461MD28641@mail.timestep.com>
Subject: IPSP Agenda (fwd)
To: ipsec-policy@mail.timestep.com
Date: Fri, 9 Jul 1999 19:32:49 -0400 (EDT)
Reply-To: ipsec-policy@mail.timestep.com
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: rpluth@nei.com
X-Return-Path: lsanchez@nutmeg.bbn.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]

----- Forwarded message from Luis A. Sanchez -----

>From POPmail Thu Jul  1 16:55:43 1999
From: "Luis A. Sanchez" <lsanchez@bbn.com>
Message-Id: <199907012054.QAA02568@nutmeg.bbn.com>
Subject: IPSP Agenda
To: agenda@ietf.org
Date: Thu, 1 Jul 1999 16:54:34 -0400 (EDT)
Cc: rpereira@timestep.com, lsanchez@bbn.com
Reply-to: lsanchez@bbn.com
X-Mailer: ELM [version 2.4ME+ PL32 (25)]

Enclosed you will find the preliminary agenda for IPSP. Thanks!

Luis


Preliminary Agenda
------------------

- Agenda Bashing                                               5 mins

o Unified IPsec policy model                                  15 mins
o Semantic Model of IPsec Policy                              15 mins
o Multi-Domain IKE                                            15 mins

- Charter Discussions                                         30 mins
- Collect feedback and modify charter                         15 mins
- Adjourn


----- End of forwarded message from Luis A. Sanchez -----



From ???@??? Sun Jul 11 16:07:30 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id RAA13148
        for <paul.hoffman@vpnc.org>; Fri, 9 Jul 1999 17:26:24 -0700 (PDT)
Received: from mail.mi.verio.com [209.69.6.110] by mail.timestep.com [209.47.58
.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Fri, 09 Jul 19
99 20:09:02 -0400
Received: from netx1.nei.com (netx1.nei.com [209.69.28.17])
        by mail.mi.verio.com (8.9.1/8.9.1) with SMTP id TAA16223
        for <ipsec-policy@mail.timestep.com>; Fri, 9 Jul 1999 19:53:51 -0400 (E
DT)
From: ron_carter@netx1.nei.com
Received: from ccMail by netx1.nei.com (ccMail Link to SMTP R8.00.00)
    id AA931564833; Fri, 09 Jul 99 20:00:35 -0500
Message-ID: <MDAEMON-F199907092009.AA090281MD29362@mail.timestep.com>
X-Mailer: ccMail Link to SMTP R8.00.00
Date: Fri, 09 Jul 99 20:00:33 -0500
To: <ipsec-policy@mail.timestep.com>
Subject: cc:Mail Link to SMTP Undeliverable Message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="simple boundary"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: ron_carter@netx1.nei.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: d6def00daf0333f7ad1e73f8db85a89a

Message is undeliverable.
Reason: User "rpluth@nei.com" is not found in the cc:Mail Directory.
Original text follows:
---------------------

Received: from mail.timestep.com by netx1.nei.com (ccMail Link to SMTP R8.00.00
)
        ; Fri, 09 Jul 99 20:00:30 -0500
Return-Path: <>
Received: from mail.mi.verio.com [209.69.6.110] by mail.timestep.com [209.47.58
.12] with SMTP (MDaemon.v2.7.SP4.R) for <rpluth@nei.com>; Fri, 09 Jul 1999 19:4
8:51 -0400
Received: from netx1.nei.com (netx1.nei.com [209.69.28.17])
        by mail.mi.verio.com (8.9.1/8.9.1) with SMTP id TAA14955
        for <ipsec-policy@mail.timestep.com>; Fri, 9 Jul 1999 19:33:38 -0400 (E
DT)
From: ron_carter@netx1.nei.com
Received: from ccMail by netx1.nei.com (ccMail Link to SMTP R8.00.00)
    id AA931563619; Fri, 09 Jul 99 19:40:22 -0500
Message-ID: <MDAEMON-F199907091948.AA485120MD29020@mail.timestep.com>
X-Mailer: ccMail Link to SMTP R8.00.00
Date: Fri, 09 Jul 99 19:40:19 -0500
To: <ipsec-policy@mail.timestep.com>
Subject: cc:Mail Link to SMTP Undeliverable Message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="simple boundary"
X-MDaemon-Deliver-To: rpluth@nei.com
X-Return-Path: ron_carter@netx1.nei.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com

Message is undeliverable.
Reason: User "rpluth@nei.com" is not found in the cc:Mail Directory.
Original text follows:
---------------------

Received: from mail.timestep.com by netx1.nei.com (ccMail Link to SMTP R8.00.00
)
        ; Fri, 09 Jul 99 19:40:15 -0500
Return-Path: <>
Received: from nutmeg.bbn.com [128.89.1.112] by mail.timestep.com [209.47.58.12
] with SMTP (MDaemon.v2.7.SP4.R) for <rpluth@nei.com>; Fri, 09 Jul 1999 19:33:5
4 -0400
Received: (from lsanchez@localhost)
        by nutmeg.bbn.com (8.8.8/8.8.7) id TAA01414
        for ipsec-policy@mail.timestep.com; Fri, 9 Jul 1999 19:32:49 -0400 (EDT
)
        (envelope-from lsanchez)
From: "Luis A. Sanchez" <lsanchez@bbn.com>
Message-ID: <MDAEMON-F199907091933.AA335461MD28641@mail.timestep.com>
Subject: IPSP Agenda (fwd)
To: ipsec-policy@mail.timestep.com
Date: Fri, 9 Jul 1999 19:32:49 -0400 (EDT)
Reply-To: ipsec-policy@mail.timestep.com
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: rpluth@nei.com
X-Return-Path: lsanchez@nutmeg.bbn.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]

----- Forwarded message from Luis A. Sanchez -----

>From POPmail Thu Jul  1 16:55:43 1999
From: "Luis A. Sanchez" <lsanchez@bbn.com>
Message-Id: <199907012054.QAA02568@nutmeg.bbn.com>
Subject: IPSP Agenda
To: agenda@ietf.org
Date: Thu, 1 Jul 1999 16:54:34 -0400 (EDT)
Cc: rpereira@timestep.com, lsanchez@bbn.com
Reply-to: lsanchez@bbn.com
X-Mailer: ELM [version 2.4ME+ PL32 (25)]

Enclosed you will find the preliminary agenda for IPSP. Thanks!

Luis


Preliminary Agenda
------------------

- Agenda Bashing                                               5 mins

o Unified IPsec policy model                                  15 mins
o Semantic Model of IPsec Policy                              15 mins
o Multi-Domain IKE                                            15 mins

- Charter Discussions                                         30 mins
- Collect feedback and modify charter                         15 mins
- Adjourn


----- End of forwarded message from Luis A. Sanchez -----



From ???@??? Mon Jul 12 17:09:47 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id HAA17176
        for <paul.hoffman@vpnc.org>; Mon, 12 Jul 1999 07:52:57 -0700 (PDT)
Received: from POP3.tu-dresden.de [141.30.2.83] by mail.timestep.com [209.47.58
.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Mon, 12 Jul 19
99 10:38:13 -0400
Received: from rmail.urz.tu-dresden.de by rks3 with SMTP (PP);
          Mon, 12 Jul 1999 16:36:03 +0200
Received: from rcs12.urz.tu-dresden.de by rmail with SMTP (IC-PP);
          Mon, 12 Jul 1999 16:26:38 +0200
Received: by rcs12.urz.tu-dresden.de (8.8.8) id QAA29020;
          Mon, 12 Jul 1999 16:36:36 +0200 (MET DST)
From: martius <martius@Rcs1.urz.tu-dresden.de>
Message-ID: <MDAEMON-F199907121038.AA381327MD29741@mail.timestep.com>
Subject: Re: IPSP Agenda (fwd)
In-Reply-To: <MDAEMON-F199907091934.AA340072MD28737@mail.timestep.com> from "Lu
is A. Sanchez" at "Jul 9, 99 07:32:49 pm"
To: ipsec-policy@mail.timestep.com
Date: Mon, 12 Jul 1999 16:36:36 +0200 (MET DST)
X-Mailer: ELM [version 2.4ME+ PL25 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: martius@rcs.urz.tu-dresden.de
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: b01cd2fab83eb38927115e7ea57064f8

Hi Luis,

saw you put MIKE on the agenda... great. (I recognized it early enough to
update my slides)

I met a lot of people here already, except you and Roy. Are you already
here in Oslo? We should make an appointment for Tuesday.

CU
Kai


From ???@??? Mon Jul 12 17:16:12 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id IAA17215
        for <paul.hoffman@vpnc.org>; Mon, 12 Jul 1999 08:22:35 -0700 (PDT)
Received: from mail.mi.verio.com [209.69.6.110] by mail.timestep.com [209.47.58
.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Mon, 12 Jul 19
99 10:57:05 -0400
Received: from netx1.nei.com (netx1.nei.com [209.69.28.17])
        by mail.mi.verio.com (8.9.1/8.9.1) with SMTP id KAA28480
        for <ipsec-policy@mail.timestep.com>; Mon, 12 Jul 1999 10:42:04 -0400 (
EDT)
From: ron_carter@netx1.nei.com
Received: from ccMail by netx1.nei.com (ccMail Link to SMTP R8.00.00)
    id AA931790931; Mon, 12 Jul 99 10:48:54 -0500
Message-ID: <MDAEMON-F199907121057.AA570565MD30120@mail.timestep.com>
X-Mailer: ccMail Link to SMTP R8.00.00
Date: Mon, 12 Jul 99 10:48:51 -0500
To: <ipsec-policy@mail.timestep.com>
Subject: cc:Mail Link to SMTP Undeliverable Message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="simple boundary"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: ron_carter@netx1.nei.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 05f160deb56ae88eb76f8634ec2ee2f5

Message is undeliverable.
Reason: User "rpluth@nei.com" is not found in the cc:Mail Directory.
Original text follows:
---------------------

Received: from mail.timestep.com by netx1.nei.com (ccMail Link to SMTP R8.00.00
)
        ; Mon, 12 Jul 99 10:48:45 -0500
Return-Path: <>
Received: from POP3.tu-dresden.de [141.30.2.83] by mail.timestep.com [209.47.58
.12] with SMTP (MDaemon.v2.7.SP4.R) for <rpluth@nei.com>; Mon, 12 Jul 1999 10:3
8:15 -0400
Received: from rmail.urz.tu-dresden.de by rks3 with SMTP (PP);
          Mon, 12 Jul 1999 16:36:03 +0200
Received: from rcs12.urz.tu-dresden.de by rmail with SMTP (IC-PP);
          Mon, 12 Jul 1999 16:26:38 +0200
Received: by rcs12.urz.tu-dresden.de (8.8.8) id QAA29020;
          Mon, 12 Jul 1999 16:36:36 +0200 (MET DST)
From: martius <martius@rcs.urz.tu-dresden.de>
Message-ID: <MDAEMON-F199907121038.AA381528MD29778@mail.timestep.com>
Subject: Re: IPSP Agenda (fwd)
In-Reply-To: <MDAEMON-F199907091934.AA340072MD28737@mail.timestep.com> from "Lu
is A. Sanchez" at "Jul 9, 99 07:32:49 pm"
To: ipsec-policy@mail.timestep.com
Date: Mon, 12 Jul 1999 16:36:36 +0200 (MET DST)
X-Mailer: ELM [version 2.4ME+ PL25 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: rpluth@nei.com
X-Return-Path: martius@rcs.urz.tu-dresden.de
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com

Hi Luis,

saw you put MIKE on the agenda... great. (I recognized it early enough to
update my slides)

I met a lot of people here already, except you and Roy. Are you already
here in Oslo? We should make an appointment for Tuesday.

CU
Kai


From ???@??? Mon Jul 12 17:16:12 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id IAA17232
        for <paul.hoffman@vpnc.org>; Mon, 12 Jul 1999 08:47:10 -0700 (PDT)
Received: from mail.mi.verio.com [209.69.6.110] by mail.timestep.com [209.47.58
.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Mon, 12 Jul 19
99 11:26:47 -0400
Received: from netx1.nei.com (netx1.nei.com [209.69.28.17])
        by mail.mi.verio.com (8.9.1/8.9.1) with SMTP id LAA03178
        for <ipsec-policy@mail.timestep.com>; Mon, 12 Jul 1999 11:11:44 -0400 (
EDT)
From: ron_carter@netx1.nei.com
Received: from ccMail by netx1.nei.com (ccMail Link to SMTP R8.00.00)
    id AA931792711; Mon, 12 Jul 99 11:18:34 -0500
Message-ID: <MDAEMON-F199907121126.AA264777MD30499@mail.timestep.com>
X-Mailer: ccMail Link to SMTP R8.00.00
Date: Mon, 12 Jul 99 11:18:31 -0500
To: <ipsec-policy@mail.timestep.com>
Subject: cc:Mail Link to SMTP Undeliverable Message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="simple boundary"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: ron_carter@netx1.nei.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: baac021c9d05de5fadfeca259988f2f8

Message is undeliverable.
Reason: User "rpluth@nei.com" is not found in the cc:Mail Directory.
Original text follows:
---------------------

Received: from mail.timestep.com by netx1.nei.com (ccMail Link to SMTP R8.00.00
)
        ; Mon, 12 Jul 99 11:18:26 -0500
Return-Path: <>
Received: from mail.mi.verio.com [209.69.6.110] by mail.timestep.com [209.47.58
.12] with SMTP (MDaemon.v2.7.SP4.R) for <rpluth@nei.com>; Mon, 12 Jul 1999 10:5
7:07 -0400
Received: from netx1.nei.com (netx1.nei.com [209.69.28.17])
        by mail.mi.verio.com (8.9.1/8.9.1) with SMTP id KAA28480
        for <ipsec-policy@mail.timestep.com>; Mon, 12 Jul 1999 10:42:04 -0400 (
EDT)
From: ron_carter@netx1.nei.com
Received: from ccMail by netx1.nei.com (ccMail Link to SMTP R8.00.00)
    id AA931790931; Mon, 12 Jul 99 10:48:54 -0500
Message-ID: <MDAEMON-F199907121057.AA570779MD30157@mail.timestep.com>
X-Mailer: ccMail Link to SMTP R8.00.00
Date: Mon, 12 Jul 99 10:48:51 -0500
To: <ipsec-policy@mail.timestep.com>
Subject: cc:Mail Link to SMTP Undeliverable Message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="simple boundary"
X-MDaemon-Deliver-To: rpluth@nei.com
X-Return-Path: ron_carter@netx1.nei.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com

Message is undeliverable.
Reason: User "rpluth@nei.com" is not found in the cc:Mail Directory.
Original text follows:
---------------------

Received: from mail.timestep.com by netx1.nei.com (ccMail Link to SMTP R8.00.00
)
        ; Mon, 12 Jul 99 10:48:45 -0500
Return-Path: <>
Received: from POP3.tu-dresden.de [141.30.2.83] by mail.timestep.com [209.47.58
.12] with SMTP (MDaemon.v2.7.SP4.R) for <rpluth@nei.com>; Mon, 12 Jul 1999 10:3
8:15 -0400
Received: from rmail.urz.tu-dresden.de by rks3 with SMTP (PP);
          Mon, 12 Jul 1999 16:36:03 +0200
Received: from rcs12.urz.tu-dresden.de by rmail with SMTP (IC-PP);
          Mon, 12 Jul 1999 16:26:38 +0200
Received: by rcs12.urz.tu-dresden.de (8.8.8) id QAA29020;
          Mon, 12 Jul 1999 16:36:36 +0200 (MET DST)
From: martius <martius@rcs.urz.tu-dresden.de>
Message-ID: <MDAEMON-F199907121038.AA381528MD29778@mail.timestep.com>
Subject: Re: IPSP Agenda (fwd)
In-Reply-To: <MDAEMON-F199907091934.AA340072MD28737@mail.timestep.com> from "Lu
is A. Sanchez" at "Jul 9, 99 07:32:49 pm"
To: ipsec-policy@mail.timestep.com
Date: Mon, 12 Jul 1999 16:36:36 +0200 (MET DST)
X-Mailer: ELM [version 2.4ME+ PL25 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: rpluth@nei.com
X-Return-Path: martius@rcs.urz.tu-dresden.de
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com

Hi Luis,

saw you put MIKE on the agenda... great. (I recognized it early enough to
update my slides)

I met a lot of people here already, except you and Roy. Are you already
here in Oslo? We should make an appointment for Tuesday.

CU
Kai


From ???@??? Thu Jul 15 16:20:17 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id FAA01244
        for <paul.hoffman@vpnc.org>; Thu, 15 Jul 1999 05:49:29 -0700 (PDT)
Received: from ctron-dnm.ctron.com [12.25.1.120] by mail.timestep.com [209.47.5
8.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Thu, 15 Jul 1
999 08:38:12 -0400
Received: (from uucp@localhost)
        by ctron-dnm.ctron.com (8.8.7/8.8.7) id IAA15765
        for <ipsec-policy@mail.timestep.com>; Thu, 15 Jul 1999 08:38:51 -0400 (
EDT)
Received: from roc-mail2.ctron.com(134.141.72.230) by ctron-dnm.ctron.com via s
map (4.1)
        id xma015718; Thu, 15 Jul 99 08:38:40 -0400
Received: from new-exc1.ctron.com (NEW-EXC1 [134.141.200.123])
        by roc-mail2.ctron.com (8.8.7/8.8.7) with ESMTP id IAA19918
        for <ipsec-policy@mail.timestep.com>; Thu, 15 Jul 1999 08:42:15 -0400 (
EDT)
Received: by new-exc1.ctron.com with Internet Mail Service (5.5.2448.0)
        id <38L7042H>; Thu, 15 Jul 1999 13:36:19 +0100
Message-ID: <MDAEMON-F199907150838.AA381280MD30888@mail.timestep.com>
From: "Waters, Stephen" <Stephen.Waters@cabletron.com>
To: ipsec-policy@mail.timestep.com
Subject: FW: Policy management, COPS, and SCVP
Date: Thu, 15 Jul 1999 13:36:18 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
        charset="iso-8859-1"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: Stephen.Waters@cabletron.com
Sender: BadMsgQ@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: [trash]
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 9d4387e1826b773f9366bf14a60b65bf

> Hi,
>
> Is anyone thinking much about policy management for IPSEC VPN
> clients? I've
> been reading a bit about Common Open Policy Service (COPS)
> which seems to
> offer a solution with 'dynamic' policy decisions.
>
> One thought I had when reading it, is that the COPS server (The Policy
> Decision Point - PDP), could be passed the client certificate
> to start the
> policy look-up. This would then allow the COPS server to do
> the job of SCVP
> as well:
>
> 1) check the certificate
> 2) return the appropriate policy, or reject.
>
> Steve.

-----Original Message-----
From: Tim Jenkins [mailto:tjenkins@TimeStep.com]
Sent: Thursday, July 15, 1999 10:54 AM
To: Waters, Stephen
Subject: RE: Policy management, COPS, and SCVP


Steve,

Just a comment on distribution; Are you reading the ipsp mailing list? It's
likely to become (or perhaps already has become) a WG, chaired by Luis
Sanchez and Roy Periera.

It's at ipsec-policy@mail.timestep.com

Your posting is perfect for that forum.

Tim

---
Tim Jenkins                       TimeStep Corporation
tjenkins@timestep.com          http://www.timestep.com
(613) 599-3610 x4304               Fax: (613) 599-3617



> -----Original Message-----
> From: Waters, Stephen [mailto:Stephen.Waters@cabletron.com]
> Sent: July 15, 1999 11:45 AM
> To: ipsec@lists.tislabs.com
> Subject: Policy management, COPS, and SCVP
>
>
>
> Hi,
>
> Is anyone thinking much about policy management for IPSEC VPN
> clients? I've
> been reading a bit about Common Open Policy Service (COPS)
> which seems to
> offer a solution with 'dynamic' policy decisions.
>
> One thought I had when reading it, is that the COPS server (The Policy
> Decision Point - PDP), could be passed the client certificate
> to start the
> policy look-up. This would then allow the COPS server to do
> the job of SCVP
> as well:
>
> 1) check the certificate
> 2) return the appropriate policy, or reject.
>
> Steve.
>



From ???@??? Tue Jul 20 09:35:34 1999
Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15])
        by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id EAA04009
        for <paul.hoffman@vpnc.org>; Tue, 20 Jul 1999 04:36:25 -0700 (PDT)
Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i
d <49639-29186>; Tue, 20 Jul 1999 07:37:53 -0400
Received: from zaphod.axion.bt.co.uk [132.146.5.1] by mail.timestep.com [209.47
.58.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Tue, 20 Jul
 1999 07:34:03 -0400
Received: from msn.bt.co.uk (actually goofy.msn.bt.co.uk) by zaphod.axion.bt.co
.uk with SMTP (PP);
          Tue, 20 Jul 1999 12:32:54 +0100
Received: from msn.bt.co.uk by msn.bt.co.uk (SMI-8.6/SMI-SVR4) id MAA13511; Tue
, 20 Jul 1999 12:37:55 +0100
Message-ID: <MDAEMON-F199907200734.AA340346MD31672@mail.timestep.com>
Date: Tue, 20 Jul 1999 07:32:48 -0400
From: Steve Forrester <steve@msn.bt.co.uk>
Reply-To: ipsec-policy@mail.timestep.com
Organization: British Telecommunications plc
X-Mailer: Mozilla 4.6 [en-gb] (Win95; U)
X-Accept-Language: en-GB,en,en-*
MIME-Version: 1.0
To: ipsec-policy@mail.timestep.com
Subject: (no subject)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: steve@msn.bt.co.uk
Sender: rpereira@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: rpereira@mail.timestep.com
X-UIDL: d3196ce10805477fe1fe64994d1cb2ca

subscribe



From ???@??? Fri Jul 23 15:49:32 1999
Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15])
        by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id PAA07647
        for <paul.hoffman@vpnc.org>; Fri, 23 Jul 1999 15:43:09 -0700 (PDT)
Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i
d <49735-17812>; Fri, 23 Jul 1999 18:45:08 -0400
Received: from ns.newbridge.com [192.75.23.67] by mail.timestep.com [209.47.58.
12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Fri, 23 Jul 199
9 15:35:17 -0400
Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id PAA11882
 for ipsec-policy@mail.timestep.com; Fri, 23 Jul 1999 15:34:26 -0400 (EDT)
Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.
ca.newbridge.com"
 via SMTP by ns.newbridge.com, id smtpdBAAa11855; Fri Jul 23 15:34:17 1999
Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP;
 Fri, 23 Jul 1999 15:34:16 -0400
Received: by exchange with Internet Mail Service (5.5.2232.9)
        id <N5H8AFAC>; Fri, 23 Jul 1999 15:37:10 -0400
Message-ID: <MDAEMON-F199907231535.AA351771MD36542@mail.timestep.com>
From: Andrew Milne <amilne@TimeStep.com>
To: ipsec-policy@mail.timestep.com
Cc: "'mcondell@bbn.com'" <mcondell@bbn.com>, "'clynn@bbn.com'" <clynn@bbn.com>,
        "'jzao@bbn.com'" <jzao@bbn.com>
Subject: SPSL draft V1 --  ipseccipher, ipsecintegrity formats
Date: Fri, 23 Jul 1999 15:37:04 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: amilne@TimeStep.com
Sender: rpereira@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: rpereira@mail.timestep.com
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 07a3b159797108ad0b96284843245e5a

Hi. I'm reading SPSL V1 (July 1, 1999, and yes, I know it wasn't posted to
this list, but it seems to me this is probably where I should be asking this
anyway), and I read in 5.3. IPSecPolicy Class, for ipseccipher:

         <ipseccipher> is a list of one or more of:
                  <ipseccipheralg> [keylen <integer-range>]
                  [rounds <integer-range>]

         <ipseccipheralg> is one of "any", "blowfish", "cast",
                  "des", "des3", "idea", "idea3", "none", "rc4",
                  "rc5", "rfc1829-iv32", "rfc1829-iv64", or an
                  <integer> as defined in [rfc2407], optionally
                  preceded by "not"

... and and for ipsecintegrityalg:

         <ipsecintegrity> is a list of one or more of:
                  <integrityalg> [keylen <integer-range>]

         <integrityalg> is one of "any", "hmacdes","hmacmd5",
                  "hmacsha1", "kpdk", or an <integer> as defined
                  in [rfc2407], optionally preceded by "not"

... but for the definition of ipcomp:

         <ipcompalg> is "any", or one or more of: "deflate", "lzs",
                  "oui", or an <integer> as defined in [rfc2407],
                  optionally preceded by "not"

... and for hashalg:

         <hashalg> is "any", or one or more of: "md5", "sha1", "tiger",
                  or an <integer> as defined in [rfc2409], optionally
                  preceded by "not"

So I get, legal for hashalg:

        a. any
        b. md5, tiger
        c. not (md5, tiger)

... which makes a certain amount of sense to me. And similarily, legal for
ipcomp:

        a. any
        b. deflate, oui
        c. not (deflate, oui)

... which also kinda makes sense. In contrast, for ipsecintegrity, I get,
all legal:

        a. any
        b. hmacdes, not hmacdes, hmacmd5
        c. hmacsha1, not kpdk...

... and similar for ipseccipher. My point being, for ipcomp and hashalg, the
spec seems successfully to rule out much that is contradictory or merely
annoying, whereas for ipseccipher and ipsecintegrityalg, it does not seem to
do so. I'd have pictured something like:

         <ipseccipher> is "any", or a list of one or more of:
                  <ipseccipheralg> [keylen <integer-range>]
                  [rounds <integer-range>], optionally
                  preceded by "not"

         <ipseccipheralg> is one of "blowfish", "cast",
                  "des", "des3", "idea", "idea3", "none", "rc4",
                  "rc5", "rfc1829-iv32", "rfc1829-iv64", or an
                  <integer> as defined in [rfc2407]

... or if the intent is to be able to specify a minimum keylength
independent of cipher algorithm:

         <ipseccipher> is "any" [keylen <integer-range>],
                  or a list of one or more of:
                  <ipseccipheralg> [keylen <integer-range>]
                  [rounds <integer-range>], optionally
                  preceded by "not"

... similar for ipsecintegrity. Or am I missing something here?

(Should say, seein' as I'm just delurking -- awesome spec, overall, thanks.)

Andrew Milne
Computer Systems Analyst
TimeStep Inc.
593 Herndon Parkway
Herndon, VA, USA 20170


From ???@??? Mon Jul 26 09:14:50 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id GAA28589
        for <paul.hoffman@vpnc.org>; Mon, 26 Jul 1999 06:33:44 -0700 (PDT)
Received: from wolfe.bbn.com [128.89.2.232] by mail.timestep.com [209.47.58.12]
 with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Mon, 26 Jul 1999 0
9:22:51 -0400
Received: (from mcondell@localhost)
        by wolfe.bbn.com (8.8.8/8.8.6) id JAA24273;
        Mon, 26 Jul 1999 09:21:11 -0400 (EDT)
Date: Mon, 26 Jul 1999 09:21:11 -0400 (EDT)
Message-ID: <MDAEMON-F199907260922.AA225173MD36966@mail.timestep.com>
From: Matthew Condell <mcondell@bbn.com>
To: ipsec-policy@mail.timestep.com
Cc: Andrew Milne <amilne@TimeStep.com>, clynn@bbn.com, jzao@bbn.com
Subject: Re: SPSL draft V1 --  ipseccipher, ipsecintegrity formats
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: mcondell@bbn.com
Sender: rpereira@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: rpereira@mail.timestep.com
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 4362d87dafb27bb178f35d40148b519a


>Hi. I'm reading SPSL V1 (July 1, 1999, and yes, I know it wasn't posted to
>this list, but it seems to me this is probably where I should be asking this
>anyway), and I read in 5.3. IPSecPolicy Class, for ipseccipher:
...
>         <hashalg> is "any", or one or more of: "md5", "sha1", "tiger",
>                  or an <integer> as defined in [rfc2409], optionally
>                  preceded by "not"
>
>So I get, legal for hashalg:
>
>       a. any
>       b. md5, tiger
>       c. not (md5, tiger)

Actually, the text was meant to describe:

        c. not md5, not tiger

It's written into the BNF in this fashion.

...

>... and similar for ipseccipher. My point being, for ipcomp and hashalg, the
>spec seems successfully to rule out much that is contradictory or merely
>annoying, whereas for ipseccipher and ipsecintegrityalg, it does not seem to
>do so. I'd have pictured something like:

But, yes this is a problem.  We make note of it in section 5.1 talking
about addresses where there is a similar problem.  Your interpretation
of c. above seems like a good solution to me.  If there are no objections,
I'll change all the occurances of 'list of [not] <element>' to
'[not] list of element'.  That should handle this problem everywhere it
occurs in the document.

Thanks for pointing this out.

Matt Condell
BBN Technologies



From ???@??? Wed Jul 28 09:15:48 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id FAA19438
        for <paul.hoffman@vpnc.org>; Wed, 28 Jul 1999 05:43:33 -0700 (PDT)
Received: from wolfe.bbn.com [128.89.2.232] by mail.timestep.com [209.47.58.12]
 with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Wed, 28 Jul 1999 0
8:33:26 -0400
Received: (from mcondell@localhost)
        by wolfe.bbn.com (8.8.8/8.8.6) id IAA05664;
        Wed, 28 Jul 1999 08:31:57 -0400 (EDT)
Date: Wed, 28 Jul 1999 08:31:57 -0400 (EDT)
Message-ID: <MDAEMON-F199907280833.AA332672MD38405@mail.timestep.com>
From: Matthew Condell <mcondell@bbn.com>
To: policy@raliegh.ibm.com
Cc: ipsec-policy@mail.timestep.com
Subject: Policy framework and IPsec policy
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: mcondell@bbn.com
Sender: rpereira@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: rpereira@mail.timestep.com
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 4d18d6272dec01ae0879a88ee60b7006


Hi,

I've been reviewing the policy WG drafts from the perspective
of IPsec policy.  My interest is more in framework issues than
data model/schema issues.  Most of my comments are based on
draft-ietf-policy-terms-02.txt.

In general, I believe the general policy framework works well
with the security policy framework, except it one basic assumption.
The general policy framework is based on an intra-domain model
where as IPsec policy MUST deal with inter-domain issues.

However, I think a few modifications to the model would allow
IPsec policy to fit in the framework, without disturbing the
intra-domain model that is already present.

In draft-ietf-policy-terms-02.txt:

Section 4.1:

For inter-domain policy negotiation, different domains will not
share a policy repository, so it is necessary for the PDPs to
be able to communicate with each other.  We should make sure
that the architecture does not prohibit this.

Section 5.10:

Inter-domain policy conflicts are not necessarily resolvable,
since it is not really possible to choose one conflicting
policy over the other.

Additionally, to allow inter-domain policy caching, it is necessary to
be able to maintain (either in the repository or PDP) policies in a
non-overlapping form. (draft-ietf-ipsec-spp-00.txt refers to
non-overlapping policies as decorrelated.) In decorrelated form, the
conditions of no two policies can be simultaneously satisfied.  The
framework must be able to support such a set of policies to enable it
to support IPsec policy.

This example shows why decorrelation is necessary for an inter-domain
policy framework.  (The example is from the Security Policy Sytem
Architecture draft which is not yet published.)

>Caching correlated policies can lead to incorrect policy
>implementation based on those cached policies, as the following
>example shows.
>
>           H1 --- SG1 --------- SG2 --- H2
>                   |             |  \__ H3
>                   |             |
>                  PS1           PS2
>
>PS2 contains the following policies in its master file:
>       src     dst     proto   direction       action
>   1)  *       H2      *       inbound         permit
>   2)  *       *       *       inbound         deny
>
>These two policies are correlated since all the selectors (src, dst,
>proto, and direction) overlap.  The following SPP exchanges occur:
>
>  1)  PS1 requests policy for H3.
>  2)  PS2 returns policy #2 to PS1 which then caches policy #2.
>  3)  PS1 now looks up the policy for H2 and discovers that it already
>      has a matching policy (policy #2) and uses that.
>
>This is clearly wrong, since policy #2 indicates that the
>communication to H2 should be denied, though PS2's policy actually
>indicates that it should be allowed.
>
>       The solution is to remove the ambiguities that may exist in
>the master file.  The policies of the master file MUST be decorrelated
>before they are entered into the Local Policy Database.  That is, the
>policies must be rewritten so that for every pair of policies there
>exists a selector for which there is a nil intersection between the
>values in both of the policies.
>
>The policies in the above example could be decorrelated as follows:
>       src     dst     proto   direction       action
>   1') *       H2      *       inbound         permit
>   2') *       not H2  *       inbound         deny
>
>Now the exchange is a bit different:
>   1)  PS1 requests policy for H3.
>   2)  PS2 returns policy #2' to PS1 which then caches policy #2'.
>   3)  PS1 now looks up the policy for H2, doesn't have a matching
>       policy, so it requests a policy for H2.
>   4)  PS2 returns policy #1' to PS1 which then caches policy #1',
>       which is the correct policy for H2.
>

These are the main points where I believe an IPsec policy framework
diverges from general policy framework.

Matthew Condell
BBN Technologies



From ???@??? Wed Jul 28 09:15:48 1999
Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15])
        by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id GAA19486
        for <paul.hoffman@vpnc.org>; Wed, 28 Jul 1999 06:07:38 -0700 (PDT)
Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i
d <55981-9983>; Wed, 28 Jul 1999 09:09:59 -0400
Received: from wolfe.bbn.com [128.89.2.232] by mail.timestep.com [209.47.58.12]
 with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Wed, 28 Jul 1999 0
8:36:48 -0400
Received: (from mcondell@localhost)
        by wolfe.bbn.com (8.8.8/8.8.6) id IAA05692;
        Wed, 28 Jul 1999 08:35:17 -0400 (EDT)
Date: Wed, 28 Jul 1999 08:35:17 -0400
Message-ID: <MDAEMON-F199907280836.AA364883MD38759@mail.timestep.com>
From: Matthew Condell <mcondell@bbn.com>
To: policy@raleigh.ibm.com
Cc: ipsec-policy@mail.timestep.com
Subject: Policy Framework and IPsec policy
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: mcondell@bbn.com
Sender: rpereira@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: rpereira@mail.timestep.com
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: b6c856fb15cfbc58b7f3b2f36b3467da


[Sorry for the repeated message to ipsec-policy.  The policy address
 is now spelled correctly]

Hi,

I've been reviewing the policy WG drafts from the perspective
of IPsec policy.  My interest is more in framework issues than
data model/schema issues.  Most of my comments are based on
draft-ietf-policy-terms-02.txt.

In general, I believe the general policy framework works well
with the security policy framework, except it one basic assumption.
The general policy framework is based on an intra-domain model
where as IPsec policy MUST deal with inter-domain issues.

However, I think a few modifications to the model would allow
IPsec policy to fit in the framework, without disturbing the
intra-domain model that is already present.

In draft-ietf-policy-terms-02.txt:

Section 4.1:

For inter-domain policy negotiation, different domains will not
share a policy repository, so it is necessary for the PDPs to
be able to communicate with each other.  We should make sure
that the architecture does not prohibit this.

Section 5.10:

Inter-domain policy conflicts are not necessarily resolvable,
since it is not really possible to choose one conflicting
policy over the other.

Additionally, to allow inter-domain policy caching, it is necessary to
be able to maintain (either in the repository or PDP) policies in a
non-overlapping form. (draft-ietf-ipsec-spp-00.txt refers to
non-overlapping policies as decorrelated.) In decorrelated form, the
conditions of no two policies can be simultaneously satisfied.  The
framework must be able to support such a set of policies to enable it
to support IPsec policy.

This example shows why decorrelation is necessary for an inter-domain
policy framework.  (The example is from the Security Policy Sytem
Architecture draft which is not yet published.)

>Caching correlated policies can lead to incorrect policy
>implementation based on those cached policies, as the following
>example shows.
>
>           H1 --- SG1 --------- SG2 --- H2
>                   |             |  \__ H3
>                   |             |
>                  PS1           PS2
>
>PS2 contains the following policies in its master file:
>       src     dst     proto   direction       action
>   1)  *       H2      *       inbound         permit
>   2)  *       *       *       inbound         deny
>
>These two policies are correlated since all the selectors (src, dst,
>proto, and direction) overlap.  The following SPP exchanges occur:
>
>  1)  PS1 requests policy for H3.
>  2)  PS2 returns policy #2 to PS1 which then caches policy #2.
>  3)  PS1 now looks up the policy for H2 and discovers that it already
>      has a matching policy (policy #2) and uses that.
>
>This is clearly wrong, since policy #2 indicates that the
>communication to H2 should be denied, though PS2's policy actually
>indicates that it should be allowed.
>
>       The solution is to remove the ambiguities that may exist in
>the master file.  The policies of the master file MUST be decorrelated
>before they are entered into the Local Policy Database.  That is, the
>policies must be rewritten so that for every pair of policies there
>exists a selector for which there is a nil intersection between the
>values in both of the policies.
>
>The policies in the above example could be decorrelated as follows:
>       src     dst     proto   direction       action
>   1') *       H2      *       inbound         permit
>   2') *       not H2  *       inbound         deny
>
>Now the exchange is a bit different:
>   1)  PS1 requests policy for H3.
>   2)  PS2 returns policy #2' to PS1 which then caches policy #2'.
>   3)  PS1 now looks up the policy for H2, doesn't have a matching
>       policy, so it requests a policy for H2.
>   4)  PS2 returns policy #1' to PS1 which then caches policy #1',
>       which is the correct policy for H2.
>

These are the main points where I believe the IPsec policy framework
diverges from general policy framework.

Matthew Condell
BBN Technologies



From ???@??? Wed Jul 28 10:48:26 1999
Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15])
        by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id KAA19929
        for <paul.hoffman@vpnc.org>; Wed, 28 Jul 1999 10:31:10 -0700 (PDT)
Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i
d <56493-23520>; Wed, 28 Jul 1999 13:33:08 -0400
Received: from smtprtp1.nortel.net [137.118.22.14] by mail.timestep.com [209.47
.58.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Wed, 28 Jul
 1999 13:15:51 -0400
Received: from zrchb213.us.nortel.com (actually zrchb213)
          by smtprtp1.nortel.net; Wed, 28 Jul 1999 13:13:17 -0400
Received: from zrtpd003.us.nortel.com ([47.140.224.137])
          by zrchb213.us.nortel.com
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.
0)
          id PYN10R7T; Wed, 28 Jul 1999 12:13:15 -0500
Received: from americasm01.nt.com (wppkhc0b.us.nortel.com [47.39.57.22])
          by zrtpd003.us.nortel.com
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.
0)
          id P3LNXN4M; Wed, 28 Jul 1999 13:13:17 -0400
Sender: "He Huang" <huanghe@nortelnetworks.com>
Message-ID: <MDAEMON-F199907281315.AA155134MD39116@mail.timestep.com>
Date: Wed, 28 Jul 1999 13:13:15 -0400
From: "He Huang" <huanghe@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.06 [en] (X11; U; HP-UX B.10.20 9000/712)
MIME-Version: 1.0
To: Matthew Condell <mcondell@bbn.com>, policy@raleigh.ibm.com,
        ipsec-policy@mail.timestep.com
Subject: Re: Policy Framework and IPsec policy
References: <199907281235.IAA05692@wolfe.bbn.com>
Content-Type: text/plain; charset=big5
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: huanghe@nortelnetworks.com
Sender: rpereira@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: rpereira@mail.timestep.com
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 930ebedee47d0d9b373dbc79abc758b0

Hi,

Certainly, before one policy is saved in policy repository/master
database, it's necessary to do conflict detection and resolution. The
question is that who is responsible for that work, PolicyFramework or
LDAP itself(Assume repository is LDAP directory). In addition, Policy
Framework suggests two solutions for policy conflict(
draft-strassner-policy- terms-00.txt): first matching rule and priority
rule. It seems not to work well in some situations. Any new solution for
policy conflict?

Matthew Condell wrote:
>
> [Sorry for the repeated message to ipsec-policy.  The policy address
>  is now spelled correctly]
>
> Hi,
>
> I've been reviewing the policy WG drafts from the perspective
> of IPsec policy.  My interest is more in framework issues than
> data model/schema issues.  Most of my comments are based on
> draft-ietf-policy-terms-02.txt.
>
> In general, I believe the general policy framework works well
> with the security policy framework, except it one basic assumption.
> The general policy framework is based on an intra-domain model
> where as IPsec policy MUST deal with inter-domain issues.
>
> However, I think a few modifications to the model would allow
> IPsec policy to fit in the framework, without disturbing the
> intra-domain model that is already present.
>
> In draft-ietf-policy-terms-02.txt:
>
> Section 4.1:
>
> For inter-domain policy negotiation, different domains will not
> share a policy repository, so it is necessary for the PDPs to
> be able to communicate with each other.  We should make sure
> that the architecture does not prohibit this.
>
> Section 5.10:
>
> Inter-domain policy conflicts are not necessarily resolvable,
> since it is not really possible to choose one conflicting
> policy over the other.
>
> Additionally, to allow inter-domain policy caching, it is necessary to
> be able to maintain (either in the repository or PDP) policies in a
> non-overlapping form. (draft-ietf-ipsec-spp-00.txt refers to
> non-overlapping policies as decorrelated.) In decorrelated form, the
> conditions of no two policies can be simultaneously satisfied.  The
> framework must be able to support such a set of policies to enable it
> to support IPsec policy.
>
> This example shows why decorrelation is necessary for an inter-domain
> policy framework.  (The example is from the Security Policy Sytem
> Architecture draft which is not yet published.)
>
> >Caching correlated policies can lead to incorrect policy
> >implementation based on those cached policies, as the following
> >example shows.
> >
> >           H1 --- SG1 --------- SG2 --- H2
> >                   |             |  \__ H3
> >                   |             |
> >                  PS1           PS2
> >
> >PS2 contains the following policies in its master file:
> >       src     dst     proto   direction       action
> >   1)  *       H2      *       inbound         permit
> >   2)  *       *       *       inbound         deny
> >
> >These two policies are correlated since all the selectors (src, dst,
> >proto, and direction) overlap.  The following SPP exchanges occur:
> >
> >  1)  PS1 requests policy for H3.
> >  2)  PS2 returns policy #2 to PS1 which then caches policy #2.
> >  3)  PS1 now looks up the policy for H2 and discovers that it already
> >      has a matching policy (policy #2) and uses that.
> >
> >This is clearly wrong, since policy #2 indicates that the
> >communication to H2 should be denied, though PS2's policy actually
> >indicates that it should be allowed.
> >
> >       The solution is to remove the ambiguities that may exist in
> >the master file.  The policies of the master file MUST be decorrelated
> >before they are entered into the Local Policy Database.  That is, the
> >policies must be rewritten so that for every pair of policies there
> >exists a selector for which there is a nil intersection between the
> >values in both of the policies.
> >
> >The policies in the above example could be decorrelated as follows:
> >       src     dst     proto   direction       action
> >   1') *       H2      *       inbound         permit
> >   2') *       not H2  *       inbound         deny
> >
> >Now the exchange is a bit different:
> >   1)  PS1 requests policy for H3.
> >   2)  PS2 returns policy #2' to PS1 which then caches policy #2'.
> >   3)  PS1 now looks up the policy for H2, doesn't have a matching
> >       policy, so it requests a policy for H2.
> >   4)  PS2 returns policy #1' to PS1 which then caches policy #1',
> >       which is the correct policy for H2.
> >
>
> These are the main points where I believe the IPsec policy framework
> diverges from general policy framework.
>
> Matthew Condell
> BBN Technologies


From ???@??? Wed Jul 28 12:01:48 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id KAA20004
        for <paul.hoffman@vpnc.org>; Wed, 28 Jul 1999 10:59:25 -0700 (PDT)
Received: from wolfe.bbn.com [128.89.2.232] by mail.timestep.com [209.47.58.12]
 with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Wed, 28 Jul 1999 1
3:48:15 -0400
Received: (from mcondell@localhost)
        by wolfe.bbn.com (8.8.8/8.8.6) id NAA07663;
        Wed, 28 Jul 1999 13:46:40 -0400 (EDT)
Date: Wed, 28 Jul 1999 13:46:40 -0400 (EDT)
Message-ID: <MDAEMON-F199907281348.AA481576MD39469@mail.timestep.com>
From: Matthew Condell <mcondell@bbn.com>
To: "He Huang" <huanghe@nortelnetworks.com>
Cc: policy@raleigh.ibm.com, ipsec-policy@mail.timestep.com
References: <379F3A2B.9AC82B6D@americasm01.nt.com>
Subject: Re: Policy Framework and IPsec policy
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: mcondell@bbn.com
Sender: rpereira@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: rpereira@mail.timestep.com
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: d6d650301ba0c836c594bf10e367bd1b


Hi,

>Certainly, before one policy is saved in policy repository/master
>database, it's necessary to do conflict detection and resolution. The
>question is that who is responsible for that work, PolicyFramework or
>LDAP itself(Assume repository is LDAP directory). In addition, Policy
>Framework suggests two solutions for policy conflict(
>draft-strassner-policy- terms-00.txt): first matching rule and priority
>rule. It seems not to work well in some situations. Any new solution for
>policy conflict?

There are really two levels of conflict resolution when dealing with
inter-domain policy.  The intra-domain conflict resolution which can
be solved using first match or priorities.

Inter-domain conflict resolution is different, however.  If two
policies that are from different domains conflict about a particular
communication, there is no appropriate resolution since the two
policies are established by two different administrative domains. The
communication may just not be possible.  The framework should
acknowledge this possiblility to not exclude inter-domain policy from
fitting withing the framework.

Matthew Condell
BBN Technologies



From ???@??? Wed Jul 28 12:01:48 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id LAA20057
        for <paul.hoffman@vpnc.org>; Wed, 28 Jul 1999 11:23:27 -0700 (PDT)
Received: from alms1.fw.att.com [192.128.167.146] by mail.timestep.com [209.47.
58.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Wed, 28 Jul
1999 14:11:50 -0400
Received: from qsun.ho.att.com ([135.16.30.2])
        by alms1.fw.att.com (AT&T IPNS/MS-2.2) with SMTP id OAA00742;
        Wed, 28 Jul 1999 14:10:21 -0400 (EDT)
Received: from schooner.local.windrose.omaha.ne.us by qsun.ho.att.com (SMI-8.6/
EMS-1.2 sol2)
        id OAA17595; Wed, 28 Jul 1999 14:10:19 -0400
From: "Ryan Moats" <jayhawk@att.com>
To: "Matthew Condell" <mcondell@bbn.com>,
        "He Huang" <huanghe@nortelnetworks.com>
Cc: <policy@raleigh.ibm.com>, <ipsec-policy@mail.timestep.com>
Subject: RE: Policy Framework and IPsec policy
Date: Wed, 28 Jul 1999 13:08:16 -0500
Message-ID: <MDAEMON-F199907281411.AA115078MD39822@mail.timestep.com>
MIME-Version: 1.0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
In-Reply-To: <199907281746.NAA07663@wolfe.bbn.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Importance: Normal
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: jayhawk@att.com
Sender: rpereira@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: rpereira@mail.timestep.com
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: b37904072c2b981c1ec44f300e07944c

| Hi,
|
| >Certainly, before one policy is saved in policy repository/master
| >database, it's necessary to do conflict detection and resolution. The
| >question is that who is responsible for that work, PolicyFramework or
| >LDAP itself(Assume repository is LDAP directory). In addition, Policy
| >Framework suggests two solutions for policy conflict(
| >draft-strassner-policy- terms-00.txt): first matching rule and priority
| >rule. It seems not to work well in some situations. Any new solution for
| >policy conflict?
|
| There are really two levels of conflict resolution when dealing with
| inter-domain policy.  The intra-domain conflict resolution which can
| be solved using first match or priorities.
|
| Inter-domain conflict resolution is different, however.  If two
| policies that are from different domains conflict about a particular
| communication, there is no appropriate resolution since the two
| policies are established by two different administrative domains. The
| communication may just not be possible.  The framework should
| acknowledge this possiblility to not exclude inter-domain policy from
| fitting withing the framework.

Just a technology note.  LDAP is not going to do conflict resolution
beyond anything provided by LDUP (replication conflict resolution).
Conflict resolution that involves syntactical interpretation of the data
is not something LDAP does (or was ever intended to do).

Ryan



From ???@??? Thu Jul 29 13:45:00 1999
Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15])
        by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id NAA00667
        for <paul.hoffman@vpnc.org>; Thu, 29 Jul 1999 13:02:10 -0700 (PDT)
Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i
d <50308-5253>; Thu, 29 Jul 1999 16:04:39 -0400
Received: from diablo.cisco.com [171.68.224.210] by mail.timestep.com [209.47.5
8.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Thu, 29 Jul 1
999 15:47:41 -0400
Received: from jschnizl1-pc.cisco.com (jschnizl-isdn.cisco.com [171.70.238.115]
) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id MAA271
70; Thu, 29 Jul 1999 12:45:36 -0700 (PDT)
Message-ID: <MDAEMON-F199907291547.AA474117MD43310@mail.timestep.com>
X-Sender: jschnizl@diablo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Thu, 29 Jul 1999 15:45:06 -0400
To: "He Huang" <huanghe@nortelnetworks.com>,
        Matthew Condell <mcondell@bbn.com>, policy@raleigh.ibm.com,
        ipsec-policy@mail.timestep.com
From: John Schnizlein <jschnizl@cisco.com>
Subject: Re: Policy Framework and IPsec policy
In-Reply-To: <379F3A2B.9AC82B6D@americasm01.nt.com>
References: <199907281235.IAA05692@wolfe.bbn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: jschnizl@cisco.com
Sender: rpereira@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: rpereira@mail.timestep.com
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 598702fa343cbb9a3ccf472cd522d3d9

At 01:13 PM 07/28/1999 -0400, He Huang wrote:
>
>Certainly, before one policy is saved in policy repository/master
>database, it's necessary to do conflict detection and resolution. The
>question is that who is responsible for that work, PolicyFramework or
>LDAP itself (Assume repository is LDAP directory)...

This is not the question. An LDAP (repository) cannot be responsible
for detecting and resolving conflicts in the semantics of a policy.
Its capability is limited to detecting conflicts (most would call
these attribute or syntax violation rather than conflicts) between
input attributes/values and the schema.

Matthew's point is that there are potential semantic conflicts between
different administrative domains even after all internal conflicts are
resolved in each domain. The assumption is that some negotiation is
necessary between the domains. If I understand his proposal, this
negotiation is easier if those rules that might conflict (are relevant
to the other domain) are separated and disambiguated with those of the
other domain as early in the process as possible.

Even though this proposal requires an explicit negotiation cycle, in
addition to a distinction in the policy store we have not considered
in the policy framework WG, is much more attractive than surprises
when the execution of policy is other than what was intended.

Have security folks determined if there is sufficient value in keeping
policy for different domains in separate subtrees of the DIT?

John



From ???@??? Fri Jul 30 07:58:05 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id GAA09637
        for <paul.hoffman@vpnc.org>; Fri, 30 Jul 1999 06:48:29 -0700 (PDT)
Received: from alcor.process.com [192.42.95.16] by mail.timestep.com [209.47.58
.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Fri, 30 Jul 19
99 09:35:19 -0400
Received: from bvolz (192.42.95.238) by alcor.process.com (MX V5.1-X A2w8g)
          with SMTP; Fri, 30 Jul 1999 09:33:20 -0400
Message-ID: <MDAEMON-F199907300935.AA351978MD43694@mail.timestep.com>
From: "Bernie Volz" <volz@process.com>
To: "Matthew Condell" <mcondell@BBN.COM>, <policy@raleigh.ibm.com>
CC: <ipsec-policy@mail.timestep.com>
References: <199907281235.IAA05692@wolfe.bbn.com>
Subject: Re: Policy Framework and IPsec policy
Date: Fri, 30 Jul 1999 09:30:43 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: volz@process.com
Sender: rpereira@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: rpereira@mail.timestep.com
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 1537b076cb5489a102b3260f2f9d2d74

FYI - Have implemented NFS (and other caching protocols) on platforms that
were not native to NFS, I have one piece of advice for doing caching. It is
best to use cached data ONLY when the question is the same. So, in your
examples, PS1 could only use the cached data (that it got for H3) if it was
again trying to see what the policies were for H3. It could not use it if it
was asking what the policies where for H1. The more complex a system of
conditions you have, the more important this becomes. I feel the PS<n> can
not assume that information it got about one question applies to a
completely different question. This does make caching less useful (and
requires the cache to store much more), but it really is the only safe way
to go, IMHO.

It also avoids your problem (though it doesn't resolve the issue of
conflicting policies in separate administrative domains).

- Bernie Volz
  Process Software

----- Original Message -----
From: Matthew Condell <mcondell@BBN.COM>
To: <policy@raleigh.ibm.com>
Cc: <ipsec-policy@mail.timestep.com>
Sent: Wednesday, July 28, 1999 8:35 AM
Subject: Policy Framework and IPsec policy


>
> [Sorry for the repeated message to ipsec-policy.  The policy address
>  is now spelled correctly]
>
> Hi,
>
> I've been reviewing the policy WG drafts from the perspective
> of IPsec policy.  My interest is more in framework issues than
> data model/schema issues.  Most of my comments are based on
> draft-ietf-policy-terms-02.txt.
>
> In general, I believe the general policy framework works well
> with the security policy framework, except it one basic assumption.
> The general policy framework is based on an intra-domain model
> where as IPsec policy MUST deal with inter-domain issues.
>
> However, I think a few modifications to the model would allow
> IPsec policy to fit in the framework, without disturbing the
> intra-domain model that is already present.
>
> In draft-ietf-policy-terms-02.txt:
>
> Section 4.1:
>
> For inter-domain policy negotiation, different domains will not
> share a policy repository, so it is necessary for the PDPs to
> be able to communicate with each other.  We should make sure
> that the architecture does not prohibit this.
>
> Section 5.10:
>
> Inter-domain policy conflicts are not necessarily resolvable,
> since it is not really possible to choose one conflicting
> policy over the other.
>
> Additionally, to allow inter-domain policy caching, it is necessary to
> be able to maintain (either in the repository or PDP) policies in a
> non-overlapping form. (draft-ietf-ipsec-spp-00.txt refers to
> non-overlapping policies as decorrelated.) In decorrelated form, the
> conditions of no two policies can be simultaneously satisfied.  The
> framework must be able to support such a set of policies to enable it
> to support IPsec policy.
>
> This example shows why decorrelation is necessary for an inter-domain
> policy framework.  (The example is from the Security Policy Sytem
> Architecture draft which is not yet published.)
>
> >Caching correlated policies can lead to incorrect policy
> >implementation based on those cached policies, as the following
> >example shows.
> >
> >           H1 --- SG1 --------- SG2 --- H2
> >                   |             |  \__ H3
> >     |             |
> >    PS1           PS2
> >
> >PS2 contains the following policies in its master file:
> > src dst proto direction action
> >   1) * H2 * inbound permit
> >   2) * * * inbound deny
> >
> >These two policies are correlated since all the selectors (src, dst,
> >proto, and direction) overlap.  The following SPP exchanges occur:
> >
> >  1)  PS1 requests policy for H3.
> >  2)  PS2 returns policy #2 to PS1 which then caches policy #2.
> >  3)  PS1 now looks up the policy for H2 and discovers that it already
> >      has a matching policy (policy #2) and uses that.
> >
> >This is clearly wrong, since policy #2 indicates that the
> >communication to H2 should be denied, though PS2's policy actually
> >indicates that it should be allowed.
> >
> > The solution is to remove the ambiguities that may exist in
> >the master file.  The policies of the master file MUST be decorrelated
> >before they are entered into the Local Policy Database.  That is, the
> >policies must be rewritten so that for every pair of policies there
> >exists a selector for which there is a nil intersection between the
> >values in both of the policies.
> >
> >The policies in the above example could be decorrelated as follows:
> > src dst proto direction action
> >   1') * H2 * inbound permit
> >   2') * not H2 * inbound deny
> >
> >Now the exchange is a bit different:
> >   1)  PS1 requests policy for H3.
> >   2)  PS2 returns policy #2' to PS1 which then caches policy #2'.
> >   3)  PS1 now looks up the policy for H2, doesn't have a matching
> >       policy, so it requests a policy for H2.
> >   4)  PS2 returns policy #1' to PS1 which then caches policy #1',
> >       which is the correct policy for H2.
> >
>
> These are the main points where I believe the IPsec policy framework
> diverges from general policy framework.
>
> Matthew Condell
> BBN Technologies
>
>



From ???@??? Fri Jul 30 13:32:39 1999
Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15])
        by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id LAA10219
        for <paul.hoffman@vpnc.org>; Fri, 30 Jul 1999 11:42:10 -0700 (PDT)
Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i
d <75194-18971>; Fri, 30 Jul 1999 11:10:20 -0400
Received: from wolfe.bbn.com [128.89.2.232] by mail.timestep.com [209.47.58.12]
 with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Fri, 30 Jul 1999 1
0:54:08 -0400
Received: (from mcondell@localhost)
        by wolfe.bbn.com (8.8.8/8.8.6) id KAA18980;
        Fri, 30 Jul 1999 10:52:49 -0400 (EDT)
Date: Fri, 30 Jul 1999 10:52:49 -0400
Message-ID: <MDAEMON-F199907301054.AA540870MD44046@mail.timestep.com>
From: Matthew Condell <mcondell@bbn.com>
To: policy@raleigh.ibm.com
Cc: ipsec-policy@mail.timestep.com
References: <000901beda8f$b9fd0d20$69e98018@process.com>
Subject: Re: Policy Framework and IPsec policy
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: mcondell@bbn.com
Sender: rpereira@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: rpereira@mail.timestep.com
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: e7548d62a69f7797deaf238aaadcf40b


Caching policies from another server is actually safe, if you can
guarantee that all the servers keep their policies in a decorrelated
form.  (More on this below.)  The system we have for exchanging IPsec
policies requires all policies to be decorrelated, so our policy
servers *can* assume that information it got about one question
applies to a completely different question, if the conditions match.

Decorrelation is a process that removes all overlap of the conditions
in a set of policy rules.  The process maintains the implicit
information about the policies that is contained in the rule ordering
(using either first match or priorities).  As a result, a question
can only match the conditions of *one* policy rule.  Also there is no
longer any need to order the policies.

Decorrelation is explained in more detail in draft-ietf-ipsec-sps-00.txt.
An algorithm for decorrelation is also presented there.  (The draft
has expired, but is still in the drafts repository.  The draft is
currently being reworked and split into multiple drafts.  The new
draft with the decorrelation process is still in the works.)

My main concern here is to make sure that the policy framework doesn't
prohibit policies to be stored in the repository in a decorrelated
form so that an inter-domain policy protocol that requires
decorrelation will still fit into the gereral policy framework.

Matthew Condell
BBN Technologies

>FYI - Have implemented NFS (and other caching protocols) on platforms that
>were not native to NFS, I have one piece of advice for doing caching. It is
>best to use cached data ONLY when the question is the same. So, in your
>examples, PS1 could only use the cached data (that it got for H3) if it was
>again trying to see what the policies were for H3. It could not use it if it
>was asking what the policies where for H1. The more complex a system of
>conditions you have, the more important this becomes. I feel the PS<n> can
>not assume that information it got about one question applies to a
>completely different question. This does make caching less useful (and
>requires the cache to store much more), but it really is the only safe way
>to go, IMHO.


From ???@??? Mon Aug 02 09:04:38 1999
Received: from mail2.uunet.ca (root@mail2.uunet.ca [142.77.1.15])
        by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id IAA25776
        for <paul.hoffman@vpnc.org>; Mon, 2 Aug 1999 08:50:20 -0700 (PDT)
Received: from mail.timestep.com ([209.47.58.12]) by mail2.uunet.ca with SMTP i
d <56148-9537>; Mon, 2 Aug 1999 11:53:04 -0400
Received: from ns.newbridge.com [192.75.23.67] by mail.timestep.com [209.47.58.
12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Mon, 02 Aug 199
9 11:41:44 -0400
Received: (from smtpd@localhost) by ns.newbridge.com (8.8.8/8.6.12) id LAA01933
 for ipsec-policy@mail.timestep.com; Mon, 2 Aug 1999 11:40:11 -0400 (EDT)
Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.
ca.newbridge.com"
 via SMTP by ns.newbridge.com, id smtpdCAAa01874; Mon Aug  2 11:40:03 1999
Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP;
 Mon, 2 Aug 1999 11:40:01 -0400
Received: by exchange with Internet Mail Service (5.5.2232.9)
        id <N5H8A3HK>; Mon, 2 Aug 1999 11:42:31 -0400
Message-ID: <MDAEMON-F199908021141.AA414481MD44410@mail.timestep.com>
From: Andrew Milne <amilne@TimeStep.com>
To: "'ipsec-policy@timestep.com'" <ipsec-policy@TimeStep.com>,
        policy@raleigh.ibm.com
Cc: ipsec-policy@mail.timestep.com, Paul Kierstead <pkierstead@TimeStep.com>
Subject: RE: Policy Framework and IPsec policy
Date: Mon, 2 Aug 1999 11:42:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: amilne@TimeStep.com
Sender: rpereira@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: rpereira@mail.timestep.com
Reply-To: ipsec-policy@mail.timestep.com
X-UIDL: 3204b17d9884399d991bbc2f4493cc04

<snip>

> My main concern here is to make sure that the policy framework doesn't
> prohibit policies to be stored in the repository in a decorrelated
> form so that an inter-domain policy protocol that requires
> decorrelation will still fit into the gereral policy framework.

> Matthew Condell
> BBN Technologies

<snip>

Just noting that our work within TimeStep R&D (IPSec SVPN stuff) on this
issue leaves me wishing wholeheartedly to express my support of this goal.
BBN's SPS draft struck us at the time as an excellent expression of a
well-thought-out mechanism, and the essential logic of having an
organization's policy server

        (1) Cache policy directives received from domains outside that
organization's control, with the assumption made that the server that sent
this directive had arranged that the directive would be an accurate
expression of the policy it enforces in isolation from any other rules
(achieved via decorrelation), and
        (2) Keep those directives separate from that organization's own,
internal, rules, so that organization can distinguish them and resolve them
properly with its own (a process somewhat different from resolution between
intra-domain rules, as Mr. Condell has previously noted in this thread)

.. is the kind of very workable approach to the problem on which I suspect
all other solutions are likely to converge anyway.

I'll note also that John Schlinzen's earlier comment re keeping policy for
different domains in different subtrees of the DIT does strike me as one
potential mechanism for keeping those rules separate.

As an additional comment, given adoption of such a mechanism, I think we do
need to keep two of these problem areas somewhat discrete for the purposes
of clear discussion: there's (1) decorrelation of rules affecting the same
domain, where those rules were probably all written by the same agent with
the understanding that they are to be understood in a common context
(decorrelation meaning they now work outside the context of the accompanying
rules), and (2) resolution of the sensible action for equipment to take when
rules expressed by different agents, controlling different domains,
conflict. The fact that the mechanism of resolution is likely to be similar
probably shouldn't be allowed to obscure the essential differences between
these problems in discussion or in the text of the drafts.

Andrew Milne
Computer Systems Analyst
TimeStep Inc.
593 Herndon Parkway
Herndon, VA, USA 20170



From ???@??? Thu Aug 26 12:14:41 1999
Received: from mail.timestep.com ([209.47.58.12])
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id LAA03539
        for <paul.hoffman@vpnc.org>; Thu, 26 Aug 1999 11:45:13 -0700 (PDT)
Received: from nutmeg.bbn.com [128.89.1.112] by mail.timestep.com [209.47.58.12
] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Thu, 26 Aug 1999
12:04:31 -0400
Received: (from lsanchez@localhost)
        by nutmeg.bbn.com (8.8.8/8.8.7) id LAA02876;
        Thu, 26 Aug 1999 11:54:09 -0400 (EDT)
        (envelope-from lsanchez)
From: "Luis A. Sanchez" <lsanchez@bbn.com>
Message-ID: <MDAEMON-F199908261204.AA043195MD48032@mail.timestep.com>
Subject: Re: FYI
In-Reply-To: <199908250341.XAA141532@northrelay03.pok.ibm.com> from Bert Wijnen
 at "Aug 25, 99 05:39:13 am"
To: WIJNEN@vnet.ibm.com (Bert Wijnen)
Date: Thu, 26 Aug 1999 11:54:09 -0400 (EDT)
Cc: raiken@cisco.com, POLICY@raleigh.ibm.com, rap@iphighway.com,
        diffserv@external.cisco.com, ipsec-policy@mail.timestep.com,
        ipsec@lists.tislabs.com, mleech@nortelnetworks.com, jis@mit.edu
Reply-To: ipsec-policy@mail.timestep.com
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org
X-Return-Path: lsanchez@nutmeg.bbn.com
Sender: rpereira@mail.timestep.com
X-MDMailing-List: ipsec-policy@mail.timestep.com
X-MDSend-Notifications-To: rpereira@mail.timestep.com
X-UIDL: 52da3d264c20ed11eaa72d15067727f0

Bert,

        One of the goals of IPSP is to specify a data model for
supporting IP security policies. This task requires at a minimum that
we work closely with the Policy Framework WG to ensure that the IPsec
data model fits within the general Policy Framework. Our folks have
been working on these issues for some time: we have authored several
documents; and, we have running code. It would be a pity to be
excluded from this meeting. We all know that QoS without security
won't do the trick so we may as well start working together now.

Luis


> Ref:  Your note of Mon, 23 Aug 1999 07:05:55 -0400
>
> Subject: Re:   FYI
>
> Bob wrote/asked w.r.t. diffserv/policy/rap meeting
> > Given the interaction between policy wrt security , Diffserv and others sho
uld't
> > the group also include security folks?
> >
> The reason we're getting these 3 WGs together is because they
> have items in their charters that together will make up the
> complete work for QoS. So it is to make sure QoS policy
> work will be done properly and such that all pieces fit together
> as one solution. So they/we have immediate need to get this
> on the table.
>
> Also, the group is already bigger than I like, so I would prefer to
> not get the IPSP people involved in this thing right now.
> Of course they can provide input on the above 3 mailing lists
> and they can also see the results/recomendations that will
> come out of the meeting.
>
> Bert
>


From ???@??? Thu Aug 26 12:14:41 1999
Received: from mail.timestep.com ([209.47.58.12]) 
        by mail.vpnc.org (8.9.3/8.9.0) with SMTP id PAA29086 
        for <paul.hoffman@vpnc.org>; Wed, 13 Oct 1999 15:51:30 -0700 (PDT) 
Received: from omega.cisco.com [171.69.63.141] by mail.timestep.com [209.47.58.12] with SMTP (MDaemon.v2.7.SP4.R) for <paul.hoffman@vpnc.org>; Wed, 13 Oct 1999 18:42:00 -0400 
Received: from cisco.com (ottawa-dhcp-163.cisco.com [171.70.78.163]) 
        by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id PAA01515 
        for <ipsec-policy@mail.timestep.com>; Wed, 13 Oct 1999 15:40:31 -0700 (PDT) 
Message-ID: <MDAEMON-F199910131842.AA420034MD52292@mail.timestep.com> 
Date: Wed, 13 Oct 1999 18:38:46 -0700 
From: Roy Pereira <royp@cisco.com> 
Organization: Cisco Systems, Inc. 
X-Mailer: Mozilla 4.5 [en] (Win95; U) 
X-Accept-Language: en 
MIME-Version: 1.0 
To: ipsec-policy@mail.timestep.com 
Subject: moving of mailing list 
Content-Type: text/plain; charset=us-ascii 
Content-Transfer-Encoding: 7bit 
X-MDaemon-Deliver-To: paul.hoffman@vpnc.org 
X-Return-Path: royp@cisco.com 
Sender: rpereira@mail.timestep.com 
X-MDMailing-List: ipsec-policy@mail.timestep.com 
X-MDSend-Notifications-To: rpereira@mail.timestep.com 
Reply-To: ipsec-policy@mail.timestep.com 
X-UIDL: de21811e0931b997434f87ae06405ecb 


Please be advised that I will be moving this mailing list from its
current server to a VPNC server.  All of your subscription information
will be kept intact.  


Paul Hoffman of VPNC will send out an email when this transfer has been
completed and the new email address and archives for the mailing list.


Thanks.



---
Roy Pereira
Product Line Manager, VPN - Security Internetworking SU
Cisco Systems, Inc.


From ???@??? Thu Aug 26 12:14:41 1999
Received: by mail.vpnc.org (8.9.3/8.9.0) id QAA29115 
        for ipsec-policy-bks; Wed, 13 Oct 1999 16:05:56 -0700 (PDT) 
X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ipsec-policy@mail.vpnc.org using -f 
Received: from mail.imc.org (ns.secondary.com [208.184.76.39]) 
        by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id QAA29111 
        for <ipsec-policy@vpnc.org>; Wed, 13 Oct 1999 16:05:54 -0700 (PDT) 
Received: from Default (ip12.proper.com [165.227.249.12]) 
        by mail.imc.org (8.9.3/8.9.3) with ESMTP id QAA16722 
        for <ipsec-policy@vpnc.org>; Wed, 13 Oct 1999 16:05:40 -0700 (PDT) 
Message-Id: <4.2.0.58.19991013160026.00d1d210@mail.imc.org> 
X-Sender: phoffman@mail.imc.org 
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 13 Oct 1999 16:07:34 -0700 
To: ipsec-policy@vpnc.org 
From: Paul Hoffman / IMC <phoffman@imc.org> 
Subject: New address for the ipsec-policy mailing list 
Mime-Version: 1.0 
Content-Type: text/plain; charset="us-ascii"; format=flowed 
Sender: owner-ipsec-policy@mail.vpnc.org 
Precedence: bulk 
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/> 
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe> 
X-UIDL: 719380c2aaa36f93fc6d1026fe1cc86f 


Greetings. As Roy said in his message, the mailing list has moved to
VPNC. The new list address is:
     ipsec-policy@vpnc.org
To unsubscribe from the list, send a message to:
     ipsec-policy-request@vpnc.org
with the single word "unsubscribe" in the body of the message.


For those of you who have lost track of the discussion, there is a
web site with an archive at <http://www.vpnc.org/ipsec-policy>.
That page also has links to the latest copies of the relevant
Internet Drafts.


--Paul Hoffman, Director
--Internet Mail Consortium
From owner-ipsec-policy@mail.vpnc.org  Thu Oct 14 12:28:25 1999
Received: from mail.vpnc.org (back.vpnc.org [165.227.249.9])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id MAA26009
	for <ipsec-policy@imc.org>; Thu, 14 Oct 1999 12:28:25 -0700 (PDT)
Received: by mail.vpnc.org (8.9.3/8.9.0) id MAA01633
	for ipsec-policy-bks; Thu, 14 Oct 1999 12:25:54 -0700 (PDT)
X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ipsec-policy@mail.vpnc.org using -f
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id MAA01628
	for <ipsec-policy@vpnc.org>; Thu, 14 Oct 1999 12:25:48 -0700 (PDT)
Received: from cisco.com (ottawa-dhcp-152.cisco.com [171.70.78.152])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id MAA06904;
	Thu, 14 Oct 1999 12:26:33 -0700 (PDT)
Message-ID: <38065830.752FE34D@cisco.com>
Date: Thu, 14 Oct 1999 15:24:49 -0700
From: Roy Pereira <royp@cisco.com>
Organization: Cisco Systems, Inc.
X-Mailer: Mozilla 4.5 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec-policy@mail.timestep.com, phoffman@mail.imc.org,
        ipsec-policy@vpnc.org, skelly@redcreek.com
Subject: Re: Fwd: Re: Pardon me...
References: <19991014191830.21661.qmail@hotmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

The reason for moving the mailing list was because I have changed jobs
and moved on to Cisco Systems (see signature below).  

Unforetunately, Cisco didn't purchase TimeStep as Dan asks, but TimeStep
was purchased by Newbridge.

My new email address is <royp@cisco.com>.

-- 
Roy Pereira
Product Line Manager, VPN - Security Internetworking SU
Cisco Systems, Inc.


> >From: "Scott G. Kelly" <skelly@redcreek.com>
> >Reply-To: ipsec-policy@mail.timestep.com
> >To: ipsec-policy@mail.timestep.com
> >CC: phoffman@mail.imc.org
> >Subject: Re: Pardon me...
> >Date: Thu, 14 Oct 1999 11:57:12 -0700
> >
> >Dan McDonald wrote:
> > >
> > > Pardon my private note to the list.  One should really wire the
> >Reply-to:
> > > field to the author, however.  Hopefully the new list location (Paul,
> >are you
> > > listening?) will do this appropriately.
> > >
> > > Sorry again,
> > > Dan
> >
> >
> >Yes, but we *all* want to know :-)
> >
> >Wuzzup, Roy?
> >
> >Scott
> >

From owner-ipsec-policy@mail.vpnc.org  Fri Oct 22 04:00:13 1999
Received: from mail.vpnc.org (back.vpnc.org [165.227.249.9])
	by mail.imc.org (8.9.3/8.9.3) with ESMTP id EAA20602
	for <ipsec-policy@imc.org>; Fri, 22 Oct 1999 04:00:12 -0700 (PDT)
Received: by mail.vpnc.org (8.9.3/8.9.0) id DAA17807
	for ipsec-policy-bks; Fri, 22 Oct 1999 03:54:38 -0700 (PDT)
X-Authentication-Warning: mail.vpnc.org: majordomo set sender to owner-ipsec-policy@mail.vpnc.org using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by mail.vpnc.org (8.9.3/8.9.0) with ESMTP id DAA17803
	for <ipsec-policy@vpnc.org>; Fri, 22 Oct 1999 03:54:36 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05914;
	Fri, 22 Oct 1999 06:57:03 -0400 (EDT)
Message-Id: <199910221057.GAA05914@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: ipsec@lists.tislabs.com, ipsec-policy@vpnc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-keromytis-ipsp-arch-00.txt
Date: Fri, 22 Oct 1999 06:57:02 -0400
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: IPsec Policy Discovery Architecture
	Author(s)	: A. Keromytis, M. Richardson, L. Sanchez 
	Filename	: draft-keromytis-ipsp-arch-00.txt
	Pages		: 7
	Date		: 21-Oct-99
	
This document describes an IP Security Policy architecture that
conforms to the requirements set forth in [IPSP-REQ].  The
architecture defines the mechanisms and protocols needed for
discovering, accessing, and processing security policy information
of varying granularity.  The architecture accommodates topology and
policy changes without need of manual reconfiguration of clients
and security gateways.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-keromytis-ipsp-arch-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-keromytis-ipsp-arch-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-keromytis-ipsp-arch-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<19991021142619.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-keromytis-ipsp-arch-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-keromytis-ipsp-arch-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<19991021142619.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ipsec-policy  Thu Nov  4 08:33:40 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA08483
	for ipsec-policy-bks; Thu, 4 Nov 1999 08:33:40 -0800 (PST)
Received: from nutmeg.bbn.com (NUTMEG.bbn.com [128.89.1.112])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08479
	for <ipsec-policy@vpnc.org>; Thu, 4 Nov 1999 08:33:39 -0800 (PST)
Received: (from lsanchez@localhost)
	by nutmeg.bbn.com (8.8.8/8.8.7) id LAA00571
	for ipsec-policy@vpnc.org; Thu, 4 Nov 1999 11:33:56 -0500 (EST)
	(envelope-from lsanchez)
From: "Luis A. Sanchez" <lsanchez@bbn.com>
Message-Id: <199911041633.LAA00571@nutmeg.bbn.com>
Subject: Agenda
To: ipsec-policy@vpnc.org
Date: Thu, 4 Nov 1999 11:33:56 -0500 (EST)
Reply-to: lsanchez@bbn.com
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Folks, IPSP will meet this coming Monday 11/8/99 at 0900hrs in
DC. IPSP is listed as a BOF because the official WG Action
announcement didn't make it on time. Our ADs committed to deal with
this immediately after this meeting. This aside, I'm requesting items
for the agenda. If you have relevant material that you would like to
present please send me email. So far we have four
presentations. Thanks,

Luis

From owner-ipsec-policy  Thu Nov  4 14:07:56 1999
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id OAA14493
	for ipsec-policy-bks; Thu, 4 Nov 1999 14:07:56 -0800 (PST)
Received: from adk.gr (COREDUMP.CIS.UPENN.EDU [158.130.6.141])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14489
	for <ipsec-policy@vpnc.org>; Thu, 4 Nov 1999 14:07:54 -0800 (PST)
Received: from dsl.cis.upenn.edu (localhost [127.0.0.1])
	by adk.gr (8.9.3/8.9.1) with ESMTP id RAA04351
	for <ipsec-policy@vpnc.org>; Thu, 4 Nov 1999 17:08:08 -0500 (EST)
Message-Id: <199911042208.RAA04351@adk.gr>
X-Mailer: exmh version 2.0.2 2/24/98
To: ipsec-policy@vpnc.org
Subject: IPSP architecture draft
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 04 Nov 1999 17:08:08 -0500
From: "Angelos D. Keromytis" <angelos@dsl.cis.upenn.edu>
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Since we do have a meeting on Monday morning, I'd like to ask people to
review the proposed architecture draft (still very much a draft), available
at the I-D directories as draft-keromytis-ipsp-arch-00.txt, or at

http://www.cis.upenn.edu/~angelos/Papers/draft-keromytis-ipsp-arch-00.txt.gz
http://www.vpnc.org/draft-keromytis-ipsp-arch

and send comments to me and/or the list.
Cheers,
-Angelos



From owner-ipsec-policy  Fri Nov  5 01:54:23 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id BAA17185
	for ipsec-policy-bks; Fri, 5 Nov 1999 01:54:23 -0800 (PST)
Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA17181
	for <ipsec-policy@vpnc.org>; Fri, 5 Nov 1999 01:54:21 -0800 (PST)
Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.117.200.23])
	by e2.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id EAA189538
	for <ipsec-policy@vpnc.org>; Fri, 5 Nov 1999 04:53:58 -0500
Received: from BLDVMA.boulder.ibm.com (bldvma.boulder.ibm.com [9.99.64.30])
	by northrelay03.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id EAA51404
	for <ipsec-policy%vpnc.org@relay.us.ibm.com>; Fri, 5 Nov 1999 04:54:41 -0500
Message-Id: <199911050954.EAA51404@northrelay03.pok.ibm.com>
Received:  by BLDVMA.boulder.ibm.com (IBM VM SMTP Level 310) via spool with SMTP id 8417 ; Fri, 05 Nov 1999 02:53:39 MST
Date: Fri, 5 Nov 99 10:54:54 CET
From: "Bert Wijnen" <WIJNEN@VNET.IBM.COM>
To: ipsec-policy@vpnc.org
Subject: BOFs of interest to this group (or at least I think so)
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

In September, a group of ADs have met with a group of people from
the various WGs that are involved in Policy-Based-Network-Management.
Luis Sanchez was present to give input for IPSP group.

In that meeting we formed 3 Design Teams to come up with strawman
"solutions/proposals" for the various problem areas.
The output of those Design Teams will be discussed at the upcoming
IETF meeting as follows:

- POLICY WG, Monday 1530-1730, Regency Ballroom.
             The topic is Use Cases and Scenarios.
             document to read: draft-ietf-policy-req-01.txt
  http://www.ietf.org/internet-drafts/draft-ietf-policy-req-01.txt

- POLTERM BOF, Friday 9-11:30, Blue Room
             The topic is Terminology for Policy Based (Network)
             Management. Documents to read:

  http://www.ietf.org/internet-drafts/draft-ops-mumble-terminology-00.txt
  this one should have as date: October 22nd

  Other documents containing terminology from the various WGs or
  otherwise relevant:

  http://www.ietf.org/internet-drafts/draft-ietf-policy-framework-00.txt
  http://www.ietf.org/internet-drafts/draft-ietf-policy-terms-00.txt
  http://www.ietf.org/internet-drafts/draft-ietf-rap-framework-03.txt
  http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-pr-01.txt

- CFGMGMT BOF, Thursday 1530-1730, Empire Room
               The topic is Requirements for Configuration Management
               and evaluation of existing/proposed protocols against
               those requirements. Documents to read:

  http://www.ietf.org/internet-drafts/draft-ops-mumble-terminology-00.txt
  this one should have as date: October 22nd

  Other documents containing terminology from the various WGs or
  otherwise relevant:

  http://www.ietf.org/internet-drafts/draft-ietf-policy-framework-00.txt
  http://www.ietf.org/internet-drafts/draft-ietf-policy-terms-00.txt
  http://www.ietf.org/internet-drafts/draft-ietf-rap-framework-03.txt
  http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-pr-01.txt

Please check out the agendas for the Meetings.
Please come and contribute, so that also the requirments and concerns
of the IPsec-Policy BOF/WG are being considered.

Bert Wijnen, co-AD for Operations and Management

From owner-ipsec-policy  Mon Nov  8 07:26:57 1999
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id HAA29584
	for ipsec-policy-bks; Mon, 8 Nov 1999 07:26:57 -0800 (PST)
Received: from nyarlathotep.cis.upenn.edu (dhcp69-ds51.ds.ietf.innovationslab.net [130.128.69.51])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29576
	for <ipsec-policy@vpnc.org>; Mon, 8 Nov 1999 07:26:51 -0800 (PST)
Received: (from angelos@localhost)
	by nyarlathotep.cis.upenn.edu (8.9.3/8.9.3) id FAA21405
	for ipsec-policy@vpnc.org; Mon, 8 Nov 1999 05:26:17 -0500 (EST)
Date: Mon, 8 Nov 1999 05:26:17 -0500 (EST)
From: "Angelos D. Keromytis" <angelos@dsl.cis.upenn.edu>
Message-Id: <199911081026.FAA21405@nyarlathotep.cis.upenn.edu>
To: ipsec-policy@vpnc.org
Subject: raw minutes from IPSP meeting
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Luis Sanchez talked briefly about agenda bashing, asked whether anyone
would like to be the co-chair. Brief outline for the following
speakers (see slides).

Mike Richardson talked about the requirements document: definition of
terminology, Security Policy system requirements. Ask for help in
determining real scenarios and desired solutions.

The problem is how to manage the process of creating and modifying
security policies so as to maintain their mutual consistency. This is
an inter-domain problem; the intra-domain is (relatively easy).

We need something in a higher layer than IKE (which is an agreement
protocol); we need a negotiation (or at least discovery) mechanism.

Important issues/features:
- discover security gateways (avoid pre-configuration, scalability,
  road warrior scenarios)

- manage dynamic SAs (linked tunnels, how are they described,
  configured, and managed).

- system administrator policy must be taken into account (since they
  can enforce that policy at the SG). End-user security policy must
  also be taken into account. Conflicts, combination must be resolved.

Issues:
- does localhost always run a policy server ?
- policy servers: pre-configured or discovered
- why (or why not) LDAP ?
(see slides)

JI commented on that two architectural problems need to be solved:
negotiation (phrasing of parameters) and directory lookup. Maybe we
shouldn't solve both, or we should solve them in an orthogonal way
(make them independent). The protocol should not be used only in
IPSP.

Angelos Keromytis briefly discussed the architecture draft (see
slides).

Jamie Jason discussed issues with IPsec Policy representation. UML
representation for policy, draft will be ready shortly after the
IETF. After the representation is stabilized, we can 

Bert Winen asked Jamie to document the reasons why to use UML for
policy specification/definition. Jamie responded that their
specification does actually use the drafts from other WGs that specify
policy.

Kai Martius discussed some (very early) implementation experiences for
a Security Policy Protocol (see slides).

Questions:

- Ed Ellison asked whether Kai's approach would be amenable to be used
  with Jamie's approach. The answer is yes.

- Someone asked for a real definition of policy, for this working
  group.

- Question whether policy must or should be confidential. Answer:
  there are cases when policy should be disclosed only to authorized
  entities.

- Should we have an inter and an intra domain protocol for security
  policy discovery/distribution ? Answer: perhaps.

- What about ICMP security failure messages ? Answer: they are not the
  right approach.

- JI asked for a way to deliver (the) policy to end applications, for
  access control purposes.

- New mailing list address: ipsec-policy@vpnc.org, use majordomo to
  subscribe.

- What about AAA ? Defer for SAD to answer (below).

- Question on how the IPSP work fits in the Policy Framework WG. Jamie
  answered that the PFWG is addressing the high-level,
  domain/application-independent issues with policy; it's the
  individual WG's responsibility to "plug in" within that framework.
  Ed Ellison (co-chair of PFWG) confirmed this, adding that feedback
  from WGs may cause changes in the PFWG basic policy model.

- JI said that you can't have a one-size-fits all policy
  model/language; different types should use whatever fits them
  (diffserv policy is inherently different from ipsec policy is
  different from xyz policy).

  Ed Ellison responded that PFWG is not trying to specify a
  one-size-fit-all, just provide a common framework. JI
  counter-responded that if we don't have running code etc., we end up
  designing by committee.

- Mike Richardson (and others) pointed out that there is a need for
  coordinated policy management, to get end-to-end service, or for
  dynamic coallitions etc.

- Request to collect all the requirements and separate them in
  different groups (different customer groups, different uses,
  short/long term) etc.

  Luis recalled hearing the same argument 6 years ago, for
  IPsec. Suggestions and comments should go to the mailing list.

- Is there an archive ? There is one on VPNC.

Marcus Leech (Security Area Director):

- IPSP is becoming a WG, hasn't happened yet due to limited time and
  bandwidth. Charter exists, creation of WG should occur soon after
  the meeting is finished.

- There has been some emphasis on working with the PFWG. There has
  been a meeting to resolve differences between IPSP and PFWG. IPsec
  policy has a different "flavor", or twists, that PFWG should take
  into consideration (which means feedback).

- Comment that we need trusted policies, not necessarily digitally
  signed (they could be communicated over a secure channel).


From owner-ipsec-policy  Mon Nov  8 10:29:59 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA02690
	for ipsec-policy-bks; Mon, 8 Nov 1999 10:29:59 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02686
	for <ipsec-policy@vpnc.org>; Mon, 8 Nov 1999 10:29:58 -0800 (PST)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA05770;
	Mon, 8 Nov 1999 10:30:14 -0800 (PST)
Received: from ha1mpk-mail.eng.sun.com (phys-ha1mpka.Eng.Sun.COM [129.146.101.34])
	by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with SMTP id KAA11389;
	Mon, 8 Nov 1999 10:30:07 -0800 (PST)
Received: from ha1mpk-mail.Eng.Sun.COM by ha1mpk-mail.eng.sun.com (SMI-8.6/SMI-SVR4)
	id KAA11547; Mon, 8 Nov 1999 10:29:56 -0800
From: Pat.Calhoun@eng.sun.com (Patrice Calhoun)
Message-Id: <199911081829.KAA11547@ha1mpk-mail.eng.sun.com>
Date: Mon, 8 Nov 1999 01:33:47 -0500
To: "Angelos D. Keromytis" <angelos@dsl.cis.upenn.edu>,
        <ipsec-policy@vpnc.org>
Reply-To: <pcalhoun@eng.sun.com>
Subject: Re: raw minutes from IPSP meeting
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

>
>- What about AAA ? Defer for SAD to answer (below).
>

Did SAD answer the question? I did not find it in the minutes and had to
attend another meeting.

PatC


From owner-ipsec-policy  Mon Nov  8 11:22:42 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA03458
	for ipsec-policy-bks; Mon, 8 Nov 1999 11:22:42 -0800 (PST)
Received: from nyarlathotep.cis.upenn.edu (dhcp69-ds51.ds.ietf.innovationslab.net [130.128.69.51])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03454
	for <ipsec-policy@vpnc.org>; Mon, 8 Nov 1999 11:22:41 -0800 (PST)
Received: from dsl.cis.upenn.edu (localhost [127.0.0.1])
	by nyarlathotep.cis.upenn.edu (8.9.3/8.9.3) with ESMTP id JAA00611
	for <ipsec-policy@vpnc.org>; Mon, 8 Nov 1999 09:22:19 -0500 (EST)
Message-Id: <199911081422.JAA00611@nyarlathotep.cis.upenn.edu>
X-Mailer: exmh version 2.0.2 2/24/98
To: ipsec-policy@vpnc.org
Subject: Re: raw minutes from IPSP meeting 
In-reply-to: Your message of "Mon, 08 Nov 1999 01:33:47 EST."
             <199911081829.KAA11547@ha1mpk-mail.eng.sun.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 08 Nov 1999 09:22:18 -0500
From: "Angelos D. Keromytis" <angelos@dsl.cis.upenn.edu>
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

In message <199911081829.KAA11547@ha1mpk-mail.eng.sun.com>, Patrice Calhoun wri
tes:
>>
>>- What about AAA ? Defer for SAD to answer (below).
>>
>
>Did SAD answer the question? I did not find it in the minutes and had to
>attend another meeting.

I don't think he addressed the issue directly; I think the answer was that we
should work in the greater context of the Policy Framework WG (which may or
may not be a satisfactory answer to you).
-Angelos



From owner-ipsec-policy  Mon Nov  8 12:39:29 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA07471
	for ipsec-policy-bks; Mon, 8 Nov 1999 12:39:29 -0800 (PST)
Received: from pzero.sandelman.ottawa.on.ca (dhcp21-fh36.fh.ietf.innovationslab.net [130.128.21.36])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA07467
	for <ipsec-policy@vpnc.org>; Mon, 8 Nov 1999 12:39:27 -0800 (PST)
Received: from morden.sandelman.ottawa.on.ca (localhost [127.0.0.1])
	by pzero.sandelman.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id OAA00837
	for <ipsec-policy@vpnc.org>; Mon, 8 Nov 1999 14:39:52 -0500 (EST)
Message-Id: <199911081939.OAA00837@pzero.sandelman.ottawa.on.ca>
To: ipsec-policy@vpnc.org
Subject: Re: raw minutes from IPSP meeting 
In-reply-to: Your message of "Mon, 08 Nov 1999 01:33:47 EST."
             <199911081829.KAA11547@ha1mpk-mail.eng.sun.com> 
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Mon, 08 Nov 1999 14:39:52 -0500
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

>>>>> "Patrice" == Patrice Calhoun <Pat.Calhoun@eng.sun.com> writes:
    >> - What about AAA ? Defer for SAD to answer (below).
    >> 

    Patrice> Did SAD answer the question? I did not find it in the minutes and had to
    Patrice> attend another meeting.

  SAD did not address that question.

]                   At IETF46 in Washington, DC                 |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [



From owner-ipsec-policy  Sun Nov 14 12:28:33 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA21213
	for ipsec-policy-bks; Sun, 14 Nov 1999 12:28:33 -0800 (PST)
Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21209
	for <ipsec-policy@vpnc.org>; Sun, 14 Nov 1999 12:28:28 -0800 (PST)
Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.117.200.23])
	by e3.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA106800
	for <ipsec-policy@vpnc.org>; Sun, 14 Nov 1999 15:28:50 -0500
Received: from BLDVMA.boulder.ibm.com (bldvma.boulder.ibm.com [9.99.64.30])
	by northrelay03.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id PAA248730
	for <ipsec-policy%vpnc.org@relay.us.ibm.com>; Sun, 14 Nov 1999 15:29:36 -0500
Message-Id: <199911142029.PAA248730@northrelay03.pok.ibm.com>
Received:  by BLDVMA.boulder.ibm.com (IBM VM SMTP Level 310) via spool with SMTP id 6106 ; Sun, 14 Nov 1999 13:28:33 MST
Date: Sun, 14 Nov 99 21:29:48 CET
From: "Bert Wijnen" <WIJNEN@VNET.IBM.COM>
To: ipsec-policy@vpnc.org
Subject: discussion of requirments for configuration management
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

At the CFGMGMT BOF in Wahsinton D.C. we decided to continue the
discussion of requirements for configuration management.

We have opened a separate mailing list for this discussion.
This mailing list is at:

  confmgt@ops.ietf.org

To subscribe do one of the following:

  - send email to confmgt-request@ops.ietf.org
    in the body put a single line with text:  subscribe

  - send email to majordomo@ops.ietf.org
    in the body put a single line with:  subscribe confmgmt

Please do not discuss configuration management requirments on the
mumble mailing list anymore.

The current list of requirements can be found in section 3 of:

   http://www.ietf.org/internet-drafts/draft-ops-mumble-conf-management-00.txt

Several people at the BOF stated support for the requirements listed
in section 3 of the above document. It is good to hear from others
if they agree or disagree with that list of requirements.

Also, at the BOF, quite a few people stated additional requirements.
It would be nice if they could all prepare their requirement in
a concise posting to the new mailing list, so that others can then
indicate if they agree or disagree.

People who were not at the BOF and who want to state additional
requirements are invited to post them and contribute to the
discussion.

The draft-ops-mumble-conf-management-00.txt document also contains
two sections (4 and 5) in which COPS-PR/PIN and SNMP/MIB are
evaluated against the requirements in section 3. We do not currently
want more discussion on an evaluation. First we want to collect all
the requirements and include them in the list. Probably the
document with requirments can be posted as an informational RFC
later. After that... we may consider evaluating solutions against
the then consolidated list of requirements, but pls not now.

Thanks,
Bert

From owner-ipsec-policy  Sun Nov 14 12:41:54 1999
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA21330
	for ipsec-policy-bks; Sun, 14 Nov 1999 12:41:54 -0800 (PST)
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21326
	for <ipsec-policy@vpnc.org>; Sun, 14 Nov 1999 12:41:53 -0800 (PST)
Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.117.200.23])
	by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA134744
	for <ipsec-policy@vpnc.org>; Sun, 14 Nov 1999 15:42:15 -0500
Received: from BLDVMA.boulder.ibm.com (bldvma.boulder.ibm.com [9.99.64.30])
	by northrelay03.pok.ibm.com (8.8.8m2/NCO v2.06) with SMTP id PAA124736
	for <ipsec-policy%vpnc.org@relay.us.ibm.com>; Sun, 14 Nov 1999 15:43:01 -0500
Message-Id: <199911142043.PAA124736@northrelay03.pok.ibm.com>
Received:  by BLDVMA.boulder.ibm.com (IBM VM SMTP Level 310) via spool with SMTP id 6143 ; Sun, 14 Nov 1999 13:41:58 MST
Date: Sun, 14 Nov 99 21:43:13 CET
From: "Bert Wijnen" <WIJNEN@VNET.IBM.COM>
To: ipsec-policy@vpnc.org
Subject: discussion of terminology for policy based (network) management
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

At the POLTERM BOF in Wahsinton D.C. we decided to continue the
discussion of terminology for policy based network management.

We have opened a separate mailing list for this discussion.
This mailing list is at:

  polterm@ops.ietf.org

To subscribe do one of the following:

  - send email to polterm-request@ops.ietf.org
    in the body put a single line with text:  subscribe

  - send email to majordomo@ops.ietf.org
    in the body put a single line with:  subscribe polterm

Please do not send postings about terminology to the mumble list anymore.

There is an initial document that discusses some of this, but it
is far from complete. But for those who have not yet seen it:

   http://www.ietf.org/internet-drafts/draft-ops-mumble-terminology-00.txt

Several people at the BOF have made comments already, based on the
slides that Fran Reichmeijer presented. I would like Fran to make the
slides available for FTP or so. COuld the others post their
statements/points (in a concise form please), so that everybody can
take part in the full discussion.

We would like the Design Team who did the original work to continue
to collect the terminology input and write a document that gets
closer and closer to a commponly agreed set of terms.
Since this is a cross WG effort, I would like the Design Team to
report to the collective set of WG chairs of those WGs, and as
such, I need to discuss that first with the WG chairs before
I can give more details.

Thanks,
Bert

From owner-ipsec-policy  Fri Jan  7 13:09:59 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA12807
	for ipsec-policy-bks; Fri, 7 Jan 2000 13:09:59 -0800 (PST)
Received: from ns01.newbridge.com (ns01.newbridge.com [192.75.23.67])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12803
	for <ipsec-policy@imc.org>; Fri, 7 Jan 2000 13:09:51 -0800 (PST)
Received: (from smtpd@localhost)
	by  ns01.newbridge.com (8.9.2/8.9.2) id QAA15836
	for <ipsec-policy@imc.org>; Fri, 7 Jan 2000 16:05:15 -0500 (EST)
Received: from portal1.newbridge.com(192.75.23.76), claiming to be "kanata-mh1.ca.newbridge.com"
 via SMTP by ns01.newbridge.com, id smtpdBAA0TdT9J; Fri Jan  7 16:05:12 2000
Received: from exchange.timestep.com by kanata-mh1.ca.newbridge.com with ESMTP for ipsec-policy@imc.org; Fri, 7 Jan 2000 16:09:56 -0500
Received: by exchange with Internet Mail Service (5.5.2232.9)
	id <CDS8Z29V>; Fri, 7 Jan 2000 16:12:06 -0500
Message-Id: <319A1C5F94C8D11192DE00805FBBADDFA85921@exchange>
From: Andrew Milne <amilne@timestep.com>
To: "'ipsec-policy@imc.org'" <ipsec-policy@imc.org>
Subject: Disregard -- testing
Date: Fri, 7 Jan 2000 16:12:00 -0500 
Importance: low
X-Priority: 5
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Testing

From owner-ipsec-policy  Wed Jan 19 14:20:28 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA13405
	for ipsec-policy-bks; Wed, 19 Jan 2000 14:20:28 -0800 (PST)
Received: from nutmeg.bbn.com (NUTMEG.bbn.com [128.89.1.112])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA13401
	for <ipsec-policy@vpnc.org>; Wed, 19 Jan 2000 14:20:27 -0800 (PST)
Received: (from lsanchez@localhost)
	by nutmeg.bbn.com (8.8.8/8.8.7) id RAA13119
	for ipsec-policy@vpnc.org; Wed, 19 Jan 2000 17:20:28 -0500 (EST)
	(envelope-from lsanchez)
From: "Luis A. Sanchez" <lsanchez@bbn.com>
Message-Id: <200001192220.RAA13119@nutmeg.bbn.com>
Subject: IPSP WG Status
In-Reply-To: <319A1C5F94C8D11192DE00805FBBADDFA85921@exchange> from Andrew Milne
 at "Jan 7, 2000 04:12:00 pm"
To: ipsec-policy@vpnc.org
Date: Wed, 19 Jan 2000 17:20:27 -0500 (EST)
Reply-to: lsanchez@bbn.com
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Folks, the IESG finally approved IPSP. The official announcement will
come out _sometime_ in the no so distant future.

Luis


From owner-ipsec-policy  Mon Feb  7 06:51:34 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id GAA27029
	for ipsec-policy-bks; Mon, 7 Feb 2000 06:51:34 -0800 (PST)
Received: from smtprtp1.ntcom.nortel.net (smtprtp1.ntcom.nortel.net [137.118.22.14])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA27025
	for <ipsec-policy@vpnc.org>; Mon, 7 Feb 2000 06:51:32 -0800 (PST)
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by smtprtp1.ntcom.nortel.net; Mon, 7 Feb 2000 09:53:28 -0500
Received: from rftzy228.ca.nortel.com ([47.130.185.28]) 
          by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id 12FVAG3B; Mon, 7 Feb 2000 09:53:14 -0500
Received: from rftzy230.ca.nortel.com ([47.130.185.30]) 
          by rftzy228.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id 1H3BB61W; Mon, 7 Feb 2000 09:53:11 -0500
Received: from nt.com (bftzh114.ca.nortel.com [47.201.2.238]) 
          by rftzy230.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id 1DXJZ0F1; Mon, 7 Feb 2000 09:53:11 -0500
Message-ID: <389EDC57.15E61E28@nt.com>
Date: Mon, 07 Feb 2000 09:53:11 -0500
X-Sybari-Space: 00000000 00000000 00000000
From: "Marcus Leech" <mleech@nortelnetworks.com>
X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec-policy@vpnc.org
Subject: Policy Framework advisor for IPSP WG
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Thanks to the efforts of John Strassner, and Bert Wijnen, OPS AD, we now have
  an official advisor and liason to the POLICY working group.  His name is
  Lee Rafalow, and he works for IBM.

Lees tasks will include:

  - acting as the interface between the POLICY WG and the IPSP WG, and provide
    a concensus view when speaking within each WG.

  - Provide support and advice to the IPSP WG on the Information Model and
    Scheme used within the POLICY work.

  - facilitate communications between the WGs.

  - report any problems to all involved WG chairs and ADs.

Welcome aboard, Lee.

-- 
----------------------------------------------------------------------
Marcus Leech                             Mail:   Dept 8M70, MS 012, FITZ
Systems Security Architect               Phone: (ESN) 393-9145  +1 613 763 9145
Security and Internet Solutions          Fax:   (ESN) 395-1407  +1 613 765 1407
Nortel Networks                          mleech@nortelnetworks.com
-----------------Expressed opinions are my own, not my employer's------

From owner-ipsec-policy  Tue Feb  8 06:02:02 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id GAA07950
	for ipsec-policy-bks; Tue, 8 Feb 2000 06:02:02 -0800 (PST)
Received: from squatch.ir.bbn.com (squatch.ir.bbn.com [192.1.98.166])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA07941
	for <ipsec-policy@vpnc.org>; Tue, 8 Feb 2000 06:01:56 -0800 (PST)
Received: (qmail 6851 invoked by uid 20813); 8 Feb 2000 14:04:11 -0000
Date: 8 Feb 2000 14:04:11 -0000
Message-ID: <20000208140411.6850.qmail@squatch.ir.bbn.com>
From: Matthew Condell <mcondell@bbn.com>
To: baltatu@athena.polito.it
Cc: ipsec-policy@vpnc.org
Subject: Re: SPP Operation
Reply-to: mcondell@bbn.com
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Hi Madalina, 

I am cc'ing the IPSP working group list with my reply.  Answers inline:

>I'm trying to understand how SPP operates, and I've got some questions 
>regarding the example described at the end of the SPP draft 
>(draft-ietf-ipsec-spp-00.txt).
>
>The part that intrigues me is the following one (step 7 in the example, draft 
>page 74):
>
>" 
>    PS1 creates a signal with a comsec record derived from knowing the
>    traffic that will pass through SG1 and, the part of the merged
>    policy that terminates at SG1:
>             SPP Header [Pol, Sender PS1, qcount 0, rcount 2]
>             Record Payload [comsec]:
>               src H1, dst SG3, ESP, OPAQUE, permit
>             Record Payload [SA rec]:
>               src SG1, dst SG2, UDP, 79, permit, ESP tunnel SG1->SG2
>             Signature Payload
>    PS1 sends the signal to SG1.   
>"
>The second record inside this SPP_POL message has to inform SG1 that all 
>packets belonging to the required communication between H1 and H2 (UDP port 
>79) have to travel inside the ESP tunnel between SG1 and SG2.
>
>My question is: how SG1 recognizes these packets, since when they arrive at 
>SG1, they are encapsulated twice (first the ESP transport between H1 and H2, 
>and then the ESP tunnel between H1 and SG3)? All the SG1 sees are ESP packets 
>from H1 to SG3, and it does have a policy to let them pass. But how does SG1 
>know to subsequently protect these packets with an ESP tunnel that is 
>negotiated with SG2 for UDP, port 79? The selectors part of the of the SA 
>record says that the communication that has to be protected by the ESP tunnel 
>from SG1 to SG2 is UDP 79, doesn't it? 
>Maybe the fact that the 2 records in the above signal message come in the same 
>SPP packet means that the ESP packets from H1 to SG3 are all "routed" to the 
>ESP tunnel SG1->SG2 ... ? 
>Maybe I'm missing something...  

The Comsec Record Payload and the SA Rec Payload work together to
describe the communication and how it must be protected.  The Comsec
Record contains the selectors that describe the communication to be
protected (src H1, dst SG3, ESP, OPAQUE), while the SA Record
describes how to protect it (ESP tunnel SG1->SG2).  The remaining
selectors in the SA record are ignored and are only in the record as a
means to simplify the already complicated record processing.

>Another thing that intrigues me is the policy server record contained in the 
>reply R1 from PS3 to PS2: isn't it supposed to say that PS3 is authoritative 
>for node H2 (instead of node H1)? 

Yes, that's a bug in the text. It should be H2, not H1.  
Thanks for catching it.

Matt Condell
BBN Technologies

From owner-ipsec-policy  Tue Feb  8 08:21:15 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA11398
	for ipsec-policy-bks; Tue, 8 Feb 2000 08:21:15 -0800 (PST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11394
	for <ipsec-policy@vpnc.org>; Tue, 8 Feb 2000 08:21:09 -0800 (PST)
Received: from jstrassn-lt ([171.69.108.130])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA06229;
	Tue, 8 Feb 2000 08:21:36 -0800 (PST)
Message-Id: <4.2.0.58.20000208080450.00ad9a00@omega.cisco.com>
X-Sender: jstrassn@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 08 Feb 2000 08:22:33 -0800
To: Shai Herzog <herzog@iphighway.com>,
        "John C. Strassner" <jstrassn@cisco.com>,
        Andrew Smith <andrew@extremenetworks.com>,
        "'Ken Roberts'" <kjr@nortelnetworks.com>
From: "John C. Strassner" <jstrassn@cisco.com>
Subject: RE: Policy issues: definition of Roles
Cc: policy@raleigh.ibm.com, "'snmpconf@snmp.com'" <snmpconf@snmp.com>,
        rap@iphighway.com, ipsec-policy@vpnc.org
In-Reply-To: <4.2.0.58.20000206232138.02f037b0@209.3.6.76>
References: <4.2.0.58.20000206174814.00c4a2a0@omega.cisco.com>
 <808F64DDB492D3119D3C00508B5D8D733EC4B2@SOL>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_43600744==_.ALT"
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

--=====================_43600744==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi Shai, comments inline.

regards,
John

At 11:48 PM 2/6/00 -0500, Shai Herzog wrote:
>I think that one of the problems is that we're confusing the
>various levels of "roles". Let me try to make the following
>observations:

<js>
Levels of roles? If a role is indeed an attribute used as a selector, this 
translates to levels of attributes. My head is hurting. ;-) More to the 
point, I don't know what you mean by "levels" of roles...

I humbly submit that you're making this too complicated. Instead, thinking 
of roles as a means to select from among a larger subset is appealing 
because it always means the same thing each time it is used.
</js>

>1. Roles and Role Combinations have only meaning (in the
>    definition sense) in the PEP.

<js>
I disagree. Granted that for the cases we've considered so far, it has been 
tied specifically to device interfaces. But a "role" is an age-old concept, 
and can be used equally in other contexts as well - roles as a selector to 
the type of job that a person is performing, for example. Which can be tied 
back to networking (Shai's CTO role gets him on the Engineering subnet, 
whereas Shai's marketing role gets him onto the Marketing subnet).

I suspect that as IPSP gets kicked off, they will want to use a more 
general definition of roles than just to describe the capabilities of a 
device interface.
</js>

>2. PDPs and DEN Policy Schemas may or may not take advantage of PEP
>    roles.
>
>    For example:
>
>    PEP Roles: Edge+Ethernet, Edge+T1
>    PDP Policy: If User=Joe, Mark (Traffic Desc) DSCP=AF11.
>
>    Here the PDP may actually track down the ingress router and
>    mark on ALL of its interfaces, regardless of Roles. It will
>    produce the following instructions:
>
>    Role = Edge+Ethernet: Mark (Traffic Desc) DSCP AF11
>    Role = Edge+T1      : Mark (Traffic Desc) DSCP AF11
>
>    My point is that we should stop thinking that the policy is bound
>    to roles 1:1.

<js>
I certainly never said that. A policy can contain multiple roles, and a 
role can be used by multiple policies. In fact, if you think of a role as a 
selector, you couldn't draw that conclusion anyway. So at least we agree 
here. ;-)
</js>

>3. PEPs are not expected to be able to merge policies for Roles in
>    Role combination.
>
>    Given the previous example, the PDP is not allowed to send the
>    following to the PEP:
>
>    Role=Edge    : Conf1
>    Role=Ethernet: Conf2
>
>    Since the PEP that has an interface with both roles in a role
>    combination (Edge+Ethernet) is now required to merge Conf1+Conf2.
>    This merge is a big NO NO, since the whole point about external
>    policy processing is that the PEP doesn't understand policy
>    implications and complications and needs to receive very specific
>    instructions.

<jcs> Agreed </js>

>4. PDPs may be smart enough to merge roles (and therefore deal with
>    individual roles within a role combination). This is actually
>    an implication of observation (2) but I though it needs to be
>    clarified.
>
>    For example, in the PDP, lets assume Ethernets get special
>    treatment (higher precedence rule).
>
>    Role=Edge    : If Service=Gold then Mark DSCP=xxx
>    Role=Ethernet: If Service=Gold then Mark DSCP=yyy
>
>    This will produce the following configuration (using COPS, or equiv):
>
>    Role=Edge+Ethernet: Mark (Traffic Desc) DSCP=yyy
>    Role=Edge+T1      : Mark (Traffic Desc) DSCP=xxx
>
>So, going back to the definition I gave a while back, the reason for
>the "ALL" comes from observation 3.
>
>PDPs can process policy whatever the hell they wish (within reason)
>but they have to respond to the PEP with specific policy for each
>COMPLETE role combination, and cannot respond to partial role
>combination or a specific role which is only a part of a role
>combination.

<js>
Seems to me that you want to differentiate between roles as used to 
influence device configuration on the PEP level vs. roles as used to build 
policy statements at the PDP level. Is this what you meant by "levels" of 
roles?

If so, then I suggest that we talk about PEP roles vs. PDP roles (as Keith 
suggested earlier) vs. roles as a selector (to make me happy ;-) )
</js>


>Shai
>
>At 05:49 PM 02/06/2000, John C. Strassner wrote:
>>A role is just one of possibly many selectors that is used to download a 
>>subset of appropriate policies from a much larger set of availale policies.
>>
>>A role can be specified as part of a policy condition or action, both of 
>>which are components of a policy rule as defined in the Policy Core 
>>Information Model.
>>
>>HTH,
>>John
>>
>>At 05:23 PM 1/31/00 -0800, Andrew Smith wrote:
>>>e.g. "HTTP traffic gets AF treatment on all Ethernet and FDDI interfaces" is
>>>a policy rule that references two roles: "Ethernet interfaces" and "FDDI
>>>interfaces". You wouldn't bother sending that rule to token-ring devices.
>>>
>>>(I guess I'm really an assembler programmer so I don't understand these
>>>"class" and "subclass" things you talk about).
>>>
>>>Andrew
>>>
>>>P.S. Maybe we should drop the "policy framework" list from this thread since
>>>this appears to be purely a "device" thing. But I did think we were
>>>attempting the (maybe thankless) task of unifying the terminology between
>>>all the WGs.
>>>
>>>-----Original Message-----
>>>From: Ken Roberts [mailto:kjr@nortelnetworks.com]
>>>Sent: Monday, January 31, 2000 4:42 PM
>>>To: Andrew Smith; 'Bob Natale'
>>>Cc: policy@raleigh.ibm.com; 'snmpconf@snmp.com'
>>>Subject: RE: Policy issues: definition of Roles
>>>
>>>
>>>Gents & others,
>>>I'm a little confused by Andrew's statement of a policy that has multiple
>>>roles. I understood a policy had rules. Rules may be crafted to include the
>>>notion of roles but are they separate rules or sub classes of one rule?
>>>When the statement "A policy that references roles W and X" is made does
>>>this imply there is a matrix relationship that can be established from one
>>>parent policy (/rule)? How is this managed? Why is this required? If
>>>policies have hierarchical structure can this not be done with containment
>>>or another relationship?
>>>I think I had better re-read the thread as maybe I've missed something.
>>>--------------------------------------------------------------------------
>>>Regards,
>>>Ken Roberts
>>>INM Product Architecture
>>>Nortel Networks
>>>?ESN   :        655-7844                        ?Direct  : 408-565-7844
>>>?  Fax    :        408-565-8226
>>>? email :      kjr@nortelnetworks.com
>>>
>>>This message may contain information proprietary to Nortel Networks
>>>Corporation so any
>>>unauthorised disclosure, copying or distribution of its contents is strictly
>>>prohibited.
>>>  -----Original Message-----
>>>From:   Andrew Smith [mailto:andrew@extremenetworks.com]
>>>Sent:   Monday, January 31, 2000 3:36 PM
>>>To:     'Bob Natale'
>>>Cc:     policy@raleigh.ibm.com; 'snmpconf@snmp.com'
>>>Subject:        RE: Policy issues: definition of Roles
>>>And, in particular, you only need to tell the device about those roles that
>>>are relevant to it - that is where the big savings are, I think. e.g.
>>>1. Device A has roles W, X and Y.
>>>2. Device B has roles W, X and Z.
>>>3. A policy that references roles W and X should be downloaded to both
>>>devices.
>>>4. A policy that references roles W and Y should be downloaded only to
>>>device A, not device B.
>>>The role combination concept in the PIB was introduced specifically in order
>>>
>>>to do this: you have to be able to list only those roles that are relevant
>>>to the policy, not necessarily ALL roles on the device, in a role
>>>combination.
>>>(Apologies if I'm repeating stuff here).
>>>Andrew
>>>
>>>
>>> > -----Original Message-----
>>> > From: Bob Natale [mailto:bnatale@acecomm.com]
>>> > Sent: Monday, January 31, 2000 3:27 PM
>>> > To: Andrew Smith
>>> > Cc: policy@raleigh.ibm.com
>>> > Subject: RE: Policy issues: definition of Roles
>>>...
>>> > That works fine for me.  All I care about on this thread is that a
>>> > "role combination" DOES NOT HAVE to include ALL of the roles supported
>>> > by a network entity/component (although there MAY well be a role
>>> > combination which does incorporate all roles supported by a network
>>> > entity/component).
>
>
>__________________________________________________________________
>Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
>55 New York Avenue                            Main: (508) 620-1141
>Framingham, MA 01701                          Fax : (212) 656-1006
>
>
>
>
>
>

--=====================_43600744==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Hi Shai, comments inline.<br>
<br>
regards,<br>
John<br>
<br>
At 11:48 PM 2/6/00 -0500, Shai Herzog wrote:<br>
<blockquote type=cite cite>I think that one of the problems is that we're
confusing the<br>
various levels of &quot;roles&quot;. Let me try to make the
following<br>
observations:</blockquote><br>
&lt;js&gt;<br>
Levels of roles? If a role is indeed an attribute used as a selector,
this translates to levels of attributes. My head is hurting. ;-) More to
the point, I don't know what you mean by &quot;levels&quot; of
roles...<br>
<br>
I humbly submit that you're making this too complicated. Instead,
thinking of roles as a means to select from among a larger subset is
appealing because it always means the same thing each time it is
used.<br>
&lt;/js&gt;<br>
<br>
<blockquote type=cite cite>1. Roles and Role Combinations have only
meaning (in the<br>
&nbsp;&nbsp; definition sense) in the PEP.</blockquote><br>
&lt;js&gt;<br>
I disagree. Granted that for the cases we've considered so far, it has
been tied specifically to device interfaces. But a &quot;role&quot; is an
age-old concept, and can be used equally in other contexts as well -
roles as a selector to the type of job that a person is performing, for
example. Which can be tied back to networking (Shai's CTO role gets him
on the Engineering subnet, whereas Shai's marketing role gets him onto
the Marketing subnet).<br>
<br>
I suspect that as IPSP gets kicked off, they will want to use a more
general definition of roles than just to describe the capabilities of a
device interface.<br>
&lt;/js&gt;<br>
<br>
<blockquote type=cite cite>2. PDPs and DEN Policy Schemas may or may not
take advantage of PEP<br>
&nbsp;&nbsp; roles.<br>
<br>
&nbsp;&nbsp; For example:<br>
<br>
&nbsp;&nbsp; PEP Roles: Edge+Ethernet, Edge+T1<br>
&nbsp;&nbsp; PDP Policy: If User=Joe, Mark (Traffic Desc) 
DSCP=AF11.<br>
<br>
&nbsp;&nbsp; Here the PDP may actually track down the ingress router
and<br>
&nbsp;&nbsp; mark on ALL of its interfaces, regardless of Roles. It
will<br>
&nbsp;&nbsp; produce the following instructions:<br>
<br>
&nbsp;&nbsp; Role = Edge+Ethernet: Mark (Traffic Desc) DSCP AF11<br>
&nbsp;&nbsp; Role = Edge+T1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Mark (Traffic
Desc) DSCP AF11<br>
<br>
&nbsp;&nbsp; My point is that we should stop thinking that the policy is
bound<br>
&nbsp;&nbsp; to roles 1:1.</blockquote><br>
&lt;js&gt;<br>
I certainly never said that. A policy can contain multiple roles, and a
role can be used by multiple policies. In fact, if you think of a role as
a selector, you couldn't draw that conclusion anyway. So at least we
agree here. ;-)<br>
&lt;/js&gt;<br>
<br>
<blockquote type=cite cite>3. PEPs are not expected to be able to merge
policies for Roles in<br>
&nbsp;&nbsp; Role combination.<br>
<br>
&nbsp;&nbsp; Given the previous example, the PDP is not allowed to send
the<br>
&nbsp;&nbsp; following to the PEP:<br>
<br>
&nbsp;&nbsp; Role=Edge&nbsp;&nbsp;&nbsp; : Conf1<br>
&nbsp;&nbsp; Role=Ethernet: Conf2<br>
<br>
&nbsp;&nbsp; Since the PEP that has an interface with both roles in a
role<br>
&nbsp;&nbsp; combination (Edge+Ethernet) is now required to merge
Conf1+Conf2.<br>
&nbsp;&nbsp; This merge is a big NO NO, since the whole point about
external<br>
&nbsp;&nbsp; policy processing is that the PEP doesn't understand
policy<br>
&nbsp;&nbsp; implications and complications and needs to receive very
specific<br>
&nbsp;&nbsp; instructions.</blockquote><br>
&lt;jcs&gt; Agreed &lt;/js&gt;<br>
<br>
<blockquote type=cite cite>4. PDPs may be smart enough to merge roles
(and therefore deal with<br>
&nbsp;&nbsp; individual roles within a role combination). This is
actually<br>
&nbsp;&nbsp; an implication of observation (2) but I though it needs to
be<br>
&nbsp;&nbsp; clarified.<br>
<br>
&nbsp;&nbsp; For example, in the PDP, lets assume Ethernets get
special<br>
&nbsp;&nbsp; treatment (higher precedence rule).<br>
<br>
&nbsp;&nbsp; Role=Edge&nbsp;&nbsp;&nbsp; : If Service=Gold then Mark
DSCP=xxx<br>
&nbsp;&nbsp; Role=Ethernet: If Service=Gold then Mark DSCP=yyy<br>
<br>
&nbsp;&nbsp; This will produce the following configuration (using COPS,
or equiv):<br>
<br>
&nbsp;&nbsp; Role=Edge+Ethernet: Mark (Traffic Desc) DSCP=yyy<br>
&nbsp;&nbsp; Role=Edge+T1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Mark (Traffic
Desc) DSCP=xxx<br>
<br>
So, going back to the definition I gave a while back, the reason 
for<br>
the &quot;ALL&quot; comes from observation 3.<br>
<br>
PDPs can process policy whatever the hell they wish (within reason)<br>
but they have to respond to the PEP with specific policy for each<br>
COMPLETE role combination, and cannot respond to partial role<br>
combination or a specific role which is only a part of a role<br>
combination.</blockquote><br>
&lt;js&gt;<br>
Seems to me that you want to differentiate between roles as used to
influence device configuration on the PEP level vs. roles as used to
build policy statements at the PDP level. Is this what you meant by
&quot;levels&quot; of roles?<br>
<br>
If so, then I suggest that we talk about PEP roles vs. PDP roles (as
Keith suggested earlier) vs. roles as a selector (to make me happy ;-)
)<br>
&lt;/js&gt;<br>
<br>
<br>
<blockquote type=cite cite>Shai<br>
<br>
At 05:49 PM 02/06/2000, John C. Strassner wrote:<br>
<blockquote type=cite cite>A role is just one of possibly many selectors
that is used to download a subset of appropriate policies from a much
larger set of availale policies.<br>
<br>
A role can be specified as part of a policy condition or action, both of
which are components of a policy rule as defined in the Policy Core
Information Model.<br>
<br>
HTH,<br>
John<br>
<br>
At 05:23 PM 1/31/00 -0800, Andrew Smith wrote:<br>
<blockquote type=cite cite>e.g. &quot;HTTP traffic gets AF treatment on
all Ethernet and FDDI interfaces&quot; is<br>
a policy rule that references two roles: &quot;Ethernet interfaces&quot;
and &quot;FDDI<br>
interfaces&quot;. You wouldn't bother sending that rule to token-ring
devices.<br>
<br>
(I guess I'm really an assembler programmer so I don't understand
these<br>
&quot;class&quot; and &quot;subclass&quot; things you talk about).<br>
<br>
Andrew<br>
<br>
P.S. Maybe we should drop the &quot;policy framework&quot; list from this
thread since<br>
this appears to be purely a &quot;device&quot; thing. But I did think we
were<br>
attempting the (maybe thankless) task of unifying the terminology
between<br>
all the WGs.<br>
<br>
-----Original Message-----<br>
From: Ken Roberts
[<a href="mailto:kjr@nortelnetworks.com" eudora="autourl">mailto:kjr@nortelnetworks.com</a>]<br>
Sent: Monday, January 31, 2000 4:42 PM<br>
To: Andrew Smith; 'Bob Natale'<br>
Cc: policy@raleigh.ibm.com; 'snmpconf@snmp.com'<br>
Subject: RE: Policy issues: definition of Roles<br>
<br>
<br>
Gents &amp; others,<br>
I'm a little confused by Andrew's statement of a policy that has
multiple<br>
roles. I understood a policy had rules. Rules may be crafted to include
the<br>
notion of roles but are they separate rules or sub classes of one
rule?<br>
When the statement &quot;A policy that references roles W and X&quot; is
made does<br>
this imply there is a matrix relationship that can be established from
one<br>
parent policy (/rule)? How is this managed? Why is this required? 
If<br>
policies have hierarchical structure can this not be done with
containment<br>
or another relationship?<br>
I think I had better re-read the thread as maybe I've missed
something.<br>
--------------------------------------------------------------------------<br>
Regards,<br>
Ken Roberts<br>
INM Product Architecture<br>
Nortel Networks<br>
?ESN&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
655-7844&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
?Direct&nbsp; : 408-565-7844<br>
?&nbsp; Fax&nbsp;&nbsp;&nbsp; :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
408-565-8226<br>
? email :&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; kjr@nortelnetworks.com<br>
<br>
This message may contain information proprietary to Nortel Networks<br>
Corporation so any<br>
unauthorised disclosure, copying or distribution of its contents is
strictly<br>
prohibited.<br>
&nbsp;-----Original Message-----<br>
From:&nbsp;&nbsp; Andrew Smith
[<a href="mailto:andrew@extremenetworks.com" eudora="autourl">mailto:andrew@extremenetworks.com</a>]<br>
Sent:&nbsp;&nbsp; Monday, January 31, 2000 3:36 PM<br>
To:&nbsp;&nbsp;&nbsp;&nbsp; 'Bob Natale'<br>
Cc:&nbsp;&nbsp;&nbsp;&nbsp; policy@raleigh.ibm.com;
'snmpconf@snmp.com'<br>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: Policy issues:
definition of Roles<br>
And, in particular, you only need to tell the device about those roles
that<br>
are relevant to it - that is where the big savings are, I think.
e.g.<br>
1. Device A has roles W, X and Y.<br>
2. Device B has roles W, X and Z.<br>
3. A policy that references roles W and X should be downloaded to
both<br>
devices.<br>
4. A policy that references roles W and Y should be downloaded only
to<br>
device A, not device B.<br>
The role combination concept in the PIB was introduced specifically in
order<br>
<br>
to do this: you have to be able to list only those roles that are
relevant<br>
to the policy, not necessarily ALL roles on the device, in a role<br>
combination.<br>
(Apologies if I'm repeating stuff here).<br>
Andrew<br>
<br>
<br>
&gt; -----Original Message-----<br>
&gt; From: Bob Natale
[<a href="mailto:bnatale@acecomm.com" eudora="autourl">mailto:bnatale@acecomm.com</a>]<br>
&gt; Sent: Monday, January 31, 2000 3:27 PM<br>
&gt; To: Andrew Smith<br>
&gt; Cc: policy@raleigh.ibm.com<br>
&gt; Subject: RE: Policy issues: definition of Roles<br>
...<br>
&gt; That works fine for me.&nbsp; All I care about on this thread is
that a<br>
&gt; &quot;role combination&quot; DOES NOT HAVE to include ALL of the
roles supported<br>
&gt; by a network entity/component (although there MAY well be a
role<br>
&gt; combination which does incorporate all roles supported by a
network<br>
&gt; entity/component).</blockquote></blockquote><br>
<br>
__________________________________________________________________<br>
Shai Herzog, Founder &amp; CTO&nbsp;&nbsp; IPHighway Inc.&nbsp;&nbsp; Tel
: (914) 654-4810<br>
55 New York
Avenue&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Main: (508) 620-1141<br>
Framingham, MA
01701&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax : (212) 656-1006<br>
<br>
<br>
<br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
<br>
</blockquote></html>

--=====================_43600744==_.ALT--


From owner-ipsec-policy  Tue Feb  8 09:08:56 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA12866
	for ipsec-policy-bks; Tue, 8 Feb 2000 09:08:56 -0800 (PST)
Received: from bmailnj.iphighway.com ([209.3.6.76])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA12862
	for <ipsec-policy@vpnc.org>; Tue, 8 Feb 2000 09:08:55 -0800 (PST)
Received: from SHAI (216-59-44-28.usa.flashcom.net [216.59.44.28]) by bmailnj.iphighway.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id D6TZS0GR; Tue, 8 Feb 2000 12:08:46 -0500
Message-Id: <4.2.0.58.20000208113808.00ab6c60@209.3.6.76>
X-Sender: herzog@209.3.6.76
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 08 Feb 2000 12:11:24 -0500
To: "John C. Strassner" <jstrassn@cisco.com>,
        "John C. Strassner" <jstrassn@cisco.com>,
        Andrew Smith <andrew@extremenetworks.com>,
        "'Ken Roberts'" <kjr@nortelnetworks.com>
From: Shai Herzog <herzog@iphighway.com>
Subject: RE: Policy issues: definition of Roles
Cc: policy@raleigh.ibm.com, "'snmpconf@snmp.com'" <snmpconf@snmp.com>,
        rap@iphighway.com, ipsec-policy@vpnc.org
In-Reply-To: <4.2.0.58.20000208080450.00ad9a00@omega.cisco.com>
References: <4.2.0.58.20000206232138.02f037b0@209.3.6.76>
 <4.2.0.58.20000206174814.00c4a2a0@omega.cisco.com>
 <808F64DDB492D3119D3C00508B5D8D733EC4B2@SOL>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_344563736==_.ALT"
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

--=====================_344563736==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 08:22 AM 02/08/2000, John C. Strassner wrote:
>Hi Shai, comments inline.
>
>regards,
>John
>
>At 11:48 PM 2/6/00 -0500, Shai Herzog wrote:
>>I think that one of the problems is that we're confusing the
>>various levels of "roles". Let me try to make the following
>>observations:
>
><js>
>Levels of roles? If a role is indeed an attribute used as a selector, this 
>translates to levels of attributes. My head is hurting. ;-) More to the 
>point, I don't know what you mean by "levels" of roles...

Sorry, didn't mean to hurt anyone ;-)
I meant: Roles at PEP, Roles at PDP, Roles in the Schema, Roles in our
head, etc....


>I humbly submit that you're making this too complicated. Instead, thinking 
>of roles as a means to select from among a larger subset is appealing 
>because it always means the same thing each time it is used.
></js>

I think the two of us have been discussing this for perhaps years ;-)
I believe that the input to the PDP (schema, GUI, whatever) isn't
necessarily mapped 1:1 with PEP configuration (In fact, it better
not be). This means that the PDP may have as input an E-2-E definition
w/o roles ( this user gets gold service (low delay, drop) ) The PDP
gets this non-role info and converts it into COPS commands to
configure the PEP based on roles:

Role=Edge, DS GOLD Service -> Mark DSCP AF11

So, the schema didn't have roles, but roles were used in configuring the
edge router.

So, the role isn't a selector in the schema (although simple schema may
use it) it is also not a selector at the PDP, but only a selector
for the PEP to advertise the kind of roles it has, and receive policy
for each one of its roles.
...

><js>
>Seems to me that you want to differentiate between roles as used to 
>influence device configuration on the PEP level vs. roles as used to build 
>policy statements at the PDP level. Is this what you meant by "levels" of 
>roles?
>
>If so, then I suggest that we talk about PEP roles vs. PDP roles (as Keith 
>suggested earlier) vs. roles as a selector (to make me happy ;-) )
></js>

YES YES YES, you hit it bulls eye! I was talking about PEP roles only
and was trying (clumsily) to express myself, thanks!

So, lets call it "PEP ROLES"

As for the other one, I believe PDP is merely an interpreter (in comes
abstract policy, out goes device policy) so it doesn't really have
roles. So, we should find another name for the second type that you
described, perhaps "Profile" (as in "user profile, application
profile,...)? or "Usage Roles".

Shai




__________________________________________________________________
Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
55 New York Avenue                            Main: (508) 620-1141
Framingham, MA 01701                          Fax : (212) 656-1006




                              
--=====================_344563736==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 08:22 AM 02/08/2000, John C. Strassner wrote:<br>
<blockquote type=cite cite>Hi Shai, comments inline.<br>
<br>
regards,<br>
John<br>
<br>
At 11:48 PM 2/6/00 -0500, Shai Herzog wrote:<br>
<blockquote type=cite cite>I think that one of the problems is that we're
confusing the<br>
various levels of &quot;roles&quot;. Let me try to make the
following<br>
observations:</blockquote><br>
&lt;js&gt;<br>
Levels of roles? If a role is indeed an attribute used as a selector,
this translates to levels of attributes. My head is hurting. ;-) More to
the point, I don't know what you mean by &quot;levels&quot; of
roles...</blockquote><br>
Sorry, didn't mean to hurt anyone ;-)<br>
I meant: Roles at PEP, Roles at PDP, Roles in the Schema, Roles in
our<br>
head, etc....<br>
<br>
<br>
<blockquote type=cite cite>I humbly submit that you're making this too
complicated. Instead, thinking of roles as a means to select from among a
larger subset is appealing because it always means the same thing each
time it is used.<br>
&lt;/js&gt;</blockquote><br>
I think the two of us have been discussing this for perhaps years
;-)<br>
I believe that the input to the PDP (schema, GUI, whatever) isn't<br>
necessarily mapped 1:1 with PEP configuration (In fact, it better <br>
not be). This means that the PDP may have as input an E-2-E
definition<br>
w/o roles ( this user gets gold service (low delay, drop) ) The PDP<br>
gets this non-role info and converts it into COPS commands to <br>
configure the PEP based on roles:<br>
<br>
Role=Edge, DS GOLD Service -&gt; Mark DSCP AF11<br>
<br>
So, the schema didn't have roles, but roles were used in configuring
the<br>
edge router.<br>
<br>
So, the role isn't a selector in the schema (although simple schema
may<br>
use it) it is also not a selector at the PDP, but only a selector<br>
for the PEP to advertise the kind of roles it has, and receive
policy<br>
for each one of its roles.<br>
...<br>
<br>
<blockquote type=cite cite>&lt;js&gt;<br>
Seems to me that you want to differentiate between roles as used to
influence device configuration on the PEP level vs. roles as used to
build policy statements at the PDP level. Is this what you meant by
&quot;levels&quot; of roles?<br>
<br>
If so, then I suggest that we talk about PEP roles vs. PDP roles (as
Keith suggested earlier) vs. roles as a selector (to make me happy ;-)
)<br>
&lt;/js&gt;<br>
</blockquote><br>
YES YES YES, you hit it bulls eye! I was talking about PEP roles
only<br>
and was trying (clumsily) to express myself, thanks!<br>
<br>
So, lets call it &quot;PEP ROLES&quot;<br>
<br>
As for the other one, I believe PDP is merely an interpreter (in
comes<br>
abstract policy, out goes device policy) so it doesn't really have<br>
roles. So, we should find another name for the second type that you<br>
described, perhaps &quot;Profile&quot; (as in &quot;user profile,
application <br>
profile,...)? or &quot;Usage Roles&quot;.<br>
<br>
Shai<br>
<br>
<br>
<br>
<br>
<div>__________________________________________________________________</div>
<div>Shai Herzog, Founder &amp; CTO&nbsp;&nbsp; IPHighway
Inc.&nbsp;&nbsp; Tel : (914) 654-4810</div>
<div>55 New York
Avenue&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Main: (508) 620-1141</div>
<div>Framingham, MA
01701&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax : (212) 656-1006</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</div>
<br>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</div>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
</html>

--=====================_344563736==_.ALT--


From owner-ipsec-policy  Tue Feb  8 10:42:39 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA15791
	for ipsec-policy-bks; Tue, 8 Feb 2000 10:42:39 -0800 (PST)
Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA15786
	for <ipsec-policy@vpnc.org>; Tue, 8 Feb 2000 10:42:35 -0800 (PST)
From: avri.doria@nokia.com
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61])
	by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id UAA07790;
	Tue, 8 Feb 2000 20:45:25 +0200 (EET)
Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182])
	by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id UAA00950;
	Tue, 8 Feb 2000 20:45:21 +0200 (EET)
Received: by daebh01nok with Internet Mail Service (5.5.2448.0)
	id <1RM26K5L>; Tue, 8 Feb 2000 12:44:48 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E46B5797B@bseis01nok>
To: herzog@iphighway.com, jstrassn@cisco.com, andrew@extremenetworks.com,
        kjr@nortelnetworks.com
Cc: policy@raleigh.ibm.com, snmpconf@snmp.com, rap@iphighway.com,
        ipsec-policy@vpnc.org
Subject: RE: Policy issues: definition of Roles
Date: Tue, 8 Feb 2000 12:44:22 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>


So, the role isn't a selector in the schema (although simple schema may
use it) it is also not a selector at the PDP, but only a selector
for the PEP to advertise the kind of roles it has, and receive policy
for each one of its roles.
...
 

 

 


<js>
Seems to me that you want to differentiate between roles as used to
influence device configuration on the PEP level vs. roles as used to build
policy statements at the PDP level. Is this what you meant by "levels" of
roles?

If so, then I suggest that we talk about PEP roles vs. PDP roles (as Keith
suggested earlier) vs. roles as a selector (to make me happy ;-) )
</js>



YES YES YES, you hit it bulls eye! I was talking about PEP roles only
and was trying (clumsily) to express myself, thanks!

So, lets call it "PEP ROLES"

As for the other one, I believe PDP is merely an interpreter (in comes
abstract policy, out goes device policy) so it doesn't really have
roles. So, we should find another name for the second type that you
described, perhaps "Profile" (as in "user profile, application 
profile,...)? or "Usage Roles".

Shai





__________________________________________________________________
Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
55 New York Avenue                            Main: (508) 620-1141
Framingham, MA 01701                          Fax : (212) 656-1006
                                              

         
                                 
                             


From owner-ipsec-policy  Tue Feb  8 10:52:01 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id KAA16162
	for ipsec-policy-bks; Tue, 8 Feb 2000 10:52:01 -0800 (PST)
Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA16153
	for <ipsec-policy@vpnc.org>; Tue, 8 Feb 2000 10:51:57 -0800 (PST)
From: avri.doria@nokia.com
Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61])
	by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id UAA21877;
	Tue, 8 Feb 2000 20:54:47 +0200 (EET)
Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183])
	by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id UAA03660;
	Tue, 8 Feb 2000 20:54:45 +0200 (EET)
Received: by daebh02nok with Internet Mail Service (5.5.2448.0)
	id <1RM3DDL3>; Tue, 8 Feb 2000 12:54:44 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E46B5797C@bseis01nok>
To: policy@raleigh.ibm.com, snmpconf@snmp.com, rap@iphighway.com,
        ipsec-policy@vpnc.org
Subject: RE: Policy issues: definition of Roles
Date: Tue, 8 Feb 2000 12:52:30 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

>So, the role isn't a selector in the schema (although simple schema may
>use it) it is also not a selector at the PDP, but only a selector
>for the PEP to advertise the kind of roles it has, and receive policy
>for each one of its roles.


I do not understand why roles are not used at the PDP.
I thought that roles was the way the PDP determined
which policies needed to be applied to the PEPs it was
dealing with.

In fact I was thinking that roles where the main link
between policies and the objects they affected, no matter
were in the architecture this occurs (e.g. at the PDP).

Regards,

a.
-----------------------------------
avri doria
Office: +1 781 993 4645
Mobile: +1 781 308 7680                
 

From owner-ipsec-policy  Tue Feb  8 10:57:59 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA16377
	for ipsec-policy-bks; Tue, 8 Feb 2000 10:57:59 -0800 (PST)
Received: from bmailnj.iphighway.com ([209.3.6.76])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA16373
	for <ipsec-policy@vpnc.org>; Tue, 8 Feb 2000 10:57:58 -0800 (PST)
Received: from SHAI (216-59-44-28.usa.flashcom.net [216.59.44.28]) by bmailnj.iphighway.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id D6TZS02D; Tue, 8 Feb 2000 13:57:53 -0500
Message-Id: <4.2.0.58.20000208134959.01ac2500@209.3.6.76>
X-Sender: herzog@209.3.6.76
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 08 Feb 2000 14:00:46 -0500
To: avri.doria@nokia.com, jstrassn@cisco.com, andrew@extremenetworks.com,
        kjr@nortelnetworks.com
From: Shai Herzog <herzog@iphighway.com>
Subject: RE: Policy issues: definition of Roles
Cc: policy@raleigh.ibm.com, snmpconf@snmp.com, rap@iphighway.com,
        ipsec-policy@vpnc.org
In-Reply-To: <B9CFA6CE8FFDD211A1FB0008C7894E46B5797B@bseis01nok>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Yap.

It just dawned on me that a roles are "logical interfaces" in the
router, as opposed to "physical interfaces".

So, in a router with physical interfaces S0..S4, rather than

SNMP:

"Configure interface S0 with ....."
"Configure interface S1 with ....."
"Configure interface S2 with ....."
"Configure interface S3 with ....."
"Configure interface S4 with ....."

The PDP says (using COPS or similar):

"Configure role "Edge+Serial" with ....."

And the PEP knows that it has 5 serial physical interfaces with this
role combination and configures S0..S4 with ....

Shai

P.S., ...With a note regarding "user profiles" and other attributes
used in the schema, which may overload the term Roles but aren't
related to the PEP roles. I call it user profiles since this
is the terminology used in security, access policies, and many
other areas of networking.


At 12:44 PM 02/08/2000, avri.doria@nokia.com wrote:
>So, the role isn't a selector in the schema (although simple schema may
>use it) it is also not a selector at the PDP, but only a selector
>for the PEP to advertise the kind of roles it has, and receive policy
>for each one of its roles.
>...
>
>
>
>
>
>
>
><js>
>Seems to me that you want to differentiate between roles as used to
>influence device configuration on the PEP level vs. roles as used to build
>policy statements at the PDP level. Is this what you meant by "levels" of
>roles?
>
>If so, then I suggest that we talk about PEP roles vs. PDP roles (as Keith
>suggested earlier) vs. roles as a selector (to make me happy ;-) )
></js>
>
>
>
>YES YES YES, you hit it bulls eye! I was talking about PEP roles only
>and was trying (clumsily) to express myself, thanks!
>
>So, lets call it "PEP ROLES"
>
>As for the other one, I believe PDP is merely an interpreter (in comes
>abstract policy, out goes device policy) so it doesn't really have
>roles. So, we should find another name for the second type that you
>described, perhaps "Profile" (as in "user profile, application
>profile,...)? or "Usage Roles".
>
>Shai
>
>
>
>
>
>__________________________________________________________________
>Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
>55 New York Avenue                            Main: (508) 620-1141
>Framingham, MA 01701                          Fax : (212) 656-1006
>
>
>
>
>


__________________________________________________________________
Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
55 New York Avenue                            Main: (508) 620-1141
Framingham, MA 01701                          Fax : (212) 656-1006




                              

From owner-ipsec-policy  Tue Feb  8 11:54:08 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id LAA18203
	for ipsec-policy-bks; Tue, 8 Feb 2000 11:54:08 -0800 (PST)
Received: from bmailnj.iphighway.com ([209.3.6.76])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA18199
	for <ipsec-policy@vpnc.org>; Tue, 8 Feb 2000 11:54:07 -0800 (PST)
Received: from SHAI (216-59-44-28.usa.flashcom.net [216.59.44.28]) by bmailnj.iphighway.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id D6TZS0JF; Tue, 8 Feb 2000 14:54:02 -0500
Message-Id: <4.2.0.58.20000208145449.00ab6c60@209.3.6.76>
X-Sender: herzog@209.3.6.76
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 08 Feb 2000 14:56:54 -0500
To: avri.doria@nokia.com, policy@raleigh.ibm.com, snmpconf@snmp.com,
        rap@iphighway.com, ipsec-policy@vpnc.org
From: Shai Herzog <herzog@iphighway.com>
Subject: RE: Policy issues: definition of Roles
In-Reply-To: <B9CFA6CE8FFDD211A1FB0008C7894E46B5797C@bseis01nok>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_354483590==_.ALT"
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

--=====================_354483590==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 12:52 PM 02/08/2000, avri.doria@nokia.com wrote:
> >So, the role isn't a selector in the schema (although simple schema may
> >use it) it is also not a selector at the PDP, but only a selector
> >for the PEP to advertise the kind of roles it has, and receive policy
> >for each one of its roles.
>
>
>I do not understand why roles are not used at the PDP.
>I thought that roles was the way the PDP determined
>which policies needed to be applied to the PEPs it was
>dealing with.

Of course the PDP uses them, but only the way they are created by
the PEP. The PDP has two sides to it, one that understands PEP stuff
(hence uses Roles) and the other that understands schemas (no roles
required).

>In fact I was thinking that roles where the main link
>between policies and the objects they affected, no matter
>were in the architecture this occurs (e.g. at the PDP).

Absolutely. See my previous message (sent after you sent this one).

I think we are in Sync.

Shai

>Regards,
>
>a.
>-----------------------------------
>avri doria
>Office: +1 781 993 4645
>Mobile: +1 781 308 7680
>


__________________________________________________________________
Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
55 New York Avenue                            Main: (508) 620-1141
Framingham, MA 01701                          Fax : (212) 656-1006




                              
--=====================_354483590==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 12:52 PM 02/08/2000, avri.doria@nokia.com wrote:<br>
<blockquote type=cite cite>&gt;So, the role isn't a selector in the
schema (although simple schema may<br>
&gt;use it) it is also not a selector at the PDP, but only a
selector<br>
&gt;for the PEP to advertise the kind of roles it has, and receive
policy<br>
&gt;for each one of its roles.<br>
<br>
<br>
I do not understand why roles are not used at the PDP.<br>
I thought that roles was the way the PDP determined<br>
which policies needed to be applied to the PEPs it was<br>
dealing with.</blockquote><br>
Of course the PDP uses them, but only the way they are created by<br>
the PEP. The PDP has two sides to it, one that understands PEP 
stuff<br>
(hence uses Roles) and the other that understands schemas (no roles<br>
required).<br>
<br>
<blockquote type=cite cite>In fact I was thinking that roles where the
main link<br>
between policies and the objects they affected, no matter<br>
were in the architecture this occurs (e.g. at the 
PDP).</blockquote><br>
Absolutely. See my previous message (sent after you sent this one).<br>
<br>
I think we are in Sync.<br>
<br>
Shai<br>
<br>
<blockquote type=cite cite>Regards,<br>
<br>
a.<br>
-----------------------------------<br>
avri doria<br>
Office: +1 781 993 4645<br>
Mobile: +1 781 308
7680&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<br>
&nbsp; </blockquote><br>
<br>
<div>__________________________________________________________________</div>
<div>Shai Herzog, Founder &amp; CTO&nbsp;&nbsp; IPHighway
Inc.&nbsp;&nbsp; Tel : (914) 654-4810</div>
<div>55 New York
Avenue&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Main: (508) 620-1141</div>
<div>Framingham, MA
01701&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax : (212) 656-1006</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</div>
<br>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</div>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
</html>

--=====================_354483590==_.ALT--


From owner-ipsec-policy  Tue Feb  8 13:00:36 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id NAA20223
	for ipsec-policy-bks; Tue, 8 Feb 2000 13:00:36 -0800 (PST)
Received: from seattle.3com.com (seattle.3com.com [129.213.128.97])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA20219
	for <ipsec-policy@vpnc.org>; Tue, 8 Feb 2000 13:00:35 -0800 (PST)
From: James_Binder@3com.com
Received: from new-york.3com.com (new-york.3com.com [129.213.157.12])
	by seattle.3com.com (8.8.8/8.8.8) with ESMTP id NAA19421;
	Tue, 8 Feb 2000 13:03:22 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104])
	by new-york.3com.com (8.8.8/8.8.8) with SMTP id NAA15892;
	Tue, 8 Feb 2000 13:03:22 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999))  id 8825687F.00737307 ; Tue, 8 Feb 2000 13:01:00 -0800
X-Lotus-FromDomain: 3COM
To: Shai Herzog <herzog@iphighway.com>
cc: avri.doria@nokia.com, jstrassn@cisco.com, andrew@extremenetworks.com,
        kjr@nortelnetworks.com, policy@raleigh.ibm.com, snmpconf@snmp.com,
        rap@iphighway.com, ipsec-policy@vpnc.org
Message-ID: <8825687F.007370B2.00@hqoutbound.ops.3com.com>
Date: Tue, 8 Feb 2000 12:56:40 -0800
Subject: RE: Policy issues: definition of Roles
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>


Maybe we should be thinking terms of "Responsibilities" as well as "Roles".
That is, Edge is "responsible" for packet classification, marking, shapping,
ect..

/jsb





Shai Herzog <herzog@iphighway.com> on 02/08/2000 11:00:46 AM

To:   avri.doria@nokia.com, jstrassn@cisco.com, andrew@extremenetworks.com,
      kjr@nortelnetworks.com
cc:   policy@raleigh.ibm.com, snmpconf@snmp.com, rap@iphighway.com,
      ipsec-policy@vpnc.org (bcc: James Binder/HQ/3Com)

Subject:  RE: Policy issues: definition of Roles




Yap.

It just dawned on me that a roles are "logical interfaces" in the
router, as opposed to "physical interfaces".

So, in a router with physical interfaces S0..S4, rather than

SNMP:

"Configure interface S0 with ....."
"Configure interface S1 with ....."
"Configure interface S2 with ....."
"Configure interface S3 with ....."
"Configure interface S4 with ....."

The PDP says (using COPS or similar):

"Configure role "Edge+Serial" with ....."

And the PEP knows that it has 5 serial physical interfaces with this
role combination and configures S0..S4 with ....

Shai

P.S., ...With a note regarding "user profiles" and other attributes
used in the schema, which may overload the term Roles but aren't
related to the PEP roles. I call it user profiles since this
is the terminology used in security, access policies, and many
other areas of networking.


At 12:44 PM 02/08/2000, avri.doria@nokia.com wrote:
>So, the role isn't a selector in the schema (although simple schema may
>use it) it is also not a selector at the PDP, but only a selector
>for the PEP to advertise the kind of roles it has, and receive policy
>for each one of its roles.
>...
>
>
>
>
>
>
>
><js>
>Seems to me that you want to differentiate between roles as used to
>influence device configuration on the PEP level vs. roles as used to build
>policy statements at the PDP level. Is this what you meant by "levels" of
>roles?
>
>If so, then I suggest that we talk about PEP roles vs. PDP roles (as Keith
>suggested earlier) vs. roles as a selector (to make me happy ;-) )
></js>
>
>
>
>YES YES YES, you hit it bulls eye! I was talking about PEP roles only
>and was trying (clumsily) to express myself, thanks!
>
>So, lets call it "PEP ROLES"
>
>As for the other one, I believe PDP is merely an interpreter (in comes
>abstract policy, out goes device policy) so it doesn't really have
>roles. So, we should find another name for the second type that you
>described, perhaps "Profile" (as in "user profile, application
>profile,...)? or "Usage Roles".
>
>Shai
>
>
>
>
>
>__________________________________________________________________
>Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
>55 New York Avenue                            Main: (508) 620-1141
>Framingham, MA 01701                          Fax : (212) 656-1006
>
>
>
>
>


__________________________________________________________________
Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
55 New York Avenue                            Main: (508) 620-1141
Framingham, MA 01701                          Fax : (212) 656-1006










From owner-ipsec-policy  Tue Feb  8 13:36:07 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id NAA21079
	for ipsec-policy-bks; Tue, 8 Feb 2000 13:36:07 -0800 (PST)
Received: from bmailnj.iphighway.com ([209.3.6.76])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA21075
	for <ipsec-policy@vpnc.org>; Tue, 8 Feb 2000 13:36:04 -0800 (PST)
Received: from SHAI (216-59-44-28.usa.flashcom.net [216.59.44.28]) by bmailnj.iphighway.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id D6TZS0L5; Tue, 8 Feb 2000 16:35:28 -0500
Message-Id: <4.2.0.58.20000208162852.00ab6c60@209.3.6.76>
X-Sender: herzog@209.3.6.76
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Tue, 08 Feb 2000 16:29:37 -0500
To: James_Binder@3com.com
From: Shai Herzog <herzog@iphighway.com>
Subject: RE: Policy issues: definition of Roles
Cc: avri.doria@nokia.com, jstrassn@cisco.com, andrew@extremenetworks.com,
        kjr@nortelnetworks.com, policy@raleigh.ibm.com, snmpconf@snmp.com,
        rap@iphighway.com, ipsec-policy@vpnc.org
In-Reply-To: <8825687F.007370B2.00@hqoutbound.ops.3com.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

At 12:56 PM 02/08/2000, James_Binder@3com.com wrote:

And what is T1's responsibility? ;-)
(...to deliver data faster than dial-up and slower than T3? ;-)

Shai



>Maybe we should be thinking terms of "Responsibilities" as well as "Roles".
>That is, Edge is "responsible" for packet classification, marking, shapping,
>ect..
>
>/jsb
>
>
>
>
>
>Shai Herzog <herzog@iphighway.com> on 02/08/2000 11:00:46 AM
>
>To:   avri.doria@nokia.com, jstrassn@cisco.com, andrew@extremenetworks.com,
>       kjr@nortelnetworks.com
>cc:   policy@raleigh.ibm.com, snmpconf@snmp.com, rap@iphighway.com,
>       ipsec-policy@vpnc.org (bcc: James Binder/HQ/3Com)
>
>Subject:  RE: Policy issues: definition of Roles
>
>
>
>
>Yap.
>
>It just dawned on me that a roles are "logical interfaces" in the
>router, as opposed to "physical interfaces".
>
>So, in a router with physical interfaces S0..S4, rather than
>
>SNMP:
>
>"Configure interface S0 with ....."
>"Configure interface S1 with ....."
>"Configure interface S2 with ....."
>"Configure interface S3 with ....."
>"Configure interface S4 with ....."
>
>The PDP says (using COPS or similar):
>
>"Configure role "Edge+Serial" with ....."
>
>And the PEP knows that it has 5 serial physical interfaces with this
>role combination and configures S0..S4 with ....
>
>Shai
>
>P.S., ...With a note regarding "user profiles" and other attributes
>used in the schema, which may overload the term Roles but aren't
>related to the PEP roles. I call it user profiles since this
>is the terminology used in security, access policies, and many
>other areas of networking.
>
>
>At 12:44 PM 02/08/2000, avri.doria@nokia.com wrote:
> >So, the role isn't a selector in the schema (although simple schema may
> >use it) it is also not a selector at the PDP, but only a selector
> >for the PEP to advertise the kind of roles it has, and receive policy
> >for each one of its roles.
> >...
> >
> >
> >
> >
> >
> >
> >
> ><js>
> >Seems to me that you want to differentiate between roles as used to
> >influence device configuration on the PEP level vs. roles as used to build
> >policy statements at the PDP level. Is this what you meant by "levels" of
> >roles?
> >
> >If so, then I suggest that we talk about PEP roles vs. PDP roles (as Keith
> >suggested earlier) vs. roles as a selector (to make me happy ;-) )
> ></js>
> >
> >
> >
> >YES YES YES, you hit it bulls eye! I was talking about PEP roles only
> >and was trying (clumsily) to express myself, thanks!
> >
> >So, lets call it "PEP ROLES"
> >
> >As for the other one, I believe PDP is merely an interpreter (in comes
> >abstract policy, out goes device policy) so it doesn't really have
> >roles. So, we should find another name for the second type that you
> >described, perhaps "Profile" (as in "user profile, application
> >profile,...)? or "Usage Roles".
> >
> >Shai
> >
> >
> >
> >
> >
> >__________________________________________________________________
> >Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
> >55 New York Avenue                            Main: (508) 620-1141
> >Framingham, MA 01701                          Fax : (212) 656-1006
> >
> >
> >
> >
> >
>
>
>__________________________________________________________________
>Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
>55 New York Avenue                            Main: (508) 620-1141
>Framingham, MA 01701                          Fax : (212) 656-1006
>
>
>
>
>
>


__________________________________________________________________
Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
55 New York Avenue                            Main: (508) 620-1141
Framingham, MA 01701                          Fax : (212) 656-1006




                              

From owner-ipsec-policy  Wed Feb  9 08:16:37 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA28902
	for ipsec-policy-bks; Wed, 9 Feb 2000 08:16:37 -0800 (PST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28893
	for <ipsec-policy@vpnc.org>; Wed, 9 Feb 2000 08:16:30 -0800 (PST)
Received: from jstrassn-lt (dhcp-171-71-229-137.cisco.com [171.71.229.137])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id IAA27134;
	Wed, 9 Feb 2000 08:17:17 -0800 (PST)
Message-Id: <4.2.0.58.20000209074033.00c1b1d0@omega.cisco.com>
X-Sender: jstrassn@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 09 Feb 2000 08:18:14 -0800
To: Shai Herzog <herzog@iphighway.com>,
        "John C. Strassner" <jstrassn@cisco.com>,
        Andrew Smith <andrew@extremenetworks.com>,
        "'Ken Roberts'" <kjr@nortelnetworks.com>
From: "John C. Strassner" <jstrassn@cisco.com>
Subject: RE: Policy issues: definition of Roles
Cc: policy@raleigh.ibm.com, "'snmpconf@snmp.com'" <snmpconf@snmp.com>,
        rap@iphighway.com, ipsec-policy@vpnc.org
In-Reply-To: <4.2.0.58.20000208113808.00ab6c60@209.3.6.76>
References: <4.2.0.58.20000208080450.00ad9a00@omega.cisco.com>
 <4.2.0.58.20000206232138.02f037b0@209.3.6.76>
 <4.2.0.58.20000206174814.00c4a2a0@omega.cisco.com>
 <808F64DDB492D3119D3C00508B5D8D733EC4B2@SOL>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_3426967==_.ALT"
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

--=====================_3426967==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Comments inline.

regards,
John

At 12:11 PM 2/8/00 -0500, Shai Herzog wrote:
>At 08:22 AM 02/08/2000, John C. Strassner wrote:
>>Hi Shai, comments inline.
>>
>>regards,
>>John
>>
>>At 11:48 PM 2/6/00 -0500, Shai Herzog wrote:
>>>I think that one of the problems is that we're confusing the
>>>various levels of "roles". Let me try to make the following
>>>observations:
>>
>><js>
>>Levels of roles? If a role is indeed an attribute used as a selector, 
>>this translates to levels of attributes. My head is hurting. ;-) More to 
>>the point, I don't know what you mean by "levels" of roles...
>
>Sorry, didn't mean to hurt anyone ;-)
>I meant: Roles at PEP, Roles at PDP, Roles in the Schema, Roles in our
>head, etc....

<js> OK, fine. You're talking about different uses of the term "role". </js>


>>I humbly submit that you're making this too complicated. Instead, 
>>thinking of roles as a means to select from among a larger subset is 
>>appealing because it always means the same thing each time it is used.
>></js>
>
>I think the two of us have been discussing this for perhaps years ;-)

<js> seems longer ;-) </js>

>I believe that the input to the PDP (schema, GUI, whatever) isn't
>necessarily mapped 1:1 with PEP configuration (In fact, it better
>not be). This means that the PDP may have as input an E-2-E definition
>w/o roles ( this user gets gold service (low delay, drop) ) The PDP
>gets this non-role info and converts it into COPS commands to
>configure the PEP based on roles:
>
>Role=Edge, DS GOLD Service -> Mark DSCP AF11
>
>So, the schema didn't have roles, but roles were used in configuring the
>edge router.

<js>
The schema may have just had policy configuration information and no roles 
as you suggest, but in this case I wonder how we achieve consistent device 
configuration? It is the role that is used to define how the edge is to be 
configured. Therefore, if each PDP defines its own role, you have chaos. On 
the other hand, if the PDP knows about a certain set of roles, then it can 
distribute these to other PDPs so that each may consistently configure the 
set of devices that it controls.
</js>

>So, the role isn't a selector in the schema (although simple schema may
>use it) it is also not a selector at the PDP, but only a selector
>for the PEP to advertise the kind of roles it has, and receive policy
>for each one of its roles.
>...

<js>
I have no problem with your above example, and is certainly a valid use of 
roles. However, it is not the only use of roles, right? Equally correct 
would be to describe the provisioning of the system using roles. There are 
two obvious examples of using roles as selectors:

   1) as a way to select the subset of policies from a large
      set of policies that are stored in the repository.
   2) as a way to retrieve the subset of policies that pertain
      to a specific set of devices or interfaces

The first way assumes that the provisioning of the system is described in 
terms of roles. This is in contrast to your example, where roles can be 
used to provision the system. The second uses roles as a selector to 
retrieve policies for specific devices or device interfaces. This is 
slightly different than the first. The first describes the behavior of the 
system. The second describes the capabilities of a device in the form of 
roles (note that this is NOT the only way, but rather ONE way, that the PEP 
can do this) so that the PDP can retrieve the policies that affect that device.
</js>


>><js>
>>Seems to me that you want to differentiate between roles as used to 
>>influence device configuration on the PEP level vs. roles as used to 
>>build policy statements at the PDP level. Is this what you meant by 
>>"levels" of roles?
>>
>>If so, then I suggest that we talk about PEP roles vs. PDP roles (as 
>>Keith suggested earlier) vs. roles as a selector (to make me happy ;-) )
>></js>
>
>YES YES YES, you hit it bulls eye! I was talking about PEP roles only
>and was trying (clumsily) to express myself, thanks!
>
>So, lets call it "PEP ROLES"
>
>As for the other one, I believe PDP is merely an interpreter (in comes
>abstract policy, out goes device policy) so it doesn't really have
>roles. So, we should find another name for the second type that you
>described, perhaps "Profile" (as in "user profile, application
>profile,...)? or "Usage Roles".

<js>
Well, we're getting very close here. Let me propose a summary to see if we 
can agree. Roles have three fundamentally different uses:

   1) to directly influence device configuration - let's
      call this PEP ROLES for now
   2) to translate from a high-level description of policy
      into one that configures the device either directly
      or indirectly - let's call this PDP ROLES for now
   3) to be used as a selector to retrieve a subset of
      applicable policies from a larger set of available
      policies - let's call this SELECTOR ROLES for now

Note that the second use is subtlely different than the third. The second 
uses roles as a means to translate between expressing policy in general 
terms and in configuring the device to implement or support that policy. So 
in Shai's example, the PDP has two inputs. One input is the definition of 
the policy from the administrator's point-of-view, which probably can not 
be used in its current form to configure devices. The other is from the 
devices that it controls. They announce their capabilities in terms of 
roles. The PDP then uses roles to translate policy from a business 
expression (Gold service, or don't allow more than 30% of my core bandwidth 
to be devoted to a certain type of traffic, or...) to a form that is used 
to ultimately configure the devices that it controls.

The third use is not focused on translation. Rather, it is a way of 
selecting policies and/or policy information to be retrieved for further 
processing.
</js>

>Shai
>
>__________________________________________________________________
>Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
>55 New York Avenue                            Main: (508) 620-1141
>Framingham, MA 01701                          Fax : (212) 656-1006

--=====================_3426967==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
Comments inline.<br>
<br>
regards,<br>
John<br>
<br>
At 12:11 PM 2/8/00 -0500, Shai Herzog wrote:<br>
<blockquote type=cite cite>At 08:22 AM 02/08/2000, John C. Strassner
wrote:<br>
<blockquote type=cite cite>Hi Shai, comments inline.<br>
<br>
regards,<br>
John<br>
<br>
At 11:48 PM 2/6/00 -0500, Shai Herzog wrote:<br>
<blockquote type=cite cite>I think that one of the problems is that we're
confusing the<br>
various levels of &quot;roles&quot;. Let me try to make the
following<br>
observations:</blockquote><br>
&lt;js&gt;<br>
Levels of roles? If a role is indeed an attribute used as a selector,
this translates to levels of attributes. My head is hurting. ;-) More to
the point, I don't know what you mean by &quot;levels&quot; of
roles...</blockquote><br>
Sorry, didn't mean to hurt anyone ;-)<br>
I meant: Roles at PEP, Roles at PDP, Roles in the Schema, Roles in
our<br>
head, etc....</blockquote><br>
&lt;js&gt; OK, fine. You're talking about different uses of the term
&quot;role&quot;. &lt;/js&gt;<br>
<br>
<br>
<blockquote type=cite cite><blockquote type=cite cite>I humbly submit
that you're making this too complicated. Instead, thinking of roles as a
means to select from among a larger subset is appealing because it always
means the same thing each time it is used.<br>
&lt;/js&gt;</blockquote><br>
I think the two of us have been discussing this for perhaps years
;-)</blockquote><br>
&lt;js&gt; seems longer ;-) &lt;/js&gt;<br>
<br>
<blockquote type=cite cite>I believe that the input to the PDP (schema,
GUI, whatever) isn't<br>
necessarily mapped 1:1 with PEP configuration (In fact, it better <br>
not be). This means that the PDP may have as input an E-2-E
definition<br>
w/o roles ( this user gets gold service (low delay, drop) ) The PDP<br>
gets this non-role info and converts it into COPS commands to <br>
configure the PEP based on roles:<br>
<br>
Role=Edge, DS GOLD Service -&gt; Mark DSCP AF11<br>
<br>
So, the schema didn't have roles, but roles were used in configuring
the<br>
edge router.</blockquote><br>
&lt;js&gt;<br>
The schema may have just had policy configuration information and no
roles as you suggest, but in this case I wonder how we achieve consistent
device configuration? It is the role that is used to define how the edge
is to be configured. Therefore, if each PDP defines its own role, you
have chaos. On the other hand, if the PDP knows about a certain set of
roles, then it can distribute these to other PDPs so that each may
consistently configure the set of devices that it controls.<br>
&lt;/js&gt;<br>
<br>
<blockquote type=cite cite>So, the role isn't a selector in the schema
(although simple schema may<br>
use it) it is also not a selector at the PDP, but only a selector<br>
for the PEP to advertise the kind of roles it has, and receive
policy<br>
for each one of its roles.<br>
...</blockquote><br>
&lt;js&gt;<br>
I have no problem with your above example, and is certainly a valid use
of roles. However, it is not the only use of roles, right? Equally
correct would be to describe the provisioning of the system using roles.
There are two obvious examples of using roles as selectors:<br>
<br>
&nbsp; 1) as a way to select the subset of policies from a large<br>
&nbsp;&nbsp;&nbsp;&nbsp; set of policies that are stored in the
repository.<br>
&nbsp; 2) as a way to retrieve the subset of policies that pertain<br>
&nbsp;&nbsp;&nbsp;&nbsp; to a specific set of devices or interfaces<br>
<br>
The first way assumes that the provisioning of the system is described in
terms of roles. This is in contrast to your example, where roles can be
used to provision the system. The second uses roles as a selector to
retrieve policies for specific devices or device interfaces. This is
slightly different than the first. The first describes the behavior of
the system. The second describes the capabilities of a device in the form
of roles (note that this is NOT the only way, but rather ONE way, that
the PEP can do this) so that the PDP can retrieve the policies that
affect that device.<br>
&lt;/js&gt;<br>
<br>
<br>
<blockquote type=cite cite><blockquote type=cite cite>&lt;js&gt;<br>
Seems to me that you want to differentiate between roles as used to
influence device configuration on the PEP level vs. roles as used to
build policy statements at the PDP level. Is this what you meant by
&quot;levels&quot; of roles?<br>
<br>
If so, then I suggest that we talk about PEP roles vs. PDP roles (as
Keith suggested earlier) vs. roles as a selector (to make me happy ;-)
)<br>
&lt;/js&gt;</blockquote><br>
YES YES YES, you hit it bulls eye! I was talking about PEP roles
only<br>
and was trying (clumsily) to express myself, thanks!<br>
<br>
So, lets call it &quot;PEP ROLES&quot;<br>
<br>
As for the other one, I believe PDP is merely an interpreter (in
comes<br>
abstract policy, out goes device policy) so it doesn't really have<br>
roles. So, we should find another name for the second type that you<br>
described, perhaps &quot;Profile&quot; (as in &quot;user profile,
application <br>
profile,...)? or &quot;Usage Roles&quot;.</blockquote><br>
&lt;js&gt;<br>
Well, we're getting very close here. Let me propose a summary to see if
we can agree. Roles have three fundamentally different uses:<br>
<br>
&nbsp; 1) to directly influence device configuration - let's<br>
&nbsp;&nbsp;&nbsp;&nbsp; call this PEP ROLES for now<br>
&nbsp; 2) to translate from a high-level description of policy<br>
&nbsp;&nbsp;&nbsp;&nbsp; into one that configures the device either
directly<br>
&nbsp;&nbsp;&nbsp;&nbsp; or indirectly - let's call this PDP ROLES for
now<br>
&nbsp; 3) to be used as a selector to retrieve a subset of<br>
&nbsp;&nbsp;&nbsp;&nbsp; applicable policies from a larger set of
available<br>
&nbsp;&nbsp;&nbsp;&nbsp; policies - let's call this SELECTOR ROLES for
now<br>
<br>
Note that the second use is subtlely different than the third. The second
uses roles as a means to translate between expressing policy in general
terms and in configuring the device to implement or support that policy.
So in Shai's example, the PDP has two inputs. One input is the definition
of the policy from the administrator's point-of-view, which probably can
not be used in its current form to configure devices. The other is from
the devices that it controls. They announce their capabilities in terms
of roles. The PDP then uses roles to translate policy from a business
expression (Gold service, or don't allow more than 30% of my core
bandwidth to be devoted to a certain type of traffic, or...) to a form
that is used to ultimately configure the devices that it controls.<br>
<br>
The third use is not focused on translation. Rather, it is a way of
selecting policies and/or policy information to be retrieved for further
processing.<br>
&lt;/js&gt;<br>
&nbsp;<br>
<blockquote type=cite cite>Shai<br>
<br>
__________________________________________________________________<br>
Shai Herzog, Founder &amp; CTO&nbsp;&nbsp; IPHighway Inc.&nbsp;&nbsp; Tel
: (914) 654-4810<br>
55 New York
Avenue&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Main: (508) 620-1141<br>
Framingham, MA
01701&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax : (212) 656-1006</blockquote></html>

--=====================_3426967==_.ALT--


From owner-ipsec-policy  Wed Feb  9 11:00:24 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA02127
	for ipsec-policy-bks; Wed, 9 Feb 2000 11:00:24 -0800 (PST)
Received: from omega.cisco.com (omega.cisco.com [171.69.63.141])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02123
	for <ipsec-policy@vpnc.org>; Wed, 9 Feb 2000 11:00:18 -0800 (PST)
Received: from jstrassn-lt (dhcp-171-71-229-137.cisco.com [171.71.229.137])
	by omega.cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id LAA20145;
	Wed, 9 Feb 2000 11:01:03 -0800 (PST)
Message-Id: <4.2.0.58.20000209093146.00b7ae70@omega.cisco.com>
X-Sender: jstrassn@omega.cisco.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Wed, 09 Feb 2000 09:56:47 -0800
To: avri.doria@nokia.com, herzog@iphighway.com, jstrassn@cisco.com,
        andrew@extremenetworks.com, kjr@nortelnetworks.com
From: "John C. Strassner" <jstrassn@cisco.com>
Subject: RE: Policy issues: definition of Roles
Cc: policy@raleigh.ibm.com, snmpconf@snmp.com, rap@iphighway.com,
        ipsec-policy@vpnc.org
In-Reply-To: <B9CFA6CE8FFDD211A1FB0008C7894E46B5797B@bseis01nok>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Hi Avri,

please see my last response. Roles have three fundamentally different uses. 
One is as a selector of policy, independent of whether the PDP or the PEP 
is involved. A second is as a translation between different forms of policy 
(e.g., a high-level business specification vs. a low-level device 
configuration specification). A third is to be able to directly influence 
device configuration.

At 12:44 PM 2/8/00 -0600, avri.doria@nokia.com wrote:


>So, the role isn't a selector in the schema (although simple schema may
>use it) it is also not a selector at the PDP, but only a selector
>for the PEP to advertise the kind of roles it has, and receive policy
>for each one of its roles.
>...
>
>
>
>
>
>
>
><js>
>Seems to me that you want to differentiate between roles as used to
>influence device configuration on the PEP level vs. roles as used to build
>policy statements at the PDP level. Is this what you meant by "levels" of
>roles?
>
>If so, then I suggest that we talk about PEP roles vs. PDP roles (as Keith
>suggested earlier) vs. roles as a selector (to make me happy ;-) )
></js>
>
>
>
>YES YES YES, you hit it bulls eye! I was talking about PEP roles only
>and was trying (clumsily) to express myself, thanks!
>
>So, lets call it "PEP ROLES"
>
>As for the other one, I believe PDP is merely an interpreter (in comes
>abstract policy, out goes device policy) so it doesn't really have
>roles. So, we should find another name for the second type that you
>described, perhaps "Profile" (as in "user profile, application
>profile,...)? or "Usage Roles".
>
>Shai
>
>
>
>
>
>__________________________________________________________________
>Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
>55 New York Avenue                            Main: (508) 620-1141
>Framingham, MA 01701                          Fax : (212) 656-1006
>
>
>
>
>
>


From owner-ipsec-policy  Wed Feb  9 11:41:53 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA02919
	for ipsec-policy-bks; Wed, 9 Feb 2000 11:41:53 -0800 (PST)
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02915
	for <ipsec-policy@vpnc.org>; Wed, 9 Feb 2000 11:41:52 -0800 (PST)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAA34106;
	Wed, 9 Feb 2000 14:44:05 -0500
Received: from lmr (dyn9-37-87-30.raleigh.ibm.com [9.37.87.30])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA20078;
	Wed, 9 Feb 2000 14:44:03 -0500
Message-ID: <001e01bf7336$35e21360$1e572509@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: <policy@raleigh.ibm.com>
Cc: <rap@iphighway.com>, <ipsec-policy@vpnc.org>, <snmpconf@snmp.com>
References: <4.2.0.58.20000208080450.00ad9a00@omega.cisco.com><4.2.0.58.20000206232138.02f037b0@209.3.6.76><4.2.0.58.20000206174814.00c4a2a0@omega.cisco.com><808F64DDB492D3119D3C00508B5D8D733EC4B2@SOL> <4.2.0.58.20000209074033.00c1b1d0@omega.cisco.com>
Subject: Re: Policy issues: definition of Roles
Date: Wed, 9 Feb 2000 14:45:23 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_001B_01BF730C.4B500380"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_001B_01BF730C.4B500380
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I like Bert's suggestion...I don't know how others feel, but my laptop =
only has 6 gig...can we confine this (and other) discussion(s) to one =
list, say policy.  Cheers, Lee

------=_NextPart_000_001B_01BF730C.4B500380
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><FONT size=3D2>I like Bert's suggestion...I =
don't know how=20
others feel, but my laptop only has 6 gig...can we confine this (and =
other)=20
discussion(s) to one list, say policy.&nbsp; Cheers, =
Lee</FONT></BODY></HTML>

------=_NextPart_000_001B_01BF730C.4B500380--


From owner-ipsec-policy  Thu Feb 10 03:01:40 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id DAA25020
	for ipsec-policy-bks; Thu, 10 Feb 2000 03:01:40 -0800 (PST)
Received: from btm4r4.alcatel.be (btm4r4.alcatel.be [195.207.101.110])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA25016
	for <ipsec-policy@vpnc.org>; Thu, 10 Feb 2000 03:01:33 -0800 (PST)
From: Rony.Baekeland@alcatel.be
Received: from bemta001.net.alcatel.be (bemta001.net.alcatel.be [138.203.144.8])
	by btm4r4.alcatel.be (8.9.1a/8.9.1) with SMTP id MAA02928
	for <ipsec-policy@vpnc.org>; Thu, 10 Feb 2000 12:03:56 +0100 (MET)
Received: by bemta001.net.alcatel.be(Lotus SMTP MTA v4.6.4  (830.2 3-23-1999))  id C1256881.003CC85B ; Thu, 10 Feb 2000 12:03:54 +0100
X-Lotus-FromDomain: ALCATEL
To: ipsec-policy@vpnc.org
Message-ID: <C1256881.003CBB09.00@bemta001.net.alcatel.be>
Date: Thu, 10 Feb 2000 12:03:19 +0100
Subject: ipsec-policy-request@vpnc.org
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>


subscribe



From owner-ipsec-policy  Fri Feb 11 06:04:44 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id GAA13250
	for ipsec-policy-bks; Fri, 11 Feb 2000 06:04:44 -0800 (PST)
Received: from bmailnj.iphighway.com ([209.3.6.76])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA13245
	for <ipsec-policy@vpnc.org>; Fri, 11 Feb 2000 06:04:37 -0800 (PST)
Received: from SHAI (216-59-44-28.usa.flashcom.net [216.59.44.28]) by bmailnj.iphighway.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0)
	id D6TZTA66; Fri, 11 Feb 2000 09:04:33 -0500
Message-Id: <4.2.0.58.20000211090103.02de3f10@209.3.6.76>
X-Sender: herzog@209.3.6.76
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 11 Feb 2000 09:05:23 -0500
To: "John C. Strassner" <jstrassn@cisco.com>,
        "John C. Strassner" <jstrassn@cisco.com>,
        Andrew Smith <andrew@extremenetworks.com>,
        "'Ken Roberts'" <kjr@nortelnetworks.com>
From: Shai Herzog <herzog@iphighway.com>
Subject: RE: Policy issues: definition of Roles
Cc: policy@raleigh.ibm.com, "'snmpconf@snmp.com'" <snmpconf@snmp.com>,
        rap@iphighway.com, ipsec-policy@vpnc.org
In-Reply-To: <4.2.0.58.20000209074033.00c1b1d0@omega.cisco.com>
References: <4.2.0.58.20000208113808.00ab6c60@209.3.6.76>
 <4.2.0.58.20000208080450.00ad9a00@omega.cisco.com>
 <4.2.0.58.20000206232138.02f037b0@209.3.6.76>
 <4.2.0.58.20000206174814.00c4a2a0@omega.cisco.com>
 <808F64DDB492D3119D3C00508B5D8D733EC4B2@SOL>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_592727597==_.ALT"
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

--=====================_592727597==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

At 08:18 AM 02/09/2000, John C. Strassner wrote:

><js>
>Well, we're getting very close here. Let me propose a summary to see if we 
>can agree. Roles have three fundamentally different uses:
>
>   1) to directly influence device configuration - let's
>      call this PEP ROLES for now
>   2) to translate from a high-level description of policy
>      into one that configures the device either directly
>      or indirectly - let's call this PDP ROLES for now
>   3) to be used as a selector to retrieve a subset of
>      applicable policies from a larger set of available
>      policies - let's call this SELECTOR ROLES for now
>
>Note that the second use is subtlely different than the third. The second 
>uses roles as a means to translate between expressing policy in general 
>terms and in configuring the device to implement or support that policy. 
>So in Shai's example, the PDP has two inputs. One input is the definition 
>of the policy from the administrator's point-of-view, which probably can 
>not be used in its current form to configure devices. The other is from 
>the devices that it controls. They announce their capabilities in terms of 
>roles. The PDP then uses roles to translate policy from a business 
>expression (Gold service, or don't allow more than 30% of my core 
>bandwidth to be devoted to a certain type of traffic, or...) to a form 
>that is used to ultimately configure the devices that it controls.
>
>The third use is not focused on translation. Rather, it is a way of 
>selecting policies and/or policy information to be retrieved for further 
>processing.

The #1 is agreed upon, but I fail to see the #2 & #3 being separate
and I have a hard time with "PDP" roles given that PDP is a translation
machine and doe not have its own definition or determination of policy
(or roles for that matter). It takes two types of input, one from above
(schema) and one from bellow (device). Those inputs may have roles in
them, but those are different "role types".


PEP Roles <-----------> PDP <---------------> Schema Roles

The job of the PDP is to bridge between PEPs and Schema, but it doesn't
have roles or policy per se.

Shai


__________________________________________________________________
Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
55 New York Avenue                            Main: (508) 620-1141
Framingham, MA 01701                          Fax : (212) 656-1006




                              
--=====================_592727597==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
At 08:18 AM 02/09/2000, John C. Strassner wrote:<br>
<br>
<blockquote type=cite cite>&lt;js&gt;<br>
Well, we're getting very close here. Let me propose a summary to see if
we can agree. Roles have three fundamentally different uses:<br>
<br>
&nbsp; 1) to directly influence device configuration - let's<br>
&nbsp;&nbsp;&nbsp;&nbsp; call this PEP ROLES for now<br>
&nbsp; 2) to translate from a high-level description of policy<br>
&nbsp;&nbsp;&nbsp;&nbsp; into one that configures the device either
directly<br>
&nbsp;&nbsp;&nbsp;&nbsp; or indirectly - let's call this PDP ROLES for
now<br>
&nbsp; 3) to be used as a selector to retrieve a subset of<br>
&nbsp;&nbsp;&nbsp;&nbsp; applicable policies from a larger set of
available<br>
&nbsp;&nbsp;&nbsp;&nbsp; policies - let's call this SELECTOR ROLES for
now<br>
<br>
Note that the second use is subtlely different than the third. The second
uses roles as a means to translate between expressing policy in general
terms and in configuring the device to implement or support that policy.
So in Shai's example, the PDP has two inputs. One input is the definition
of the policy from the administrator's point-of-view, which probably can
not be used in its current form to configure devices. The other is from
the devices that it controls. They announce their capabilities in terms
of roles. The PDP then uses roles to translate policy from a business
expression (Gold service, or don't allow more than 30% of my core
bandwidth to be devoted to a certain type of traffic, or...) to a form
that is used to ultimately configure the devices that it controls.<br>
<br>
The third use is not focused on translation. Rather, it is a way of
selecting policies and/or policy information to be retrieved for further
processing.</blockquote><br>
The #1 is agreed upon, but I fail to see the #2 &amp; #3 being
separate<br>
and I have a hard time with &quot;PDP&quot; roles given that PDP is a
translation<br>
machine and doe not have its own definition or determination of
policy<br>
(or roles for that matter). It takes two types of input, one from
above<br>
(schema) and one from bellow (device). Those inputs may have roles
in<br>
them, but those are different &quot;role types&quot;.<br>
<br>
<br>
PEP Roles &lt;-----------&gt; PDP &lt;---------------&gt; Schema
Roles<br>
<br>
The job of the PDP is to bridge between PEPs and Schema, but it
doesn't<br>
have roles or policy per se.<br>
<br>
Shai<br>
<br>
<br>
<div>__________________________________________________________________</div>
<div>Shai Herzog, Founder &amp; CTO&nbsp;&nbsp; IPHighway
Inc.&nbsp;&nbsp; Tel : (914) 654-4810</div>
<div>55 New York
Avenue&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Main: (508) 620-1141</div>
<div>Framingham, MA
01701&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax : (212) 656-1006</div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</div>
<br>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</div>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
</html>

--=====================_592727597==_.ALT--


From owner-ipsec-policy  Mon Feb 21 11:31:23 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id LAA26295
	for ipsec-policy-bks; Mon, 21 Feb 2000 11:31:23 -0800 (PST)
Received: from dfmail.datafellows.com (dfmail.datafellows.com [194.252.6.39])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA26291
	for <ipsec-policy@vpnc.org>; Mon, 21 Feb 2000 11:31:21 -0800 (PST)
Received: (qmail 5829 invoked from network); 21 Feb 2000 19:35:26 -0000
Received: from dfintra.datafellows.com (194.197.29.8)
  by dfmail.datafellows.com with SMTP; 21 Feb 2000 19:35:26 -0000
Received: (qmail 15866 invoked from network); 21 Feb 2000 19:34:48 -0000
Received: from df129-180.datafellows.com (HELO F-Secure.com) (10.128.129.180)
  by dfintra.datafellows.com with SMTP; 21 Feb 2000 19:34:48 -0000
Message-ID: <38B19362.74CB6CA8@F-Secure.com>
Date: Mon, 21 Feb 2000 21:34:58 +0200
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Oyj
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec-policy@vpnc.org, ipsec@lists.tislabs.com
Subject: IPSP WG solutions are too complex
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

(Reply to only one list, thanks.)

In my view what IPSP is trying to create is too complex. 
The SPS is a "swiss army knife" -type of solution, while there is
no need for that kind of a solution. There are certainly valid problems
to be solved, but the correct way would be specify only what is 
necessary, and not to try to solve everything at once.

For example, each network entity needs to have a base policy (ad hoc terminology)
so that the network entity knows what it can trust, who it's allowed to communicate
with, and so forth. This base policy is relatively static, it might
change for example when the network entity migrates to another network
location. It's perfectly OK for IETF to specify standards that define
how the base policy can be assigned for the network entity. 

However, several companies including F-Secure and Microsoft already have 
solutions for the problem of assigning a base policy for a network entity.
Such companies have little interest in changing the whole policy distribution
mechanism only to solve some of the other problems, which are not related
to the base policy (like security gateway discovery).

I would strongly suggest that the solutions created by IPSP be divided
into two categories:
1) The internal policy distribution of a company. Some companies may wish
   to employ IETF-specified policy distribution mechanisms, while other 
   companies wish to employ other, proprietary methods.
2) The problem of INTERCONNECTING network entities that belong to different
   organizations, and which have their policies defined by different authorities.
   Here we have (what I view) relevant problems for IPSP, including SGW discovery.

This division mirrors an existing philosophy already found in
routing protocols. Also, this division would enable parts of the network
to evolve in a more rapid speed than other parts. This would be similar
to an organization taking a new and improved routing protocol for its internal
network, while using an older and less capable routing protocol in interconnections
to the rest of the world.

Another reason to do this is that this would reduce the complexity of the
solutions created. As we've seen discussed quite extensively in IPSec WG,
the complexity of a solution creates bugs. The complexity of a security policy
system is just as bad as the complexity of IPSec/IKE.

Some specific issues follow..

A problem in category 2) is what happens when A wishes to contact to B using
IKE, and the connection setup fails. Here one problem is that A has really
little knowledge of WHY the setup failed, because IKE will not provide such
knowledge. I move that the correct way to solve this particular problem would
be to fix IKE (in IPSec WG) to provide sufficient information to A, so that
the IKE connection can be fixed (manually or automatically). The good way to 
solve this particular problem is not to employ SPS/SPP. If B doesn't wish to
give this information through a modified IKE, it hardly wishes to give it
through SPP either.

Another problem in category 2) is the SGW discovery problem. Let's take an example
situation: A laptop is roaming in the Internet, and it wishes to connect to its
own VPN, to a peer whose address is 10.x.y.z. Let's assume there are very many
SGWs, or some other reason, why we don't want to configure all of them statically
to the laptop. Here a policy protocol querying some server as to the correct
SGW to use is OK, and 'must' in fact be used since the peer's IP address is not routable. 
However, the protocol can be considerably simpler than (the whole of) SPP.

If the peer's IP address is routable, SGW discovery could be done by using ICMP security
failure messages. In my view this alternative should not be dismissed too lightly.
If the ICMP system is insecure ;), it should be fixed, and some WG should take on that task.

Also, a question regarding SPS: Assuming I have a laptop, and the laptop discovers
several SGWs that need to be traversed to reach point B, how would one specify
a policy that states that the laptop MAY NOT authenticate itself to any of the
SGWs that are dynamically discovered. (I'm worried in this case that No Such Agency
will try to put a SGW in the between, and discover who I am.) In any case, is there
any practical use for more than two SGWs? One between where I am now and Internet,
another between Internet and the destination? If there are no such cases, the first
SGW can be known by methods in category 1), the second by a simple SGW discovery
protocol in category 2).

Also, creating solutions incrementally in IPSP WG would make it much easier
to coordinate the solutions with those created in IPSRA, for example. Also,
incremental solutions would be much easier to take in real use. By incremental
I mean solutions that are "only what is necessary, and not everything at once".

-- 
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

F-Secure Corporation       http://www.F-Secure.com 

F-Secure products: Integrated Solutions for Enterprise Security

From owner-ipsec-policy  Mon Feb 21 13:13:23 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA28815
	for ipsec-policy-bks; Mon, 21 Feb 2000 13:13:23 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.82.195])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA28811
	for <ipsec-policy@vpnc.org>; Mon, 21 Feb 2000 13:13:21 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com
	with Novell_GroupWise; Mon, 21 Feb 2000 14:16:46 -0700
Message-Id: <s8b148ce.076@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.3.1
Date: Mon, 21 Feb 2000 14:16:41 -0700
From: "Hilarie Orman" <horman@novell.com>
To: <Ari.Huttunen@F-Secure.com>, <ipsec-policy@vpnc.org>
Subject: Re: IPSP WG solutions are too complex
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA28812
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

I think that everyone would be happy if there were only one way to
determine applicable IPSEC policy.  Knowing that there are going
to be several different proprietary solutions isn't comforting to someone
planning enterprise security for more than a small organization, is it?
Even for routing protocols, the local protocols are still standards.

You can cover the "do not authenticate" rules with a more
general base policy rules like "use only the gateways specified in
policy signed by your home organization" or "use cert A for
authentication to gateways not specified by signed policy".

Could we separate the issue into "policy at home" and "policy
away"?  Even when at home, I'd expect to have some gateway
discovery needs at times.  Secure enclaves may have their own
internal gateways, or there may be multiple, independently configured
security gateways to the outside world.  But I could believe that
dealing with the local problem could be handled with only a subset
of the machinery needed for "away".

Hilarie





From owner-ipsec-policy  Tue Feb 22 07:09:58 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id HAA10791
	for ipsec-policy-bks; Tue, 22 Feb 2000 07:09:58 -0800 (PST)
Received: from dfmail.datafellows.com (dfmail.datafellows.com [194.252.6.39])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id HAA10786
	for <ipsec-policy@vpnc.org>; Tue, 22 Feb 2000 07:09:53 -0800 (PST)
Received: (qmail 14846 invoked from network); 22 Feb 2000 08:07:19 -0000
Received: from dfintra.datafellows.com (194.197.29.8)
  by dfmail.datafellows.com with SMTP; 22 Feb 2000 08:07:19 -0000
Received: (qmail 7640 invoked from network); 22 Feb 2000 08:06:41 -0000
Received: from df129-180.datafellows.com (HELO F-Secure.com) (10.128.129.180)
  by dfintra.datafellows.com with SMTP; 22 Feb 2000 08:06:41 -0000
Message-ID: <38B2439F.F81C4124@F-Secure.com>
Date: Tue, 22 Feb 2000 10:06:55 +0200
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Oyj
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Hilarie Orman <horman@novell.com>
CC: ipsec-policy@vpnc.org
Subject: Re: IPSP WG solutions are too complex
References: <s8b148d2.021@prv-mail25.provo.novell.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Hilarie Orman wrote:
> 
> I think that everyone would be happy if there were only one way to
> determine applicable IPSEC policy.  Knowing that there are going
> to be several different proprietary solutions isn't comforting to someone
> planning enterprise security for more than a small organization, is it?
> Even for routing protocols, the local protocols are still standards.

I agree that standards based solutions are preferrable. What I argue is
that the intradomain problem space is sufficiently different from the
interdomain problem space to warrant separate solutions for the two.
Here the crucial thing to note is that 'intradomain' would be the setting
of the security policy by one authority, regardless of whether the network
entity in question is inside or outside of any particular networking domain.
'Interdomain' would concern issues relating to policy negotiation between
network entities that are policied by different authorities.

This would allow organizations to choose either standards based or 
proprietary methods (like the Active Directory or the F-Secure Framework)
for their internal security configuration needs. The decision would
be based on the needs of the organization, and the marketplace.

Further, the internal security configuration methods would be able
to change independently from the external security negotiation methods.
This would be useful, for example, if the new security policy system
used internally would be able to combat security problems that the
old system couldn't. (In combination with new internally deployed software.)

> You can cover the "do not authenticate" rules with a more
> general base policy rules like "use only the gateways specified in
> policy signed by your home organization" or "use cert A for
> authentication to gateways not specified by signed policy".

How would you specify these policy rules using a) SPSL, b) policy schema?

At least I don't see a good way to achieve either. I suggest that one
reason for this is that these rules are not meaningful in an interdomain
security policy negotiation. A domain would not wish to inform other domains
of these rules, they would become evident to the other domains by the actions
taken by this domain. E.g. another domain would just notice that "cert A"
is being used without knowing why this domain used it.
 
> Could we separate the issue into "policy at home" and "policy
> away"?  Even when at home, I'd expect to have some gateway
> discovery needs at times.  Secure enclaves may have their own
> internal gateways, or there may be multiple, independently configured
> security gateways to the outside world.  But I could believe that
> dealing with the local problem could be handled with only a subset
> of the machinery needed for "away".

I would like to handle this with an intradomain policy that is dependent
on the location where the network entity resides. Here the crucial thing
to discover is what policy should be used in the current network location.
The policy itself, however, is ultimately provided by the same authority,
there is no need to 'negotiate'.

> 
> Hilarie

Ari

-- 
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

F-Secure Corporation       http://www.F-Secure.com 

F-Secure products: Integrated Solutions for Enterprise Security

From owner-ipsec-policy  Tue Feb 22 08:07:59 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA13378
	for ipsec-policy-bks; Tue, 22 Feb 2000 08:07:59 -0800 (PST)
Received: from squatch.ir.bbn.com (squatch.ir.bbn.com [192.1.98.166])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA13373
	for <ipsec-policy@vpnc.org>; Tue, 22 Feb 2000 08:07:56 -0800 (PST)
Received: (qmail 42886 invoked by uid 20813); 22 Feb 2000 16:11:52 -0000
Date: 22 Feb 2000 16:11:52 -0000
Message-ID: <20000222161152.42885.qmail@squatch.ir.bbn.com>
From: Matthew Condell <mcondell@bbn.com>
To: ipsec-policy@vpnc.org
Subject: Re: IPSP WG solutions are too complex
Reply-to: mcondell@bbn.com
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

>I would strongly suggest that the solutions created by IPSP be divided
>into two categories:
>1) The internal policy distribution of a company. Some companies may wish
>   to employ IETF-specified policy distribution mechanisms, while other 
>   companies wish to employ other, proprietary methods.

SPS/SPP doesn't try to solve the problem of distributing base policy
within a company.  The only part of the protocol that attempts to do
anything along these lines is the transfer record that helps a
secondary policy server sync up with the primary server.  It tries to
determine a policy to be used to protect a particular communication
using the policies already distributed to hosts within the network.

>2) The problem of INTERCONNECTING network entities that belong to different
>   organizations, and which have their policies defined by different
>   authorities.  Here we have (what I view) relevant problems for
>   IPSP, including SGW discovery.

This is what SPP tries to accomplish.

>A problem in category 2) is what happens when A wishes to contact to B using
>IKE, and the connection setup fails. Here one problem is that A has really
>little knowledge of WHY the setup failed, because IKE will not provide such
>knowledge. I move that the correct way to solve this particular problem would
>be to fix IKE (in IPSec WG) to provide sufficient information to A, so that
>the IKE connection can be fixed (manually or automatically). The good way to 
>solve this particular problem is not to employ SPS/SPP. If B doesn't wish to
>give this information through a modified IKE, it hardly wishes to give it
>through SPP either.

SPP doesn't attempt to provide this information, either.

>Another problem in category 2) is the SGW discovery problem. Let's
>take an example situation: A laptop is roaming in the Internet, and it
>wishes to connect to its own VPN, to a peer whose address is
>10.x.y.z. Let's assume there are very many SGWs, or some other reason,
>why we don't want to configure all of them statically to the
>laptop. Here a policy protocol querying some server as to the correct
>SGW to use is OK, and 'must' in fact be used since the peer's IP
>address is not routable.  However, the protocol can be considerably
>simpler than (the whole of) SPP.

One reason not to configure all the SGWs is that you may not know
all the SGWs that your communication will encounter.

>If the peer's IP address is routable, SGW discovery could be done by
>using ICMP security failure messages. In my view this alternative
>should not be dismissed too lightly.  If the ICMP system is insecure
>;), it should be fixed, and some WG should take on that task.

Security aside, is this solution really less complex than SPP's
gateway discovery?  Also, it negates any benefit of the policy
discovery/negotiation part of SPP.

>Also, a question regarding SPS: Assuming I have a laptop, and the
>laptop discovers several SGWs that need to be traversed to reach point
>B, how would one specify a policy that states that the laptop MAY NOT
>authenticate itself to any of the SGWs that are dynamically
>discovered. (I'm worried in this case that No Such Agency will try to
>put a SGW in the between, and discover who I am.) In any case, is

SPP, as currently defined, doesn't authenticate the end-host to the
SGW's, only it's local policy server.  The policy server does the
rest.  SPP also only "discovers" the gateways that require security
associations for the communication. If you don't want a security 
association with unknown SGW's, that's easy to specify using a 
language like SPSL.

>there any practical use for more than two SGWs? One between where I am
>now and Internet, another between Internet and the destination? If
>there are no such cases, the first SGW can be known by methods in
>category 1), the second by a simple SGW discovery protocol in category
>2).

Sure.  Engineering in company A wants to talk to engineering in
company B.  Both engineering departments have their own SGW within
their corporate SGW.  That's 4 SGWs to deal with.  If one of the
groups within one of the engineering departments has its own SGW,
you have more.

Matt Condell

From owner-ipsec-policy  Tue Feb 22 20:40:52 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id UAA08133
	for ipsec-policy-bks; Tue, 22 Feb 2000 20:40:52 -0800 (PST)
Received: from dfssl.exchange.microsoft.com ([131.107.88.59])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA08129
	for <ipsec-policy@vpnc.org>; Tue, 22 Feb 2000 20:40:31 -0800 (PST)
Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 22 Feb 2000 20:41:41 -0800 (Pacific Standard Time)
Received: by dfssl with Internet Mail Service (5.5.2650.21)
	id <198BL6YX>; Tue, 22 Feb 2000 20:41:41 -0800
Message-ID: <4992824A0863D211964B0008C7B1ACB80A5BD553@fifi.platinum.corp.microsoft.com>
From: William Dixon <wdixon@exchange.microsoft.com>
To: ipsec-policy@vpnc.org
Cc: "Luis A. Sanchez" <lsanchez@bbn.com>,
        "Jason, Jamie"
	 <jamie.jason@intel.com>
Subject: RE: IPSP WG solutions are too complex
Date: Tue, 22 Feb 2000 20:41:39 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Well, either we decide that IPSec can only be deployed in a particular way
that requires traversal of security gateways so we can constrain the process
of "determining policy", which would mean revise the architecture doc to
build in security gateways and their discovery, or we accept the current
IPSec RFC model for end-to-end security with a few points of minimal
allow/deny control and agree on protocol configuration.  That leaves
"determining policy" and the presence of gateways to the customer &
management software.  I favor the latter. 

So let's initially focus on secure configuration in IPSec policy WG so we
can concretely deliver something that would enable interop.

>From the last IETF _adhoc_ policy meeting in the lobby Sunday, we recognized
there is a big difference between policies and that we have to clarify what
and where we do work.  I see the following types of policies being discussed
in rough order from bottom up.

-----------------------------------------------------------------------
Protocol Configuration Policies --------------

-- Base IPSec engine configuration - IPSP defined, PEP, supported in
products by either API or policy representation of how to apply security
actions on packets for the appropriate mode, meets all RFC 2401
requirements.  Does not include any "access control", only config info
sufficient to enable the behavior that Hilarie, myself, Ari and others need.
  a. Identity protect mode (MM/QM) - MM IP only "filters", QM 5 tuple
filters with filter actions (permit, block, negotiate) with associates
cipher suite proposals
  b. Aggressive mode - equivalent of QM filter with MM attributes also
associated
  c. Other modes should fit here

-- Other client config information - not in IPSP.  like route table entries,
additional filters, IKE-CFG info, IPSP just defines place in the config blob
where these go.  Vendors can publish their own specs if they like.


Behavioral Policies ----------------

-- IPSec audit/event controls - not in IPSP initially, but with defined
place just like access control, linked to the MIB & RFC requirements for
audit, so it could be added later.

-- IPSec access control - recommend IPSP doesn't deal with this, just
provides requirement for callouts during IKE negotiation steps, after each
auth, at the end of each phase.  Likely requirement is to enable RADIUS
attribute representation of the data required for the decision.  Some people
want static representation of access control policies, some need dynamic
request/reply between PEP & PDP, so I don't see cross vendor agreement soon.

-- Custom behaviors - e.g. monitoring, notifications, and other stuff
related to what value vendors what to add.


Management Policies ----------------

-- Custom higher level "policies" - not in IPSP.  These are really
embodiments of management models, which products define and distinguish, may
include additional product specific info, such as userid, groups of users,
typical Remote Access Policy as we have today (e.g. notion of "my internal
network" or virtual topology, etc) - these are ultimately translated into
config & behavioral policy for the systems involved.


IPSec Policy Distribution Mechanisms ------------

File -- (format in IPSP for the policy components that are in IPSP)
-- secured blob - some kind of PK signed blob, preferably one that people
have parsers for, a PKCS #12 that contains a cert with a parsable data field
containing policy.  This is used to export config info & import it between
vendors.  The format also provides for vendor extensions to config &
behavior, using their IKE VendorID as an identifying label.

Formatted Retrieval via Transports -- (formats in IPSP for the policy
components that are in IPSP)
-- LDAP
-- COPS
-- XML

Change Notification -- (not in IPSP??)
-- defined by management system

----------------------------------------------------------------------------
-------
Yes Ari, I think IKE should be improved to define the error conditions and
notify contents, and then fixed to optionally provide unauthenticated
notifications based on policy setting, and to SHOULD provide authenticated
notifies.

The IMCP method of discovery is a very useful one, particularly for internal
networks, and should be pursued by the IPSec WG.

Policy systems will surely be attacked as a means of subverting security
service provided.  So the simpler we make the base mechanisms and the
security for them, the better.  

From owner-ipsec-policy  Fri Feb 25 06:42:05 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id GAA26198
	for ipsec-policy-bks; Fri, 25 Feb 2000 06:42:05 -0800 (PST)
Received: from dfmail.datafellows.com (dfmail.datafellows.com [194.252.6.39])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA26193
	for <ipsec-policy@vpnc.org>; Fri, 25 Feb 2000 06:42:02 -0800 (PST)
Received: (qmail 30815 invoked from network); 25 Feb 2000 14:46:22 -0000
Received: from dfintra.datafellows.com (HELO dfintra.f-secure.com) (194.197.29.8)
  by dfmail.datafellows.com with SMTP; 25 Feb 2000 14:46:22 -0000
Received: (qmail 7537 invoked from network); 25 Feb 2000 14:45:42 -0000
Received: from df129-180.datafellows.com (HELO F-Secure.com) (10.128.129.180)
  by dfintra.datafellows.com with SMTP; 25 Feb 2000 14:45:42 -0000
Message-ID: <38B695BA.7B1B78C1@F-Secure.com>
Date: Fri, 25 Feb 2000 16:46:18 +0200
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Oyj
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec-policy@vpnc.org
Subject: [Fwd: IPSP WG solutions are too complex]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

This is a resend due to mail system fault...
//Ari

Ari Huttunen wrote:
> 
> Hilarie Orman wrote:
> >
> > I think that everyone would be happy if there were only one way to
> > determine applicable IPSEC policy.  Knowing that there are going
> > to be several different proprietary solutions isn't comforting to someone
> > planning enterprise security for more than a small organization, is it?
> > Even for routing protocols, the local protocols are still standards.
> 
> I agree that standards based solutions are preferrable. What I argue is
> that the intradomain problem space is sufficiently different from the
> interdomain problem space to warrant separate solutions for the two.
> Here the crucial thing to note is that 'intradomain' would be the setting
> of the security policy by one authority, regardless of whether the network
> entity in question is inside or outside of any particular networking domain.
> 'Interdomain' would concern issues relating to policy negotiation between
> network entities that are policied by different authorities.
> 
> This would allow organizations to choose either standards based or
> proprietary methods (like the Active Directory or the F-Secure Framework)
> for their internal security configuration needs. The decision would
> be based on the needs of the organization, and the marketplace.
> 
> Further, the internal security configuration methods would be able
> to change independently from the external security negotiation methods.
> This would be useful, for example, if the new security policy system
> used internally would be able to combat security problems that the
> old system couldn't. (In combination with new internally deployed software.)
> 
> > You can cover the "do not authenticate" rules with a more
> > general base policy rules like "use only the gateways specified in
> > policy signed by your home organization" or "use cert A for
> > authentication to gateways not specified by signed policy".
> 
> How would you specify these policy rules using a) SPSL, b) policy schema?
> 
> At least I don't see a good way to achieve either. I suggest that one
> reason for this is that these rules are not meaningful in an interdomain
> security policy negotiation. A domain would not wish to inform other domains
> of these rules, they would become evident to the other domains by the actions
> taken by this domain. E.g. another domain would just notice that "cert A"
> is being used without knowing why this domain used it.
> 
> > Could we separate the issue into "policy at home" and "policy
> > away"?  Even when at home, I'd expect to have some gateway
> > discovery needs at times.  Secure enclaves may have their own
> > internal gateways, or there may be multiple, independently configured
> > security gateways to the outside world.  But I could believe that
> > dealing with the local problem could be handled with only a subset
> > of the machinery needed for "away".
> 
> I would like to handle this with an intradomain policy that is dependent
> on the location where the network entity resides. Here the crucial thing
> to discover is what policy should be used in the current network location.
> The policy itself, however, is ultimately provided by the same authority,
> there is no need to 'negotiate'.
> 
> >
> > Hilarie
> 
> Ari
> 
> --
> Ari Huttunen                   phone: +358 9 859 900
> Senior Software Engineer       fax  : +358 9 8599 0452
> 
> F-Secure Corporation       http://www.F-Secure.com
> 
> F-Secure products: Integrated Solutions for Enterprise Security

-- 
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

F-Secure Corporation       http://www.F-Secure.com 

F-Secure products: Integrated Solutions for Enterprise Security

From owner-ipsec-policy  Fri Feb 25 06:35:33 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id GAA26016
	for ipsec-policy-bks; Fri, 25 Feb 2000 06:35:33 -0800 (PST)
Received: from dfmail.datafellows.com (dfmail.datafellows.com [194.252.6.39])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA26011
	for <ipsec-policy@vpnc.org>; Fri, 25 Feb 2000 06:35:31 -0800 (PST)
Received: (qmail 30609 invoked from network); 25 Feb 2000 14:39:50 -0000
Received: from dfintra.datafellows.com (HELO dfintra.f-secure.com) (194.197.29.8)
  by dfmail.datafellows.com with SMTP; 25 Feb 2000 14:39:50 -0000
Received: (qmail 6176 invoked from network); 25 Feb 2000 14:39:10 -0000
Received: from df129-180.datafellows.com (HELO F-Secure.com) (10.128.129.180)
  by dfintra.datafellows.com with SMTP; 25 Feb 2000 14:39:10 -0000
Message-ID: <38B69432.5327C84F@F-Secure.com>
Date: Fri, 25 Feb 2000 16:39:46 +0200
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Oyj
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
CC: ipsec-policy@vpnc.org
Subject: Re: IPSP WG solutions are too complex
References: <38B19362.74CB6CA8@F-Secure.com> <v04220809b4da16073971@[128.33.238.74]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Stephen,

I hope you don't mind me replying to the whole list. This didn't
appear to be 'private mail'.

Stephen Kent wrote:
> 
> Ari,
> 
> I believe that the IPSP WG was created on the premise that there is a
> need to be able to express more sophisticated security policies for
> IPsec, and that this needs to be linked to IPsec. If you
> fundamentally don't agree with this premise, then you probably ought
> not waste your time, and that of the WG members, if your position is
> one that is fundamentally in conflict with the WG's charter.

I don't think my position is in fundamental conflict with the charter.
There certainly is a need to "express more sophisticated security policies 
for IPsec". Something along the lines of the IPSec policy schema and
some more concrete incarnations of it are most appropriate. 

As the charter says:
# 3) provide guidelines for the provisioning of IPsec policies using existing 
# policy distribution protocols. This includes profiles for distributing IPsec 
# policies over protocols such as LDAP, COPS, SNMP, and FTP, 

This should include the possibility for distributing the policies in
a proprietary way also. The protocol negotiating the resulting policies
should not care, as long as the internal way of storing the policy can
be converted to the external way.

I guess my argument could be expressed in a way more suitable 
for the WG. I.e. suppose that a network entity obtains its security
policy via LDAP. Now it would need to do SGW discovery. It's not in my
view acceptable to impose the requirement on the network node to implement
all of complicated features of the SPP/SPSL/SPS just to do a 'relatively'
simple task.

The way I interpret the SPS/SPSL/SPP drafts is that they are
"the one and only" method of doing things. They do not sufficiently
account for other methods of distributing policies, including LDAP.

I would be much happier with SPS/SPSL/SPP if the drafts specified
subsets, so that for purpose XXX you would need to implement parts
YYY and ZZZ of the system. Alternatively we could have separate
protocols for individual tasks (to be determined).

> The fact that your company and MS have "solutions" to a part of this
> problem is not really relevant to this WG, since such solutions are
> not IETF standards, unless you want to contribute your experience in
> developing these solutions as yet another input to the WG process.

Please note that these "proprietary solutions" are able to do a lot
more than just specify IPSec policies. It's not possible to just replace
them with whatever IPSP produces, since IPSP charter is not about
being able to configure everything. 

Being able to deploy enhanced solutions to parts of the problem
is in my view a good goal. This would also facilitate future IETF
protocol development to achieve same functionality.

> Another premise of the creation of this WG is that routing policies
> are NOT the same as security policies and that use of a language,
> distribution mechanism, etc. developed for the former context are not
> necessary appropriate for the latter context.

That may be true. I used the routing protocol metaphor mainly in
trying to explain my view. I'll gladly change the terminology if
you provide the the perfect one.

> 
> In response to your specific comments:
> 
>         - not all of use agree with Bruce's analysis of complexity
> problems in IPsec, so that is a contentious starting point for a
> discussion. However, one area where there is a lot of agreement re
> complexity is with regard to IKE.  In that light, it's hard to
> understand how you can suggest adding more complexity to IKE to solve
> the problems that SPS/SPP addresses!

The complexity issue is around the main functionalities of IKE. Adding
more informational messages to resolve configuration problems would
not add any noticable complexity. E.g. there is no need to negotiate
between parties whether for example the responder will return more
informative informational messages or not. That is for the responder's
internal policy.

>         - you suggested that SGW discovery be effected via ICMP (if
> the target's address is routable), followed by the observation that
> if ICMP is not secure enough to do this, then this WG should fix it.
> Changes to ICMP are definitely outside the scope of this WG, so this
> is not a viable suggestion.

I guess you're right there. IPSP cannot wait until some other
group fixes ICMP insecurity.

> 
> Steve

Ari

-- 
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

F-Secure Corporation       http://www.F-Secure.com 

F-Secure products: Integrated Solutions for Enterprise Security

From owner-ipsec-policy  Tue Feb 29 06:23:01 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id GAA10156
	for ipsec-policy-bks; Tue, 29 Feb 2000 06:23:01 -0800 (PST)
Received: from dfmail.datafellows.com (dfmail.datafellows.com [194.252.6.39])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA10151
	for <ipsec-policy@vpnc.org>; Tue, 29 Feb 2000 06:22:57 -0800 (PST)
Received: (qmail 26835 invoked from network); 29 Feb 2000 14:22:57 -0000
Received: from dfintra.datafellows.com (HELO dfintra.f-secure.com) (194.197.29.8)
  by dfmail.datafellows.com with SMTP; 29 Feb 2000 14:22:57 -0000
Received: (qmail 15091 invoked from network); 29 Feb 2000 14:22:17 -0000
Received: from df129-180.datafellows.com (HELO F-Secure.com) (10.128.129.180)
  by dfintra.datafellows.com with SMTP; 29 Feb 2000 14:22:17 -0000
Message-ID: <38BBD63C.54E2F6D@F-Secure.com>
Date: Tue, 29 Feb 2000 16:22:52 +0200
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Oyj
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec-policy@vpnc.org
Subject: SPS trust model? (Re: IPSP WG solutions are too complex)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Matt Condell wrote:
> >I would strongly suggest that the solutions created by IPSP be divided
> >into two categories:
> >1) The internal policy distribution of a company. Some companies may wish
> >   to employ IETF-specified policy distribution mechanisms, while other 
> >   companies wish to employ other, proprietary methods.
> 
> SPS/SPP doesn't try to solve the problem of distributing base policy
> within a company.  The only part of the protocol that attempts to do
> anything along these lines is the transfer record that helps a
> secondary policy server sync up with the primary server.  It tries to
> determine a policy to be used to protect a particular communication
> using the policies already distributed to hosts within the network.
> 
> >2) The problem of INTERCONNECTING network entities that belong to different
> >   organizations, and which have their policies defined by different
> >   authorities.  Here we have (what I view) relevant problems for
> >   IPSP, including SGW discovery.
> 
> This is what SPP tries to accomplish.

OK, it seems I've been misunderstanding the meaning of SPS. I no longer
object to the concept of SPS, only specifics about how it is done. A major
issue about the trust model is at the end of this mail.

> >A problem in category 2) is what happens when A wishes to contact to B using
> >IKE, and the connection setup fails. Here one problem is that A has really
> >little knowledge of WHY the setup failed, because IKE will not provide such
> >knowledge. I move that the correct way to solve this particular problem would
> >be to fix IKE (in IPSec WG) to provide sufficient information to A, so that
> >the IKE connection can be fixed (manually or automatically). The good way to 
> >solve this particular problem is not to employ SPS/SPP. If B doesn't wish to
> >give this information through a modified IKE, it hardly wishes to give it
> >through SPP either.
> 
> SPP doesn't attempt to provide this information, either.

I thought the COMSEC query is exactly for this purpose?

> >Another problem in category 2) is the SGW discovery problem. Let's
> >take an example situation: A laptop is roaming in the Internet, and it
> >wishes to connect to its own VPN, to a peer whose address is
> >10.x.y.z. Let's assume there are very many SGWs, or some other reason,
> >why we don't want to configure all of them statically to the
> >laptop. Here a policy protocol querying some server as to the correct
> >SGW to use is OK, and 'must' in fact be used since the peer's IP
> >address is not routable.  However, the protocol can be considerably
> >simpler than (the whole of) SPP.
> 
> One reason not to configure all the SGWs is that you may not know
> all the SGWs that your communication will encounter.

How about this scenario: A laptop belonging to security domain A
is roaming "out there". The laptop wishes to contact another
entity inside the security domain A, only the INTERNAL IP address of the
peer is know at this time. The security domain B is in the between and wishes
all communication to go through one of its SGWs.

SPS would like us to contact security domain B's policy server first
(by having B's SGW intercept the traffic), but at this time we don't
yet know where to route the packets. That information will only be
available after we contact domain A's policy server.

> >If the peer's IP address is routable, SGW discovery could be done by
> >using ICMP security failure messages. In my view this alternative
> >should not be dismissed too lightly.  If the ICMP system is insecure
> >;), it should be fixed, and some WG should take on that task.
> 
> Security aside, is this solution really less complex than SPP's
> gateway discovery?  Also, it negates any benefit of the policy
> discovery/negotiation part of SPP.

How about the question of how exactly the client knows when it should
contact the policy server? Of course the client's policy could say
that "always contact policy server", but that is inefficient, since
the most usual security policies could be configured to the client's
base policy already.

How about if the client would just try to contact the peer using the
client's base policy, and if it gets an ICMP security failure message,
the client would contact the policy server? In this case the ICMP
security doesn't have to be fixed; it's only used to know when to 
explicitly query for a new policy.

> >Also, a question regarding SPS: Assuming I have a laptop, and the
> >laptop discovers several SGWs that need to be traversed to reach point
> >B, how would one specify a policy that states that the laptop MAY NOT
> >authenticate itself to any of the SGWs that are dynamically
> >discovered. (I'm worried in this case that No Such Agency will try to
> >put a SGW in the between, and discover who I am.) In any case, is
> 
> SPP, as currently defined, doesn't authenticate the end-host to the
> SGW's, only it's local policy server.  The policy server does the
> rest.  SPP also only "discovers" the gateways that require security
> associations for the communication. If you don't want a security 
> association with unknown SGW's, that's easy to specify using a 
> language like SPSL.

A major problem with SPS is for me that I don't see how the trust model
can work. E.g.

          Security                          Security
          Domain Foo                        Domain Foo

          +----------+                      +----------+
          |  Policy  |                      |  Policy  |
          | Server A |                      | Server B |
          +----------+                      +----------+
               ^  ^                             ^  ^
+---------+ Q1 |  | Q2    /\            /\   Q2 |  | Q3 +----------+
|   Host  | R1 |  | R2   /  \  Q2/R2   /  \  R2 |  | R3 |   Host   |
|    A    |<---   -----><SGA ><------><SGB ><---   ---->|     B    |
+---------+              \  /          \  /             +----------+
                          \/            \/

How can policy server A trust that policy server B is authorative
in representing host B? The 'solution' provided by SPS/SPP is that
policy server B *claims* that it can represent host B. THIS IS NOT
SUFFICIENT. I don't see how this can be solved, except by
a) Host B issuing an X.509 attribute cert that says that it
   authorizes policy server B to represent it.
b) Using SPKI for the same purpose.

Ari

-- 
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

F-Secure Corporation       http://www.F-Secure.com 

F-Secure products: Integrated Solutions for Enterprise Security

From owner-ipsec-policy  Tue Feb 29 08:29:44 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA12888
	for ipsec-policy-bks; Tue, 29 Feb 2000 08:29:44 -0800 (PST)
Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA12884
	for <ipsec-policy@vpnc.org>; Tue, 29 Feb 2000 08:29:43 -0800 (PST)
Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.19 2000/01/29 00:15:43 dmccart Exp $) with SMTP id QAA11960
	for <ipsec-policy@vpnc.org>; Tue, 29 Feb 2000 16:30:14 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 29 Feb 2000 16:29:32 0000 (GMT)
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2448.0)
	id <FFKFP6TS>; Tue, 29 Feb 2000 08:29:30 -0800
Message-ID: <3D33CF40366DD111AC4100A0C96B22AC05AD699A@fmsmsx34.fm.intel.com>
From: "Lortz, Victor" <victor.lortz@intel.com>
To: ipsec-policy@vpnc.org
Subject: RE: SPS trust model? (Re: IPSP WG solutions are too complex)
Date: Tue, 29 Feb 2000 08:29:24 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>


> -----Original Message-----
> From:	Ari Huttunen [SMTP:Ari.Huttunen@F-Secure.com]
> Sent:	Tuesday, February 29, 2000 6:23 AM
> To:	ipsec-policy@vpnc.org
> Subject:	SPS trust model? (Re: IPSP WG solutions are too complex)
> 
[Lortz, Victor]  [prior content omitted...]

> A major problem with SPS is for me that I don't see how the trust model
> can work. E.g.
> 
>           Security                          Security
>           Domain Foo                        Domain Foo
> 
>           +----------+                      +----------+
>           |  Policy  |                      |  Policy  |
>           | Server A |                      | Server B |
>           +----------+                      +----------+
>                ^  ^                             ^  ^
> +---------+ Q1 |  | Q2    /\            /\   Q2 |  | Q3 +----------+
> |   Host  | R1 |  | R2   /  \  Q2/R2   /  \  R2 |  | R3 |   Host   |
> |    A    |<---   -----><SGA ><------><SGB ><---   ---->|     B    |
> +---------+              \  /          \  /             +----------+
>                           \/            \/
> 
> How can policy server A trust that policy server B is authorative
> in representing host B? The 'solution' provided by SPS/SPP is that
> policy server B *claims* that it can represent host B. THIS IS NOT
> SUFFICIENT. I don't see how this can be solved, except by
> a) Host B issuing an X.509 attribute cert that says that it
>    authorizes policy server B to represent it.
> b) Using SPKI for the same purpose.
> 
> Ari
> 
[Lortz, Victor]  Your diagram indicates that both policy server A and B are
in the same domain "Foo".  Is this a typo?  I had been assuming that A and B
were different domains.  If so, how does one deal with policy conflicts
between domains A and B?  Just because host B wants to use a certain set of
policies, why should hosts in security domain A consent to using them?  They
might compromise the security of host A in some way.  Importing or merging
policies from different security domains is a difficult problem even if you
know you have the right sets of policies.  I'm troubled by the prospect of
IPsec policies transparently "morphing" in unpredictable ways as hosts
connect to various security domains.  I'd rather just specify a generic
"fallback" behavior that conforms to the security requirements of a given
host and applies to all cases where policy incompatibilities prevent the
initial connection from succeeding.  

Regards,

Vic Lortz
Communications Architecture Lab
Intel Architecture Labs

>  


From owner-ipsec-policy  Tue Feb 29 11:01:33 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id LAA15150
	for ipsec-policy-bks; Tue, 29 Feb 2000 11:01:33 -0800 (PST)
Received: from squatch.ir.bbn.com (squatch.ir.bbn.com [192.1.98.166])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA15146
	for <ipsec-policy@vpnc.org>; Tue, 29 Feb 2000 11:01:32 -0800 (PST)
Received: (qmail 87056 invoked by uid 20813); 29 Feb 2000 19:01:33 -0000
Date: 29 Feb 2000 19:01:33 -0000
Message-ID: <20000229190133.87055.qmail@squatch.ir.bbn.com>
From: Matthew Condell <mcondell@bbn.com>
To: ipsec-policy@vpnc.org
Subject: Re: SPS trust model? 
Reply-to: mcondell@bbn.com
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Ari Huttunen wrote:
>> >A problem in category 2) is what happens when A wishes to contact to B using
>> >IKE, and the connection setup fails. Here one problem is that A has really
>> >little knowledge of WHY the setup failed, because IKE will not provide such
>> >knowledge. I move that the correct way to solve this particular problem would
>> >be to fix IKE (in IPSec WG) to provide sufficient information to A, so that
>> >the IKE connection can be fixed (manually or automatically). The good way to 
>> >solve this particular problem is not to employ SPS/SPP. If B doesn't wish to
>> >give this information through a modified IKE, it hardly wishes to give it
>> >through SPP either.
>> 
>> SPP doesn't attempt to provide this information, either.
>
>I thought the COMSEC query is exactly for this purpose?

The purpose fo the COMSEC query is to figure out what security
associations a host needs to use to communicate with another host,
taking into account the security requirements of both endhosts and any
intermediate gateways.  If the policies of one of the entities does
not permit the communication or a mutually acceptable SA can not be
determined, the response to the COMSEC query may not be any more 
informative than to say that the communication is not permitted.


>> >Another problem in category 2) is the SGW discovery problem. Let's
>> >take an example situation: A laptop is roaming in the Internet, and it
>> >wishes to connect to its own VPN, to a peer whose address is
>> >10.x.y.z. Let's assume there are very many SGWs, or some other reason,
>> >why we don't want to configure all of them statically to the
>> >laptop. Here a policy protocol querying some server as to the correct
>> >SGW to use is OK, and 'must' in fact be used since the peer's IP
>> >address is not routable.  However, the protocol can be considerably
>> >simpler than (the whole of) SPP.
>> 
>> One reason not to configure all the SGWs is that you may not know
>> all the SGWs that your communication will encounter.
>
>How about this scenario: A laptop belonging to security domain A
>is roaming "out there". The laptop wishes to contact another
>entity inside the security domain A, only the INTERNAL IP address of the
>peer is know at this time. The security domain B is in the between and wishes
>all communication to go through one of its SGWs.
>
>SPS would like us to contact security domain B's policy server first
>(by having B's SGW intercept the traffic), but at this time we don't
>yet know where to route the packets. That information will only be
>available after we contact domain A's policy server.

This was disscussed a bit in one of the SPS drafts.  It might have
been the original SPS architecture draft that is in the process of 
being split into multiple documents.  However, it is still an issue
that needs to be discussed more thoroughly.

A requirement we put on a mobile host outside its own security domain
is that it acts as its own policy server.  

>> >If the peer's IP address is routable, SGW discovery could be done by
>> >using ICMP security failure messages. In my view this alternative
>> >should not be dismissed too lightly.  If the ICMP system is insecure
>> >;), it should be fixed, and some WG should take on that task.
>> 
>> Security aside, is this solution really less complex than SPP's
>> gateway discovery?  Also, it negates any benefit of the policy
>> discovery/negotiation part of SPP.
>
>How about the question of how exactly the client knows when it should
>contact the policy server? Of course the client's policy could say
>that "always contact policy server", but that is inefficient, since
>the most usual security policies could be configured to the client's
>base policy already.

Many policies can be configured into the base policy, but many cannot,
since you don't necessarily have control over the policies of the 
gateways and other end-host that you are communicating with

>How about if the client would just try to contact the peer using the
>client's base policy, and if it gets an ICMP security failure message,
>the client would contact the policy server? In this case the ICMP
>security doesn't have to be fixed; it's only used to know when to 
>explicitly query for a new policy.

What we did in our implementation (I'm not sure if it has made it into
the drafts or not...) is that the policy query is done in parallel with
sending out the communication using the base policy.  If the communication
succeeds, great. If it doesn't, the policy is in place for it to be
retried.

>> >Also, a question regarding SPS: Assuming I have a laptop, and the
>> >laptop discovers several SGWs that need to be traversed to reach point
>> >B, how would one specify a policy that states that the laptop MAY NOT
>> >authenticate itself to any of the SGWs that are dynamically
>> >discovered. (I'm worried in this case that No Such Agency will try to
>> >put a SGW in the between, and discover who I am.) In any case, is
>> 
>> SPP, as currently defined, doesn't authenticate the end-host to the
>> SGW's, only it's local policy server.  The policy server does the
>> rest.  SPP also only "discovers" the gateways that require security
>> associations for the communication. If you don't want a security 
>> association with unknown SGW's, that's easy to specify using a 
>> language like SPSL.
>
>A major problem with SPS is for me that I don't see how the trust model
>can work. E.g.
>
>          Security                          Security
>          Domain Foo                        Domain Foo
>
>          +----------+                      +----------+
>          |  Policy  |                      |  Policy  |
>          | Server A |                      | Server B |
>          +----------+                      +----------+
>               ^  ^                             ^  ^
>+---------+ Q1 |  | Q2    /\            /\   Q2 |  | Q3 +----------+
>|   Host  | R1 |  | R2   /  \  Q2/R2   /  \  R2 |  | R3 |   Host   |
>|    A    |<---   -----><SGA ><------><SGB ><---   ---->|     B    |
>+---------+              \  /          \  /             +----------+
>                          \/            \/
>
>How can policy server A trust that policy server B is authorative
>in representing host B? The 'solution' provided by SPS/SPP is that
>policy server B *claims* that it can represent host B. THIS IS NOT
>SUFFICIENT. I don't see how this can be solved, except by

No question this is not sufficient.  That's why SPP does not depend
upon any policy server's claims.  The policy server records exist so
that claim can be made and can be verified.  

The processing rules state that the authoritative claims must be
verified and suggests certificates as a means of doing this.
The drafts should probably be more explicit about this and future
revisions will be.

>a) Host B issuing an X.509 attribute cert that says that it
>   authorizes policy server B to represent it.
>b) Using SPKI for the same purpose.

Matthew Condell
BBN Technologies

From owner-ipsec-policy  Wed Mar  1 01:18:11 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id BAA15698
	for ipsec-policy-bks; Wed, 1 Mar 2000 01:18:11 -0800 (PST)
Received: from dfmail.datafellows.com (dfmail.datafellows.com [194.252.6.39])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA15694
	for <ipsec-policy@vpnc.org>; Wed, 1 Mar 2000 01:18:09 -0800 (PST)
Received: (qmail 31912 invoked from network); 1 Mar 2000 09:18:11 -0000
Received: from dfintra.datafellows.com (HELO dfintra.f-secure.com) (194.197.29.8)
  by dfmail.datafellows.com with SMTP; 1 Mar 2000 09:18:11 -0000
Received: (qmail 10729 invoked from network); 1 Mar 2000 09:17:30 -0000
Received: from df129-180.datafellows.com (HELO F-Secure.com) (10.128.129.180)
  by dfintra.datafellows.com with SMTP; 1 Mar 2000 09:17:30 -0000
Message-ID: <38BCE054.EA7C0462@F-Secure.com>
Date: Wed, 01 Mar 2000 11:18:12 +0200
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Oyj
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mcondell@bbn.com
CC: ipsec-policy@vpnc.org
Subject: Re: SPS trust model?
References: <20000229190133.87055.qmail@squatch.ir.bbn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Matthew Condell wrote:
> 
> Ari Huttunen wrote:
> >How about this scenario: A laptop belonging to security domain A
> >is roaming "out there". The laptop wishes to contact another
> >entity inside the security domain A, only the INTERNAL IP address of the
> >peer is know at this time. The security domain B is in the between and wishes
> >all communication to go through one of its SGWs.
> >
> >SPS would like us to contact security domain B's policy server first
> >(by having B's SGW intercept the traffic), but at this time we don't
> >yet know where to route the packets. That information will only be
> >available after we contact domain A's policy server.
> 
> This was disscussed a bit in one of the SPS drafts.  It might have
> been the original SPS architecture draft that is in the process of
> being split into multiple documents.  However, it is still an issue
> that needs to be discussed more thoroughly.
> 
> A requirement we put on a mobile host outside its own security domain
> is that it acts as its own policy server.

What good does this do? A mobile host should not contain any other
policies than those directly applicable to it.

The way I figure this should be fixed is that the mobile host has
a base policy, which says that it "should contact a policy server
with the address x.y.z.w in its host security domain to learn about
the SGW to use to contact 10.x.y.z". After that 'ordinary' SPS/SPP
would be used to learn about the intermediate SGWs and policies 
that are necessary to contact the SGW that was learned about by
this initial query.

The problem with this is that it doesn't fit SPS, as it's currently
specified. SPS should probably be changed so that some policy
queries can pass through intermediate security domains without
any action by the intermediate security domains. (Other than inspecting
the query, perhaps..)

> >How about if the client would just try to contact the peer using the
> >client's base policy, and if it gets an ICMP security failure message,
> >the client would contact the policy server? In this case the ICMP
> >security doesn't have to be fixed; it's only used to know when to
> >explicitly query for a new policy.
> 
> What we did in our implementation (I'm not sure if it has made it into
> the drafts or not...) is that the policy query is done in parallel with
> sending out the communication using the base policy.  If the communication
> succeeds, great. If it doesn't, the policy is in place for it to be
> retried.

That creates unnecessary work for the policy server, and possibly
scalability problems.

> >A major problem with SPS is for me that I don't see how the trust model
> >can work. E.g.
> >
> >          Security                          Security
> >          Domain Foo                        Domain Foo
> >
> >          +----------+                      +----------+
> >          |  Policy  |                      |  Policy  |
> >          | Server A |                      | Server B |
> >          +----------+                      +----------+
> >               ^  ^                             ^  ^
> >+---------+ Q1 |  | Q2    /\            /\   Q2 |  | Q3 +----------+
> >|   Host  | R1 |  | R2   /  \  Q2/R2   /  \  R2 |  | R3 |   Host   |
> >|    A    |<---   -----><SGA ><------><SGB ><---   ---->|     B    |
> >+---------+              \  /          \  /             +----------+
> >                          \/            \/
> >
> >How can policy server A trust that policy server B is authorative
> >in representing host B? The 'solution' provided by SPS/SPP is that
> >policy server B *claims* that it can represent host B. THIS IS NOT
> >SUFFICIENT. I don't see how this can be solved, except by
> 
> No question this is not sufficient.  That's why SPP does not depend
> upon any policy server's claims.  The policy server records exist so
> that claim can be made and can be verified.
> 
> The processing rules state that the authoritative claims must be
> verified and suggests certificates as a means of doing this.
> The drafts should probably be more explicit about this and future
> revisions will be.

This issue is so vital to the SPS/SPP that you really must address
this in the "security considerations" section, and show beyond
reasonable doubt that the trust model is sound. "Suggesting certificates"
is not an answer. Having watched PKIX work also, I would say that
anything certificate related is very often a problem too. One specific
reason to doubt the trust model is that X.509 is not very good at
delegating authorization.

Ari

-- 
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

F-Secure Corporation       http://www.F-Secure.com 

F-Secure products: Integrated Solutions for Enterprise Security

From owner-ipsec-policy  Fri Mar 10 03:26:18 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id DAA12838
	for ipsec-policy-bks; Fri, 10 Mar 2000 03:26:18 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA12832
	for <ipsec-policy@vpnc.org>; Fri, 10 Mar 2000 03:26:16 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27999;
	Fri, 10 Mar 2000 06:27:06 -0500 (EST)
Message-Id: <200003101127.GAA27999@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipsec-policy@vpnc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsp-spsl-00.txt
Date: Fri, 10 Mar 2000 06:27:06 -0500
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Policy Working Group of the IETF.

	Title		: Security Policy Specification Language
	Author(s)	: M. Condell, C. Lynn, J Zao
	Filename	: draft-ietf-ipsp-spsl-00.txt
	Pages		: 45
	Date		: 09-Mar-00
	
This document describes the Security Policy Specification Language
(SPSL), a language designed to express security policies, security
domains, and the entities that manage the policies and domains.  The
syntax and semantics of the language are presented here.  SPSL
currently supports policies for packet filtering, IP Security (IPsec),
and IKE exchanges.  However, it may easily be extended to express
other types of policies.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsp-spsl-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipsp-spsl-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipsp-spsl-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000309135819.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsp-spsl-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipsp-spsl-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000309135819.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ipsec-policy  Fri Mar 10 12:42:48 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA26808
	for ipsec-policy-bks; Fri, 10 Mar 2000 12:42:48 -0800 (PST)
Received: from mx.crypto.com ([207.140.168.138])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA26804
	for <ipsec-policy@vpnc.org>; Fri, 10 Mar 2000 12:42:46 -0800 (PST)
Received: from fbi.crypto.com (localhost [127.0.0.1])
	by mx.crypto.com (8.9.3/8.9.3) with ESMTP id PAA14068
	for <ipsec-policy@vpnc.org>; Fri, 10 Mar 2000 15:43:39 -0500 (EST)
Received: from fbi.crypto.com (mab@localhost)
	by fbi.crypto.com (8.9.3/8.9.3) with ESMTP id PAA16573
	for <ipsec-policy@vpnc.org>; Fri, 10 Mar 2000 15:44:22 -0500
Message-Id: <200003102044.PAA16573@fbi.crypto.com>
X-Authentication-Warning: fbi.crypto.com: mab owned process doing -bs
X-Mailer: exmh version 2.1.1 10/15/1999
To: ipsec-policy@vpnc.org
Subject: Compliance Checking and IPSEC Policy Management draft available
Date: Fri, 10 Mar 2000 15:44:22 -0500
From: Matt Blaze <mab@research.att.com>
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

We've written a (rather rough) ID documenting our compliance checking
architecture for controlling IPSEC.  This essentially reflects the
KeyNote-based policy management scheme in the isakmpd distributed with
OpenBSD 2.6.

We think the idea of a two-level compliance checking hierarchy (SA policy
and packet policy), with a flexible language used for SA policy, is
a very promising approach for managing IPSEC policy.

Fortunately, there are no intellectual property issues (as far as I know).

The draft should be available in the usual ID places soon, or from
	http://www.crypto.com/papers/draft-blaze-ipsp-trustmgt-00.txt

For more information on the KeyNote language, see RFC-2704
	http://www.crypto.com/papers/rfc2704.txt
or the Trust Management web page:
	http://www.crypto.com/trustmgt/kn.html

-matt





From owner-ipsec-policy  Wed Mar 15 03:20:53 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id DAA26259
	for ipsec-policy-bks; Wed, 15 Mar 2000 03:20:53 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA26255
	for <ipsec-policy@vpnc.org>; Wed, 15 Mar 2000 03:20:52 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28252;
	Wed, 15 Mar 2000 06:22:06 -0500 (EST)
Message-Id: <200003151122.GAA28252@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: ipsec-policy@vpnc.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-ipsp-config-policy-model-00.txt
Date: Wed, 15 Mar 2000 06:22:06 -0500
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Policy Working Group of the IETF.

	Title		: IPsec Configuration Policy Model
	Author(s)	: J. Jason
	Filename	: draft-ietf-ipsp-config-policy-model-00.txt
	Pages		: 30
	Date		: 14-Mar-00
	
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].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsp-config-policy-model-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipsp-config-policy-model-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-ipsp-config-policy-model-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20000314132440.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-ipsp-config-policy-model-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ipsp-config-policy-model-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20000314132440.I-D@ietf.org>

--OtherAccess--

--NextPart--



From owner-ipsec-policy  Wed Mar 15 09:11:55 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA09185
	for ipsec-policy-bks; Wed, 15 Mar 2000 09:11:55 -0800 (PST)
Received: from nutmeg.bbn.com (NUTMEG.bbn.com [128.89.1.112])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09180
	for <ipsec-policy@vpnc.org>; Wed, 15 Mar 2000 09:11:51 -0800 (PST)
Received: (from lsanchez@localhost)
	by nutmeg.bbn.com (8.8.8/8.8.7) id MAA01412
	for ipsec-policy@vpnc.org; Wed, 15 Mar 2000 12:10:06 -0500 (EST)
	(envelope-from lsanchez)
From: "Luis A. Sanchez" <lsanchez@bbn.com>
Message-Id: <200003151710.MAA01412@nutmeg.bbn.com>
Subject: Agenda Input
To: ipsec-policy@vpnc.org
Date: Wed, 15 Mar 2000 12:10:05 -0500 (EST)
Reply-to: lsanchez@bbn.com
X-Mailer: ELM [version 2.4ME+ PL61 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Folks, if you would like a time slot to present _relevant_ material in
Adelaide please email your request to Hilarie and myself by 3/17/00 no
later than 1000hrs (EST). Thanks,

Luis

From owner-ipsec-policy  Mon Mar 27 03:34:40 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id DAA01711
	for ipsec-policy-bks; Mon, 27 Mar 2000 03:34:40 -0800 (PST)
Received: from adk.gr (dhcp-192-16.ietf.connect.com.au [169.208.192.16])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01707
	for <ipsec-policy@vpnc.org>; Mon, 27 Mar 2000 03:34:34 -0800 (PST)
Received: (from angelos@localhost)
	by adk.gr (8.9.3/8.9.3) id GAA18175
	for ipsec-policy@vpnc.org; Mon, 27 Mar 2000 06:30:20 -0500 (EST)
Date: Mon, 27 Mar 2000 06:30:20 -0500 (EST)
From: "Angelos D. Keromytis" <angelos@dsl.cis.upenn.edu>
Message-Id: <200003271130.GAA18175@adk.gr>
To: ipsec-policy@vpnc.org
Subject: minutes from meeting
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Hilarie Orman (co-chair):

We met three times as a BOF. We discussed the charter, and agreed that
we need to become an WG. Roy left, Luis, got Hillary to co-chair

Agenda:
Jamie Jason: IPSEC Configuration Policy Model
Matt Condell: SPSL
Matt Blaze: Compliance checing for IPSEC
John Zao: Semantic Model of IPSEC policy

1st presentation
----------------

Jamie Jason (jamie.jason@intel.com) gave a presentation on "IPsec
Configuration Policy Model" (available as
draft-jason-ipsp-config-policy-model-00.txt).

The draft is a synthesis of several schema documents, and is based on
UML. The draft describes the IPsec configuration model (as opposed to
an administration level, which is at a different -- presumably higher
-- layer).

The model consists of policies which contain a set of rules (composed
of conditions -- expressions and filters) and resulting in actions and
proposals (in the IKE and IPsec sense).

A policy is an ordered set of rules for both IKE and IPsec, and is
"targeted" to a particular interface on a system. An interface is
assumed to have an "IPsec role" (using the Protocol Framework WG
terminology). There may be multiple policies per interface, but only
one is active at a time.

The rules in a policy are used to associate condition criteria with
corresponding actions. Rules are not shared among policies, and may be
individual enabled/disabled.

Conditions is a set of expressions (using disjunction, conjunction,
and negation).

Filters match criteria for traffic parameters (addresses, FQDNs,
ports/ranges, etc.)

Actions are used to control IKE by specifying parameters used during
negotiations (e.g., lifetimes, IKE mode, PFS, proposals, etc.)

Proposals are used to specify individual negotiation parameters.

Issues:
 - fine line between policy and implementation, which should not
   be crossed when discussing policy.

 - how should unauthenticated messages (in IKE) be handled ?

 - vendor ID for explicit Diffie-Hellman groups or IPcomp algorithms ?

 - should rules have directionality (or be bidirectional) ? Two kinds
   of directionality: IKE (Initiator/Responder), and IP traffic. IPsec
   SAs are unidirectional, but IKE always negotiates bidirectional
   SAs, so which approach should be modeled ?

Potential future additions to the draft:
 - Fallback values (when negotiation fails).
 - Default behaviors for traffic over an interface (depending on peer ?)
 - Nested policies (different levels of administration).
 - Richer filtering capabilities.

2nd presentation
----------------

Matt Condell (mcondell@bbn.com) was not present, so Luis Sanchez
(co-chair, lsanchez@bbn.com) gave the presentation on SPSL on his
behalf. The draft on SPSL is available as draft-ietf-ipsp-spsl-00.txt

The presentation started with a language overview. SPSL is a
vendor-independent language for defining static filter, IPSEC and IKE
policies. It is extensible, and uses a class structure (management
entities, network entities, and policies, with subclasses in each
category). The language is attribute/value-based, and the attributes
may be single or multi-valued, and attributes are ordered.

Management entities: maintainer class (administrator, defines who may
modify SPSL objects), and a certificate class (fetch, process, etc.)

Network entities: node (points to an interface to which a policy may
be applied), gateway, node-set, gateway-set, policy server (interfaces
of a policy server that manages the policies), and domain.

Two classes of policies: policy class 1 (static filtering rules --
results in permit/deny/forward and has a long and a short form,
policies are ordered), and policy class 2 (IPsec-policy class,
subclasses are IPsec-Action and IKE-Action -- subclasses inherit
attributes from parent policy class).

Recent changes: lists may contain multiple data types, protocol and
port added to forward action, reverse-day-of-month added to
<valid-time> attribute (consistent with Policy WG), security
considerations section discusses tampering protection for SPSL files,
fixed inconsistencies, added more examples and clarifications in the
draft.

Remaining issues: define certificate encodings, work on signatures of
objects (various issues on maintainance/administration/updates there),
definition of SA endpoints, possible support for DNS name in
policies.

3rd presentation
----------------

Matt Blaze (mab@research.att.com) discussed a compliance checking
model for IPSP (draft available as draft-blaze-ipsp-trustmgt-00.txt,
joint work with John Ioannidis and Angelos Keromytis).

Matt started with a question: what is IPsec policy really ?  Answer
(sort of): IPsec policy governs the kind of traffic that is allowed
through IPsec endpoints. That means SA policy, and packet policy.

Packet policy: that's really just traditional packet filtering,
combined with information on what SA was used or should be used
(depending on input/output). The important thing here is to make it
fast, and all IPsec implementations must and do already support this
in various forms.

SA policy is essentially meta filters: they determine whether SAs
should be created, what packet policy should be, etc. SA policy deals
with more complex policies than simple packet filtering, contains
credentials, multiple entities, delegation, digital signatures,
etc. Since SA policy verification occurs less frequently than packet
policy, we can spend more effort in this.

IPSP has to facilitate two things:
 - Negotiation: help hosts discover compatible policies and
   credentials for IPsec SA creation
 - Compliance Checking: allow hosts to enforce their own SA and packet
   filtering policies at SA creation time (insert security here)

There is no standard SA policy mechanism/language.

The two approaches to designing IPSP:
 1) Monolithic: one big protocol. Does everything, guarantees that at
 the end of the protocol "dance" life is good and everyone agrees on
 what to do. Dangerous because this leads to complex protocols,
 dangerous from a security point of view because of it.

 2) Two phase: negotiate, then check. Compliance check what was
    negotiated. This is simpler/safer, as all the security is in the
    compliance checker, which is a better-studied problem than a big
    negotiation protocol.

What might we standardize:
 - A language for expressing packet filters (adaptation might be
   needed on a per implementation/host/OS basis).

 - A language for expressing SA policies (ditto).

 - A language and management scheme for IPsec credentials (which are
   part of the policy), especially important for supporting
   distributed policies.

 - A protocol for negotiating these things, to use as input to local
   compliance checkers.

Matt then discussed a compliance-checking IPsec implementation, which
is distributed with OpenBSD 2.6 (www.openbsd.org), and the same code
works in Linux. This architecture uses KeyNote for compliance
checking, to express policies and credentials.

In this architecture, everyone runs IKE, but might have a local policy
(written in KeyNote). IKE hacked to pass credentials (X.509 /
KeyNote). IKE daemon (isakmpd) rewrites proposed packet filter,
identity of peer, IP addresses, etc as a KeyNote action and queries
the KeyNote compliance checker. If KeyNote says OK, the SAs are
created. Packet processing is left totally unaffected, as all the
policy processing occurs in the IKE level.

Advantages of this architecture:
 - Separate negotiation (complex, untrusted) from compliance checking
   (simple, can be made trustworthy).

 - Can use any compliance-checking language.
   - Different hosts can write their policies in any language they
   want.
   -Some benefit to standardizing the language however.

 - It all works well in practice.
   - Minimal performance impact.
   - No architectural changes to IPsec protocols/implementations.

Advantages of using KeyNote as the language:
 - Fast (by design): at worst, linear in the number of rules
 - Well-understood semantics
 - Natural way to do policy distribution (a signed policy can be
   signed, at which point it automatically becomes a credential that
   can be used by other people who trust the signer)
 - Thus, it is a natural way to do distributed policy.
   - Monotonic
   - Quickly resolves relevant policy statements from multiple sources.
 - But you don't have to use KeyNote if you don't like it.

KeyNote is described in RFC-2704, a web page exists in
    http://www.crypto.com/trustmgt

Important message: keep negotiation and compliance checking separate.

(Answer to question: compliance checking means verifying whether a
proposed action is allowed/consistent with security policy. It may not
be the best term, but figuring out terms in computer science has
become very difficult.)

4th presentation
----------------

John Zao (jzao@bbn.com) was absent, so Hilarie (horman@novell.com)
gave the presentation in his place.

Draft available as draft-zao-policy-semantics-00.txt

The presentation is about a semantic model of IPsec policy
interaction (what does IPsec policy mean, and how policies interact).

Problem statement: two endpoints may have several security gateways
they need to traverse, with independent policy sources. How do they
discover the relevant policies and determine what SAs need to be
established (and with whom) in order to communicate without violating
any of these policies ?

There are 3 ways of solving the policy interaction problem:
resolution, decorrelation, reconciliation.

Policy resolution: in case of conflict, try to resolve by increasing
the security of the communication channel (IPsec transforms). This
implies a way of ordering algorithms/parameters by strength. An
example was given when this may not be desirable (if encryption is not
really considered more powerful than just authentication, but is
orthogonal).

Policy decorrelation: break apart any rules that have overlap, and
introduce extra rules as necessary. This requires access to all
parties' policies. Decorrelation occurs internally in each party's
SPD. The idea is that policies are explicit to the extend where there
can't be any collisions/overlaps.

Policy reconciliation: here, an intermediate gateway adds extra rules
in its SPD.

Proposal: algebraic policy semantics. There is an algebraic model that
allows one to take a direct product of selector sets and produce a
lattice of actions.

The policy is the set of all rules saying that if a particular packet
has attributes that are a member of the cross product, then there is
an action to be taken.

Actions form a partially ordered structure. Based on "natural" order
of action components (crypto algorithms are incompatible, DH group
values are incompatible, key lengths are ordered linearly upward,
expirations are ordered linearly downward), and in composition of
partial orders (disjunctive boolean expressions, tuples with
independently ordered components, tuples with lexicographically
ordered components, etc).

Hilarie then briefly showed the algebraic forms of the three cases
(resolution, decorrelation, reconciliation). The important part here
is that, since this is a decidable algebraic process, it can always be
resolved and done by a computer automatically.

The tough part is the decorrelation of partially ordered policies,
which is shown to be doable.

Question was whether policy decorrelation causes an explosion in the
number of rules. Steve Kent answered that we don't have enough
experience to determine how correlated policies are, which directly
influences how many rules are produced in decorrelating them.

----------------

Angelos Keromytis: there are two architecture documents (requirements
and architecture) which will shortly become official items. WE NEED
FEEDBACK!

Luis Sanchez: ditto. We need to put together a roadmap document
(Hilarie's task), then update the drafts and move forward.

Comment: we have to update the milestones in the charter.



From owner-ipsec-policy  Mon Mar 27 17:49:18 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id RAA20555
	for ipsec-policy-bks; Mon, 27 Mar 2000 17:49:18 -0800 (PST)
Received: from mx.crypto.com ([207.140.168.138])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA20551
	for <ipsec-policy@vpnc.org>; Mon, 27 Mar 2000 17:49:17 -0800 (PST)
Received: from fbi.crypto.com (localhost [127.0.0.1])
	by mx.crypto.com (8.9.3/8.9.3) with ESMTP id UAA14656
	for <ipsec-policy@vpnc.org>; Mon, 27 Mar 2000 20:51:35 -0500 (EST)
Received: from fbi.crypto.com (mab@localhost)
	by fbi.crypto.com (8.9.3/8.9.3) with ESMTP id UAA03253
	for <ipsec-policy@vpnc.org>; Mon, 27 Mar 2000 20:53:00 -0500
Message-Id: <200003280153.UAA03253@fbi.crypto.com>
X-Authentication-Warning: fbi.crypto.com: mab owned process doing -bs
X-Mailer: exmh version 2.1.1 10/15/1999
To: ipsec-policy@vpnc.org
Subject: slides from my presentation
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 27 Mar 2000 20:53:00 -0500
From: Matt Blaze <mab@research.att.com>
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

I've made available the slides from my presentation at IPSP in Adelaide.

For good, old fashioned, as-god-intended-these-things-to-be PostScript:
	http://www.crypto.com/talks/mab-ipsp-ietf47/mab-ipsp-ietf47.ps

For evil, new-fangled, sure-sign-of-the-apocalypse Powerpoint-generated
HTML:
	http://www.crypto.com/talks/mab-ipsp-ietf47/index.html

-matt



From owner-ipsec-policy  Wed Mar 29 00:27:42 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id AAA11821
	for ipsec-policy-bks; Wed, 29 Mar 2000 00:27:42 -0800 (PST)
Received: from athena.polito.it. (giunone.polito.it [130.192.3.45])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA11750
	for <ipsec-policy@vpnc.org>; Wed, 29 Mar 2000 00:26:53 -0800 (PST)
Received: (from baltatu@localhost)
	by athena.polito.it. (8.9.3/8.9.3) id KAA28366;
	Wed, 29 Mar 2000 10:30:11 +0200 (MET DST)
From: Madalina Baltatu <baltatu@athena.polito.it>
Message-Id: <200003290830.KAA28366@athena.polito.it.>
X-Mailer: exmh version 1.6.2 7/18/95
To: mcondell@bbn.com
cc: ipsec-policy@vpnc.org
Subject: Master File and SPS Database
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 29 Mar 2000 10:30:11 +0200
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Hello.

I would have a coupple of questions about the roles  the Master Files and SPS 
Databases are supposed to play in SPS.  
It seems to me that during normal operation, policy servers use only the 
information which is inside the SPS database (local or cache) to reply to 
policy queries. The Master File does not seem to be accessed. It is used only 
for the initial configuration of the policy servers. When a server starts, it 
has to load the Master File info into the database. Is right till now?

When an administrator entity changes the Master File (or only a part of it), 
what is the procedure to update the server database? (is that left to the 
implementors choice?)

If a server receives an SPP-POL message from one of the nodes inside its 
authoritative area, where does this policy go? I suppose only in the database 
(the cache part -- page 36 of the SPP draft)... Isn't it necessary to up-date 
the Master File to reflect this change? 

The policy server is supposed to be the only one which has write/modify access 
to the SPS database, isn't it? (if not -- I mean if some administrator entity  
can change the database -- I do not see what the Master File serves for).

Thank you in advance.
Best Regards,
Madalina.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Madalina Baltatu, Ph.D. Student 			
Politecnico di Torino, DAUIN    
corso Duca degli Abruzzi 24     
10129 Torino (TO), Italy        
phone: +390115647084            
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


From owner-ipsec-policy  Wed Mar 29 05:57:42 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id FAA28208
	for ipsec-policy-bks; Wed, 29 Mar 2000 05:57:42 -0800 (PST)
Received: from squatch.ir.bbn.com (squatch.ir.bbn.com [192.1.98.166])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA28204
	for <ipsec-policy@vpnc.org>; Wed, 29 Mar 2000 05:57:41 -0800 (PST)
Received: (qmail 67676 invoked by uid 20813); 29 Mar 2000 13:59:58 -0000
Date: 29 Mar 2000 13:59:58 -0000
Message-ID: <20000329135958.67675.qmail@squatch.ir.bbn.com>
From: Matthew Condell <mcondell@bbn.com>
To: Madalina Baltatu <baltatu@athena.polito.it>
cc: ipsec-policy@vpnc.org
Subject: Re: Master File and SPS Database
Reply-to: mcondell@bbn.com
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

>I would have a coupple of questions about the roles  the Master Files and SPS 
>Databases are supposed to play in SPS.  

In general your understanding of the Master File and the SPS Database
is right.  

The Master File is the enforcement point's policy, established by the
system's administrator.  It does not change unless updated by the
administrator.  It loaded into the SPS databases when the host starts
up and is reloaded when it is modified.  The host can not violate the
policy set forth in the Master File.

The SPS Databases are bootstrapped by the Master File and some of them
change during the process of SPP negotiations.  However, despite changing,
they are guaranteed never to violate the policies from the Master File.

>It seems to me that during normal operation, policy servers use only the 
>information which is inside the SPS database (local or cache) to reply to 
>policy queries. The Master File does not seem to be accessed. It is used only 
>for the initial configuration of the policy servers. When a server starts, it 
>has to load the Master File info into the database. Is right till now?

Correct.

>When an administrator entity changes the Master File (or only a part of it), 
>what is the procedure to update the server database? (is that left to the 
>implementors choice?)

The SPS Databases need to be cleared and the new Master File loaded.
This is necessary to guarantee that no policies in the SPS Databases
violate the Master File.  It incurs a performance hit, since cached 
policies are lost, but correctness is more important.

>If a server receives an SPP-POL message from one of the nodes inside its 
>authoritative area, where does this policy go? I suppose only in the database 
>(the cache part -- page 36 of the SPP draft)... Isn't it necessary to up-date 
>the Master File to reflect this change? 

The policy goes only into the cache.  SPP negotiations are not allowed
to change the enforcement point's base policy.  It may only cache
information received from the policy resolution.

It is important to understand that SPP policy resolution does not change
an enforcement point's policy.  I just finds common ground between the
EP's policy and the other relevent EPs policies (if common ground exists),
so each EP can protect a communication in a way that is acceptable to
the other EPs involved.  This information is temporarily cached, since it
may change over time.

>The policy server is supposed to be the only one which has
>write/modify access to the SPS database, isn't it? (if not -- I mean
>if some administrator entity can change the database -- I do not see
>what the Master File serves for).

Yes.  The administrator changes the database by modifying the Master
File.  That is the only way to change an enforcement point's policy.
(How the Master File is created, modified, and distributed to EPs is 
out of the scope of SPS)

Hope this clears things up.

Matt Condell
BBN Technologies

From owner-ipsec-policy  Sat Apr  8 09:40:38 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA19845
	for ipsec-policy-bks; Sat, 8 Apr 2000 09:40:38 -0700 (PDT)
Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19839
	for <ipsec-policy@vpnc.org>; Sat, 8 Apr 2000 09:40:36 -0700 (PDT)
Received: from zopps.fi (ws4.piuha.net [195.165.196.4])
	by ws2.piuha.net (Postfix) with ESMTP id 3B0FE7634C
	for <ipsec-policy@vpnc.org>; Sat,  8 Apr 2000 19:43:47 +0300 (EEST)
Message-ID: <38EF5249.F66264F4@zopps.fi>
Date: Sat, 08 Apr 2000 18:37:45 +0300
From: Jari Arkko <jari.arkko@piuha.net>
Reply-To: jarkko@zopps.fi
Organization: None
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: ipsec-policy@vpnc.org
Subject: SPSL questions
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Hi. I've been reading the SPSL draft (draft-ietf-ipsp-spsl-00.txt) and I have a
couple of questions:

1. Several attributes specify "list of <x>" and at the same time indicate the
   attribute is "m-v". Is the meaning that there'd be one attribute for each object
   with a list as a value? Or that there'd be several attributes each with a single
   value? Or that the attribute can appear several times, each time containing a list?  
   What is the semantic difference of these, if any?  Example:

	domain: foobar
	...
	mnt-by:	adm1, adm2
   versus
	domain: foobar
	...
	mnt-by: adm1
	mnt-by: adm2
   versus
	domain: foobar
	...
	mnt-by: adm1, adm2
	mnt-by: adm3, adm4

2. I may have missed the text about ordering of policy rule matching, and the
handling of possibly overlapping rules. Are these allowed or not, and if they
are, how are they handled?

3. SPSL has complex mechanisms for ensuring that each object hasn't been forged.
However, the draft notes in section 6.3 that there are attacks where this doesn't
help. This kind of reminds me of the secure DNS situation, where it is not only
necessary to prove that a particular record is a correct one, but also prove that
between two names A and B there are no other names. Here we need to know that 
we've received the whole policy and that an attacker has not e.g. deleted a
deny rule. So my question is: why bother with object-level security at all if
we need file-level security also? In secure DNS, we can't rely on getting
the whole zone file due to obvious scalability problems. But in the case of SPSL,
don't we load the policy from a server at the beginning of time, not piece-by-piece
as in DNS?

4. Related to the above question: in the case of multiple sources of policy
information, how can we ensure that the PEPs have got all of the policy? Is
it even possible to have multiple sources of policy information for one network?

Jari Arkko
- Jari.Arkko@ericsson.com
- jarkko@piuha.net

From owner-ipsec-policy  Tue Apr 11 16:51:30 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id QAA29012
	for ipsec-policy-bks; Tue, 11 Apr 2000 16:51:30 -0700 (PDT)
Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA29008
	for <ipsec-policy@vpnc.org>; Tue, 11 Apr 2000 16:51:28 -0700 (PDT)
Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1])
	by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA21565
	for <ipsec-policy@vpnc.org>; Tue, 11 Apr 2000 19:55:03 -0400 (EDT)
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id TAA21547
	for <ipsec-policy@vpnc.org>; Tue, 11 Apr 2000 19:55:02 -0400 (EDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2448.0)
	id <2P0YKRHX>; Wed, 12 Apr 2000 01:55:01 +0200
Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB06BF7ED3@nl0006exch002u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: ipsec-policy@vpnc.org
Subject: Policy Terminology
Date: Wed, 12 Apr 2000 01:54:57 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

> The Policy Terminology work has now become a part of the Policy Framework
> WG.
> I recommend that members of this IIIPSP WG keep an eye on what happens
> there,
> because in the end, we (IESG) do require a consisten use of terms when
> talking
> about Policy Based Management.
> 
> Bert (co-AD for Operations and Management Area)
> 
> 

From owner-ipsec-policy  Fri Apr 14 09:03:15 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA00573
	for ipsec-policy-bks; Fri, 14 Apr 2000 09:03:15 -0700 (PDT)
Received: from squatch.ir.bbn.com (squatch.ir.bbn.com [192.1.98.166])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA00569
	for <ipsec-policy@vpnc.org>; Fri, 14 Apr 2000 09:03:13 -0700 (PDT)
Received: (qmail 51629 invoked by uid 20813); 14 Apr 2000 16:06:41 -0000
Date: 14 Apr 2000 16:06:41 -0000
Message-ID: <20000414160641.51628.qmail@squatch.ir.bbn.com>
From: Matthew Condell <mcondell@bbn.com>
To: ipsec-policy@vpnc.org
Subject: Re: SPSL questions
Reply-to: mcondell@bbn.com
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Jari Arkko wrote:
>1. Several attributes specify "list of <x>" and at the same time
>   indicate the attribute is "m-v". Is the meaning that there'd be one
>   attribute for each object with a list as a value? Or that there'd
>   be several attributes each with a single value? Or that the
>   attribute can appear several times, each time containing a list?
>   What is the semantic difference of these, if any?  Example:

It means that the attribute can appear multiple times, each containing
a list (see section 1.2.2).  Since most of the attributes (except
policy, for example) are ORed together (section 5.1), they are
semantically the same.  The flexibility was designed to make the files
easier to edit by hand.

>2. I may have missed the text about ordering of policy rule matching, and the
>handling of possibly overlapping rules. Are these allowed or not, and if they
>are, how are they handled?

Section 5.5 addresses this.

>3. SPSL has complex mechanisms for ensuring that each object hasn't
>been forged.  However, the draft notes in section 6.3 that there are
>attacks where this doesn't help. This kind of reminds me of the secure
>DNS situation, where it is not only necessary to prove that a
>particular record is a correct one, but also prove that between two
>names A and B there are no other names. Here we need to know that
>we've received the whole policy and that an attacker has not
>e.g. deleted a deny rule. So my question is: why bother with
>object-level security at all if we need file-level security also? In
>secure DNS, we can't rely on getting the whole zone file due to
>obvious scalability problems. But in the case of SPSL, don't we load
>the policy from a server at the beginning of time, not piece-by-piece
>as in DNS?

The process of securing the file and objects is still evolving.  
I think that you are right, that if the entire file is signed then
signing each object is not necessary.  However, there may be some
benefits to signing each individual object.  For example, it can provide 
verification of which maintainer last modified an object.  

>4. Related to the above question: in the case of multiple sources of
>policy information, how can we ensure that the PEPs have got all of
>the policy? Is it even possible to have multiple sources of policy
>information for one network?

We hadn't envisioned there being multiple sources of policy
information for a particular PEP.  My initial thought, though, is if
there is multiple sources of information, it is beyond the scope of
the policy language to provide assurances that a PEP has got all of
its policy.

Matthew Condell
BBN Technologies

From owner-ipsec-policy  Wed May  3 23:31:45 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id XAA19619
	for ipsec-policy-bks; Wed, 3 May 2000 23:31:45 -0700 (PDT)
Received: from mail.inter.net.il (parker.inter.net.il [192.116.202.33])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA19608
	for <ipsec-policy@vpnc.org>; Wed, 3 May 2000 23:31:41 -0700 (PDT)
Received: from radguard.com (radguard.com [192.114.169.3])
	by mail.inter.net.il (8.9.3/8.9.3) with SMTP id JAA20001
	for <ipsec-policy@vpnc.org>; Thu, 4 May 2000 09:36:16 +0300 (IDT)
Received: by radguard.com   (4.1/SMI-4.1)
	id AA21054; Thu, 4 May 00 09:38:55 IDT
Received: from UNKNOWN(192.114.33.100), claiming to be "hellman.radguard.com"
 via SMTP by radguard.com, id smtpdAAAa21051; Thu May  4 09:38:46 2000
Received: from radguard.com by hellman.radguard.com (8.8.8+Sun/SMI-SVR4)
	id IAA20157; Thu, 4 May 2000 08:38:56 +0200 (IST)
Message-Id: <391128B3.5CBC87CC@radguard.com>
Date: Thu, 04 May 2000 09:37:23 +0200
From: Yaron Sheffer <yaron.sheffer@radguard.com>
Organization: RADGUARD
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
Mime-Version: 1.0
To: IPSP List <ipsec-policy@vpnc.org>
Subject: Some comments on SPSL
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Hi,

below are some high-level comments to the SPSL draft. I am sparing the
group a long list of comments regarding the nuts and bolts of the
language, which I sent to the authors.

Your replies and counter-comments are most welcome.

- A specialized language is less flexible than UML for describing
information. UML can derive various implementation-specific schema for
the same basic information, which is more difficult when starting from a
language. Also, SPSL is semantically constrained in its lack of direct
support for inheritance.
- The language is lacking the essential distinction of lexical vs
syntactic levels (LEX vs YACC). This is apparent in several places, e.g.
where numbers are implicitly assumed to be decimal or hex.
- It is not clear why protection of the data objects should be part of
the language. I believe it is best left out, and standard (CMS?) object
wrapping techniques be used instead, at the implementor's discretion.
- The information model assumes that only fixed "nodes" (DNS names) are
protected. But it should allow for user identification by NAI (Email
address) or Distinguished Name. IKE is very flexible in identifying
endpoints and this should be reflected in SPSL.
- In several places inheritance can be used for simplicity. For example,
a policy server is a node, so its type definition could be derived from
that of a node. Given that the language does not support inheritance, a
"policy server" object could contain an sub-object that is a node.

Thanks,
    Yaron



From owner-ipsec-policy  Tue May  9 06:29:51 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id GAA18573
	for ipsec-policy-bks; Tue, 9 May 2000 06:29:51 -0700 (PDT)
Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA18569
	for <ipsec-policy@vpnc.org>; Tue, 9 May 2000 06:29:50 -0700 (PDT)
Received: by sentry.gw.tislabs.com; id JAA10723; Tue, 9 May 2000 09:37:34 -0400 (EDT)
Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5)
	id xma010716; Tue, 9 May 00 09:37:21 -0400
Received: (from balenson@localhost)
	by clipper.gw.tislabs.com (8.9.3/8.9.1) id JAA18608
	for ipsec-policy@vpnc.org; Tue, 9 May 2000 09:30:37 -0400 (EDT)
Date: Tue, 9 May 2000 09:30:37 -0400 (EDT)
From: "David M. Balenson" <balenson@tislabs.com>
Message-Id: <200005091330.JAA18608@clipper.gw.tislabs.com>
To: ipsec-policy@vpnc.org
Subject: CFP: ISOC Netw & Distr Sys Security Symp (NDSS'01)
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

            C  A  L  L       F  O  R       P  A  P  E  R  S


                          The Internet Society
         2001 Network and Distributed System Security Symposium
                               (NDSS'01)

                           February 7-9, 2001

                Catamaran Resort, San Diego, California


                            IMPORTANT DATES
          Paper Submission due:           August 2, 2000
          Author Notification:            September 27, 2000
          Camera-ready final papers due:  October 31, 2000


GOAL: 
  This symposium will foster information exchange among researchers 
  and practioners of network and distributed system security 
  services.  The intended audience includes those who are interested 
  in the practical aspects of network and distributed system security,
  focusing on actual system design and implementation, rather than
  theory.  A major goal of the symposium is to encourage and enable 
  the Internet community to apply, deploy, and advance the state of
  available security technology.  The proceedings of the symposium 
  will be published by the Internet Society.

Submissions are solicited for, but are not limited to, the following
topics:
 * Secure Electronic Commerce: e.g., payment, barter, EDI,
   notarization/timestamping, endorsement and licensing.
 * Intellectual Property Protection: protocols, schemas,
   implementations, metering, watermarking, other forms of rights
   management.
 * Implementation, deployment and management of network security
   policies.
 * Integrating Security in Internet protocols: routing, naming,
   TCP/IP, multicast, network management, and the Web.
 * Attack-resistant protocols and services.
 * Special problems and case studies: e.g., interplay and tradeoffs
   between security and efficiency, usability, reliability and cost.
 * Security for collaborative applications and services: tele- and
   video-conferencing, groupwork, etc.
 * Fundamental services: authentication, data integrity,
   confidentiality, authorization, non-repudiation, and availability.
 * Supporting mechanisms and APIs: key management and certification,
   revocation, audit trails and accountability.
 * Public Key Infrastructure.
 * Integrating security services with system and application security
   facilities and protocols: e.g., message handling, file
   transport/access, directories, time synchronization, database
   management, boot services, mobile computing.
 * Security for emerging technologies: sensor networks, specialized
   testbeds, wireless/mobile (and ad hoc) networks, personal
   communication systems, and large heterogeneous distributed systems.
 * Intrusion Avoidance, Detection, and Response: systems, experiences
   and architectures.
 * Network Perimeter Controls: firewalls, packet filters, application
   gateways.
 * Virtual Private Networks.


BEST PAPER AWARD:
  There will be a best paper award again this year. The award will
  be presented at the symposium to the authors of the best overall
  paper as selected by the Program Committee.


SUBMISSIONS:
  The Program Committee invites both technical papers and panel
  proposals. Technical papers should be at most 20 pages long. Panel
  proposals should be at most two pages and should describe the
  topic, identify the panel chair, explain the format of the panel,
  and list three to four potential panelists. Technical papers will
  appear in the proceedings. A description of each panel will appear
  in the proceedings, and may - at the discretion of the panel chair
  - include written position statements from the panelists.

  Each submission must contain a separate title page with the type
  of submission (paper or panel), the title or topic, the names of
  the author(s), organizational affiliation(s), telephone and FAX
  numbers, postal addresses, e-mail addresses, and must specify the
  contact author in case of multi-author submissions. The names of
  authors, affiliations, and other identifying information should
  appear only on the separate title page. Submissions must be
  received by August 2, 2000, and must be made via electronically
  in either PostScript or ASCII format. If the Committee is unable
  to print a PostScript submission, a hardcopy will be requested.
  Therefore, PostScript submissions must arrive well before the
  deadline.

  Submission information can be found at
  http://www.isoc.org/ndss01/cfp. Dates, final call for papers,
  advance program, and registration information will be available
  soon at http://www.isoc.org/ndss01.

  Each submission will be acknowledged by e-mail. If acknowledgment
  is not received within seven days, please contact the program
  Co-chairs as indicated below. Authors and panelists will be
  notified of acceptance by September 27, 2000. Instructions for
  preparing camera-ready copy for the proceedings will be sent at
  that time. The camera-ready copy must be received by October 31,
  2000.


GENERAL CHAIR: 
  Stephen Welke, Trusted Computer Solutions

PROGRAM CO-CHAIRS:
  Avi Rubin, AT&T Labs - Research
  Paul Van Oorschot, Entrust Technologies

TUTORIAL CHAIR:
  Eric Harder, National Security Agency

LOCAL ARRANGEMENTS CHAIR:
  Thomas Hutton, San Diego Supercomputer Center

PUBLICATIONS CHAIR:
  Mahesh Tripunitara, Purdue University

PUBLICITY CHAIR:
  David Balenson, NAI Labs, Network Associates

LOGISTICS CHAIR:
  Carla Rosenfeld, Internet Society

PROGRAM COMMITTEE:
  Bennet Yee, University of California San Diego
  Bill Cheswick, Bell Labs
  Dave Kormann, AT&T Labs - Research
  David Aucksmith, Intel Corportation
  David P. Maher, Intertrust
  David Wagner, UC Berkeley
  Edward W. Felten, Princeton University
  Fabian Monrose, Bell Labs
  Gary McGraw, Reliable Software Technologies
  James Ellis, Sun Microsystems
  Kevin McCurley, IBM Almaden Research Center
  Matt Bishop, UC Davis
  Mudge, L0pht Heavy Industries, Inc.
  Peter Gutmann, University of Auckland, New Zealand
  Radia Perlman, Sun Microsystems
  Sandra Murphy, Network Associates
  Tom Berson, Anagram Laboratories
  Virgil D. Gligor, University of Maryland


From owner-ipsec-policy  Tue May  9 10:05:26 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA22606
	for ipsec-policy-bks; Tue, 9 May 2000 10:05:26 -0700 (PDT)
Received: from scooby.lineone.net ([194.75.152.224])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22596;
	Tue, 9 May 2000 10:05:23 -0700 (PDT)
Received: from ukd ([195.171.177.9])
	by scooby.lineone.net (8.9.3/8.9.3) with SMTP id QAA06295;
	Tue, 9 May 2000 16:50:29 +0100 (BST)
Message-ID: <014f01bfb9cf$8fae5900$09b1abc3@ukd>
From: "Formacompany" <formations@ukdata.com>
To: "Finance Director" <webmaster@ukdata.com>
Subject: Instant on-line credit reports
Date: Tue, 9 May 2000 16:56:47 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Do you need fast accurate information to assist you when appraising
potential customers, and suppliers?

The UK Data internet website www.ukdata.com contains 28 million pages of
data with full information on every UK company!

Credit Reports-Director Searches-Accounts-Annual Returns

All of these products and many more are available to you immediately, and
can be downloaded to and printed from your personal computer.

Free samples of all reports are available at www.ukdata.com.

Please also visit www.formacompany.co.uk the on-line company formation
website

Thank You

Charles Fletcher
www.ukdata.com an instant report on every UK business
www.formacompany.co.uk the on-line company formation site
www.irishdata.ie - instant reports on all Irish companies














From owner-ipsec-policy  Tue May  9 13:10:24 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id NAA26958
	for ipsec-policy-bks; Tue, 9 May 2000 13:10:24 -0700 (PDT)
Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA26953
	for <ipsec-policy@vpnc.org>; Tue, 9 May 2000 13:10:22 -0700 (PDT)
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by ertpg14e1.nortelnetworks.com; Tue, 9 May 2000 16:15:36 -0400
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id KTCJPJ72; Tue, 9 May 2000 16:14:46 -0400
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) 
          by zcard00f.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id KL5GATLR; Tue, 9 May 2000 16:14:47 -0400
Message-ID: <3918723A.24757F39@americasm01.nt.com>
Date: Tue, 09 May 2000 16:16:58 -0400
From: "Abdallah Rayhan" <arayhan@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: IPSP List <ipsec-policy@vpnc.org>
Subject: domain-set class
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

SPSL defines domain class but not domain-set class?
I wonder why is that!  A corp might want to define a set
of domains where each domain is controlled by a polserv.
A domain policy could be similar to other domains or
narrowed down to more restrictive policies to secure
certain resources. You end up with a corp domain-set
which includes a number of domains each of which
as its own policy set.

Also, while the policy class provides an extended list
of selectors, it does not have content inspection attributes
or things like URL filtering and auditing. Policy does not
stop at packet filtering actions but should be sophisticated
enough to describe the behaviors of best of breed firewalls.
Otherwise, SG vendors would find not much value in supporting
a policy language failing to capture the sophisticated
operations firewalls provide now.


Abdallah Rayhan


From owner-ipsec-policy  Tue May  9 14:34:18 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA28088
	for ipsec-policy-bks; Tue, 9 May 2000 14:34:18 -0700 (PDT)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA28084
	for <ipsec-policy@vpnc.org>; Tue, 9 May 2000 14:34:17 -0700 (PDT)
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by smtprch1.nortel.com; Tue, 9 May 2000 16:38:34 -0500
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id KTCJPV0D; Tue, 9 May 2000 17:38:28 -0400
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) 
          by zcard00f.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id KL5GATTR; Tue, 9 May 2000 17:38:30 -0400
Message-ID: <391885D9.B9B4E23@americasm01.nt.com>
Date: Tue, 09 May 2000 17:40:42 -0400
From: "Abdallah Rayhan" <arayhan@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: IPSP List <ipsec-policy@vpnc.org>
Subject: policy format
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

SPSL states that the policy can be defined in three formats, e.g.,
short, long, and combined. I believe this is redundancy and
source of confusion. Policy should have one format which
is general enough to include the properties of the other ones.
If optimization is a concern then the optimized version can
be obtained when policy is sent on the wire.

Abdallah Rayhan




From owner-ipsec-policy  Wed May 10 05:19:47 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id FAA25290
	for ipsec-policy-bks; Wed, 10 May 2000 05:19:47 -0700 (PDT)
Received: from squatch.ir.bbn.com (squatch.ir.bbn.com [192.1.98.166])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA25285
	for <ipsec-policy@vpnc.org>; Wed, 10 May 2000 05:19:45 -0700 (PDT)
Received: (qmail 10727 invoked by uid 20813); 10 May 2000 12:25:29 -0000
Date: 10 May 2000 12:25:29 -0000
Message-ID: <20000510122529.10726.qmail@squatch.ir.bbn.com>
From: Matthew Condell <mcondell@bbn.com>
To: ipsec-policy@vpnc.org
Subject: Re: policy format
Reply-to: mcondell@bbn.com
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Essentially, there is only one format for policy -- the combined
format.  The document describes it as three logical formats as
an attempt to make it easier to describe the parts of the policy
object.  If this is being found confusing, we can attempt to
either describe the object only as one form or be more
explicit that the three forms are artificial divisions of the 
object.

>SPSL states that the policy can be defined in three formats, e.g.,
>short, long, and combined. I believe this is redundancy and
>source of confusion. Policy should have one format which
>is general enough to include the properties of the other ones.
>If optimization is a concern then the optimized version can
>be obtained when policy is sent on the wire.

Matt Condell
BBN Technologies

From owner-ipsec-policy  Wed May 10 05:47:05 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id FAA25596
	for ipsec-policy-bks; Wed, 10 May 2000 05:47:05 -0700 (PDT)
Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA25592
	for <ipsec-policy@vpnc.org>; Wed, 10 May 2000 05:47:04 -0700 (PDT)
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by ertpg14e1.nortelnetworks.com; Wed, 10 May 2000 08:52:47 -0400
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id K4CS6YZ0; Wed, 10 May 2000 08:52:47 -0400
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) 
          by zcard00f.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id KL5GA4CM; Wed, 10 May 2000 08:52:47 -0400
Message-ID: <39195C23.63946C36@americasm01.nt.com>
Date: Wed, 10 May 2000 08:54:59 -0400
From: "Abdallah Rayhan" <arayhan@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: mcondell@bbn.com
CC: ipsec-policy@vpnc.org
Subject: Re: policy format
References: <20000510122529.10726.qmail@squatch.ir.bbn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

One can argue for one form or another. However to reduce
complexity and less confusion, one form should be enough
as long as it can express all the requirements. Three forms
does not bring anything new.

Abdallah Rayhan

Matthew Condell wrote:

> Essentially, there is only one format for policy -- the combined
> format.  The document describes it as three logical formats as
> an attempt to make it easier to describe the parts of the policy
> object.  If this is being found confusing, we can attempt to
> either describe the object only as one form or be more
> explicit that the three forms are artificial divisions of the
> object.
>
> >SPSL states that the policy can be defined in three formats, e.g.,
> >short, long, and combined. I believe this is redundancy and
> >source of confusion. Policy should have one format which
> >is general enough to include the properties of the other ones.
> >If optimization is a concern then the optimized version can
> >be obtained when policy is sent on the wire.
>
> Matt Condell
> BBN Technologies


From owner-ipsec-policy  Wed May 10 06:26:46 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id GAA26245
	for ipsec-policy-bks; Wed, 10 May 2000 06:26:46 -0700 (PDT)
Received: from squatch.ir.bbn.com (squatch.ir.bbn.com [192.1.98.166])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id GAA26241
	for <ipsec-policy@vpnc.org>; Wed, 10 May 2000 06:26:45 -0700 (PDT)
Received: (qmail 11111 invoked by uid 20813); 10 May 2000 13:32:42 -0000
Date: 10 May 2000 13:32:42 -0000
Message-ID: <20000510133242.11110.qmail@squatch.ir.bbn.com>
From: Matthew Condell <mcondell@bbn.com>
To: ipsec-policy@vpnc.org
Subject: Re: domain-set class
Reply-to: mcondell@bbn.com
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

>SPSL defines domain class but not domain-set class?
>I wonder why is that!  A corp might want to define a set
>of domains where each domain is controlled by a polserv.
>A domain policy could be similar to other domains or
>narrowed down to more restrictive policies to secure
>certain resources. You end up with a corp domain-set
>which includes a number of domains each of which
>as its own policy set.

It is currently this way because we had envisioned that,
at most, an SPSL file would contain information for a 
single domain, not information for multiple domains.
However, the scenario you describe can easily be handled
with the current specification.

There are at least two possibilities with the overarching corporate
domain policy in your scenario.  There could be a parent domain
physically exists with its own enforcement points and policy servers
which enforces a corporate-wide policy over the other domain. In this
case, a domain object is created with the domain's policy servers and
enforcement points.

The second possibility is that there is only logically a parent domain
and each sub-domain is responsible for enforcing the parent domain's
policies.  In this case, a domain object can be created which includes
each of the sub-domains policy servers and enforcement points in its
definition.  Or each sub-domain may be trusted to have a copy of the
policy which it directly enforces.

I would argue that a domain-set object is not needed, though I
probably can be convinced that it may be useful.

>Also, while the policy class provides an extended list
>of selectors, it does not have content inspection attributes
>or things like URL filtering and auditing. Policy does not
>stop at packet filtering actions but should be sophisticated
>enough to describe the behaviors of best of breed firewalls.
>Otherwise, SG vendors would find not much value in supporting
>a policy language failing to capture the sophisticated
>operations firewalls provide now.

The current purpose of SPSL is to specify policy for IPsec.
Where it was easy to specify a list of selectors to filter
that extend beyond IPsec, we did.  Our goal was not to 
provide an exhaustive list of check that a SG may want to 
check for beyond IPsec.  It should be possible to add that
kind of information to the language by "subclassing" the
policy class, though I don't think it should added to
this draft.  

Matt Condell
BBN Technologies

From owner-ipsec-policy  Wed May 10 06:43:27 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id GAA26568
	for ipsec-policy-bks; Wed, 10 May 2000 06:43:27 -0700 (PDT)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26564
	for <ipsec-policy@vpnc.org>; Wed, 10 May 2000 06:43:26 -0700 (PDT)
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by smtprch1.nortel.com; Wed, 10 May 2000 08:48:46 -0500
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id K4CS7A95; Wed, 10 May 2000 09:48:41 -0400
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) 
          by zcard00f.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id KL5GA4L0; Wed, 10 May 2000 09:48:42 -0400
Message-ID: <3919693D.DE8706F9@americasm01.nt.com>
Date: Wed, 10 May 2000 09:50:53 -0400
From: "Abdallah Rayhan" <arayhan@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Yaron Sheffer <yaron.sheffer@radguard.com>
CC: IPSP List <ipsec-policy@vpnc.org>
Subject: Re: Some comments on SPSL
References: <391128B3.5CBC87CC@radguard.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

See comments below!

Abdallah Rayhan

Yaron Sheffer wrote:

> Hi,
>
> below are some high-level comments to the SPSL draft. I am sparing the
> group a long list of comments regarding the nuts and bolts of the
> language, which I sent to the authors.
>
> Your replies and counter-comments are most welcome.
>
> - A specialized language is less flexible than UML for describing
> information. UML can derive various implementation-specific schema for
> the same basic information, which is more difficult when starting from a
> language. Also, SPSL is semantically constrained in its lack of direct
> support for inheritance.

I think SPSL is more like a template language than a programming
language. Having said that, inheritance in the general sense
could lead to complex semantical conflicts that would be difficult
to resolve. The protocols that use SPSL are signaling protocols
in nature, we still dont know much about them!!! Hence, the policy
engine need to deduce policy in realtime.


> - The language is lacking the essential distinction of lexical vs
> syntactic levels (LEX vs YACC). This is apparent in several places, e.g.
> where numbers are implicitly assumed to be decimal or hex.

SPSL could use some improvement here.

> - It is not clear why protection of the data objects should be part of
> the language. I believe it is best left out, and standard (CMS?) object
> wrapping techniques be used instead, at the implementor's discretion.

Right now, it is mandatory to protect the objects. However, if you store
the objects in a directory then the directory can do that for you. A
reasonable
approach would be to say that it is recommended but not mandatory.
The protocols that use the policy should have enough security constructs
to ensure the integrity of the data being exchanged between the policy
server
and the security gateway.

> - The information model assumes that only fixed "nodes" (DNS names) are
> protected. But it should allow for user identification by NAI (Email
> address) or Distinguished Name. IKE is very flexible in identifying
> endpoints and this should be reflected in SPSL.

SPSL is about PEP which basically are network entities and not users.
If the objective of SPSL is to become a general policy language (GPL),
then I would agree with you. Otherwise, it ought to be device oriented.
It would be interesting to have SPSL as a subset of a GPL if there is
a GPL standard!

> - In several places inheritance can be used for simplicity. For example,
> a policy server is a node, so its type definition could be derived from
> that of a node. Given that the language does not support inheritance, a
> "policy server" object could contain an sub-object that is a node.

See comment above.



From owner-ipsec-policy  Wed May 10 08:12:28 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA28239
	for ipsec-policy-bks; Wed, 10 May 2000 08:12:28 -0700 (PDT)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28232
	for <ipsec-policy@vpnc.org>; Wed, 10 May 2000 08:12:27 -0700 (PDT)
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by smtprch1.nortel.com; Wed, 10 May 2000 10:17:36 -0500
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id K4DZ4BWZ; Wed, 10 May 2000 11:17:27 -0400
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) 
          by zcard00f.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id KL5GA47C; Wed, 10 May 2000 11:17:31 -0400
Message-ID: <39197E0F.DC40DC6B@americasm01.nt.com>
Date: Wed, 10 May 2000 11:19:43 -0400
From: "Abdallah Rayhan" <arayhan@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: IPSP List <ipsec-policy@vpnc.org>
Subject: packet description language
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

In Section 7. Remaining Issues, there is a mention of "packet
description language and selectors that use the language" !

Can anyone elaborate on this more ?

Abdallah Rayhan





From owner-ipsec-policy  Wed May 10 08:50:20 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA29587
	for ipsec-policy-bks; Wed, 10 May 2000 08:50:20 -0700 (PDT)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA29583
	for <ipsec-policy@vpnc.org>; Wed, 10 May 2000 08:50:18 -0700 (PDT)
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by smtprch1.nortel.com; Wed, 10 May 2000 10:55:53 -0500
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id KVDMB3J0; Wed, 10 May 2000 11:55:49 -0400
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) 
          by zcard00f.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id KL5GAVAQ; Wed, 10 May 2000 11:55:50 -0400
Message-ID: <39198709.3CF91687@americasm01.nt.com>
Date: Wed, 10 May 2000 11:58:01 -0400
From: "Abdallah Rayhan" <arayhan@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: IPSP List <ipsec-policy@vpnc.org>
Subject: "policy" attribute
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

The definition of the policy attribute in the policy class is
quite redundant especially when it comes to long and
combined formats. This is true for actions and the various
selectors. For example, actions can be defined independently
or part of the policy attribute. I understand the need for
flexibility however probably there is a better way of doing
this. For example, the values in most classes are primitive
objects. So every time you need to say the same thing
you need to write the whole value. However, if values can
be structured objects themselves, then you can define
a limited number of actions (focusing on actions instead
of being lost in semantics of every action in every policy
object) and  enforce whatever applies to a particular policy
object.  Similar thing goes for selectors and policy. This
concept  should make SPSL more extensible than what it
is right now.  The basic classes would be generic enough
to support  any kind of policy and not limited to IPSec when
extended.

Abdallah Rayhan




From owner-ipsec-policy  Wed May 10 10:57:02 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA11207
	for ipsec-policy-bks; Wed, 10 May 2000 10:57:02 -0700 (PDT)
Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA11203
	for <ipsec-policy@vpnc.org>; Wed, 10 May 2000 10:57:00 -0700 (PDT)
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by ertpg14e1.nortelnetworks.com; Wed, 10 May 2000 14:02:43 -0400
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id KVDMCFB5; Wed, 10 May 2000 14:02:43 -0400
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) 
          by zcard00f.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id KL5GAVQR; Wed, 10 May 2000 14:02:43 -0400
Message-ID: <3919A4C7.94062963@americasm01.nt.com>
Date: Wed, 10 May 2000 14:04:55 -0400
From: "Abdallah Rayhan" <arayhan@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: IPSP List <ipsec-policy@vpnc.org>
Subject: conditions and actions in Policy class
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

In the policy class (short format), the policy attribute must be
met before an action can be enforced. Since policy is m-v
then the policy conditions are examined in order of listing,
preference is based on listing. Is my interpretation correct
here?

When we have the long format, what attributes or selectors
must be met before an action takes place? Do conditions
have to match all present selectors like dst, ipv6-class,
ipv6-flow, ...? If that is the case then how do you handle
selectors when they appear more than once? e.g. they are
of m-v type!

Abdallah Rayhan




From owner-ipsec-policy  Thu May 11 11:10:50 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA20851
	for ipsec-policy-bks; Thu, 11 May 2000 11:10:50 -0700 (PDT)
Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20847
	for <ipsec-policy@vpnc.org>; Thu, 11 May 2000 11:10:45 -0700 (PDT)
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by ertpg14e1.nortelnetworks.com; Thu, 11 May 2000 14:12:48 -0400
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id KXJMRC18; Thu, 11 May 2000 14:12:48 -0400
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) 
          by zcard00f.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id KX18RN5J; Thu, 11 May 2000 14:12:48 -0400
Message-ID: <391AF8A4.CF9B27A3@americasm01.nt.com>
Date: Thu, 11 May 2000 14:15:00 -0400
From: "Abdallah Rayhan" <arayhan@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: IPSP List <ipsec-policy@vpnc.org>
Subject: ICMP messages
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

In the requirements draft of the discovery protocol the following
text about ICMP messages is found in Section 1.2,

"For instance, the source may become aware of the presence
of a firewall if it receives ICMP messages from the firewall as it
discards the packets.......

This clumsy process can be further complicated by the fact
that many firewalls may drop the packets without sending back
any messages."

If a firewall decides not to send any ICMP error messages
because it does not want to reveal its identity to the public
by sending ICMP messages carrying clear text, then any
discovery  protocol that runs in the clear will probably be
faced with firewall  ignorance due to the same reasons. In
this case we will end up where we started

Any comments?

Abdallah Rayhan



From owner-ipsec-policy  Thu May 11 11:28:00 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA21118
	for ipsec-policy-bks; Thu, 11 May 2000 11:28:00 -0700 (PDT)
Received: from adk.gr (COREDUMP.CIS.UPENN.EDU [158.130.6.141])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA21114
	for <ipsec-policy@vpnc.org>; Thu, 11 May 2000 11:27:59 -0700 (PDT)
Received: from dsl.cis.upenn.edu (localhost [127.0.0.1])
	by adk.gr (8.10.1/8.9.3) with ESMTP id e4BIXPb03781;
	Thu, 11 May 2000 14:33:25 -0400 (EDT)
Message-Id: <200005111833.e4BIXPb03781@adk.gr>
X-Mailer: exmh version 2.0.2 2/24/98
To: "Abdallah Rayhan" <arayhan@nortelnetworks.com>
Cc: IPSP List <ipsec-policy@vpnc.org>
Subject: Re: ICMP messages 
In-reply-to: Your message of "Thu, 11 May 2000 14:15:00 EDT."
             <391AF8A4.CF9B27A3@americasm01.nt.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 11 May 2000 14:33:25 -0400
From: "Angelos D. Keromytis" <angelos@dsl.cis.upenn.edu>
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

In message <391AF8A4.CF9B27A3@americasm01.nt.com>, "Abdallah Rayhan" writes:
>
>If a firewall decides not to send any ICMP error messages
>because it does not want to reveal its identity to the public
>by sending ICMP messages carrying clear text, then any
>discovery  protocol that runs in the clear will probably be
>faced with firewall  ignorance due to the same reasons. In
>this case we will end up where we started

The problem does not lie with the security properties of the ICMP message
(clear text or encrypted), but with the fact that it is ICMP and thus de
facto filtered by most firewalls in existance. This attitude is unlikely
to change.

On the other hand, a new protocol that just does discovery is more likely to
be allowed through (even if proxied).
-Angelos




From owner-ipsec-policy  Thu May 11 12:04:50 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA21754
	for ipsec-policy-bks; Thu, 11 May 2000 12:04:50 -0700 (PDT)
Received: from adk.gr (COREDUMP.CIS.UPENN.EDU [158.130.6.141])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21748
	for <ipsec-policy@vpnc.org>; Thu, 11 May 2000 12:04:42 -0700 (PDT)
Received: from dsl.cis.upenn.edu (localhost [127.0.0.1])
	by adk.gr (8.10.1/8.9.3) with ESMTP id e4BJA0b23911;
	Thu, 11 May 2000 15:10:00 -0400 (EDT)
Message-Id: <200005111910.e4BJA0b23911@adk.gr>
X-Mailer: exmh version 2.0.2 2/24/98
To: "Abdallah Rayhan" <arayhan@nortelnetworks.com>
Cc: IPSP List <ipsec-policy@vpnc.org>
Subject: Re: ICMP messages 
In-reply-to: Your message of "Thu, 11 May 2000 15:09:46 EDT."
             <391B057A.80A2A2A0@americasm01.nt.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 11 May 2000 15:10:00 -0400
From: "Angelos D. Keromytis" <angelos@dsl.cis.upenn.edu>
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

In message <391B057A.80A2A2A0@americasm01.nt.com>, "Abdallah Rayhan" writes:
>
>Firewalls can make another de facto regarding the discovery
>protocol if it posses a threat to the inside or for any other reason.

Keyword here being "if". There's no reason why it should be viewed as
a threat. This is purely an engineering problem.
-Angelos



From owner-ipsec-policy  Thu May 11 12:01:56 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA21661
	for ipsec-policy-bks; Thu, 11 May 2000 12:01:56 -0700 (PDT)
Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21647
	for <ipsec-policy@vpnc.org>; Thu, 11 May 2000 12:01:53 -0700 (PDT)
Received: from zcard00m.ca.nortel.com (actually zcard00m) 
          by ertpg14e1.nortelnetworks.com; Thu, 11 May 2000 15:07:34 -0400
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id K4DZXN6L; Thu, 11 May 2000 15:07:29 -0400
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) 
          by zcard00f.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id KX18R3CF; Thu, 11 May 2000 15:07:34 -0400
Message-ID: <391B057A.80A2A2A0@americasm01.nt.com>
Date: Thu, 11 May 2000 15:09:46 -0400
From: "Abdallah Rayhan" <arayhan@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Angelos D. Keromytis" <angelos@dsl.cis.upenn.edu>
CC: IPSP List <ipsec-policy@vpnc.org>
Subject: Re: ICMP messages
References: <200005111833.e4BIXPb03781@adk.gr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Angelos,

Firewalls can make another de facto regarding the discovery
protocol if it posses a threat to the inside or for any other reason.

A proxy sounds interesting but wont you need something
like IKE to start with before starting negotiating policy?
If that is the case, then IKE could serve as a discovery
protocol in addition to providing endpoint authentication
and encryption for the negotiation phase.

Abdallah

"Angelos D. Keromytis" wrote:

> In message <391AF8A4.CF9B27A3@americasm01.nt.com>, "Abdallah Rayhan" writes:
> >
> >If a firewall decides not to send any ICMP error messages
> >because it does not want to reveal its identity to the public
> >by sending ICMP messages carrying clear text, then any
> >discovery  protocol that runs in the clear will probably be
> >faced with firewall  ignorance due to the same reasons. In
> >this case we will end up where we started
>
> The problem does not lie with the security properties of the ICMP message
> (clear text or encrypted), but with the fact that it is ICMP and thus de
> facto filtered by most firewalls in existance. This attitude is unlikely
> to change.
>
> On the other hand, a new protocol that just does discovery is more likely to
> be allowed through (even if proxied).
> -Angelos


From owner-ipsec-policy  Fri May 12 04:59:42 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id EAA22146
	for ipsec-policy-bks; Fri, 12 May 2000 04:59:42 -0700 (PDT)
Received: from dfmail.datafellows.com (dfmail.datafellows.com [194.252.6.39])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA22142
	for <ipsec-policy@vpnc.org>; Fri, 12 May 2000 04:59:40 -0700 (PDT)
Received: (qmail 14275 invoked from network); 12 May 2000 12:03:43 -0000
Received: from dfintra.datafellows.com (HELO dfintra.f-secure.com) (194.197.29.8)
  by dfmail.datafellows.com with SMTP; 12 May 2000 12:03:43 -0000
Received: (qmail 25854 invoked from network); 12 May 2000 12:04:54 -0000
Received: from df129-180.datafellows.com (HELO F-Secure.com) (10.128.129.180)
  by dfintra.datafellows.com with SMTP; 12 May 2000 12:04:54 -0000
Message-ID: <391BF3ED.CF8D4B1A@F-Secure.com>
Date: Fri, 12 May 2000 15:07:09 +0300
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Oyj
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Yaron Sheffer <yaron.sheffer@radguard.com>
CC: IPSP List <ipsec-policy@vpnc.org>
Subject: Re: Some comments on SPSL
References: <391128B3.5CBC87CC@radguard.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

This WG should make the distinction about the policy model and how
it is actually represented. I'm thinking something along the lines
of draft-jason-ipsp-config-policy-model-00.txt here, although I don't
necessarily endorse the whole draft.

The model should be defined in a language independent way, using
UML or something similar. I believe the general policy WG is using
CIM, which might also be a good choice.

I don't particularly like this WG to define a totally new 
format for policies. As was argued by Yaron, creating
a new format has its problems.

I therefore propose that this WG define a policy file format
based on XML. This has several advantages:
- Relatively readable syntax, even in ASCII.
- Much support for the XML file format in the industry.
- XMLDSIG WG is defining methods to create signatures for XML.

Of course, this doesn't yet tackle any of the real problems of
what should be in the policy file, or if there should be inheritance,
or anything of that sort.

Ari

Yaron Sheffer wrote:
> 
> Hi,
> 
> below are some high-level comments to the SPSL draft. I am sparing the
> group a long list of comments regarding the nuts and bolts of the
> language, which I sent to the authors.
> 
> Your replies and counter-comments are most welcome.
> 
> - A specialized language is less flexible than UML for describing
> information. UML can derive various implementation-specific schema for
> the same basic information, which is more difficult when starting from a
> language. Also, SPSL is semantically constrained in its lack of direct
> support for inheritance.
> - The language is lacking the essential distinction of lexical vs
> syntactic levels (LEX vs YACC). This is apparent in several places, e.g.
> where numbers are implicitly assumed to be decimal or hex.
> - It is not clear why protection of the data objects should be part of
> the language. I believe it is best left out, and standard (CMS?) object
> wrapping techniques be used instead, at the implementor's discretion.
> - The information model assumes that only fixed "nodes" (DNS names) are
> protected. But it should allow for user identification by NAI (Email
> address) or Distinguished Name. IKE is very flexible in identifying
> endpoints and this should be reflected in SPSL.
> - In several places inheritance can be used for simplicity. For example,
> a policy server is a node, so its type definition could be derived from
> that of a node. Given that the language does not support inheritance, a
> "policy server" object could contain an sub-object that is a node.
> 
> Thanks,
>     Yaron

-- 
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

F-Secure Corporation       http://www.F-Secure.com 

F-Secure products: Integrated Solutions for Enterprise Security

From owner-ipsec-policy  Sun May 14 08:46:47 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA11470
	for ipsec-policy-bks; Sun, 14 May 2000 08:46:47 -0700 (PDT)
Received: from mail.inter.net.il (parker.inter.net.il [192.116.202.33])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11464
	for <ipsec-policy@vpnc.org>; Sun, 14 May 2000 08:46:39 -0700 (PDT)
Received: from radguard.com (radguard.com [192.114.169.3])
	by mail.inter.net.il (8.9.3/8.9.3) with SMTP id SAA21807;
	Sun, 14 May 2000 18:50:53 +0300 (IDT)
Received: by radguard.com   (4.1/SMI-4.1)
	id AA24685; Sat, 13 May 00 11:27:37 IDT
Received: from UNKNOWN(192.114.33.100), claiming to be "hellman.radguard.com"
 via SMTP by radguard.com, id smtpdAAAa24683; Sat May 13 11:27:32 2000
Received: from radguard.com by hellman.radguard.com (8.8.8+Sun/SMI-SVR4)
	id KAA12056; Sat, 13 May 2000 10:27:23 +0200 (IST)
Message-Id: <391D1F99.1C45F435@radguard.com>
Date: Sat, 13 May 2000 11:25:46 +0200
From: Yaron Sheffer <yaron.sheffer@radguard.com>
Organization: RADGUARD
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
Mime-Version: 1.0
To: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Cc: IPSP List <ipsec-policy@vpnc.org>
Subject: Re: Some comments on SPSL
References: <391128B3.5CBC87CC@radguard.com> <391BF3ED.CF8D4B1A@F-Secure.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Hi Ari,

following your proposal, I would like to propose that we finalize a policy
information model in UML. Then we could work on two semi-automatic
derivatives, one for LDAP and one for XML. I think Jason's draft is a good
starting point for the model.

SPSL has one additional goal that in not well covered by either of the above,
which is human readability. However SPSL can also be derived from the
information model, making for a human-readable equivalent to an LDAP or
XML-based policy. But I believe many vendors would prefer a GUI-based
representation instead.

Since you mention xmldsig, I think mechanisms for protecting the policy should
not be part of the policy (as in SPSL) but of the container: XML, LDAP or
whatever. Policy representation is complicated enough as it is, plus the
protection mechanisms are tightly bound to external enforcement mechanisms
(e.g. access control in LDAP) rather than to the policy itself. In some sense,
including digital signatures in the policy definition is equivalent to the
IPSec RFCs specifying a digital signature for the device driver that
implements IPSec.

Regards,
    Yaron

Ari Huttunen wrote:

> This WG should make the distinction about the policy model and how
> it is actually represented. I'm thinking something along the lines
> of draft-jason-ipsp-config-policy-model-00.txt here, although I don't
> necessarily endorse the whole draft.
>
> The model should be defined in a language independent way, using
> UML or something similar. I believe the general policy WG is using
> CIM, which might also be a good choice.
>
> I don't particularly like this WG to define a totally new
> format for policies. As was argued by Yaron, creating
> a new format has its problems.
>
> I therefore propose that this WG define a policy file format
> based on XML. This has several advantages:
> - Relatively readable syntax, even in ASCII.
> - Much support for the XML file format in the industry.
> - XMLDSIG WG is defining methods to create signatures for XML.
>
> Of course, this doesn't yet tackle any of the real problems of
> what should be in the policy file, or if there should be inheritance,
> or anything of that sort.
>
> Ari
>
> Yaron Sheffer wrote:
> >
> > Hi,
> >
> > below are some high-level comments to the SPSL draft. I am sparing the
> > group a long list of comments regarding the nuts and bolts of the
> > language, which I sent to the authors.
> >
> > Your replies and counter-comments are most welcome.
> >
> > - A specialized language is less flexible than UML for describing
> > information. UML can derive various implementation-specific schema for
> > the same basic information, which is more difficult when starting from a
> > language. Also, SPSL is semantically constrained in its lack of direct
> > support for inheritance.
> > - The language is lacking the essential distinction of lexical vs
> > syntactic levels (LEX vs YACC). This is apparent in several places, e.g.
> > where numbers are implicitly assumed to be decimal or hex.
> > - It is not clear why protection of the data objects should be part of
> > the language. I believe it is best left out, and standard (CMS?) object
> > wrapping techniques be used instead, at the implementor's discretion.
> > - The information model assumes that only fixed "nodes" (DNS names) are
> > protected. But it should allow for user identification by NAI (Email
> > address) or Distinguished Name. IKE is very flexible in identifying
> > endpoints and this should be reflected in SPSL.
> > - In several places inheritance can be used for simplicity. For example,
> > a policy server is a node, so its type definition could be derived from
> > that of a node. Given that the language does not support inheritance, a
> > "policy server" object could contain an sub-object that is a node.
> >
> > Thanks,
> >     Yaron
>
> --
> Ari Huttunen                   phone: +358 9 859 900
> Senior Software Engineer       fax  : +358 9 8599 0452
>
> F-Secure Corporation       http://www.F-Secure.com
>
> F-Secure products: Integrated Solutions for Enterprise Security


From owner-ipsec-policy  Mon May 15 09:21:41 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA24431
	for ipsec-policy-bks; Mon, 15 May 2000 09:21:41 -0700 (PDT)
Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24426
	for <ipsec-policy@vpnc.org>; Mon, 15 May 2000 09:21:36 -0700 (PDT)
Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.28 2000/05/06 00:07:11 dmccart Exp $) with SMTP id QAA16229;
	Mon, 15 May 2000 16:28:08 GMT
Received: from fmsmsx28.FM.INTEL.COM ([132.233.48.28]) by 132.233.48.205
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Mon, 15 May 2000 16:27:19 0000 (GMT)
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2448.0)
	id <KFHHRNN3>; Mon, 15 May 2000 09:27:17 -0700
Message-ID: <F2E11798B9F8D111AC3E00A0C95D77C603F2074F@fmsmsx43.fm.intel.com>
From: "Jason, Jamie" <jamie.jason@intel.com>
To: "'Yaron Sheffer'" <yaron.sheffer@radguard.com>,
        Ari Huttunen
	 <Ari.Huttunen@F-Secure.com>
Cc: IPSP List <ipsec-policy@vpnc.org>
Subject: RE: Some comments on SPSL
Date: Mon, 15 May 2000 09:27:15 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

This week, I will be meeting with Lee Rafalow, the Policy Working Group
liaison to IPSP.  This is in conjunction with a DMTF Face-2-Face where we
will also be discussing the DMTF version of IPsec policy.  We're going to
discuss how the IPsec policy model in the draft I wrote meshes with the
Policy Core Information Model (PCIM) - the draft in the Policy Working
Group.  After that I will be updating the IPsec UML draft to reflect changes
from there as well as feedback from Adelaide.  I would appreciate that if
anyone has any comments on the current draft that they send them to me by
5/22 so that I can start incorporating them into the updated draft.  Most
especially, I would love to hear from vendors that are doing IPsec remote
access solutions that use IPsec tunnel mode.

Also, we are currently working on an XML derivation of the schema.  If you
would like, we could write it up as an I-D and submit it.  Following that
update of the UML draft, I intend on deriving a COPS PIB and will submit
that as a draft as well - I am not sure if that gets submitted to IPSP or to
RAP.

Jamie

> -----Original Message-----
> From: Yaron Sheffer [mailto:yaron.sheffer@radguard.com]
> Sent: Saturday, May 13, 2000 2:26 AM
> To: Ari Huttunen
> Cc: IPSP List
> Subject: Re: Some comments on SPSL
> 
> 
> Hi Ari,
> 
> following your proposal, I would like to propose that we 
> finalize a policy
> information model in UML. Then we could work on two semi-automatic
> derivatives, one for LDAP and one for XML. I think Jason's 
> draft is a good
> starting point for the model.
> 
> SPSL has one additional goal that in not well covered by 
> either of the above,
> which is human readability. However SPSL can also be derived from the
> information model, making for a human-readable equivalent to 
> an LDAP or
> XML-based policy. But I believe many vendors would prefer a GUI-based
> representation instead.
> 
> Since you mention xmldsig, I think mechanisms for protecting 
> the policy should
> not be part of the policy (as in SPSL) but of the container: 
> XML, LDAP or
> whatever. Policy representation is complicated enough as it 
> is, plus the
> protection mechanisms are tightly bound to external 
> enforcement mechanisms
> (e.g. access control in LDAP) rather than to the policy 
> itself. In some sense,
> including digital signatures in the policy definition is 
> equivalent to the
> IPSec RFCs specifying a digital signature for the device driver that
> implements IPSec.
> 
> Regards,
>     Yaron
> 
> Ari Huttunen wrote:
> 
> > This WG should make the distinction about the policy model and how
> > it is actually represented. I'm thinking something along the lines
> > of draft-jason-ipsp-config-policy-model-00.txt here, 
> although I don't
> > necessarily endorse the whole draft.
> >
> > The model should be defined in a language independent way, using
> > UML or something similar. I believe the general policy WG is using
> > CIM, which might also be a good choice.
> >
> > I don't particularly like this WG to define a totally new
> > format for policies. As was argued by Yaron, creating
> > a new format has its problems.
> >
> > I therefore propose that this WG define a policy file format
> > based on XML. This has several advantages:
> > - Relatively readable syntax, even in ASCII.
> > - Much support for the XML file format in the industry.
> > - XMLDSIG WG is defining methods to create signatures for XML.
> >
> > Of course, this doesn't yet tackle any of the real problems of
> > what should be in the policy file, or if there should be 
> inheritance,
> > or anything of that sort.
> >
> > Ari
> >
> > Yaron Sheffer wrote:
> > >
> > > Hi,
> > >
> > > below are some high-level comments to the SPSL draft. I 
> am sparing the
> > > group a long list of comments regarding the nuts and bolts of the
> > > language, which I sent to the authors.
> > >
> > > Your replies and counter-comments are most welcome.
> > >
> > > - A specialized language is less flexible than UML for describing
> > > information. UML can derive various 
> implementation-specific schema for
> > > the same basic information, which is more difficult when 
> starting from a
> > > language. Also, SPSL is semantically constrained in its 
> lack of direct
> > > support for inheritance.
> > > - The language is lacking the essential distinction of lexical vs
> > > syntactic levels (LEX vs YACC). This is apparent in 
> several places, e.g.
> > > where numbers are implicitly assumed to be decimal or hex.
> > > - It is not clear why protection of the data objects 
> should be part of
> > > the language. I believe it is best left out, and standard 
> (CMS?) object
> > > wrapping techniques be used instead, at the implementor's 
> discretion.
> > > - The information model assumes that only fixed "nodes" 
> (DNS names) are
> > > protected. But it should allow for user identification by 
> NAI (Email
> > > address) or Distinguished Name. IKE is very flexible in 
> identifying
> > > endpoints and this should be reflected in SPSL.
> > > - In several places inheritance can be used for 
> simplicity. For example,
> > > a policy server is a node, so its type definition could 
> be derived from
> > > that of a node. Given that the language does not support 
> inheritance, a
> > > "policy server" object could contain an sub-object that is a node.
> > >
> > > Thanks,
> > >     Yaron
> >
> > --
> > Ari Huttunen                   phone: +358 9 859 900
> > Senior Software Engineer       fax  : +358 9 8599 0452
> >
> > F-Secure Corporation       http://www.F-Secure.com
> >
> > F-Secure products: Integrated Solutions for Enterprise Security
> 
> 


From owner-ipsec-policy  Fri May 19 00:39:00 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id AAA16705
	for ipsec-policy-bks; Fri, 19 May 2000 00:39:00 -0700 (PDT)
Received: from dfmail.datafellows.com (dfmail.datafellows.com [194.252.6.39])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA16691
	for <ipsec-policy@vpnc.org>; Fri, 19 May 2000 00:38:57 -0700 (PDT)
Received: (qmail 1326 invoked by uid 0); 19 May 2000 07:43:53 -0000
Received: from dfintra.datafellows.com (HELO dfintra.f-secure.com) (194.197.29.8)
  by dfmail.datafellows.com with SMTP; 19 May 2000 07:43:53 -0000
Received: (qmail 20279 invoked from network); 19 May 2000 07:45:13 -0000
Received: from df129-180.datafellows.com (HELO F-Secure.com) (10.128.129.180)
  by dfintra.datafellows.com with SMTP; 19 May 2000 07:45:13 -0000
Message-ID: <3924F10B.5C834C91@F-Secure.com>
Date: Fri, 19 May 2000 10:45:15 +0300
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Oyj
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Scott G. Kelly" <skelly@redcreek.com>
CC: ietf-ipsra@vpnc.org, IPSP List <ipsec-policy@vpnc.org>
Subject: Re: [Fwd: l2tp/ipsec for remote access (LONG; was Re: PPP over IPSec... 
 on the ipsec list)]
References: <392439A4.11B1819C@redcreek.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

"Scott G. Kelly" wrote:
> I'd like to point out one thing: the current ipsec spec requires no
> changes in order for you to deploy a remote access solution using l2tp.
> You can configure your security gateways to secure l2tp over udp, and
> have your remote access client tunnel through to a NAS which terminates
> the l2tp connection.
> 
> Scott

One concern with this is that you can accidentally
configure one end of a connection to use plain IPSec while the
other end wants to use L2TP/IPSec. It gets even more complicated
when you locate L2TP and IPSec endpoints in different boxes, or
even if you run IPSec inside L2TP, as one draft suggests.

If the result at the end of this discussion is that L2TP should
be in the picture, I would strongly suggest that IKE negotiation
and SPP (or whatever IPSP WG produces for this purpose) also
take proper note of L2TP.

It has been stated many times in this thread that since PPP/L2TP
already exist and are deployed, it is the path of least resistance
to remote access. I doubt that until I see them fully incorporated,
including this negotiation I mention above.

Ari

-- 
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

F-Secure Corporation       http://www.F-Secure.com 

F-Secure products: Integrated Solutions for Enterprise Security

From owner-ipsec-policy  Mon May 22 03:29:32 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id DAA16783
	for ipsec-policy-bks; Mon, 22 May 2000 03:29:32 -0700 (PDT)
Received: from trustworks.com (mail.trustworks.nl [212.206.223.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA16779
	for <ipsec-policy@vpnc.org>; Mon, 22 May 2000 03:29:26 -0700 (PDT)
Received: by trustworks.com (8.8.5/SMI-SVR4)
	id MAA01150; Mon, 22 May 2000 12:34:34 +0200 (MET DST)
Received: from relay1.trustworks.com by trustworks.com (8.8.5/SMI-SVR4)
	id QAA12567; Wed, 10 May 2000 16:39:10 +0200 (MET DST)
Received: by relay1.trustworks.com (8.8.5/1.5)
	id SAA04919; Wed, 10 May 2000 18:39:47 +0400 (MSD)
Received: from ns.secondary.com(208.184.76.39) by zuka via smap (V2.0)
	id xma004879; Wed, 10 May 00 18:39:10 +0400
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id GAA26568
	for ipsec-policy-bks; Wed, 10 May 2000 06:43:27 -0700 (PDT)
Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA26564
	for <ipsec-policy@vpnc.org>; Wed, 10 May 2000 06:43:26 -0700 (PDT)
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by smtprch1.nortel.com; Wed, 10 May 2000 08:48:46 -0500
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id K4CS7A95; Wed, 10 May 2000 09:48:41 -0400
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) 
          by zcard00f.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id KL5GA4L0; Wed, 10 May 2000 09:48:42 -0400
Message-ID: <3919693D.DE8706F9@americasm01.nt.com>
Date: Wed, 10 May 2000 09:50:53 -0400
From: "Abdallah Rayhan" <arayhan@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
CC: IPSP List <ipsec-policy@vpnc.org>
Subject: Re: Some comments on SPSL
References: <391128B3.5CBC87CC@radguard.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

See comments below!

Abdallah Rayhan

Yaron Sheffer wrote:

> Hi,
>
> below are some high-level comments to the SPSL draft. I am sparing the
> group a long list of comments regarding the nuts and bolts of the
> language, which I sent to the authors.
>
> Your replies and counter-comments are most welcome.
>
> - A specialized language is less flexible than UML for describing
> information. UML can derive various implementation-specific schema for
> the same basic information, which is more difficult when starting from a
> language. Also, SPSL is semantically constrained in its lack of direct
> support for inheritance.

I think SPSL is more like a template language than a programming
language. Having said that, inheritance in the general sense
could lead to complex semantical conflicts that would be difficult
to resolve. The protocols that use SPSL are signaling protocols
in nature, we still dont know much about them!!! Hence, the policy
engine need to deduce policy in realtime.


> - The language is lacking the essential distinction of lexical vs
> syntactic levels (LEX vs YACC). This is apparent in several places, e.g.
> where numbers are implicitly assumed to be decimal or hex.

SPSL could use some improvement here.

> - It is not clear why protection of the data objects should be part of
> the language. I believe it is best left out, and standard (CMS?) object
> wrapping techniques be used instead, at the implementor's discretion.

Right now, it is mandatory to protect the objects. However, if you store
the objects in a directory then the directory can do that for you. A
reasonable
approach would be to say that it is recommended but not mandatory.
The protocols that use the policy should have enough security constructs
to ensure the integrity of the data being exchanged between the policy
server
and the security gateway.

> - The information model assumes that only fixed "nodes" (DNS names) are
> protected. But it should allow for user identification by NAI (Email
> address) or Distinguished Name. IKE is very flexible in identifying
> endpoints and this should be reflected in SPSL.

SPSL is about PEP which basically are network entities and not users.
If the objective of SPSL is to become a general policy language (GPL),
then I would agree with you. Otherwise, it ought to be device oriented.
It would be interesting to have SPSL as a subset of a GPL if there is
a GPL standard!

> - In several places inheritance can be used for simplicity. For example,
> a policy server is a node, so its type definition could be derived from
> that of a node. Given that the language does not support inheritance, a
> "policy server" object could contain an sub-object that is a node.

See comment above.




From owner-ipsec-policy  Mon May 22 03:27:33 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id DAA16723
	for ipsec-policy-bks; Mon, 22 May 2000 03:27:33 -0700 (PDT)
Received: from trustworks.com (mail.trustworks.nl [212.206.223.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA16712
	for <ipsec-policy@vpnc.org>; Mon, 22 May 2000 03:27:19 -0700 (PDT)
Received: by trustworks.com (8.8.5/SMI-SVR4)
	id MAA00417; Mon, 22 May 2000 12:32:37 +0200 (MET DST)
Received: from relay1.trustworks.com by trustworks.com (8.8.5/SMI-SVR4)
	id PAA00874; Fri, 12 May 2000 15:14:31 +0200 (MET DST)
Received: by relay1.trustworks.com (8.8.5/1.5)
	id RAA09764; Fri, 12 May 2000 17:04:33 +0400 (MSD)
Received: from ns.secondary.com(208.184.76.39) by zuka via smap (V2.0)
	id xma009721; Fri, 12 May 00 17:03:55 +0400
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id EAA22146
	for ipsec-policy-bks; Fri, 12 May 2000 04:59:42 -0700 (PDT)
Received: from dfmail.datafellows.com (dfmail.datafellows.com [194.252.6.39])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA22142
	for <ipsec-policy@vpnc.org>; Fri, 12 May 2000 04:59:40 -0700 (PDT)
Received: (qmail 14275 invoked from network); 12 May 2000 12:03:43 -0000
Received: from dfintra.datafellows.com (HELO dfintra.f-secure.com) (194.197.29.8)
  by dfmail.datafellows.com with SMTP; 12 May 2000 12:03:43 -0000
Received: (qmail 25854 invoked from network); 12 May 2000 12:04:54 -0000
Received: from df129-180.datafellows.com (HELO F-Secure.com) (10.128.129.180)
  by dfintra.datafellows.com with SMTP; 12 May 2000 12:04:54 -0000
Message-ID: <391BF3ED.CF8D4B1A@F-Secure.com>
Date: Fri, 12 May 2000 15:07:09 +0300
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Oyj
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: IPSP List <ipsec-policy@vpnc.org>
Subject: Re: Some comments on SPSL
References: <391128B3.5CBC87CC@radguard.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

This WG should make the distinction about the policy model and how
it is actually represented. I'm thinking something along the lines
of draft-jason-ipsp-config-policy-model-00.txt here, although I don't
necessarily endorse the whole draft.

The model should be defined in a language independent way, using
UML or something similar. I believe the general policy WG is using
CIM, which might also be a good choice.

I don't particularly like this WG to define a totally new 
format for policies. As was argued by Yaron, creating
a new format has its problems.

I therefore propose that this WG define a policy file format
based on XML. This has several advantages:
- Relatively readable syntax, even in ASCII.
- Much support for the XML file format in the industry.
- XMLDSIG WG is defining methods to create signatures for XML.

Of course, this doesn't yet tackle any of the real problems of
what should be in the policy file, or if there should be inheritance,
or anything of that sort.

Ari

Yaron Sheffer wrote:
> 
> Hi,
> 
> below are some high-level comments to the SPSL draft. I am sparing the
> group a long list of comments regarding the nuts and bolts of the
> language, which I sent to the authors.
> 
> Your replies and counter-comments are most welcome.
> 
> - A specialized language is less flexible than UML for describing
> information. UML can derive various implementation-specific schema for
> the same basic information, which is more difficult when starting from a
> language. Also, SPSL is semantically constrained in its lack of direct
> support for inheritance.
> - The language is lacking the essential distinction of lexical vs
> syntactic levels (LEX vs YACC). This is apparent in several places, e.g.
> where numbers are implicitly assumed to be decimal or hex.
> - It is not clear why protection of the data objects should be part of
> the language. I believe it is best left out, and standard (CMS?) object
> wrapping techniques be used instead, at the implementor's discretion.
> - The information model assumes that only fixed "nodes" (DNS names) are
> protected. But it should allow for user identification by NAI (Email
> address) or Distinguished Name. IKE is very flexible in identifying
> endpoints and this should be reflected in SPSL.
> - In several places inheritance can be used for simplicity. For example,
> a policy server is a node, so its type definition could be derived from
> that of a node. Given that the language does not support inheritance, a
> "policy server" object could contain an sub-object that is a node.
> 
> Thanks,
>     Yaron

-- 
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

F-Secure Corporation       http://www.F-Secure.com 

F-Secure products: Integrated Solutions for Enterprise Security


From owner-ipsec-policy  Mon May 22 03:29:21 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id DAA16778
	for ipsec-policy-bks; Mon, 22 May 2000 03:29:21 -0700 (PDT)
Received: from trustworks.com (mail.trustworks.nl [212.206.223.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA16768
	for <ipsec-policy@vpnc.org>; Mon, 22 May 2000 03:29:15 -0700 (PDT)
Received: by trustworks.com (8.8.5/SMI-SVR4)
	id MAA01140; Mon, 22 May 2000 12:34:33 +0200 (MET DST)
Received: from relay1.trustworks.com by trustworks.com (8.8.5/SMI-SVR4)
	id PAA12220; Wed, 10 May 2000 15:26:04 +0200 (MET DST)
Received: by relay1.trustworks.com (8.8.5/1.5)
	id RAA00857; Wed, 10 May 2000 17:26:43 +0400 (MSD)
Received: from ns.secondary.com(208.184.76.39) by zuka via smap (V2.0)
	id xma000828; Wed, 10 May 00 17:25:58 +0400
Received: by ns.secondary.com (8.9.3/8.9.3) id FAA25596
	for ipsec-policy-bks; Wed, 10 May 2000 05:47:05 -0700 (PDT)
Received: from ertpg14e1.nortelnetworks.com (ertpg14e1.nortelnetworks.com [47.234.0.35])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA25592
	for <ipsec-policy@vpnc.org>; Wed, 10 May 2000 05:47:04 -0700 (PDT)
Received: from zcard00n.ca.nortel.com (actually zcard00n) 
          by ertpg14e1.nortelnetworks.com; Wed, 10 May 2000 08:52:47 -0400
Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id K4CS6YZ0; Wed, 10 May 2000 08:52:47 -0400
Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) 
          by zcard00f.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) 
          id KL5GA4CM; Wed, 10 May 2000 08:52:47 -0400
Message-ID: <39195C23.63946C36@americasm01.nt.com>
Date: Wed, 10 May 2000 08:54:59 -0400
From: "Abdallah Rayhan" <arayhan@nortelnetworks.com>
Organization: Nortel Networks
X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
CC: ipsec-policy@vpnc.org
Subject: Re: policy format
References: <20000510122529.10726.qmail@squatch.ir.bbn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

One can argue for one form or another. However to reduce
complexity and less confusion, one form should be enough
as long as it can express all the requirements. Three forms
does not bring anything new.

Abdallah Rayhan

Matthew Condell wrote:

> Essentially, there is only one format for policy -- the combined
> format.  The document describes it as three logical formats as
> an attempt to make it easier to describe the parts of the policy
> object.  If this is being found confusing, we can attempt to
> either describe the object only as one form or be more
> explicit that the three forms are artificial divisions of the
> object.
>
> >SPSL states that the policy can be defined in three formats, e.g.,
> >short, long, and combined. I believe this is redundancy and
> >source of confusion. Policy should have one format which
> >is general enough to include the properties of the other ones.
> >If optimization is a concern then the optimized version can
> >be obtained when policy is sent on the wire.
>
> Matt Condell
> BBN Technologies



From owner-ipsec-policy  Mon May 22 03:27:34 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id DAA16725
	for ipsec-policy-bks; Mon, 22 May 2000 03:27:34 -0700 (PDT)
Received: from trustworks.com (mail.trustworks.nl [212.206.223.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA16711
	for <ipsec-policy@vpnc.org>; Mon, 22 May 2000 03:27:19 -0700 (PDT)
Received: by trustworks.com (8.8.5/SMI-SVR4)
	id MAA00489; Mon, 22 May 2000 12:32:40 +0200 (MET DST)
Received: from relay1.trustworks.com by trustworks.com (8.8.5/SMI-SVR4)
	id SAA04428; Sun, 14 May 2000 18:37:23 +0200 (MET DST)
Received: by relay1.trustworks.com (8.8.5/1.5)
	id UAA13519; Sun, 14 May 2000 20:38:03 +0400 (MSD)
Received: from ns.secondary.com(208.184.76.39) by zuka via smap (V2.0)
	id xma013501; Sun, 14 May 00 20:37:38 +0400
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA11470
	for ipsec-policy-bks; Sun, 14 May 2000 08:46:47 -0700 (PDT)
Received: from mail.inter.net.il (parker.inter.net.il [192.116.202.33])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA11464
	for <ipsec-policy@vpnc.org>; Sun, 14 May 2000 08:46:39 -0700 (PDT)
Received: from radguard.com (radguard.com [192.114.169.3])
	by mail.inter.net.il (8.9.3/8.9.3) with SMTP id SAA21807;
	Sun, 14 May 2000 18:50:53 +0300 (IDT)
Received: by radguard.com   (4.1/SMI-4.1)
	id AA24685; Sat, 13 May 00 11:27:37 IDT
Received: from UNKNOWN(192.114.33.100), claiming to be "hellman.radguard.com"
 via SMTP by radguard.com, id smtpdAAAa24683; Sat May 13 11:27:32 2000
Received: from radguard.com by hellman.radguard.com (8.8.8+Sun/SMI-SVR4)
	id KAA12056; Sat, 13 May 2000 10:27:23 +0200 (IST)
Message-Id: <391D1F99.1C45F435@radguard.com>
Date: Sat, 13 May 2000 11:25:46 +0200
From: Yaron Sheffer <yaron.sheffer@radguard.com>
Organization: RADGUARD
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
Mime-Version: 1.0
Cc: IPSP List <ipsec-policy@vpnc.org>
Subject: Re: Some comments on SPSL
References: <391128B3.5CBC87CC@radguard.com> <391BF3ED.CF8D4B1A@F-Secure.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Hi Ari,

following your proposal, I would like to propose that we finalize a policy
information model in UML. Then we could work on two semi-automatic
derivatives, one for LDAP and one for XML. I think Jason's draft is a good
starting point for the model.

SPSL has one additional goal that in not well covered by either of the above,
which is human readability. However SPSL can also be derived from the
information model, making for a human-readable equivalent to an LDAP or
XML-based policy. But I believe many vendors would prefer a GUI-based
representation instead.

Since you mention xmldsig, I think mechanisms for protecting the policy should
not be part of the policy (as in SPSL) but of the container: XML, LDAP or
whatever. Policy representation is complicated enough as it is, plus the
protection mechanisms are tightly bound to external enforcement mechanisms
(e.g. access control in LDAP) rather than to the policy itself. In some sense,
including digital signatures in the policy definition is equivalent to the
IPSec RFCs specifying a digital signature for the device driver that
implements IPSec.

Regards,
    Yaron

Ari Huttunen wrote:

> This WG should make the distinction about the policy model and how
> it is actually represented. I'm thinking something along the lines
> of draft-jason-ipsp-config-policy-model-00.txt here, although I don't
> necessarily endorse the whole draft.
>
> The model should be defined in a language independent way, using
> UML or something similar. I believe the general policy WG is using
> CIM, which might also be a good choice.
>
> I don't particularly like this WG to define a totally new
> format for policies. As was argued by Yaron, creating
> a new format has its problems.
>
> I therefore propose that this WG define a policy file format
> based on XML. This has several advantages:
> - Relatively readable syntax, even in ASCII.
> - Much support for the XML file format in the industry.
> - XMLDSIG WG is defining methods to create signatures for XML.
>
> Of course, this doesn't yet tackle any of the real problems of
> what should be in the policy file, or if there should be inheritance,
> or anything of that sort.
>
> Ari
>
> Yaron Sheffer wrote:
> >
> > Hi,
> >
> > below are some high-level comments to the SPSL draft. I am sparing the
> > group a long list of comments regarding the nuts and bolts of the
> > language, which I sent to the authors.
> >
> > Your replies and counter-comments are most welcome.
> >
> > - A specialized language is less flexible than UML for describing
> > information. UML can derive various implementation-specific schema for
> > the same basic information, which is more difficult when starting from a
> > language. Also, SPSL is semantically constrained in its lack of direct
> > support for inheritance.
> > - The language is lacking the essential distinction of lexical vs
> > syntactic levels (LEX vs YACC). This is apparent in several places, e.g.
> > where numbers are implicitly assumed to be decimal or hex.
> > - It is not clear why protection of the data objects should be part of
> > the language. I believe it is best left out, and standard (CMS?) object
> > wrapping techniques be used instead, at the implementor's discretion.
> > - The information model assumes that only fixed "nodes" (DNS names) are
> > protected. But it should allow for user identification by NAI (Email
> > address) or Distinguished Name. IKE is very flexible in identifying
> > endpoints and this should be reflected in SPSL.
> > - In several places inheritance can be used for simplicity. For example,
> > a policy server is a node, so its type definition could be derived from
> > that of a node. Given that the language does not support inheritance, a
> > "policy server" object could contain an sub-object that is a node.
> >
> > Thanks,
> >     Yaron
>
> --
> Ari Huttunen                   phone: +358 9 859 900
> Senior Software Engineer       fax  : +358 9 8599 0452
>
> F-Secure Corporation       http://www.F-Secure.com
>
> F-Secure products: Integrated Solutions for Enterprise Security



From owner-ipsec-policy  Mon May 22 03:27:44 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id DAA16743
	for ipsec-policy-bks; Mon, 22 May 2000 03:27:44 -0700 (PDT)
Received: from trustworks.com (mail.trustworks.nl [212.206.223.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA16726
	for <ipsec-policy@vpnc.org>; Mon, 22 May 2000 03:27:35 -0700 (PDT)
Received: by trustworks.com (8.8.5/SMI-SVR4)
	id MAA00541; Mon, 22 May 2000 12:32:58 +0200 (MET DST)
Received: from relay1.trustworks.com by trustworks.com (8.8.5/SMI-SVR4)
	id TAA08211; Mon, 15 May 2000 19:14:27 +0200 (MET DST)
Received: by relay1.trustworks.com (8.8.5/1.5)
	id VAA12234; Mon, 15 May 2000 21:15:14 +0400 (MSD)
Received: from ns.secondary.com(208.184.76.39) by zuka via smap (V2.0)
	id xma012188; Mon, 15 May 00 21:14:37 +0400
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA24431
	for ipsec-policy-bks; Mon, 15 May 2000 09:21:41 -0700 (PDT)
Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA24426
	for <ipsec-policy@vpnc.org>; Mon, 15 May 2000 09:21:36 -0700 (PDT)
Received: from SMTP (fmsmsxvs05-1.fm.intel.com [132.233.42.205])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.28 2000/05/06 00:07:11 dmccart Exp $) with SMTP id QAA16229;
	Mon, 15 May 2000 16:28:08 GMT
Received: from fmsmsx28.FM.INTEL.COM ([132.233.48.28]) by 132.233.48.205
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Mon, 15 May 2000 16:27:19 0000 (GMT)
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2448.0)
	id <KFHHRNN3>; Mon, 15 May 2000 09:27:17 -0700
Message-ID: <F2E11798B9F8D111AC3E00A0C95D77C603F2074F@fmsmsx43.fm.intel.com>
From: "\"Jason, Jamie\" <jamie.jason@intel.com>
        Ari Huttunen"
	 <jamie.jason@intel.com>
Cc: IPSP List <ipsec-policy@vpnc.org>
Subject: RE: Some comments on SPSL
Date: Mon, 15 May 2000 09:27:15 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
	charset="iso-8859-1"
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

This week, I will be meeting with Lee Rafalow, the Policy Working Group
liaison to IPSP.  This is in conjunction with a DMTF Face-2-Face where we
will also be discussing the DMTF version of IPsec policy.  We're going to
discuss how the IPsec policy model in the draft I wrote meshes with the
Policy Core Information Model (PCIM) - the draft in the Policy Working
Group.  After that I will be updating the IPsec UML draft to reflect changes
from there as well as feedback from Adelaide.  I would appreciate that if
anyone has any comments on the current draft that they send them to me by
5/22 so that I can start incorporating them into the updated draft.  Most
especially, I would love to hear from vendors that are doing IPsec remote
access solutions that use IPsec tunnel mode.

Also, we are currently working on an XML derivation of the schema.  If you
would like, we could write it up as an I-D and submit it.  Following that
update of the UML draft, I intend on deriving a COPS PIB and will submit
that as a draft as well - I am not sure if that gets submitted to IPSP or to
RAP.

Jamie

> -----Original Message-----
> From: Yaron Sheffer [mailto:yaron.sheffer@radguard.com]
> Sent: Saturday, May 13, 2000 2:26 AM
> To: Ari Huttunen
> Cc: IPSP List
> Subject: Re: Some comments on SPSL
> 
> 
> Hi Ari,
> 
> following your proposal, I would like to propose that we 
> finalize a policy
> information model in UML. Then we could work on two semi-automatic
> derivatives, one for LDAP and one for XML. I think Jason's 
> draft is a good
> starting point for the model.
> 
> SPSL has one additional goal that in not well covered by 
> either of the above,
> which is human readability. However SPSL can also be derived from the
> information model, making for a human-readable equivalent to 
> an LDAP or
> XML-based policy. But I believe many vendors would prefer a GUI-based
> representation instead.
> 
> Since you mention xmldsig, I think mechanisms for protecting 
> the policy should
> not be part of the policy (as in SPSL) but of the container: 
> XML, LDAP or
> whatever. Policy representation is complicated enough as it 
> is, plus the
> protection mechanisms are tightly bound to external 
> enforcement mechanisms
> (e.g. access control in LDAP) rather than to the policy 
> itself. In some sense,
> including digital signatures in the policy definition is 
> equivalent to the
> IPSec RFCs specifying a digital signature for the device driver that
> implements IPSec.
> 
> Regards,
>     Yaron
> 
> Ari Huttunen wrote:
> 
> > This WG should make the distinction about the policy model and how
> > it is actually represented. I'm thinking something along the lines
> > of draft-jason-ipsp-config-policy-model-00.txt here, 
> although I don't
> > necessarily endorse the whole draft.
> >
> > The model should be defined in a language independent way, using
> > UML or something similar. I believe the general policy WG is using
> > CIM, which might also be a good choice.
> >
> > I don't particularly like this WG to define a totally new
> > format for policies. As was argued by Yaron, creating
> > a new format has its problems.
> >
> > I therefore propose that this WG define a policy file format
> > based on XML. This has several advantages:
> > - Relatively readable syntax, even in ASCII.
> > - Much support for the XML file format in the industry.
> > - XMLDSIG WG is defining methods to create signatures for XML.
> >
> > Of course, this doesn't yet tackle any of the real problems of
> > what should be in the policy file, or if there should be 
> inheritance,
> > or anything of that sort.
> >
> > Ari
> >
> > Yaron Sheffer wrote:
> > >
> > > Hi,
> > >
> > > below are some high-level comments to the SPSL draft. I 
> am sparing the
> > > group a long list of comments regarding the nuts and bolts of the
> > > language, which I sent to the authors.
> > >
> > > Your replies and counter-comments are most welcome.
> > >
> > > - A specialized language is less flexible than UML for describing
> > > information. UML can derive various 
> implementation-specific schema for
> > > the same basic information, which is more difficult when 
> starting from a
> > > language. Also, SPSL is semantically constrained in its 
> lack of direct
> > > support for inheritance.
> > > - The language is lacking the essential distinction of lexical vs
> > > syntactic levels (LEX vs YACC). This is apparent in 
> several places, e.g.
> > > where numbers are implicitly assumed to be decimal or hex.
> > > - It is not clear why protection of the data objects 
> should be part of
> > > the language. I believe it is best left out, and standard 
> (CMS?) object
> > > wrapping techniques be used instead, at the implementor's 
> discretion.
> > > - The information model assumes that only fixed "nodes" 
> (DNS names) are
> > > protected. But it should allow for user identification by 
> NAI (Email
> > > address) or Distinguished Name. IKE is very flexible in 
> identifying
> > > endpoints and this should be reflected in SPSL.
> > > - In several places inheritance can be used for 
> simplicity. For example,
> > > a policy server is a node, so its type definition could 
> be derived from
> > > that of a node. Given that the language does not support 
> inheritance, a
> > > "policy server" object could contain an sub-object that is a node.
> > >
> > > Thanks,
> > >     Yaron
> >
> > --
> > Ari Huttunen                   phone: +358 9 859 900
> > Senior Software Engineer       fax  : +358 9 8599 0452
> >
> > F-Secure Corporation       http://www.F-Secure.com
> >
> > F-Secure products: Integrated Solutions for Enterprise Security
> 
> 



From owner-ipsec-policy  Mon May 22 07:10:27 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA21899
	for ipsec-policy-bks; Mon, 22 May 2000 07:10:27 -0700 (PDT)
Received: from adk.gr (216-59-55-64.usa.flashcom.net [216.59.55.64])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA21895
	for <ipsec-policy@vpnc.org>; Mon, 22 May 2000 07:10:25 -0700 (PDT)
Received: from dsl.cis.upenn.edu (localhost [127.0.0.1])
	by adk.gr (8.10.1/8.9.3) with ESMTP id e4ME3xU31709
	for <ipsec-policy@vpnc.org>; Mon, 22 May 2000 10:03:59 -0400 (EDT)
Message-Id: <200005221403.e4ME3xU31709@adk.gr>
X-Mailer: exmh version 2.0.2 2/24/98
To: IPSP List <ipsec-policy@vpnc.org>
Subject: Re: Some comments on SPSL 
In-reply-to: Your message of "Sat, 13 May 2000 11:25:46 +0200."
             <391D1F99.1C45F435@radguard.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 22 May 2000 10:03:58 -0400
From: "Angelos D. Keromytis" <angelos@dsl.cis.upenn.edu>
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

In message <391D1F99.1C45F435@radguard.com>, Yaron Sheffer writes:
>
>following your proposal, I would like to propose that we finalize a policy
>information model in UML. Then we could work on two semi-automatic
>derivatives, one for LDAP and one for XML. I think Jason's draft is a good
>starting point for the model.

It has already been decided (both in this WG and elsewhere in the IETF
hierarchy) that LDAP is not the right way for storing/retrieving/distributing
policy (at least not for the purposes of IPSP), nor for doing gateway discovery
-- or just about anything related to IPSP; Luis Sanchez can enumerate the
reasons again, or you can find them in the last IETF's proceedings (if I
remember correctly).

>Since you mention xmldsig, I think mechanisms for protecting the policy should
>not be part of the policy (as in SPSL) but of the container: XML, LDAP or
>whatever.

That would make it very difficult (or impossible) to express relationships
between policies, or cascade/layer policies in any reasonable manner. In fact,
one of my quips with SPSL (which we've addressed with KeyNote) is that it
doesn't go far enough in this direction.
-Angelos



From owner-ipsec-policy  Mon May 22 08:32:09 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA24286
	for ipsec-policy-bks; Mon, 22 May 2000 08:32:09 -0700 (PDT)
Received: from mail.inter.net.il (parker.inter.net.il [192.116.202.33])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24282
	for <ipsec-policy@vpnc.org>; Mon, 22 May 2000 08:32:06 -0700 (PDT)
Received: from radguard.com (radguard.com [192.114.169.3])
	by mail.inter.net.il (8.9.3/8.9.3) with SMTP id SAA24398;
	Mon, 22 May 2000 18:37:55 +0300 (IDT)
Received: by radguard.com   (4.1/SMI-4.1)
	id AA19047; Mon, 22 May 00 18:39:20 IDT
Received: from UNKNOWN(192.114.33.100), claiming to be "hellman.radguard.com"
 via SMTP by radguard.com, id smtpdAAAa19045; Mon May 22 18:39:15 2000
Received: from radguard.com by hellman.radguard.com (8.8.8+Sun/SMI-SVR4)
	id RAA05252; Mon, 22 May 2000 17:39:31 +0200 (IST)
Message-Id: <3929625C.3F17B59@radguard.com>
Date: Mon, 22 May 2000 18:37:48 +0200
From: Yaron Sheffer <yaron.sheffer@radguard.com>
Organization: RADGUARD
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
Mime-Version: 1.0
To: "Angelos D. Keromytis" <angelos@dsl.cis.upenn.edu>
Cc: IPSP List <ipsec-policy@vpnc.org>, lsanchez@bbn.com
Subject: Re: Some comments on SPSL
References: <200005221403.e4ME3xU31709@adk.gr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Hi Angelos,

re: suitability of LDAP, I think you are referring to Luis's presentation from the
Washington IETF, which I have not been able to locate (the minutes only say: why -
or why not - LDAP). Can you please summarize why LDAP is not the right way?

Regarding the self-protecting policy, if the model is no more powerful than signing
the container (file), then this is a redundant mechanism. If however more
sophisticated trust relations can be defined, then they should be reflected in the
language. Or in the information model, alternatively.

Thanks,
    Yaron

"Angelos D. Keromytis" wrote:

> In message <391D1F99.1C45F435@radguard.com>, Yaron Sheffer writes:
> >
> >following your proposal, I would like to propose that we finalize a policy
> >information model in UML. Then we could work on two semi-automatic
> >derivatives, one for LDAP and one for XML. I think Jason's draft is a good
> >starting point for the model.
>
> It has already been decided (both in this WG and elsewhere in the IETF
> hierarchy) that LDAP is not the right way for storing/retrieving/distributing
> policy (at least not for the purposes of IPSP), nor for doing gateway discovery
> -- or just about anything related to IPSP; Luis Sanchez can enumerate the
> reasons again, or you can find them in the last IETF's proceedings (if I
> remember correctly).
>
> >Since you mention xmldsig, I think mechanisms for protecting the policy should
> >not be part of the policy (as in SPSL) but of the container: XML, LDAP or
> >whatever.
>
> That would make it very difficult (or impossible) to express relationships
> between policies, or cascade/layer policies in any reasonable manner. In fact,
> one of my quips with SPSL (which we've addressed with KeyNote) is that it
> doesn't go far enough in this direction.
> -Angelos


From owner-ipsec-policy  Mon May 22 11:06:26 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA27687
	for ipsec-policy-bks; Mon, 22 May 2000 11:06:26 -0700 (PDT)
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27683
	for <ipsec-policy@vpnc.org>; Mon, 22 May 2000 11:06:25 -0700 (PDT)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id OAB07476
	for <ipsec-policy@vpnc.org>; Mon, 22 May 2000 14:12:54 -0400
Received: from lmr (dyn9-37-49-166.raleigh.ibm.com [9.37.49.166])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id OAA27926
	for <ipsec-policy@vpnc.org>; Mon, 22 May 2000 14:12:59 -0400
Message-ID: <00dc01bfc419$dd719c20$a6312509@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: <ipsec-policy@vpnc.org>
References: <200005221403.e4ME3xU31709@adk.gr> <3929625C.3F17B59@radguard.com>
Subject: Representing policy (was: Some comments on SPSL)
Date: Mon, 22 May 2000 14:16:04 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

The IPSP WG is embarking on the same early path that the Policy Framework WG
also followed for a while.  There are two parallel efforts: one to define an
IPSec policy information model and one to define an IPSec policy
specification language.  If done properly these are isomorphic.  The
decision made in the Policy Framework WG was to focus on one, an information
model, rather than on two and on trying to keep them semantically
equivalent. To be consistent with the Policy Framework--a desirable and, it
turns, easily achievable goal--we should also focus on the information
model.

Jamie has a good start on an IPSec Policy Information Model
(draft-ietf-ipsp-policy-info-model-00.txt) and we've done some more work
that, I think, will be folded into the next draft.  Among other proposed
modifications, that work includes fitting the model into the policy
framework so that IPSP classes are derived from Policy Framework classes.

Once an information model is established, then implementations of the model
can be derived as needed for such things as COPS, LDAP, SPSL, XML, etc.  I,
too, am interested the arguments about LDAP (and other implementations) but
I believe these are second-order questions (that can be addressed in
parallel).

Lee

Lee M. Rafalow
Voice: 1-919-254-4455; Fax: 1-919-254-6243
IBM Internet Technology Management
IBM Corporation
P.O. Box 12195, BRQA/502
RTP, NC 27709 USA
Alternate email: rafalow@us.ibm.com
Home email: rafalow@mindspring.com


From owner-ipsec-policy  Mon May 22 14:41:54 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA01781
	for ipsec-policy-bks; Mon, 22 May 2000 14:41:54 -0700 (PDT)
Received: from adk.gr (COREDUMP.CIS.UPENN.EDU [158.130.6.141])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01777
	for <ipsec-policy@vpnc.org>; Mon, 22 May 2000 14:41:53 -0700 (PDT)
Received: from dsl.cis.upenn.edu (localhost [127.0.0.1])
	by adk.gr (8.10.1/8.9.3) with ESMTP id e4MLm7123372;
	Mon, 22 May 2000 17:48:07 -0400 (EDT)
Message-Id: <200005222148.e4MLm7123372@adk.gr>
X-Mailer: exmh version 2.0.2 2/24/98
To: "Lee Rafalow" <rafalow@raleigh.ibm.com>
Cc: ipsec-policy@vpnc.org
Subject: Re: Representing policy (was: Some comments on SPSL) 
In-reply-to: Your message of "Mon, 22 May 2000 14:16:04 EDT."
             <00dc01bfc419$dd719c20$a6312509@raleigh.ibm.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 22 May 2000 17:48:07 -0400
From: "Angelos D. Keromytis" <angelos@dsl.cis.upenn.edu>
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

In message <00dc01bfc419$dd719c20$a6312509@raleigh.ibm.com>, "Lee Rafalow" writ
es:
>The IPSP WG is embarking on the same early path that the Policy Framework WG
>also followed for a while.  There are two parallel efforts: one to define an
>IPSec policy information model and one to define an IPSec policy
>specification language.  If done properly these are isomorphic.  The
>decision made in the Policy Framework WG was to focus on one, an information
>model, rather than on two and on trying to keep them semantically
>equivalent. To be consistent with the Policy Framework--a desirable and, it
>turns, easily achievable goal--we should also focus on the information
>model.

I won't dispute the necessity of an information model; however, information
models won't move the bits around. Thus, we ultimately do need a specification
language :-)
-Angelos



From owner-ipsec-policy  Mon May 22 14:40:52 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA01757
	for ipsec-policy-bks; Mon, 22 May 2000 14:40:52 -0700 (PDT)
Received: from adk.gr (COREDUMP.CIS.UPENN.EDU [158.130.6.141])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01752
	for <ipsec-policy@vpnc.org>; Mon, 22 May 2000 14:40:50 -0700 (PDT)
Received: from dsl.cis.upenn.edu (localhost [127.0.0.1])
	by adk.gr (8.10.1/8.9.3) with ESMTP id e4MLkA109267;
	Mon, 22 May 2000 17:46:14 -0400 (EDT)
Message-Id: <200005222146.e4MLkA109267@adk.gr>
X-Mailer: exmh version 2.0.2 2/24/98
To: Yaron Sheffer <yaron.sheffer@radguard.com>
Cc: IPSP List <ipsec-policy@vpnc.org>, lsanchez@bbn.com
Subject: Re: Some comments on SPSL 
In-reply-to: Your message of "Mon, 22 May 2000 18:37:48 +0200."
             <3929625C.3F17B59@radguard.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 22 May 2000 17:46:09 -0400
From: "Angelos D. Keromytis" <angelos@dsl.cis.upenn.edu>
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

In message <3929625C.3F17B59@radguard.com>, Yaron Sheffer writes:
>Hi Angelos,
>
>re: suitability of LDAP, I think you are referring to Luis's presentation from
> the
>Washington IETF, which I have not been able to locate (the minutes only say: w
>hy -
>or why not - LDAP). Can you please summarize why LDAP is not the right way?

The reasons I can remember:
 - One of the mechanisms that may be used to provide security for LDAP is
   IPsec (so, chicken and egg problem).
 - Access to LDAP directories/servers may be impossible before determining
   what firewalls are out there and how to get through them.
 - LDAP is not well suited for dynamically discovering firewalls (or other
   types of entities) -- it's a directory, thus is as up-to-date as the
   information stored there. While one might reasonably expect a local LDAP
   server to have accurate information about the local network, it's not
   clear how well this'll work across multiple administrative domains.
 - LDAP generally requires some infrastructure (and, if it were used in IPSP,
   domain servers would need to point to each other); we don't have one. We'd
   like IPSP not to depend on an "outside" infrastructure, since it provides
   a "core" service.
 - Generally speaking, it's a bad idea to have a low level protocol depend
   on a higher level protocol for its operations (but there are exceptions).

I think Luis had a couple more reasons written down, but these should be the
main ones (and I can't seem to find a copy of his slides -- Luis ?)

>Regarding the self-protecting policy, if the model is no more powerful than si
>gning
>the container (file), then this is a redundant mechanism. If however more
>sophisticated trust relations can be defined, then they should be reflected in
> the
>language. Or in the information model, alternatively.

As you say, more sophisticated trust relations should be possible -- in the
form of constrained delegation for example. Not only this allows for
decentralized management (I'll refer you to Pekka Nikander's thesis, from '98,
on the subject), but it could also permit seamless mixing of credentials
and policies. Regarding trust relations (and definitions thereof), I'll refer
you to KeyNote (RFC 2704).
Cheers,
-Angelos



From owner-ipsec-policy  Tue May 23 04:24:01 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id EAA12346
	for ipsec-policy-bks; Tue, 23 May 2000 04:24:01 -0700 (PDT)
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA12342
	for <ipsec-policy@vpnc.org>; Tue, 23 May 2000 04:24:00 -0700 (PDT)
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id HAA16318
	for <ipsec-policy@vpnc.org>; Tue, 23 May 2000 07:30:29 -0400
Received: from lmr (dyn9-37-49-166.raleigh.ibm.com [9.37.49.166])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id HAA29298
	for <ipsec-policy@vpnc.org>; Tue, 23 May 2000 07:30:29 -0400
Message-ID: <003901bfc4aa$d851ff00$a6312509@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: <ipsec-policy@vpnc.org>
References: <200005222148.e4MLm7123372@adk.gr>
Subject: Re: Representing policy (was: Some comments on SPSL) 
Date: Tue, 23 May 2000 07:34:23 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

> I won't dispute the necessity of an information model; however,
information
> models won't move the bits around. Thus, we ultimately do need a
specification
> language :-)
> -Angelos

And I won't dispute the need to move bits around (but that doesn't
necessarily mean a specification language).  More importantly, right now, is
that we have a single, authoritative policy model from which formats (and
protocols) for moving bits around can be derived.  IMHO, that model is best
expressed as UML both because it's a good design tool and because it's
consistent with the Policy Framework.  Cheers, Lee

Lee M. Rafalow
Voice: 1-919-254-4455; Fax: 1-919-254-6243
IBM Internet Technology Management
IBM Corporation
P.O. Box 12195, BRQA/501
RTP, NC 27709 USA
Alternate email: rafalow@us.ibm.com
Home email: rafalow@mindspring.com


From owner-ipsec-policy  Tue May 23 09:45:22 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18148
	for ipsec-policy-bks; Tue, 23 May 2000 09:45:22 -0700 (PDT)
Received: from dfmail.datafellows.com (dfmail.datafellows.com [194.252.6.39])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA18144
	for <ipsec-policy@vpnc.org>; Tue, 23 May 2000 09:45:20 -0700 (PDT)
Received: (qmail 29796 invoked by uid 0); 23 May 2000 16:50:28 -0000
Received: from dfintra.datafellows.com (HELO dfintra.f-secure.com) (194.197.29.8)
  by dfmail.datafellows.com with SMTP; 23 May 2000 16:50:28 -0000
Received: (qmail 4957 invoked from network); 23 May 2000 16:51:54 -0000
Received: from df129-180.datafellows.com (HELO F-Secure.com) (10.128.129.180)
  by dfintra.datafellows.com with SMTP; 23 May 2000 16:51:54 -0000
Message-ID: <392AB734.37B668C5@F-Secure.com>
Date: Tue, 23 May 2000 19:52:04 +0300
From: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Organization: F-Secure Oyj
X-Mailer: Mozilla 4.7 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Angelos D. Keromytis" <angelos@dsl.cis.upenn.edu>
CC: Yaron Sheffer <yaron.sheffer@radguard.com>,
        IPSP List <ipsec-policy@vpnc.org>, lsanchez@bbn.com
Subject: Re: Some comments on SPSL
References: <200005222146.e4MLkA109267@adk.gr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

"Angelos D. Keromytis" wrote:
> 
> In message <3929625C.3F17B59@radguard.com>, Yaron Sheffer writes:
> >Hi Angelos,
> >
> >re: suitability of LDAP, I think you are referring to Luis's presentation from
> > the
> >Washington IETF, which I have not been able to locate (the minutes only say: w
> >hy -
> >or why not - LDAP). Can you please summarize why LDAP is not the right way?
> 
> The reasons I can remember:
>  - One of the mechanisms that may be used to provide security for LDAP is
>    IPsec (so, chicken and egg problem).
>  - Access to LDAP directories/servers may be impossible before determining
>    what firewalls are out there and how to get through them.
>  - LDAP is not well suited for dynamically discovering firewalls (or other
>    types of entities) -- it's a directory, thus is as up-to-date as the
>    information stored there. While one might reasonably expect a local LDAP
>    server to have accurate information about the local network, it's not
>    clear how well this'll work across multiple administrative domains.
>  - LDAP generally requires some infrastructure (and, if it were used in IPSP,
>    domain servers would need to point to each other); we don't have one. We'd
>    like IPSP not to depend on an "outside" infrastructure, since it provides
>    a "core" service.
>  - Generally speaking, it's a bad idea to have a low level protocol depend
>    on a higher level protocol for its operations (but there are exceptions).
> 
> I think Luis had a couple more reasons written down, but these should be the
> main ones (and I can't seem to find a copy of his slides -- Luis ?)

Well.. I'm not *really* convinced that LDAP is a bad idea. What you have
successfully shown is that it doesn't solve all the problems. However, I'm
yet to see a protocol that would. The last point is a red herring; IP relies
on RIP/OSPF/etc. and ESP relies on IKE.

You would need some method of performing the initial configuration, including
giving the entity an LDAP server address, to fix most of the issues you mention.
If there're undiscovered gateways in the middle, you'd also need IPSP or similar.

Should initial security configuration of devices be a work item for this WG?
There used to be a draft that defined several issues about initial configuration,
but I think it's expired. 

Ari

-- 
Ari Huttunen                   phone: +358 9 859 900
Senior Software Engineer       fax  : +358 9 8599 0452

F-Secure Corporation       http://www.F-Secure.com 

F-Secure products: Integrated Solutions for Enterprise Security

From owner-ipsec-policy  Tue May 23 11:04:32 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id LAA20461
	for ipsec-policy-bks; Tue, 23 May 2000 11:04:32 -0700 (PDT)
Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.192.161])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA20457
	for <ipsec-policy@vpnc.org>; Tue, 23 May 2000 11:04:31 -0700 (PDT)
Received: (from kzm@localhost)
	by foxhound.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id LAA02072;
	Tue, 23 May 2000 11:11:13 -0700 (PDT)
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <200005231811.LAA02072@foxhound.cisco.com>
Subject: Re: Some comments on SPSL
To: Ari.Huttunen@F-Secure.com (Ari Huttunen)
Date: Tue, 23 May 2000 11:11:12 -0700 (PDT)
Cc: ipsec-policy@vpnc.org (IPSP List), lsanchez@bbn.com
In-Reply-To: <392AB734.37B668C5@F-Secure.com> from "Ari Huttunen" at May 23, 2000 07:52:04 PM
X-Mailer: ELM [version 2.5 PL1]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

> > The reasons I can remember:
> >  - One of the mechanisms that may be used to provide security for LDAP is
> >    IPsec (so, chicken and egg problem).
> >  - Access to LDAP directories/servers may be impossible before determining
> >    what firewalls are out there and how to get through them.
> >  - LDAP is not well suited for dynamically discovering firewalls (or other
> >    types of entities) -- it's a directory, thus is as up-to-date as the
> >    information stored there. While one might reasonably expect a local LDAP
> >    server to have accurate information about the local network, it's not
> >    clear how well this'll work across multiple administrative domains.
> >  - LDAP generally requires some infrastructure (and, if it were used in IPSP,
> >    domain servers would need to point to each other); we don't have one. We'd
> >    like IPSP not to depend on an "outside" infrastructure, since it provides
> >    a "core" service.
> >  - Generally speaking, it's a bad idea to have a low level protocol depend
> >    on a higher level protocol for its operations (but there are exceptions).
> > 
> > I think Luis had a couple more reasons written down, but these should be the
> > main ones (and I can't seem to find a copy of his slides -- Luis ?)
> 
> Well.. I'm not *really* convinced that LDAP is a bad idea. 

I suggest it depends on how LDAP is used.  Having network/security
devices issue LDAP queries is OK when your policy is static, but if you
want policy to depend on dynamically-changing network state, then you
need some central intelligence/logic to collect the dynamically-changing
network state, such that the central intelligence/logic recognizes the
conditions on which the changes in policy depend.  LDAP is a storage
updating and querying mechanism; despite all its admirable qualities,
the Directory doesn't contain logic to collect and analyse data.

For example, if you had a policy that installs a special configuration
when two conditions in the network are both happening at the same time.
Suppose one set of devices know the state of condition-1, and a disjoint
set of devices know the state of condition-2, i.e., no individual
device knows that both conditions are happening.  To handle this when
individual devices have LDAP access to a Directory, I think you would
need the first set of devices to be updating the Directory every time
the state of condition-1 changed, and the second set of devices to be
updating the Directory every time the state of condition-2 changed.
You would also need some trigger mechanism to recognize when
condition-1 and condition-2 are both happening (in order to cause all
devices to issue LDAP requests to install the special configuration).
I suggest that if it's possible for the state of condition-1 and/or
condition-2 to change frequently, then the overhead of such a solution
is impractical.  Instead, you need some central intelligence/logic to
collect the state changes and recognize when condition-1 and
condition-2 are both happening.  This central intelligence/logic is
normally considered part of a Policy Server.  It's OK, and possible
valuable, for one (or more) Policy Server(s) to use the Directory as
permanant storage for policies, and therefore use LDAP as the access
mechanism to store/update the policies in the Directory.

Keith.

From owner-ipsec-policy  Tue May 23 12:03:38 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA21838
	for ipsec-policy-bks; Tue, 23 May 2000 12:03:38 -0700 (PDT)
Received: from adk.gr ([135.207.10.123])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA21834
	for <ipsec-policy@vpnc.org>; Tue, 23 May 2000 12:03:36 -0700 (PDT)
Received: from dsl.cis.upenn.edu (localhost [127.0.0.1])
	by adk.gr (8.10.1/8.9.3) with ESMTP id e4NIxKF27184;
	Tue, 23 May 2000 14:59:20 -0400 (EDT)
Message-Id: <200005231859.e4NIxKF27184@adk.gr>
X-Mailer: exmh version 2.0.2 2/24/98
To: Ari Huttunen <Ari.Huttunen@F-Secure.com>
Cc: Yaron Sheffer <yaron.sheffer@radguard.com>,
        IPSP List <ipsec-policy@vpnc.org>, lsanchez@bbn.com
Subject: Re: Some comments on SPSL 
In-reply-to: Your message of "Tue, 23 May 2000 19:52:04 +0300."
             <392AB734.37B668C5@F-Secure.com> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 23 May 2000 14:59:19 -0400
From: "Angelos D. Keromytis" <angelos@dsl.cis.upenn.edu>
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

In message <392AB734.37B668C5@F-Secure.com>, Ari Huttunen writes:
>
>Well.. I'm not *really* convinced that LDAP is a bad idea. What you have
>successfully shown is that it doesn't solve all the problems. However, I'm
>yet to see a protocol that would.

I'll agree with you; however, at the very least a discovery protocol is needed
(LDAP or DNS or whatever else, could in principle provide storage services).

>The last point is a red herring; IP relies on RIP/OSPF/etc. and ESP
>relies on IKE.

Touche', and that's why I said that there are exceptions (and I had exactly
these in mind). This does not mean we shouldn't try to minimize such
dependencies, however.

>You would need some method of performing the initial configuration, including
>giving the entity an LDAP server address, to fix most of the issues you mentio
>n.
>If there're undiscovered gateways in the middle, you'd also need IPSP or simil
>ar.

Exactly right. The question is whether there's a better (for whatever
definition of better) way of then distributing policies, than LDAP.

>Should initial security configuration of devices be a work item for this WG?
>There used to be a draft that defined several issues about initial configurati
>on,
>but I think it's expired. 

I think it should, but I don't remember such a draft.
-Angelos



From owner-ipsec-policy  Tue May 23 12:51:17 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id MAA23105
	for ipsec-policy-bks; Tue, 23 May 2000 12:51:17 -0700 (PDT)
Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23101
	for <ipsec-policy@vpnc.org>; Tue, 23 May 2000 12:51:16 -0700 (PDT)
Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id KCP8VQ5Y; Tue, 23 May 2000 12:58:03 -0700
Message-ID: <392AE2AA.90034028@redcreek.com>
Date: Tue, 23 May 2000 12:57:30 -0700
From: "Scott G. Kelly" <skelly@redcreek.com>
Organization: RedCreek Communications
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Angelos D. Keromytis" <angelos@dsl.cis.upenn.edu>
CC: Ari Huttunen <Ari.Huttunen@F-Secure.com>,
        Yaron Sheffer <yaron.sheffer@radguard.com>,
        IPSP List <ipsec-policy@vpnc.org>, lsanchez@bbn.com
Subject: Re: Some comments on SPSL
References: <200005231859.e4NIxKF27184@adk.gr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

"Angelos D. Keromytis" wrote:
<trimmed...>

>Should initial security configuration of devices be a work item for this WG?
> >There used to be a draft that defined several issues about initial configurati
> >on,
> >but I think it's expired.
> 
> I think it should, but I don't remember such a draft.
> -Angelos

The draft was entitled "Secure Configuration of IPsec-Enabled Devices". 
It was an initial pass, and left a lot of ground uncovered. I still have
a copy if anyone is interested.

Scott

From owner-ipsec-policy  Tue May 23 14:19:11 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA25615
	for ipsec-policy-bks; Tue, 23 May 2000 14:19:11 -0700 (PDT)
Received: from ihemlsrv.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA25594
	for <ipsec-policy@vpnc.org>; Tue, 23 May 2000 14:19:09 -0700 (PDT)
Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1])
	by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA29769
	for <ipsec-policy@vpnc.org>; Tue, 23 May 2000 17:26:15 -0400 (EDT)
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62])
	by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id RAA29743
	for <ipsec-policy@vpnc.org>; Tue, 23 May 2000 17:26:15 -0400 (EDT)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21)
	id <LH82JPVA>; Tue, 23 May 2000 23:26:14 +0200
Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB075E746A@nl0006exch002u.nl.lucent.com>
From: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
To: "Angelos D. Keromytis" <angelos@dsl.cis.upenn.edu>
Cc: ipsec-policy@vpnc.org, Lee Rafalow <rafalow@raleigh.ibm.com>
Subject: RE: Representing policy (was: Some comments on SPSL) 
Date: Tue, 23 May 2000 23:26:10 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Ohhh... and a "Specification Language" does move bitgs around????

Bert

> ----------
> From: 	Angelos D. Keromytis[SMTP:angelos@dsl.cis.upenn.edu]
> Sent: 	Monday, May 22, 2000 11:48 PM
> To: 	Lee Rafalow
> Cc: 	ipsec-policy@vpnc.org
> Subject: 	Re: Representing policy (was: Some comments on SPSL) 
> 
> In message <00dc01bfc419$dd719c20$a6312509@raleigh.ibm.com>, "Lee Rafalow"
> writ
> es:
> >The IPSP WG is embarking on the same early path that the Policy Framework
> WG
> >also followed for a while.  There are two parallel efforts: one to define
> an
> >IPSec policy information model and one to define an IPSec policy
> >specification language.  If done properly these are isomorphic.  The
> >decision made in the Policy Framework WG was to focus on one, an
> information
> >model, rather than on two and on trying to keep them semantically
> >equivalent. To be consistent with the Policy Framework--a desirable and,
> it
> >turns, easily achievable goal--we should also focus on the information
> >model.
> 
> I won't dispute the necessity of an information model; however,
> information
> models won't move the bits around. Thus, we ultimately do need a
> specification
> language :-)
> -Angelos
> 
> 

From owner-ipsec-policy  Tue May 23 20:27:13 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id UAA21028
	for ipsec-policy-bks; Tue, 23 May 2000 20:27:13 -0700 (PDT)
Received: from pzero.sandelman.ottawa.on.ca (pzero.sandelman.ottawa.on.ca [209.151.24.8])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA21019
	for <ipsec-policy@vpnc.org>; Tue, 23 May 2000 20:27:11 -0700 (PDT)
Received: from morden.sandelman.ottawa.on.ca (localhost [127.0.0.1])
	by pzero.sandelman.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA00930;
	Tue, 23 May 2000 23:28:17 -0400 (EDT)
Message-Id: <200005240328.XAA00930@pzero.sandelman.ottawa.on.ca>
To: IPSP List <ipsec-policy@vpnc.org>, lsanchez@bbn.com
Subject: Re: Some comments on SPSL 
In-reply-to: Your message of "Mon, 22 May 2000 17:46:09 EDT."
             <200005222146.e4MLkA109267@adk.gr> 
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 23 May 2000 23:28:17 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

>>>>> "Angelos" == Angelos D Keromytis <angelos@dsl.cis.upenn.edu> writes:
    Angelos> I think Luis had a couple more reasons written down, but these should be the
    Angelos> main ones (and I can't seem to find a copy of his slides -- Luis ?)

  LDAP does not inherently provide for signed objects (needed to provide
auditing of events and for transitivity of trust), you have to include this
in the schema. So one has to include this facility somewhere.
  LDAP just becomes a database in the end, with a complicated index system,
and you still have to provide for a simple transport and discovery mechanism.

    Angelos> As you say, more sophisticated trust relations should be possible -- in the
    Angelos> form of constrained delegation for example. Not only this allows for
    Angelos> decentralized management (I'll refer you to Pekka Nikander's thesis, from '98,
    Angelos> on the subject), but it could also permit seamless mixing of credentials
    Angelos> and policies. Regarding trust relations (and definitions thereof), I'll refer
    Angelos> you to KeyNote (RFC 2704).

  All good reads!

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [



From owner-ipsec-policy  Tue May 23 20:48:38 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id UAA23913
	for ipsec-policy-bks; Tue, 23 May 2000 20:48:38 -0700 (PDT)
Received: from pzero.sandelman.ottawa.on.ca (pzero.sandelman.ottawa.on.ca [209.151.24.8])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA23906
	for <ipsec-policy@vpnc.org>; Tue, 23 May 2000 20:48:37 -0700 (PDT)
Received: from morden.sandelman.ottawa.on.ca (localhost [127.0.0.1])
	by pzero.sandelman.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id XAA01066
	for <ipsec-policy@vpnc.org>; Tue, 23 May 2000 23:49:43 -0400 (EDT)
Message-Id: <200005240349.XAA01066@pzero.sandelman.ottawa.on.ca>
To: IPSP List <ipsec-policy@vpnc.org>
Subject: Re: Some comments on SPSL 
In-reply-to: Your message of "Tue, 23 May 2000 19:52:04 +0300."
             <392AB734.37B668C5@F-Secure.com> 
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 23 May 2000 23:49:43 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

>>>>> "Ari" == Ari Huttunen <Ari.Huttunen@F-Secure.com> writes:
    Ari> You would need some method of performing the initial configuration, including
    Ari> giving the entity an LDAP server address, to fix most of the issues you mention.
    Ari> If there're undiscovered gateways in the middle, you'd also need IPSP or similar.

  Exactly, you still need the discovery protocol.

  I do not believe that any currently deployed VPN scenaries need more than a 
common language to describe the gateway policy and (perhaps) the ability to
retrieve this from a database. However, for even the simplest situation where 
a client wants to create a tunnel that must cross another security gateway to 
reach its gateway (a notebook travelling to behind another entities
firewall), you need IPSP.

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

From owner-ipsec-policy  Wed May 24 04:12:03 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id EAA21029
	for ipsec-policy-bks; Wed, 24 May 2000 04:12:03 -0700 (PDT)
Received: from mail.inter.net.il (parker.inter.net.il [192.116.202.33])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA21018
	for <ipsec-policy@vpnc.org>; Wed, 24 May 2000 04:11:59 -0700 (PDT)
Received: from radguard.com (radguard.com [192.114.169.3])
	by mail.inter.net.il (8.9.3/8.9.3) with SMTP id OAA20324;
	Wed, 24 May 2000 14:13:01 +0300 (IDT)
Received: by radguard.com   (4.1/SMI-4.1)
	id AA26415; Wed, 24 May 00 14:15:56 IDT
Received: from UNKNOWN(192.114.33.100), claiming to be "hellman.radguard.com"
 via SMTP by radguard.com, id smtpdAAAa26410; Wed May 24 14:15:53 2000
Received: from radguard.com by hellman.radguard.com (8.8.8+Sun/SMI-SVR4)
	id NAA08920; Wed, 24 May 2000 13:16:10 +0200 (IST)
Message-Id: <392BC7A2.F2AF309A@radguard.com>
Date: Wed, 24 May 2000 14:14:26 +0200
From: Yaron Sheffer <yaron.sheffer@radguard.com>
Organization: RADGUARD
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
Mime-Version: 1.0
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Cc: IPSP List <ipsec-policy@vpnc.org>
Subject: Re: Some comments on SPSL
References: <200005240349.XAA01066@pzero.sandelman.ottawa.on.ca>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

Michael,

can you give a more concrete example? I fail to see what kind of (reasonable) policy
negotiation can happen between the client, the visited gateway and the home gateway. Seems to
me either the visited gateway allows IKE/IPSec to the home gateway, or it doesn't, period. So
I don't understand the benefit of policy discovery in this scenario.

Thanks,
    Yaron

Michael Richardson wrote:

> >>>>> "Ari" == Ari Huttunen <Ari.Huttunen@F-Secure.com> writes:
>     Ari> You would need some method of performing the initial configuration, including
>     Ari> giving the entity an LDAP server address, to fix most of the issues you mention.
>     Ari> If there're undiscovered gateways in the middle, you'd also need IPSP or similar.
>
>   Exactly, you still need the discovery protocol.
>
>   I do not believe that any currently deployed VPN scenaries need more than a
> common language to describe the gateway policy and (perhaps) the ability to
> retrieve this from a database. However, for even the simplest situation where
> a client wants to create a tunnel that must cross another security gateway to
> reach its gateway (a notebook travelling to behind another entities
> firewall), you need IPSP.
>
> ]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
> ]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
> ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
> ] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [


From owner-ipsec-policy  Wed May 24 09:59:12 2000
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA02700
	for ipsec-policy-bks; Wed, 24 May 2000 09:59:12 -0700 (PDT)
Received: from pzero.sandelman.ottawa.on.ca (pzero.sandelman.ottawa.on.ca [209.151.24.8])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02694
	for <ipsec-policy@vpnc.org>; Wed, 24 May 2000 09:59:10 -0700 (PDT)
Received: from morden.sandelman.ottawa.on.ca (localhost [127.0.0.1])
	by pzero.sandelman.ottawa.on.ca (8.8.8/8.8.8) with ESMTP id MAA06975;
	Wed, 24 May 2000 12:59:22 -0400 (EDT)
Message-Id: <200005241659.MAA06975@pzero.sandelman.ottawa.on.ca>
To: Yaron Sheffer <yaron.sheffer@radguard.com>
cc: IPSP List <ipsec-policy@vpnc.org>
Subject: Re: Some comments on SPSL 
In-reply-to: Your message of "Wed, 24 May 2000 14:14:26 +0200."
             <392BC7A2.F2AF309A@radguard.com> 
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Date: Wed, 24 May 2000 12:59:22 -0400
From: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

>>>>> "Yaron" == Yaron Sheffer <yaron.sheffer@radguard.com> writes:
    Yaron> can you give a more concrete example? I fail to see what kind of
    Yaron> (reasonable) policy negotiation can happen between the client, the
    Yaron> visited gateway and the home gateway. Seems to me either the
    Yaron> visited gateway allows IKE/IPSec to the home gateway, or it
    Yaron> doesn't, period. So I don't understand the benefit of policy

  That is presently true because there is no way to negotiate a more
sophisticated policy and no way to delegate trust. 

  Please see the poorly written, and long expired:
 http://www.sandelman.ottawa.on.ca/SSW/ietf/draft-richardson-ipsec-traversal-cert-01.txt

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

From owner-ipsec-policy  Wed May 24 09:02:16 2000
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA00736
	for ipsec-policy-bks; Wed, 24 May 2000 09:02:16 -0700 (PDT)
Received: from exchange.redcreek.com (mail.redcreek.com [209.125.38.15])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA00732
	for <ipsec-policy@vpnc.org>; Wed, 24 May 2000 09:02:14 -0700 (PDT)
Received: from redcreek.com (host43.redcreek.com [209.218.26.43]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id KCP8VSBH; Wed, 24 May 2000 09:09:21 -0700
Message-ID: <392BFE71.8FF33BAB@redcreek.com>
Date: Wed, 24 May 2000 09:08:17 -0700
From: "Scott G. Kelly" <skelly@redcreek.com>
Organization: RedCreek Communications
X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Ari Huttunen <Ari.Huttunen@F-Secure.com>
CC: ipsec-policy@vpnc.org
Subject: Re: secure config draft (was Re: Some comments on SPSL)
References: <200005231859.e4NIxKF27184@adk.gr> <392AE2AA.90034028@redcreek.com> <392B7907.F6834415@F-Secure.com>
Content-Type: multipart/mixed;
 boundary="------------A4DE9D2A03673C40DBACBCD8"
Sender: owner-ipsec-policy@mail.vpnc.org
Precedence: bulk
List-Archive: <http://www.vpnc.org/ipsec-policy/mail-archive/>
List-ID: <ipsec-policy.vpnc.org>
List-Unsubscribe: <mailto:ipsec-policy-request@vpnc.org?body=unsubscribe>

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

Hi Ari,

Ari Huttunen wrote:
> 
> Yes please. Could you perhaps post the text to this mailing
> list so it gets stored in the archive? Or you can just send
> a copy to me.

I've attached the draft. As I said, it was an initial pass, and there
are numerous things that were left for later edits (which have yet to
occur). 

Scott
--------------A4DE9D2A03673C40DBACBCD8
Content-Type: text/plain; charset=us-ascii;
 name="secconf00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="secconf00.txt"




IPSEC Working Group                         Scott Kelly,
INTERNET-DRAFT                              RedCreek Communications
draft-ietf-ipsec-secconf-00.txt             Mike St. Johns,
Expires in 6 months                         @Home Network
                                            October, 1998


         Secure Configuration of IPsec-Enabled Network Devices


Status of This Memo
   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   Comments on this document should be sent to "ipsec@tis.com", the IETF
   IPsec WG discussion list.

Abstract

   Remote configuration of network devices which implement IPsec-
   related services is desirable as a matter of convenience and of
   scale. In some cases, these devices are installed on a network with
   no prior configuration. In such cases, secure mechanisms for
   bootstrap configuration are required. In this document the associated
   issues are examined, and a multi-tiered approach is proposed from
   which a specific method may be selected based upon the security
   requirements of the environment in which the security device exists.
   While the primary devices considered here are security gateways and
   bump-in-the-wire encryptors, many of the resulting conclusions may
   extend to other devices, including host IPsec implementations.


1. Problem Space Overview

   In general, the level of inconvenience associated with configuring a
   network device is directly proportional to the level of security



Kelly, St. Johns          Expires April, 1999                  [Page 1]

Internet Draft      draft-ietf-ipsec-secconf-00.txt        October, 1998


   desired of the device once configured. To a somewhat lesser degree,
   it is also a function of the environment in which configuration takes
   place, and of whether the device has been previously configured for
   that environment. When initially  deploying an IP security device
   such as a security gateway or a bump-in-the-wire encryptor, there are
   at least two common requirements. First, the device requires the
   assignment of an IP address and associated infrastructure
   information. Second, it requires additional configuration relating to
   the specific device and to local security policy.

   In obtaining the required configuration, one of 3 general scenarios
   may occur: in the first, the device is placed on the network without
   any initial configuration, and DHCP is used to assign an IP address
   and a next boot or configuration server, after which time the
   additional configuration information is retrieved. This is the
   "bootstrap" method. In the second scenario, the device is entirely
   configured offline (on a private network, using a serial port, or in
   some other manner) before being placed on the network. In the third
   scenario, the device is first assigned an IP address and some sort of
   configuration server designation, and then it is placed on the
   network where it obtains additional configuration information from
   the specified server.

   In all of the above cases, network configuration is followed by
   additional security and device configuration, using SNMP, LDAP, or
   some proprietary mechanism. Depending upon a variety of
   circumstances, the security requirements of a particular installation
   will determine which of these methods represents an acceptabl