From owner-ipsec-policy@mail.vpnc.org  Mon Feb  5 11:42:11 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11490
	for <ipsp-archive@odin.ietf.org>; Mon, 5 Feb 2001 11:42:10 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA10084
	for ipsec-policy-bks; Mon, 5 Feb 2001 07:19:03 -0800 (PST)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA10076
	for <ipsec-policy@imc.org>; Mon, 5 Feb 2001 07:19:02 -0800 (PST)
From: Man.M.Li@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f15FQEg28786
	for <ipsec-policy@imc.org>; Mon, 5 Feb 2001 09:26:14 -0600 (CST)
Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T518a54f4a2ac12f255115@davir02nok.americas.nokia.com> for <ipsec-policy@imc.org>;
 Mon, 5 Feb 2001 09:26:14 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <1C0LBSTW>; Mon, 5 Feb 2001 09:21:06 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E460292B884@bseis01nok>
To: ipsec-policy@imc.org
Subject: DMTF SAAction restriction
Date: Mon, 5 Feb 2001 09:16:18 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
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>

Hi,

The DMTF policy model Section 3 first paragraph indicates "The IPsec model
restricts the use of SAActions to an ordered choice rather than a list of
actions to be executed." I am wondering how the following situation would be
handled with this restriction. We had similar discussions among IPsec PIB
authors.

       A (host)===========C(gateway)---B(host)

A and C are connected to public Internet and B is connected to C. To protect
TCP traffic between hosts A and B, an IPsec security association in
transport mode needs to be established between hosts A and B. In addition,
an IPsec security association in tunnel mode may be set up between host A
and the gateway C that protects the LAN host B resides.

In this case, A takes one action to set up an association between A and B.
In addition, A should also set up a tunnel between A and C. From A's point
of view, there are MULTIPLE actions to be taken in that order.

How would you specify a policy to A if you are not allowed to specify a list
of actions to be executed? 


Man Li
Nokia 
5 Wayside Road, Burlington, MA 01803
man.m.li@nokia.com
phone 1-781-993-3923
GSM 1-781-492-2850 


From owner-ipsec-policy@mail.vpnc.org  Mon Feb  5 11:56:38 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11775
	for <ipsp-archive@odin.ietf.org>; Mon, 5 Feb 2001 11:56:38 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA13838
	for ipsec-policy-bks; Mon, 5 Feb 2001 07:54:00 -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 HAA13829
	for <ipsec-policy@imc.org>; Mon, 5 Feb 2001 07:53:59 -0800 (PST)
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.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id QAA05133;
	Mon, 5 Feb 2001 16:02:25 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, 05 Feb 2001 16:01:00 0000 (GMT)
Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <DCS3AXW4>; Mon, 5 Feb 2001 08:00:59 -0800
Message-ID: <794826DE8867D411BAB8009027AE9EB904DD7A19@FMSMSX38>
From: "Jason, Jamie" <jamie.jason@intel.com>
To: "'Man.M.Li@nokia.com'" <Man.M.Li@nokia.com>, ipsec-policy@imc.org
Subject: RE: DMTF SAAction restriction
Date: Mon, 5 Feb 2001 08:00:57 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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>

Lee can correct me if I am wrong on this one, but I believe we had this same
discussion during a conference call between Lee, Eric Vyncke, and myself.  I
believe the solution we came up with was that policy evaluation would first
encounter the transport rule.  Policy evaluation would then search to
determine if there was a tunnel rule that would apply (it would do this
recursively as you may have tunnels in tunnels).  This update probably
hasn't hit the MOF file or whitepaper yet.

Jamie

> -----Original Message-----
> From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
> Sent: Monday, February 05, 2001 7:16 AM
> To: ipsec-policy@imc.org
> Subject: DMTF SAAction restriction
> 
> 
> Hi,
> 
> The DMTF policy model Section 3 first paragraph indicates 
> "The IPsec model
> restricts the use of SAActions to an ordered choice rather 
> than a list of
> actions to be executed." I am wondering how the following 
> situation would be
> handled with this restriction. We had similar discussions 
> among IPsec PIB
> authors.
> 
>        A (host)===========C(gateway)---B(host)
> 
> A and C are connected to public Internet and B is connected 
> to C. To protect
> TCP traffic between hosts A and B, an IPsec security association in
> transport mode needs to be established between hosts A and B. 
> In addition,
> an IPsec security association in tunnel mode may be set up 
> between host A
> and the gateway C that protects the LAN host B resides.
> 
> In this case, A takes one action to set up an association 
> between A and B.
> In addition, A should also set up a tunnel between A and C. 
> From A's point
> of view, there are MULTIPLE actions to be taken in that order.
> 
> How would you specify a policy to A if you are not allowed to 
> specify a list
> of actions to be executed? 
> 
> 
> Man Li
> Nokia 
> 5 Wayside Road, Burlington, MA 01803
> man.m.li@nokia.com
> phone 1-781-993-3923
> GSM 1-781-492-2850 
> 



From owner-ipsec-policy@mail.vpnc.org  Mon Feb  5 13:22:22 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13482
	for <ipsp-archive@odin.ietf.org>; Mon, 5 Feb 2001 13:22:21 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18971
	for ipsec-policy-bks; Mon, 5 Feb 2001 09:23:42 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA18967
	for <ipsec-policy@imc.org>; Mon, 5 Feb 2001 09:23:41 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com
	with Novell_GroupWise; Mon, 05 Feb 2001 10:30:07 -0700
Message-Id: <sa7e80af.066@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Mon, 05 Feb 2001 10:29:57 -0700
From: "Hilarie Orman" <HORMAN@novell.com>
To: <ipsec-policy@imc.org>, <Man.M.Li@nokia.com>
Subject: Re: DMTF SAAction restriction
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 JAA18968
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>
Content-Transfer-Encoding: 8bit

Superb question.  The specification for this kind of policy
 hasn't been defined yet, although the drafts do cover the 
problem.

In practice, I think most implementations assume that
there is a gateway D in A's security domain, and that
the C<->D policy is specificied and enforced at those
gateways.

Of course, the symmetry isn't required.  Consider two cases:

1. The system adminstrators know the topology and
policy in advance.
2. A learns about C dynamically, in the course of
trying to contact host B.

The security gateway discover protocol is supposed
to cover the second case.  This leaves open the question
of how to specify the policy at C, and how A is supposed
to be configured wrt C.

We seem to need a higher level policy that expresses
requirements for composed SA's.  Something like
"the A<->B policies can/must be used with
A<->C gateway policy" and "gateway policies must
be tried before non-gateway policies".

If there are more than two layers of gateway, I'm not
sure that the simple rules cover all the cases.  John Zao
might be able to help formulate sensible coverage
rules for this specification.  John?  Are you listening?

Hilarie

>>> <Man.M.Li@nokia.com> 02/05/01 08:16AM >>>
Hi,

The DMTF policy model Section 3 first paragraph indicates "The IPsec model
restricts the use of SAActions to an ordered choice rather than a list of
actions to be executed." I am wondering how the following situation would be
handled with this restriction. We had similar discussions among IPsec PIB
authors.

       A (host)===========C(gateway)---B(host)

A and C are connected to public Internet and B is connected to C. To protect
TCP traffic between hosts A and B, an IPsec security association in
transport mode needs to be established between hosts A and B. In addition,
an IPsec security association in tunnel mode may be set up between host A
and the gateway C that protects the LAN host B resides.

In this case, A takes one action to set up an association between A and B.
In addition, A should also set up a tunnel between A and C. From A's point
of view, there are MULTIPLE actions to be taken in that order.

How would you specify a policy to A if you are not allowed to specify a list
of actions to be executed? 


Man Li
Nokia 
5 Wayside Road, Burlington, MA 01803
man.m.li@nokia.com 
phone 1-781-993-3923
GSM 1-781-492-2850 



From owner-ipsec-policy@mail.vpnc.org  Mon Feb  5 14:36:45 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15605
	for <ipsp-archive@odin.ietf.org>; Mon, 5 Feb 2001 14:36:45 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id KAA22600
	for ipsec-policy-bks; Mon, 5 Feb 2001 10:25:35 -0800 (PST)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA22596
	for <ipsec-policy@imc.org>; Mon, 5 Feb 2001 10:25:33 -0800 (PST)
From: Man.M.Li@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f15IWkg26526
	for <ipsec-policy@imc.org>; Mon, 5 Feb 2001 12:32:46 -0600 (CST)
Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T518aff96a0ac12f255115@davir02nok.americas.nokia.com>;
 Mon, 5 Feb 2001 12:32:37 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <1C0LBWMY>; Mon, 5 Feb 2001 12:27:29 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E460292B886@bseis01nok>
To: jamie.jason@intel.com, ipsec-policy@imc.org
Subject: RE: DMTF SAAction restriction
Date: Mon, 5 Feb 2001 12:22:36 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
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>

What selectors are you looking for in your second search after the transport
rule? Is it a selector for the already encrypted packets (hence protocol =
ESP, for example) or for the original packets (protocol = tcp)? I see
problems in both cases. In the first case, if there is a rule to set up a
tunnel for ESP packets, we may include some other traffic that are ESP
transport protected but should not be included in the tunnel. In other
words, those traffic should only be transport protected.

In the second case, we cannot reach the second selector for tunnel set up
because first matches will stop the search.

A simple solution would be to remove the restriction and let SAActions to
indicate an ordered list of actions to be executed. 

Man Li
Nokia 
5 Wayside Road, Burlington, MA 01803
man.m.li@nokia.com
phone 1-781-993-3923
GSM 1-781-492-2850 

-----Original Message-----
From: ext Jason, Jamie [mailto:jamie.jason@intel.com]
Sent: Monday, February 05, 2001 11:01 AM
To: 'Man.M.Li@nokia.com'; ipsec-policy@imc.org
Subject: RE: DMTF SAAction restriction


Lee can correct me if I am wrong on this one, but I believe we had this same
discussion during a conference call between Lee, Eric Vyncke, and myself.  I
believe the solution we came up with was that policy evaluation would first
encounter the transport rule.  Policy evaluation would then search to
determine if there was a tunnel rule that would apply (it would do this
recursively as you may have tunnels in tunnels).  This update probably
hasn't hit the MOF file or whitepaper yet.

Jamie

> -----Original Message-----
> From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
> Sent: Monday, February 05, 2001 7:16 AM
> To: ipsec-policy@imc.org
> Subject: DMTF SAAction restriction
> 
> 
> Hi,
> 
> The DMTF policy model Section 3 first paragraph indicates 
> "The IPsec model
> restricts the use of SAActions to an ordered choice rather 
> than a list of
> actions to be executed." I am wondering how the following 
> situation would be
> handled with this restriction. We had similar discussions 
> among IPsec PIB
> authors.
> 
>        A (host)===========C(gateway)---B(host)
> 
> A and C are connected to public Internet and B is connected 
> to C. To protect
> TCP traffic between hosts A and B, an IPsec security association in
> transport mode needs to be established between hosts A and B. 
> In addition,
> an IPsec security association in tunnel mode may be set up 
> between host A
> and the gateway C that protects the LAN host B resides.
> 
> In this case, A takes one action to set up an association 
> between A and B.
> In addition, A should also set up a tunnel between A and C. 
> From A's point
> of view, there are MULTIPLE actions to be taken in that order.
> 
> How would you specify a policy to A if you are not allowed to 
> specify a list
> of actions to be executed? 
> 
> 
> Man Li
> Nokia 
> 5 Wayside Road, Burlington, MA 01803
> man.m.li@nokia.com
> phone 1-781-993-3923
> GSM 1-781-492-2850 
> 


From owner-ipsec-policy@mail.vpnc.org  Mon Feb  5 16:08:36 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17504
	for <ipsp-archive@odin.ietf.org>; Mon, 5 Feb 2001 16:08:36 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id MAA27044
	for ipsec-policy-bks; Mon, 5 Feb 2001 12:03:05 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA27037
	for <ipsec-policy@imc.org>; Mon, 5 Feb 2001 12:03:03 -0800 (PST)
Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com
	with Novell_GroupWise; Mon, 05 Feb 2001 13:09:52 -0700
Message-Id: <sa7ea620.068@prv-mail20.provo.novell.com>
X-Mailer: Novell GroupWise Internet Agent 5.5.5.1
Date: Mon, 05 Feb 2001 13:09:43 -0700
From: "Hilarie Orman" <HORMAN@novell.com>
To: <ipsec-policy@imc.org>, <jamie.jason@intel.com>, <Man.M.Li@nokia.com>
Subject: RE: DMTF SAAction restriction
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 MAA27040
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>
Content-Transfer-Encoding: 8bit

Why would it be erroneous to include a tunnel gratuitously?
Wrt to security, what is the problem?

Hilarie

>>> <Man.M.Li@nokia.com> 02/05/01 11:22AM >>>
What selectors are you looking for in your second search after the transport
rule? Is it a selector for the already encrypted packets (hence protocol =
ESP, for example) or for the original packets (protocol = tcp)? I see
problems in both cases. In the first case, if there is a rule to set up a
tunnel for ESP packets, we may include some other traffic that are ESP
transport protected but should not be included in the tunnel. In other
words, those traffic should only be transport protected.

In the second case, we cannot reach the second selector for tunnel set up
because first matches will stop the search.

A simple solution would be to remove the restriction and let SAActions to
indicate an ordered list of actions to be executed. 

Man Li
Nokia 
5 Wayside Road, Burlington, MA 01803
man.m.li@nokia.com 
phone 1-781-993-3923
GSM 1-781-492-2850 

-----Original Message-----
From: ext Jason, Jamie [mailto:jamie.jason@intel.com] 
Sent: Monday, February 05, 2001 11:01 AM
To: 'Man.M.Li@nokia.com'; ipsec-policy@imc.org 
Subject: RE: DMTF SAAction restriction


Lee can correct me if I am wrong on this one, but I believe we had this same
discussion during a conference call between Lee, Eric Vyncke, and myself.  I
believe the solution we came up with was that policy evaluation would first
encounter the transport rule.  Policy evaluation would then search to
determine if there was a tunnel rule that would apply (it would do this
recursively as you may have tunnels in tunnels).  This update probably
hasn't hit the MOF file or whitepaper yet.

Jamie

> -----Original Message-----
> From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] 
> Sent: Monday, February 05, 2001 7:16 AM
> To: ipsec-policy@imc.org 
> Subject: DMTF SAAction restriction
> 
> 
> Hi,
> 
> The DMTF policy model Section 3 first paragraph indicates 
> "The IPsec model
> restricts the use of SAActions to an ordered choice rather 
> than a list of
> actions to be executed." I am wondering how the following 
> situation would be
> handled with this restriction. We had similar discussions 
> among IPsec PIB
> authors.
> 
>        A (host)===========C(gateway)---B(host)
> 
> A and C are connected to public Internet and B is connected 
> to C. To protect
> TCP traffic between hosts A and B, an IPsec security association in
> transport mode needs to be established between hosts A and B. 
> In addition,
> an IPsec security association in tunnel mode may be set up 
> between host A
> and the gateway C that protects the LAN host B resides.
> 
> In this case, A takes one action to set up an association 
> between A and B.
> In addition, A should also set up a tunnel between A and C. 
> From A's point
> of view, there are MULTIPLE actions to be taken in that order.
> 
> How would you specify a policy to A if you are not allowed to 
> specify a list
> of actions to be executed? 
> 
> 
> Man Li
> Nokia 
> 5 Wayside Road, Burlington, MA 01803
> man.m.li@nokia.com 
> phone 1-781-993-3923
> GSM 1-781-492-2850 
> 



From owner-ipsec-policy@mail.vpnc.org  Mon Feb  5 17:37:34 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19481
	for <ipsp-archive@odin.ietf.org>; Mon, 5 Feb 2001 17:37:34 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id NAA01513
	for ipsec-policy-bks; Mon, 5 Feb 2001 13:17:03 -0800 (PST)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA01503
	for <ipsec-policy@imc.org>; Mon, 5 Feb 2001 13:17:00 -0800 (PST)
From: Man.M.Li@nokia.com
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f15LOCg18570
	for <ipsec-policy@imc.org>; Mon, 5 Feb 2001 15:24:12 -0600 (CST)
Received: from daebh02nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T518b9c6afaac12f2570b1@davir04nok.americas.nokia.com>;
 Mon, 5 Feb 2001 15:23:55 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <1BRS619J>; Mon, 5 Feb 2001 15:23:54 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E460292B88C@bseis01nok>
To: HORMAN@novell.com, ipsec-policy@imc.org, jamie.jason@intel.com,
        Man.M.Li@nokia.com
Subject: RE: DMTF SAAction restriction
Date: Mon, 5 Feb 2001 15:14:01 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
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>

Security per se may not be a problem. But if only a small percentage of
traffic needs multiple nested protection and we end up with giving all the
traffic multiple protections, it would be a waste of resources (e.g.,
processing resource for encryption). Security comes with a price and I
question if service providers or corporate IT managers will be happy about
giving the free ride at the expense of network resources. 

Man Li
Nokia 
5 Wayside Road, Burlington, MA 01803
man.m.li@nokia.com
phone 1-781-993-3923
GSM 1-781-492-2850 

-----Original Message-----
From: ext Hilarie Orman [mailto:HORMAN@novell.com]
Sent: Monday, February 05, 2001 3:10 PM
To: ipsec-policy@imc.org; jamie.jason@intel.com; Man.M.Li@nokia.com
Subject: RE: DMTF SAAction restriction


Why would it be erroneous to include a tunnel gratuitously?
Wrt to security, what is the problem?

Hilarie

>>> <Man.M.Li@nokia.com> 02/05/01 11:22AM >>>
What selectors are you looking for in your second search after the transport
rule? Is it a selector for the already encrypted packets (hence protocol =
ESP, for example) or for the original packets (protocol = tcp)? I see
problems in both cases. In the first case, if there is a rule to set up a
tunnel for ESP packets, we may include some other traffic that are ESP
transport protected but should not be included in the tunnel. In other
words, those traffic should only be transport protected.

In the second case, we cannot reach the second selector for tunnel set up
because first matches will stop the search.

A simple solution would be to remove the restriction and let SAActions to
indicate an ordered list of actions to be executed. 

Man Li
Nokia 
5 Wayside Road, Burlington, MA 01803
man.m.li@nokia.com 
phone 1-781-993-3923
GSM 1-781-492-2850 

-----Original Message-----
From: ext Jason, Jamie [mailto:jamie.jason@intel.com] 
Sent: Monday, February 05, 2001 11:01 AM
To: 'Man.M.Li@nokia.com'; ipsec-policy@imc.org 
Subject: RE: DMTF SAAction restriction


Lee can correct me if I am wrong on this one, but I believe we had this same
discussion during a conference call between Lee, Eric Vyncke, and myself.  I
believe the solution we came up with was that policy evaluation would first
encounter the transport rule.  Policy evaluation would then search to
determine if there was a tunnel rule that would apply (it would do this
recursively as you may have tunnels in tunnels).  This update probably
hasn't hit the MOF file or whitepaper yet.

Jamie

> -----Original Message-----
> From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com] 
> Sent: Monday, February 05, 2001 7:16 AM
> To: ipsec-policy@imc.org 
> Subject: DMTF SAAction restriction
> 
> 
> Hi,
> 
> The DMTF policy model Section 3 first paragraph indicates 
> "The IPsec model
> restricts the use of SAActions to an ordered choice rather 
> than a list of
> actions to be executed." I am wondering how the following 
> situation would be
> handled with this restriction. We had similar discussions 
> among IPsec PIB
> authors.
> 
>        A (host)===========C(gateway)---B(host)
> 
> A and C are connected to public Internet and B is connected 
> to C. To protect
> TCP traffic between hosts A and B, an IPsec security association in
> transport mode needs to be established between hosts A and B. 
> In addition,
> an IPsec security association in tunnel mode may be set up 
> between host A
> and the gateway C that protects the LAN host B resides.
> 
> In this case, A takes one action to set up an association 
> between A and B.
> In addition, A should also set up a tunnel between A and C. 
> From A's point
> of view, there are MULTIPLE actions to be taken in that order.
> 
> How would you specify a policy to A if you are not allowed to 
> specify a list
> of actions to be executed? 
> 
> 
> Man Li
> Nokia 
> 5 Wayside Road, Burlington, MA 01803
> man.m.li@nokia.com 
> phone 1-781-993-3923
> GSM 1-781-492-2850 
> 


From owner-ipsec-policy@mail.vpnc.org  Mon Feb  5 19:04:48 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20920
	for <ipsp-archive@odin.ietf.org>; Mon, 5 Feb 2001 19:04:48 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id OAA05524
	for ipsec-policy-bks; Mon, 5 Feb 2001 14:50:28 -0800 (PST)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05520
	for <ipsec-policy@imc.org>; Mon, 5 Feb 2001 14:50:26 -0800 (PST)
From: Man.M.Li@nokia.com
Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f15Mveg27314
	for <ipsec-policy@imc.org>; Mon, 5 Feb 2001 16:57:40 -0600 (CST)
Received: from daebh02nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T518bf24205ac12f256081@davir03nok.americas.nokia.com> for <ipsec-policy@imc.org>;
 Mon, 5 Feb 2001 16:57:40 -0600
Received: by daebh02nok with Internet Mail Service (5.5.2652.78)
	id <1BRS6GH7>; Mon, 5 Feb 2001 16:57:40 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E460292B88E@bseis01nok>
To: ipsec-policy@imc.org
Subject: DMTF model - credential management ID
Date: Mon, 5 Feb 2001 16:47:47 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
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>

Hi,

With the DMTF model, I am wondering if it is possible to say in a policy
"accept certificates from VeriSign with this matchField and this
matchValue". The matchField and matchValue are already in the credential
filter. But is there a place where we can specify the unique name or ID of a
credential management, e.g., Verisign? 

Man Li
Nokia 
5 Wayside Road, Burlington, MA 01803
man.m.li@nokia.com
phone 1-781-993-3923
GSM 1-781-492-2850 


From owner-ipsec-policy@mail.vpnc.org  Mon Feb  5 20:03:19 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21518
	for <ipsp-archive@odin.ietf.org>; Mon, 5 Feb 2001 20:03:18 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id QAA09109
	for ipsec-policy-bks; Mon, 5 Feb 2001 16:00:31 -0800 (PST)
Received: from wanderer.hardakers.net (IDENT:root@dns2.hardaker.davis.ca.us [168.150.190.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA09102
	for <ipsec-policy@imc.org>; Mon, 5 Feb 2001 16:00:29 -0800 (PST)
Received: (from hardaker@localhost)
	by wanderer.hardakers.net (8.9.3/8.9.3) id QAA31278;
	Mon, 5 Feb 2001 16:10:29 -0800
X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f
To: ipsec-policy <ipsec-policy@imc.org>
Subject: draft-ietf-ipsp-config-policy-model comments
From: Wes Hardaker <wes@hardakers.net>
X-URL: http://dcas.ucdavis.edu/~hardaker
Organization: Network Associates - NAI Labs
X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA
 SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/
 IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4
Date: 05 Feb 2001 16:10:27 -0800
Message-ID: <sdsnls1xjg.fsf@wanderer.hardakers.net>
Lines: 54
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.2 (Notus)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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>

(Some of these could have been brought up before, I didn't check the archives.)

1) The definitions for SARule, SAAction, SAStaticAction,
   SANegotiationAction and IPsecAction contain the following sentence:

     "Although the class is concrete, is MUST not be instantiated."

   I suspect you might as well use the fully-capitalized wording for
   "must not":

     "Although the class is concrete, is MUST NOT be instantiated."
                                              ^^^

2) Regarding the above, why not just make the classes abstract to
   ensure they're not instantiated?

3) Some of the objects (EG, IKERuleOverridePoint) contain high to low
   precedence (higher numbers have a larger precedence) and others
   (EG, IPsecPolicyGroupInPolicyGroup's "Precedence" attribute) have
   low to high precedence where lower numbers have a larger
   precedence.  Although not important from a technical prospective,
   it would make more sense to have this be consistent across the
   entire document unless there is a reason its done like it is.

4) Section 5.12 specifies the property of FQDNFilterEntry as "Name"
   but section 5.12.1 which describes the property has a name of
   "Address" instead of "Name".

5) Section 6.2 which describes "The Class SAStaticAction" says that it
   "serves as the base class for IKE and IPsec actions that
   do not require negotiation.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^

   But yet, section 6.2.1 "The property LifetimeSeconds" describes the
   property value with "A non-zero value is typically used in
   conjunction with fallback actions performed when there is a
   negotiation failure of some sort."
   ^^^^^^^^^^^^^^^^^^^

   To lead away from possible confusion, I'd suggest rewording the
   above to something like: "A non-zero value is typically used in
   conjunction with fallback action from a failed SANegotiationAction
   to an SAStaticAction after a negotiation failure of some sort has
   taken place."

6) section 6.7.3, 6.7.4 and 6.11.1 say that "A random value may be
   added...".  I think I'd suggest making that "may" be a "SHOULD" and
   if not that then possibly a "MAY".

-- 
Wes Hardaker
NAI Labs
Network Associates


From owner-ipsec-policy@mail.vpnc.org  Tue Feb  6 10:27:48 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18010
	for <ipsp-archive@odin.ietf.org>; Tue, 6 Feb 2001 10:27:47 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id GAA09648
	for ipsec-policy-bks; Tue, 6 Feb 2001 06:12:59 -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 GAA09643
	for <ipsec-policy@vpnc.org>; Tue, 6 Feb 2001 06:12:57 -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 JAA24972
	for <ipsec-policy@vpnc.org>; Tue, 6 Feb 2001 09:19:42 -0500
Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA29542;
	Tue, 6 Feb 2001 09:19:43 -0500
Message-ID: <001a01c09047$a3d818e0$11312509@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: <policy@raleigh.ibm.com>
Cc: <ipsec-policy@vpnc.org>
References: <20010206090932.55336.qmail@web10509.mail.yahoo.com>
Subject: IPSP Use of FilterEntry (Re: Preliminary results from PCIMe technical meeting, 1/24/01 - 1/26/01)
Date: Tue, 6 Feb 2001 09:18:12 -0500
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.50.4522.1200
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200
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>
Content-Transfer-Encoding: 7bit

Mahadevan, There has been some discussion on this list and, of course, on
the IPSP list but there's no conclusive answer as yet.  Jamie and I have
discussed this and we'll leave the IPsec Config Policy Model (ICPM, aka
ICIM) as it is for now.  The reason is primarily one of timing: the PCIMe
draft is being written right now and ICPM needs to be updated in time for
the March meeting.  We need stability in the technical content and these
kind of representation details are really secondary right now.

That said, in the long run whether we use FilterEntry or
PolicyVariable/PolicyValue pairs is tbd, but the answer will lie in how the
IPSP WG sees the trade-offs between common policy representation vs. a model
that's close to its device-level implementation.

Lee

----- Original Message -----
From: "Mahadevan Iyer" <iyermahadevan@yahoo.com>
To: <policy@raleigh.ibm.com>
Sent: Tuesday, February 06, 2001 4:09 AM
Subject: Re: Preliminary results from PCIMe technical meeting, 1/24/01 -
1/26/01


> --- John Strassner <jstrassn@cisco.com> wrote:
> > This last sentence is misleading. One can easily
> > define
> > equivalences between the
> > FilterEntry.MatchConditionType and
> > the PolicyVariable classes and also between the
> > FilterEntry.MatchConditionValue and the PolicyValue
> > classes.
> > The perception that PolicyVariables and PolicyValues
> > somehow
> > break FilterEntries is just plain wrong.
>
> Can someone summarize the reasons why we will continue
> to have the notion of FilterEntry in IPSP drafts. If
> the reasons have been summarized in a thread, a
> pointer to the thread would be sufficient.
>
> Thanks
>
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - Buy the things you want at great prices.
> http://auctions.yahoo.com/
>



From owner-ipsec-policy@mail.vpnc.org  Tue Feb  6 10:29:10 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18049
	for <ipsp-archive@odin.ietf.org>; Tue, 6 Feb 2001 10:29:09 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id GAA10025
	for ipsec-policy-bks; Tue, 6 Feb 2001 06:19:50 -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 GAA10021
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 06:19:49 -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 JAA24266
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 09:26:34 -0500
Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA31966
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 09:26:36 -0500
Message-ID: <003b01c09048$99f83700$11312509@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: <ipsec-policy@imc.org>
References: <B9CFA6CE8FFDD211A1FB0008C7894E460292B88E@bseis01nok>
Subject: Re: DMTF model - credential management ID
Date: Tue, 6 Feb 2001 09:25:05 -0500
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.50.4522.1200
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200
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>
Content-Transfer-Encoding: 7bit

The model has two controls with respect to certs:  the AcceptCredentialsFrom
association specifies which credential management services are in the trust
hierarchies; the CredentialFilterEntry permits filtering on any of the
values in a cert.

Lee
----- Original Message -----
From: <Man.M.Li@nokia.com>
To: <ipsec-policy@imc.org>
Sent: Monday, February 05, 2001 5:47 PM
Subject: DMTF model - credential management ID


> Hi,
>
> With the DMTF model, I am wondering if it is possible to say in a policy
> "accept certificates from VeriSign with this matchField and this
> matchValue". The matchField and matchValue are already in the credential
> filter. But is there a place where we can specify the unique name or ID of
a
> credential management, e.g., Verisign?
>
> Man Li
> Nokia
> 5 Wayside Road, Burlington, MA 01803
> man.m.li@nokia.com
> phone 1-781-993-3923
> GSM 1-781-492-2850
>



From owner-ipsec-policy@mail.vpnc.org  Tue Feb  6 11:03:20 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19525
	for <ipsp-archive@odin.ietf.org>; Tue, 6 Feb 2001 11:03:19 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id GAA11393
	for ipsec-policy-bks; Tue, 6 Feb 2001 06:43:03 -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 GAA11388
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 06:43:01 -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 JAA39674
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 09:49:46 -0500
Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA20468
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 09:49:48 -0500
Message-ID: <004201c0904b$d7bfebc0$11312509@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: <ipsec-policy@imc.org>
References: <B9CFA6CE8FFDD211A1FB0008C7894E460292B88C@bseis01nok>
Subject: Re: DMTF SAAction restriction
Date: Tue, 6 Feb 2001 09:48:16 -0500
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.50.4522.1200
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200
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>
Content-Transfer-Encoding: 7bit

The approach that we've thought through so far would use your first example
to set up the tunnel.  We could explore your suggestion to add a sematic to
the action list, but that complicates it significantly.  We already have
semantics for the initiator and responder that are variations on "try until
one succeeds."  Recall that for the initiator it's try the first one, if
that fails try the second, etc.  For the responder it's a little more
complicated: respond from the first action that is appropriate to the
request (this allows a single rule to deal with both aggressive and main
mode requests).

To add semantics for "do ordered list of actions" would require a fairly
complicated grammar for grouping actions into execution strategy groups (do
all, do first successful).

A way out of this might be to use the structured rules being proposed in the
PCIM Extensions draft (currently being written) but that'll have to wait
until we have a PCIMe draft to discuss.

Lee
----- Original Message -----
From: <Man.M.Li@nokia.com>
To: <HORMAN@novell.com>; <ipsec-policy@imc.org>; <jamie.jason@intel.com>;
<Man.M.Li@nokia.com>
Sent: Monday, February 05, 2001 4:14 PM
Subject: RE: DMTF SAAction restriction


> Security per se may not be a problem. But if only a small percentage of
> traffic needs multiple nested protection and we end up with giving all the
> traffic multiple protections, it would be a waste of resources (e.g.,
> processing resource for encryption). Security comes with a price and I
> question if service providers or corporate IT managers will be happy about
> giving the free ride at the expense of network resources.
>
> Man Li
> Nokia
> 5 Wayside Road, Burlington, MA 01803
> man.m.li@nokia.com
> phone 1-781-993-3923
> GSM 1-781-492-2850
>
> -----Original Message-----
> From: ext Hilarie Orman [mailto:HORMAN@novell.com]
> Sent: Monday, February 05, 2001 3:10 PM
> To: ipsec-policy@imc.org; jamie.jason@intel.com; Man.M.Li@nokia.com
> Subject: RE: DMTF SAAction restriction
>
>
> Why would it be erroneous to include a tunnel gratuitously?
> Wrt to security, what is the problem?
>
> Hilarie
>
> >>> <Man.M.Li@nokia.com> 02/05/01 11:22AM >>>
> What selectors are you looking for in your second search after the
transport
> rule? Is it a selector for the already encrypted packets (hence protocol =
> ESP, for example) or for the original packets (protocol = tcp)? I see
> problems in both cases. In the first case, if there is a rule to set up a
> tunnel for ESP packets, we may include some other traffic that are ESP
> transport protected but should not be included in the tunnel. In other
> words, those traffic should only be transport protected.
>
> In the second case, we cannot reach the second selector for tunnel set up
> because first matches will stop the search.
>
> A simple solution would be to remove the restriction and let SAActions to
> indicate an ordered list of actions to be executed.
>
> Man Li
> Nokia
> 5 Wayside Road, Burlington, MA 01803
> man.m.li@nokia.com
> phone 1-781-993-3923
> GSM 1-781-492-2850
>
> -----Original Message-----
> From: ext Jason, Jamie [mailto:jamie.jason@intel.com]
> Sent: Monday, February 05, 2001 11:01 AM
> To: 'Man.M.Li@nokia.com'; ipsec-policy@imc.org
> Subject: RE: DMTF SAAction restriction
>
>
> Lee can correct me if I am wrong on this one, but I believe we had this
same
> discussion during a conference call between Lee, Eric Vyncke, and myself.
I
> believe the solution we came up with was that policy evaluation would
first
> encounter the transport rule.  Policy evaluation would then search to
> determine if there was a tunnel rule that would apply (it would do this
> recursively as you may have tunnels in tunnels).  This update probably
> hasn't hit the MOF file or whitepaper yet.
>
> Jamie
>
> > -----Original Message-----
> > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
> > Sent: Monday, February 05, 2001 7:16 AM
> > To: ipsec-policy@imc.org
> > Subject: DMTF SAAction restriction
> >
> >
> > Hi,
> >
> > The DMTF policy model Section 3 first paragraph indicates
> > "The IPsec model
> > restricts the use of SAActions to an ordered choice rather
> > than a list of
> > actions to be executed." I am wondering how the following
> > situation would be
> > handled with this restriction. We had similar discussions
> > among IPsec PIB
> > authors.
> >
> >        A (host)===========C(gateway)---B(host)
> >
> > A and C are connected to public Internet and B is connected
> > to C. To protect
> > TCP traffic between hosts A and B, an IPsec security association in
> > transport mode needs to be established between hosts A and B.
> > In addition,
> > an IPsec security association in tunnel mode may be set up
> > between host A
> > and the gateway C that protects the LAN host B resides.
> >
> > In this case, A takes one action to set up an association
> > between A and B.
> > In addition, A should also set up a tunnel between A and C.
> > From A's point
> > of view, there are MULTIPLE actions to be taken in that order.
> >
> > How would you specify a policy to A if you are not allowed to
> > specify a list
> > of actions to be executed?
> >
> >
> > Man Li
> > Nokia
> > 5 Wayside Road, Burlington, MA 01803
> > man.m.li@nokia.com
> > phone 1-781-993-3923
> > GSM 1-781-492-2850
> >



From owner-ipsec-policy@mail.vpnc.org  Tue Feb  6 11:46:14 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21794
	for <ipsp-archive@odin.ietf.org>; Tue, 6 Feb 2001 11:46:11 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id HAA14508
	for ipsec-policy-bks; Tue, 6 Feb 2001 07:31:58 -0800 (PST)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14502
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 07:31:55 -0800 (PST)
Received: from brussels.cisco.com (brussels.cisco.com [144.254.15.68])
	by ogma.cisco.com (Postfix) with ESMTP
	id A3DCE17B; Tue,  6 Feb 2001 16:38:37 +0100 (MET)
Received: from evyncke-8kcdt.cisco.com (evyncke-isdn-home.cisco.com [10.49.1.170])
	by brussels.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id QAA06707;
	Tue, 6 Feb 2001 16:38:33 +0100 (MET)
Message-Id: <4.3.2.7.2.20010206161617.00baaf00@brussels.cisco.com>
X-Sender: evyncke@brussels.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 06 Feb 2001 16:38:32 +0100
To: "Jason, Jamie" <jamie.jason@intel.com>,
        "'Man.M.Li@nokia.com'" <Man.M.Li@nokia.com>, ipsec-policy@imc.org
From: Eric Vyncke <evyncke@cisco.com>
Subject: RE: DMTF SAAction restriction
In-Reply-To: <794826DE8867D411BAB8009027AE9EB904DD7A19@FMSMSX38>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id HAA14505
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>
X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id HAA14508
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA21794

Instead of having a list of SAActions for a single SARule, multiple
SARules will be used (with a single SAAction for each SARule).
This mandates of course a careful order of the SARules (putting
the transport ones before the tunnel ones).

The DMTF WP has still to be updated but the process can be described
as:

1) IP traffic from host A to host B triggers a SAAction to build
   an IPSec transport mode SA

2) this obviously generates some IKE traffic from host A to host B

3) the SARules are then recursively checked

4) IKE traffic from host A to host B triggers another SAAction
  (whose filter is set to IKE and ESP traffic from host A to the
   domain protected by C) to build an IPSec tunnel mode SA

A similar process needs to be applied for the SecurityAssociation and
FilterOfSecurityAction once the SA have been built.

This is in plain agreement with RFC2401 section 4.5 (case 4) where
it is stated that: 'the sender MUST apply the transport header before 
the tunnel header´.

With this scheme, you should even be able to cope with extreme designs
like:

host A --- SG1---SG2---SG3---host B
! !!!!=======!     !     !      !
! !!!==============!     !      !
! !!=====================!      !
!===============================

where the transport mode A-B is included in tunnel mode A-SG3 itself in
tunnel mode A-SG2, ...

-eric

At 08:00 5/02/01 -0800, Jason, Jamie wrote:
>Lee can correct me if I am wrong on this one, but I believe we had this same
>discussion during a conference call between Lee, Eric Vyncke, and myself.  I
>believe the solution we came up with was that policy evaluation would first
>encounter the transport rule.  Policy evaluation would then search to
>determine if there was a tunnel rule that would apply (it would do this
>recursively as you may have tunnels in tunnels).  This update probably
>hasn't hit the MOF file or whitepaper yet.
>
>Jamie
>
>> -----Original Message-----
>> From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
>> Sent: Monday, February 05, 2001 7:16 AM
>> To: ipsec-policy@imc.org
>> Subject: DMTF SAAction restriction
>> 
>> 
>> Hi,
>> 
>> The DMTF policy model Section 3 first paragraph indicates 
>> "The IPsec model
>> restricts the use of SAActions to an ordered choice rather 
>> than a list of
>> actions to be executed." I am wondering how the following 
>> situation would be
>> handled with this restriction. We had similar discussions 
>> among IPsec PIB
>> authors.
>> 
>>        A (host)===========C(gateway)---B(host)
>> 
>> A and C are connected to public Internet and B is connected 
>> to C. To protect
>> TCP traffic between hosts A and B, an IPsec security association in
>> transport mode needs to be established between hosts A and B. 
>> In addition,
>> an IPsec security association in tunnel mode may be set up 
>> between host A
>> and the gateway C that protects the LAN host B resides.
>> 
>> In this case, A takes one action to set up an association 
>> between A and B.
>> In addition, A should also set up a tunnel between A and C. 
>> From A's point
>> of view, there are MULTIPLE actions to be taken in that order.
>> 
>> How would you specify a policy to A if you are not allowed to 
>> specify a list
>> of actions to be executed? 
>> 
>> 
>> Man Li
>> Nokia 
>> 5 Wayside Road, Burlington, MA 01803
>> man.m.li@nokia.com
>> phone 1-781-993-3923
>> GSM 1-781-492-2850 
>> 

Eric Vyncke                        
Distinguished Engineer             Cisco Systems EMEA
Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
E-mail: evyncke@cisco.com          Mobile: +32-475-312.458
PGP Key available on request       MOBILE HAS CHANGED ON 11th November 2000



From owner-ipsec-policy@mail.vpnc.org  Tue Feb  6 11:48:29 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21891
	for <ipsp-archive@odin.ietf.org>; Tue, 6 Feb 2001 11:48:28 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id HAA14650
	for ipsec-policy-bks; Tue, 6 Feb 2001 07:33:09 -0800 (PST)
Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14643
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 07:33:08 -0800 (PST)
From: Man.M.Li@nokia.com
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f16FfVw18067
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 09:41:51 -0600 (CST)
Received: from daebh01nok.americas.nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T518f87fb2aac12f254074@davir01nok.americas.nokia.com> for <ipsec-policy@imc.org>;
 Tue, 6 Feb 2001 09:40:04 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <1C0LCAC2>; Tue, 6 Feb 2001 09:34:56 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E460292B88F@bseis01nok>
To: ipsec-policy@imc.org
Subject: RE: DMTF SAAction restriction
Date: Tue, 6 Feb 2001 09:30:08 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
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>

Is the "try until one succeeds" being described in any RFCs or is it only
ONE way of implementation? I recall ISAKMP allow initiator to propose
multiple proposals and multiple transforms for responder to choose from. But
I do not recall seeing this "try until one succeeds". 


Man Li
Nokia 
5 Wayside Road, Burlington, MA 01803
man.m.li@nokia.com
phone 1-781-993-3923
GSM 1-781-492-2850 

-----Original Message-----
From: ext Lee Rafalow [mailto:rafalow@raleigh.ibm.com]
Sent: Tuesday, February 06, 2001 9:48 AM
To: ipsec-policy@imc.org
Subject: Re: DMTF SAAction restriction


The approach that we've thought through so far would use your first example
to set up the tunnel.  We could explore your suggestion to add a sematic to
the action list, but that complicates it significantly.  We already have
semantics for the initiator and responder that are variations on "try until
one succeeds."  Recall that for the initiator it's try the first one, if
that fails try the second, etc.  For the responder it's a little more
complicated: respond from the first action that is appropriate to the
request (this allows a single rule to deal with both aggressive and main
mode requests).


To add semantics for "do ordered list of actions" would require a fairly
complicated grammar for grouping actions into execution strategy groups (do
all, do first successful).

A way out of this might be to use the structured rules being proposed in the
PCIM Extensions draft (currently being written) but that'll have to wait
until we have a PCIMe draft to discuss.

Lee
----- Original Message -----
From: <Man.M.Li@nokia.com>
To: <HORMAN@novell.com>; <ipsec-policy@imc.org>; <jamie.jason@intel.com>;
<Man.M.Li@nokia.com>
Sent: Monday, February 05, 2001 4:14 PM
Subject: RE: DMTF SAAction restriction


> Security per se may not be a problem. But if only a small percentage of
> traffic needs multiple nested protection and we end up with giving all the
> traffic multiple protections, it would be a waste of resources (e.g.,
> processing resource for encryption). Security comes with a price and I
> question if service providers or corporate IT managers will be happy about
> giving the free ride at the expense of network resources.
>
> Man Li
> Nokia
> 5 Wayside Road, Burlington, MA 01803
> man.m.li@nokia.com
> phone 1-781-993-3923
> GSM 1-781-492-2850
>
> -----Original Message-----
> From: ext Hilarie Orman [mailto:HORMAN@novell.com]
> Sent: Monday, February 05, 2001 3:10 PM
> To: ipsec-policy@imc.org; jamie.jason@intel.com; Man.M.Li@nokia.com
> Subject: RE: DMTF SAAction restriction
>
>
> Why would it be erroneous to include a tunnel gratuitously?
> Wrt to security, what is the problem?
>
> Hilarie
>
> >>> <Man.M.Li@nokia.com> 02/05/01 11:22AM >>>
> What selectors are you looking for in your second search after the
transport
> rule? Is it a selector for the already encrypted packets (hence protocol =
> ESP, for example) or for the original packets (protocol = tcp)? I see
> problems in both cases. In the first case, if there is a rule to set up a
> tunnel for ESP packets, we may include some other traffic that are ESP
> transport protected but should not be included in the tunnel. In other
> words, those traffic should only be transport protected.
>
> In the second case, we cannot reach the second selector for tunnel set up
> because first matches will stop the search.
>
> A simple solution would be to remove the restriction and let SAActions to
> indicate an ordered list of actions to be executed.
>
> Man Li
> Nokia
> 5 Wayside Road, Burlington, MA 01803
> man.m.li@nokia.com
> phone 1-781-993-3923
> GSM 1-781-492-2850
>
> -----Original Message-----
> From: ext Jason, Jamie [mailto:jamie.jason@intel.com]
> Sent: Monday, February 05, 2001 11:01 AM
> To: 'Man.M.Li@nokia.com'; ipsec-policy@imc.org
> Subject: RE: DMTF SAAction restriction
>
>
> Lee can correct me if I am wrong on this one, but I believe we had this
same
> discussion during a conference call between Lee, Eric Vyncke, and myself.
I
> believe the solution we came up with was that policy evaluation would
first
> encounter the transport rule.  Policy evaluation would then search to
> determine if there was a tunnel rule that would apply (it would do this
> recursively as you may have tunnels in tunnels).  This update probably
> hasn't hit the MOF file or whitepaper yet.
>
> Jamie
>
> > -----Original Message-----
> > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
> > Sent: Monday, February 05, 2001 7:16 AM
> > To: ipsec-policy@imc.org
> > Subject: DMTF SAAction restriction
> >
> >
> > Hi,
> >
> > The DMTF policy model Section 3 first paragraph indicates
> > "The IPsec model
> > restricts the use of SAActions to an ordered choice rather
> > than a list of
> > actions to be executed." I am wondering how the following
> > situation would be
> > handled with this restriction. We had similar discussions
> > among IPsec PIB
> > authors.
> >
> >        A (host)===========C(gateway)---B(host)
> >
> > A and C are connected to public Internet and B is connected
> > to C. To protect
> > TCP traffic between hosts A and B, an IPsec security association in
> > transport mode needs to be established between hosts A and B.
> > In addition,
> > an IPsec security association in tunnel mode may be set up
> > between host A
> > and the gateway C that protects the LAN host B resides.
> >
> > In this case, A takes one action to set up an association
> > between A and B.
> > In addition, A should also set up a tunnel between A and C.
> > From A's point
> > of view, there are MULTIPLE actions to be taken in that order.
> >
> > How would you specify a policy to A if you are not allowed to
> > specify a list
> > of actions to be executed?
> >
> >
> > Man Li
> > Nokia
> > 5 Wayside Road, Burlington, MA 01803
> > man.m.li@nokia.com
> > phone 1-781-993-3923
> > GSM 1-781-492-2850
> >


From owner-ipsec-policy@mail.vpnc.org  Tue Feb  6 12:50:09 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24981
	for <ipsp-archive@odin.ietf.org>; Tue, 6 Feb 2001 12:50:07 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA18803
	for ipsec-policy-bks; Tue, 6 Feb 2001 08:23:16 -0800 (PST)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18799
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 08:23:15 -0800 (PST)
From: Man.M.Li@nokia.com
Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f16GUNg29358
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 10:30:33 -0600 (CST)
Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T518fb6092aac12f256081@davir03nok.americas.nokia.com>;
 Tue, 6 Feb 2001 10:30:22 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <1C0LCBCS>; Tue, 6 Feb 2001 10:25:14 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E460292B891@bseis01nok>
To: evyncke@cisco.com, ipsec-policy@imc.org
Subject: RE: DMTF SAAction restriction
Date: Tue, 6 Feb 2001 10:20:26 -0600 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
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>

Correct me if I am wrong. But why cannot the three tries be bundled into one
action with multiple proposals? My understanding is that the purpose of
having multiple proposals is exactly such that if the responder cannot
accept the first one (hence fails), it has the choice to choose another one
from the list. 

Man Li
Nokia 
5 Wayside Road, Burlington, MA 01803
man.m.li@nokia.com
phone 1-781-993-3923
GSM 1-781-492-2850 

-----Original Message-----
From: ext Eric Vyncke [mailto:evyncke@cisco.com]
Sent: Tuesday, February 06, 2001 11:17 AM
To: Man.M.Li@nokia.com; ipsec-policy@imc.org
Subject: RE: DMTF SAAction restriction


We talked about different things:

1) when ISAKMP is trying to build a SA, it sends multiple proposals

2) in the DMTF model, for one data traffic pattern, multiple actions are
tried
until success:
    a) let's try ISAKMP with 3DES+RSA or 3DES-pre-shared with SG1
    b) if it fails, let's try ISAKMP with 3DES+RSA or 3DES-pre-shared with
SG2
    c) if it fails, let's try DES-pre-shared with SG3

Obviously, the DMTF model allows the configuration of a complex IKE proposal
(see IKEProposal class which is associated to SANegotiationAction).

Hope this helps

-eric

At 09:30 6/02/01 -0600, Man.M.Li@nokia.com wrote:
>Is the "try until one succeeds" being described in any RFCs or is it only
>ONE way of implementation? I recall ISAKMP allow initiator to propose
>multiple proposals and multiple transforms for responder to choose from.
But
>I do not recall seeing this "try until one succeeds". 
>
>
>Man Li
>Nokia 
>5 Wayside Road, Burlington, MA 01803
>man.m.li@nokia.com
>phone 1-781-993-3923
>GSM 1-781-492-2850 
>
>-----Original Message-----
>From: ext Lee Rafalow [mailto:rafalow@raleigh.ibm.com]
>Sent: Tuesday, February 06, 2001 9:48 AM
>To: ipsec-policy@imc.org
>Subject: Re: DMTF SAAction restriction
>
>
>The approach that we've thought through so far would use your first example
>to set up the tunnel.  We could explore your suggestion to add a sematic to
>the action list, but that complicates it significantly.  We already have
>semantics for the initiator and responder that are variations on "try until
>one succeeds."  Recall that for the initiator it's try the first one, if
>that fails try the second, etc.  For the responder it's a little more
>complicated: respond from the first action that is appropriate to the
>request (this allows a single rule to deal with both aggressive and main
>mode requests).
>
>
>To add semantics for "do ordered list of actions" would require a fairly
>complicated grammar for grouping actions into execution strategy groups (do
>all, do first successful).
>
>A way out of this might be to use the structured rules being proposed in
the
>PCIM Extensions draft (currently being written) but that'll have to wait
>until we have a PCIMe draft to discuss.
>
>Lee
>----- Original Message -----
>From: <Man.M.Li@nokia.com>
>To: <HORMAN@novell.com>; <ipsec-policy@imc.org>; <jamie.jason@intel.com>;
><Man.M.Li@nokia.com>
>Sent: Monday, February 05, 2001 4:14 PM
>Subject: RE: DMTF SAAction restriction
>
>
>> Security per se may not be a problem. But if only a small percentage of
>> traffic needs multiple nested protection and we end up with giving all
the
>> traffic multiple protections, it would be a waste of resources (e.g.,
>> processing resource for encryption). Security comes with a price and I
>> question if service providers or corporate IT managers will be happy
about
>> giving the free ride at the expense of network resources.
>>
>> Man Li
>> Nokia
>> 5 Wayside Road, Burlington, MA 01803
>> man.m.li@nokia.com
>> phone 1-781-993-3923
>> GSM 1-781-492-2850
>>
>> -----Original Message-----
>> From: ext Hilarie Orman [mailto:HORMAN@novell.com]
>> Sent: Monday, February 05, 2001 3:10 PM
>> To: ipsec-policy@imc.org; jamie.jason@intel.com; Man.M.Li@nokia.com
>> Subject: RE: DMTF SAAction restriction
>>
>>
>> Why would it be erroneous to include a tunnel gratuitously?
>> Wrt to security, what is the problem?
>>
>> Hilarie
>>
>> >>> <Man.M.Li@nokia.com> 02/05/01 11:22AM >>>
>> What selectors are you looking for in your second search after the
>transport
>> rule? Is it a selector for the already encrypted packets (hence protocol
=
>> ESP, for example) or for the original packets (protocol = tcp)? I see
>> problems in both cases. In the first case, if there is a rule to set up a
>> tunnel for ESP packets, we may include some other traffic that are ESP
>> transport protected but should not be included in the tunnel. In other
>> words, those traffic should only be transport protected.
>>
>> In the second case, we cannot reach the second selector for tunnel set up
>> because first matches will stop the search.
>>
>> A simple solution would be to remove the restriction and let SAActions to
>> indicate an ordered list of actions to be executed.
>>
>> Man Li
>> Nokia
>> 5 Wayside Road, Burlington, MA 01803
>> man.m.li@nokia.com
>> phone 1-781-993-3923
>> GSM 1-781-492-2850
>>
>> -----Original Message-----
>> From: ext Jason, Jamie [mailto:jamie.jason@intel.com]
>> Sent: Monday, February 05, 2001 11:01 AM
>> To: 'Man.M.Li@nokia.com'; ipsec-policy@imc.org
>> Subject: RE: DMTF SAAction restriction
>>
>>
>> Lee can correct me if I am wrong on this one, but I believe we had this
>same
>> discussion during a conference call between Lee, Eric Vyncke, and myself.
>I
>> believe the solution we came up with was that policy evaluation would
>first
>> encounter the transport rule.  Policy evaluation would then search to
>> determine if there was a tunnel rule that would apply (it would do this
>> recursively as you may have tunnels in tunnels).  This update probably
>> hasn't hit the MOF file or whitepaper yet.
>>
>> Jamie
>>
>> > -----Original Message-----
>> > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
>> > Sent: Monday, February 05, 2001 7:16 AM
>> > To: ipsec-policy@imc.org
>> > Subject: DMTF SAAction restriction
>> >
>> >
>> > Hi,
>> >
>> > The DMTF policy model Section 3 first paragraph indicates
>> > "The IPsec model
>> > restricts the use of SAActions to an ordered choice rather
>> > than a list of
>> > actions to be executed." I am wondering how the following
>> > situation would be
>> > handled with this restriction. We had similar discussions
>> > among IPsec PIB
>> > authors.
>> >
>> >        A (host)===========C(gateway)---B(host)
>> >
>> > A and C are connected to public Internet and B is connected
>> > to C. To protect
>> > TCP traffic between hosts A and B, an IPsec security association in
>> > transport mode needs to be established between hosts A and B.
>> > In addition,
>> > an IPsec security association in tunnel mode may be set up
>> > between host A
>> > and the gateway C that protects the LAN host B resides.
>> >
>> > In this case, A takes one action to set up an association
>> > between A and B.
>> > In addition, A should also set up a tunnel between A and C.
>> > From A's point
>> > of view, there are MULTIPLE actions to be taken in that order.
>> >
>> > How would you specify a policy to A if you are not allowed to
>> > specify a list
>> > of actions to be executed?
>> >
>> >
>> > Man Li
>> > Nokia
>> > 5 Wayside Road, Burlington, MA 01803
>> > man.m.li@nokia.com
>> > phone 1-781-993-3923
>> > GSM 1-781-492-2850
>> > 

Eric Vyncke                        
Distinguished Engineer             Cisco Systems EMEA
Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
E-mail: evyncke@cisco.com          Mobile: +32-475-312.458
PGP Key available on request       MOBILE HAS CHANGED ON 11th November 2000


From owner-ipsec-policy@mail.vpnc.org  Tue Feb  6 12:56:19 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25276
	for <ipsp-archive@odin.ietf.org>; Tue, 6 Feb 2001 12:56:18 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA18455
	for ipsec-policy-bks; Tue, 6 Feb 2001 08:09:59 -0800 (PST)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18450
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 08:09:56 -0800 (PST)
Received: from brussels.cisco.com (brussels.cisco.com [144.254.15.68])
	by ogma.cisco.com (Postfix) with ESMTP
	id D3C7F175; Tue,  6 Feb 2001 17:16:43 +0100 (MET)
Received: from evyncke-8kcdt.cisco.com (evyncke-isdn-home.cisco.com [10.49.1.170])
	by brussels.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA23111;
	Tue, 6 Feb 2001 17:16:40 +0100 (MET)
Message-Id: <4.3.2.7.2.20010206171137.00c2f180@brussels.cisco.com>
X-Sender: evyncke@brussels.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 06 Feb 2001 17:17:13 +0100
To: Man.M.Li@nokia.com, ipsec-policy@imc.org
From: Eric Vyncke <evyncke@cisco.com>
Subject: RE: DMTF SAAction restriction
In-Reply-To: <B9CFA6CE8FFDD211A1FB0008C7894E460292B88F@bseis01nok>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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 talked about different things:

1) when ISAKMP is trying to build a SA, it sends multiple proposals

2) in the DMTF model, for one data traffic pattern, multiple actions are tried
until success:
    a) let's try ISAKMP with 3DES+RSA or 3DES-pre-shared with SG1
    b) if it fails, let's try ISAKMP with 3DES+RSA or 3DES-pre-shared with SG2
    c) if it fails, let's try DES-pre-shared with SG3

Obviously, the DMTF model allows the configuration of a complex IKE proposal
(see IKEProposal class which is associated to SANegotiationAction).

Hope this helps

-eric

At 09:30 6/02/01 -0600, Man.M.Li@nokia.com wrote:
>Is the "try until one succeeds" being described in any RFCs or is it only
>ONE way of implementation? I recall ISAKMP allow initiator to propose
>multiple proposals and multiple transforms for responder to choose from. But
>I do not recall seeing this "try until one succeeds". 
>
>
>Man Li
>Nokia 
>5 Wayside Road, Burlington, MA 01803
>man.m.li@nokia.com
>phone 1-781-993-3923
>GSM 1-781-492-2850 
>
>-----Original Message-----
>From: ext Lee Rafalow [mailto:rafalow@raleigh.ibm.com]
>Sent: Tuesday, February 06, 2001 9:48 AM
>To: ipsec-policy@imc.org
>Subject: Re: DMTF SAAction restriction
>
>
>The approach that we've thought through so far would use your first example
>to set up the tunnel.  We could explore your suggestion to add a sematic to
>the action list, but that complicates it significantly.  We already have
>semantics for the initiator and responder that are variations on "try until
>one succeeds."  Recall that for the initiator it's try the first one, if
>that fails try the second, etc.  For the responder it's a little more
>complicated: respond from the first action that is appropriate to the
>request (this allows a single rule to deal with both aggressive and main
>mode requests).
>
>
>To add semantics for "do ordered list of actions" would require a fairly
>complicated grammar for grouping actions into execution strategy groups (do
>all, do first successful).
>
>A way out of this might be to use the structured rules being proposed in the
>PCIM Extensions draft (currently being written) but that'll have to wait
>until we have a PCIMe draft to discuss.
>
>Lee
>----- Original Message -----
>From: <Man.M.Li@nokia.com>
>To: <HORMAN@novell.com>; <ipsec-policy@imc.org>; <jamie.jason@intel.com>;
><Man.M.Li@nokia.com>
>Sent: Monday, February 05, 2001 4:14 PM
>Subject: RE: DMTF SAAction restriction
>
>
>> Security per se may not be a problem. But if only a small percentage of
>> traffic needs multiple nested protection and we end up with giving all the
>> traffic multiple protections, it would be a waste of resources (e.g.,
>> processing resource for encryption). Security comes with a price and I
>> question if service providers or corporate IT managers will be happy about
>> giving the free ride at the expense of network resources.
>>
>> Man Li
>> Nokia
>> 5 Wayside Road, Burlington, MA 01803
>> man.m.li@nokia.com
>> phone 1-781-993-3923
>> GSM 1-781-492-2850
>>
>> -----Original Message-----
>> From: ext Hilarie Orman [mailto:HORMAN@novell.com]
>> Sent: Monday, February 05, 2001 3:10 PM
>> To: ipsec-policy@imc.org; jamie.jason@intel.com; Man.M.Li@nokia.com
>> Subject: RE: DMTF SAAction restriction
>>
>>
>> Why would it be erroneous to include a tunnel gratuitously?
>> Wrt to security, what is the problem?
>>
>> Hilarie
>>
>> >>> <Man.M.Li@nokia.com> 02/05/01 11:22AM >>>
>> What selectors are you looking for in your second search after the
>transport
>> rule? Is it a selector for the already encrypted packets (hence protocol =
>> ESP, for example) or for the original packets (protocol = tcp)? I see
>> problems in both cases. In the first case, if there is a rule to set up a
>> tunnel for ESP packets, we may include some other traffic that are ESP
>> transport protected but should not be included in the tunnel. In other
>> words, those traffic should only be transport protected.
>>
>> In the second case, we cannot reach the second selector for tunnel set up
>> because first matches will stop the search.
>>
>> A simple solution would be to remove the restriction and let SAActions to
>> indicate an ordered list of actions to be executed.
>>
>> Man Li
>> Nokia
>> 5 Wayside Road, Burlington, MA 01803
>> man.m.li@nokia.com
>> phone 1-781-993-3923
>> GSM 1-781-492-2850
>>
>> -----Original Message-----
>> From: ext Jason, Jamie [mailto:jamie.jason@intel.com]
>> Sent: Monday, February 05, 2001 11:01 AM
>> To: 'Man.M.Li@nokia.com'; ipsec-policy@imc.org
>> Subject: RE: DMTF SAAction restriction
>>
>>
>> Lee can correct me if I am wrong on this one, but I believe we had this
>same
>> discussion during a conference call between Lee, Eric Vyncke, and myself.
>I
>> believe the solution we came up with was that policy evaluation would
>first
>> encounter the transport rule.  Policy evaluation would then search to
>> determine if there was a tunnel rule that would apply (it would do this
>> recursively as you may have tunnels in tunnels).  This update probably
>> hasn't hit the MOF file or whitepaper yet.
>>
>> Jamie
>>
>> > -----Original Message-----
>> > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
>> > Sent: Monday, February 05, 2001 7:16 AM
>> > To: ipsec-policy@imc.org
>> > Subject: DMTF SAAction restriction
>> >
>> >
>> > Hi,
>> >
>> > The DMTF policy model Section 3 first paragraph indicates
>> > "The IPsec model
>> > restricts the use of SAActions to an ordered choice rather
>> > than a list of
>> > actions to be executed." I am wondering how the following
>> > situation would be
>> > handled with this restriction. We had similar discussions
>> > among IPsec PIB
>> > authors.
>> >
>> >        A (host)===========C(gateway)---B(host)
>> >
>> > A and C are connected to public Internet and B is connected
>> > to C. To protect
>> > TCP traffic between hosts A and B, an IPsec security association in
>> > transport mode needs to be established between hosts A and B.
>> > In addition,
>> > an IPsec security association in tunnel mode may be set up
>> > between host A
>> > and the gateway C that protects the LAN host B resides.
>> >
>> > In this case, A takes one action to set up an association
>> > between A and B.
>> > In addition, A should also set up a tunnel between A and C.
>> > From A's point
>> > of view, there are MULTIPLE actions to be taken in that order.
>> >
>> > How would you specify a policy to A if you are not allowed to
>> > specify a list
>> > of actions to be executed?
>> >
>> >
>> > Man Li
>> > Nokia
>> > 5 Wayside Road, Burlington, MA 01803
>> > man.m.li@nokia.com
>> > phone 1-781-993-3923
>> > GSM 1-781-492-2850
>> > 

Eric Vyncke                        
Distinguished Engineer             Cisco Systems EMEA
Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
E-mail: evyncke@cisco.com          Mobile: +32-475-312.458
PGP Key available on request       MOBILE HAS CHANGED ON 11th November 2000



From owner-ipsec-policy@mail.vpnc.org  Tue Feb  6 12:57:56 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25371
	for <ipsp-archive@odin.ietf.org>; Tue, 6 Feb 2001 12:57:55 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA19077
	for ipsec-policy-bks; Tue, 6 Feb 2001 08:28:56 -0800 (PST)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19070
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 08:28:53 -0800 (PST)
Received: from brussels.cisco.com (brussels.cisco.com [144.254.15.68])
	by ogma.cisco.com (Postfix) with ESMTP
	id 961E11E6; Tue,  6 Feb 2001 17:35:41 +0100 (MET)
Received: from evyncke-8kcdt.cisco.com (evyncke-isdn-home.cisco.com [10.49.1.170])
	by brussels.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id RAA29913;
	Tue, 6 Feb 2001 17:35:38 +0100 (MET)
Message-Id: <4.3.2.7.2.20010206173558.00c3fb10@brussels.cisco.com>
X-Sender: evyncke@brussels.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 06 Feb 2001 17:36:25 +0100
To: Man.M.Li@nokia.com, ipsec-policy@imc.org
From: Eric Vyncke <evyncke@cisco.com>
Subject: RE: DMTF SAAction restriction
In-Reply-To: <B9CFA6CE8FFDD211A1FB0008C7894E460292B891@bseis01nok>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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>

Because, I'm sending proposals to three different IKE peers.

-eric

At 10:20 6/02/01 -0600, Man.M.Li@nokia.com wrote:
>Correct me if I am wrong. But why cannot the three tries be bundled into one
>action with multiple proposals? My understanding is that the purpose of
>having multiple proposals is exactly such that if the responder cannot
>accept the first one (hence fails), it has the choice to choose another one
>from the list. 
>
>Man Li
>Nokia 
>5 Wayside Road, Burlington, MA 01803
>man.m.li@nokia.com
>phone 1-781-993-3923
>GSM 1-781-492-2850 
>
>-----Original Message-----
>From: ext Eric Vyncke [mailto:evyncke@cisco.com]
>Sent: Tuesday, February 06, 2001 11:17 AM
>To: Man.M.Li@nokia.com; ipsec-policy@imc.org
>Subject: RE: DMTF SAAction restriction
>
>
>We talked about different things:
>
>1) when ISAKMP is trying to build a SA, it sends multiple proposals
>
>2) in the DMTF model, for one data traffic pattern, multiple actions are
>tried
>until success:
>    a) let's try ISAKMP with 3DES+RSA or 3DES-pre-shared with SG1
>    b) if it fails, let's try ISAKMP with 3DES+RSA or 3DES-pre-shared with
>SG2
>    c) if it fails, let's try DES-pre-shared with SG3
>
>Obviously, the DMTF model allows the configuration of a complex IKE proposal
>(see IKEProposal class which is associated to SANegotiationAction).
>
>Hope this helps
>
>-eric
>
>At 09:30 6/02/01 -0600, Man.M.Li@nokia.com wrote:
>>Is the "try until one succeeds" being described in any RFCs or is it only
>>ONE way of implementation? I recall ISAKMP allow initiator to propose
>>multiple proposals and multiple transforms for responder to choose from.
>But
>>I do not recall seeing this "try until one succeeds". 
>>
>>
>>Man Li
>>Nokia 
>>5 Wayside Road, Burlington, MA 01803
>>man.m.li@nokia.com
>>phone 1-781-993-3923
>>GSM 1-781-492-2850 
>>
>>-----Original Message-----
>>From: ext Lee Rafalow [mailto:rafalow@raleigh.ibm.com]
>>Sent: Tuesday, February 06, 2001 9:48 AM
>>To: ipsec-policy@imc.org
>>Subject: Re: DMTF SAAction restriction
>>
>>
>>The approach that we've thought through so far would use your first example
>>to set up the tunnel.  We could explore your suggestion to add a sematic to
>>the action list, but that complicates it significantly.  We already have
>>semantics for the initiator and responder that are variations on "try until
>>one succeeds."  Recall that for the initiator it's try the first one, if
>>that fails try the second, etc.  For the responder it's a little more
>>complicated: respond from the first action that is appropriate to the
>>request (this allows a single rule to deal with both aggressive and main
>>mode requests).
>>
>>
>>To add semantics for "do ordered list of actions" would require a fairly
>>complicated grammar for grouping actions into execution strategy groups (do
>>all, do first successful).
>>
>>A way out of this might be to use the structured rules being proposed in
>the
>>PCIM Extensions draft (currently being written) but that'll have to wait
>>until we have a PCIMe draft to discuss.
>>
>>Lee
>>----- Original Message -----
>>From: <Man.M.Li@nokia.com>
>>To: <HORMAN@novell.com>; <ipsec-policy@imc.org>; <jamie.jason@intel.com>;
>><Man.M.Li@nokia.com>
>>Sent: Monday, February 05, 2001 4:14 PM
>>Subject: RE: DMTF SAAction restriction
>>
>>
>>> Security per se may not be a problem. But if only a small percentage of
>>> traffic needs multiple nested protection and we end up with giving all
>the
>>> traffic multiple protections, it would be a waste of resources (e.g.,
>>> processing resource for encryption). Security comes with a price and I
>>> question if service providers or corporate IT managers will be happy
>about
>>> giving the free ride at the expense of network resources.
>>>
>>> Man Li
>>> Nokia
>>> 5 Wayside Road, Burlington, MA 01803
>>> man.m.li@nokia.com
>>> phone 1-781-993-3923
>>> GSM 1-781-492-2850
>>>
>>> -----Original Message-----
>>> From: ext Hilarie Orman [mailto:HORMAN@novell.com]
>>> Sent: Monday, February 05, 2001 3:10 PM
>>> To: ipsec-policy@imc.org; jamie.jason@intel.com; Man.M.Li@nokia.com
>>> Subject: RE: DMTF SAAction restriction
>>>
>>>
>>> Why would it be erroneous to include a tunnel gratuitously?
>>> Wrt to security, what is the problem?
>>>
>>> Hilarie
>>>
>>> >>> <Man.M.Li@nokia.com> 02/05/01 11:22AM >>>
>>> What selectors are you looking for in your second search after the
>>transport
>>> rule? Is it a selector for the already encrypted packets (hence protocol
>=
>>> ESP, for example) or for the original packets (protocol = tcp)? I see
>>> problems in both cases. In the first case, if there is a rule to set up a
>>> tunnel for ESP packets, we may include some other traffic that are ESP
>>> transport protected but should not be included in the tunnel. In other
>>> words, those traffic should only be transport protected.
>>>
>>> In the second case, we cannot reach the second selector for tunnel set up
>>> because first matches will stop the search.
>>>
>>> A simple solution would be to remove the restriction and let SAActions to
>>> indicate an ordered list of actions to be executed.
>>>
>>> Man Li
>>> Nokia
>>> 5 Wayside Road, Burlington, MA 01803
>>> man.m.li@nokia.com
>>> phone 1-781-993-3923
>>> GSM 1-781-492-2850
>>>
>>> -----Original Message-----
>>> From: ext Jason, Jamie [mailto:jamie.jason@intel.com]
>>> Sent: Monday, February 05, 2001 11:01 AM
>>> To: 'Man.M.Li@nokia.com'; ipsec-policy@imc.org
>>> Subject: RE: DMTF SAAction restriction
>>>
>>>
>>> Lee can correct me if I am wrong on this one, but I believe we had this
>>same
>>> discussion during a conference call between Lee, Eric Vyncke, and myself.
>>I
>>> believe the solution we came up with was that policy evaluation would
>>first
>>> encounter the transport rule.  Policy evaluation would then search to
>>> determine if there was a tunnel rule that would apply (it would do this
>>> recursively as you may have tunnels in tunnels).  This update probably
>>> hasn't hit the MOF file or whitepaper yet.
>>>
>>> Jamie
>>>
>>> > -----Original Message-----
>>> > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
>>> > Sent: Monday, February 05, 2001 7:16 AM
>>> > To: ipsec-policy@imc.org
>>> > Subject: DMTF SAAction restriction
>>> >
>>> >
>>> > Hi,
>>> >
>>> > The DMTF policy model Section 3 first paragraph indicates
>>> > "The IPsec model
>>> > restricts the use of SAActions to an ordered choice rather
>>> > than a list of
>>> > actions to be executed." I am wondering how the following
>>> > situation would be
>>> > handled with this restriction. We had similar discussions
>>> > among IPsec PIB
>>> > authors.
>>> >
>>> >        A (host)===========C(gateway)---B(host)
>>> >
>>> > A and C are connected to public Internet and B is connected
>>> > to C. To protect
>>> > TCP traffic between hosts A and B, an IPsec security association in
>>> > transport mode needs to be established between hosts A and B.
>>> > In addition,
>>> > an IPsec security association in tunnel mode may be set up
>>> > between host A
>>> > and the gateway C that protects the LAN host B resides.
>>> >
>>> > In this case, A takes one action to set up an association
>>> > between A and B.
>>> > In addition, A should also set up a tunnel between A and C.
>>> > From A's point
>>> > of view, there are MULTIPLE actions to be taken in that order.
>>> >
>>> > How would you specify a policy to A if you are not allowed to
>>> > specify a list
>>> > of actions to be executed?
>>> >
>>> >
>>> > Man Li
>>> > Nokia
>>> > 5 Wayside Road, Burlington, MA 01803
>>> > man.m.li@nokia.com
>>> > phone 1-781-993-3923
>>> > GSM 1-781-492-2850
>>> > 
>
>Eric Vyncke                        
>Distinguished Engineer             Cisco Systems EMEA
>Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
>E-mail: evyncke@cisco.com          Mobile: +32-475-312.458
>PGP Key available on request       MOBILE HAS CHANGED ON 11th November 2000 

Eric Vyncke                        
Distinguished Engineer             Cisco Systems EMEA
Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
E-mail: evyncke@cisco.com          Mobile: +32-475-312.458
PGP Key available on request       MOBILE HAS CHANGED ON 11th November 2000



From owner-ipsec-policy@mail.vpnc.org  Tue Feb  6 13:23:28 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26902
	for <ipsp-archive@odin.ietf.org>; Tue, 6 Feb 2001 13:23:27 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id IAA20484
	for ipsec-policy-bks; Tue, 6 Feb 2001 08:59:22 -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 IAA20479
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 08:59:10 -0800 (PST)
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id RAA24596;
	Tue, 6 Feb 2001 17:07:32 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 06 Feb 2001 17:06:07 0000 (GMT)
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <1NRGJFF3>; Tue, 6 Feb 2001 09:06:05 -0800
Message-ID: <794826DE8867D411BAB8009027AE9EB904DD7A22@FMSMSX38>
From: "Jason, Jamie" <jamie.jason@intel.com>
To: "'Man.M.Li@nokia.com'" <Man.M.Li@nokia.com>, evyncke@cisco.com,
        ipsec-policy@imc.org
Subject: RE: DMTF SAAction restriction
Date: Tue, 6 Feb 2001 09:06:02 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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>

The ability to try different actions until one succeeds was not created as a
way to subvert the IKE proposal mechanism (i.e., we don't want it used to
try one proposal, and then if that fails, try another, etc.).  This came out
of discussions we had with regard to establishing tunnels.  For example, I
have several different machines I can contact to establish a VPN connection
into Intel.  I would set up my actions such that my machine would first
attempt to establish a tunnel to the Jones Farm server, if that fails, I
would then try to establish a tunnel to the Santa Clara server, etc.

Hopes this helps.
  
Jamie

> -----Original Message-----
> From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
> Sent: Tuesday, February 06, 2001 8:20 AM
> To: evyncke@cisco.com; ipsec-policy@imc.org
> Subject: RE: DMTF SAAction restriction
> 
> 
> Correct me if I am wrong. But why cannot the three tries be 
> bundled into one
> action with multiple proposals? My understanding is that the 
> purpose of
> having multiple proposals is exactly such that if the responder cannot
> accept the first one (hence fails), it has the choice to 
> choose another one
> from the list. 
> 
> Man Li
> Nokia 
> 5 Wayside Road, Burlington, MA 01803
> man.m.li@nokia.com
> phone 1-781-993-3923
> GSM 1-781-492-2850 
> 
> -----Original Message-----
> From: ext Eric Vyncke [mailto:evyncke@cisco.com]
> Sent: Tuesday, February 06, 2001 11:17 AM
> To: Man.M.Li@nokia.com; ipsec-policy@imc.org
> Subject: RE: DMTF SAAction restriction
> 
> 
> We talked about different things:
> 
> 1) when ISAKMP is trying to build a SA, it sends multiple proposals
> 
> 2) in the DMTF model, for one data traffic pattern, multiple 
> actions are
> tried
> until success:
>     a) let's try ISAKMP with 3DES+RSA or 3DES-pre-shared with SG1
>     b) if it fails, let's try ISAKMP with 3DES+RSA or 
> 3DES-pre-shared with
> SG2
>     c) if it fails, let's try DES-pre-shared with SG3
> 
> Obviously, the DMTF model allows the configuration of a 
> complex IKE proposal
> (see IKEProposal class which is associated to SANegotiationAction).
> 
> Hope this helps
> 
> -eric
> 
> At 09:30 6/02/01 -0600, Man.M.Li@nokia.com wrote:
> >Is the "try until one succeeds" being described in any RFCs 
> or is it only
> >ONE way of implementation? I recall ISAKMP allow initiator to propose
> >multiple proposals and multiple transforms for responder to 
> choose from.
> But
> >I do not recall seeing this "try until one succeeds". 
> >
> >
> >Man Li
> >Nokia 
> >5 Wayside Road, Burlington, MA 01803
> >man.m.li@nokia.com
> >phone 1-781-993-3923
> >GSM 1-781-492-2850 
> >
> >-----Original Message-----
> >From: ext Lee Rafalow [mailto:rafalow@raleigh.ibm.com]
> >Sent: Tuesday, February 06, 2001 9:48 AM
> >To: ipsec-policy@imc.org
> >Subject: Re: DMTF SAAction restriction
> >
> >
> >The approach that we've thought through so far would use 
> your first example
> >to set up the tunnel.  We could explore your suggestion to 
> add a sematic to
> >the action list, but that complicates it significantly.  We 
> already have
> >semantics for the initiator and responder that are 
> variations on "try until
> >one succeeds."  Recall that for the initiator it's try the 
> first one, if
> >that fails try the second, etc.  For the responder it's a little more
> >complicated: respond from the first action that is appropriate to the
> >request (this allows a single rule to deal with both 
> aggressive and main
> >mode requests).
> >
> >
> >To add semantics for "do ordered list of actions" would 
> require a fairly
> >complicated grammar for grouping actions into execution 
> strategy groups (do
> >all, do first successful).
> >
> >A way out of this might be to use the structured rules being 
> proposed in
> the
> >PCIM Extensions draft (currently being written) but that'll 
> have to wait
> >until we have a PCIMe draft to discuss.
> >
> >Lee
> >----- Original Message -----
> >From: <Man.M.Li@nokia.com>
> >To: <HORMAN@novell.com>; <ipsec-policy@imc.org>; 
> <jamie.jason@intel.com>;
> ><Man.M.Li@nokia.com>
> >Sent: Monday, February 05, 2001 4:14 PM
> >Subject: RE: DMTF SAAction restriction
> >
> >
> >> Security per se may not be a problem. But if only a small 
> percentage of
> >> traffic needs multiple nested protection and we end up 
> with giving all
> the
> >> traffic multiple protections, it would be a waste of 
> resources (e.g.,
> >> processing resource for encryption). Security comes with a 
> price and I
> >> question if service providers or corporate IT managers 
> will be happy
> about
> >> giving the free ride at the expense of network resources.
> >>
> >> Man Li
> >> Nokia
> >> 5 Wayside Road, Burlington, MA 01803
> >> man.m.li@nokia.com
> >> phone 1-781-993-3923
> >> GSM 1-781-492-2850
> >>
> >> -----Original Message-----
> >> From: ext Hilarie Orman [mailto:HORMAN@novell.com]
> >> Sent: Monday, February 05, 2001 3:10 PM
> >> To: ipsec-policy@imc.org; jamie.jason@intel.com; Man.M.Li@nokia.com
> >> Subject: RE: DMTF SAAction restriction
> >>
> >>
> >> Why would it be erroneous to include a tunnel gratuitously?
> >> Wrt to security, what is the problem?
> >>
> >> Hilarie
> >>
> >> >>> <Man.M.Li@nokia.com> 02/05/01 11:22AM >>>
> >> What selectors are you looking for in your second search after the
> >transport
> >> rule? Is it a selector for the already encrypted packets 
> (hence protocol
> =
> >> ESP, for example) or for the original packets (protocol = 
> tcp)? I see
> >> problems in both cases. In the first case, if there is a 
> rule to set up a
> >> tunnel for ESP packets, we may include some other traffic 
> that are ESP
> >> transport protected but should not be included in the 
> tunnel. In other
> >> words, those traffic should only be transport protected.
> >>
> >> In the second case, we cannot reach the second selector 
> for tunnel set up
> >> because first matches will stop the search.
> >>
> >> A simple solution would be to remove the restriction and 
> let SAActions to
> >> indicate an ordered list of actions to be executed.
> >>
> >> Man Li
> >> Nokia
> >> 5 Wayside Road, Burlington, MA 01803
> >> man.m.li@nokia.com
> >> phone 1-781-993-3923
> >> GSM 1-781-492-2850
> >>
> >> -----Original Message-----
> >> From: ext Jason, Jamie [mailto:jamie.jason@intel.com]
> >> Sent: Monday, February 05, 2001 11:01 AM
> >> To: 'Man.M.Li@nokia.com'; ipsec-policy@imc.org
> >> Subject: RE: DMTF SAAction restriction
> >>
> >>
> >> Lee can correct me if I am wrong on this one, but I 
> believe we had this
> >same
> >> discussion during a conference call between Lee, Eric 
> Vyncke, and myself.
> >I
> >> believe the solution we came up with was that policy 
> evaluation would
> >first
> >> encounter the transport rule.  Policy evaluation would 
> then search to
> >> determine if there was a tunnel rule that would apply (it 
> would do this
> >> recursively as you may have tunnels in tunnels).  This 
> update probably
> >> hasn't hit the MOF file or whitepaper yet.
> >>
> >> Jamie
> >>
> >> > -----Original Message-----
> >> > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
> >> > Sent: Monday, February 05, 2001 7:16 AM
> >> > To: ipsec-policy@imc.org
> >> > Subject: DMTF SAAction restriction
> >> >
> >> >
> >> > Hi,
> >> >
> >> > The DMTF policy model Section 3 first paragraph indicates
> >> > "The IPsec model
> >> > restricts the use of SAActions to an ordered choice rather
> >> > than a list of
> >> > actions to be executed." I am wondering how the following
> >> > situation would be
> >> > handled with this restriction. We had similar discussions
> >> > among IPsec PIB
> >> > authors.
> >> >
> >> >        A (host)===========C(gateway)---B(host)
> >> >
> >> > A and C are connected to public Internet and B is connected
> >> > to C. To protect
> >> > TCP traffic between hosts A and B, an IPsec security 
> association in
> >> > transport mode needs to be established between hosts A and B.
> >> > In addition,
> >> > an IPsec security association in tunnel mode may be set up
> >> > between host A
> >> > and the gateway C that protects the LAN host B resides.
> >> >
> >> > In this case, A takes one action to set up an association
> >> > between A and B.
> >> > In addition, A should also set up a tunnel between A and C.
> >> > From A's point
> >> > of view, there are MULTIPLE actions to be taken in that order.
> >> >
> >> > How would you specify a policy to A if you are not allowed to
> >> > specify a list
> >> > of actions to be executed?
> >> >
> >> >
> >> > Man Li
> >> > Nokia
> >> > 5 Wayside Road, Burlington, MA 01803
> >> > man.m.li@nokia.com
> >> > phone 1-781-993-3923
> >> > GSM 1-781-492-2850
> >> > 
> 
> Eric Vyncke                        
> Distinguished Engineer             Cisco Systems EMEA
> Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
> E-mail: evyncke@cisco.com          Mobile: +32-475-312.458
> PGP Key available on request       MOBILE HAS CHANGED ON 11th 
> November 2000
> 



From owner-ipsec-policy@mail.vpnc.org  Tue Feb  6 13:37:43 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27448
	for <ipsp-archive@odin.ietf.org>; Tue, 6 Feb 2001 13:37:43 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id JAA21043
	for ipsec-policy-bks; Tue, 6 Feb 2001 09:09:49 -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 JAA21038
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 09:09:48 -0800 (PST)
Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id RAA29743;
	Tue, 6 Feb 2001 17:18:25 GMT
Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 06 Feb 2001 17:17:01 0000 (GMT)
Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <D000A18X>; Tue, 6 Feb 2001 09:16:59 -0800
Message-ID: <794826DE8867D411BAB8009027AE9EB904DD7A23@FMSMSX38>
From: "Jason, Jamie" <jamie.jason@intel.com>
To: "'Wes Hardaker'" <wes@hardakers.net>,
        ipsec-policy
	 <ipsec-policy@imc.org>
Subject: RE: draft-ietf-ipsp-config-policy-model comments
Date: Tue, 6 Feb 2001 09:16:57 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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>

First, thanks for taking the time for reading the draft.

I'll answer your questions inline.

> 1) The definitions for SARule, SAAction, SAStaticAction,
>    SANegotiationAction and IPsecAction contain the following sentence:
> 
>      "Although the class is concrete, is MUST not be instantiated."
>
> 2) Regarding the above, why not just make the classes abstract to
>    ensure they're not instantiated?

The above mentioned classes are concrete in the DMTF version of the model,
which is used as the basis for the IETF model.  At this time, it escapes me
why this is so in the DMTF model - maybe Lee Rafalow can help me here and
jog my memory.

> 3) Some of the objects (EG, IKERuleOverridePoint) contain high to low
>    precedence (higher numbers have a larger precedence) and others
>    (EG, IPsecPolicyGroupInPolicyGroup's "Precedence" attribute) have
>    low to high precedence where lower numbers have a larger
>    precedence.  Although not important from a technical prospective,
>    it would make more sense to have this be consistent across the
>    entire document unless there is a reason its done like it is.

First, let me note that the rule override point attributes are gone.

I will go through the draft and find the areas where we have things like
order, precedence, and priority and determine if there is something we can
do about inconsistencies - some of the attributes are inherited from PCIM
and therefore we won't be able to change them.

> 4) Section 5.12 specifies the property of FQDNFilterEntry as "Name"
>    but section 5.12.1 which describes the property has a name of
>    "Address" instead of "Name".

Ooops...cut and paste error.

> 5) Section 6.2 which describes "The Class SAStaticAction" says that it
>    "serves as the base class for IKE and IPsec actions that
>    do not require negotiation.
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
>    But yet, section 6.2.1 "The property LifetimeSeconds" describes the
>    property value with "A non-zero value is typically used in
>    conjunction with fallback actions performed when there is a
>    negotiation failure of some sort."
>    ^^^^^^^^^^^^^^^^^^^

Another cut and paste error.  There should be no mention of negotiation,
either explicitly or implicitly in this section.

> 6) section 6.7.3, 6.7.4 and 6.11.1 say that "A random value may be
>    added...".  I think I'd suggest making that "may" be a "SHOULD" and
>    if not that then possibly a "MAY".

I will look at those sections and determine the intent and make the
appropriate change.

Thanks.
Jamie



From owner-ipsec-policy@mail.vpnc.org  Tue Feb  6 14:13:58 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28367
	for <ipsp-archive@odin.ietf.org>; Tue, 6 Feb 2001 14:13:57 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA22267
	for ipsec-policy-bks; Tue, 6 Feb 2001 09:37:38 -0800 (PST)
Received: from D2CSPIMG001.smartpipes.com ([63.89.185.24])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA22262
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 09:37:37 -0800 (PST)
Received: by D2CSPIMG001.smartpipes.com with Internet Mail Service (5.5.2653.19)
	id <1KSWYG2C>; Tue, 6 Feb 2001 17:44:26 -0000
Message-ID: <8E1E94178828D143B34A560A7A6F2C0B0199AC58@mailmaestro.smartpipes.com>
From: "Wang, Cliff" <CWang@smartpipes.com>
To: "'Eric Vyncke'" <evyncke@cisco.com>, Man.M.Li@nokia.com,
        ipsec-policy@imc.org
Subject: RE: DMTF SAAction restriction
Date: Tue, 6 Feb 2001 17:44:25 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

I am confused.....

First, for one data traffic pattern example in 2) below, 
why we try 3 gateways? Are you talking about redundancy? 

In Man's example, we are
talking about one tunnel nested in another one. Both tunnels
need to be set up. The inside tunnel is between A and B. The 
outside tunnel is between A and C. There is no trial and fail allowed. 

I think that we are talking about different things.

-----Original Message-----
From: Eric Vyncke [mailto:evyncke@cisco.com]
Sent: Tuesday, February 06, 2001 11:17 AM
To: Man.M.Li@nokia.com; ipsec-policy@imc.org
Subject: RE: DMTF SAAction restriction


We talked about different things:

1) when ISAKMP is trying to build a SA, it sends multiple proposals

2) in the DMTF model, for one data traffic pattern, multiple actions are
tried
until success:
    a) let's try ISAKMP with 3DES+RSA or 3DES-pre-shared with SG1
    b) if it fails, let's try ISAKMP with 3DES+RSA or 3DES-pre-shared with
SG2
    c) if it fails, let's try DES-pre-shared with SG3

Obviously, the DMTF model allows the configuration of a complex IKE proposal
(see IKEProposal class which is associated to SANegotiationAction).

Hope this helps

-eric

At 09:30 6/02/01 -0600, Man.M.Li@nokia.com wrote:
>Is the "try until one succeeds" being described in any RFCs or is it only
>ONE way of implementation? I recall ISAKMP allow initiator to propose
>multiple proposals and multiple transforms for responder to choose from.
But
>I do not recall seeing this "try until one succeeds". 
>
>
>Man Li
>Nokia 
>5 Wayside Road, Burlington, MA 01803
>man.m.li@nokia.com
>phone 1-781-993-3923
>GSM 1-781-492-2850 
>
>-----Original Message-----
>From: ext Lee Rafalow [mailto:rafalow@raleigh.ibm.com]
>Sent: Tuesday, February 06, 2001 9:48 AM
>To: ipsec-policy@imc.org
>Subject: Re: DMTF SAAction restriction
>
>
>The approach that we've thought through so far would use your first example
>to set up the tunnel.  We could explore your suggestion to add a sematic to
>the action list, but that complicates it significantly.  We already have
>semantics for the initiator and responder that are variations on "try until
>one succeeds."  Recall that for the initiator it's try the first one, if
>that fails try the second, etc.  For the responder it's a little more
>complicated: respond from the first action that is appropriate to the
>request (this allows a single rule to deal with both aggressive and main
>mode requests).
>
>
>To add semantics for "do ordered list of actions" would require a fairly
>complicated grammar for grouping actions into execution strategy groups (do
>all, do first successful).
>
>A way out of this might be to use the structured rules being proposed in
the
>PCIM Extensions draft (currently being written) but that'll have to wait
>until we have a PCIMe draft to discuss.
>
>Lee
>----- Original Message -----
>From: <Man.M.Li@nokia.com>
>To: <HORMAN@novell.com>; <ipsec-policy@imc.org>; <jamie.jason@intel.com>;
><Man.M.Li@nokia.com>
>Sent: Monday, February 05, 2001 4:14 PM
>Subject: RE: DMTF SAAction restriction
>
>
>> Security per se may not be a problem. But if only a small percentage of
>> traffic needs multiple nested protection and we end up with giving all
the
>> traffic multiple protections, it would be a waste of resources (e.g.,
>> processing resource for encryption). Security comes with a price and I
>> question if service providers or corporate IT managers will be happy
about
>> giving the free ride at the expense of network resources.
>>
>> Man Li
>> Nokia
>> 5 Wayside Road, Burlington, MA 01803
>> man.m.li@nokia.com
>> phone 1-781-993-3923
>> GSM 1-781-492-2850
>>
>> -----Original Message-----
>> From: ext Hilarie Orman [mailto:HORMAN@novell.com]
>> Sent: Monday, February 05, 2001 3:10 PM
>> To: ipsec-policy@imc.org; jamie.jason@intel.com; Man.M.Li@nokia.com
>> Subject: RE: DMTF SAAction restriction
>>
>>
>> Why would it be erroneous to include a tunnel gratuitously?
>> Wrt to security, what is the problem?
>>
>> Hilarie
>>
>> >>> <Man.M.Li@nokia.com> 02/05/01 11:22AM >>>
>> What selectors are you looking for in your second search after the
>transport
>> rule? Is it a selector for the already encrypted packets (hence protocol
=
>> ESP, for example) or for the original packets (protocol = tcp)? I see
>> problems in both cases. In the first case, if there is a rule to set up a
>> tunnel for ESP packets, we may include some other traffic that are ESP
>> transport protected but should not be included in the tunnel. In other
>> words, those traffic should only be transport protected.
>>
>> In the second case, we cannot reach the second selector for tunnel set up
>> because first matches will stop the search.
>>
>> A simple solution would be to remove the restriction and let SAActions to
>> indicate an ordered list of actions to be executed.
>>
>> Man Li
>> Nokia
>> 5 Wayside Road, Burlington, MA 01803
>> man.m.li@nokia.com
>> phone 1-781-993-3923
>> GSM 1-781-492-2850
>>
>> -----Original Message-----
>> From: ext Jason, Jamie [mailto:jamie.jason@intel.com]
>> Sent: Monday, February 05, 2001 11:01 AM
>> To: 'Man.M.Li@nokia.com'; ipsec-policy@imc.org
>> Subject: RE: DMTF SAAction restriction
>>
>>
>> Lee can correct me if I am wrong on this one, but I believe we had this
>same
>> discussion during a conference call between Lee, Eric Vyncke, and myself.
>I
>> believe the solution we came up with was that policy evaluation would
>first
>> encounter the transport rule.  Policy evaluation would then search to
>> determine if there was a tunnel rule that would apply (it would do this
>> recursively as you may have tunnels in tunnels).  This update probably
>> hasn't hit the MOF file or whitepaper yet.
>>
>> Jamie
>>
>> > -----Original Message-----
>> > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
>> > Sent: Monday, February 05, 2001 7:16 AM
>> > To: ipsec-policy@imc.org
>> > Subject: DMTF SAAction restriction
>> >
>> >
>> > Hi,
>> >
>> > The DMTF policy model Section 3 first paragraph indicates
>> > "The IPsec model
>> > restricts the use of SAActions to an ordered choice rather
>> > than a list of
>> > actions to be executed." I am wondering how the following
>> > situation would be
>> > handled with this restriction. We had similar discussions
>> > among IPsec PIB
>> > authors.
>> >
>> >        A (host)===========C(gateway)---B(host)
>> >
>> > A and C are connected to public Internet and B is connected
>> > to C. To protect
>> > TCP traffic between hosts A and B, an IPsec security association in
>> > transport mode needs to be established between hosts A and B.
>> > In addition,
>> > an IPsec security association in tunnel mode may be set up
>> > between host A
>> > and the gateway C that protects the LAN host B resides.
>> >
>> > In this case, A takes one action to set up an association
>> > between A and B.
>> > In addition, A should also set up a tunnel between A and C.
>> > From A's point
>> > of view, there are MULTIPLE actions to be taken in that order.
>> >
>> > How would you specify a policy to A if you are not allowed to
>> > specify a list
>> > of actions to be executed?
>> >
>> >
>> > Man Li
>> > Nokia
>> > 5 Wayside Road, Burlington, MA 01803
>> > man.m.li@nokia.com
>> > phone 1-781-993-3923
>> > GSM 1-781-492-2850
>> > 

Eric Vyncke                        
Distinguished Engineer             Cisco Systems EMEA
Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
E-mail: evyncke@cisco.com          Mobile: +32-475-312.458
PGP Key available on request       MOBILE HAS CHANGED ON 11th November 2000


From owner-ipsec-policy@mail.vpnc.org  Tue Feb  6 14:54:06 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29789
	for <ipsp-archive@odin.ietf.org>; Tue, 6 Feb 2001 14:54:05 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA25891
	for ipsec-policy-bks; Tue, 6 Feb 2001 10:43:37 -0800 (PST)
Received: from selene.cps.intel.com (selene.cps.intel.com [192.198.165.10])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25879
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 10:43:31 -0800 (PST)
Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204])
	by selene.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id KAA12872;
	Tue, 6 Feb 2001 10:50:05 -0800 (PST)
Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.204
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 06 Feb 2001 18:50:05 0000 (GMT)
Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <DRV86QZ6>; Tue, 6 Feb 2001 10:50:03 -0800
Message-ID: <794826DE8867D411BAB8009027AE9EB904DD7A26@FMSMSX38>
From: "Jason, Jamie" <jamie.jason@intel.com>
To: "'Wang, Cliff'" <CWang@smartpipes.com>,
        "Jason, Jamie"
	 <jamie.jason@intel.com>,
        "'Man.M.Li@nokia.com'" <Man.M.Li@nokia.com>, evyncke@cisco.com,
        ipsec-policy@imc.org
Subject: RE: DMTF SAAction restriction
Date: Tue, 6 Feb 2001 10:50:03 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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>

> Thanks for the clarifications.
> 
> Then the trial and switch by failure is really addressing a different
> issue, which is providing redundant IKE connection.
> 
> The original question is on how to set up policy for nested tunnels.

I think this is what Eric is going to address in his update to the DMTF
whitepaper (which will be rolled into the next I-D of the policy model).

Jamie



From owner-ipsec-policy@mail.vpnc.org  Tue Feb  6 15:00:13 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29972
	for <ipsp-archive@odin.ietf.org>; Tue, 6 Feb 2001 15:00:12 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id KAA26286
	for ipsec-policy-bks; Tue, 6 Feb 2001 10:50:01 -0800 (PST)
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 KAA26282
	for <ipsec-policy@vpnc.org>; Tue, 6 Feb 2001 10:50:00 -0800 (PST)
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 NAA23358;
	Tue, 6 Feb 2001 13:56:43 -0500
Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id NAA03438;
	Tue, 6 Feb 2001 13:56:43 -0500
Message-ID: <00ff01c0906e$372444e0$11312509@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: <ipsec-policy@vpnc.org>
Cc: "Victor Lortz" <victor.lortz@intel.com>
References: <794826DE8867D411BAB8009027AE9EB904DD7A23@FMSMSX38>
Subject: Re: draft-ietf-ipsp-config-policy-model comments
Date: Tue, 6 Feb 2001 13:54:19 -0500
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.50.4522.1200
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200
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>
Content-Transfer-Encoding: 7bit

> > 1) The definitions for SARule, SAAction, SAStaticAction,
> >    SANegotiationAction and IPsecAction contain the following sentence:
> >
> >      "Although the class is concrete, is MUST not be instantiated."
> >
> > 2) Regarding the above, why not just make the classes abstract to
> >    ensure they're not instantiated?
>
> The above mentioned classes are concrete in the DMTF version of the model,
> which is used as the basis for the IETF model.  At this time, it escapes
me
> why this is so in the DMTF model - maybe Lee Rafalow can help me here and
> jog my memory.

Unfortunately, what I'm remembering and what I read in PCIM are two
different things.  What I remember is that the parent classes were concrete
and therefore they had to be concrete; but that's not completely true.

PolicyRule is concrete so SARule needs to be concrete.

PolicyAction is abstract so SARule can be made abstract as well.  That means
we can also make SAStaticAction, PreconfiguredSAAction, SANegotiationAction
and IPsecAction all abstract.  I think PolicyAction was concrete at some
point and then changed to abstract and we didn't update along with that
change.

Thanks for spotting this.

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@mail.vpnc.org  Tue Feb  6 15:06:30 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00160
	for <ipsp-archive@odin.ietf.org>; Tue, 6 Feb 2001 15:06:30 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id KAA25670
	for ipsec-policy-bks; Tue, 6 Feb 2001 10:40:21 -0800 (PST)
Received: from D2CSPIMG001.smartpipes.com ([63.89.185.24])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA25666
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 10:40:19 -0800 (PST)
Received: by D2CSPIMG001.smartpipes.com with Internet Mail Service (5.5.2653.19)
	id <1KSWYGSQ>; Tue, 6 Feb 2001 18:47:09 -0000
Message-ID: <8E1E94178828D143B34A560A7A6F2C0B0199AC5A@mailmaestro.smartpipes.com>
From: "Wang, Cliff" <CWang@smartpipes.com>
To: "'Jason, Jamie'" <jamie.jason@intel.com>,
        "'Man.M.Li@nokia.com'"
	 <Man.M.Li@nokia.com>, evyncke@cisco.com,
        ipsec-policy@imc.org
Subject: RE: DMTF SAAction restriction
Date: Tue, 6 Feb 2001 18:47:08 -0000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

Thanks for the clarifications.

Then the trial and switch by failure is really addressing a different
issue, which is providing redundant IKE connection.

The original question is on how to set up policy for nested tunnels.

-----Original Message-----
From: Jason, Jamie [mailto:jamie.jason@intel.com]
Sent: Tuesday, February 06, 2001 12:06 PM
To: 'Man.M.Li@nokia.com'; evyncke@cisco.com; ipsec-policy@imc.org
Subject: RE: DMTF SAAction restriction


The ability to try different actions until one succeeds was not created as a
way to subvert the IKE proposal mechanism (i.e., we don't want it used to
try one proposal, and then if that fails, try another, etc.).  This came out
of discussions we had with regard to establishing tunnels.  For example, I
have several different machines I can contact to establish a VPN connection
into Intel.  I would set up my actions such that my machine would first
attempt to establish a tunnel to the Jones Farm server, if that fails, I
would then try to establish a tunnel to the Santa Clara server, etc.

Hopes this helps.
  
Jamie

> -----Original Message-----
> From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
> Sent: Tuesday, February 06, 2001 8:20 AM
> To: evyncke@cisco.com; ipsec-policy@imc.org
> Subject: RE: DMTF SAAction restriction
> 
> 
> Correct me if I am wrong. But why cannot the three tries be 
> bundled into one
> action with multiple proposals? My understanding is that the 
> purpose of
> having multiple proposals is exactly such that if the responder cannot
> accept the first one (hence fails), it has the choice to 
> choose another one
> from the list. 
> 
> Man Li
> Nokia 
> 5 Wayside Road, Burlington, MA 01803
> man.m.li@nokia.com
> phone 1-781-993-3923
> GSM 1-781-492-2850 
> 
> -----Original Message-----
> From: ext Eric Vyncke [mailto:evyncke@cisco.com]
> Sent: Tuesday, February 06, 2001 11:17 AM
> To: Man.M.Li@nokia.com; ipsec-policy@imc.org
> Subject: RE: DMTF SAAction restriction
> 
> 
> We talked about different things:
> 
> 1) when ISAKMP is trying to build a SA, it sends multiple proposals
> 
> 2) in the DMTF model, for one data traffic pattern, multiple 
> actions are
> tried
> until success:
>     a) let's try ISAKMP with 3DES+RSA or 3DES-pre-shared with SG1
>     b) if it fails, let's try ISAKMP with 3DES+RSA or 
> 3DES-pre-shared with
> SG2
>     c) if it fails, let's try DES-pre-shared with SG3
> 
> Obviously, the DMTF model allows the configuration of a 
> complex IKE proposal
> (see IKEProposal class which is associated to SANegotiationAction).
> 
> Hope this helps
> 
> -eric
> 
> At 09:30 6/02/01 -0600, Man.M.Li@nokia.com wrote:
> >Is the "try until one succeeds" being described in any RFCs 
> or is it only
> >ONE way of implementation? I recall ISAKMP allow initiator to propose
> >multiple proposals and multiple transforms for responder to 
> choose from.
> But
> >I do not recall seeing this "try until one succeeds". 
> >
> >
> >Man Li
> >Nokia 
> >5 Wayside Road, Burlington, MA 01803
> >man.m.li@nokia.com
> >phone 1-781-993-3923
> >GSM 1-781-492-2850 
> >
> >-----Original Message-----
> >From: ext Lee Rafalow [mailto:rafalow@raleigh.ibm.com]
> >Sent: Tuesday, February 06, 2001 9:48 AM
> >To: ipsec-policy@imc.org
> >Subject: Re: DMTF SAAction restriction
> >
> >
> >The approach that we've thought through so far would use 
> your first example
> >to set up the tunnel.  We could explore your suggestion to 
> add a sematic to
> >the action list, but that complicates it significantly.  We 
> already have
> >semantics for the initiator and responder that are 
> variations on "try until
> >one succeeds."  Recall that for the initiator it's try the 
> first one, if
> >that fails try the second, etc.  For the responder it's a little more
> >complicated: respond from the first action that is appropriate to the
> >request (this allows a single rule to deal with both 
> aggressive and main
> >mode requests).
> >
> >
> >To add semantics for "do ordered list of actions" would 
> require a fairly
> >complicated grammar for grouping actions into execution 
> strategy groups (do
> >all, do first successful).
> >
> >A way out of this might be to use the structured rules being 
> proposed in
> the
> >PCIM Extensions draft (currently being written) but that'll 
> have to wait
> >until we have a PCIMe draft to discuss.
> >
> >Lee
> >----- Original Message -----
> >From: <Man.M.Li@nokia.com>
> >To: <HORMAN@novell.com>; <ipsec-policy@imc.org>; 
> <jamie.jason@intel.com>;
> ><Man.M.Li@nokia.com>
> >Sent: Monday, February 05, 2001 4:14 PM
> >Subject: RE: DMTF SAAction restriction
> >
> >
> >> Security per se may not be a problem. But if only a small 
> percentage of
> >> traffic needs multiple nested protection and we end up 
> with giving all
> the
> >> traffic multiple protections, it would be a waste of 
> resources (e.g.,
> >> processing resource for encryption). Security comes with a 
> price and I
> >> question if service providers or corporate IT managers 
> will be happy
> about
> >> giving the free ride at the expense of network resources.
> >>
> >> Man Li
> >> Nokia
> >> 5 Wayside Road, Burlington, MA 01803
> >> man.m.li@nokia.com
> >> phone 1-781-993-3923
> >> GSM 1-781-492-2850
> >>
> >> -----Original Message-----
> >> From: ext Hilarie Orman [mailto:HORMAN@novell.com]
> >> Sent: Monday, February 05, 2001 3:10 PM
> >> To: ipsec-policy@imc.org; jamie.jason@intel.com; Man.M.Li@nokia.com
> >> Subject: RE: DMTF SAAction restriction
> >>
> >>
> >> Why would it be erroneous to include a tunnel gratuitously?
> >> Wrt to security, what is the problem?
> >>
> >> Hilarie
> >>
> >> >>> <Man.M.Li@nokia.com> 02/05/01 11:22AM >>>
> >> What selectors are you looking for in your second search after the
> >transport
> >> rule? Is it a selector for the already encrypted packets 
> (hence protocol
> =
> >> ESP, for example) or for the original packets (protocol = 
> tcp)? I see
> >> problems in both cases. In the first case, if there is a 
> rule to set up a
> >> tunnel for ESP packets, we may include some other traffic 
> that are ESP
> >> transport protected but should not be included in the 
> tunnel. In other
> >> words, those traffic should only be transport protected.
> >>
> >> In the second case, we cannot reach the second selector 
> for tunnel set up
> >> because first matches will stop the search.
> >>
> >> A simple solution would be to remove the restriction and 
> let SAActions to
> >> indicate an ordered list of actions to be executed.
> >>
> >> Man Li
> >> Nokia
> >> 5 Wayside Road, Burlington, MA 01803
> >> man.m.li@nokia.com
> >> phone 1-781-993-3923
> >> GSM 1-781-492-2850
> >>
> >> -----Original Message-----
> >> From: ext Jason, Jamie [mailto:jamie.jason@intel.com]
> >> Sent: Monday, February 05, 2001 11:01 AM
> >> To: 'Man.M.Li@nokia.com'; ipsec-policy@imc.org
> >> Subject: RE: DMTF SAAction restriction
> >>
> >>
> >> Lee can correct me if I am wrong on this one, but I 
> believe we had this
> >same
> >> discussion during a conference call between Lee, Eric 
> Vyncke, and myself.
> >I
> >> believe the solution we came up with was that policy 
> evaluation would
> >first
> >> encounter the transport rule.  Policy evaluation would 
> then search to
> >> determine if there was a tunnel rule that would apply (it 
> would do this
> >> recursively as you may have tunnels in tunnels).  This 
> update probably
> >> hasn't hit the MOF file or whitepaper yet.
> >>
> >> Jamie
> >>
> >> > -----Original Message-----
> >> > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
> >> > Sent: Monday, February 05, 2001 7:16 AM
> >> > To: ipsec-policy@imc.org
> >> > Subject: DMTF SAAction restriction
> >> >
> >> >
> >> > Hi,
> >> >
> >> > The DMTF policy model Section 3 first paragraph indicates
> >> > "The IPsec model
> >> > restricts the use of SAActions to an ordered choice rather
> >> > than a list of
> >> > actions to be executed." I am wondering how the following
> >> > situation would be
> >> > handled with this restriction. We had similar discussions
> >> > among IPsec PIB
> >> > authors.
> >> >
> >> >        A (host)===========C(gateway)---B(host)
> >> >
> >> > A and C are connected to public Internet and B is connected
> >> > to C. To protect
> >> > TCP traffic between hosts A and B, an IPsec security 
> association in
> >> > transport mode needs to be established between hosts A and B.
> >> > In addition,
> >> > an IPsec security association in tunnel mode may be set up
> >> > between host A
> >> > and the gateway C that protects the LAN host B resides.
> >> >
> >> > In this case, A takes one action to set up an association
> >> > between A and B.
> >> > In addition, A should also set up a tunnel between A and C.
> >> > From A's point
> >> > of view, there are MULTIPLE actions to be taken in that order.
> >> >
> >> > How would you specify a policy to A if you are not allowed to
> >> > specify a list
> >> > of actions to be executed?
> >> >
> >> >
> >> > Man Li
> >> > Nokia
> >> > 5 Wayside Road, Burlington, MA 01803
> >> > man.m.li@nokia.com
> >> > phone 1-781-993-3923
> >> > GSM 1-781-492-2850
> >> > 
> 
> Eric Vyncke                        
> Distinguished Engineer             Cisco Systems EMEA
> Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
> E-mail: evyncke@cisco.com          Mobile: +32-475-312.458
> PGP Key available on request       MOBILE HAS CHANGED ON 11th 
> November 2000
> 


From owner-ipsec-policy@mail.vpnc.org  Tue Feb  6 15:18:05 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00677
	for <ipsp-archive@odin.ietf.org>; Tue, 6 Feb 2001 15:18:04 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id JAA22678
	for ipsec-policy-bks; Tue, 6 Feb 2001 09:52:37 -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 JAA22673
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 09:52:35 -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 MAA06726
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 12:59:20 -0500
Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA26990
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 12:59:23 -0500
Message-ID: <00d101c09066$3d4b8fc0$11312509@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: <ipsec-policy@imc.org>
References: <B9CFA6CE8FFDD211A1FB0008C7894E460292B891@bseis01nok>
Subject: Re: DMTF SAAction restriction
Date: Tue, 6 Feb 2001 12:57:13 -0500
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.50.4522.1200
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200
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>
Content-Transfer-Encoding: 7bit

As Eric indicated, the model has actions that contain proposals that contain
transforms.  So, a single action is used to send multiple proposals.  The
"try until successful" semantic on the ordered actions permits a rule to
specify fallback actions for the initiator.  The most common example might
be a rule that could specify a negotiation action as the first choice and a
bypass or discard static action as the second choice.  So, if the IKE
negotiation fails for some reason, the rule explicitly states the
alternative action.  Another example might be that a rule could also specify
a different negotiation action, perhaps to a different security gateway as a
second, third, ... action to try in the event of failure.  Similarly, the
fallback action could be to use a preconfigured SA in the event that the
peer has no IKE service.  These fallback functions may be beyond that
required for the protocol as specified, but they're not beyond that required
for implementations that use the protocol.  So, assuming we agree on these
semantics, this will be documented in the draft but it will documented as an
optional function.

I hope this helps.  Lee

----- Original Message -----
From: <Man.M.Li@nokia.com>
To: <evyncke@cisco.com>; <ipsec-policy@imc.org>
Sent: Tuesday, February 06, 2001 11:20 AM
Subject: RE: DMTF SAAction restriction


> Correct me if I am wrong. But why cannot the three tries be bundled into
one
> action with multiple proposals? My understanding is that the purpose of
> having multiple proposals is exactly such that if the responder cannot
> accept the first one (hence fails), it has the choice to choose another
one
> from the list.
>
> Man Li
> Nokia
> 5 Wayside Road, Burlington, MA 01803
> man.m.li@nokia.com
> phone 1-781-993-3923
> GSM 1-781-492-2850
>
> -----Original Message-----
> From: ext Eric Vyncke [mailto:evyncke@cisco.com]
> Sent: Tuesday, February 06, 2001 11:17 AM
> To: Man.M.Li@nokia.com; ipsec-policy@imc.org
> Subject: RE: DMTF SAAction restriction
>
>
> We talked about different things:
>
> 1) when ISAKMP is trying to build a SA, it sends multiple proposals
>
> 2) in the DMTF model, for one data traffic pattern, multiple actions are
> tried
> until success:
>     a) let's try ISAKMP with 3DES+RSA or 3DES-pre-shared with SG1
>     b) if it fails, let's try ISAKMP with 3DES+RSA or 3DES-pre-shared with
> SG2
>     c) if it fails, let's try DES-pre-shared with SG3
>
> Obviously, the DMTF model allows the configuration of a complex IKE
proposal
> (see IKEProposal class which is associated to SANegotiationAction).
>
> Hope this helps
>
> -eric
>
> At 09:30 6/02/01 -0600, Man.M.Li@nokia.com wrote:
> >Is the "try until one succeeds" being described in any RFCs or is it only
> >ONE way of implementation? I recall ISAKMP allow initiator to propose
> >multiple proposals and multiple transforms for responder to choose from.
> But
> >I do not recall seeing this "try until one succeeds".
> >
> >
> >Man Li
> >Nokia
> >5 Wayside Road, Burlington, MA 01803
> >man.m.li@nokia.com
> >phone 1-781-993-3923
> >GSM 1-781-492-2850
> >
> >-----Original Message-----
> >From: ext Lee Rafalow [mailto:rafalow@raleigh.ibm.com]
> >Sent: Tuesday, February 06, 2001 9:48 AM
> >To: ipsec-policy@imc.org
> >Subject: Re: DMTF SAAction restriction
> >
> >
> >The approach that we've thought through so far would use your first
example
> >to set up the tunnel.  We could explore your suggestion to add a sematic
to
> >the action list, but that complicates it significantly.  We already have
> >semantics for the initiator and responder that are variations on "try
until
> >one succeeds."  Recall that for the initiator it's try the first one, if
> >that fails try the second, etc.  For the responder it's a little more
> >complicated: respond from the first action that is appropriate to the
> >request (this allows a single rule to deal with both aggressive and main
> >mode requests).
> >
> >
> >To add semantics for "do ordered list of actions" would require a fairly
> >complicated grammar for grouping actions into execution strategy groups
(do
> >all, do first successful).
> >
> >A way out of this might be to use the structured rules being proposed in
> the
> >PCIM Extensions draft (currently being written) but that'll have to wait
> >until we have a PCIMe draft to discuss.
> >
> >Lee
> >----- Original Message -----
> >From: <Man.M.Li@nokia.com>
> >To: <HORMAN@novell.com>; <ipsec-policy@imc.org>; <jamie.jason@intel.com>;
> ><Man.M.Li@nokia.com>
> >Sent: Monday, February 05, 2001 4:14 PM
> >Subject: RE: DMTF SAAction restriction
> >
> >
> >> Security per se may not be a problem. But if only a small percentage of
> >> traffic needs multiple nested protection and we end up with giving all
> the
> >> traffic multiple protections, it would be a waste of resources (e.g.,
> >> processing resource for encryption). Security comes with a price and I
> >> question if service providers or corporate IT managers will be happy
> about
> >> giving the free ride at the expense of network resources.
> >>
> >> Man Li
> >> Nokia
> >> 5 Wayside Road, Burlington, MA 01803
> >> man.m.li@nokia.com
> >> phone 1-781-993-3923
> >> GSM 1-781-492-2850
> >>
> >> -----Original Message-----
> >> From: ext Hilarie Orman [mailto:HORMAN@novell.com]
> >> Sent: Monday, February 05, 2001 3:10 PM
> >> To: ipsec-policy@imc.org; jamie.jason@intel.com; Man.M.Li@nokia.com
> >> Subject: RE: DMTF SAAction restriction
> >>
> >>
> >> Why would it be erroneous to include a tunnel gratuitously?
> >> Wrt to security, what is the problem?
> >>
> >> Hilarie
> >>
> >> >>> <Man.M.Li@nokia.com> 02/05/01 11:22AM >>>
> >> What selectors are you looking for in your second search after the
> >transport
> >> rule? Is it a selector for the already encrypted packets (hence
protocol
> =
> >> ESP, for example) or for the original packets (protocol = tcp)? I see
> >> problems in both cases. In the first case, if there is a rule to set up
a
> >> tunnel for ESP packets, we may include some other traffic that are ESP
> >> transport protected but should not be included in the tunnel. In other
> >> words, those traffic should only be transport protected.
> >>
> >> In the second case, we cannot reach the second selector for tunnel set
up
> >> because first matches will stop the search.
> >>
> >> A simple solution would be to remove the restriction and let SAActions
to
> >> indicate an ordered list of actions to be executed.
> >>
> >> Man Li
> >> Nokia
> >> 5 Wayside Road, Burlington, MA 01803
> >> man.m.li@nokia.com
> >> phone 1-781-993-3923
> >> GSM 1-781-492-2850
> >>
> >> -----Original Message-----
> >> From: ext Jason, Jamie [mailto:jamie.jason@intel.com]
> >> Sent: Monday, February 05, 2001 11:01 AM
> >> To: 'Man.M.Li@nokia.com'; ipsec-policy@imc.org
> >> Subject: RE: DMTF SAAction restriction
> >>
> >>
> >> Lee can correct me if I am wrong on this one, but I believe we had this
> >same
> >> discussion during a conference call between Lee, Eric Vyncke, and
myself.
> >I
> >> believe the solution we came up with was that policy evaluation would
> >first
> >> encounter the transport rule.  Policy evaluation would then search to
> >> determine if there was a tunnel rule that would apply (it would do this
> >> recursively as you may have tunnels in tunnels).  This update probably
> >> hasn't hit the MOF file or whitepaper yet.
> >>
> >> Jamie
> >>
> >> > -----Original Message-----
> >> > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
> >> > Sent: Monday, February 05, 2001 7:16 AM
> >> > To: ipsec-policy@imc.org
> >> > Subject: DMTF SAAction restriction
> >> >
> >> >
> >> > Hi,
> >> >
> >> > The DMTF policy model Section 3 first paragraph indicates
> >> > "The IPsec model
> >> > restricts the use of SAActions to an ordered choice rather
> >> > than a list of
> >> > actions to be executed." I am wondering how the following
> >> > situation would be
> >> > handled with this restriction. We had similar discussions
> >> > among IPsec PIB
> >> > authors.
> >> >
> >> >        A (host)===========C(gateway)---B(host)
> >> >
> >> > A and C are connected to public Internet and B is connected
> >> > to C. To protect
> >> > TCP traffic between hosts A and B, an IPsec security association in
> >> > transport mode needs to be established between hosts A and B.
> >> > In addition,
> >> > an IPsec security association in tunnel mode may be set up
> >> > between host A
> >> > and the gateway C that protects the LAN host B resides.
> >> >
> >> > In this case, A takes one action to set up an association
> >> > between A and B.
> >> > In addition, A should also set up a tunnel between A and C.
> >> > From A's point
> >> > of view, there are MULTIPLE actions to be taken in that order.
> >> >
> >> > How would you specify a policy to A if you are not allowed to
> >> > specify a list
> >> > of actions to be executed?
> >> >
> >> >
> >> > Man Li
> >> > Nokia
> >> > 5 Wayside Road, Burlington, MA 01803
> >> > man.m.li@nokia.com
> >> > phone 1-781-993-3923
> >> > GSM 1-781-492-2850
> >> >
>
> Eric Vyncke
> Distinguished Engineer             Cisco Systems EMEA
> Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
> E-mail: evyncke@cisco.com          Mobile: +32-475-312.458
> PGP Key available on request       MOBILE HAS CHANGED ON 11th November
2000



From owner-ipsec-policy@mail.vpnc.org  Tue Feb  6 15:20:52 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00771
	for <ipsp-archive@odin.ietf.org>; Tue, 6 Feb 2001 15:20:51 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA27582
	for ipsec-policy-bks; Tue, 6 Feb 2001 11:14:02 -0800 (PST)
Received: from wanderer.hardakers.net (IDENT:root@dns2.hardaker.davis.ca.us [168.150.190.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA27573
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 11:13:58 -0800 (PST)
Received: (from hardaker@localhost)
	by wanderer.hardakers.net (8.9.3/8.9.3) id LAA09761;
	Tue, 6 Feb 2001 11:24:04 -0800
X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f
To: "Jason, Jamie" <jamie.jason@intel.com>
Cc: "'Wes Hardaker'" <wes@hardakers.net>, ipsec-policy <ipsec-policy@imc.org>
Subject: Re: draft-ietf-ipsp-config-policy-model comments
References: <794826DE8867D411BAB8009027AE9EB904DD7A23@FMSMSX38>
From: Wes Hardaker <wes@hardakers.net>
X-URL: http://dcas.ucdavis.edu/~hardaker
Organization: Network Associates - NAI Labs
X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA
 SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/
 IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4
Date: 06 Feb 2001 11:24:03 -0800
In-Reply-To: <794826DE8867D411BAB8009027AE9EB904DD7A23@FMSMSX38>
Message-ID: <sdvgqnsjho.fsf@wanderer.hardakers.net>
Lines: 33
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.2 (Notus)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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>

>>>>> On Tue, 6 Feb 2001 09:16:57 -0800 , "Jason, Jamie" <jamie.jason@intel.com> said:

Jason> The above mentioned classes are concrete in the DMTF version of
Jason> the model, which is used as the basis for the IETF model.  At
Jason> this time, it escapes me why this is so in the DMTF model -
Jason> maybe Lee Rafalow can help me here and jog my memory.

Is it a requirement that derived classes from concrete can't be abstract?

>> 5) Section 6.2 which describes "The Class SAStaticAction" says that it
>> "serves as the base class for IKE and IPsec actions that
>> do not require negotiation.
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 
>> But yet, section 6.2.1 "The property LifetimeSeconds" describes the
>> property value with "A non-zero value is typically used in
>> conjunction with fallback actions performed when there is a
>> negotiation failure of some sort."
>> ^^^^^^^^^^^^^^^^^^^

Jason> Another cut and paste error.  There should be no mention of negotiation,
Jason> either explicitly or implicitly in this section.

I originally thought it was a cut-and-paste kind of error and
shouldn't be specified, but when I was writing the above note I
re-read it and wondered if you actually intended to say what my
re-phrasing attempted to clarify.  I'm actually much happier that
you'll be dropping that notion altogether.

-- 
Wes Hardaker
NAI Labs
Network Associates


From owner-ipsec-policy@mail.vpnc.org  Tue Feb  6 15:30:24 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01048
	for <ipsp-archive@odin.ietf.org>; Tue, 6 Feb 2001 15:30:24 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id LAA28100
	for ipsec-policy-bks; Tue, 6 Feb 2001 11:22:38 -0800 (PST)
Received: from ogma.cisco.com (ogma.cisco.com [144.254.74.39])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA28095
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 11:22:36 -0800 (PST)
Received: from brussels.cisco.com (brussels.cisco.com [144.254.15.68])
	by ogma.cisco.com (Postfix) with ESMTP
	id E0E2E117; Tue,  6 Feb 2001 20:29:25 +0100 (MET)
Received: from evyncke-8kcdt.cisco.com (evyncke-isdn-home.cisco.com [10.49.1.170])
	by brussels.cisco.com (8.8.8+Sun/8.8.8) with ESMTP id UAA14323;
	Tue, 6 Feb 2001 20:29:18 +0100 (MET)
Message-Id: <4.3.2.7.2.20010206202313.00c34220@brussels.cisco.com>
X-Sender: evyncke@brussels.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 06 Feb 2001 20:30:02 +0100
To: "Wang, Cliff" <CWang@smartpipes.com>, ipsec-policy@imc.org
From: Eric Vyncke <evyncke@cisco.com>
Subject: RE: DMTF SAAction restriction
In-Reply-To: <8E1E94178828D143B34A560A7A6F2C0B0199AC58@mailmaestro.smart
 pipes.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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 17:44 6/02/01 +0000, Wang, Cliff wrote:
>I am confused.....

Sorry for the confusion.

>First, for one data traffic pattern example in 2) below, 
>why we try 3 gateways? Are you talking about redundancy? 

In the attached example, I used redundancy design for simplicity
sake.

>In Man's example, we are
>talking about one tunnel nested in another one. Both tunnels
>need to be set up. The inside tunnel is between A and B. The 
>outside tunnel is between A and C. There is no trial and fail allowed. 
>
>I think that we are talking about different things.

This is indeed different. The redundancy example was using different
policies to be applied to one specific traffic until success. 

Nested tunnels is about applying simultaneously multiple policies with 
two different SArules:
1) one rule for IP traffic from host A to internal host B => transport mode
2) one rule for IP traffic from host A to all hosts protected by
security gateway C => tunnel mode

SARules must be ordered (usually you should put the transport mode rules
before the tunnel mode rules) so that rule 1) is first fired, generating
IKE/IPSec traffic which in turn fires rule 2).

NB: the scheme can be extended to cope with redundancy for the security
gateway ;-)

Hope this helps

-eric

>-----Original Message-----
>From: Eric Vyncke [mailto:evyncke@cisco.com]
>Sent: Tuesday, February 06, 2001 11:17 AM
>To: Man.M.Li@nokia.com; ipsec-policy@imc.org
>Subject: RE: DMTF SAAction restriction
>
>
>We talked about different things:
>
>1) when ISAKMP is trying to build a SA, it sends multiple proposals
>
>2) in the DMTF model, for one data traffic pattern, multiple actions are
>tried
>until success:
>    a) let's try ISAKMP with 3DES+RSA or 3DES-pre-shared with SG1
>    b) if it fails, let's try ISAKMP with 3DES+RSA or 3DES-pre-shared with
>SG2
>    c) if it fails, let's try DES-pre-shared with SG3
>
>Obviously, the DMTF model allows the configuration of a complex IKE proposal
>(see IKEProposal class which is associated to SANegotiationAction).
>
>Hope this helps
>
>-eric

Eric Vyncke                        
Distinguished Engineer             Cisco Systems EMEA
Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
E-mail: evyncke@cisco.com          Mobile: +32-475-312.458
PGP Key available on request       MOBILE HAS CHANGED ON 11th November 2000



From owner-ipsec-policy@mail.vpnc.org  Wed Feb  7 01:28:18 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13985
	for <ipsp-archive@odin.ietf.org>; Wed, 7 Feb 2001 01:28:16 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id VAA21845
	for ipsec-policy-bks; Tue, 6 Feb 2001 21:30:09 -0800 (PST)
Received: from web10502.mail.yahoo.com (web10502.mail.yahoo.com [216.136.130.152])
	by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA21838
	for <ipsec-policy@vpnc.org>; Tue, 6 Feb 2001 21:30:05 -0800 (PST)
Message-ID: <20010207053722.14320.qmail@web10502.mail.yahoo.com>
Received: from [198.206.187.100] by web10502.mail.yahoo.com; Tue, 06 Feb 2001 21:37:22 PST
Date: Tue, 6 Feb 2001 21:37:22 -0800 (PST)
From: Mahadevan Iyer <iyermahadevan@yahoo.com>
Subject: Re: IPSP Use of FilterEntry (Re: Preliminary results from PCIMe technical meeting, 1/24/01 - 1/26/01)
To: Lee Rafalow <rafalow@raleigh.ibm.com>, policy@raleigh.ibm.com
Cc: ipsec-policy@vpnc.org
In-Reply-To: <001a01c09047$a3d818e0$11312509@raleigh.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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>

--- Lee Rafalow <rafalow@raleigh.ibm.com> wrote:
> That said, in the long run whether we use
> FilterEntry or
> PolicyVariable/PolicyValue pairs is tbd, but the
> answer will lie in how the
> IPSP WG sees the trade-offs between common policy
> representation vs. a model
> that's close to its device-level implementation.

What is the device-level implementation aspect that
points to FilterEntries. As far as I know IKE itself
has a notion of proxy id's(not filterentries) which at
this point are specified as IP subnets. 

Thanks

__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices.
http://auctions.yahoo.com/


From owner-ipsec-policy@mail.vpnc.org  Wed Feb  7 02:24:27 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26026
	for <ipsp-archive@odin.ietf.org>; Wed, 7 Feb 2001 02:24:26 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id WAA22749
	for ipsec-policy-bks; Tue, 6 Feb 2001 22:16:41 -0800 (PST)
Received: from mail.network.de (fw.web2cad.de [62.225.10.125])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA22744
	for <ipsec-policy@imc.org>; Tue, 6 Feb 2001 22:16:38 -0800 (PST)
Received: from mailout.genius.de (notes.web2cad.de [10.2.0.3])
	by mail.network.de (8.9.3/8.9.3) with SMTP id HAA26036;
	Wed, 7 Feb 2001 07:23:46 +0100
Received: from web2cad.de ([10.10.11.213]) by mailout.genius.de (Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) with SMTP id 412569EC.0022F167; Sat, 7 Feb 1970 07:29:44 +0100
Message-ID: <3A80E9E2.3E4746CD@web2cad.de>
Date: Wed, 07 Feb 2001 07:23:30 +0100
From: vincent <vincent@web2cad.de>
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14 i686)
X-Accept-Language: de
MIME-Version: 1.0
To: "Wang, Cliff" <CWang@smartpipes.com>
CC: "'Jason, Jamie'" <jamie.jason@intel.com>,
        "'Man.M.Li@nokia.com'" <Man.M.Li@nokia.com>, evyncke@cisco.com,
        ipsec-policy@imc.org
Subject: Re: DMTF SAAction restriction
References: <8E1E94178828D143B34A560A7A6F2C0B0199AC5A@mailmaestro.smartpipes.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>
Content-Transfer-Encoding: 7bit

"Wang, Cliff" wrote:
> 
> Thanks for the clarifications.
> 
> Then the trial and switch by failure is really addressing a different
> issue, which is providing redundant IKE connection.
> 
> The original question is on how to set up policy for nested tunnels.
> 
> -----Original Message-----
> From: Jason, Jamie [mailto:jamie.jason@intel.com]
> Sent: Tuesday, February 06, 2001 12:06 PM
> To: 'Man.M.Li@nokia.com'; evyncke@cisco.com; ipsec-policy@imc.org
> Subject: RE: DMTF SAAction restriction
> 
> The ability to try different actions until one succeeds was not created as a
> way to subvert the IKE proposal mechanism (i.e., we don't want it used to
> try one proposal, and then if that fails, try another, etc.).  This came out
> of discussions we had with regard to establishing tunnels.  For example, I
> have several different machines I can contact to establish a VPN connection
> into Intel.  I would set up my actions such that my machine would first
> attempt to establish a tunnel to the Jones Farm server, if that fails, I
> would then try to establish a tunnel to the Santa Clara server, etc.
> 
> Hopes this helps.
> 
> Jamie
> 
> > -----Original Message-----
> > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
> > Sent: Tuesday, February 06, 2001 8:20 AM
> > To: evyncke@cisco.com; ipsec-policy@imc.org
> > Subject: RE: DMTF SAAction restriction
> >
> >
> > Correct me if I am wrong. But why cannot the three tries be
> > bundled into one
> > action with multiple proposals? My understanding is that the
> > purpose of
> > having multiple proposals is exactly such that if the responder cannot
> > accept the first one (hence fails), it has the choice to
> > choose another one
> > from the list.
> >
> > Man Li
> > Nokia
> > 5 Wayside Road, Burlington, MA 01803
> > man.m.li@nokia.com
> > phone 1-781-993-3923
> > GSM 1-781-492-2850
> >
> > -----Original Message-----
> > From: ext Eric Vyncke [mailto:evyncke@cisco.com]
> > Sent: Tuesday, February 06, 2001 11:17 AM
> > To: Man.M.Li@nokia.com; ipsec-policy@imc.org
> > Subject: RE: DMTF SAAction restriction
> >
> >
> > We talked about different things:
> >
> > 1) when ISAKMP is trying to build a SA, it sends multiple proposals
> >
> > 2) in the DMTF model, for one data traffic pattern, multiple
> > actions are
> > tried
> > until success:
> >     a) let's try ISAKMP with 3DES+RSA or 3DES-pre-shared with SG1
> >     b) if it fails, let's try ISAKMP with 3DES+RSA or
> > 3DES-pre-shared with
> > SG2
> >     c) if it fails, let's try DES-pre-shared with SG3
> >
> > Obviously, the DMTF model allows the configuration of a
> > complex IKE proposal
> > (see IKEProposal class which is associated to SANegotiationAction).
> >
> > Hope this helps
> >
> > -eric
> >
> > At 09:30 6/02/01 -0600, Man.M.Li@nokia.com wrote:
> > >Is the "try until one succeeds" being described in any RFCs
> > or is it only
> > >ONE way of implementation? I recall ISAKMP allow initiator to propose
> > >multiple proposals and multiple transforms for responder to
> > choose from.
> > But
> > >I do not recall seeing this "try until one succeeds".
> > >
> > >
> > >Man Li
> > >Nokia
> > >5 Wayside Road, Burlington, MA 01803
> > >man.m.li@nokia.com
> > >phone 1-781-993-3923
> > >GSM 1-781-492-2850
> > >
> > >-----Original Message-----
> > >From: ext Lee Rafalow [mailto:rafalow@raleigh.ibm.com]
> > >Sent: Tuesday, February 06, 2001 9:48 AM
> > >To: ipsec-policy@imc.org
> > >Subject: Re: DMTF SAAction restriction
> > >
> > >
> > >The approach that we've thought through so far would use
> > your first example
> > >to set up the tunnel.  We could explore your suggestion to
> > add a sematic to
> > >the action list, but that complicates it significantly.  We
> > already have
> > >semantics for the initiator and responder that are
> > variations on "try until
> > >one succeeds."  Recall that for the initiator it's try the
> > first one, if
> > >that fails try the second, etc.  For the responder it's a little more
> > >complicated: respond from the first action that is appropriate to the
> > >request (this allows a single rule to deal with both
> > aggressive and main
> > >mode requests).
> > >
> > >
> > >To add semantics for "do ordered list of actions" would
> > require a fairly
> > >complicated grammar for grouping actions into execution
> > strategy groups (do
> > >all, do first successful).
> > >
> > >A way out of this might be to use the structured rules being
> > proposed in
> > the
> > >PCIM Extensions draft (currently being written) but that'll
> > have to wait
> > >until we have a PCIMe draft to discuss.
> > >
> > >Lee
> > >----- Original Message -----
> > >From: <Man.M.Li@nokia.com>
> > >To: <HORMAN@novell.com>; <ipsec-policy@imc.org>;
> > <jamie.jason@intel.com>;
> > ><Man.M.Li@nokia.com>
> > >Sent: Monday, February 05, 2001 4:14 PM
> > >Subject: RE: DMTF SAAction restriction
> > >
> > >
> > >> Security per se may not be a problem. But if only a small
> > percentage of
> > >> traffic needs multiple nested protection and we end up
> > with giving all
> > the
> > >> traffic multiple protections, it would be a waste of
> > resources (e.g.,
> > >> processing resource for encryption). Security comes with a
> > price and I
> > >> question if service providers or corporate IT managers
> > will be happy
> > about
> > >> giving the free ride at the expense of network resources.
> > >>
> > >> Man Li
> > >> Nokia
> > >> 5 Wayside Road, Burlington, MA 01803
> > >> man.m.li@nokia.com
> > >> phone 1-781-993-3923
> > >> GSM 1-781-492-2850
> > >>
> > >> -----Original Message-----
> > >> From: ext Hilarie Orman [mailto:HORMAN@novell.com]
> > >> Sent: Monday, February 05, 2001 3:10 PM
> > >> To: ipsec-policy@imc.org; jamie.jason@intel.com; Man.M.Li@nokia.com
> > >> Subject: RE: DMTF SAAction restriction
> > >>
> > >>
> > >> Why would it be erroneous to include a tunnel gratuitously?
> > >> Wrt to security, what is the problem?
> > >>
> > >> Hilarie
> > >>
> > >> >>> <Man.M.Li@nokia.com> 02/05/01 11:22AM >>>
> > >> What selectors are you looking for in your second search after the
> > >transport
> > >> rule? Is it a selector for the already encrypted packets
> > (hence protocol
> > =
> > >> ESP, for example) or for the original packets (protocol =
> > tcp)? I see
> > >> problems in both cases. In the first case, if there is a
> > rule to set up a
> > >> tunnel for ESP packets, we may include some other traffic
> > that are ESP
> > >> transport protected but should not be included in the
> > tunnel. In other
> > >> words, those traffic should only be transport protected.
> > >>
> > >> In the second case, we cannot reach the second selector
> > for tunnel set up
> > >> because first matches will stop the search.
> > >>
> > >> A simple solution would be to remove the restriction and
> > let SAActions to
> > >> indicate an ordered list of actions to be executed.
> > >>
> > >> Man Li
> > >> Nokia
> > >> 5 Wayside Road, Burlington, MA 01803
> > >> man.m.li@nokia.com
> > >> phone 1-781-993-3923
> > >> GSM 1-781-492-2850
> > >>
> > >> -----Original Message-----
> > >> From: ext Jason, Jamie [mailto:jamie.jason@intel.com]
> > >> Sent: Monday, February 05, 2001 11:01 AM
> > >> To: 'Man.M.Li@nokia.com'; ipsec-policy@imc.org
> > >> Subject: RE: DMTF SAAction restriction
> > >>
> > >>
> > >> Lee can correct me if I am wrong on this one, but I
> > believe we had this
> > >same
> > >> discussion during a conference call between Lee, Eric
> > Vyncke, and myself.
> > >I
> > >> believe the solution we came up with was that policy
> > evaluation would
> > >first
> > >> encounter the transport rule.  Policy evaluation would
> > then search to
> > >> determine if there was a tunnel rule that would apply (it
> > would do this
> > >> recursively as you may have tunnels in tunnels).  This
> > update probably
> > >> hasn't hit the MOF file or whitepaper yet.
> > >>
> > >> Jamie
> > >>
> > >> > -----Original Message-----
> > >> > From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
> > >> > Sent: Monday, February 05, 2001 7:16 AM
> > >> > To: ipsec-policy@imc.org
> > >> > Subject: DMTF SAAction restriction
> > >> >
> > >> >
> > >> > Hi,
> > >> >
> > >> > The DMTF policy model Section 3 first paragraph indicates
> > >> > "The IPsec model
> > >> > restricts the use of SAActions to an ordered choice rather
> > >> > than a list of
> > >> > actions to be executed." I am wondering how the following
> > >> > situation would be
> > >> > handled with this restriction. We had similar discussions
> > >> > among IPsec PIB
> > >> > authors.
> > >> >
> > >> >        A (host)===========C(gateway)---B(host)
> > >> >
> > >> > A and C are connected to public Internet and B is connected
> > >> > to C. To protect
> > >> > TCP traffic between hosts A and B, an IPsec security
> > association in
> > >> > transport mode needs to be established between hosts A and B.
> > >> > In addition,
> > >> > an IPsec security association in tunnel mode may be set up
> > >> > between host A
> > >> > and the gateway C that protects the LAN host B resides.
> > >> >
> > >> > In this case, A takes one action to set up an association
> > >> > between A and B.
> > >> > In addition, A should also set up a tunnel between A and C.
> > >> > From A's point
> > >> > of view, there are MULTIPLE actions to be taken in that order.
> > >> >
> > >> > How would you specify a policy to A if you are not allowed to
> > >> > specify a list
> > >> > of actions to be executed?
> > >> >
> > >> >
> > >> > Man Li
> > >> > Nokia
> > >> > 5 Wayside Road, Burlington, MA 01803
> > >> > man.m.li@nokia.com
> > >> > phone 1-781-993-3923
> > >> > GSM 1-781-492-2850
> > >> >
> >
> > Eric Vyncke
> > Distinguished Engineer             Cisco Systems EMEA
> > Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
> > E-mail: evyncke@cisco.com          Mobile: +32-475-312.458
> > PGP Key available on request       MOBILE HAS CHANGED ON 11th
> > November 2000
> >
Please can everybody tell me, how i unsubscribe that mailinglist
ipsec.policy from my
mailing account!
Please give me an answer!
Thanks!

Christian


From owner-ipsec-policy@mail.vpnc.org  Wed Feb  7 11:00:12 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02332
	for <ipsp-archive@odin.ietf.org>; Wed, 7 Feb 2001 11:00:11 -0500 (EST)
Received: (from majordomo@localhost)
	by ns.secondary.com (8.9.3/8.9.3) id GAA11602
	for ipsec-policy-bks; Wed, 7 Feb 2001 06:27:19 -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 GAA11598
	for <ipsec-policy@vpnc.org>; Wed, 7 Feb 2001 06:27:18 -0800 (PST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id JAA21252
	for <ipsec-policy@vpnc.org>; Wed, 7 Feb 2001 09:34:08 -0500
Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA12602;
	Wed, 7 Feb 2001 09:34:10 -0500
Message-ID: <003e01c09112$d07a78e0$11312509@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: <policy@raleigh.ibm.com>
Cc: <ipsec-policy@vpnc.org>
References: <20010207053722.14320.qmail@web10502.mail.yahoo.com>
Subject: Re: IPSP Use of FilterEntry (Re: Preliminary results from PCIMe technical meeting, 1/24/01 - 1/26/01)
Date: Wed, 7 Feb 2001 09:32:34 -0500
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.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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>
Content-Transfer-Encoding: 7bit

Mahadevan,

First, let's make sure everyone understands that the IPSP model is for a PEP
not for a PDP.  It's a device-level configuration model of an IKE service
and related stack components in a security client or security gateway; it's
not a domain policy.

Implementations vary, of course, but the notion that filter entries are
closer to a device-level policy implementation has to do with the fact that
parsing a general grammar (Variable, Operator, Value) is not the most
efficient implementation of a filter.  One of our implementations, for
example, uses the stack's 5-tuple filters to not only find the outbound SAs
but to also test the address-based conditions for the rules...it's pretty
efficient.  A parser for the VOV syntax wouldn't be implemented in that
product.

But that doesn't mean we shouldn't express the conditions in a VOV syntax in
the information model just that there are trade-offs.  It's very tempting to
try to find an algorithmic mapping from an information model to an
implementable data model.  Such a mapping for VOV won't even be close for
some implementations whereas it'll be close for Filters.  But as long as the
PIB, MIB, LDAP, et al mapping activities aren't tempted to do that, then
this concern is diminished.

Another thing to consider here is that a general grammar can specify
conditions that a PEP might not be able to parse into its limited set of
filter options.  A PDP can take a general specification of a domain-level
policy and map it to a set of device-level policies that match the
capabilities of a given PEP.  A PEP cannot be expected to handle any policy,
just the ones appropriate for it.  This concern doesn't disappear if we use
filters, but it's easier to spot the conditions that can be specified that
may not be supported.

Just a few things to consider.  Cheers, Lee

----- Original Message -----
From: "Mahadevan Iyer" <iyermahadevan@yahoo.com>
To: "Lee Rafalow" <rafalow@raleigh.ibm.com>; <policy@raleigh.ibm.com>
Cc: <ipsec-policy@vpnc.org>
Sent: Wednesday, February 07, 2001 12:37 AM
Subject: Re: IPSP Use of FilterEntry (Re: Preliminary results from PCIMe
technical meeting, 1/24/01 - 1/26/01)


> --- Lee Rafalow <rafalow@raleigh.ibm.com> wrote:
> > That said, in the long run whether we use
> > FilterEntry or
> > PolicyVariable/PolicyValue pairs is tbd, but the
> > answer will lie in how the
> > IPSP WG sees the trade-offs between common policy
> > representation vs. a model
> > that's close to its device-level implementation.
>
> What is the device-level implementation aspect that
> points to FilterEntries. As far as I know IKE itself
> has a notion of proxy id's(not filterentries) which at
> this point are specified as IP subnets.
>
> Thanks
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Auctions - Buy the things you want at great prices.
> http://auctions.yahoo.com/
>



From owner-ipsec-policy@mail.vpnc.org  Wed Feb  7 11:03:39 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02395
	for <ipsp-archive@odin.ietf.org>; Wed, 7 Feb 2001 11:03:39 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id GAA12202
	for ipsec-policy-bks; Wed, 7 Feb 2001 06:38:08 -0800 (PST)
Received: from wanderer.hardakers.net (IDENT:root@dns2.hardaker.davis.ca.us [168.150.190.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12196
	for <ipsec-policy@vpnc.org>; Wed, 7 Feb 2001 06:38:06 -0800 (PST)
Received: (from hardaker@localhost)
	by wanderer.hardakers.net (8.9.3/8.9.3) id GAA18374;
	Wed, 7 Feb 2001 06:48:05 -0800
X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f
To: "Lee Rafalow" <rafalow@raleigh.ibm.com>
Cc: <ipsec-policy@vpnc.org>, "Victor Lortz" <victor.lortz@intel.com>
Subject: Re: draft-ietf-ipsp-config-policy-model comments
References: <794826DE8867D411BAB8009027AE9EB904DD7A23@FMSMSX38>
	<00ff01c0906e$372444e0$11312509@raleigh.ibm.com>
From: Wes Hardaker <wes@hardakers.net>
X-URL: http://dcas.ucdavis.edu/~hardaker
Organization: Network Associates - NAI Labs
X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA
 SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/
 IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4
Date: 07 Feb 2001 06:48:05 -0800
In-Reply-To: <00ff01c0906e$372444e0$11312509@raleigh.ibm.com>
Message-ID: <sdbsser1lm.fsf@wanderer.hardakers.net>
Lines: 10
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.2 (Notus)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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>

>>>>> On Tue, 6 Feb 2001 13:54:19 -0500, "Lee Rafalow" <rafalow@raleigh.ibm.com> said:

Lee> PolicyRule is concrete so SARule needs to be concrete.

Is this mandated by the definition language?

-- 
Wes Hardaker
NAI Labs
Network Associates


From owner-ipsec-policy@mail.vpnc.org  Wed Feb  7 11:45:23 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03329
	for <ipsp-archive@odin.ietf.org>; Wed, 7 Feb 2001 11:45:23 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id HAA13807
	for ipsec-policy-bks; Wed, 7 Feb 2001 07:09:21 -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 HAA13802
	for <ipsec-policy@vpnc.org>; Wed, 7 Feb 2001 07:09:19 -0800 (PST)
Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA32024;
	Wed, 7 Feb 2001 10:15:56 -0500
Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17])
	by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id KAA24718;
	Wed, 7 Feb 2001 10:15:49 -0500
Message-ID: <006401c09118$a26bf2c0$11312509@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: <ipsec-policy@vpnc.org>
Cc: "Victor Lortz" <victor.lortz@intel.com>
References: <794826DE8867D411BAB8009027AE9EB904DD7A23@FMSMSX38><00ff01c0906e$372444e0$11312509@raleigh.ibm.com> <sdbsser1lm.fsf@wanderer.hardakers.net>
Subject: Re: draft-ietf-ipsp-config-policy-model comments
Date: Wed, 7 Feb 2001 09:58:47 -0500
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.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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>
Content-Transfer-Encoding: 7bit

Yes, in CIM, which is our foundation for these classes, abstract can only
derive from abstract.  Lee

----- Original Message -----
From: "Wes Hardaker" <wes@hardakers.net>
To: "Lee Rafalow" <rafalow@raleigh.ibm.com>
Cc: <ipsec-policy@vpnc.org>; "Victor Lortz" <victor.lortz@intel.com>
Sent: Wednesday, February 07, 2001 9:48 AM
Subject: Re: draft-ietf-ipsp-config-policy-model comments


> >>>>> On Tue, 6 Feb 2001 13:54:19 -0500, "Lee Rafalow"
<rafalow@raleigh.ibm.com> said:
>
> Lee> PolicyRule is concrete so SARule needs to be concrete.
>
> Is this mandated by the definition language?
>
> --
> Wes Hardaker
> NAI Labs
> Network Associates
>



From owner-ipsec-policy@mail.vpnc.org  Wed Feb  7 12:55:53 2001
Received: from ns.secondary.com (ns.secondary.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04887
	for <ipsp-archive@odin.ietf.org>; Wed, 7 Feb 2001 12:55:52 -0500 (EST)
Received: by ns.secondary.com (8.9.3/8.9.3) id IAA20270
	for ipsec-policy-bks; Wed, 7 Feb 2001 08:25:28 -0800 (PST)
Received: from wanderer.hardakers.net (IDENT:root@dns2.hardaker.davis.ca.us [168.150.190.2])
	by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA20266
	for <ipsec-policy@imc.org>; Wed, 7 Feb 2001 08:25:26 -0800 (PST)
Received: (from hardaker@localhost)
	by wanderer.hardakers.net (8.9.3/8.9.3) id IAA19048;
	Wed, 7 Feb 2001 08:35:30 -0800
X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f
To: ipsec-policy@imc.org
Subject: dmtf white paper typo
From: Wes Hardaker <wes@hardakers.net>
X-URL: http://dcas.ucdavis.edu/~hardaker
Organization: Network Associates - NAI Labs
X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA
 SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/
 IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4
Date: 07 Feb 2001 08:35:30 -0800
Message-ID: <sd7l32pi25.fsf@wanderer.hardakers.net>
Lines: 10
User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.2 (Notus)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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 DMTF white paper has a typo on Page 11: "Figure 3 shows the
different..." which should say "Figure 4 shows the different..."
                                       ^

-- 
Wes Hardaker
NAI Labs
Network Associates


From owner-ipsec-policy@mail.vpnc.org  Thu Feb  8 17:55:26 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21210
	for <ipsp-archive@odin.ietf.org>; Thu, 8 Feb 2001 17:55:25 -0500 (EST)
Received: by above.proper.com (8.9.3/8.9.3) id NAA03659
	for ipsec-policy-bks; Thu, 8 Feb 2001 13:43:55 -0800 (PST)
Received: from hki-cesium1.fin.sonerazed.net (hki-smtp-1.fin.sonerazed.net [213.28.116.17])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA03655
	for <ipsec-policy@vpnc.org>; Thu, 8 Feb 2001 13:43:53 -0800 (PST)
From: bigjoe@japan.com
Received: from [63.24.178.219] by hki-cesium1.fin.sonerazed.net
          (InterMail vK.4.02.00.00 201-232-116 license 73185894472d214f558e80011438392a)
          with SMTP
          id <20010208214346.OIFH8208.hki-cesium1@[63.24.178.219]>;
          Thu, 8 Feb 2001 23:43:46 +0200
Received: from kili.otago.ac.nz by 1Cust219.tnt3.irving2.tx.da.uu.net with ESMTP; Thu, 08 Feb 2001 15:42:53 -0600
Message-ID: <00002e0e36a7$00006b24$00005a0f@kili.otago.ac.nz>
To: <j@horizontes.com.br>
Subject: Brand New E-Mail pager for FR-EE!                         23055
Date: Thu, 08 Feb 2001 15:42:45 -0600
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Reply-To: bigjoe@japan.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>
   Accessmate E-Mail display pager. This is the top of the line PCS technology
   pager made today. This side viewable display pager has a retail value of
   $189.00and comes with its own e-mail address so you can receive your e-mails
   as well as alpha-numeric and numeric messages instantly where ever you are.
   Your new e-mail pager has features like 50,000 character memory, message time
   stamping, automatic garbled message correction, beeps or vibrates,
   incandescent backlight, saved message folder, a unique never out of range
   feature that allows your pager to retrieve messages sent earlier when your
   pager was out of range or turned completely off. You can also receive
   weather, news and sports .The Motorola e-mail pager is very small and uses
   only a single double A battery. All we ask before we ship you your Free pager
   is for you to allow us to provide the airtime for you. There is no long term
   contract or credit check. Airtime is month to month and can be cancelled at
   any time. This pager will comes pre-programmed with its own e-mail address as
   well as a local telephone number to receive numeric pages. This pager comes
   with a complete 30 day money back guarantee, if after receiving this pager
   you're not completely happy, send it back and receive a full refund.
Content-Transfer-Encoding: 7bit

   For immediate delivery call Paging America at toll free at 877-699-8546















   Brand New E-Mail pager for FREE!

   No long term contract
   No activation fee
   No big prepayment of airtime
   No credit check

   PAGING AMERICA is going to give you absolutely Free the Brand new Motorola




From owner-ipsec-policy@mail.vpnc.org  Fri Feb  9 20:22:51 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05663
	for <ipsp-archive@odin.ietf.org>; Fri, 9 Feb 2001 20:22:49 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.9.3/8.9.3) id QAA12633
	for ipsec-policy-bks; Fri, 9 Feb 2001 16:02:46 -0800 (PST)
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA12627;
	Fri, 9 Feb 2001 16:02:42 -0800 (PST)
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <CTQSWK33>; Fri, 9 Feb 2001 19:02:32 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078C23@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'zeroconf@merit.edu'" <zeroconf@merit.edu>, seamoby@cdma-2000.org,
        MOBILE-IP@STANDARDS.NORTELNETWORKS.COM,
        "'srvloc@srvloc.org'"
	 <srvloc@srvloc.org>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>,
        "'manet@itd.nrl.navy.mil'" <manet@itd.nrl.navy.mil>,
        "'ipsec@lists.tislabs.com'" <ipsec@lists.tislabs.com>,
        "'ipsec-policy@vpnc.org'" <ipsec-policy@vpnc.org>,
        "'ietf-ipsra@vpnc.org'" <ietf-ipsra@vpnc.org>,
        "'ietf-sacred@imc.org'"
	 <ietf-sacred@imc.org>,
        "'enum@ietf.org'" <enum@ietf.org>,
        "'sigtran@standards.nortelnetworks.com'"
	 <sigtran@STANDARDS.NORTELNETWORKS.COM>,
        "'ietf@ietf.org'"
	 <ietf@ietf.org>,
        "'IETF-Announce@ietf.org'" <IETF-Announce@ietf.org>,
        "'BLUETOOTH-BOF@mailbag.cps.intel.com'"
	 <BLUETOOTH-BOF@mailbag.cps.intel.com>
Cc: "'Thomas Narten'" <narten@raleigh.ibm.com>,
        Akers Ron-WRA001
	 <Ron.Akers@motorola.com>
Subject: BOF:   IP over Bluetooth for 50th Meeting of IETF. 
Date: Fri, 9 Feb 2001 19:02:30 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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>


Myself and Ron Akers have requested an IP over Bluetooth BOF for the 50th
Meeting of the IETF in Minneapolis.  The BOF will discuss the creation of a
IETF Working Group to investigate the most open and efficient way to place
IP over the Bluetooth Host Controller.

Current work in this area within the Bluetooth SIG concentrates on defining
IP over a set of other lower-layer stacks. Currently there are two options
defined by the Bluetoth SIG:

 Option 1: IP/PPP/RFCOM/L2CAP/Host Controller

 Option 2: IP/PAN Profile/L2CAP/Host Controller
 	   (where the PAN Profile is a Bluetooth SIG work in progress)
 

We are proposing that the IETF form a WG to define a more efficient way of
running IP over Bluetooth. In particular, IP would run
 over an IETF protocol over the Host Controller without L2CAP.  This option
may be adopted by the Bluetooth SIG at a later date as a Profile.  Since all
Bluetooth SIG Profiles are optional, a customer may choose any combination
of Profiles in a final product.  Further, since Bluetooth Working Groups
have it in their mandate to adopt protocols from other standards making
bodies such as the IETF, there exists a clear path for IETF work to be
adopted by the Bluetooth SIG.
 
Whereas the last BOF was informational only and organized by the Bluetooth
SIG itself, the objective of this BOF will be to foster innovation, and
speed progress by placing IP related protocol development wihin the IETF and
Bluetooth-specific protocol development
 within the Bluetooth SIG, by developing an IP over Bluetooth IETF Working
Group.
 
This effort will define its own way of running IP over Bluetooth, by
carefully selecting a set of Bluetooth protocols (freely available from
published specifications at
http://www.bluetooth.com/developer/specification/specification.asp) on which
to build IP.

Please join myself, Kulwinder Atwal, and Ron Akers on the pre-BOF mailing
list:
 
This site runs version 2.0.1 of the "Mailman" list manager.  
The following describes commands you can send to get
information about, and control your subscription to the lists at
this site. Note that much of the following can also be 
accomplished via the World Wide Web, at:

    http://internet.motlabs.com/mailman/listinfo/bluetooth

In particular, you can use the Web site to have your password sent to
your delivery address.

Email commands can be in the subject line or in the body 
of the message. The commands should be set to the following address:

  <bluetooth-request@internet.motlabs.com>

About the descriptions - words in "<>"s signify REQUIRED items and
words in "[]" denote OPTIONAL items.  Do not include the "<>"s or
"[]"s when you use the commands.

The following commands are valid:

    subscribe [password] [digest-option] [address=<address>]
        Subscribe to the mailing list.  Your password must be given to
        unsubscribe or change your options.  When you subscribe to the
        list, you'll be reminded of your password periodically.
        'digest-option' may be either: 'nodigest' or 'digest' (no
        quotes!)  If you wish to subscribe an address other than the
        address you send this request from, you may specify
        "address=<email address>" (no brackets around the email
        address, no quotes!)

    unsubscribe <password> [address]
        Unsubscribe from the mailing list.  Your password must match
        the one you gave when you subscribed.  If you are trying to
        unsubscribe from a different address than the one you
        subscribed from, you may specify it in the 'address' field.

    who
        See everyone who is on this mailing list.

    info
        View the introductory information for this list.

    lists
        See what mailing lists are run by this Mailman server.

    help
        This message.

    set <option> <on|off> <password> 
        Turn on or off list options.  Valid options are:

        ack:
            Turn this on to receive acknowledgement mail when you send
            mail to the list.

        digest:
            Receive mail from the list bundled together instead of one
            post at a time.

        plain:
            Get plain-text, not MIME-compliant, digests (only if
            digest is set)

        nomail:
            Stop delivering mail.  Useful if you plan on taking a
            short vacation.

        norcv:
            Turn this on to NOT receive posts you send to the list.
            Does not work if digest is set.

        hide:
            Conceals your address when people look at who is on this
            list.


    options
        Show the current values of your list options.

    password <oldpassword> <newpassword> 
        Change your list password.
    
    end or --
       Stop processing commands (good to do if your mailer
       automatically adds a signature file - it'll save you from a lot
       of cruft).


Commands should be sent to bluetooth-request@internet.motlabs.com

Questions and concerns for the attention of a person should be sent to

    bluetooth-admin@internet.motlabs.com



Kulwinder Atwal
Bluetooth Design
Zucotto Wireless Inc.
kulwinder.atwal@zucotto.com

------------------------------------------------------------
Ron Akers                               Voice :(847)576-7928
Networks and Infrastructure Research      FAX :(847)576-3240
Motorola Laboratories           email:ron.akers@motorola.com 
1301 Algonquin Rd, Rm 2246
Schaumburg, IL. 60196
------------------------------------------------------------


From owner-ipsec-policy@mail.vpnc.org  Sun Feb 11 09:25:20 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09168
	for <ipsp-archive@odin.ietf.org>; Sun, 11 Feb 2001 09:25:20 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.9.3/8.9.3) id FAA15885
	for ipsec-policy-bks; Sun, 11 Feb 2001 05:19:35 -0800 (PST)
Received: from rip.psg.com (exim@rip.psg.com [147.28.0.39])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA15876;
	Sun, 11 Feb 2001 05:19:34 -0800 (PST)
Received: from randy by rip.psg.com with local (Exim 3.16 #1)
	id 14RwNr-000MOk-00; Sun, 11 Feb 2001 05:17:43 -0800
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "David Almer zahav" <almer@tadlys.com>
Cc: <zeroconf@merit.edu>, <seamoby@cdma-2000.org>,
        <MOBILE-IP@marvin.corpeast.baynetworks.com>, <srvloc@srvloc.org>,
        <aaa-wg@merit.edu>, <manet@itd.nrl.navy.mil>,
        <ipsec@lists.tislabs.com>, <ipsec-policy@vpnc.org>,
        <ietf-ipsra@vpnc.org>, <ietf-sacred@imc.org>, <enum@ietf.org>,
        <sigtran@marvin.corpeast.baynetworks.com>, <ietf@ietf.org>,
        <IETF-Announce@ietf.org>, <BLUETOOTH-BOF@mailbag.cps.intel.com>
Subject: Re: BOF: IP over Bluetooth for 50th Meeting of IETF.
References: <004f01c09429$3dceb1e0$589618ac@tadlys>
Message-Id: <E14RwNr-000MOk-00@rip.psg.com>
Date: Sun, 11 Feb 2001 05:17:43 -0800
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>
Content-Transfer-Encoding: 7bit

> Gentlemen,

> Please join myself, David Almer on the pre-BOF mailing list.

are women not welcome?

randy


From owner-ipsec-policy@mail.vpnc.org  Sun Feb 11 09:40:00 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09331
	for <ipsp-archive@odin.ietf.org>; Sun, 11 Feb 2001 09:40:00 -0500 (EST)
Received: by above.proper.com (8.9.3/8.9.3) id FAA15779
	for ipsec-policy-bks; Sun, 11 Feb 2001 05:09:43 -0800 (PST)
Received: from frigg.inter.net.il (frigg.inter.net.il [192.114.186.16])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA15731;
	Sun, 11 Feb 2001 05:05:28 -0800 (PST)
Received: from 1david.tadlys ([192.116.242.18])
	by frigg.inter.net.il (Mirapoint)
	with SMTP id AJR08293;
	Sun, 11 Feb 2001 14:47:24 +0200 (IST)
Message-ID: <004f01c09429$3dceb1e0$589618ac@tadlys>
From: "David Almer zahav" <almer@tadlys.com>
To: <zeroconf@merit.edu>, <seamoby@cdma-2000.org>,
        <MOBILE-IP@marvin.corpeast.baynetworks.com>, <srvloc@srvloc.org>,
        <aaa-wg@merit.edu>, <manet@itd.nrl.navy.mil>,
        <ipsec@lists.tislabs.com>, <ipsec-policy@vpnc.org>,
        <ietf-ipsra@vpnc.org>, <ietf-sacred@imc.org>, <enum@ietf.org>,
        <sigtran@marvin.corpeast.baynetworks.com>, <ietf@ietf.org>,
        <IETF-Announce@ietf.org>, <BLUETOOTH-BOF@mailbag.cps.intel.com>
Cc: "David Almer @tadlys" <almer@tadlys.com>
Subject: BOF: IP over Bluetooth for 50th Meeting of IETF.
Date: Sun, 11 Feb 2001 14:49:15 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_003A_01C09439.CE0A4480"
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_003A_01C09439.CE0A4480
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

Gentlemen,

Please join myself, David Almer on the pre-BOF mailing list.

Regards,
David Almer
Director Systems Engineering
Tadlys Ltd.
7 Oppenheimer St., Rehovot, Israel
tel:    972 - 8 - 936 6641
email: almer@tadlys.com
=20


------=_NextPart_000_003A_01C09439.CE0A4480
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1255" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Gentlemen,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Please join myself, David Almer on the =
pre-BOF=20
mailing list.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2><BR>Regards,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>David Almer</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Director Systems =
Engineering</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Tadlys&nbsp;Ltd.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>7 Oppenheimer St., Rehovot, =
Israel</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>tel:&nbsp;&nbsp;&nbsp; 972 - 8 - 936=20
6641</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>email:=20
almer@tadlys.com<BR>&nbsp;<BR></DIV></FONT></BODY></HTML>

------=_NextPart_000_003A_01C09439.CE0A4480--



From owner-ipsec-policy@mail.vpnc.org  Sun Feb 11 18:35:21 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13591
	for <ipsp-archive@odin.ietf.org>; Sun, 11 Feb 2001 18:35:21 -0500 (EST)
Received: by above.proper.com (8.9.3/8.9.3) id OAA27703
	for ipsec-policy-bks; Sun, 11 Feb 2001 14:06:49 -0800 (PST)
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA27694;
	Sun, 11 Feb 2001 14:06:47 -0800 (PST)
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <CTQSWK83>; Sun, 11 Feb 2001 17:06:34 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E3078C30@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Randy Bush'" <randy@psg.com>, David Almer zahav <almer@tadlys.com>
Cc: zeroconf@merit.edu, seamoby@cdma-2000.org,
        MOBILE-IP@marvin.corpeast.baynetworks.com, srvloc@srvloc.org,
        aaa-wg@merit.edu, manet@itd.nrl.navy.mil, ipsec@lists.tislabs.com,
        ipsec-policy@vpnc.org, ietf-ipsra@vpnc.org, ietf-sacred@imc.org,
        enum@ietf.org, sigtran@marvin.corpeast.baynetworks.com, ietf@ietf.org,
        IETF-Announce@ietf.org, BLUETOOTH-BOF@mailbag.cps.intel.com
Subject: RE: [seamoby] Re: BOF: IP over Bluetooth for 50th Meeting of IETF
	.
Date: Sun, 11 Feb 2001 17:06:26 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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>

Everyone's invited!  Welcome.

- Kulwinder Atwal.


> -----Original Message-----
> From: Randy Bush [mailto:randy@psg.com]
> Sent: Sunday, February 11, 2001 8:18 AM
> To: David Almer zahav
> Cc: zeroconf@merit.edu; seamoby@cdma-2000.org;
> MOBILE-IP@marvin.corpeast.baynetworks.com; srvloc@srvloc.org;
> aaa-wg@merit.edu; manet@itd.nrl.navy.mil; ipsec@lists.tislabs.com;
> ipsec-policy@vpnc.org; ietf-ipsra@vpnc.org; ietf-sacred@imc.org;
> enum@ietf.org; sigtran@marvin.corpeast.baynetworks.com; ietf@ietf.org;
> IETF-Announce@ietf.org; BLUETOOTH-BOF@mailbag.cps.intel.com
> Subject: [seamoby] Re: BOF: IP over Bluetooth for 50th 
> Meeting of IETF.
> 
> 
> > Gentlemen,
> 
> > Please join myself, David Almer on the pre-BOF mailing list.
> 
> are women not welcome?
> 
> randy
> 


From owner-ipsec-policy@mail.vpnc.org  Mon Feb 12 05:59:24 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03522
	for <ipsp-archive@odin.ietf.org>; Mon, 12 Feb 2001 05:59:24 -0500 (EST)
Received: by above.proper.com (8.9.3/8.9.3) id CAA08410
	for ipsec-policy-bks; Mon, 12 Feb 2001 02:07:12 -0800 (PST)
Received: from mimesweeper.radioscape.com (mail.radioscape.com [193.122.23.66])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id CAA08388;
	Mon, 12 Feb 2001 02:06:44 -0800 (PST)
Received: from euler.radioscape.com (unverified) by mimesweeper.radioscape.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T51ae8647d20a000006102@mimesweeper.radioscape.com>;
 Mon, 12 Feb 2001 10:06:26 +0000
Received: by EULER with Internet Mail Service (5.5.2653.19)
	id <C03YGBMN>; Mon, 12 Feb 2001 09:58:38 -0000
Message-ID: <3190BC9FA8F6D3119508009027E5B33E1CDBF6@MORSE>
From: "Thakare, Kiran" <KThakare@radioscape.com>
To: "'Randy Bush'" <randy@PSG.COM>, David Almer zahav <almer@tadlys.com>
Cc: zeroconf@merit.edu, seamoby@cdma-2000.org,
        MOBILE-IP@marvin.corpeast.baynetworks.com, srvloc@srvloc.org,
        aaa-wg@merit.edu, manet@itd.nrl.navy.mil, ipsec@lists.tislabs.com,
        ipsec-policy@vpnc.org, ietf-ipsra@vpnc.org, ietf-sacred@imc.org,
        enum@ietf.org, sigtran@marvin.corpeast.baynetworks.com, ietf@ietf.org,
        IETF-Announce@ietf.org, BLUETOOTH-BOF@mailbag.cps.intel.com
Subject: RE: BOF: IP over Bluetooth for 50th Meeting of IETF.
Date: Mon, 12 Feb 2001 10:06:26 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

Dear All (whatever gender u amy carry)

Please join myself 'Ms Kiran Thakare' for pre-BOF mailing list.

Thanks
Kiran

-----Original Message-----
From: Randy Bush [mailto:randy@PSG.COM]
Sent: 11 February 2001 13:18
To: David Almer zahav
Cc: zeroconf@merit.edu; seamoby@cdma-2000.org;
MOBILE-IP@marvin.corpeast.baynetworks.com; srvloc@srvloc.org;
aaa-wg@merit.edu; manet@itd.nrl.navy.mil; ipsec@lists.tislabs.com;
ipsec-policy@vpnc.org; ietf-ipsra@vpnc.org; ietf-sacred@imc.org;
enum@ietf.org; sigtran@marvin.corpeast.baynetworks.com; ietf@ietf.org;
IETF-Announce@ietf.org; BLUETOOTH-BOF@mailbag.cps.intel.com
Subject: Re: BOF: IP over Bluetooth for 50th Meeting of IETF.


> Gentlemen,

> Please join myself, David Almer on the pre-BOF mailing list.

are women not welcome?

randy


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
postmaster@radioscape.com.

This footnote also confirms that this email message has been scanned
for the presence of computer viruses known at the time of sending.

www.radioscape.com
**********************************************************************


From owner-ipsec-policy@mail.vpnc.org  Mon Feb 12 14:53:59 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19963
	for <ipsp-archive@odin.ietf.org>; Mon, 12 Feb 2001 14:53:58 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.9.3/8.9.3) id KAA13281
	for ipsec-policy-bks; Mon, 12 Feb 2001 10:25:03 -0800 (PST)
Received: from NEPTUNE.zucotto.com ([216.95.209.154])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA13268;
	Mon, 12 Feb 2001 10:25:00 -0800 (PST)
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2650.21)
	id <CTQSWMHL>; Mon, 12 Feb 2001 13:24:47 -0500
Message-ID: <FC0292EA4D13D34EA2E5FC728D70A8E33935CA@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'James Kempf'" <kempf@heliopolis.Eng.Sun.COM>, zeroconf@merit.edu,
        seamoby@cdma-2000.org, MOBILE-IP@standards.nortelnetworks.com,
        srvloc@srvloc.org, aaa-wg@merit.edu, manet@itd.nrl.navy.mil,
        ipsec@lists.tislabs.com, ipsec-policy@vpnc.org, ietf-ipsra@vpnc.org,
        ietf-sacred@imc.org, enum@ietf.org,
        sigtran@standards.nortelnetworks.com, ietf@ietf.org,
        IETF-Announce@ietf.org, BLUETOOTH-BOF@mailbag.cps.intel.com,
        kulwinder.atwal@herc.zucotto.com
Cc: narten@raleigh.ibm.com, Ron.Akers@motorola.com
Subject: RE: [seamoby] BOF:   IP over Bluetooth for 50th Meeting of IETF. 
Date: Mon, 12 Feb 2001 13:24:43 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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>

Your concerns will be addressed in a favourable manner.
Please join the list.  Your input is very welcome.

- Kulwinder.

> -----Original Message-----
> From: James Kempf [mailto:kempf@heliopolis.Eng.Sun.COM]
> Sent: Monday, February 12, 2001 1:18 PM
> To: zeroconf@merit.edu; seamoby@cdma-2000.org;
> MOBILE-IP@standards.nortelnetworks.com; srvloc@srvloc.org;
> aaa-wg@merit.edu; manet@itd.nrl.navy.mil; ipsec@lists.tislabs.com;
> ipsec-policy@vpnc.org; ietf-ipsra@vpnc.org; ietf-sacred@imc.org;
> enum@ietf.org; sigtran@standards.nortelnetworks.com; ietf@ietf.org;
> IETF-Announce@ietf.org; BLUETOOTH-BOF@mailbag.cps.intel.com;
> kulwinder.atwal@herc.zucotto.com
> Cc: narten@raleigh.ibm.com; Ron.Akers@motorola.com
> Subject: Re: [seamoby] BOF: IP over Bluetooth for 50th 
> Meeting of IETF. 
> 
> 
> Kulwinder,
> 
> There is an issue here with the closed, proprietary nature of 
> the Bluetooth
> SIG. Since information on what the SIG is doing is not available until
> it is complete, there is nothing to prevent the SIG from 
> doing something
> that would invalidate the work that IETF puts into desiging a better
> IP over Bluetooth.
> 
> Is there any possibility of gaining assurance from the SIG that they
> won't do something like this?
> 
> 		jak
> 
> 
> >
> >Myself and Ron Akers have requested an IP over Bluetooth BOF 
> for the 50th
> >Meeting of the IETF in Minneapolis.  The BOF will discuss 
> the creation of a
> >IETF Working Group to investigate the most open and 
> efficient way to place
> >IP over the Bluetooth Host Controller.
> >
> >Current work in this area within the Bluetooth SIG 
> concentrates on defining
> >IP over a set of other lower-layer stacks. Currently there 
> are two options
> >defined by the Bluetoth SIG:
> >
> > Option 1: IP/PPP/RFCOM/L2CAP/Host Controller
> >
> > Option 2: IP/PAN Profile/L2CAP/Host Controller
> > 	   (where the PAN Profile is a Bluetooth SIG work in progress)
> > 
> >
> >We are proposing that the IETF form a WG to define a more 
> efficient way of
> >running IP over Bluetooth. In particular, IP would run
> > over an IETF protocol over the Host Controller without 
> L2CAP.  This option
> >may be adopted by the Bluetooth SIG at a later date as a 
> Profile.  Since all
> >Bluetooth SIG Profiles are optional, a customer may choose 
> any combination
> >of Profiles in a final product.  Further, since Bluetooth 
> Working Groups
> >have it in their mandate to adopt protocols from other 
> standards making
> >bodies such as the IETF, there exists a clear path for IETF 
> work to be
> >adopted by the Bluetooth SIG.
> > 
> >Whereas the last BOF was informational only and organized by 
> the Bluetooth
> >SIG itself, the objective of this BOF will be to foster 
> innovation, and
> >speed progress by placing IP related protocol development 
> wihin the IETF and
> >Bluetooth-specific protocol development
> > within the Bluetooth SIG, by developing an IP over 
> Bluetooth IETF Working
> >Group.
> > 
> >This effort will define its own way of running IP over Bluetooth, by
> >carefully selecting a set of Bluetooth protocols (freely 
> available from
> >published specifications at
> >http://www.bluetooth.com/developer/specification/specificatio
> n.asp) on which
> >to build IP.
> >
> >Please join myself, Kulwinder Atwal, and Ron Akers on the 
> pre-BOF mailing
> >list:
> > 
> >This site runs version 2.0.1 of the "Mailman" list manager.  
> >The following describes commands you can send to get
> >information about, and control your subscription to the lists at
> >this site. Note that much of the following can also be 
> >accomplished via the World Wide Web, at:
> >
> >    http://internet.motlabs.com/mailman/listinfo/bluetooth
> >
> >In particular, you can use the Web site to have your password sent to
> >your delivery address.
> >
> >Email commands can be in the subject line or in the body 
> >of the message. The commands should be set to the following address:
> >
> >  <bluetooth-request@internet.motlabs.com>
> >
> >About the descriptions - words in "<>"s signify REQUIRED items and
> >words in "[]" denote OPTIONAL items.  Do not include the "<>"s or
> >"[]"s when you use the commands.
> >
> >The following commands are valid:
> >
> >    subscribe [password] [digest-option] [address=<address>]
> >        Subscribe to the mailing list.  Your password must 
> be given to
> >        unsubscribe or change your options.  When you 
> subscribe to the
> >        list, you'll be reminded of your password periodically.
> >        'digest-option' may be either: 'nodigest' or 'digest' (no
> >        quotes!)  If you wish to subscribe an address other than the
> >        address you send this request from, you may specify
> >        "address=<email address>" (no brackets around the email
> >        address, no quotes!)
> >
> >    unsubscribe <password> [address]
> >        Unsubscribe from the mailing list.  Your password must match
> >        the one you gave when you subscribed.  If you are trying to
> >        unsubscribe from a different address than the one you
> >        subscribed from, you may specify it in the 'address' field.
> >
> >    who
> >        See everyone who is on this mailing list.
> >
> >    info
> >        View the introductory information for this list.
> >
> >    lists
> >        See what mailing lists are run by this Mailman server.
> >
> >    help
> >        This message.
> >
> >    set <option> <on|off> <password> 
> >        Turn on or off list options.  Valid options are:
> >
> >        ack:
> >            Turn this on to receive acknowledgement mail 
> when you send
> >            mail to the list.
> >
> >        digest:
> >            Receive mail from the list bundled together 
> instead of one
> >            post at a time.
> >
> >        plain:
> >            Get plain-text, not MIME-compliant, digests (only if
> >            digest is set)
> >
> >        nomail:
> >            Stop delivering mail.  Useful if you plan on taking a
> >            short vacation.
> >
> >        norcv:
> >            Turn this on to NOT receive posts you send to the list.
> >            Does not work if digest is set.
> >
> >        hide:
> >            Conceals your address when people look at who is on this
> >            list.
> >
> >
> >    options
> >        Show the current values of your list options.
> >
> >    password <oldpassword> <newpassword> 
> >        Change your list password.
> >    
> >    end or --
> >       Stop processing commands (good to do if your mailer
> >       automatically adds a signature file - it'll save you 
> from a lot
> >       of cruft).
> >
> >
> >Commands should be sent to bluetooth-request@internet.motlabs.com
> >
> >Questions and concerns for the attention of a person should 
> be sent to
> >
> >    bluetooth-admin@internet.motlabs.com
> >
> >
> >
> >Kulwinder Atwal
> >Bluetooth Design
> >Zucotto Wireless Inc.
> >kulwinder.atwal@zucotto.com
> >
> >------------------------------------------------------------
> >Ron Akers                               Voice :(847)576-7928
> >Networks and Infrastructure Research      FAX :(847)576-3240
> >Motorola Laboratories           email:ron.akers@motorola.com 
> >1301 Algonquin Rd, Rm 2246
> >Schaumburg, IL. 60196
> >------------------------------------------------------------
> 


From owner-ipsec-policy@mail.vpnc.org  Mon Feb 12 15:58:22 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21262
	for <ipsp-archive@odin.ietf.org>; Mon, 12 Feb 2001 15:58:21 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.9.3/8.9.3) id KAA12996
	for ipsec-policy-bks; Mon, 12 Feb 2001 10:21:56 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA12819;
	Mon, 12 Feb 2001 10:19:56 -0800 (PST)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA07466;
	Mon, 12 Feb 2001 10:17:57 -0800 (PST)
Received: from srmtv29a.Eng.Sun.COM (srmtv29a.Eng.Sun.COM [152.70.1.41])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11825;
	Mon, 12 Feb 2001 10:17:56 -0800 (PST)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by srmtv29a.Eng.Sun.COM (8.10.2+Sun/8.10.2) with SMTP id f1CIHtB19978;
	Mon, 12 Feb 2001 10:17:55 -0800 (PST)
Message-Id: <200102121817.f1CIHtB19978@srmtv29a.Eng.Sun.COM>
Date: Mon, 12 Feb 2001 10:17:55 -0800 (PST)
From: James Kempf <kempf@heliopolis.Eng.Sun.COM>
Reply-To: James Kempf <kempf@heliopolis.Eng.Sun.COM>
Subject: Re: [seamoby] BOF:   IP over Bluetooth for 50th Meeting of IETF. 
To: zeroconf@merit.edu, seamoby@cdma-2000.org,
        MOBILE-IP@STANDARDS.NORTELNETWORKS.COM, srvloc@srvloc.org,
        aaa-wg@merit.edu, manet@itd.nrl.navy.mil, ipsec@lists.tislabs.com,
        ipsec-policy@vpnc.org, ietf-ipsra@vpnc.org, ietf-sacred@imc.org,
        enum@ietf.org, sigtran@STANDARDS.NORTELNETWORKS.COM, ietf@ietf.org,
        IETF-Announce@ietf.org, BLUETOOTH-BOF@mailbag.cps.intel.com,
        kulwinder.atwal@zucotto.com
Cc: narten@raleigh.ibm.com, Ron.Akers@motorola.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: IQNb6xGFCtgsJJ6tIPx3Gg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
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>

Kulwinder,

There is an issue here with the closed, proprietary nature of the Bluetooth
SIG. Since information on what the SIG is doing is not available until
it is complete, there is nothing to prevent the SIG from doing something
that would invalidate the work that IETF puts into desiging a better
IP over Bluetooth.

Is there any possibility of gaining assurance from the SIG that they
won't do something like this?

		jak


>
>Myself and Ron Akers have requested an IP over Bluetooth BOF for the 50th
>Meeting of the IETF in Minneapolis.  The BOF will discuss the creation of a
>IETF Working Group to investigate the most open and efficient way to place
>IP over the Bluetooth Host Controller.
>
>Current work in this area within the Bluetooth SIG concentrates on defining
>IP over a set of other lower-layer stacks. Currently there are two options
>defined by the Bluetoth SIG:
>
> Option 1: IP/PPP/RFCOM/L2CAP/Host Controller
>
> Option 2: IP/PAN Profile/L2CAP/Host Controller
> 	   (where the PAN Profile is a Bluetooth SIG work in progress)
> 
>
>We are proposing that the IETF form a WG to define a more efficient way of
>running IP over Bluetooth. In particular, IP would run
> over an IETF protocol over the Host Controller without L2CAP.  This option
>may be adopted by the Bluetooth SIG at a later date as a Profile.  Since all
>Bluetooth SIG Profiles are optional, a customer may choose any combination
>of Profiles in a final product.  Further, since Bluetooth Working Groups
>have it in their mandate to adopt protocols from other standards making
>bodies such as the IETF, there exists a clear path for IETF work to be
>adopted by the Bluetooth SIG.
> 
>Whereas the last BOF was informational only and organized by the Bluetooth
>SIG itself, the objective of this BOF will be to foster innovation, and
>speed progress by placing IP related protocol development wihin the IETF and
>Bluetooth-specific protocol development
> within the Bluetooth SIG, by developing an IP over Bluetooth IETF Working
>Group.
> 
>This effort will define its own way of running IP over Bluetooth, by
>carefully selecting a set of Bluetooth protocols (freely available from
>published specifications at
>http://www.bluetooth.com/developer/specification/specification.asp) on which
>to build IP.
>
>Please join myself, Kulwinder Atwal, and Ron Akers on the pre-BOF mailing
>list:
> 
>This site runs version 2.0.1 of the "Mailman" list manager.  
>The following describes commands you can send to get
>information about, and control your subscription to the lists at
>this site. Note that much of the following can also be 
>accomplished via the World Wide Web, at:
>
>    http://internet.motlabs.com/mailman/listinfo/bluetooth
>
>In particular, you can use the Web site to have your password sent to
>your delivery address.
>
>Email commands can be in the subject line or in the body 
>of the message. The commands should be set to the following address:
>
>  <bluetooth-request@internet.motlabs.com>
>
>About the descriptions - words in "<>"s signify REQUIRED items and
>words in "[]" denote OPTIONAL items.  Do not include the "<>"s or
>"[]"s when you use the commands.
>
>The following commands are valid:
>
>    subscribe [password] [digest-option] [address=<address>]
>        Subscribe to the mailing list.  Your password must be given to
>        unsubscribe or change your options.  When you subscribe to the
>        list, you'll be reminded of your password periodically.
>        'digest-option' may be either: 'nodigest' or 'digest' (no
>        quotes!)  If you wish to subscribe an address other than the
>        address you send this request from, you may specify
>        "address=<email address>" (no brackets around the email
>        address, no quotes!)
>
>    unsubscribe <password> [address]
>        Unsubscribe from the mailing list.  Your password must match
>        the one you gave when you subscribed.  If you are trying to
>        unsubscribe from a different address than the one you
>        subscribed from, you may specify it in the 'address' field.
>
>    who
>        See everyone who is on this mailing list.
>
>    info
>        View the introductory information for this list.
>
>    lists
>        See what mailing lists are run by this Mailman server.
>
>    help
>        This message.
>
>    set <option> <on|off> <password> 
>        Turn on or off list options.  Valid options are:
>
>        ack:
>            Turn this on to receive acknowledgement mail when you send
>            mail to the list.
>
>        digest:
>            Receive mail from the list bundled together instead of one
>            post at a time.
>
>        plain:
>            Get plain-text, not MIME-compliant, digests (only if
>            digest is set)
>
>        nomail:
>            Stop delivering mail.  Useful if you plan on taking a
>            short vacation.
>
>        norcv:
>            Turn this on to NOT receive posts you send to the list.
>            Does not work if digest is set.
>
>        hide:
>            Conceals your address when people look at who is on this
>            list.
>
>
>    options
>        Show the current values of your list options.
>
>    password <oldpassword> <newpassword> 
>        Change your list password.
>    
>    end or --
>       Stop processing commands (good to do if your mailer
>       automatically adds a signature file - it'll save you from a lot
>       of cruft).
>
>
>Commands should be sent to bluetooth-request@internet.motlabs.com
>
>Questions and concerns for the attention of a person should be sent to
>
>    bluetooth-admin@internet.motlabs.com
>
>
>
>Kulwinder Atwal
>Bluetooth Design
>Zucotto Wireless Inc.
>kulwinder.atwal@zucotto.com
>
>------------------------------------------------------------
>Ron Akers                               Voice :(847)576-7928
>Networks and Infrastructure Research      FAX :(847)576-3240
>Motorola Laboratories           email:ron.akers@motorola.com 
>1301 Algonquin Rd, Rm 2246
>Schaumburg, IL. 60196
>------------------------------------------------------------



From owner-ipsec-policy@mail.vpnc.org  Wed Feb 14 15:37:15 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16205
	for <ipsp-archive@odin.ietf.org>; Wed, 14 Feb 2001 15:37:14 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.9.3/8.9.3) id LAA08435
	for ipsec-policy-bks; Wed, 14 Feb 2001 11:06:58 -0800 (PST)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA08431
	for <ipsec-policy@vpnc.org>; Wed, 14 Feb 2001 11:06:57 -0800 (PST)
From: Man.M.Li@nokia.com
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1EJ6Tg29135
	for <ipsec-policy@vpnc.org>; Wed, 14 Feb 2001 13:06:45 -0600 (CST)
Received: from daebh01nok.americas.nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T51b977da63ac12f255115@davir02nok.americas.nokia.com> for <ipsec-policy@vpnc.org>;
 Wed, 14 Feb 2001 13:06:30 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <16XNAQQQ>; Wed, 14 Feb 2001 13:01:16 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E460292B8D3@bseis01nok>
To: ipsec-policy@vpnc.org
Subject:  IPsecAction granularity again
Date: Wed, 14 Feb 2001 12:56:26 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
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>

Hi,

I think the ietf IPsec information model uses the granularity in a different
way and that is the way I like. Correct me Jamie if I mis-understand the
intention. The granularity is used to indicate the following function
specified in Section 4.4.1. RFC2401:

"For each selector, the policy entry specifies how
   to derive the corresponding values for a new Security Association
   Database (SAD, see Section 4.4.3) entry from those in the SPD and the
   packet (Note that at present, ranges are only supported for IP
   addresses; but wildcarding can be expressed for all selectors):

           a. use the value in the packet itself -- This will limit use
              of the SA to those packets which have this packet's value
              for the selector even if the selector for the policy entry
              has a range of allowed values or a wildcard for this
              selector.
           b. use the value associated with the policy entry -- If this
              were to be just a single value, then there would be no
              difference between (b) and (a).  However, if the allowed
              values for the selector are a range (for IP addresses) or
              wildcard, then in the case of a range,(b) would enable use
              of the SA by any packet with a selector value within the
              range not just by packets with the selector value of the
              packet that triggered the creation of the SA.  In the case
              of a wildcard, (b) would allow use of the SA by packets
              with any value for this selector."

In the ietf IPsec info model, the granularity is in the filter list and has
two choices: narrow and wide that correspond to (a) and (b).


Man Li
Nokia 
5 Wayside Road, Burlington, MA 01803
man.m.li@nokia.com
phone 1-781-993-3923
GSM 1-781-492-2850 

-----Original Message-----
From: ext Lee Rafalow [mailto:rafalow@raleigh.ibm.com]
Sent: Wednesday, January 10, 2001 10:46 AM
To: ipsec-policy@vpnc.org
Cc: tm-ipsec
Subject: Re: IPsecAction granularity


Ricky, Here's the reasoning for its location in the model.

The conditions (filters) are used to determine which rule applies to a
packet (for which there's currently no SA).  As with other action
properties, the granularity is used to determine how to negotiate and build
the SA.  In this case, the granularity is used (in conjunction with the
filters) to determine the selector for a given IPsec SA.

So, the same rule can be evaluated (i.e., filter) and yield different
selectors.

IHTH.  Lee

----- Original Message -----
From: "Ricky Charlet" <rcharlet@redcreek.com>
To: ".ipsec-policy" <ipsec-policy@vpnc.org>
Sent: Tuesday, January 09, 2001 7:30 PM
Subject: ICIM: IPsecAction granularity


> Howdy,
>
> I dislike the granularity property of IPsecActions. It purports to be
> controlling whether subnet mask, or protocol, or port fields should be
> wild-carded in SA Proposals. And this makes the granularity property
> part of a selector. I think any property of a selector should be over on
> the Filter Entry side and not in an IPsecAction.
>
>
> --
>   Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903


From owner-ipsec-policy@mail.vpnc.org  Thu Feb 15 14:11:31 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27720
	for <ipsp-archive@odin.ietf.org>; Thu, 15 Feb 2001 14:11:31 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.9.3/8.9.3) id JAA14083
	for ipsec-policy-bks; Thu, 15 Feb 2001 09:49:34 -0800 (PST)
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA14079
	for <ipsec-policy@vpnc.org>; Thu, 15 Feb 2001 09:49:32 -0800 (PST)
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.35 2001/02/12 09:03:45 smothers Exp $) with ESMTP id RAA00364;
	Thu, 15 Feb 2001 17:50:46 GMT
Received: by fmsmsx18.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <13BVH5YL>; Thu, 15 Feb 2001 09:47:55 -0800
Message-ID: <794826DE8867D411BAB8009027AE9EB904DD7A8A@FMSMSX38>
From: "Jason, Jamie" <jamie.jason@intel.com>
To: "'Man.M.Li@nokia.com'" <Man.M.Li@nokia.com>, ipsec-policy@vpnc.org
Subject: RE: IPsecAction granularity again
Date: Thu, 15 Feb 2001 09:47:49 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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>

In the next version of the model, the granularity enumeration has 4
different values.

1.  use the subnet from the filter that matched...although I think that this
may have to be reworded to also include if the filter has an address range.
I need to look into the filter entry from CIM again to see what it has in
it.
2.  use the IP addresses from the packet that triggered the action, i.e.,
wildcard the IP protocol and the ports.
3.  use the IP addresses and IP protocol from the packet, i.e., wildcard the
ports if the IP protocol is a layer-4 protocol which uses ports.
4.  use the IP addresses, IP protocol, and ports (if there are layer 4
ports) from the packet that triggered the action.

So, (1) above corresponds to (b) and (4) corresponds to (a) below.  (2) and
(3) are kind in the middle.

Although I am beginning to wonder if these are sufficient...I'll have to get
back to you on that.

Jamie

> -----Original Message-----
> From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
> Sent: Wednesday, February 14, 2001 10:56 AM
> To: ipsec-policy@vpnc.org
> Subject: IPsecAction granularity again
> 
> 
> Hi,
> 
> I think the ietf IPsec information model uses the granularity 
> in a different
> way and that is the way I like. Correct me Jamie if I 
> mis-understand the
> intention. The granularity is used to indicate the following function
> specified in Section 4.4.1. RFC2401:
> 
> "For each selector, the policy entry specifies how
>    to derive the corresponding values for a new Security Association
>    Database (SAD, see Section 4.4.3) entry from those in the 
> SPD and the
>    packet (Note that at present, ranges are only supported for IP
>    addresses; but wildcarding can be expressed for all selectors):
> 
>            a. use the value in the packet itself -- This will 
> limit use
>               of the SA to those packets which have this 
> packet's value
>               for the selector even if the selector for the 
> policy entry
>               has a range of allowed values or a wildcard for this
>               selector.
>            b. use the value associated with the policy entry 
> -- If this
>               were to be just a single value, then there would be no
>               difference between (b) and (a).  However, if the allowed
>               values for the selector are a range (for IP 
> addresses) or
>               wildcard, then in the case of a range,(b) would 
> enable use
>               of the SA by any packet with a selector value within the
>               range not just by packets with the selector value of the
>               packet that triggered the creation of the SA.  
> In the case
>               of a wildcard, (b) would allow use of the SA by packets
>               with any value for this selector."
> 
> In the ietf IPsec info model, the granularity is in the 
> filter list and has
> two choices: narrow and wide that correspond to (a) and (b).
> 
> 
> Man Li
> Nokia 
> 5 Wayside Road, Burlington, MA 01803
> man.m.li@nokia.com
> phone 1-781-993-3923
> GSM 1-781-492-2850 
> 
> -----Original Message-----
> From: ext Lee Rafalow [mailto:rafalow@raleigh.ibm.com]
> Sent: Wednesday, January 10, 2001 10:46 AM
> To: ipsec-policy@vpnc.org
> Cc: tm-ipsec
> Subject: Re: IPsecAction granularity
> 
> 
> Ricky, Here's the reasoning for its location in the model.
> 
> The conditions (filters) are used to determine which rule applies to a
> packet (for which there's currently no SA).  As with other action
> properties, the granularity is used to determine how to 
> negotiate and build
> the SA.  In this case, the granularity is used (in 
> conjunction with the
> filters) to determine the selector for a given IPsec SA.
> 
> So, the same rule can be evaluated (i.e., filter) and yield different
> selectors.
> 
> IHTH.  Lee
> 
> ----- Original Message -----
> From: "Ricky Charlet" <rcharlet@redcreek.com>
> To: ".ipsec-policy" <ipsec-policy@vpnc.org>
> Sent: Tuesday, January 09, 2001 7:30 PM
> Subject: ICIM: IPsecAction granularity
> 
> 
> > Howdy,
> >
> > I dislike the granularity property of IPsecActions. It 
> purports to be
> > controlling whether subnet mask, or protocol, or port 
> fields should be
> > wild-carded in SA Proposals. And this makes the granularity property
> > part of a selector. I think any property of a selector 
> should be over on
> > the Filter Entry side and not in an IPsecAction.
> >
> >
> > --
> >   Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903
> 


From owner-ipsec-policy@mail.vpnc.org  Fri Feb 16 09:42:42 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00441
	for <ipsp-archive@odin.ietf.org>; Fri, 16 Feb 2001 09:42:41 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.9.3/8.9.3) id FAA27730
	for ipsec-policy-bks; Fri, 16 Feb 2001 05:31:23 -0800 (PST)
Received: from cisco.com (brussels.cisco.com [144.254.15.68])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA27717
	for <ipsec-policy@vpnc.org>; Fri, 16 Feb 2001 05:31:19 -0800 (PST)
Received: from evyncke-8kcdt.cisco.com (evyncke-isdn-home.cisco.com [10.49.1.170])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id OAA01636;
	Fri, 16 Feb 2001 14:30:32 +0100 (MET)
Message-Id: <4.3.2.7.2.20010216142827.00b2b860@brussels.cisco.com>
X-Sender: evyncke@brussels.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 16 Feb 2001 14:31:04 +0100
To: "Jason, Jamie" <jamie.jason@intel.com>,
        "'Man.M.Li@nokia.com'" <Man.M.Li@nokia.com>, ipsec-policy@vpnc.org
From: Eric Vyncke <evyncke@cisco.com>
Subject: RE: IPsecAction granularity again
In-Reply-To: <794826DE8867D411BAB8009027AE9EB904DD7A8A@FMSMSX38>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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>

Jamie

Except for the IP address range which was overlooked, I believe that the
4 choices cover all real life implementations. We could possibly argue
that the wild card is to be applied on one side only of the 5-tuple
(i.e. from my local IP address to all your remote subnet). If so,
the granularity property should rather be a 5-tuple mask.

Just my 0.01 EUR

-eric

At 09:47 15/02/01 -0800, Jason, Jamie wrote:
>In the next version of the model, the granularity enumeration has 4
>different values.
>
>1.  use the subnet from the filter that matched...although I think that this
>may have to be reworded to also include if the filter has an address range.
>I need to look into the filter entry from CIM again to see what it has in
>it.
>2.  use the IP addresses from the packet that triggered the action, i.e.,
>wildcard the IP protocol and the ports.
>3.  use the IP addresses and IP protocol from the packet, i.e., wildcard the
>ports if the IP protocol is a layer-4 protocol which uses ports.
>4.  use the IP addresses, IP protocol, and ports (if there are layer 4
>ports) from the packet that triggered the action.
>
>So, (1) above corresponds to (b) and (4) corresponds to (a) below.  (2) and
>(3) are kind in the middle.
>
>Although I am beginning to wonder if these are sufficient...I'll have to get
>back to you on that.
>
>Jamie
>
>> -----Original Message-----
>> From: Man.M.Li@nokia.com [mailto:Man.M.Li@nokia.com]
>> Sent: Wednesday, February 14, 2001 10:56 AM
>> To: ipsec-policy@vpnc.org
>> Subject: IPsecAction granularity again
>> 
>> 
>> Hi,
>> 
>> I think the ietf IPsec information model uses the granularity 
>> in a different
>> way and that is the way I like. Correct me Jamie if I 
>> mis-understand the
>> intention. The granularity is used to indicate the following function
>> specified in Section 4.4.1. RFC2401:
>> 
>> "For each selector, the policy entry specifies how
>>    to derive the corresponding values for a new Security Association
>>    Database (SAD, see Section 4.4.3) entry from those in the 
>> SPD and the
>>    packet (Note that at present, ranges are only supported for IP
>>    addresses; but wildcarding can be expressed for all selectors):
>> 
>>            a. use the value in the packet itself -- This will 
>> limit use
>>               of the SA to those packets which have this 
>> packet's value
>>               for the selector even if the selector for the 
>> policy entry
>>               has a range of allowed values or a wildcard for this
>>               selector.
>>            b. use the value associated with the policy entry 
>> -- If this
>>               were to be just a single value, then there would be no
>>               difference between (b) and (a).  However, if the allowed
>>               values for the selector are a range (for IP 
>> addresses) or
>>               wildcard, then in the case of a range,(b) would 
>> enable use
>>               of the SA by any packet with a selector value within the
>>               range not just by packets with the selector value of the
>>               packet that triggered the creation of the SA.  
>> In the case
>>               of a wildcard, (b) would allow use of the SA by packets
>>               with any value for this selector."
>> 
>> In the ietf IPsec info model, the granularity is in the 
>> filter list and has
>> two choices: narrow and wide that correspond to (a) and (b).
>> 
>> 
>> Man Li
>> Nokia 
>> 5 Wayside Road, Burlington, MA 01803
>> man.m.li@nokia.com
>> phone 1-781-993-3923
>> GSM 1-781-492-2850 
>> 
>> -----Original Message-----
>> From: ext Lee Rafalow [mailto:rafalow@raleigh.ibm.com]
>> Sent: Wednesday, January 10, 2001 10:46 AM
>> To: ipsec-policy@vpnc.org
>> Cc: tm-ipsec
>> Subject: Re: IPsecAction granularity
>> 
>> 
>> Ricky, Here's the reasoning for its location in the model.
>> 
>> The conditions (filters) are used to determine which rule applies to a
>> packet (for which there's currently no SA).  As with other action
>> properties, the granularity is used to determine how to 
>> negotiate and build
>> the SA.  In this case, the granularity is used (in 
>> conjunction with the
>> filters) to determine the selector for a given IPsec SA.
>> 
>> So, the same rule can be evaluated (i.e., filter) and yield different
>> selectors.
>> 
>> IHTH.  Lee
>> 
>> ----- Original Message -----
>> From: "Ricky Charlet" <rcharlet@redcreek.com>
>> To: ".ipsec-policy" <ipsec-policy@vpnc.org>
>> Sent: Tuesday, January 09, 2001 7:30 PM
>> Subject: ICIM: IPsecAction granularity
>> 
>> 
>> > Howdy,
>> >
>> > I dislike the granularity property of IPsecActions. It 
>> purports to be
>> > controlling whether subnet mask, or protocol, or port 
>> fields should be
>> > wild-carded in SA Proposals. And this makes the granularity property
>> > part of a selector. I think any property of a selector 
>> should be over on
>> > the Filter Entry side and not in an IPsecAction.
>> >
>> >
>> > --
>> >   Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903
>> 

Eric Vyncke                        
Distinguished Engineer             Cisco Systems EMEA
Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
E-mail: evyncke@cisco.com          Mobile: +32-475-312.458 (CHANGED)
PGP fingerprint: D35F BEF9 643F 656F 90F5  76C5 9CA1 C289 D398 B141



From owner-ipsec-policy@mail.vpnc.org  Fri Feb 16 20:26:27 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12709
	for <ipsp-archive@odin.ietf.org>; Fri, 16 Feb 2001 20:26:27 -0500 (EST)
Received: by above.proper.com (8.9.3/8.9.3) id PAA04543
	for ipsec-policy-bks; Fri, 16 Feb 2001 15:55:56 -0800 (PST)
Received: from rc_westlake.interdyn.com ([205.147.53.144])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA04537
	for <ipsec-policy@vpnc.org>; Fri, 16 Feb 2001 15:55:55 -0800 (PST)
Received: by RC_WESTLAKE with Internet Mail Service (5.5.2653.19)
	id <1F7PC9YK>; Fri, 16 Feb 2001 15:55:28 -0800
Received: from redcreek.com (host186.redcreek.com [209.218.26.186]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21)
	id 15AA8QSH; Fri, 16 Feb 2001 15:55:24 -0800
Message-ID: <3A8DB11A.9043F66E@redcreek.com>
Date: Fri, 16 Feb 2001 16:00:42 -0700
From: Ricky Charlet <rcharlet@redcreek.com>
Organization: Redcreek Communications
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
CC: ipsec-policy@vpnc.org
Subject: Re: IPsecAction granularity again
References: <4.3.2.7.2.20010216142827.00b2b860@brussels.cisco.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>
Content-Transfer-Encoding: 7bit

Howdy,

	I still content that granularity does not belong over in the Action
side of the house. It is confusing. Someone should be able to justify
the value of putting a part of the selector definition over with the
actions or we should move it back into the conditions.

--
Ricky Charlet


From owner-ipsec-policy@mail.vpnc.org  Fri Feb 16 20:52:27 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12901
	for <ipsp-archive@odin.ietf.org>; Fri, 16 Feb 2001 20:52:25 -0500 (EST)
Received: by above.proper.com (8.9.3/8.9.3) id QAA07302
	for ipsec-policy-bks; Fri, 16 Feb 2001 16:41:47 -0800 (PST)
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA07298
	for <ipsec-policy@vpnc.org>; Fri, 16 Feb 2001 16:41:46 -0800 (PST)
Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id AAA29560;
	Sat, 17 Feb 2001 00:41:44 GMT
Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Sat, 17 Feb 2001 00:41:44 0000 (GMT)
Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <1RTCASAX>; Fri, 16 Feb 2001 16:41:43 -0800
Message-ID: <794826DE8867D411BAB8009027AE9EB904DD7AA8@FMSMSX38>
From: "Jason, Jamie" <jamie.jason@intel.com>
To: "'Ricky Charlet'" <rcharlet@redcreek.com>
Cc: ipsec-policy@vpnc.org
Subject: RE: IPsecAction granularity again
Date: Fri, 16 Feb 2001 16:41:41 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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>

I agree with Lee's argument (pasted below) for inclusion in the action.  In
the model, the condition is used for matching to determine if rules apply.
Creating the selector that will be given to the negotiating peer, in my
opinion, is part of the application the negotiation action.

<Lee Rafalow>
> The conditions (filters) are used to determine which rule applies to a
> packet (for which there's currently no SA).  As with other action
> properties, the granularity is used to determine how to 
> negotiate and build
> the SA.  In this case, the granularity is used (in 
> conjunction with the
> filters) to determine the selector for a given IPsec SA.
</Lee Rafalow>

As for the contention that putting the granularity in the action is
confusing, I personally find it clearer to keep it with the action
information.

Jamie

> -----Original Message-----
> From: Ricky Charlet [mailto:rcharlet@redcreek.com]
> Sent: Friday, February 16, 2001 3:01 PM
> Cc: ipsec-policy@vpnc.org
> Subject: Re: IPsecAction granularity again
> 
> 
> Howdy,
> 
> 	I still content that granularity does not belong over 
> in the Action
> side of the house. It is confusing. Someone should be able to justify
> the value of putting a part of the selector definition over with the
> actions or we should move it back into the conditions.
> 
> --
> Ricky Charlet
> 



From owner-ipsec-policy@mail.vpnc.org  Mon Feb 19 07:19:47 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02270
	for <ipsp-archive@odin.ietf.org>; Mon, 19 Feb 2001 07:19:42 -0500 (EST)
Received: by above.proper.com (8.9.3/8.9.3) id DAA26920
	for ipsec-policy-bks; Mon, 19 Feb 2001 03:09:41 -0800 (PST)
Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr [193.49.124.31])
	by above.proper.com (8.9.3/8.9.3) with SMTP id DAA26916
	for <ipsec-policy@vpnc.org>; Mon, 19 Feb 2001 03:09:40 -0800 (PST)
Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19)
	id <FHYD575R>; Mon, 19 Feb 2001 11:32:55 +0100
Message-ID: <91A311FF6A85D3118DDF0060080C3D829DE1AB@lat3721.lannion.cnet.fr>
From: MORAND Pierrick FTRD/DMI/CAE <pierrick.morand@rd.francetelecom.fr>
To: "IPSEC-POLICY (E-mail)" <ipsec-policy@vpnc.org>
Subject: IPSEC PIB - Clarification request
Date: Mon, 19 Feb 2001 11:30:30 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

In the last version of the IPSec PIB document (version 01) some aspects of
the current PIB definition lead me to ask for some clarification.

1-An IpSecRuleEntry can reference a group of actions. These actions are
applied to the set of flows described by the set of IpSecSelectorEntries
attached to the rule.

a) can someone give examples of multiple actions that can be applied to the
same flows ? It seems that section 4.3 introduces this aspect but the
example starts introducing an exchange between two hosts A et B and a third
one C appears as if A had to communicate with C. In this example I
personally understand that the document attempts to say that a single rule
should be able to specify that traffic between A and B should be handle in
transport mode and a tunnel should be setup to handle traffic exchanged
between A and B thanks to the tunnel between A and gateway C. It seems this
should lead to the definition of 2 rules, each of them referencing a
different action (transport mode for one and tunnel mode for the other).

b) in case several actions are attached to an IpSecRule does this mean that
they shall all be applied in sequence according to their order or shall we
understand that once an action has been achieved the rest of actions will
not be considered ?

c) in case traffic shall be discarded or bypassed, it is written in the
description part of ipSecActionActionGroupId (page 20), that this last
attribute must be set to zero. In this case if one rule says that traffic
between A and B shall be discarded WITH NO logging and an other rule says
that traffic between C and D shall be discarded WITH logging this will lead
to create two ipSecActionEntries with GroupId set to zero. One will say
discard and no logging, the other will say discard and logging. If these
actions are attached to 2 different rules the corresponding action will
referenced an ipSecRuleIpSecActionGroupId of zero value that references
these two actions which are opposite. How will the system react ?

2-My understanding of IKE is that IKE phase 1 an 2 are triggered by IPSec.
It seems in the document that Ike Rules can be established independently of
IPsec Rules. Does this means that other protocols than IPSec are today able
to make use of IKE ? If so, wouldn't this lead to the definition of a stand
alone IKE PIB ? The current definition allows to create a RuleEntry with a
role combination and constraints and ipSecRuleEntry to reference and IKE
Rule having the same rule combination. Isn't there here is a duplicated
information ?

Thanks a lot for clarifying these points with my apologizes if my
understanding was incorrect partly due to the fact I am not an IpSec expert
at all.

Pierrick Morand
france telecom R&D/DMI/SIR/IPI
Tel   : +33 2 31 75 91 79 -  Fax : +33 2 31 73 56 26
Email :pierrick.morand@francetelecom.com




From owner-ipsec-policy@mail.vpnc.org  Mon Feb 19 12:45:51 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10104
	for <ipsp-archive@odin.ietf.org>; Mon, 19 Feb 2001 12:45:51 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.9.3/8.9.3) id IAA09843
	for ipsec-policy-bks; Mon, 19 Feb 2001 08:17:19 -0800 (PST)
Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA09839
	for <ipsec-policy@vpnc.org>; Mon, 19 Feb 2001 08:17:17 -0800 (PST)
From: Man.M.Li@nokia.com
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f1JGHFg29966
	for <ipsec-policy@vpnc.org>; Mon, 19 Feb 2001 10:17:15 -0600 (CST)
Received: from daebh01nok.americas.nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T51d29cb608ac12f25715a@davir04nok.americas.nokia.com>;
 Mon, 19 Feb 2001 10:17:16 -0600
Received: by daebh01nok with Internet Mail Service (5.5.2652.78)
	id <FHXQNKRM>; Mon, 19 Feb 2001 10:17:16 -0600
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E460292B8EA@bseis01nok>
To: pierrick.morand@rd.francetelecom.fr, ipsec-policy@vpnc.org
Subject: RE: IPSEC PIB - Clarification request
Date: Mon, 19 Feb 2001 10:17:14 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
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>

Hi Pierrick,

Thank you for reading the draft and for your comments. Please see my
comments below. The next version will clarify these points.

Man Li
Nokia 
5 Wayside Road, Burlington, MA 01803
man.m.li@nokia.com
phone 1-781-993-3923
GSM 1-781-492-2850 

-----Original Message-----
From: ext MORAND Pierrick FTRD/DMI/CAE
[mailto:pierrick.morand@rd.francetelecom.fr]
Sent: Monday, February 19, 2001 5:31 AM
To: IPSEC-POLICY (E-mail)
Subject: IPSEC PIB - Clarification request


In the last version of the IPSec PIB document (version 01) some aspects of
the current PIB definition lead me to ask for some clarification.

1-An IpSecRuleEntry can reference a group of actions. These actions are
applied to the set of flows described by the set of IpSecSelectorEntries
attached to the rule.

a) can someone give examples of multiple actions that can be applied to the
same flows ? It seems that section 4.3 introduces this aspect but the
example starts introducing an exchange between two hosts A et B and a third
one C appears as if A had to communicate with C. In this example I
personally understand that the document attempts to say that a single rule
should be able to specify that traffic between A and B should be handle in
transport mode and a tunnel should be setup to handle traffic exchanged
between A and B thanks to the tunnel between A and gateway C. It seems this
should lead to the definition of 2 rules, each of them referencing a
different action (transport mode for one and tunnel mode for the other).

From A's point of view, there are two actions that need to be taken in
sequence. Hence the PIB downloaded to A will include a group of actions.

b) in case several actions are attached to an IpSecRule does this mean that
they shall all be applied in sequence according to their order or shall we
understand that once an action has been achieved the rest of actions will
not be considered ?

All of them should be applied in sequence.

c) in case traffic shall be discarded or bypassed, it is written in the
description part of ipSecActionActionGroupId (page 20), that this last
attribute must be set to zero. In this case if one rule says that traffic
between A and B shall be discarded WITH NO logging and an other rule says
that traffic between C and D shall be discarded WITH logging this will lead
to create two ipSecActionEntries with GroupId set to zero. One will say
discard and no logging, the other will say discard and logging. If these
actions are attached to 2 different rules the corresponding action will
referenced an ipSecRuleIpSecActionGroupId of zero value that references
these two actions which are opposite. How will the system react ?

Good point! The restriction "When ipSecActionAction is bypass or discard,
this attribute must be zero" should be removed. The description of the Order
attribute needs corresponding modification.

2-My understanding of IKE is that IKE phase 1 an 2 are triggered by IPSec.
It seems in the document that Ike Rules can be established independently of
IPsec Rules. Does this means that other protocols than IPSec are today able
to make use of IKE ? If so, wouldn't this lead to the definition of a stand
alone IKE PIB ? The current definition allows to create a RuleEntry with a
role combination and constraints and ipSecRuleEntry to reference and IKE
Rule having the same rule combination. Isn't there here is a duplicated
information ?

There are three scenarios to be addressed. 

- IPsec policy controls both IKE phase 1 and 2 negotiation.
- IPsec policy controls only IKE phase 1 negotiation. 
- IPsec policy controls only IKE phase 2 negotiation.  

In order to address the last two scenarios, both IPsecRule and IKERule have
role combinations. For the first scenario, the requirement for IPsecRule and
IKERule to have the same role combination is to ensure the consistency. It
may be easier for IPsecRule to simply reference an IKERule without
concerning the role combination of IKERule. We need to think a bit more on
this.

 


From owner-ipsec-policy@mail.vpnc.org  Mon Feb 19 15:29:29 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14027
	for <ipsp-archive@odin.ietf.org>; Mon, 19 Feb 2001 15:29:28 -0500 (EST)
Received: by above.proper.com (8.9.3/8.9.3) id LAA15510
	for ipsec-policy-bks; Mon, 19 Feb 2001 11:11:59 -0800 (PST)
Received: from D2CSPIMG001.smartpipes.com ([63.89.185.24])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA15506
	for <ipsec-policy@vpnc.org>; Mon, 19 Feb 2001 11:11:58 -0800 (PST)
Received: by D2CSPIMG001.smartpipes.com with Internet Mail Service (5.5.2653.19)
	id <15HFS9HP>; Mon, 19 Feb 2001 19:11:30 -0000
Message-ID: <8E1E94178828D143B34A560A7A6F2C0B0199ACB8@mailmaestro.smartpipes.com>
From: "Wang, Cliff" <CWang@smartpipes.com>
To: ipsec-policy@vpnc.org
Subject: Question on IKERejectAction in IPsec information model 
Date: Mon, 19 Feb 2001 19:11:22 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

In the information mode:

6.5. The Class IKERejectAction

   The class IKERejectAction is used to prevent attempting an IKE
   negotiation with the peer(s).  The class definition for
   IKERejectAction is as follows:

   NAME         IKERejectAction
   DESCRIPTION  Specifies that an IKE negotiation should not even be
                attempted.
   DERIVED FROM SAStaticAction
   ABSTRACT     FALSE
   PROPERTIES   DoLogging


What is the action on the packet, discard/drop/use static SA? It only
specifies no IKE negotiation.


From owner-ipsec-policy@mail.vpnc.org  Tue Feb 20 18:55:42 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29692
	for <ipsp-archive@odin.ietf.org>; Tue, 20 Feb 2001 18:55:42 -0500 (EST)
Received: by above.proper.com (8.9.3/8.9.3) id OAA03106
	for ipsec-policy-bks; Tue, 20 Feb 2001 14:39:57 -0800 (PST)
Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA03102
	for <ipsec-policy@vpnc.org>; Tue, 20 Feb 2001 14:39:56 -0800 (PST)
Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id OAA19505;
	Tue, 20 Feb 2001 14:39:34 -0800 (PST)
Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Tue, 20 Feb 2001 22:35:32 0000 (GMT)
Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <10LSHT0Q>; Tue, 20 Feb 2001 10:59:04 -0800
Message-ID: <794826DE8867D411BAB8009027AE9EB904DD7AAD@FMSMSX38>
From: "Jason, Jamie" <jamie.jason@intel.com>
To: "'Wang, Cliff'" <CWang@smartpipes.com>, ipsec-policy@vpnc.org
Subject: RE: Question on IKERejectAction in IPsec information model 
Date: Tue, 20 Feb 2001 09:12:56 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

Cliff,

let me look into this and see if the DMTF model/whitepaper sheds any light
on it.  Upon re-reading the section, it seems to be vague and at a minimum
should probably discuss the different scenarios when that particular action
may be triggered (i.e., data packet sent/arrived with no SA, IKE packet
arrives, etc.).

Jamie

> -----Original Message-----
> From: Wang, Cliff [mailto:CWang@smartpipes.com]
> Sent: Monday, February 19, 2001 11:11 AM
> To: ipsec-policy@vpnc.org
> Subject: Question on IKERejectAction in IPsec information model 
> 
> 
> In the information mode:
> 
> 6.5. The Class IKERejectAction
> 
>    The class IKERejectAction is used to prevent attempting an IKE
>    negotiation with the peer(s).  The class definition for
>    IKERejectAction is as follows:
> 
>    NAME         IKERejectAction
>    DESCRIPTION  Specifies that an IKE negotiation should not even be
>                 attempted.
>    DERIVED FROM SAStaticAction
>    ABSTRACT     FALSE
>    PROPERTIES   DoLogging
> 
> 
> What is the action on the packet, discard/drop/use static SA? It only
> specifies no IKE negotiation.
> 



From owner-ipsec-policy@mail.vpnc.org  Tue Feb 20 21:06:12 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA01815
	for <ipsp-archive@odin.ietf.org>; Tue, 20 Feb 2001 21:06:11 -0500 (EST)
Received: by above.proper.com (8.9.3/8.9.3) id QAA06157
	for ipsec-policy-bks; Tue, 20 Feb 2001 16:54:19 -0800 (PST)
Received: from cisco.com (brussels.cisco.com [144.254.15.68])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA06153
	for <ipsec-policy@vpnc.org>; Tue, 20 Feb 2001 16:54:17 -0800 (PST)
Received: from evyncke-8kcdt.cisco.com (dhcp-171-69-37-14.cisco.com [171.69.37.14])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id BAA17715;
	Wed, 21 Feb 2001 01:53:27 +0100 (MET)
Message-Id: <4.3.2.7.2.20010221014347.00b28170@brussels.cisco.com>
X-Sender: evyncke@brussels.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 21 Feb 2001 01:53:59 +0100
To: "Jason, Jamie" <jamie.jason@intel.com>,
        "'Wang, Cliff'" <CWang@smartpipes.com>, ipsec-policy@vpnc.org
From: Eric Vyncke <evyncke@cisco.com>
Subject: RE: Question on IKERejectAction in IPsec information model 
In-Reply-To: <794826DE8867D411BAB8009027AE9EB904DD7AAD@FMSMSX38>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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>

Jamie,

As far as I can remember, this action was mainly to reject an IKE
session from specific peers. I.e. actually denying a remote peer
to send IKE packet to us. The filter could be on IP addresses or
IKE identity (in the case of aggressive mode).

Hence, if I am not mistaken, the description is wrong and should
be fixed.

Cliff, 

this action should only be applied for inbound filters for
UDP/500 or from some IKE identities.

-eric

At 09:12 20/02/01 -0800, Jason, Jamie wrote:
>Cliff,
>
>let me look into this and see if the DMTF model/whitepaper sheds any light
>on it.  Upon re-reading the section, it seems to be vague and at a minimum
>should probably discuss the different scenarios when that particular action
>may be triggered (i.e., data packet sent/arrived with no SA, IKE packet
>arrives, etc.).
>
>Jamie
>
>> -----Original Message-----
>> From: Wang, Cliff [mailto:CWang@smartpipes.com]
>> Sent: Monday, February 19, 2001 11:11 AM
>> To: ipsec-policy@vpnc.org
>> Subject: Question on IKERejectAction in IPsec information model 
>> 
>> 
>> In the information mode:
>> 
>> 6.5. The Class IKERejectAction
>> 
>>    The class IKERejectAction is used to prevent attempting an IKE
>>    negotiation with the peer(s).  The class definition for
>>    IKERejectAction is as follows:
>> 
>>    NAME         IKERejectAction
>>    DESCRIPTION  Specifies that an IKE negotiation should not even be
>>                 attempted.
>>    DERIVED FROM SAStaticAction
>>    ABSTRACT     FALSE
>>    PROPERTIES   DoLogging
>> 
>> 
>> What is the action on the packet, discard/drop/use static SA? It only
>> specifies no IKE negotiation.
>> 

Eric Vyncke                        
Distinguished Engineer             Cisco Systems EMEA
Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
E-mail: evyncke@cisco.com          Mobile: +32-475-312.458 (CHANGED)
PGP fingerprint: D35F BEF9 643F 656F 90F5  76C5 9CA1 C289 D398 B141



From owner-ipsec-policy@mail.vpnc.org  Tue Feb 20 21:55:51 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03108
	for <ipsp-archive@odin.ietf.org>; Tue, 20 Feb 2001 21:55:51 -0500 (EST)
Received: by above.proper.com (8.9.3/8.9.3) id RAA08213
	for ipsec-policy-bks; Tue, 20 Feb 2001 17:52:25 -0800 (PST)
Received: from ganymede.or.intel.com (jffdns01.or.intel.com [134.134.248.3])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id RAA08209
	for <ipsec-policy@vpnc.org>; Tue, 20 Feb 2001 17:52:23 -0800 (PST)
Received: from SMTP (orsmsxvs02-1.jf.intel.com [192.168.65.201])
	by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id RAA15790;
	Tue, 20 Feb 2001 17:52:03 -0800 (PST)
Received: from orsmsx29.jf.intel.com ([192.168.70.29]) by 192.168.70.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 21 Feb 2001 01:52:03 0000 (GMT)
Received: by orsmsx29.jf.intel.com with Internet Mail Service (5.5.2653.19)
	id <FKYVJ8TX>; Tue, 20 Feb 2001 17:52:00 -0800
Message-ID: <794826DE8867D411BAB8009027AE9EB904DD7ABA@FMSMSX38>
From: "Jason, Jamie" <jamie.jason@intel.com>
To: "'Eric Vyncke'" <evyncke@cisco.com>,
        "'Wang, Cliff'"
	 <CWang@smartpipes.com>, ipsec-policy@vpnc.org
Subject: RE: Question on IKERejectAction in IPsec information model 
Date: Tue, 20 Feb 2001 17:18:49 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

That is what I was thinking as we already have a mechanism in place (via the
static actions bypass/discard) for noting that we don't wish to do any IKE
for certain types of packets.

Jamie

> -----Original Message-----
> From: Eric Vyncke [mailto:evyncke@cisco.com]
> Sent: Tuesday, February 20, 2001 4:54 PM
> To: Jason, Jamie; 'Wang, Cliff'; ipsec-policy@vpnc.org
> Subject: RE: Question on IKERejectAction in IPsec information model 
> 
> 
> Jamie,
> 
> As far as I can remember, this action was mainly to reject an IKE
> session from specific peers. I.e. actually denying a remote peer
> to send IKE packet to us. The filter could be on IP addresses or
> IKE identity (in the case of aggressive mode).
> 
> Hence, if I am not mistaken, the description is wrong and should
> be fixed.
> 
> Cliff, 
> 
> this action should only be applied for inbound filters for
> UDP/500 or from some IKE identities.
> 
> -eric
> 
> At 09:12 20/02/01 -0800, Jason, Jamie wrote:
> >Cliff,
> >
> >let me look into this and see if the DMTF model/whitepaper 
> sheds any light
> >on it.  Upon re-reading the section, it seems to be vague 
> and at a minimum
> >should probably discuss the different scenarios when that 
> particular action
> >may be triggered (i.e., data packet sent/arrived with no SA, 
> IKE packet
> >arrives, etc.).
> >
> >Jamie
> >
> >> -----Original Message-----
> >> From: Wang, Cliff [mailto:CWang@smartpipes.com]
> >> Sent: Monday, February 19, 2001 11:11 AM
> >> To: ipsec-policy@vpnc.org
> >> Subject: Question on IKERejectAction in IPsec information model 
> >> 
> >> 
> >> In the information mode:
> >> 
> >> 6.5. The Class IKERejectAction
> >> 
> >>    The class IKERejectAction is used to prevent attempting an IKE
> >>    negotiation with the peer(s).  The class definition for
> >>    IKERejectAction is as follows:
> >> 
> >>    NAME         IKERejectAction
> >>    DESCRIPTION  Specifies that an IKE negotiation should 
> not even be
> >>                 attempted.
> >>    DERIVED FROM SAStaticAction
> >>    ABSTRACT     FALSE
> >>    PROPERTIES   DoLogging
> >> 
> >> 
> >> What is the action on the packet, discard/drop/use static 
> SA? It only
> >> specifies no IKE negotiation.
> >> 
> 
> Eric Vyncke                        
> Distinguished Engineer             Cisco Systems EMEA
> Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
> E-mail: evyncke@cisco.com          Mobile: +32-475-312.458 (CHANGED)
> PGP fingerprint: D35F BEF9 643F 656F 90F5  76C5 9CA1 C289 D398 B141
> 
> 



From owner-ipsec-policy@mail.vpnc.org  Wed Feb 21 11:18:13 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01460
	for <ipsp-archive@odin.ietf.org>; Wed, 21 Feb 2001 11:18:13 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.9.3/8.9.3) id GAA09206
	for ipsec-policy-bks; Wed, 21 Feb 2001 06:49:10 -0800 (PST)
Received: from D2CSPIMG001.smartpipes.com ([63.89.185.24])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA09198
	for <ipsec-policy@vpnc.org>; Wed, 21 Feb 2001 06:49:07 -0800 (PST)
Received: by D2CSPIMG001.smartpipes.com with Internet Mail Service (5.5.2653.19)
	id <FKJ8Q151>; Wed, 21 Feb 2001 14:48:40 -0000
Message-ID: <8E1E94178828D143B34A560A7A6F2C0B0199ACC8@mailmaestro.smartpipes.com>
From: "Wang, Cliff" <CWang@smartpipes.com>
To: "'Jason, Jamie'" <jamie.jason@intel.com>,
        "'Eric Vyncke'"
	 <evyncke@cisco.com>, ipsec-policy@vpnc.org
Subject: RE: Question on IKERejectAction in IPsec information model 
Date: Wed, 21 Feb 2001 14:48:40 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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 any rule with IKERejectAction is to stop negotiation
by dropping the packets? Or I have to pass a message
to the IKE engine to drop the request and let the packet
pass the filter?

Would it be simpler just to have a drop rule to stop
the IKE packets?

If the filter is of type IKE identity, then there are 
a couple of issues:
1) The main mode identity won't come in until 5th
message. At that time, you have done D-H exchange.
If the purpose of this filter is to prevent
denial-of-service, the adversary has just defeated that.
2) The filter code itself has no IKE protocol
intelligence. That means the IKE engine has to
lookup up the filter again after receiving
the ID payload. This requirement is not RFC 2409
specified.

I would suggest that to stop peer IKE negotiation,
just set up a simple drop rule with that peer
on UDP port 500.

-----Original Message-----
From: Jason, Jamie [mailto:jamie.jason@intel.com]
Sent: Tuesday, February 20, 2001 8:19 PM
To: 'Eric Vyncke'; 'Wang, Cliff'; ipsec-policy@vpnc.org
Subject: RE: Question on IKERejectAction in IPsec information model 


That is what I was thinking as we already have a mechanism in place (via the
static actions bypass/discard) for noting that we don't wish to do any IKE
for certain types of packets.

Jamie

> -----Original Message-----
> From: Eric Vyncke [mailto:evyncke@cisco.com]
> Sent: Tuesday, February 20, 2001 4:54 PM
> To: Jason, Jamie; 'Wang, Cliff'; ipsec-policy@vpnc.org
> Subject: RE: Question on IKERejectAction in IPsec information model 
> 
> 
> Jamie,
> 
> As far as I can remember, this action was mainly to reject an IKE
> session from specific peers. I.e. actually denying a remote peer
> to send IKE packet to us. The filter could be on IP addresses or
> IKE identity (in the case of aggressive mode).
> 
> Hence, if I am not mistaken, the description is wrong and should
> be fixed.
> 
> Cliff, 
> 
> this action should only be applied for inbound filters for
> UDP/500 or from some IKE identities.
> 
> -eric
> 
> At 09:12 20/02/01 -0800, Jason, Jamie wrote:
> >Cliff,
> >
> >let me look into this and see if the DMTF model/whitepaper 
> sheds any light
> >on it.  Upon re-reading the section, it seems to be vague 
> and at a minimum
> >should probably discuss the different scenarios when that 
> particular action
> >may be triggered (i.e., data packet sent/arrived with no SA, 
> IKE packet
> >arrives, etc.).
> >
> >Jamie
> >
> >> -----Original Message-----
> >> From: Wang, Cliff [mailto:CWang@smartpipes.com]
> >> Sent: Monday, February 19, 2001 11:11 AM
> >> To: ipsec-policy@vpnc.org
> >> Subject: Question on IKERejectAction in IPsec information model 
> >> 
> >> 
> >> In the information mode:
> >> 
> >> 6.5. The Class IKERejectAction
> >> 
> >>    The class IKERejectAction is used to prevent attempting an IKE
> >>    negotiation with the peer(s).  The class definition for
> >>    IKERejectAction is as follows:
> >> 
> >>    NAME         IKERejectAction
> >>    DESCRIPTION  Specifies that an IKE negotiation should 
> not even be
> >>                 attempted.
> >>    DERIVED FROM SAStaticAction
> >>    ABSTRACT     FALSE
> >>    PROPERTIES   DoLogging
> >> 
> >> 
> >> What is the action on the packet, discard/drop/use static 
> SA? It only
> >> specifies no IKE negotiation.
> >> 
> 
> Eric Vyncke                        
> Distinguished Engineer             Cisco Systems EMEA
> Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
> E-mail: evyncke@cisco.com          Mobile: +32-475-312.458 (CHANGED)
> PGP fingerprint: D35F BEF9 643F 656F 90F5  76C5 9CA1 C289 D398 B141
> 
> 


From owner-ipsec-policy@mail.vpnc.org  Wed Feb 21 15:12:12 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08286
	for <ipsp-archive@odin.ietf.org>; Wed, 21 Feb 2001 15:12:11 -0500 (EST)
Received: by above.proper.com (8.9.3/8.9.3) id KAA23271
	for ipsec-policy-bks; Wed, 21 Feb 2001 10:24:51 -0800 (PST)
Received: from wanderer.hardakers.net (IDENT:root@dns2.hardaker.davis.ca.us [168.150.190.2])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA23265
	for <ipsec-policy@vpnc.org>; Wed, 21 Feb 2001 10:24:49 -0800 (PST)
Received: (from hardaker@localhost)
	by wanderer.hardakers.net (8.9.3/8.9.3) id KAA02366;
	Wed, 21 Feb 2001 10:28:14 -0800
X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f
To: ipsec-policy@vpnc.org
Subject: classification level filter objects
From: Wes Hardaker <wes@hardakers.net>
X-URL: http://dcas.ucdavis.edu/~hardaker
Organization: Network Associates - NAI Labs
X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA
 SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/
 IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4
Date: 21 Feb 2001 10:28:12 -0800
Message-ID: <sd8zmzhow3.fsf@wanderer.hardakers.net>
Lines: 12
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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 ClassificationLevelFilterEntry class defines a Level parameter
that the filter must match against.  I take it this is an exact match?
IE, if the packet's Classification level is not exactly equal to the
ClassificationLevelFilterEntry.Level value then it doesn't match?  (A
< or > operator might make some sense here, possibly as a separate
property dictating which to use (<, >, !=, ==).

-- 
Wes Hardaker
NAI Labs
Network Associates


From owner-ipsec-policy@mail.vpnc.org  Wed Feb 21 18:37:00 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13881
	for <ipsp-archive@odin.ietf.org>; Wed, 21 Feb 2001 18:37:00 -0500 (EST)
Received: by above.proper.com (8.9.3/8.9.3) id OAA28574
	for ipsec-policy-bks; Wed, 21 Feb 2001 14:23:18 -0800 (PST)
Received: from cisco.com (brussels.cisco.com [144.254.15.68])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA28570
	for <ipsec-policy@vpnc.org>; Wed, 21 Feb 2001 14:23:16 -0800 (PST)
Received: from evyncke-8kcdt.cisco.com (dhcp-1sjc13-2-83-54.cisco.com [171.70.83.54])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA16918;
	Wed, 21 Feb 2001 23:22:38 +0100 (MET)
Message-Id: <4.3.2.7.2.20010221231447.00b3b950@brussels.cisco.com>
X-Sender: evyncke@brussels.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 21 Feb 2001 23:23:11 +0100
To: Wes Hardaker <wes@hardakers.net>, ipsec-policy@vpnc.org
From: Eric Vyncke <evyncke@cisco.com>
Subject: Re: classification level filter objects
In-Reply-To: <sd8zmzhow3.fsf@wanderer.hardakers.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
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>

Wes,

This is a good point. RFC2401 point 8.2 clearly talks about a RANGE
of sensitivity labels. So, the IPSOFilterEntry should
be changed to add a range (plus possibly ==).

BTW, I assumed that you are talking about the DMTF IPSOFilterEntry
because I cannot find ClassificationLevelFilterEntry in the current
DMTF model.

Regards

-eric


At 10:28 21/02/01 -0800, Wes Hardaker wrote:
>The ClassificationLevelFilterEntry class defines a Level parameter
>that the filter must match against.  I take it this is an exact match?
>IE, if the packet's Classification level is not exactly equal to the
>ClassificationLevelFilterEntry.Level value then it doesn't match?  (A
>< or > operator might make some sense here, possibly as a separate
>property dictating which to use (<, >, !=, ==).
>
>-- 
>Wes Hardaker
>NAI Labs
>Network Associates 

Eric Vyncke                        
Distinguished Engineer             Cisco Systems EMEA
Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
E-mail: evyncke@cisco.com          Mobile: +32-475-312.458 (CHANGED)
PGP fingerprint: D35F BEF9 643F 656F 90F5  76C5 9CA1 C289 D398 B141



From owner-ipsec-policy@mail.vpnc.org  Wed Feb 21 18:39:20 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13930
	for <ipsp-archive@odin.ietf.org>; Wed, 21 Feb 2001 18:39:17 -0500 (EST)
Received: by above.proper.com (8.9.3/8.9.3) id OAA29679
	for ipsec-policy-bks; Wed, 21 Feb 2001 14:36:31 -0800 (PST)
Received: from wanderer.hardakers.net (IDENT:root@dns2.hardaker.davis.ca.us [168.150.190.2])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA29654
	for <ipsec-policy@vpnc.org>; Wed, 21 Feb 2001 14:36:21 -0800 (PST)
Received: (from hardaker@localhost)
	by wanderer.hardakers.net (8.9.3/8.9.3) id OAA02862;
	Wed, 21 Feb 2001 14:38:56 -0800
X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f
To: Eric Vyncke <evyncke@cisco.com>
Cc: ipsec-policy@vpnc.org
Subject: Re: classification level filter objects
References: <4.3.2.7.2.20010221231447.00b3b950@brussels.cisco.com>
From: Wes Hardaker <wes@hardakers.net>
X-URL: http://dcas.ucdavis.edu/~hardaker
Organization: Network Associates - NAI Labs
X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA
 SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/
 IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4
Date: 21 Feb 2001 14:38:56 -0800
In-Reply-To: <4.3.2.7.2.20010221231447.00b3b950@brussels.cisco.com> (Eric Vyncke's message of "Wed, 21 Feb 2001 23:23:11 +0100")
Message-ID: <sdhf1nd5kv.fsf@wanderer.hardakers.net>
Lines: 12
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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>

>>>>> On Wed, 21 Feb 2001 23:23:11 +0100, Eric Vyncke <evyncke@cisco.com> said:

Eric> BTW, I assumed that you are talking about the DMTF
Eric> IPSOFilterEntry because I cannot find
Eric> ClassificationLevelFilterEntry in the current DMTF model.

It came from the draft-ietf-ipsp-config-policy-model-01 draft.

-- 
Wes Hardaker
NAI Labs
Network Associates


From owner-ipsec-policy@mail.vpnc.org  Wed Feb 21 19:24:38 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14805
	for <ipsp-archive@odin.ietf.org>; Wed, 21 Feb 2001 19:24:37 -0500 (EST)
Received: by above.proper.com (8.9.3/8.9.3) id PAA02692
	for ipsec-policy-bks; Wed, 21 Feb 2001 15:26:15 -0800 (PST)
Received: from wanderer.hardakers.net (IDENT:root@dns2.hardaker.davis.ca.us [168.150.190.2])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA02685
	for <ipsec-policy@vpnc.org>; Wed, 21 Feb 2001 15:26:12 -0800 (PST)
Received: (from hardaker@localhost)
	by wanderer.hardakers.net (8.9.3/8.9.3) id PAA03024;
	Wed, 21 Feb 2001 15:29:31 -0800
X-Authentication-Warning: wanderer.hardakers.net: hardaker set sender to wes@hardakers.net using -f
To: "Jason, Jamie" <jamie.jason@intel.com>
Cc: Eric Vyncke <evyncke@cisco.com>, ipsec-policy@vpnc.org
Subject: Re: classification level filter objects
References: <794826DE8867D411BAB8009027AE9EB904DD7ABF@FMSMSX38>
From: Wes Hardaker <wes@hardakers.net>
X-URL: http://dcas.ucdavis.edu/~hardaker
Organization: Network Associates - NAI Labs
X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA
 SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/
 IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4
Date: 21 Feb 2001 15:29:29 -0800
In-Reply-To: <794826DE8867D411BAB8009027AE9EB904DD7ABF@FMSMSX38> ("Jason, Jamie"'s message of "Wed, 21 Feb 2001 15:19:03 -0800")
Message-ID: <sdbsrvd38m.fsf@wanderer.hardakers.net>
Lines: 20
User-Agent: Gnus/5.090001 (Oort Gnus v0.01) XEmacs/21.2 (Terspichore)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
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>

>>>>> On Wed, 21 Feb 2001 15:19:03 -0800, "Jason, Jamie" <jamie.jason@intel.com> said:

Jamie> that class is being removed as we speak (I am in the process of
Jamie> updating the draft right now) - the class IPSOFilterEntry will
Jamie> take over the functionality that was originally in
Jamie> ClassificationLevelFilterEntry.

Thanks for the info.

Jamie> At the current time, there is only a mechanism to provide an
Jamie> exact match.  Stay tuned as the filter stuff could be in flux
Jamie> as there is PCIM extensions work that could affect that filter
Jamie> entries in the IPsec model.

Heh.  That's going to make writing the IPSEC-POLICY-MIB difficult ;-)

-- 
Wes Hardaker
NAI Labs
Network Associates


From owner-ipsec-policy@mail.vpnc.org  Wed Feb 21 19:28:43 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14866
	for <ipsp-archive@odin.ietf.org>; Wed, 21 Feb 2001 19:28:42 -0500 (EST)
Received: by above.proper.com (8.9.3/8.9.3) id PAA02345
	for ipsec-policy-bks; Wed, 21 Feb 2001 15:19:28 -0800 (PST)
Received: from thalia.fm.intel.com (fmfdns02.fm.intel.com [132.233.247.11])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id PAA02341
	for <ipsec-policy@vpnc.org>; Wed, 21 Feb 2001 15:19:27 -0800 (PST)
Received: from SMTP (fmsmsxvs01-1.fm.intel.com [132.233.42.201])
	by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id XAA13830;
	Wed, 21 Feb 2001 23:19:11 GMT
Received: from fmsmsx17.intel.com ([132.233.48.17]) by 132.233.48.201
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Wed, 21 Feb 2001 23:19:11 0000 (GMT)
Received: by fmsmsx17.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <FMQD64SZ>; Wed, 21 Feb 2001 15:19:09 -0800
Message-ID: <794826DE8867D411BAB8009027AE9EB904DD7ABF@FMSMSX38>
From: "Jason, Jamie" <jamie.jason@intel.com>
To: "'Wes Hardaker'" <wes@hardakers.net>, Eric Vyncke <evyncke@cisco.com>
Cc: ipsec-policy@vpnc.org
Subject: RE: classification level filter objects
Date: Wed, 21 Feb 2001 15:19:03 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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>

Wes,

that class is being removed as we speak (I am in the process of updating the
draft right now) - the class IPSOFilterEntry will take over the
functionality that was originally in ClassificationLevelFilterEntry.  At the
current time, there is only a mechanism to provide an exact match.  Stay
tuned as the filter stuff could be in flux as there is PCIM extensions work
that could affect that filter entries in the IPsec model.

Jamie

> -----Original Message-----
> From: Wes Hardaker [mailto:wes@hardakers.net]
> Sent: Wednesday, February 21, 2001 2:39 PM
> To: Eric Vyncke
> Cc: ipsec-policy@vpnc.org
> Subject: Re: classification level filter objects
> 
> 
> >>>>> On Wed, 21 Feb 2001 23:23:11 +0100, Eric Vyncke 
> <evyncke@cisco.com> said:
> 
> Eric> BTW, I assumed that you are talking about the DMTF
> Eric> IPSOFilterEntry because I cannot find
> Eric> ClassificationLevelFilterEntry in the current DMTF model.
> 
> It came from the draft-ietf-ipsp-config-policy-model-01 draft.
> 
> -- 
> Wes Hardaker
> NAI Labs
> Network Associates
> 



From owner-ipsec-policy@mail.vpnc.org  Thu Feb 22 14:02:20 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22943
	for <ipsp-archive@odin.ietf.org>; Thu, 22 Feb 2001 14:02:12 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.9.3/8.9.3) id JAA24167
	for ipsec-policy-bks; Thu, 22 Feb 2001 09:40:04 -0800 (PST)
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id JAA24163
	for <ipsec-policy@vpnc.org>; Thu, 22 Feb 2001 09:40:02 -0800 (PST)
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA17872
	for <ipsec-policy@vpnc.org>; Thu, 22 Feb 2001 12:39:31 -0500
Received: from lmr (dyn9-37-49-17.raleigh.ibm.com [9.37.49.17])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id MAA28606
	for <ipsec-policy@vpnc.org>; Thu, 22 Feb 2001 12:39:33 -0500
Message-ID: <007a01c09cf5$fe1fee80$11312509@raleigh.ibm.com>
From: "Lee Rafalow" <rafalow@raleigh.ibm.com>
To: <ipsec-policy@vpnc.org>
References: <8E1E94178828D143B34A560A7A6F2C0B0199ACC8@mailmaestro.smartpipes.com>
Subject: Re: Question on IKERejectAction in IPsec information model 
Date: Thu, 22 Feb 2001 12:36:28 -0500
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.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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>
Content-Transfer-Encoding: 7bit

The intent of the IKERejectAction is to specify the drop rule for UDP port
500.  The implementation of this drop rule is more likely to be in the stack
than in the IKE service, but the functional decomposition is not addressed
in the model.  For the IKE Service, the IKERejectAction could be in a rule
that has condition=TRUE with the lowest priority to provide an explicit rule
for the default action as a responder.  So, for example, when you do get the
ID payload, it no longer matches the rule that was being used but now
matches this lower priority default rule.  Does this help or am I missing
something?

I'll fix the wording in the DMTF MOF to improve clarity and it'll get
reflected into the IETF draft.  Thanks, Lee

----- Original Message -----
From: "Wang, Cliff" <CWang@smartpipes.com>
To: "'Jason, Jamie'" <jamie.jason@intel.com>; "'Eric Vyncke'"
<evyncke@cisco.com>; <ipsec-policy@vpnc.org>
Sent: Wednesday, February 21, 2001 9:48 AM
Subject: RE: Question on IKERejectAction in IPsec information model


> So any rule with IKERejectAction is to stop negotiation
> by dropping the packets? Or I have to pass a message
> to the IKE engine to drop the request and let the packet
> pass the filter?
>
> Would it be simpler just to have a drop rule to stop
> the IKE packets?
>
> If the filter is of type IKE identity, then there are
> a couple of issues:
> 1) The main mode identity won't come in until 5th
> message. At that time, you have done D-H exchange.
> If the purpose of this filter is to prevent
> denial-of-service, the adversary has just defeated that.
> 2) The filter code itself has no IKE protocol
> intelligence. That means the IKE engine has to
> lookup up the filter again after receiving
> the ID payload. This requirement is not RFC 2409
> specified.
>
> I would suggest that to stop peer IKE negotiation,
> just set up a simple drop rule with that peer
> on UDP port 500.
>
> -----Original Message-----
> From: Jason, Jamie [mailto:jamie.jason@intel.com]
> Sent: Tuesday, February 20, 2001 8:19 PM
> To: 'Eric Vyncke'; 'Wang, Cliff'; ipsec-policy@vpnc.org
> Subject: RE: Question on IKERejectAction in IPsec information model
>
>
> That is what I was thinking as we already have a mechanism in place (via
the
> static actions bypass/discard) for noting that we don't wish to do any IKE
> for certain types of packets.
>
> Jamie
>
> > -----Original Message-----
> > From: Eric Vyncke [mailto:evyncke@cisco.com]
> > Sent: Tuesday, February 20, 2001 4:54 PM
> > To: Jason, Jamie; 'Wang, Cliff'; ipsec-policy@vpnc.org
> > Subject: RE: Question on IKERejectAction in IPsec information model
> >
> >
> > Jamie,
> >
> > As far as I can remember, this action was mainly to reject an IKE
> > session from specific peers. I.e. actually denying a remote peer
> > to send IKE packet to us. The filter could be on IP addresses or
> > IKE identity (in the case of aggressive mode).
> >
> > Hence, if I am not mistaken, the description is wrong and should
> > be fixed.
> >
> > Cliff,
> >
> > this action should only be applied for inbound filters for
> > UDP/500 or from some IKE identities.
> >
> > -eric
> >
> > At 09:12 20/02/01 -0800, Jason, Jamie wrote:
> > >Cliff,
> > >
> > >let me look into this and see if the DMTF model/whitepaper
> > sheds any light
> > >on it.  Upon re-reading the section, it seems to be vague
> > and at a minimum
> > >should probably discuss the different scenarios when that
> > particular action
> > >may be triggered (i.e., data packet sent/arrived with no SA,
> > IKE packet
> > >arrives, etc.).
> > >
> > >Jamie
> > >
> > >> -----Original Message-----
> > >> From: Wang, Cliff [mailto:CWang@smartpipes.com]
> > >> Sent: Monday, February 19, 2001 11:11 AM
> > >> To: ipsec-policy@vpnc.org
> > >> Subject: Question on IKERejectAction in IPsec information model
> > >>
> > >>
> > >> In the information mode:
> > >>
> > >> 6.5. The Class IKERejectAction
> > >>
> > >>    The class IKERejectAction is used to prevent attempting an IKE
> > >>    negotiation with the peer(s).  The class definition for
> > >>    IKERejectAction is as follows:
> > >>
> > >>    NAME         IKERejectAction
> > >>    DESCRIPTION  Specifies that an IKE negotiation should
> > not even be
> > >>                 attempted.
> > >>    DERIVED FROM SAStaticAction
> > >>    ABSTRACT     FALSE
> > >>    PROPERTIES   DoLogging
> > >>
> > >>
> > >> What is the action on the packet, discard/drop/use static
> > SA? It only
> > >> specifies no IKE negotiation.
> > >>
> >
> > Eric Vyncke
> > Distinguished Engineer             Cisco Systems EMEA
> > Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
> > E-mail: evyncke@cisco.com          Mobile: +32-475-312.458 (CHANGED)
> > PGP fingerprint: D35F BEF9 643F 656F 90F5  76C5 9CA1 C289 D398 B141
> >
> >



From owner-ipsec-policy@mail.vpnc.org  Thu Feb 22 16:03:14 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA27320
	for <ipsp-archive@odin.ietf.org>; Thu, 22 Feb 2001 16:03:04 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.9.3/8.9.3) id LAA29033
	for ipsec-policy-bks; Thu, 22 Feb 2001 11:31:32 -0800 (PST)
Received: from D2CSPIMG001.smartpipes.com ([63.89.185.24])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA29028
	for <ipsec-policy@vpnc.org>; Thu, 22 Feb 2001 11:31:31 -0800 (PST)
Received: by D2CSPIMG001.smartpipes.com with Internet Mail Service (5.5.2653.19)
	id <FKJ8Q2R0>; Thu, 22 Feb 2001 19:31:01 -0000
Message-ID: <8E1E94178828D143B34A560A7A6F2C0B0199ACD0@mailmaestro.smartpipes.com>
From: "Wang, Cliff" <CWang@smartpipes.com>
To: "'Lee Rafalow'" <rafalow@raleigh.ibm.com>, ipsec-policy@vpnc.org
Subject: RE: Question on IKERejectAction in IPsec information model 
Date: Thu, 22 Feb 2001 19:30:54 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
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>

Yes, I see the intended purpose of this IKERejectAction.
But I am still doubtful about its usefulness.
When you find that an incoming ID mis-matches, I think that
a sane IKE implementation would drop the negotiation there.
Looking up the rule again for this default rule seems
unnecessary, or I am missing something?

-----Original Message-----
From: Lee Rafalow [mailto:rafalow@raleigh.ibm.com]
Sent: Thursday, February 22, 2001 12:36 PM
To: ipsec-policy@vpnc.org
Subject: Re: Question on IKERejectAction in IPsec information model 


The intent of the IKERejectAction is to specify the drop rule for UDP port
500.  The implementation of this drop rule is more likely to be in the stack
than in the IKE service, but the functional decomposition is not addressed
in the model.  For the IKE Service, the IKERejectAction could be in a rule
that has condition=TRUE with the lowest priority to provide an explicit rule
for the default action as a responder.  So, for example, when you do get the
ID payload, it no longer matches the rule that was being used but now
matches this lower priority default rule.  Does this help or am I missing
something?

I'll fix the wording in the DMTF MOF to improve clarity and it'll get
reflected into the IETF draft.  Thanks, Lee

----- Original Message -----
From: "Wang, Cliff" <CWang@smartpipes.com>
To: "'Jason, Jamie'" <jamie.jason@intel.com>; "'Eric Vyncke'"
<evyncke@cisco.com>; <ipsec-policy@vpnc.org>
Sent: Wednesday, February 21, 2001 9:48 AM
Subject: RE: Question on IKERejectAction in IPsec information model


> So any rule with IKERejectAction is to stop negotiation
> by dropping the packets? Or I have to pass a message
> to the IKE engine to drop the request and let the packet
> pass the filter?
>
> Would it be simpler just to have a drop rule to stop
> the IKE packets?
>
> If the filter is of type IKE identity, then there are
> a couple of issues:
> 1) The main mode identity won't come in until 5th
> message. At that time, you have done D-H exchange.
> If the purpose of this filter is to prevent
> denial-of-service, the adversary has just defeated that.
> 2) The filter code itself has no IKE protocol
> intelligence. That means the IKE engine has to
> lookup up the filter again after receiving
> the ID payload. This requirement is not RFC 2409
> specified.
>
> I would suggest that to stop peer IKE negotiation,
> just set up a simple drop rule with that peer
> on UDP port 500.
>
> -----Original Message-----
> From: Jason, Jamie [mailto:jamie.jason@intel.com]
> Sent: Tuesday, February 20, 2001 8:19 PM
> To: 'Eric Vyncke'; 'Wang, Cliff'; ipsec-policy@vpnc.org
> Subject: RE: Question on IKERejectAction in IPsec information model
>
>
> That is what I was thinking as we already have a mechanism in place (via
the
> static actions bypass/discard) for noting that we don't wish to do any IKE
> for certain types of packets.
>
> Jamie
>
> > -----Original Message-----
> > From: Eric Vyncke [mailto:evyncke@cisco.com]
> > Sent: Tuesday, February 20, 2001 4:54 PM
> > To: Jason, Jamie; 'Wang, Cliff'; ipsec-policy@vpnc.org
> > Subject: RE: Question on IKERejectAction in IPsec information model
> >
> >
> > Jamie,
> >
> > As far as I can remember, this action was mainly to reject an IKE
> > session from specific peers. I.e. actually denying a remote peer
> > to send IKE packet to us. The filter could be on IP addresses or
> > IKE identity (in the case of aggressive mode).
> >
> > Hence, if I am not mistaken, the description is wrong and should
> > be fixed.
> >
> > Cliff,
> >
> > this action should only be applied for inbound filters for
> > UDP/500 or from some IKE identities.
> >
> > -eric
> >
> > At 09:12 20/02/01 -0800, Jason, Jamie wrote:
> > >Cliff,
> > >
> > >let me look into this and see if the DMTF model/whitepaper
> > sheds any light
> > >on it.  Upon re-reading the section, it seems to be vague
> > and at a minimum
> > >should probably discuss the different scenarios when that
> > particular action
> > >may be triggered (i.e., data packet sent/arrived with no SA,
> > IKE packet
> > >arrives, etc.).
> > >
> > >Jamie
> > >
> > >> -----Original Message-----
> > >> From: Wang, Cliff [mailto:CWang@smartpipes.com]
> > >> Sent: Monday, February 19, 2001 11:11 AM
> > >> To: ipsec-policy@vpnc.org
> > >> Subject: Question on IKERejectAction in IPsec information model
> > >>
> > >>
> > >> In the information mode:
> > >>
> > >> 6.5. The Class IKERejectAction
> > >>
> > >>    The class IKERejectAction is used to prevent attempting an IKE
> > >>    negotiation with the peer(s).  The class definition for
> > >>    IKERejectAction is as follows:
> > >>
> > >>    NAME         IKERejectAction
> > >>    DESCRIPTION  Specifies that an IKE negotiation should
> > not even be
> > >>                 attempted.
> > >>    DERIVED FROM SAStaticAction
> > >>    ABSTRACT     FALSE
> > >>    PROPERTIES   DoLogging
> > >>
> > >>
> > >> What is the action on the packet, discard/drop/use static
> > SA? It only
> > >> specifies no IKE negotiation.
> > >>
> >
> > Eric Vyncke
> > Distinguished Engineer             Cisco Systems EMEA
> > Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
> > E-mail: evyncke@cisco.com          Mobile: +32-475-312.458 (CHANGED)
> > PGP fingerprint: D35F BEF9 643F 656F 90F5  76C5 9CA1 C289 D398 B141
> >
> >


From owner-ipsec-policy@mail.vpnc.org  Thu Feb 22 23:11:19 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA07513
	for <ipsp-archive@odin.ietf.org>; Thu, 22 Feb 2001 23:11:19 -0500 (EST)
Received: by above.proper.com (8.9.3/8.9.3) id TAA23351
	for ipsec-policy-bks; Thu, 22 Feb 2001 19:19:13 -0800 (PST)
Received: from rc_westlake.interdyn.com ([205.147.53.144])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA23346
	for <ipsec-policy@vpnc.org>; Thu, 22 Feb 2001 19:19:12 -0800 (PST)
Received: by RC_WESTLAKE with Internet Mail Service (5.5.2653.19)
	id <FPGYVQK7>; Thu, 22 Feb 2001 19:18:51 -0800
Received: from redcreek.com (host186.redcreek.com [209.218.26.186]) by exchange.redcreek.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id F3KS95S1; Thu, 22 Feb 2001 19:18:50 -0800
Message-ID: <3A95C9FF.DEE3AD00@redcreek.com>
Date: Thu, 22 Feb 2001 19:25:03 -0700
From: Ricky Charlet <rcharlet@redcreek.com>
Organization: Redcreek Communications
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.16-22 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: ".ipsec-policy" <ipsec-policy@vpnc.org>
Subject: Information Model question.
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>
Content-Transfer-Encoding: 7bit

Howdy,

	I can't seem to find AntiReplay properties in the DMTF IPsec Policy
Model. I would expect them in the AHTransform and ESPTransform. Am I
just looking in the wrong place?


-- 
  Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903


From owner-ipsec-policy@mail.vpnc.org  Fri Feb 23 12:28:24 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10202
	for <ipsp-archive@odin.ietf.org>; Fri, 23 Feb 2001 12:28:22 -0500 (EST)
Received: by above.proper.com (8.9.3/8.9.3) id IAA25797
	for ipsec-policy-bks; Fri, 23 Feb 2001 08:08:11 -0800 (PST)
Received: from rumor.cps.intel.com (rumor.cps.intel.com [192.102.198.242])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA25792
	for <ipsec-policy@vpnc.org>; Fri, 23 Feb 2001 08:08:09 -0800 (PST)
Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204])
	by rumor.cps.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.35 2001/02/12 09:03:45 smothers Exp $) with SMTP id QAA24110;
	Fri, 23 Feb 2001 16:07:34 GMT
Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.204
  (Norton AntiVirus for Internet Email Gateways 1.0) ;
  Fri, 23 Feb 2001 16:07:37 0000 (GMT)
Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21)
	id <17DPCH5Q>; Fri, 23 Feb 2001 08:07:36 -0800
Message-ID: <794826DE8867D411BAB8009027AE9EB904DD7ACF@FMSMSX38>
From: "Jason, Jamie" <jamie.jason@intel.com>
To: "'Ricky Charlet'" <rcharlet@redcreek.com>,
        ".ipsec-policy"
	 <ipsec-policy@vpnc.org>
Subject: RE: Information Model question.
Date: Fri, 23 Feb 2001 08:07:31 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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>

Ricky,

thanks for the reminder.  While updating the draft, I have been racking my
brain because I knew there was something I was going to add to the model.
We had it in the original model and then took it out, assuming that it would
be left up to the implementation to use a global setting as to whether or
not to do anti-replay detection.  However, we found that in some instances,
it is nice to be able to control this on a flow-by-flow basis.

Jamie

> -----Original Message-----
> From: Ricky Charlet [mailto:rcharlet@redcreek.com]
> Sent: Thursday, February 22, 2001 6:25 PM
> To: .ipsec-policy
> Subject: Information Model question.
> 
> 
> Howdy,
> 
> 	I can't seem to find AntiReplay properties in the DMTF 
> IPsec Policy
> Model. I would expect them in the AHTransform and ESPTransform. Am I
> just looking in the wrong place?
> 
> 
> -- 
>   Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903
> 



From owner-ipsec-policy@mail.vpnc.org  Mon Feb 26 17:50:04 2001
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02241
	for <ipsp-archive@odin.ietf.org>; Mon, 26 Feb 2001 17:50:02 -0500 (EST)
Received: (from majordomo@localhost)
	by above.proper.com (8.9.3/8.9.3) id NAA07496
	for ipsec-policy-bks; Mon, 26 Feb 2001 13:29:47 -0800 (PST)
Received: from cisco.com (brussels.cisco.com [144.254.15.68])
	by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA07492
	for <ipsec-policy@vpnc.org>; Mon, 26 Feb 2001 13:29:45 -0800 (PST)
Received: from EVYNCKE-W2K.cisco.com (evyncke-isdn-home.cisco.com [10.49.1.170])
	by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id WAA24058;
	Mon, 26 Feb 2001 22:29:12 +0100 (MET)
Message-Id: <4.3.2.7.2.20010226095422.019a9568@brussels.cisco.com>
X-Sender: evyncke@brussels.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 26 Feb 2001 09:56:25 +0100
To: "Wang, Cliff" <CWang@smartpipes.com>
From: Eric Vyncke <evyncke@cisco.com>
Subject: RE: Question on IKERejectAction in IPsec information model 
Cc: "'Jason, Jamie'" <jamie.jason@intel.com>, ipsec-policy@vpnc.org
In-Reply-To: <8E1E94178828D143B34A560A7A6F2C0B0199ACC8@mailmaestro.smart
 pipes.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>

Cliff,

Sorry for late reply, comments in-line:

At 14:48 21/02/2001 +0000, Wang, Cliff wrote:
>So any rule with IKERejectAction is to stop negotiation
>by dropping the packets? Or I have to pass a message
>to the IKE engine to drop the request and let the packet
>pass the filter?

The goal is to prevent IKE to start a negotiation as responder,
the way you implement it is probably local matter.

>Would it be simpler just to have a drop rule to stop
>the IKE packets?

No, because we would also like to reject connections from some IKE
by using their identity (obviously only applies to aggressive mode).

I hope that this does make sense ;-)

-eric


>If the filter is of type IKE identity, then there are
>a couple of issues:
>1) The main mode identity won't come in until 5th
>message. At that time, you have done D-H exchange.
>If the purpose of this filter is to prevent
>denial-of-service, the adversary has just defeated that.
>2) The filter code itself has no IKE protocol
>intelligence. That means the IKE engine has to
>lookup up the filter again after receiving
>the ID payload. This requirement is not RFC 2409
>specified.
>
>I would suggest that to stop peer IKE negotiation,
>just set up a simple drop rule with that peer
>on UDP port 500.
>
>-----Original Message-----
>From: Jason, Jamie [mailto:jamie.jason@intel.com]
>Sent: Tuesday, February 20, 2001 8:19 PM
>To: 'Eric Vyncke'; 'Wang, Cliff'; ipsec-policy@vpnc.org
>Subject: RE: Question on IKERejectAction in IPsec information model
>
>
>That is what I was thinking as we already have a mechanism in place (via the
>static actions bypass/discard) for noting that we don't wish to do any IKE
>for certain types of packets.
>
>Jamie
>
> > -----Original Message-----
> > From: Eric Vyncke [mailto:evyncke@cisco.com]
> > Sent: Tuesday, February 20, 2001 4:54 PM
> > To: Jason, Jamie; 'Wang, Cliff'; ipsec-policy@vpnc.org
> > Subject: RE: Question on IKERejectAction in IPsec information model
> >
> >
> > Jamie,
> >
> > As far as I can remember, this action was mainly to reject an IKE
> > session from specific peers. I.e. actually denying a remote peer
> > to send IKE packet to us. The filter could be on IP addresses or
> > IKE identity (in the case of aggressive mode).
> >
> > Hence, if I am not mistaken, the description is wrong and should
> > be fixed.
> >
> > Cliff,
> >
> > this action should only be applied for inbound filters for
> > UDP/500 or from some IKE identities.
> >
> > -eric
> >
> > At 09:12 20/02/01 -0800, Jason, Jamie wrote:
> > >Cliff,
> > >
> > >let me look into this and see if the DMTF model/whitepaper
> > sheds any light
> > >on it.  Upon re-reading the section, it seems to be vague
> > and at a minimum
> > >should probably discuss the different scenarios when that
> > particular action
> > >may be triggered (i.e., data packet sent/arrived with no SA,
> > IKE packet
> > >arrives, etc.).
> > >
> > >Jamie
> > >
> > >> -----Original Message-----
> > >> From: Wang, Cliff [mailto:CWang@smartpipes.com]
> > >> Sent: Monday, February 19, 2001 11:11 AM
> > >> To: ipsec-policy@vpnc.org
> > >> Subject: Question on IKERejectAction in IPsec information model
> > >>
> > >>
> > >> In the information mode:
> > >>
> > >> 6.5. The Class IKERejectAction
> > >>
> > >>    The class IKERejectAction is used to prevent attempting an IKE
> > >>    negotiation with the peer(s).  The class definition for
> > >>    IKERejectAction is as follows:
> > >>
> > >>    NAME         IKERejectAction
> > >>    DESCRIPTION  Specifies that an IKE negotiation should
> > not even be
> > >>                 attempted.
> > >>    DERIVED FROM SAStaticAction
> > >>    ABSTRACT     FALSE
> > >>    PROPERTIES   DoLogging
> > >>
> > >>
> > >> What is the action on the packet, discard/drop/use static
> > SA? It only
> > >> specifies no IKE negotiation.
> > >>
> >
> > Eric Vyncke
> > Distinguished Engineer             Cisco Systems EMEA
> > Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
> > E-mail: evyncke@cisco.com          Mobile: +32-475-312.458 (CHANGED)
> > PGP fingerprint: D35F BEF9 643F 656F 90F5  76C5 9CA1 C289 D398 B141
> >
> >

Eric Vyncke
Distinguished Engineer             Cisco Systems EMEA
Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
E-mail: evyncke@cisco.com          Mobile: +32-475-312.458 (CHANGED)
PGP fingerprint: D35F BEF9 643F 656F 90F5  76C5 9CA1 C289 D398 B141