Avoiding tricking IKE v2 nodes into talking v1

[Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>]

In IKEv2, we were careful to specify how to safely negotiate
new versions in the future. There's a bit in v2 saying "I could be
speaking a higher version number". That way if two version 3 nodes
are attempting to talk, and an attacker (or Maxwell) throws away the
version 3 messages, and the nodes try to talk version 2 instead,
they will know they could be speaking a higher version, and try again
with version 3.

But since the IKEv1 spec didn't have any such bit, we assumed there
was nothing we could do about the possibility of two v2 nodes being
tricked into talking v1. But then I noticed the feature in SSL
that cleverly manages to have SSLv3 nodes talk SSLv2, but recognize
that they could be speaking v3, in a way that didn't require any
modifications to v2 (it's amazingly cute how they do it).

Inspired by SSL, it seems like it might be nice to find some hack
so that IKE version 2 capable nodes won't get tricked into talking IKEv1.
Currently the v2 spec says that you try to talk v2, and if you don't
get a response, you try talking v1.

The IKEv1 spec is not very explicit about things like how to handle
receipt of nonzero reserved bits (it says "must be zero",
but doesn't say "must be ignored upon receipt"). Otherwise, we could
use a reserved bit in IKEv1 similar to what we defined in IKEv2.

But given that it looks like it might be dangerous to fool with reserved
bits in v1, is there some other method that would be guaranteed not to
upset any current implementations?

One thing I could imagine is defining a dummy crypto algorithm. When
the initiator proposes that algorithm, it means "I'm sending you v1 messages
since you didn't answer my v2 messages, but I am capable of speaking
v2". If Bob speaks v2 and gets an IKE_SA_init from Alice with that
dummy crypto algorithm, I'd suggest that Bob should choose that dummy
crypto algorithm, which tells Alice "let's start over with v2". Alice
then should abort the v1 IKE, and start up again with a v2 IKE.

What do people think? Is there a more elegant way of doing this?
Is it not worth the work?

Also, while I'm asking...would any IKEv1 implementations crash or
do something possibly even worse if they receive an version 2 IKE_SA_init?
I assume they either reject or ignore such messages, because otherwise
it would be a trivial denial of service attack on IKEv1.

Radia