Setting DF is supposed to prevent some midpath IPv4 device from silently "fixing" a MTU problem by doing you a favor that you don't want.
IPv4 fragmentation can be used in a mode that mimics IPv6: Only fragment on the originating host, always set DF on on all outbound packets, even if they are already fragmented. Any protocol or application that does not work in this configuration will also fail on IPv6. 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 Sun, Oct 27, 2013 at 10:50 PM, Valery Smyslov <[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 <[email protected]> > *To:* Valery Smyslov <[email protected]> > *Cc:* tsvwg <[email protected]> ; [email protected] ; [email protected] ; > [email protected] ; [email protected]; Joe > Touch <[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]> 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
