[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.