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

[Michael Richardson <[e-mail]>]

Tero Kivinen <[e-mail]> wrote:
    TK> ----------------------------------------------------------------------
    TK> Specifically, the messages of the IKE_AUTH exchange can become
    TK> quite large, as they may contain a chain of certificates, an
    TK> "Auth" payload (that may contain a public key signature), CRLs,
    TK> and some configuration information that is carried in the CFG
    TK> payload.
    TK> ----------------------------------------------------------------------

    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:

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

    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.

    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.   

-- 
Michael Richardson
-on the road-