Re: Avoiding tricking IKE v2 nodes into talking v1

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Dan" == Dan Harkins <dharkins@tibernian.com> writes:

 Dan> The complaint about IKEv1 is that it is too complex and hard to
 Dan> understand, not that it is insecure. So I don't see falling back
 Dan> to IKEv1 as a real problem.

 Dan> If something really has to be done I suggest we come up with an
 Dan> IKEv1 "vendor ID" payload that says something like "I can
 Dan> actually speak a higher version of IKE". This payload would be
 Dan> sent in the 5th and 6th message in Main Mode or the 2nd and 3rd
 Dan> in Aggressive Mode. Most implementations can handle "vendor ID"
 Dan> payloads in these parts of the exchanges.

But vendor ID payloads don't announce any protocol action, they only
set a namespace for subsequent private payloads.  You can only have
one at a time, so this approach wouldn't work if someone is already
using the vendor ID payload for some other purpose.

 Dan> Regarding your question about an IKEv1 implementation that
 Dan> crashes or worse if they receive an IKEv2 IKE_SA_init message,
 Dan> while the IKEv1 spec does not proscribe such behavior it also
 Dan> doesn't explicitly prohibit it (another area in which it is
 Dan> vague) but I'd argue that any implementation that crashed (or
 Dan> worse) for any reason is broken.  

Exactly.  I don't see any reason for the IKE spec to say that.  This
rule is true for every protocol.  If you crash because of something
you received, you're broken, end of discussion.  One could put that
statement in every protocol spec but it would just be duplicating a
statement of the obvious...

	  paul