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

Re: divergent interpretations of IKE/IPsec - interop issues



At 10:43 21.03.2002 +0100, you wrote:
>Hello,
>
>During interoperability tests on several IKE/IPsec implementations, we
>discovered different interpretations of the IKEv1 or IPsec
>specification.
>
>Let's consider the following transform:
>
>(1)       [IP][data]  ==(IPsec)==>  [IP][AH][ESP][encrypted IP+data]
>
>To negociate such transform as IKE-initiator,
>(2) some implementations send a QM proposal of AH_transport + ESP_tunnel
>     (6WIND, KAME, OpenBSD...)
>(3) some other implementations send a QM proposal of AH_tunnel +
>     ESP_tunnel (FreeS/WAN, Cisco...)
>
>If initiator and responder use different interpretations, the
>negociation fails most of the time.
>These two different interpretations consequently lead to
>non-interoperable implementations.
>
>IMHO only ESP is in tunnel mode in this transform, as opposed to AH
>which is in transport mode. But some implementors seem to consider that
>mode applies globally to the transform (AH+ESP).
>
>Are (2) and (3) valid representations of transform (1) ?
>
>/christophe

The past few interops I've been to have addressed this issue over and over 
again.
The agreement was that (3) is correct.

Some software may accept type (2) proposals are well, if they are responder.
But sending type (2) QM proposals is not allowed.

The basic idea is that the attributes should be consistent over protocols.
You have the same lifetime for AH and ESP, you have the same PFS setting,
and you should have the same tunnel/transport setting.

A more interesting issue is IPCOMP. We send PFS info and lifetimes for IPCOMP
as well, just to make it consistent. Not everybody does that...

J–rn Sierwald