Re: Avoiding tricking IKE v2 nodes into talking v1

[Jean-Jacques Puig <Jean-Jacques.Puig@int-evry.fr>]

Hi,

On Mon, Aug 26, 2002 at 10:00:38AM -0700, Dan Harkins wrote:
>   The complaint about IKEv1 is that it is too complex and hard to
> understand, not that it is insecure. So I don't see falling back
> to IKEv1 as a real problem. 
> 
>   If something really has to be done I suggest we come up with an 
> IKEv1 "vendor ID" payload that says something like "I can actually 
> speak a higher version of IKE". This payload would be sent in the 
> 5th and 6th message in Main Mode or the 2nd and 3rd in Aggressive 
> Mode. Most implementations can handle "vendor ID" payloads in these 
> parts of the exchanges.

I wonder if the use Notification Payload (ISAKMP - 3.14) with a new
Notify Message Type (some values were kept for future use) would work
also. Is this payload in use in IKEv1 ? Or is it not related to IKEv1 ?

> 
>   Regarding your question about an IKEv1 implementation that crashes 
> or worse if they receive an IKEv2 IKE_SA_init message, while the
> IKEv1 spec does not proscribe such behavior it also doesn't explicitly
> prohibit it (another area in which it is vague) but I'd argue that
> any implementation that crashed (or worse) for any reason is broken.
> There was a very popular IP stack that used to crash when it received
> the "Christmas Tree" packet (all options, lights, bells and whistles
> turned on). That wasn't a problem with IP, it was a problem with that
> implementation. Similarly with IKEv1, if it crashes upon receipt of
> unexpected input it's not a problem with the protocol it's a problem
> with the implementation.

Crashing is obviously an implementation issue. Though developers may
expect protocols designers to be explicits enough on the behavior of the
protocol or to kindly give information of a failback behavior. I think
implementing IKEv1 is a nightmare, and 'out of the norm' protocol
behaviors are here quite likely to produce unexpected results.

--
Jean-Jacques Puig