[rohc] Inconsistency in texts for ESP, AH and GRE extension headers

["Lars-Erik Jonsson \(LU/EAB\)" <lars-erik.jonsson at ericsson.com>]

3095ers,

I've been made aware of an additional inconsistency in RFC3095 that
we should clarify in the implementer's guide. The issue is about
how to compress/decompress the sequence number in AH, ESP and GRE
extension headers, as these sequence numbers are similar, but the
RFC might be read as if they were treated differently. The text on
the ESP sequence number handling seems correct, while the AH and
GRE texts might be seen as implying implicit slopes for these, 
which robustness-wise is a flawed concept we have previously
discussed and found neither to be specified in 3095, nor really
workable.

The 3095 texts for AH, ESP and GRE can be found at the end of
this mail. It is suggested that the implementer's guide should
get a clarifying section as follows:

8.13.  Compression of SN in AH and GRE extension headers

   The AH and GRE sequence numbers are compressed exactly as the
   ESP sequence number. Specifically, the principle for when to
   include or exclude the AH and GRE sequence numbers is the same
   as for ESP, i.e. the following rule applies to all these 
   sequence numbers:

      Sequence Number: Not sent when the offset from the sequence number
          of the compressed header is constant.  When the offset is not
          constant, the sequence number may be compressed by sending
          LSBs.  See 5.8.4.

Any comments on this?

BR
/L-E


--------------------------------------------

5.8.4.2.  Authentication Header (AH)

   <snip> 

   If the sequence number in the AH linearly increases as the RTP
   Sequence Number increases, and the compressor is confident that the
   decompressor has obtained the pattern, the sequence number in AH need
   not be sent.  The decompressor applies linear extrapolation to
   reconstruct the sequence number in the AH.

  
5.8.4.3.  Encapsulating Security Payload Header (ESP)

   <snip>

      Sequence Number: Not sent when the offset from the sequence number
          of the compressed header is constant.  When the offset is not
          constant, the sequence number may be compressed by sending
          LSBs.  See 5.8.4.


5.8.4.4.  GRE Header [RFC 2784, RFC 2890]

   <snip>

   If the sequence number in the GRE header linearly increases as the
   RTP Sequence Number increases and the compressor is confident that
   the decompressor has received the pattern, the sequence number in GRE
   need not be sent.  The decompressor applies linear extrapolation to
   reconstruct the sequence number in the GRE header.

_______________________________________________
Rohc mailing list
Rohc at ietf.org
https://www1.ietf.org/mailman/listinfo/rohc