[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: divergent interpretations of IKE/IPsec - interop issues
Joern,
--- Joern Sierwald <joern@f-secure.com> wrote:
> >(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...)
>
> 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.
This is one of the things that should go into any documents
clarifying how to implement IKEv1, and there are a lot of
other issues like this, such as:
- the order of ESP & AH in the proposal (and are you
allowed to reverse it in a response),
- don't use multiple SA payloads in QM,
- don't use commit in phase 1,
- don't send redundant id payloads in phase 2 (some
implementations choke),
- don't send ranges or masks that cover only a single address
(some implementations will not recognize them as such)
- the nonce size issue
- you can choose cookies randomly, no benefit from using a stateless
computation as indicated by the specs
- how to write retransmission code, what are the relevant parameters
(timeouts, number of attempts, etc)
- what sort of cert req / cert payloads to send
- etc.
What new implementors would need, imho, is a document that
specifies
(1) what parts of IKE you need to implement,
(2) what you definitely should not implement because it will
be a waste of your time, and
(3) the broken features that have been deployed (such as
sending AH tunnel when you mean AH transport ;-)
Best regards,
-Sami
__________________________________________________
Do You Yahoo!?
Yahoo! Movies - coverage of the 74th Academy Awards®
http://movies.yahoo.com/