RE: DMTF SAAction restriction

[Eric Vyncke <evyncke@xxxxxxxxx>]

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

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