[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: IKE v2 Requirements and backwards compatability

>>>>> "Henry" == Henry Spencer <henry@spsystems.net> writes:

 Henry> On Mon, 17 Dec 2001, Scott Fanning wrote:
 >> So, whatever we do, the next protocol will have to use a different
 >> UDP port?  Should that be a requirement, or is that too protocol
 >> specific?

 Henry> I think the requirement needs to be written a bit more
 Henry> broadly, although that may be the preferred way of satisfying
 Henry> it.  Perhaps like so:

 Henry> (a) An IKE1/IKE2 responder must be able to determine, from the
 Henry> first packet received, which protocol the initiator wishes to
 Henry> use.

 Henry> (b) An IKE1-only responder must reliably reject attempts to
 Henry> use IKE2 to it.

 Henry> (c) Preferably, an IKE1/IKE2 initiator should be able to
 Henry> easily determine which protocol(s) the responder can handle.

 Henry>...
 Henry> Requirement (c) is harder.  (With multiple ports, getting an
 Henry> ICMP Port Unreachable message might be felt to satisfy
 Henry> it... but do you trust that message, which after all is
 Henry> unauthenticated?)  Fortunately it's also less critical.

I wouldn't agree that it is less critical, unless you believe that the
improvements in IKEv2 are minor enough that it doesn't matter much if
you end up using IKEv1 instead of IKEv2 "by accident".

Assuming there are good reasons why an initiator would want to use
IKEv2 if it is available, you need a good mechanism that allows you to
do both of these:

a. Perform an IKEv2 exchange without undue delay.

b. Discover that IKEv2 is not available, without undue delay, so you
can fall back to IKEv1.

The inclusion of "without undue delay" is intentional.  For example,
if IKEv2 uses a different port, timeout could be taken as evidence
that IKEv2 is not supported, but that would not satisfy "without undue
delay".  ICMP Port Unreachable might be satisfactory, but ICMP is
often tossed by firewalls.

Given that IKEv1 has a version number, and a correctly stated version
check rule, the answer is easy:  use the same port, and a higher
version number.  This does not restrict IKEv2 at all -- it can be 100%
different from IKEv1, the only detail is that the first message must
contain a value larger than 1 at the offset where IKEv1 has its
version number.

	paul
Follow-Ups: References: