RE: DMTF SAAction restriction

[Man.M.Li@xxxxxxxxx]

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@xxxxxxxxx
phone 1-781-993-3923
GSM 1-781-492-2850 

-----Original Message-----
From: ext Hilarie Orman [mailto:HORMAN@xxxxxxxxxx]
Sent: Monday, February 05, 2001 3:10 PM
To: ipsec-policy@xxxxxxx; jamie.jason@xxxxxxxxx; Man.M.Li@xxxxxxxxx
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@xxxxxxxxx> 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@xxxxxxxxx 
phone 1-781-993-3923
GSM 1-781-492-2850 

-----Original Message-----
From: ext Jason, Jamie [mailto:jamie.jason@xxxxxxxxx] 
Sent: Monday, February 05, 2001 11:01 AM
To: 'Man.M.Li@xxxxxxxxx'; ipsec-policy@xxxxxxx 
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@xxxxxxxxx [mailto:Man.M.Li@xxxxxxxxx] 
> Sent: Monday, February 05, 2001 7:16 AM
> To: ipsec-policy@xxxxxxx 
> 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@xxxxxxxxx 
> phone 1-781-993-3923
> GSM 1-781-492-2850 
>