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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sep 22, 2009, at 12:35, <Pasi.Eronen@xxxxxxxxx> 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

_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]