RE: IKEv2: prepending four octets

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

The IKEv1 RFC mandated that IKE communications be from port 500 to port 500.
It states that replies to an IKE packet go to port 500, not the source port.
Implementations that follow the RFC cannot work when a NAT changes the
ports.  To overcome this problem, many NAT implementations added special
handling to port 500: they would change only the IP address and choose peers
based on IKE cookies.  These schemes worked fairly well, but not always, and
they definitely don't allow normal NAT traversal through UDP encapsulation
(no IKE cookies)

Since these "smart" NAT devices are all over the place, we need to use a new
port that doesn't have this special handling.

-----Original Message-----
From: ravi [mailto:ravivsn@roc.co.in]
Sent: Wednesday, March 19, 2003 7:05 AM
To: Yoav Nir
Cc: ipsec@lists.tislabs.com
Subject: Re: IKEv2: prepending four octets


Hi,

> You prepend four zeros to IKE messages, because no
>IPsec-encapsulated-in-UDP message begins with four zeros.  An encapsulated
>IPSec packet begins with the SPI which is always non-zero.  Adding four
>zeros to the beginning of an IKE message makes it possible to distinguish
>IKE messages from encapsulated IPSec packets.
>
>
IKEv2 is being defined fresh. Why can't we use port 500 for the purpose of
      NAT Traversal. If we make this packet also containing first four bytes
after
      UDP header as 0s in case of IKE packet, then there is no need for port
4500

--Ravi

>Hope this helps
>
>Yoav
>
>-----Original Message-----
>From: owner-ipsec@lists.tislabs.com
>[mailto:owner-ipsec@lists.tislabs.com]On Behalf Of ravi
>Sent: Tuesday, March 18, 2003 10:11 AM
>To: ipsec@lists.tislabs.com
>Subject: IKEv2: prepending four octets
>
>
>Dear All,
>I am going through the ikev2-0.5 draft.It says
>In the IKE header when sent on UDP port 4500 ,IKE messages have
>prepended four octets of Zero.
>
>My doubt is what made to prepend four octets of Zeroes before the IKE
>message.
>Thanks in advance,
>Ravi Kumar CH.
>
>
>
>
>