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.
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.
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.
Kind Regards,
Raj
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
