RE: IKEv2:limitation of 4k for UDP payload

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

Hi Ravi,

The problem with IKE over TCP is that the TCP connection is terminated at
the end of the negotiation.

If the initiator is behind a NAT device, then the responder loses the
ability to negotiate a new CHILD-SA with it, because the mapping in the NAT
device is immediately lost.  With UDP, it is possible to keep the mapping
alive by sending an occasional packet.  So, when using IKE over TCP you need
to assume one of the following:
 - no NAT, or
 - only one side initiates all negotiations

Both of these are hard to stomach.

Yoav

-----Original Message-----
From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On
Behalf Of Ravi

Hi,
I understand this was discussed several times and I could not find clear
answer. Please bear with me and I hope some body clarifies it for me.
I have some practical problem where the one of TCP/IP stacks which I am
working
with has limitation of 4K for UDP payload. I understand, when certificate
authentication is involved, IKE not only sends the certificate but also
multiple
CA certificates (if cross chaining is present). This might overshoot the 4K
limit.
We are trying to work with TCP/IP stack vendor to increase this. But I had
this doubt
and why UDP is chosen for IKE over TCP. If TCP is chosen, there is no
limitation
on the payload. It seems DNS RFC does this. It listens on both UDP and TCP
port 53.
Why can't IKEv2 also standardize both UDP and TCP port 4500?

     Thanks in advance

--


The views presented in this mail are completely mine. The company is not
responsible for whatsoever.
----------
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184

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