I guess the idea is that if the packet is still bigger than the PMTU, then the IKE host gets back a "fragmentation needed" ICMP, and the IKE daemon learns of that and resends packets with appropriately small size.
There are some issues with this: 1. It requires yet another retransmission 2. There's a lot of things on the IPv4 Internet that drop ICMP messages. IPv6 simply doesn't work without them, but IPv4 usually manages. 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#. 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. Yoav [1] http://stackoverflow.com/questions/4142080/path-mtu-discovery-in-c-sharp On Oct 28, 2013, at 7:50 AM, Valery Smyslov <[email protected]<mailto:[email protected]>> wrote: Hi Matt, the whole idea of the draft is avoiding IP fragmentation for IKE when it prevents IKE to work. What about DF bit - I don't see how setting it would help IKE to work. Regards, Valery. ----- Original Message ----- From: Matt Mathis<mailto:[email protected]> To: Valery Smyslov<mailto:[email protected]> Cc: tsvwg<mailto:[email protected]> ; [email protected]<mailto:[email protected]> ; [email protected]<mailto:[email protected]> ; [email protected]<mailto:[email protected]> ; [email protected]<mailto:[email protected]> ; Joe Touch<mailto:[email protected]> Sent: Saturday, October 26, 2013 12:41 AM Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04 I concur with Joe: once you have enough machinery work well with IPv6 fragmentation semantics, you should use it for IPv4 too, and unconditionally set DF. This probably applies to *all* protocols. IPv4 reassembly is hopelessly out of scale. IP ID wrap times are likely to be sub second for any large CGN connecting to any large service..... They might even be shorter than the queuing times. I suspect that if you re-review decade old papers on fragmentation, you will find some scale assumptions that are no longer correct. In that time the Internet has moved at least another two orders of magnitude in packet rates. Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Fri, Oct 25, 2013 at 1:18 PM, Joe Touch <[email protected]<mailto:[email protected]>> wrote: On 10/24/2013 10:45 PM, Valery Smyslov wrote: ... You're using existing IKE messages *and* existing timeouts to determine when there is a problem. A separate timer would be useful, if only to allow you to decouple fragment retransmission from IKE transaction retries. No, the timeouts are different. I should have made it more expplicit in the draft. That'd be useful. ... Always setting DF bit in this case will probably increase the delay before IKE SA is set up (as more probes will need to be done). Except that if you continue to allow IP fragmentation, you can't claim your solution is robust to IP fragment poisoning. Note, that this approach is in line with advices, given for IKE in the paper C. Kaufman, R. Perlman, and B. Sommerfeld, "DoS protection for UDP-based protocols", ACM Conference on Computer and Communications Security, October 2003. That paper doesn't consider IKE-level fragmentation, which you're introducing. I agree that DF=0 for IKE without IKE-level fragmentation. It does, in Section 3.3. Sorry - I missed that. But that section also gives good reasons why this is a bad idea in IKE too. Joe _______________________________________________ IPsec mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
