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]> 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] https://www.ietf.org/mailman/listinfo/ipsec
