[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKE v2 Requirements and backwards compatability
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?
I think the requirement needs to be written a bit more broadly, although
that may be the preferred way of satisfying it. Perhaps like so:
(a) An IKE1/IKE2 responder must be able to determine, from the first packet
received, which protocol the initiator wishes to use.
(b) An IKE1-only responder must reliably reject attempts to use IKE2 to it.
(c) Preferably, an IKE1/IKE2 initiator should be able to easily determine
which protocol(s) the responder can handle.
Requirement (a) doesn't necessarily mean separate ports, so long as the
packets of the two protocols are different enough. Requirement (b) means
that if a separate port is not used, the packet differences must be
obvious enough that an IKE1-only responder will reliably decide that the
packet is junk and should be discarded. Fortunately, ISAKMP includes a
version number and mandates rejecting packets with unknown versions, so
both of these are trivial to meet, if care is taken that an IKE2 packet
has its version number in exactly the same place as an IKE1 version number
(you might think this would be an obvious necessity for a multi-version
protocol, but there have been protocols which have botched it).
Requirement (c) is harder. (With multiple ports, getting an ICMP Port
Unreachable message might be felt to satisfy it... but do you trust that
message, which after all is unauthenticated?) Fortunately it's also
less critical.
Henry Spencer
henry@spsystems.net
Follow-Ups:
References: