Re: Last call comments for ROHCoIPsec: draft-ietf-rohc-hcoipsec, draft-ietf-rohc-ikev2-extensions-hcoipsec, draft-ietf-rohc-ipsec-extensions-hcoipsec

On Sep 22, 2009, at 12:35, <[email protected]> wrote:

>>> 3) According to RFC 4224, ROHC segmentation does not work over
>>> reordering channels. Thus, it seems suggesting that ROHC
>>> segmentation could be used instead of pre-encryption fragmentation
>>> (e.g.  ipsec-extensions, Section 3.3) -- and in general, allowing
>>> segmentation at all -- seems misguided (it's unnecessary
>>> complexity that would be IMHO best left out).
>>
>> Although I agree that ROHC segmentation is not a good idea, it is an
>> optional functionality in the spec.  The implementer can decide
>> whether or not they want to code it.
>>
>> If a vendor chooses not to implement the functionality, they can
>> hardwire the MRRU channel parameter to zero.
>
> 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.

Is ROHC segmentation "better" than IP fragmentation?
It certainly has fewer of the problems of IP fragmentation.
It does require throwing some CPU at the data (it uses a CRC).

Because header compression creates a variable-MTU channel, being able  
to segment in a pinch is a boon.

Since the ROHC framework has the functionality, and it is not hard to  
make it work on IPsec, I would favor retaining it.

Gruesse, Carsten