Subject: [IPsec] Comments on draft-ietf-ipsecme-ikev2-fragmentation-00

From: Yaron Sheffer <[email-masked]>
Date: Fri, 26 Jul 2013 00:46:49 +0200

- The coverage of SKF is unclear to me. Specifically, does SKF sign the 
fragment number?
- The heuristic of using the received size to determine the fragment 
size to send is brittle. Why not optionally negotiate in the 
notification, by each side (optionally) adding its notion of the PMTU to 
the notification, and if two values are advertised, choosing the lower 
of them. One of the peers might be configured or might have already 
discovered the PMTU.
- Why at all add replay protection here? This adds complexity with IMHO 
no extra value.
- I suggest to add a Transport Considerations section. E.g. what if some 
fragments are lost? Timeouts? Seems to me the packet loss ratio would be 
higher than normal.

Thanks,
     Yaron

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 26 Jul 2013 10:58:13 +0400

Hi Yaron,

>- The coverage of SKF is unclear to me. Specifically, does SKF sign the 

Yes. As with SK Payload the whole message, including IKE Header,
unprotected Payloads preceeding SKF Payload (if any) and SKF Payload itself
(from the begining of Generic Header to the end of Payload content padding)
is included in ICV computation.

In description of SKF Payload the draft says:
       Other fields are identical to those specified in Section 3.14 of
       [RFC5996].

(Note, that "Other fields" includes "Integrity Checksum Data" field)

And Section 3.14 of RFC5669 says about that field:
   o  Integrity Checksum Data is the cryptographic checksum of the
      entire message starting with the Fixed IKE header through the Pad
      Length.  The checksum MUST be computed over the encrypted message.
      Its length is determined by the integrity algorithm negotiated.

If you think that this reference is insufficient, I could copy-paste
descriptions of all other fields from RFC5996.

> - The heuristic of using the received size to determine the fragment size 
> to send is brittle. Why not optionally negotiate in the notification, by 
> each side (optionally) adding its notion of the PMTU to the notification, 
> and if two values are advertised, choosing the lower of them. One of the 
> peers might be configured or might have already discovered the PMTU.

I'm in favour of minimizing manual configuration. In general, peers
will not know PMTU, but the protocol allows them to discover it.
Note, that this doesn't preclude using some preconfigured
PMTU values.

> - Why at all add replay protection here? This adds complexity with IMHO no 
> extra value.

Replay protection is the feature of IKEv2 (section 2.2). Are you suggesting
to abandon it? The draft just clarifies that in case of IKE Fragmentation
all fragments will bear the same Message ID as the original message,
that was fragmented. So, receiver in this case must not drop all incoming
fragments after the first it received, treating them as replays, but
must also look at fragment number field.

> fragments are lost? Timeouts? Seems to me the packet loss ratio would be 

OK.

Regards,
Valery.

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

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 27 Jul 2013 07:41:57 +0200

Hi Valery,

please see below.

Thanks,
	Yaron

On 2013-07-26 08:58, Valery Smyslov wrote:
> Hi Yaron,
>
>> - The coverage of SKF is unclear to me. Specifically, does SKF sign
>> the fragment number?
>

No, I would suggest to cut-and-paste. But please also add:

The cryptographic processing is identical to Sec. 3.14 of RFC 5996, as 
well as documents updating it for particular algorithms or modes, such 
as RFC 5282.

Also, in the second paragraph of 2.5, please change "as well as" to 
"similarly to the".

>> notification, by each side (optionally) adding its notion of the PMTU
>> to the notification, and if two values are advertised, choosing the
>> lower of them. One of the peers might be configured or might have
>> already discovered the PMTU.
>

I was giving an example. People might choose configuration or discovery 
to obtain the information. But your text suggests that the peers should 
somehow share the information (e.g. because only one side can perform 
discovery), and I propose to make this sharing simpler and more explicit.

>
>> - Why at all add replay protection here? This adds complexity with
>> IMHO no extra value.
>

I re-read this part of the draft and I think it is fine.

>
>> - I suggest to add a Transport Considerations section. E.g. what if
>> some fragments are lost? Timeouts? Seems to me the packet loss ratio
>> would be higher than normal.
>
> OK.
>
> Regards,
> Valery.
>
>>
>> Thanks,
>>     Yaron

---

From: "Valery Smyslov" <[email-masked]>
Date: Sat, 27 Jul 2013 21:46:54 +0400

Hi Yaron,

please find my answers inline.

> No, I would suggest to cut-and-paste.

Sorry, "would" or "would not"?

> But please also add:
> well as documents updating it for particular algorithms or modes, such as 
> RFC 5282.

OK.

> Also, in the second paragraph of 2.5, please change "as well as" to 

OK, thank you.

> I was giving an example. People might choose configuration or discovery to 
> obtain the information. But your text suggests that the peers should 

I understand your point.

But I have some doubts whether PMTU discovery (ot PMTU configuring)
is needed here at all. It is possible to just specify that all fragments
must have their sizes smaller or equal than the size, that is guaranteed
not to be gragmented by IP level. From my understanding for IPv6
this size is specified - 1280 bytes. What about IPv4 - as far as I know,
no official low limit exists, but in real life 576 byte is often considered
as this limit. If we stick to these values and get rid of any discovery
or configuring, protocol will become a bit simpler. And IKE is not
a bulk transfer protocol, so network efficiency could be suboptimal.
I'd like to know what the others think about this.

Thank you for your comments,
Valery.

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 27 Jul 2013 22:58:40 +0200

Hi Valery,

"would not". And I agree we should get additional inputs about useful 
fragment lengths.

Thanks,
	Yaron

On 2013-07-27 19:46, Valery Smyslov wrote:
>> > (from the begining of Generic Header to the end of Payload content >
>> padding)
>> I was giving an example. People might choose configuration or
>> discovery to obtain the information. But your text suggests that the
>> peers should somehow share the information (e.g. because only one side
>> can perform discovery), and I propose to make this sharing simpler and
>> more explicit.
>
> I understand your point.
>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 29 Jul 2013 19:10:29 +0200

On 07/27/2013 07:46 PM, Valery Smyslov wrote:

> or configuring, protocol will become a bit simpler. 

I would strongly prefer that over any discovery/negotiation.

It also matches IKEv1 behaviour I see in the wild

---

From: Michael Richardson <[email-masked]>
Date: Mon, 29 Jul 2013 15:56:32 -0400

Please note that fragmentation below UDP is unpopular among IPv6.
  http://www.ietf.org/proceedings/87/slides/slides-87-6man-2.pdf

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 30 Jul 2013 08:07:25 +0200

Hi Michael,

thanks for reference. IP fragmentation is exactly the thing
we are trying to avoid with this solution. So, we are in line
with IPv6 folks.

Regards,
Valery Smyslov. 

-----Original Message----- 
From: Michael Richardson 
Sent: Monday, July 29, 2013 9:56 PM 
To: [email-masked] 
Subject: Re: [IPsec] Comments on draft-ietf-ipsecme-ikev2-fragmentation-00 

[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 30 Jul 2013 08:14:27 +0200

Unless *everybody* thinks that a fixed number is the right way to go, 
there will be people doing PMTU discovery, configuration and hardcoded 
length. So again we would like both peers to advertise the value they're 
using, so that each can *choose* to use the lower value, or use the 
other peer's value.

Thanks,
	Yaron

---

From: Paul Wouters <[email-masked]>
Date: Tue, 30 Jul 2013 02:39:54 -0400 (EDT)

On Tue, 30 Jul 2013, Yaron Sheffer wrote:

> Unless *everybody* thinks that a fixed number is the right way to go, there 
> will be people doing PMTU discovery, configuration and hardcoded length. So 
> again we would like both peers to advertise the value they're using, so that 
> each can *choose* to use the lower value, or use the other peer's value.

What's the gain? At 576 bytes you will need what, 3 to 5 packets? When
negotiating an optimal mtu, you will need what? 2 packets? Does it
really matter whether you burst out 2 or 5 packets within the same ms?

Your pmtu might not be the peer's pmtu, as these are not nececssarilly
symmetric. Why take the risk?

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 30 Jul 2013 09:49:58 -0400 (EDT)

I still don't understand what the DOS protection actually accomplishes.
I think it actually makes the problem worse.

If the attacker is on-path, it can just withhold the packet. If the
attack is not on-path he either cannot see your packets, which means the
cookies/SPI numbers protect the exchange (whole packets and fragments),
or they can see your packets. So let's assume they can see your packets.

The initiator sends a packet with their cookie and the responder cookie
set to 0. The attacker responds immediately with 1000 spoofed packets
with different responder cookies. The initiator now has 1001 potentially
valid responder states. Is it going to send 1001 packets and keep track
of these? And all of this happens before fragmentation can even kick in,
because we need a valid icookie/rcookie to identify them (with or
without some authentication). If you do keep state, good. You send out
1001 ike packets (if this is 3g or wifi, it's probably going to fail)

Let's say you can actually proceed at this point. You are further into the
exchange, and now you are getting a bunch of fragments. Now the attacker
can simply sent you bogus fragments with the real icookies/rcookies and
apart from receiving this network DOS, your CPU will be under a DOS
because it has to do crypto before it can discard all these packets. Or
the attacker can use other zombies to send a motherload of fragments to
the other endpoint. As teh attacker can just start a "new" exchange,
they can keep sending your fragments to keep your CPU busy.

Now look at the very simple defacto IKEv1 fragmentation, which is basically
and IKEv1 header (with icookie/rcookie) followed by a single payload:

  *                      1                   2                   3
  *  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  * ! Next Payload  !   RESERVED    !         Payload Length        !
  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  * !          Fragment_ID          !  Fragment_num !     Flags     !
  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  * !                                                               !
  * ~                         Fragment Data                         ~
  * !                                                               !
  * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The only supported flag is "last fragment", when you received the
fragment containing that, you can try and assemble the packet.

The Fragment_ID is unneccessary (and in practice all implementations
I've seen hardcode it to 1) and we should leave it out if we specify
this for IKEv2, unless we need to support multiple exchanges in flight
for the same SA.

I'm still not convinced the extra complexity solves any real practical
problem. Could someone try to convince me again why we need to
cryptographically protect a fragment of cryptographically protected
information?

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 30 Jul 2013 17:27:17 +0300

Paul Wouters writes:
> of these? 

If implementation really wants to make sure it is protected against
DoS attacks it is allowed to do that. See section 2.4 in RFC 5996
saying:

----------------------------------------------------------------------
   There is a DoS attack on the initiator of an IKE SA that can be
   avoided if the initiator takes the proper care.  Since the first two
   messages of an SA setup are not cryptographically protected, an
   attacker could respond to the initiator's message before the genuine
   responder and poison the connection setup attempt.  To prevent this,
   the initiator MAY be willing to accept multiple responses to its
   first message, treat each as potentially legitimate, respond to it,
   and then discard all the invalid half-open connections when it
   receives a valid cryptographically protected response to any one of
   its requests.  Once a cryptographically valid response is received,
   all subsequent responses should be ignored whether or not they are
   cryptographically valid.
----------------------------------------------------------------------

Note, that this does not need cookies to protect against this attack.
Cookies protect the responder, not initiator. I assume you actually
mean SPI's not cookies in your text. 

> And all of this happens before fragmentation can even kick in,

If attacker tries hard enough he can make the connections fail. The
difference is that with non-authenticated fragmentation packets he
does not need to send 1000 packets for each packet initiator sends. He
needs to send one packet for each full message initiator sends, i.e.
if initiator fragments IKE_AUTH packet to 10 pieces each of them 500
bytes (with total of 5 kB packet), the attacker needs to send just one
40 byte packet to cause the whole 5 kB to be trashed.

If attacker is flooding packets to network at fast rate, it is easy to
find it, if the attacker sends one packet every now and then it is
much harder to detect. 

> they can keep sending your fragments to keep your CPU busy.

Again that is different attack. Sending so much packets that
destination is overloaded when decrypting the traffic is again attack
that will require so much bandwidth that it is easy to see, and it
will be costly for the attacker too.

The question here is not whether attacker can cause DoS, the question
is can we make it so that attacker has at least same cost or even
higher cost to do the attack.

This is called amplification factor, and thats why we try to design
protocols so that there is no easy way to trigger big expensive
operations with one small packet. In this case we do not want to allow
the attacker to send one small packet that will cause receiver to
discard much more data it already have.

> cryptographically protect a fragment of cryptographically protected

IKEv2 is tried to make to be much more robust against DoS attacks than
IKEv1. In IKEv1 that design might have been acceptable, but as we can
do things better and protect against that kind of attacks in IKEv2, I
suggest we do it. I do not really think it makes implementation that
much harder. It is

Encode and Encrypt and MAC packet
Split in pieces
For each piece
    Send piece out

vs

Split in pices
For each piece
    Encode and Encrypt and MAC piece
    Send piece out

On the receiving end it will be:

Receive packet
Add it to reassembly queue (including all random packets attacker sends)
If all fragments received
   Reassemble packet
   Verify MAC, decrypt and decode

vs

Recieve packet
Verify MAC, if wrong drop
If MAC verification succeeds, add to reassembly queue
If all fragments received
   Reassemble packet
   Decrypt and decode

(Decryption can also happen earlier, depending on the implementation,
i.e. the reassembly queue can actually have decrypted pieces
especially in case AEAD ciphers are used).
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 31 Jul 2013 08:38:44 +0200

Hi Paul,

actually, Tero has already answered your question and I have very little to 
add.
I just want to reemphasize, that this design doesn't protect server from
exhausting its CPU resources when attacker sends zillions of bogus 
messages -
in this case both designs are roughly equivalent. But this design protects
against more subtle attack - when attacker infrequently sends bogus
fragments. If fragments are not protected, than attacker spendind _zero_
resources can effectively prevent legal user to connect. And, as Tero
pointed out, this kind of attack is much harder to trace down.

Regards,
Valery.

-----Original Message----- 
From: Paul Wouters
Sent: Tuesday, July 30, 2013 3:49 PM
To: IPsecme WG
Subject: [IPsec] DOS protection and 
draft-ietf-ipsecme-ikev2-fragmentation-00

  *                      1                   2                   3

Paul