While I agree with you in general, I think that IKE has its own peculiarity,
that makes things a bit different.
There is a difference between IPv6 and IPv4. In IPv6 one can assume,
that packets below 1280 bytes will not be fragmented en route. This leaves
enough room
to make IKE level fragmentation and be sure, that no IP fragmentation will take
place.
With IPv4 any IP packet greater 68 bytes is fragmentable. Due to IKE message
construction restrictions you cannot make IKE fragments that small,
so you always have a possibility, that packets will still be fragmented by IP
level.
If you send them with DF=1 and intermediate device still wants to fragment them,
then you will just prevent IKE to succeed with 100% probability. If in this
case DF=0,
then it might work.
If, as you suggest, originating host performs IP fragmentation and sends IP
fragments
with DF=1, then we have exactly the problem the draft is intended to solve -
the presence of IP fragments on the whole path. Draft introduces IKE-level
fragmentation
to avoid IP fragmentation whenever possible and to only let it be if it is
impossible. But if it
is unavoidable, then there are more chances for IKE to work if IP fragments
exist
only on the part of the path, i.e. when fragmentation is done by intermediate
device.
----- Original Message -----
From: Matt Mathis
To: Valery Smyslov
Cc: tsvwg ; tsv-...@tools.ietf.org ; ipsec@ietf.org ;
draft-ietf-ipsecme-ikev2-fragmentat...@tools.ietf.org ; tsv-...@ietf.org ; Joe
Touch
Sent: Tuesday, October 29, 2013 2:22 AM
Subject: Re: [tsvwg] [IPsec] TSVDIR-ish
reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04
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 <sva...@gmail.com> 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
To: Valery Smyslov
Cc: tsvwg ; tsv-...@tools.ietf.org ; ipsec@ietf.org ;
draft-ietf-ipsecme-ikev2-fragmentat...@tools.ietf.org ; tsv-...@ietf.org ; Joe
Touch
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 <to...@isi.edu> 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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
