On 10/23/2013 11:42 PM, Valery Smyslov wrote:
Hi Joe,
thank you for your suggestions. I still have some comments.
On 10/22/2013 11:25 PM, Valery Smyslov wrote:
I appreciate the work transport folks has done. I will also appreciate
if you point out what exact lessons should be applied here and why.
And you may consider PMTUD in IKE as simplified PLMTUD,
implemented according with Section 10.4 of RFC4821.
From the second sentence of that section: Because you never generate
distinct probes, finding out when the MTU fails is tied to timeouts in
your message exchange system, rather than being decoupled.
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.
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.
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.
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.
Joe
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
