Re: divergent interpretations of IKE/IPsec - interop issues

[Richard Guy Briggs <rgb@conscoop.ottawa.on.ca>]

On Thu, Mar 21, 2002 at 01:31:53PM -0500, Paul Koning wrote:
> >>>>> "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.

Why would you do that unless you intentionally were nesting tunnels?

This would really infuriate those advocating transport mode only...

What you have listed *can* be done with nested tunnels because in that
case, all three IP headers could be different pairs of addresses.  This,
of course, creates a security issue because of the unauthenticated ESP
header.

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

	slainte mhath, RGB

-- 
Richard Guy Briggs           --    ~\                 Auto-Free Ottawa! Canada
<www.TriColour.net>            --    \@       @           <www.flora.org/afo/>
No Internet Wiretapping!        --   _\\/\%___\\/\%        Vote! -- <Green.ca>
<www.FreeSWAN.org>_______GTVS6#790__(*)_______(*)(*)_______<www.Marillion.com>