RE: IKEv2:limitation of 4k for UDP payload

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

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-----
From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On
Behalf Of Ravi

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:

>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>http://www.s
andelman.ottawa.on.ca/ipsec/1999/05/msg00014.html
>
>vinay
>
>

--


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