Hi Pasi,
Carsten Bormann wrote:
OK, let me phrase my question in another way: why does the spec
contain a feature that does not really work? (Even as optional
feature?)
Well, it actually does work.
RFC 4224, section 5.2.1 tells us that when a channel is reordering
and you don't notice, packets will be lost. Now IPsec is a strange
animal: It is reordering, but the order can be reconstructed from
the sequence number. So a reassembler could (here really: SHOULD)
use that to avoid stitching together packets in the wrong order and
then discarding them.
Well, the current drafts don't specify any such behavior, so the
feature as it's currently written does not work. (Also, using the
ESP/AH sequence number this way would be very unusual -- there
might be some complications...)
If we include text that states this behavior, does this address your concern?
FWIW, I could also think of deployment scenarios where packet
reordering is minimal (e.g., ROHCOIPsec is instantiated over a single
[bandwidth constrained] link). Such scenarios may not even require
the use of the ESP/AH sequence number to reconstruct ROHC segments.
Best Regards,
Emre
Best regards,
Psai
_______________________________________________
Rohc mailing list
Rohc(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/rohc
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf