Subject: IKEv2: prepending four octets

From: ravi <[email-masked]>
Date: Tue, 18 Mar 2003 13:41:19 +0530

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.

---

From: "Yoav Nir" <[email-masked]>
Date: Tue, 18 Mar 2003 13:55:27 +0200

Hi,

I will try to answer both your questions:

1. The next payload field of an encrypted payload is that of the first
encapsulated payload rather than zero because otherwise we would not know
how to parse the first encrypted payload.

2. 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.

Hope this helps

Yoav

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of ravi
Sent: Tuesday, March 18, 2003 10:11 AM
To: [email-masked]
Subject: IKEv2: prepending four octets

Dear All,

---

From: ravi <[email-masked]>
Date: Wed, 19 Mar 2003 10:35:24 +0530

Hi,

> You prepend four zeros to IKE messages, because no
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

---

From: Vinay K Nallamothu <[email-masked]>
Date: 19 Mar 2003 15:51:45 +0530

>       UDP header as 0s in case of IKE packet, then there is no need for port 4500
This is to avoid any IKE aware NAPT devices present in between playing
smart. These devices make use of the SPI field to uniquely identify the
source behind the NAPT.

For more details please go through  sections 9.1 to 9.3 of
draft-ietf-ipsec-ikev2-tutorial-01.txt.

Hope this helps
vinay

---

From: "Yoav Nir" <[email-masked]>
Date: Wed, 19 Mar 2003 10:10:03 +0200

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:[email-masked]]
Sent: Wednesday, March 19, 2003 7:05 AM
To: Yoav Nir
Cc: [email-masked]
Subject: Re: IKEv2: prepending four octets

Hi,

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

---

From: Ravi <[email-masked]>
Date: Thu, 20 Mar 2003 15:16:59 +0530

Hi.

Yoav Nir wrote:

>ports.

agreed

>  To overcome this problem, many NAT implementations added special
>handling to port 500:
>

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.

--Ravi

---

From: Tero Kivinen <[email-masked]>
Date: Sat, 22 Mar 2003 02:36:13 +0800

>  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. 
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: "Yoav Nir" <[email-masked]>
Date: Tue, 25 Mar 2003 09:44:47 +0200

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:[email-masked]]
Sent: Tuesday, March 25, 2003 9:43 AM
To: Tero Kivinen
Cc: [email-masked]; Yoav Nir
Subject: Re: IKEv2: prepending four octets

Hi,

Tero Kivinen wrote:

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

---

From: Ravi <[email-masked]>
Date: Tue, 25 Mar 2003 13:12:40 +0530

Hi,

>this properly and will send the notification, can get rid of the extra
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.

-- 

------------------------------------------------------------------------

ROC home page <http://www.roc.co.in>

---

From: Francis Dupont <[email-masked]>
Date: Tue, 25 Mar 2003 19:00:17 +0100

In your previous mail you wrote:

=> I agree.

   IOW an IKEv2 implementation must not assume that peers start the
   negotiations on port 500.

=> I agree.

   Coding a Remote Access client like that is
   
=> I believe we should give at least a MAY to initiate over 500 and 4500,
perhaps with a SHOULD for port 4500 if one knows there is a NAT and a SHOULD
for port 500 if one knows there is no NAT. In fact, this is more in the
scope of a BCP. About listening, I am in favor of a MUST for both 500
and 4500.

Regards

[email-masked]

---

From: Ravi <[email-masked]>
Date: Wed, 26 Mar 2003 19:25:15 +0530

Hi,

May I know why ikev2 should listen on both 500 and 4500.?What purpose does
it solve? In my view, we are complicating the protocol and implementation by doing
this. 
If both IKEv1 and IKEv2 exist (most probably they exist as separate processes
or tasks and it is easy if we let IKEv1 and V2 exist separately), ikev1 can listen
on port 500 and ikev2 listen on 4500.

On the initiating side, if it has both v1 and v2, first it can try contacting the
responder with port 4500 i.e. IKEv2. If it does not get response in certain
duration, it can assume that IKEV2 is not supported by the responder and it can
fallback onto the ikev1 which sends packets onto port 500.

Also implementation wise it makes it easy and ikev1 and ikev2 can come from
two different vendors and typically TCP/IP stacks don't allow two sockets 
listening on same port.

-- 

Rendezvous On Chip (i) Pvt Ltd