OK, you convinced me. 576 is the right value to recommend for initiator. Not sure if for responder it's also preferable to use 576, or to go with the idea in 2.5.1 of using the fragment size from the request.
Yoav -----Original Message----- From: Tero Kivinen [mailto:kivi...@iki.fi] Sent: Monday, October 28, 2013 4:05 PM To: Yoav Nir Cc: Valery Smyslov; tsvwg; Joe Touch; <tsv-...@tools.ietf.org>; <ipsec@ietf.org>; <draft-ietf-ipsecme-ikev2-fragmentat...@tools.ietf.org>; Matt Mathis; <tsv-...@ietf.org> Subject: Re: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 Yoav Nir writes: > 3. While the TCP stack has access to these ICMP packets and the PMTU > that they convey, a userspace IKE daemon usually doesn't. See [1] for > how people suggest doing it in C#. Actually for example our code tries to get ICMP messages for IKE packets, mostly so that we can make timeout shorter if we start to receive ICMP messages saying the other end is not going to responded. If we get ICMP port unreachable for every single IKE packet we send, there is no point of waiting for 2 minutes and 15 retranmissions to realize that the other end is not responding, 20 seconds and 5 retries might be better... > IKE is supposed to be done in two round-trips. It would be better to > just pick 576 and send way too many IKE fragments then to try PMTU > discovery. Yes. We are talking here about sending one 500-300 byte message from initiator to responder, and getting about same sized message back. After that we will only use few hundred bytes long exchanges. Doing PMTU for sending and receiving one packet is bit overkill. -- kivi...@iki.fi Email secured by Check Point _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
