Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt

From: [email-masked]
Date: Fri, 04 Oct 2013 05:35:52 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.

	Title           : IKEv2 Fragmentation
	Author(s)       : Valery Smyslov
	Filename        : draft-ietf-ipsecme-ikev2-fragmentation-03.txt
	Pages           : 20
	Date            : 2013-10-04

Abstract:
   This document describes the way to avoid IP fragmentation of large
   IKEv2 messages.  This allows IKEv2 messages to traverse network
   devices that don't allow IP fragments to pass through.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-fragmentation

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-fragmentation-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-fragmentation-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 4 Oct 2013 16:56:44 +0400

Hi all,

I've just posted new version of IKEv2 Fragmentation draft.
Comparing with -02 version it clarifies Initiator's behaviour
with regard to retransmissions.

Regards,
Valery Smyslov.

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, October 04, 2013 4:35 PM
Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-03.txt

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

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 04 Oct 2013 16:47:04 +0300

Hi Valery,

thanks for the update. A question about some text that's not new to -03:

Quoting from Sec. 2:

If Responder receives IKE Fragment Message after it received, 
successfully verified and processed regular message with the same 
Message ID, it means that response message didn't reach Initiator and it 
activated IKE Fragmentation.  If Fragment Number in Encrypted Fragment 
Payload in this message is equal to 1, Responder MUST fragment its 
response and retransmit it back to Initiator in fragmented form.

I think the MUST in the second sentence is incorrect. Assume the sender 
switched to fragmented form, but the responder knows that it sent a very 
short response. The response got lost, but this is unrelated to 
fragmentation. So the responder should simply retransmit it as-is, and 
there's no reason to fragment it.

Also I'm not happy with the first part of the new text (last paragraph 
of Sec. 2), which adds complexity for both sender and responder. The 
sender must ensure that when it re-fragments the message, the fragment 
count is indeed higher (so it cannot use a simple table of possible 
fragment sizes). And the receiver must add the number of fragments into 
its IKE-level retransmit logic. I understand why this might be needed 
sometimes, but is the added flexibility (allowing to retry different 
fragment sizes) worth the complexity?

Thanks,
     Yaron

On 4.10.2013 15:56, Valery Smyslov wrote:
> ----- Original Message ----- From: <[email-masked]>
> Subject: [IPsec] I-D Action: 
> draft-ietf-ipsecme-ikev2-fragmentation-03.txt
>
>
>>

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 4 Oct 2013 18:59:30 +0400

Hi Yaron,

> If Responder receives IKE Fragment Message after it received, successfully 
> verified and processed regular message with the same Message ID, it means 
> that response message didn't reach Initiator and it activated IKE 
> Fragmentation.  If Fragment Number in Encrypted Fragment Payload in this 
> message is equal to 1, Responder MUST fragment its response and retransmit 
> it back to Initiator in fragmented form.
>

The idea is that it is Initiator who decides whether to use fragmentation or 
not,
as only he/she is responsible for retransmissions. Responder is just a 
"slave".
And for simplicity we assume that either both use fragmentation or both 
don't.
It is stated in the beginning of Page 5: "Responder MUST send response 
message
in the same form (fragmented or not) as corresponded request message."
You are right that it may lead (and actually leads) to "false positive"
decisions to use fragmentation in situations when it actually can't help.

We may change this logic as follows:

    Responder MUST fragment its response if it is greater than
    Responder's fragmentation threshold and SHOULD NOT do it otherwise.

Is it OK? In this case the requirement for Responder to use the same
form should also be changed to SHOULD (or removed completely).

> Also I'm not happy with the first part of the new text (last paragraph of 
> Sec. 2), which adds complexity for both sender and responder. The sender 
> must ensure that when it re-fragments the message, the fragment count is 
> indeed higher (so it cannot use a simple table of possible fragment 
> sizes). And the receiver must add the number of fragments into its 
> IKE-level retransmit logic. I understand why this might be needed 

That is the question. This is only for PMTU discovery. Still waiting for WG 
members
to discuss whether it is needed. And anyway all this functionality is marked 
as MAY.

"MUST" for ensuring that fragments number is increased after
refragmenting is just for fo desire "to be on the safe side" - in real life
it will almost always be increased as IKE PMTU discovery is coarse-grained:
if you decrease fragment size in half you will get twice as many fragments.
And there's no need for IKE to perform fine-grained PMTU discovery, if any.

What about the need for responder to take fragments number
into consideration, - I don't think it will complicate implementation,
just one more field to compare.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 4 Oct 2013 11:57:01 -0400 (EDT)

> form should also be changed to SHOULD (or removed completely).

I still think that's not right. A responder might know that it is
connected to a network with mtu issues. It should be able to skip the
failure of the first response packet not making it by starting out with
fragmenting (in ikev1 terms that would be ike_frag=force).

I think either end should be able to start fragmentation. Once an
endpoint receives a full fragmented packet correctly, it should also
send back using fragments.

The goal is to reduce latency and retransmissions. On mobile devices
with an "always on" VPN, that is really important. (i.e. my iphone is
failing at that terribly, but for other reasons)

>> indeed higher (so it cannot use a simple table of possible fragment sizes). 
>> And the receiver must add the number of fragments into its IKE-level 
>> retransmit logic. I understand why this might be needed sometimes, but is 
>> the added flexibility (allowing to retry different fragment sizes) worth 
>> the complexity?
>

I already think authenticated fragments is adding a lot of
logic. Let's not add more. Optimising on size is pointless, just
fragment near the minimum packet size. It's going to add what? 1 more
fragment?

> just one more field to compare.

The word "number" and "id" is confusing in the IKEv1 version. I'm not
sure what you are referring to here (I have to re-read the entire draft
to give feedback before vancouver)

The IKEv1 fragment id is never used. All real world implementations
always set it to 1 AFAIK. A peer never really has more then one
fragmented IKE packet outstanding with a peer. Perhaps that is different
in v2?

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 4 Oct 2013 21:53:22 +0400

Hi Paul,

> > The idea is that it is Initiator who decides whether to use 
> > fragmentation or not,

While I agree with you that ability to start using fragmentation by 
responder
without waiting for fragmented message from initiator is useful
in some situations, I still think that in general it is initiator who should
turn this option on. In most situations peers will first try to send
unfragmented message in hope that it will pass. In this case
it is not reliable to rely on responder's logic when to turn
fragmentation on, as responder may only respond to retransmitting
messages and it doesn't know how many retries initiator will do.
So it may decide to fragment message too late. The only exception -
the situation you described, when responder always sends messages
fragmented. I think we may add this exception to responder's logic.

> > That is the question. This is only for PMTU discovery. Still waiting for 
> > WG members
> > to discuss whether it is needed. And anyway all this functionality is 
> > marked as MAY.
>

I also think that PMTU discovery isn't very useful for IKE.
That's why it is MAY. I just don't like hardcoded values for message size,
especially 576 bytes, as I couldn't find in the RFCs that
IP datagrams of this size will pass anywhere. So, in my mind,  we don't have
safe low limit for IPv4. That's why I leave a small backdoor -
PMTU discovery, that is not limited to any predefined value.

> fragmented IKE packet outstanding with a peer. Perhaps that is different

There is no field "id" in IKEv2 Fragmentation Payload - just Fragment Number
and Total Fragments. But Total Fragments field plays a dual role if
peer uses PMTU discovery - i.e. tries several fragment sizes.
In this case Total Fragments allows to distinguish between fragments from
different sets (assuming that trying smaller fragment size results in
increasing number of fragments).

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 8 Oct 2013 10:51:56 -0400 (EDT)

> fragmented. I think we may add this exception to responder's logic.

Okay.

> That's why it is MAY.

That does not help implementors who still have to implement the MAY's.
if even you as a document author does not think it is veru usefil,
then I think it should just not be in the document.

> I just don't like hardcoded values for message size,

But the hardcoded value does not need to be set in stone for everyone.
It can be a value of "at least X and at most Y", and then left to
implementors and operational experience.

> increasing number of fragments).

All the more reasons not to have PMTU dicovery.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 9 Oct 2013 14:49:55 +0300

> increasing number of fragments).

This was the thing that confiused me when reading the document. The
section 2.5 should explain the Total Fragments much better. I.e.
change the definition something like:

   o  Total Fragments (2 octets) - number of fragments original message
      was divided into. If original message is resent with different
      fragmentation boundaries this value MUST be larger than the
      previously used Total Fragments value, i.e the responder will
      use this to detect whether the incoming message belongs to the
      group of packets fragmented in same way. This field MUST NOT be
      zero.

Or something like that.

Also I do not understand why the Fragment Number and Total Fragments
start from 1. I think it would be more logical to have first fragment
be 0, second 1, and the Total Fragments would be The Last Fragment#
field. That way we do not need to have special check that fragment
needs to be ignored if Fragment Number or Total Fragments are 0.

In general I think the sending and receiving rules should be explained
a bit more.

For example the

   o  Check message validity - in particular, check whether values of
      Fragment Number and Total Fragments in Encrypted Fragment Payload
      are valid.  If not - message MUST be silently discarded.

should be changed to say:

   o  Check message validity - in particular, check whether values of
      Fragment Number (must be <= Total Fragments) and Total Fragments
      (must be >= previously seen Total Fragments for this message) in
      Encrypted Fragment Payload are valid. If not - message MUST be
      silently discarded.

It should clearly say that if Total Fragments is less than previously
seen then this fragment needs to be discarded.

Now when I am reading th text several times through I see that all the
required things are there, but when I was reading it first time
through it was really hard to parse what is going on, and especially
as I missed the dual role of the Total Fragments I got confused.

It might be enough to just add more text in the Total Fragments
description, clearly stating that it has dual role, i.e. telling what
is the max fragment number of this message, and to separate the
different fragmentation boundaries. My text above does not yet
properly describe that either, so some better text is needed. 
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Wed, 9 Oct 2013 09:40:08 -0400 (EDT)

> seen then this fragment needs to be discarded.

But you must only do that after the decryption/authentication of the
fragment or we are back at square one with an easy DoS this whole
mechanism was supposed to protect us from.

Which of course means an attacker can just send crap faster that you can
verify it is crap after performing crypto on the fragment.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 9 Oct 2013 18:07:38 +0300

> mechanism was supposed to protect us from.

We can drop the packets which have Total Fragments less than
previously seen authenticated fragment. To drop packets in the queue,
or update the total fragments value needs to be done only based on the
authenticated packet, and the document already had those steps after
ICV verification, so it already did that correctly.

The document was just not really explaining what the message validity
checks done in the first bullet point. 
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 10 Oct 2013 09:34:20 +0400

> then I think it should just not be in the document.

Sorry, I wasn't very clear. By "isn't very useful" I meant that it is not 
useful
for the usual PMTU discovery goal in TCP - to find _maximum_ IP datagram
size that is not fragmented by IP level. In IKE its the goal is different -
to find _some_reasonable_ IP datagram size that is not fragmented by IP.

If we have the size that is guaranteed to not be fragmented,
no PMTU discovery will be needed. As far as I understand, for IPv6
it is 1280 bytes. But as far as I know, there's no such value for IPv4.
If we mandate (or recommend) using really small value e.g. 128 bytes,
than the perfomance will suffer badly, so it it not a good option.
I'm especially worring about network I'm not familiar with -
mobile networks or other constrained environments.
It would be great if some experts in such networks could clarify this.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 10 Oct 2013 09:44:47 +0400

Hi Tero,

>      group of packets fragmented in same way. This field MUST NOT be

OK.

> needs to be ignored if Fragment Number or Total Fragments are 0.

That's a matter of taste. Actually, I wanted to leave one special value - 
zero,
just in case the protocol needs to be extended in the future.
I have currently no idea how it can be extended (if ever), but anyway
it is a good practice in protocol design to leave this possibility.

>      Encrypted Fragment Payload are valid. If not - message MUST be

OK.

> properly describe that either, so some better text is needed.

OK, I'll try to explain in more details.

Thanks,
Valery.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 10 Oct 2013 09:00:11 +0300

> Sorry, I wasn't very clear. By "isn't very useful" I meant that it is
> not useful
I'm even more worried that if we use small fragments, reliability will 
deteriorate. Because we do not have per-packet acknowledgement, and so 
if any fragment is dropped, the whole message must be resent. This is 
probably a greater risk in mobile networks.

---

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

Hi Paul,

> verify it is crap after performing crypto on the fragment.

Not necessary. It depends on the state receiver currently is in.

When you receive very first fragment and start reassembly you
remember its Total Fragments field (of course after you validate message).

After that you have the following possibilities.

1. You receive fragment with the same Total Fragments.You continue
reassembling, adding this fragment to the queue, or discarding it
if it is a duplicate packet

2. You receive fragment with the smaller Total Fragments. It may either
be a late packet from the previous set of fragments (larger in size)
that accidently reach us, or it may be attack packet, or it may be
packet from broken peer. In any case it is safe to discard it
without any verification.

3. You receive fragment with greater Total Fragments. In this case,
if you already successfully reassembled message and send a response,
it most probably means that response didn't reach peer. In this
case it is safe to retransmit response without any verification
of fragment authenticity, it won't hurt peer even if it was faked fragment.
You may rate limit such responses or you may verify fragment before - as you 
wish.
And if you support PMTU discovery, you may refragment response
into smaller fragments, but in this case it is better to verify
fragment before, as refragmentation cost is not zero.
If you still in the process of reassembling, than yes, you need
to verify fragment and, if it is valid, discard all received so
far fragments and start reassembling over, as it becomes clear
that peer decreased fragmen size and retransmits new set
of fragments, so its pointless for you to wait for the rest of
fragments from previous set.

---

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

> deteriorate. Because we do not have per-packet acknowledgement, and so if 
> any fragment is dropped, the whole message must be resent. This is 

Yes, a good point.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 10 Oct 2013 15:59:20 +0300

> probably a greater risk in mobile networks.

The fix there is to use IP level fragmentation... And only switch to
use small IKEv2 level fragmented packets if that does not work. This
whole protocol is only needed on the broken networks, so it does not
matter if it is very suboptimal, as we can always say that if you
enable fragmentation support on your devices, things will work
better.
-- 
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 15 Oct 2013 18:44:44 -0700

Could you wrap up the last set of suggestions for more text into a -04? That would let us do a WG LC soon.

--Paul Hoffman

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 16 Oct 2013 10:39:17 +0400

Yes, sure. I'm planning to do it by Friday.

> --Paul Hoffman=

---

From: "Mike Sullenberger (mls)" <[email-masked]>
Date: Thu, 17 Oct 2013 18:34:02 +0000

As I remember it IPv4 has a minimum packet size of 576 that won't (or at least shouldn't be) fragmented by IP.

Mike.

Mike Sullenberger, DSE
[email-masked]            .:|:.:|:.
Customer Advocacy          CISCO

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Valery Smyslov
> Sent: Wednesday, October 09, 2013 10:34 PM
> To: Paul Wouters
> Cc: [email-masked]
> Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-
> 03.txt
> 
> > if even you as a document author does not think it is very useful,
> Sorry, I wasn't very clear. By "isn't very useful" I meant that it is not useful
> size that is not fragmented by IP level. In IKE its the goal is different - to find
> _some_reasonable_ IP datagram size that is not fragmented by IP.
> 
> If we have the size that is guaranteed to not be fragmented, no PMTU
> discovery will be needed. As far as I understand, for IPv6 it is 1280 bytes. But
> as far as I know, there's no such value for IPv4.
> If we mandate (or recommend) using really small value e.g. 128 bytes, than
> the performance will suffer badly, so it is not a good option.
> I'm especially worrying about network I'm not familiar with - mobile
> networks or other constrained environments.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 17 Oct 2013 19:09:04 +0000

Yes, it says so in RFC 1122. Microsoft sends 576-byte packets when it does IKEv1 fragmentation.

Still, I don't think you're going to find on the modern Internet any networks that aren't usable by IPv6. So I think we should be pretty safe in adoption IPv6's minimum of 1280

Yoav

---

From: "Mike Sullenberger (mls)" <[email-masked]>
Date: Thu, 17 Oct 2013 19:31:41 +0000

Yoav,

Yes, I agree.   In fact except for tunneling stealing bytes, you could likely get away with 1500 bytes.  I think that 1280 is good compromise, with perhaps a hop down to 576 if 1280 runs into trouble.

Mike.

Mike Sullenberger, DSE
[email-masked]            .:|:.:|:.
Customer Advocacy          CISCO

> From: Yoav Nir [mailto:[email-masked]]
> Sent: Thursday, October 17, 2013 12:09 PM
> To: Mike Sullenberger (mls)
> Cc: Valery Smyslov; [email-masked]; Paul Wouters
> Still, I don't think you're going to find on the modern Internet any networks
> that aren't usable by IPv6. So I think we should be pretty safe in adoption
> IPv6's minimum of 1280
> 
> Yoav
> 
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Valery Smyslov
> >> not useful for the usual PMTU discovery goal in TCP - to find
> >> _maximum_ IP datagram size that is not fragmented by IP level. In IKE
> >> its the goal is different - to find _some_reasonable_ IP datagram size that
> is not fragmented by IP.
> >>
> >> discovery will be needed. As far as I understand, for IPv6 it is 1280
> >> bytes. But as far as I know, there's no such value for IPv4.
> >> than the performance will suffer badly, so it is not a good option.

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 18 Oct 2013 18:41:14 +0400

Hi Yoav,

> Yes, it says so in RFC 1122. Microsoft sends 576-byte packets when it does 

Actually, it is not a requirement in RFC1122, but only recommendation 
(although a "strong" one):

             "Since nearly all networks in the Internet currently
              support an MTU of 576 or greater, we strongly recommend
              the use of 576 for datagrams sent to non-local networks."

But I agree that 576 works in 90 or more percent of cases. And even 1280
will probably work for IPv4, but not so sure about it.

Valery.

> Still, I don't think you're going to find on the modern Internet any 
> networks that aren't usable by IPv6.
> So I think we should be pretty safe in adoption IPv6's minimum of 1280
>
> Yoav
>