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

From: [email-masked]
Date: Mon, 09 Sep 2013 05:56:09 -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-02.txt
	Pages           : 20
	Date            : 2013-09-09

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

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

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: Mon, 9 Sep 2013 17:03:43 +0400

Hi all,

I've just posted new version of IKEv2 Fragmentation draft.
It addresses Yaron's comments on the -01 version.

Regards,
Valery Smyslov.

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

---

From: "Rajeshwar Singh Jenwar (rsj)" <[email-masked]>
Date: Wed, 18 Sep 2013 07:02:42 +0000

Hi Valery,

IKEv2 fragmentation is mostly used for large sized packets. There are use-cases when our implementation needs to send huge sized packet over IKEv2 control plane channel. 
On lossy network if one of the fragment is lost, using current draft, responder will not be able to reassemble IKEv2 packet, so initiator needs to re-transmit all the fragments again.

If we are already going for integrity protected encryption for each fragment, is option of ACK response for each fragment using encrypted fragment payload has been investigated ?

Using encrypted fragment payload for ACK for fragment, if some fragment are lost while retransmitting we can retransmit only those fragments for which we have not received ACK.
The solution works well for time critical large size control packets, on the down side, it incurs ACK overhead for each fragment on networks where there is no packet loss.

In constrained devices environment, need of fragmentation will be more as these networks can carry limited size of packet.
More re-transmit on lossy and constraint devices will consume more battery too.
At the same time these network are lossy in nature, so having an ACK mechanism for fragments make more sense.

Kind Regards,
Raj

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Valery Smyslov
Sent: Monday, September 09, 2013 6:34 PM
To: [email-masked]
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-fragmentation-02.txt

Hi all,

Regards,
Valery Smyslov.

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

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 18 Sep 2013 15:52:54 +0400

Hi Raj,

> IKEv2 fragmentation is mostly used for large sized packets. There are 
> use-cases when our
> implementation needs to send huge sized packet over IKEv2 control plane 
> channel.
> On lossy network if one of the fragment is lost, using current draft, 
> responder will not be able
> to reassemble IKEv2 packet, so initiator needs to re-transmit all the 
> fragments again.

True.

> If we are already going for integrity protected encryption for each 
> fragment, is option of ACK
> response for each fragment using encrypted fragment payload has been 
> investigated ?

I was thinking about ACKs, but rejected this idea for the sake of 
simplicity.
Adding ACKs would have required to change all the underlying 
request-response logic
from simple

Request  --->
              <--- Response

to

Request  --->
              <--- ACK(s)
              <--- Response
ACK(s)    --->

and this change would have violated some of RFC5996 core statements.
For example, in IKEv2 only Initiator is responsible for retransmissions,
with ACKs this would have not been true.

> Using encrypted fragment payload for ACK for fragment, if some fragment 
> are lost while
> retransmitting we can retransmit only those fragments for which we have 
> not received ACK.
> The solution works well for time critical large size control packets, on 
> the down side, it incurs
> ACK overhead for each fragment on networks where there is no packet loss.
>
> In constrained devices environment, need of fragmentation will be more as 
> these networks
> can carry limited size of packet.

>From my opinion, it depends. ACKs would have been useful if:
- fragments are relatively large
- probability of packet loss is relatively small
- you want to reach maximum network bandwidth utilization

For situation you described, adding ACK might make things even worse, 
because:
- when fragments are small, overhead caused by ACKs becomes significant
    in terms both network utilization and power consumption. Note, that ACKs
    must be protected against spoofing, so you should make some cypto
    operations on each of them (at least calculate ICV).
- if network is lossy, ACKs will get lost either, causing unnecessary
    retransmissions and bandwidth consumption

For example. Consider we have network with fragment size 512 bytes
and probability of packet loss of 1/100. And consider you want
to send 50Kbytes of data in 10 IKE Messages. So, each IKE Message
wiil be splitted into 10 fragments, totally 100 fragments.
With very high probability one of them will get lost.
Without ACKs one entire Message of 10 fragments will be retransmitted,
So we have 5Kbytes overhead (10%).
With ACKs we have to acknowledge all 100 fragments sending 100 ACKs.
With ACK size about 50 bytes (header, ICV) it is 5Kbytes overhead.
Again, one fragment will get lost, causing its retransmission.
And among 100 ACKs one will also get lost, causing unnecessary
retransmission of one fragment. So, total overhead will be 6Kbytes (12%).

Of cause, this example is oversimplified, but the idea is clear.

I think that if you need to send large amount of data over IKE you'd
better to split data on the higher level (if it is possible).
IKE Fragmentation will do its best, but it is the last resort
for those cases, when splitting is impossible.

BTW: thinking of this I came across one simple optimization that is not yet
in the draft. If some of response fragments get lost, but Initiator
have received at least one of them (meaning, that Responder
get received request Message), Initiator may retransmit not all, but only
the very first of request fragments to cause Responder to resend its 
response.
This is simple and I will add this optimization (as MAY) to the next version
of the draft. Thank you.

> Raj

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 18 Sep 2013 09:58:51 -0400 (EDT)

> The solution works well for time critical large size control packets, on the down side, it incurs ACK overhead for each fragment on networks where there is no packet loss.

Isn't it easier (and cheaper/faster) to jsut send all fragments again?
The receiving hasn't thrown away its previosuly received fragments and
can just discard the duplicate frames.

> At the same time these network are lossy in nature, so having an ACK mechanism for fragments make more sense.

I'd say it would take more resources to build up a new packet to request
particular frames. Also in IKEv2, its really up to the initiator to
re-send, so itshould jsut re-send all its frames while the responder
just waits on the missing frames.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 19 Sep 2013 14:58:01 +0300

Rajeshwar Singh Jenwar (rsj) writes:
> IKEv2 fragmentation is mostly used for large sized packets. There
> are use-cases when our implementation needs to send huge sized
> packet over IKEv2 control plane channel.

I have understood that the idea for IKEv2 fragmentation is to be used
for large packets which cannot be split in to the pieces in the
existing exchanges. I.e. when the IKE_AUTH gets too big because the
certificate payloads etc.

If you are doing some extension over IKEv2 where you know that the
data will be large, you should define the protocol so it uses multiple
IKEv2 messages. I.e. if you are planning to make policy transport
exchange for IKEv2, it would be better to split the data to smaller
pieces by the upper level and send them as separate messages. This
also allows windowing of the messages, i.e. you can send next message
while you are waiting for the IKEv2 acknowledgement of the previous
IKEv2 message, and if you are not getting it, you can retransmit the
packet normally (all fragments of it).

Anyways IKEv2 is not really designed for large data transfers, as it
is misssing some key features for that use. For example the policy
transport would be much better done as separate TCP stream inside the
IKEv2 negotiated ESP SA... 

> fragment, is option of ACK response for each fragment using
> encrypted fragment payload has been investigated ?

I think the current versions is simplier and better.

> In constrained devices environment, need of fragmentation will be
> more as these networks can carry limited size of packet. More
> re-transmit on lossy and constraint devices will consume more
> battery too. At the same time these network are lossy in nature, so
> having an ACK mechanism for fragments make more sense.

In radio networks there is quite often link layer acks already, so the
link layer tries to make sure each fragment reaches its destination
and they will do retransmissions at their own. Constrained devices
might not have enough resources to actually do any large sized packets
anyways, and that makes it even more important to make sure the
packets do not get too big and do some upper level splitting of the
data.
-- 
[email-masked]