That's true. I don't see any requirements in section 10.4. that the
probes
must be distinct. Request/reply nature of IKE's messages make them
well suitable for probes and I see no need here to introduce
separate mechanism, adding complexity, consuming bandwith and adding
delay.
Moreover, section 10.4 explicitely allows using application data for
probes.
Yes, but there are two components:
- the probes
- the timeouts
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.
When doing PMTU discovery host needs to try several MTU sizes
before considering peer to be dead, so exchange timeout must be
greater then the sum of all probes timeouts. Probe timeout should
be relatively short, just less then 10 seconds before going to next size,
while the whole exchange timeout is pretty long, about one minute or more.
From Section 9: You don't talk about trying to make sure that IPv4 DF
is set, as per Section 9, which means that even the conservative
values you pick might continue to generate fragments downstream.
With all due respect, I have to disagree that setting DF bit is needed
in case of IKE.
With IKE the goal is not to make sure that _no_ IP fragmentation takes
place
on the path, but to make sure that IP fragmentation issues, if any,
do not prevent IKE communications. So, IP fragmentation is present on
the path,
but it doesn't bother us - let it be.
Agreed. But that's the case when IKE works with whatever message size you
start with.
If it doesn't allow IKE to work
(either by dropping IP fragments or by attacking destination host with
bogus fragments) - we will try to avoid it. So, in your example, even if
IP fragments are generated downstream, but those fragments are passed -
let them be.
Your mechanism kicks in (presumably) when IKE fails, and then you retry
with application-layer fragments. App-layer fragments are useless if the
network level then fragments the messages. That's why you should set DF=1.
Again, there's no need for IKE to absolutely disallow IP fragmentation
unless
it prevents IKE to communicate. If we have two routers down the
path, first fragmenting IP packets into size S1 and the second fragmenting
them into size S2, so that S2 < S1, and some device between them
that drops IP fragments, then it is enough for IKE to make so that
application fragments will have size < S1, but probably > S2.
Then we will avoid first fragmentation, but will still allow second one,
as it doesn't bother us. In this case application fragments are
useful, even with the presence of IP fragmentation.
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).
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.
that is reffered by RFC5996 as recommendations to protect against IP
fragmentation issues. Section 3.3 of this paper discusses the ways PMTUD
should be done in IKE and finds it more advantageous not to set DF bit.
That too refers to IKE without IKE-level fragmentation (see Sec 2). Again,
once you introduce fragmentation at the IKE-level to avoid IP
fragmentation, it makes no sense to continue to allow it at the IP level.
Please, see above.
Joe
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
