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

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

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

Making it work for IPsec might not be impossible, but it does
require additional work beyond what's in the current drafts.

Best regards,
Psai