Subject: [rohc] RE: List compression issues

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Wed, 10 Sep 2003 10:22:51 +0200

Kristofer,

> -----Original Message-----
> From: Kristofer Sandlund [mailto:[email-masked]]
> Sent: den 8 september 2003 16:17
> To: [email-masked]
> Cc: Lars-Erik Jonsson (LU/EAB)
> Subject: List compression issues
> 
> 
> Hi all!
> 
> I've been going over the list compression spec to see if 
> there are any "holes" 
> in it and I have found the following issues that the spec is 
> unclear or maybe 
> even erroneous.
> 
> Issue 1:
> RFC 3095, section 5.8:
> 
>  >   IPv6 base headers and IPv4 headers cannot be part of an extension
>  >   header chain.  Headers which can be part of extension 
> header chains
>  >   include
>  >
>  >   a) the AH header
>  >   b) the null ESP header
>  >   c) the minimal encapsulation header [RFC2004, section 3.1]
>  >   d) the GRE header [GRE1, GRE2]
>  >   e) IPv6 extension headers.
> 
> The word "include" is not really true as I see it. Of course the list 
> compression mechanism can be used to compress other headers, but if a 
> 3095-implementation compresses another type of header than 
> those listed above, the decompressor must know how to get the length
> of that header. For example, the IPv6 extension headers send a length
> field in byte 2, while the GRE header length must be calculated from
> the flag byte. The ESP NULL header does send any length field at all
> etc.
> 
> So I cannot see how the decompressor should decompress an "unknown"
> header type without prior knowledge on where the length information
> is stored in the list item sent. If we were to add an
> "uncompressed-format-for-unknown-header-types", where it is 
> specified where the length field is located and its interpretation,
> we would still have problems with how the decompressor should
> restore the header. E.g. where does the length field go and where
> do I put the next header field (if it is not in the first byte of
> the original header)? Since this would be quite a large addition to
> make this work (unless, I have missed something), I feel that the
> "include" word should be removed, and that only the headers listed
> above should be compressible with RFC3095 list compression. I feel
> this should be added to the implementers guide.

If noone objects and bring some facts we both have missed, I agree
with you on this!

> Issue 2:
> RFC3095 section 5.8.4.3 (ESP NULL header list compression):
> 
>  >      Pad Length: Dynamic.  Always sent.  14th octet from 
> end of packet.
>  >      Next Header: Static.  13th octet from end of packet.
> 
> So what if I have an ESP NULL in the inner header chain and 
> one in the outer header chain? Suddenly the statment above
> is not true for the inner ESP NULL header. It seems that
> this kind of header is not very likely to occur and the spec 
> should maybe disallow compression of such a header chain.
> But if that is the intention of 3095, then we should put in
> the implementer's guide that only one ESP NULL header can
> be present in a compressed packet. The other option is of 
> course to allow this compression and then the "Pad length" 
> should be defined as being "14 octet from the end of the
> current ESP 'trailer'". Note: the ESP "trailer" will be
> variable length and therefore we would not have a constant 
> offset when multiple headers are present.

Agree with your concerns! 

> Suggested additions for implementer's guide:
> "The only headers that can be compressed using list 
> compression are AH header, null ESP header, minimal
> encapsulation header, GRE header and IPv6 extension 
> headers.

OK!

> The compressor should only compress packets containing
> at most one null ESP header due to the offset of the
> fields in the trailer part of the ESP header."

Ok, maybe "should" should be a little bit more precise,
e.g. "must" (or rewrite a little bit and use "must not").

/L-E

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Kristofer Sandlund <[email-masked]>
Date: Thu, 11 Sep 2003 08:38:08 +0200

Lars-Erik,

> e.g. "must" (or rewrite a little bit and use "must not").

I agree. Feel free to change it as you suggested, my text was a little 
non-RFC-ish :)

Rgds,
	Kristofer Sandlund, Effnet AB