Re: [IPsec] Comments to draft-ietf-ipsecme-ike-tcp-00.txt

[Tero Kivinen <[e-mail]>]

Michael Richardson writes:
> Tero Kivinen <[e-mail]> wrote:
>     TK> In addition to the IKE_AUTH there is another big class of UPD
>     TK> packets which can be large, and which might get fragmented, i.e
>     TK> udp encapsulated nat traversal IPsec UDP packets. If the
> 
> I don't think you are suggesting any specific technical change to
> support this.  I think that you are saying that we need to be more clear
> that we aren't proposing anything here.  And that if TCP gets used for
> the AUTH payload, that might be a clue to the IPsec layer that it should
> do:

No, I was just pointing out that IKE_AUTH is not the only packet which
can be big packets, and UDP encapsulated packets might also have
problems bypassing the NATs dropping all fragments. 

>     TK> For tunnel mode IPsec traffic, the gateway can fragment inner
>     TK> packets before wrapping them to ESP, so the outer ESP packets
>     TK> visible to nat box are not fragmented.
> 
> which the gateway machine might not otherwise do. But, this can't be
> done for IPv6.
> (There isn't really any significant downside to doing this.  If
> anything, this moves the memory expense of fragment reassembly from
> gateways to end nodes.)

On the other hand I am not sure NAT boxes do drop IPv6 fragments...
IPv6 and NAT are not used that often together.

>     TK> which means we cannot modify the NAT_DETECTION_*_IP payloads
>     TK> when switching from UPD to TCP. This might cause NAT to be
>     TK> detected even when there is none there (i.e. the UDP source port
>     TK> is 500, but TCP source port is most likely going to be random).
> 
> The document does not tell us if we have to originate from port-500.
> I don't think that we can.

I think it says for TCP we use random port, but for UDP the IKEv2
RFC5996 says you use port 500 (but must allow source port to be other
than 500). With TCP there is problems if we try to use source and dest
port of 500 for all requests, as there might still be old connections
waiting for cleanup in the system when we start next one.

>     TK> Also I think this document should tell the justifications why
>     TK> the TCP session is not kept alive all the time, but only created
>     TK> for sending one packet and then immediately teared down. I
>     TK> assume the idea there is that open TCP session actually requires
>     TK> quite a lot of resources from the SGW, i.e. maintaining the send
>     TK> and receive windows requires tens of kilobytes of memory. Of
>     TK> course the downside of such short TCP sessions is that sending
>     TK> one exchange over TCP now requires 2 round trips of delay, and
>     TK> most likely around 10 packets, compared to the 1 round trip and
>     TK> 2 packets.  
> 
> Yes.  I think that the congestion window argument is probably not
> relevant. I don't think the congestion window will open much even if the
> first round trip goes through.   

In most systems just opening the TCP session will reserve 32 kB
buffers for sending and receiving immediately when you open tcp
connection. Earlier that was one of the parameters you needed to tune
down for web servers if you wanted to support lots of clients.
-- 
[e-mail]