Subject: [rohc] List compression issues

From: Kristofer Sandlund <[email-masked]>
Date: Mon, 08 Sep 2003 16:17:13 +0200

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.

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.

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

/Kristofer Sandlund, Effnet AB

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