Rohcers have to excuse me for double posting. I want pass on some information from a parallel thread on the rohc list.
As Tero pointed out, there already is a way in ROHCoIPSec to send packets uncompressed. The tunnel already keeps track of the MTU to compensate for the IP, ESP AH headers. So adding ROHC overhead should not a problem. Why not let the user decide whether or not to use ROHC segmentation, IP fragmentation or sending large packets through the uncompressed channel. We could list pros and cons and give some guidelines. /Calle Tero Kivinen wrote: > Carl Knutsson writes: >> RTP profile can in worst-case add up to around 20 bytes. Header >> compression works best for small packets. Large packets that doesn't fit >> the MTU because of the overhead could be sent uncompressed or over a >> channel without ROHC. The overhead for the uncompressed profile is only >> a few bytes. This overhead is added to the PMTU field. > > With ROHC over IPsec there is already a way to express uncompressed > packets without any overhead (i.e. if next header is ROHC protocol > then packet is compressed with ROHC, if not then it is uncompressed), > so sending uncompressed packets does not add any more overhead than > what IPsec already adds. > > The amount of overhead for IPsec is per SA, as it depends on the > protocol (ESP/AH) and about the algorithms selected for that SA, so > adding ROHC overhead there should be easy. The ROHC overhead should > take account the normal ROHC maximum header expansion and the ROHC ICV > length. Carsten Bormann wrote: >> 2. Set a commonly supported ROHC MTU for the tunnel and use ROHC >> segmentation to handle the packets that gets expanded beyond PMTUD. >> [...] Not >> certain that the ROHC segmentation mechanism can work over reordering >> transports. > > As Carl pointed out, ROHC segmentation is efficient only for > non-reordering links. > It is similar to AAL5, but does not use a length field. > Assuming the CRC is effective, it responds to undetected reordering with > dropping the (reassembled) packet(s) affected with a likelihood of p ≈ > 1-2**-32 (and delivering a bad one with q ≈ 2**-32). > I'm not happy about the security implications if it is not. > > However, the IPsec sequence number might be good enough to reliably > detect reordering or even to resequence before ROHC reassembly. I think > that might be the right thing to do, as ROHC segmentation is much better > than IP fragmentation on a non-reordering link. > > So there *was* something specific that ROHC could bring to the table... > > The remaining problem is that the compressor needs to know the tunnel MTU. > > On ROHC, I wrote: > >> So what would you want the compressor to do? >> Run PLPMTUD (probes can be done by occasionally compressing badly*) on >> the tunnel and reject (ICMP unreachable/Frag needed) all DF/IPv6 >> packets that would not fit with worst-case expansion? >> Probably safe, but somewhat expensive. >> [...] >> >> *) Yes, this needs way more text. >> You would need to compress badly whenever compressing a packet that, >> badly compressed, would not fit the currently established safe PMTU. >> That unfortunately tends to shrink while compressing well, which ROHC >> tends to do :-) > > So let's replace that with: > >> Run PLPMTUD (probes can be done by occasionally compressing badly*) on >> the tunnel and ROHC-segment all DF/IPv6 packets that would not fit >> with worst-case expansion. >> *) This can be done by sending the packet on a separate CID with an >> IR, with some impact on compression efficiency on the original CID. > > Does that work? > > Gruesse, Carsten > > _______________________________________________ > Rohc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rohc
