[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IBM VPN Bakeoff Issues





>> From: Tim Jenkins <tjenkins@TimeStep.com>
>> 
>> In response to some of the list of issues and questions raised at the IBM
>> VPN interoperability workshop:
>> 
>> > 9. Should the order of protocols dictate the order of security
>> > association or should AH, ESP, IPComp always be processed in a
>> > certain order?  Most vendors agreed with the latter
>> 
>> If we consider that a fixed order is assumed, and that we will never
support
>> ESP and ESP, there are only 4 kinds of bundles possible: IPCOMP+ESP,
>> IPCOMP+AH, ESP+AH, and IPCOMP+ESP+AH.
>
>Looking at this from the pont of view of implemenor of a basic IPSEC +
>PFKEY in the kernel, I am perhaps a bit confused again: my
>understanding of the IPSEC architecture was
>
> for outgoing
>	from policy selector -> SA bundle (list of SA's), apply them
>	in whatever order the bundle lists.
>
> for incoming,
>	apply SA's from the packet, remember the order, and after all
>	done find the matching policy entry and check that the order
>	applied matches the order in bundle.

SW - I think there are different type of bundle here. Say a policy calls
from AH+ESP protection, then that is an 'adjacent-SA-bundle'.  Given the
definition for an SPD, the other type of bundle is an
(adjacent-SA-bundle)-bundle! In our implementation, this second type of
bundle is actually a policy-bundle.

Maybe more definition is needed:

adjacent-SA-bundle :=  AH AND/OR ESP  adjacent and all terminate at the same
host (since IPCOMP does not have an SA, as such, and is optional per packet,
I guess it doesn't need mentioning as an 'SA', but as 'option' mentioned in
the AH and/or ESP SA. These can be tunnel or transport mode.

policy-bundle (or some other name) := a combination of ajacent-SA-bundles
where two consequtive transport-mode  adjacent-SA-bundles are pointless (and
illegal?).

Steve.