Subject: IKEv2:limitation of 4k for UDP payload

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

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

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

---

From: Vinay K Nallamothu <[email-masked]>
Date: 27 Mar 2003 11:36:37 +0530

On Wed, 2003-03-26 at 19:12, Ravi wrote:
> and why UDP is chosen for IKE over TCP.
Just rewording one of the earlier discussion:

One of the design requirements is transport protocol independence
because of which IKE can not assume about the reliable streaming
capabilities of the transport layer such as TCP. This seems to be the
reason why UDP was chosen over TCP.

But this does not stop from implementing IKE over TCP. In fact few
implementations already do this. For e.g: Check Point FW-1 NG FP3

You can find the original discussion at
http://www.sandelman.ottawa.on.ca/ipsec/1999/05/msg00014.html

vinay

---

From: "Yoav Nir" <[email-masked]>
Date: Thu, 27 Mar 2003 09:58:28 +0200

That Check Point implements it is nice, if you have a Check Point client.
This does not add interoperability, which is the main concern of the IKE
document.

I don't think we can standardize of TCP as a MUST requirement, because many
TCP stacks are vulnerable to DoS attacks.  It would be nice, though, to have
an optional IKE over TCP.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Vinay K Nallamothu
Sent: Thursday, March 27, 2003 8:07 AM
To: Ravi
Cc: [email-masked]
Subject: Re: IKEv2:limitation of 4k for UDP payload

vinay

---

From: "Yoav Nir" <[email-masked]>
Date: Thu, 27 Mar 2003 10:42:02 +0200

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: [email-masked] [mailto:[email-masked]]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

--

----------

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

---

From: Ravi <[email-masked]>
Date: Thu, 27 Mar 2003 15:09:50 +0530

You are right that, unless some text is present either as SHOULD or MUST and
clarification text indicating how TCP can be used, then there would be interoperable
problems.
Since, it is not well defined, I am going ahead with IKEv2 implementation using UDP.
       Thank you for your answers.

--

---

From: Ravi <[email-masked]>
Date: Thu, 27 Mar 2003 15:05:55 +0530

Thank for your response. If the checkpoint also works on TCP, how does it
interoperate. How does the peer know whether it can use TCP or UDP?
Since, there is no protocol support, I presume that initiator knows that peer
support TCP based IKE via out-of-band way.
 
If TCP is used
        A. Is it assumed that each transaction happens in one single TCP session
             i.e command and response happen in one TCP session. This is required
             as there could be NAT devices in between.
        B. More transactions can happen in one single TCP session.
        C.  Notify messages are two types. One type is in response to some message
             and other is sent in unsolicited way.
             In case of first type, it needs to use same TCP session. In second case,
             it  can send by creating new TCP session.

     Is there any work going on defining OR clarifying how TCP can be used with
     IKE? 

     Thanks in advance.
      Ravi

--

---

From: "Yoav Nir" <[email-masked]>
Date: Thu, 27 Mar 2003 16:31:56 +0200

The obvious was to encode it is to just send the packets the same way,
except encapsulated in a TCP connection to port 500 instead of UDP.  It
requires no other change.  Since I don't think we're planning to also have
TCP encapsulation of IPsec, there's no real need for prepending four clear
octets.

-----Original Message-----

Thank for your response. If the checkpoint also works on TCP, how does it
interoperate. How does the peer know whether it can use TCP or UDP?
Since, there is no protocol support, I presume that initiator knows that
peer
support TCP based IKE via out-of-band way.

If TCP is used
        A. Is it assumed that each transaction happens in one single TCP
session
             i.e command and response happen in one TCP session. This is
required
             as there could be NAT devices in between.
        B. More transactions can happen in one single TCP session.
        C.  Notify messages are two types. One type is in response to some
message
             and other is sent in unsolicited way.
             In case of first type, it needs to use same TCP session. In
second case,
             it  can send by creating new TCP session.

     Is there any work going on defining OR clarifying how TCP can be used
with
     IKE?

     Thanks in advance.
      Ravi

Vinay K Nallamothu wrote:

><http://www.sandelman.ottawa.on.ca/ipsec/1999/05/msg00014.html>http://www.s
andelman.ottawa.on.ca/ipsec/1999/05/msg00014.html

--

----------
Ravi Kumar CH