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... > 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 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 protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
