Tero Kivinen <kivi...@iki.fi> 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:

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

So, the converse statement (for me) is that you think that we should
specify a way to carry ESP over TCP.

    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> On the other hand I am not sure NAT boxes do drop IPv6
    TK> fragments...  IPv6 and NAT are not used that often together.

IPv6 packets inside ESP over IPv4-ESP-UDP.
This gives your laptop ubiquitous IPv6, even when behind stupid networks.

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

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

yeah, but the concern listed in the document is that the initial
congestion window wouldn't be big enough to quickly send out the large
IKE_AUTH payload.   Having at least one RTT for the initial IKE_INIT
exchange would allow TCP to double the window, and get an estimate for
RTT.

-- 
Michael Richardson
-on the road-



Attachment: pgp4BCeUM0os4.pgp
Description: PGP signature

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to