Re: divergent interpretations of IKE/IPsec - interop issues

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Joern" == Joern Sierwald <joern@f-secure.com> writes:

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

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

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

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

Interesting.  I thought it was the other way around (i.e., (2) is
correct) but I'm rusty.

So the consequence is that there is no way to request the following
encapsulation:
	[IP][AH][IP][ESP][encrypted IP+data]
in a single negotiation.

Yet another fine reason to let ESP do the whole job by itself... :-)

    paul