Subject: [IPsec] TSVDIR-ish review of draft-ietf-ipsecme-ikev2-fragmentation-04

From: Joe Touch <[email-masked]>
Date: Mon, 21 Oct 2013 17:06:51 -0700

Hi, all,

I've reviewed the following doc for TSVDIR:
	draft-ietf-ipsecme-ikev2-fragmentation-04

Although this is not intended as a complete TSVDIR review, I have 
checked for the typical issues.

Joe

-------------------------------------------------------------------

draft-ietf-ipsecme-ikev2-fragmentation-04
	
This doc makes the case that IKEv2 should implement its own 
frag/reassembly mechanism, because some NATs don't pass IP fragments.

First, the issue with NATs and fragments should be made more clear, 
especially citing existing descriptions of this issue, e.g., RFC4787. 
Note that NATs which do not pass fragments violate RFQ-14 of that BCP 
RFC, and it might be useful to report this issue to the vendor.

Second, it is not clear why this issue is being handled inside IKE. 
Appendix A provides a design rationale, but it clearly trades 
computation and space overhead for local storage, and still permits DOS 
attacks (e.g., overloading the receiver with false fragments).

An equally viable solution (see ** below) would involve placing a single 
signed IKE message into a single IP packet, fragmenting that packet, and 
transmitting those fragments inside UDP datagrams. This approach could 
use the innermost IP encapsulation as the reassembly layer.

**: Although this approach is susceptible to fragmentation overload, so 
too is transmitting the original message over IP that is naturally 
fragmented at the network layer anyway - this introducing no new 
vulnerability.

This IP-encapsulated IKE message would need the same negotiation 
described in section 2.3, but would avoid the complexity of most of the 
rest of the document, relying instead on existing IP reassembly.

In conclusion, I don't see the need for the level of detail and 
mechanism proscribed, basically because it reinvents the wheel, but see 
no other substantial issues with it.

Additionally, regarding PMTUD, this should be done using PLMTUD (RFC 
4821), and should be described as such.

---

---

From: Joe Touch <[email-masked]>
Date: Mon, 21 Oct 2013 17:26:47 -0700

Hi, all,

I've reviewed the following doc for TSVDIR:
      draft-amjads-ipsecme-ikev2-data-channel-00

Joe

draft-amjads-ipsecme-ikev2-data-channel-00

This doc makes the case that IKEv2 can provide a secure data channel for
arbitrary communication, rather than being used (as designed) to
configure IPsec channels for that purpose.

This mechanism lacks congestion control, and so needs to be used only 
where its load is known to be a small fraction of capacity. In specific, 
IKE's window mechanism allows for increasing the window size but not 
decreasing it, as is needed to react to network congestion.

The acknowledged data transfer mode uses IKE's window mechanism, which 
is presumably set to a small value, and may result in very low 
throughput. Attempts to increase this window size to overcome this 
limitation can easily increase burstiness and network loss.

This mechanism includes its own fragmentation mechanism based on a 
pre-configiured MTU, where it should use an adaptive size based on 
PLMTUD (RFC4821). The mechanism described replicates that of IP, and so 
introduces no new issues. Fragment reassembly appears to rely on the IKE 
sequence number, and the relationship between the two should be more 
clear, especially on the reuse of the IKE sequence number and how that 
affects reassembly timeout.

---

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 22 Oct 2013 16:50:57 +0400

Hi Joe,

thank you for your review.
Please, see my comments inline.

> Although this is not intended as a complete TSVDIR review, I have checked 
> for the typical issues.
>
> Joe
>
> especially citing existing descriptions of this issue, e.g., RFC4787. Note 
> that NATs which do not pass fragments violate RFQ-14 of that BCP RFC, and 
> it might be useful to report this issue to the vendor.
>
> Appendix A provides a design rationale, but it clearly trades computation 
> and space overhead for local storage, and still permits DOS

I don't see a strict computation/memory tradeoff here. You must
verify message validity in any case, whether it is done before
reassempling (on each fragment), or after it is complete (including
the case when you get garbage message due to false fragments).
The amount of consumped CPU power will be roughly the same.
But the amount of memory consumption will be smaller if
you are able to discard false fragments.

> attacks (e.g., overloading the receiver with false fragments).

This attack is always possible both with and without fragmentation
(just overloading with false full messages) and IKE is designed to withstand 
it.
Handling fragmentation in IKE doesn't make it more vulnerable to this 
attack.
On the other hand, handling fragmentation outside IKE (on IP level)
or using unauthenticated fragments in IKE, makes it susceptible to an 
attack,
described in the rationale, i.e. when attacker spending virtually zero 
resources
can stop IKE communication by infrequently injecting bad fragments,
which results in "poisoning" of reassembling queue. Using authenticated 
fragments
prevents this kind of attack.

> transmitting those fragments inside UDP datagrams. This approach could use 
> the innermost IP encapsulation as the reassembly layer.
>

But using IKE fragmentation in this case might eliminate this vulnerability.

> This IP-encapsulated IKE message would need the same negotiation described 
> in section 2.3, but would avoid the complexity of most of the rest of the 
> document, relying instead on existing IP reassembly.
>
> In conclusion, I don't see the need for the level of detail and mechanism 
> proscribed, basically because it reinvents the wheel, but see no other 
> substantial issues with it.
>

IMHO, PLMTUD doesn't suite well for IKE. First, IKE is UDP-based
and RFC4821 has many restrictions when used with connectionless
datagram protocols, some of which are often difficult to satisfy in 
environments,
where IKE is used. Second, the goal of PLMTUD is to find _maximum_
MTU size that is not fragmented by IP, in other words, to maximize
throughput. For IKE the goal of PMTUD is to find _any_reasonable_
MTU size that won't be fragmented by IP. Throughput is not important.
Third, PMTU discovery in the draft is completely optional and one may
use any other mechanisms (including PLMTUD, if it is available)
to obtain MTU information.

Thanks,
Valery Smyslov.

---

From: Joe Touch <[email-masked]>
Date: Tue, 22 Oct 2013 08:27:28 -0700

Hi, Valery,

> The amount of consumped CPU power will be roughly the same.

The cost to verify several individual messages is higher than the cost 
to verify a single message, especially when the individual messages are 
not exactly the blocksize of the algorithm used.

So in the case of no attack, the overhead of your proposed mechanism is 
higher. You can't drop an entire message when a single false fragment 
arrives, because there could be other valid fragments on the way. So 
either way you end up checking the same amount of data, but your 
computational overhead is higher.

> you are able to discard false fragments.

Yes, but you also need to keep some state about pending partial valid 
messages.

AFAICT, the memory difference is more likely to be negligible, but the 
processing difference high.

> (just overloading with false full messages) and IKE is designed to
> withstand it.

Avoiding fragmentation poisoning attacks is not a motivation of this 
work. If you want to make that case, you need to explain why you think 
that is a significant issue and worth the effort to fix inside IKE.

Further, this method does not necessarily avoid IP fragmentation. 
Fragments are supposed to pass through a NAT (see my previous 
reference), and when they do your mechanism wouldn't adjust the IKE size 
downward.

>> An equally viable solution (see ** below) would involve placing a
>> single signed IKE message into a single IP packet, fragmenting that
>> packet, and transmitting those fragments inside UDP datagrams. This
>> approach could use the innermost IP encapsulation as the reassembly
>> layer.
>>
>> **: Although this approach is susceptible to fragmentation overload,
>> so too is transmitting the original message over IP that is naturally

It might, but again that's not your threat model and there are other 
vulnerabilities this method opens up (e.g., replay attacks have a higher 
CPU impact).

>> described in section 2.3, but would avoid the complexity of most of
>> the rest of the document, relying instead on existing IP reassembly.
>>
>> mechanism proscribed, basically because it reinvents the wheel, but
>> see no other substantial issues with it.
>>
> where IKE is used.

You are re-inventing PLMUTD. In places where you claim RFC4821 is too 
complex - those are the places where your mechanism is deficient IMO. 
E.g., positive verification that a message gets through as a 
confirmation of when you've achieved a reasonable size.

> Second, the goal of PLMTUD is to find _maximum_

Agreed, but if that's the case, why not always send the smallest 
possible message size (68 bytes)? It's because the overhead is too high 
(additional headers, blocksize mismatch, and computational startup cost 
on each block). Further, most transports don't care about 1400 vs. 1500 
bytes; they're searching for a rough approximation of a 'large' packet, 
as are you IMO.

> to obtain MTU information.

The transport folks spent a lot of time on PLMTUD; there are a lot of 
lessons there that can and should be applied here. PLMTUD is already 
flexible enough to apply here directly. You can always reinvent the 
wheel, of course.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Tue, 22 Oct 2013 11:35:13 -0400 (EDT)

> (just overloading with false full messages) and IKE is designed to withstand 

Partially. For unfragmented IKE, the cookies/SPI mitigate this if
you give preference to IKE messages further in the processing queue.
With this draft, I'm forced to do more crypto on IKE packets before I
can decide if these need prioritization or not (with the exception of
the first packet, which cannot get fragmented anyway)

> Handling fragmentation in IKE doesn't make it more vulnerable to this attack.

Handling encrypted fragments does, because you will spend more time
doing the crypto. Although this still happens after the cookie/spi
verification. You are doing an additional round of crypto on each fragment
in addition to the regular IKE crypto you need to perform on the assembled
packet. Fragments could be made artificially long and the IKE packet
artificial big, resulting in much more crypto. Now I think this might
not matter much, because the attacker needs to be local and they will
only be local to a remote endpoint which has enough CPU, not the ipsec
core gateway that actually might run out of CPU power when under attack.

> or using unauthenticated fragments in IKE, makes it susceptible to an attack,
> which results in "poisoning" of reassembling queue.

But the attack is theoretical and of no practical value.

1) on-path attacker (remote)

They can just DOS you regardless by withholding packets.

2) off-path attacker (remote)

These attackers don't know the cookies/spi's so they can't really sent
a forged fragment you would use for assembly - protected with crypto or
not. It is also impossible for them to time their attack so that one of
their fragments intersect with one of your fragments so they would need
to start sending fragments before the endpoint does but using mostly
wrong cookies/spis and would swamp an endpoint with easilly detectable
forged packets.

3) shared medium like wifi hotspot (local)

These are the only attackers with enough knowledge to sent sufficiently
advanced bad fragments interfering with incoming fragments. They can
already do all the damage they want without resorting to IKE fragment
spoofing.  They can arp spoof the gateway, sent a Wifi de-association
request, sent enough garbage to fill the air waves, and interfere with
the IKE in such a way that you think the remote peer does not support
fragmentation at all. So this draft protects against a local attacker
that wants to masquerade as a network failure and only prevent you from
doing IKE, hoping you will fall back to plaintext traffic. Software
could notify the user that they seem to be under attack, which IMHO
would be more valuable to the user than quiet resilience against the
attack.

> Using authenticated fragments prevents this kind of attack.

Yes, it prevents one of the low hanging fruits. Which I don't think is
worth the complexity of this draft compared to the existing
fragmentation code out in the wild.

> But using IKE fragmentation in this case might eliminate this vulnerability.

At the price of adding more complexity to IKE. With the attacker not
stopped from their goal.

>> Additionally, regarding PMTUD, this should be done using PLMTUD (RFC 4821), 
>> and should be described as such.
>

I agree. There is going to be like 2 to 4 fragments. Size does not
matter. It's better to cut down on latency/RTT by using an MTU size
that is for sure to work on the first go.

But that's also why this complexity is not worth it. Fragmentation does
only mean going from 1 IKE packet to 2-4 IKE packets. The timeframe
to mess with these are in the 5ms range. If an attacker has that
accuracy against you, you've lost already regardless. I doubt the
attacker can even pull it off on wifi.

The original IKE fragmentation is really nice and simple. Copy part of
the original IKE header, add a single payload with fragment payload
type and fragment number/max, sent fragments in a burst.

This draft looks like it is fixing a security issue, while it really
should be just about sending smaller packets as similar as possible
to the original single packet. Messing with one IKE packet versus 2-4
IKE packets is not a real problem that I think needs fixing.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 23 Oct 2013 11:14:08 +0400

Hi Paul,

> the first packet, which cannot get fragmented anyway)

The SPIs are still there and you are supposed to check them
before you will do any crypto. What is the difference?

> artificial big, resulting in much more crypto. Now I think this might

No, there is no additional round of crypto. After you has verified
and decrypted fragment you will store it in decrypted form.
After reassembly has finished you will get decrypted message.
No more crypto to apply.

> But the attack is theoretical and of no practical value.

I am not so confident.

> They can just DOS you regardless by withholding packets.

There may be cases when attacker, even on-path,
could only eavesdrop and inject packets, but not to block them.

> wrong cookies/spis and would swamp an endpoint with easilly detectable

Again, I am not so confident that it is impossible, especially for
particular implementation. Remember, that TCP ISN was also
considered impossible to predict untill we saw a successfull attack
on particular implementation of TCP.

> would be more valuable to the user than quiet resilience against the

Sorry, I don't follow your logic here. Security software should
thwart the attacks as much, as it could, and not just
notify user that he is under attack and give up. DoS attacks
are difficult to thwart and sometimes are easy to perform.
So what is the reason not to thwart one kind of them?
I agree that others are still possible, but they may have
their own drawback for attacker and why should we
give him/her more options to choose from?

> fragmentation code out in the wild.

Is it really _much_ complex if you first fragment then encrypt compared
to first encrypt then fragment?

> At the price of adding more complexity to IKE. With the attacker not

See above.

> type and fragment number/max, sent fragments in a burst.

Not much difference from the draft - just move fragmentation
before encryption.

> IKE packets is not a real problem that I think needs fixing.

It is about sending smaller packets, but doing so in a secure manner.

> Paul

Regards,
Valery.

---

From: Valery Smyslov <[email-masked]>
Date: Wed, 23 Oct 2013 10:25:56 +0400

> The cost to verify several individual messages is higher than the cost to 
> verify a single message, especially when the individual messages are not 
> exactly the blocksize of the algorithm used.

Right. That's why I wrote "_roughly_ the same". Of course there is some
overhead, not only due to blocksize, but mainly due to the inclusion of IKE 
Header
into ICV calculations for each fragment message.

> computational overhead is higher.

Yes, it is higher, but the amount of the overhead could be estimated
about 10%. If some system cannot bear this overhead, I think it is broken.

> Yes, but you also need to keep some state about pending partial valid 

Right. But only after fragment is validated.

> processing difference high.

No. In solution you have proposed (relying on IP fragmentation
inside UDP datagrams) the attacker could send you millions
of packets, all with different IP Fragmentation IDs in inner packet. As you
has no way to know which Fragmentation ID is valid (from real peer)
you will need to try to reassemble all of them, consuming
as much memory, as attacker wishes. If attacker is smart enough,
s(he) could easy make so, that all the false fragments will eventually
be reassembled by your system (into garbage), and you will also consume
the CPU power trying to validate them. In this case you will consume
roughly the same CPU power as with authenticated fragments,
but the amount of your memory consumption will be under attacker's control.

> Avoiding fragmentation poisoning attacks is not a motivation of this work. 
> If you want to make that case, you need to explain why you think that is a 
> significant issue and worth the effort to fix inside IKE.

Actually, Security Consideration Section of RFC5996 has already
stated that IP fragmentation is a significant issue for IKE:

   If the messages of IKEv2 are long enough that IP-level fragmentation
   is necessary, it is possible that attackers could prevent the
   exchange from completing by exhausting the reassembly buffers.

RFC5996 advices to avoid IP fragmentation by using Hash and URL
format for certificates. For some reasons, this is not widely supported
by implementations and is not generic solution (some systems
transfer a fair amount of data in Configuration Payloads, in which
case Hash and URL won't help).

The immediate goal of IKE Fragmentation was to deal with
devices, that block IP fragments. But the solution is all in line
with RFC5996, advicing avoid IP fragmentation whenever possible.

> Fragments are supposed to pass through a NAT (see my previous reference), 
> and when they do your mechanism wouldn't adjust the IKE size downward.

It doesn't matter. If IP fragmentation works in some environment - it is ok.
If it doesn't (either because some intermediate devices block
IP fragments or because an attacker is trying to exploit it),
then peers detect it and start using IKE Fragmentation.

> vulnerabilities this method opens up (e.g., replay attacks have a higher 

Why? Are you reffering to the fact, that with IKE Fragmentation you need to
check 4 additional bytes to detect a replay? Is it really a CPU impact?

> E.g., positive verification that a message gets through as a confirmation 
> of when you've achieved a reasonable size.

It is sufficient for IKE.

> Agreed, but if that's the case, why not always send the smallest possible 
> message size (68 bytes)? It's because the overhead is too high (additional 
> headers, blocksize mismatch, and computational startup cost on each 
> block). Further, most transports don't care about 1400 vs. 1500 bytes; 
> they're searching for a rough approximation of a 'large' packet, as are 
> you IMO.

I think, the main difference is that PLMTUD is always trying
to increase MTU size when everything works fine, while in IKE
PMTUD is supposed to decrease it only if packets don't get through.
For IKE the former is just not needed.

> flexible enough to apply here directly. You can always reinvent the wheel, 
> of course.

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.

Regards,
Valery.

---

From: Joe Touch <[email-masked]>
Date: Wed, 23 Oct 2013 10:23:23 -0700

> 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.

 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.

Finally, and this is separate from RFC4821, you don't mention the fact 
that dropping fragments is against the recommended behavior for NATs. I 
appreciate trying to get around that issue, but it's equally important 
to indicate this as a flaw of the network, rather than "just the way it is".

Joe

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 24 Oct 2013 10:42:50 +0400

Hi Joe,

thank you for your suggestions. I still have some comments.

> 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.

> 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. 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.

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 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.

> appreciate trying to get around that issue, but it's equally important to 
> indicate this as a flaw of the network, rather than "just the way it is".

That's true and I will definitely add some words about it.

> Joe

Thank you,
Valery Smyslov.

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Oct 2013 10:05:41 -0700

> Moreover, section 10.4 explicitely allows using application data for

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.

>> 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.
> 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
> 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.

>               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.

> 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

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 25 Oct 2013 09:45:48 +0400

> allow you to decouple fragment retransmission from IKE transaction 

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.

> Agreed. But that's the case when IKE works with whatever message size you 
> start with.
>

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).

> introducing. I agree that DF=0 for IKE without IKE-level fragmentation.

It does, in Section 3.3.

> That too refers to IKE without IKE-level fragmentation (see Sec 2). Again, 
> once you introduce fragmentation at the IKE-level to avoid IP 

Please, see above.

Regards,
Valery.

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 25 Oct 2013 22:35:46 +0300

Hi Paul,

Sorry for the late reply.

You seem to assume that SPIs are random. This is not mandated by IKEv2 
and in practice it is usually, but not always, the case. See 
http://www.ietf.org/mail-archive/web/ipsec/current/msg06563.html

Thanks,
	Yaron

On 2013-10-22 18:35, Paul Wouters wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 Oct 2013 13:18:59 -0700

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.

...
> 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.

>> introducing. I agree that DF=0 for IKE without IKE-level fragmentation.

Sorry - I missed that. But that section also gives good reasons why this 
is a bad idea in IKE too.

Joe

---

From: Matt Mathis <[email-masked]>
Date: Fri, 25 Oct 2013 13:41:05 -0700

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.

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 28 Oct 2013 09:41:39 +0400

> your solution is robust to IP fragment poisoning.

I think it is.

Consider the situation when IKE responder is under attack
via IP fragmentation (no matter which - poisoning attack or memory
exhausting attack). In any case responder will not be able to reply.
After some (short) timeout initiator will try to apply IKE Fragmentation.
Then, if those new messages are not fragmented on the path, they
will bypass reassembly code on responder and the attack will
be thwarted. If those messages are fragmented, even with their
smallest allowed size, then it doesn't matter whether DF bit is set or not.
If it is set, fragmenting device will drop messages, if it is not set,
than attack will not be thwarted. Nothing can be done.

Resume: setting DF bit in situation when even the smallest IKE Fragment
messages are still fragmented by IP will definitely prevent IKE to work.
Unsetting it will leave a chance (as with any DoS attack).

> is a bad idea in IKE too.

It lists some drawbacks: added complexity and lack of individual ACKs.
They were discussed by WG and found acceptable.
It suggests using TCP instead. That was considered by WG,
but rejected due to numerous issues.

Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 28 Oct 2013 09:50:42 +0400

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 ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; 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--

  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.

    That'd be useful.

    ...

    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

      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

---

From: Yoav Nir <[email-masked]>
Date: Mon, 28 Oct 2013 06:20:30 +0000

I guess the idea is that if the packet is still bigger than the PMTU, then the IKE host gets back a "fragmentation needed" ICMP, and the IKE daemon learns of that and resends packets with appropriately small size.

There are some issues with this:
 1. It requires yet another retransmission
 2. There's a lot of things on the IPv4 Internet that drop ICMP messages. IPv6 simply doesn't work without them, but IPv4 usually manages.
 3. While the TCP stack has access to these ICMP packets and the PMTU that they convey, a userspace IKE daemon usually doesn't. See [1] for how people suggest doing it in C#.

IKE is supposed to be done in two round-trips. It would be better to just pick 576 and send way too many IKE fragments then to try PMTU discovery.

Yoav

[1] http://stackoverflow.com/questions/4142080/path-mtu-discovery-in-c-sharp

On Oct 28, 2013, at 7:50 AM, Valery Smyslov <[email-masked]<mailto:[email-masked]>> wrote:

Hi Matt,

Regards,
Valery.

----- Original Message -----
From: Matt Mathis<mailto:[email-masked]>
To: Valery Smyslov<mailto:[email-masked]>
Cc: tsvwg<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> ; [email-masked]<mailto:[email-masked]> ; Joe Touch<mailto:[email-masked]>
Sent: Saturday, October 26, 2013 12:41 AM
Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04

Thanks,
--MM--

On Fri, Oct 25, 2013 at 1:18 PM, Joe Touch <[email-masked]<mailto:[email-masked]>> wrote:

That'd be useful.

...

It does, in Section 3.3.

Joe

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 28 Oct 2013 16:05:10 +0200

Yoav Nir writes:
>  3. While the TCP stack has access to these ICMP packets and the
>  PMTU that they convey, a userspace IKE daemon usually doesn't. See
>  [1] for how people suggest doing it in C#.

Actually for example our code tries to get ICMP messages for IKE
packets, mostly so that we can make timeout shorter if we start to
receive ICMP messages saying the other end is not going to responded.
If we get ICMP port unreachable for every single IKE packet we send,
there is no point of waiting for 2 minutes and 15 retranmissions to
realize that the other end is not responding, 20 seconds and 5 retries
might be better...

> IKE is supposed to be done in two round-trips. It would be better to
> just pick 576 and send way too many IKE fragments then to try PMTU
> discovery.

Yes. We are talking here about sending one 500-300 byte message from
initiator to responder, and getting about same sized message back.

After that we will only use few hundred bytes long exchanges.

Doing PMTU for sending and receiving one packet is bit overkill.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Mon, 28 Oct 2013 14:27:55 +0000

OK, you convinced me. 576 is the right value to recommend for initiator. Not sure if for responder it's also preferable to use 576, or to go with the idea in 2.5.1 of using the fragment size from the request.

Yoav

-----Original Message-----
From: Tero Kivinen [mailto:[email-masked]] 
Sent: Monday, October 28, 2013 4:05 PM
To: Yoav Nir
Cc: Valery Smyslov; tsvwg; Joe Touch; <[email-masked]>; <[email-masked]>; <[email-masked]>; Matt Mathis; <[email-masked]>
Subject: Re: [IPsec] [tsvwg] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04

Yoav Nir writes:
>  3. While the TCP stack has access to these ICMP packets and the  PMTU 
> that they convey, a userspace IKE daemon usually doesn't. See  [1] for 
> how people suggest doing it in C#.

Actually for example our code tries to get ICMP messages for IKE packets, mostly so that we can make timeout shorter if we start to receive ICMP messages saying the other end is not going to responded.
If we get ICMP port unreachable for every single IKE packet we send, there is no point of waiting for 2 minutes and 15 retranmissions to realize that the other end is not responding, 20 seconds and 5 retries might be better...

> just pick 576 and send way too many IKE fragments then to try PMTU 

Yes. We are talking here about sending one 500-300 byte message from initiator to responder, and getting about same sized message back.

Email secured by Check Point

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Oct 2013 09:21:40 -0700

On 10/27/2013 11:20 PM, Yoav Nir wrote:
> I guess the idea is that if the packet is still bigger than the PMTU,
> then the IKE host gets back a "fragmentation needed" ICMP, and the IKE
> daemon learns of that and resends packets with appropriately small size.
>

You proceed to describe how PMTUD works, but this is intended (AFAICT) 
to be more like PLMUTD - which does not rely on ICMPs.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Oct 2013 09:25:55 -0700

> than attack will not be thwarted. Nothing can be done.

You're not proposing to use the smallest size, which would be 68 bytes. 
So by not setting DF, you're enabling a fragmentation attack. If you set 
DF, a receiver could drop all fragments from addresses it wants to 
protect against IKE fragment poisoning.

Joe

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 29 Oct 2013 09:53:31 +0400

> You're not proposing to use the smallest size, which would be 68 bytes.

No, as it is not possible with this solution. Depending on algorithms 
involved
the smallest IP packet containing IKE message is about
100 bytes, and it is almost useless as in this case it  contains only
a few bytes of useful data. The minimum IP packet size still useful
would be about 256 bytes.

> DF, a receiver could drop all fragments from addresses it wants to protect 
> against IKE fragment poisoning.

Yes. But if even the smallest IKE messages are to be fragmented
by intermediate node, then setting DF bit (or dropping all IP fragments)
will just not enable IKE to succeed. By not setting it we give IKE a chance.

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 29 Oct 2013 10:27:20 +0400

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 ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; 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--

  On Sun, Oct 27, 2013 at 10:50 PM, Valery Smyslov <[email-masked]> wrote:

    Hi Matt,

    Regards,
    Valery.

      ----- Original Message ----- 
      From: Matt Mathis 
      To: Valery Smyslov 
      Cc: tsvwg ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; Joe Touch 
      Sent: Saturday, October 26, 2013 12:41 AM
      Subject: Re: [tsvwg] [IPsec] TSVDIR-ish reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04

      Thanks,
      --MM--

        That'd be useful.

        ...

          It does, in Section 3.3.

        Joe

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 29 Oct 2013 16:03:10 +0200

Valery Smyslov writes:
> Draft introduces IKE-level fragmentation to avoid IP fragmentation
> whenever possible and to only let it be if it is impossible.

Actually the first preference is to use IP fragmentation, and if that
works, it is what we use, and we do not try IKE fragmentation at all.
Only if the large packets do not go through then we try to enable IKE
fragmentation and so on...

So all of this draft is used only if there is some device on the path
that will drop at least some fragments somewhere. And yes, we might
miscategorize some network errors as IP fragments getting lost, as we
have no indication from the network whether the packet was lost
because it got fragmented on the IP level, or for some reasons. There
is no way IKEv2 could even get that information, so we assume that if
multiple full size retransmission of IKEv2 packets are lost, then
there might be fragmentation issue, and we enable IKE fragmentation.

> 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.

Yep.
-- 
[email-masked]

---

From: Matt Mathis <[email-masked]>
Date: Mon, 28 Oct 2013 15:22:29 -0700

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--

On Sun, Oct 27, 2013 at 10:50 PM, Valery Smyslov <[email-masked]> wrote:

> **
> *From:* Matt Mathis <[email-masked]>
> *To:* Valery Smyslov <[email-masked]>
> *Cc:* tsvwg <[email-masked]> ; [email-masked] ; [email-masked] ;
> [email-masked] ; [email-masked]; Joe
> Touch <[email-masked]>
> *Sent:* Saturday, October 26, 2013 12:41 AM
> *Subject:* Re: [tsvwg] [IPsec] TSVDIR-ish
> reviewofdraft-ietf-ipsecme-ikev2-fragmentation-04
>
> 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.
>