Subject: DMTF SAAction restriction

From: [email-masked]
Date: Mon, 5 Feb 2001 09:16:18 -0600

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
[email-masked]
phone 1-781-993-3923
GSM 1-781-492-2850

---

From: "Hilarie Orman" <[email-masked]>
Date: Mon, 05 Feb 2001 10:29:57 -0700

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

>>> <[email-masked]> 02/05/01 08:16AM >>>
Hi,

Man Li
Nokia

---

From: [email-masked]
Date: Mon, 5 Feb 2001 12:22:36 -0600

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 

-----Original Message-----
From: ext Jason, Jamie [mailto:[email-masked]]
Sent: Monday, February 05, 2001 11:01 AM
To: [email-masked]'; [email-masked]
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: [email-masked] [mailto:[email-masked]]
> Sent: Monday, February 05, 2001 7:16 AM
> To: [email-masked]
> Subject: DMTF SAAction restriction
> 
> 
> Hi,
>

---

From: "Hilarie Orman" <[email-masked]>
Date: Mon, 05 Feb 2001 13:09:43 -0700

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

Hilarie

>>> <[email-masked]> 02/05/01 11:22AM >>>

Man Li
Nokia 

-----Original Message-----
From: ext Jason, Jamie [mailto:[email-masked]] 
Sent: Monday, February 05, 2001 11:01 AM
To: [email-masked]'; [email-masked] 
Subject: RE: DMTF SAAction restriction

Jamie

---

From: "Jason, Jamie" <[email-masked]>
Date: Tue, 6 Feb 2001 09:06:02 -0800

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

> Sent: Tuesday, February 06, 2001 8:20 AM
> To: [email-masked]; [email-masked]
> 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 
> From: ext Eric Vyncke [mailto:[email-masked]]
> Sent: Tuesday, February 06, 2001 11:17 AM
> To: [email-masked]; [email-masked]
> 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, [email-masked] 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 
> >From: ext Lee Rafalow [mailto:[email-masked]]
> >Sent: Tuesday, February 06, 2001 9:48 AM
> >To: [email-masked]
> >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: <[email-masked]>
> >To: <[email-masked]>; <[email-masked]>; 
> <[email-masked]>;
> ><[email-masked]>
> >Sent: Monday, February 05, 2001 4:14 PM
> >> 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
> >> From: ext Hilarie Orman [mailto:[email-masked]]
> >> Sent: Monday, February 05, 2001 3:10 PM
> >> To: [email-masked]; [email-masked]; [email-masked]
> >> rule? Is it a selector for the already encrypted packets 
> (hence protocol
> =
> >> 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
> Eric Vyncke                        
> Distinguished Engineer             Cisco Systems EMEA
> Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
> E-mail: [email-masked]          Mobile: +32-475-312.458
> PGP Key available on request       MOBILE HAS CHANGED ON 11th 
> November 2000
>

---

From: "Wang, Cliff" <[email-masked]>
Date: Tue, 6 Feb 2001 17:44:25 -0000

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:[email-masked]]
Sent: Tuesday, February 06, 2001 11:17 AM
To: [email-masked]; [email-masked]
Subject: RE: DMTF SAAction restriction

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, [email-masked] wrote:
>Is the "try until one succeeds" being described in any RFCs or is it only
>multiple proposals and multiple transforms for responder to choose from.
But
>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
>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
>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
>To: <[email-masked]>; <[email-masked]>; <[email-masked]>;
><[email-masked]>
>> 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

Eric Vyncke                        
Distinguished Engineer             Cisco Systems EMEA
Phone:  +32-2-778.4677             Fax:    +32-2-778.4300
E-mail: [email-masked]          Mobile: +32-475-312.458
PGP Key available on request       MOBILE HAS CHANGED ON 11th November 2000

---

From: "Jason, Jamie" <[email-masked]>
Date: Tue, 6 Feb 2001 10:50:03 -0800

> 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: Eric Vyncke <[email-masked]>
Date: Tue, 06 Feb 2001 20:30:02 +0100

>I am confused.....

Sorry for the confusion.

>why we try 3 gateways? Are you talking about redundancy? 

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

>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

Eric Vyncke