RE: IKEv2: prepending four octets

["Yoav Nir" <ynir@CheckPoint.com>]

I think that we should at least agree that a peer that only works with port
4500 such as Ravi describes should interoperate with all IKEv2
implementations.

IOW an IKEv2 implementation must not assume that peers start the
negotiations on port 500.  Coding a Remote Access client like that is
acceptable, since clients always initiate the first IKE negotiation.
Gateways may initiate the negotiation on port 4500 when working with IKEv2
peers (in fact, this could be a recommendation at the SHOULD level), but
they SHOULD also listen on port 500.

-----Original Message-----
From: Ravi [mailto:ravivsn@roc.co.in]
Sent: Tuesday, March 25, 2003 9:43 AM
To: Tero Kivinen
Cc: ipsec@lists.tislabs.com; Yoav Nir
Subject: Re: IKEv2: prepending four octets


Hi,

Tero Kivinen wrote:

ravivsn@roc.co.in (Ravi) writes:

So, we will not disturb these NAT devices to work on port 500
Since, IKEv2 is now building from scratch we shall standardise Port 4500
instead  of 500.The non Zero in first
 four bytes indicates IPsec packets and Zeros indicate IKE packets.


The problem with that is that it causes long timeout during the
transition period, i.e if initiator supports both IKEv1 and IKEv2, it
would start with IKEv2 to port 4500. The responder which only supports
IKEv1, would not even see those packets, and the initiator would have
to wait for the timeout (tens of seconds or even few minutes?) before
falling back to IKEv1 and port 500.

If the initiator starts with port 500 (with IKEv2 protocol) then the
IKEv1 implement will see the packet, and hopefully it will send back
notification INVALID-MAJOR-VERSION. There will be implementations out
there that will not send that notification back, but for those who did
this properly and will send the notification, can get rid of the extra
timeout.

I understand the reasoning. Thank you for this. But, to me it seems
unnecessary     complication. I feel, it is reasonable to wait until timeout
and standardize one port for both NAT/No-NAT traversal.


--


The views presented in this mail are completely mine. The company is not
responsible for whatsoever.


Ravi Kumar CH
Trainee Research Associate
Rendezevous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184

ROC home page