Tero Kivinen <kivi...@iki.fi> 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-
pgpHB8DniUx6n.pgp
Description: PGP signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
