Re: Compression of AH/NULL-ESP headers in ROHCv1

At Tue, 1 Dec 2009 11:16:20 +0530,
Anil Maguluri wrote:
> Q1. what are the fields are part of dynamic context for AH/ESP NULL
>     headers?

There are no static fields in the extension headers. Therefore the
extension headers are not defining the context. The whole extension
header chain is handled with the list compression stuff. And the CL
can appear in the extension-3.

AH:
The authentication data is sent always. 

If the SPI changes, the whole header must resent. You can see the SPI
as static, but a changed SPI does not define a new context/stream. The
length field also.

If the SN jumps different from the "master" SN (RTP-SN), it must
updated with the IPX field Aseq. See RFC 3095 5.8.4.2.

And the next header field is reconstructed by de-compressor, because
the de-compressor nows the whole extension header chain and therefore
the previous and next header from the AH header. It is defined by its
position in the CL.

For ESP/Null see RFC.

> Q2. For AH, there is no uncompressed format specified in the RFC
>     3095. Can you please let me know uncompressed format of the AH
>     header?

For ESP and GRE a special uncompressed format is needed, because the
next header field is not the first. So you must re-write this headers
into a form where the next header field is first. On AH and the IPv6
extension headers the next header field is first, therefore they can
be used as they are without rewriting, excepted the next header
field. The next header field must changed that it points to itself.
Thus, the uncompressed form is as-is with authentication data.

RFC: "If the uncompressed AH is sent, the authentication data field is
sent inside the uncompressed AH;"

> Q3. What is the use of "AH data for inner/outer list" field in the
>     general format for a RTP header as specified in the RFC (section
>     5.7, page 77)?

RFC: "otherwise, it is sent after the compressed IP/UDP/RTP and IPv6
extension headers and before the payload. See beginning of section
5.7."

This is the positon of the authentication data, if it is not sent
within the CL as uncompressed AH list item (the AH can compressed
away, if the SPI and length is unchanged, and the SN can inferred from
master SN and the pattern is known by de-compressor). Then the field
form the AH header "authentication data" are placed there.

> Q1. I did not see the above information in RFC. Can you please let
>     me know In which section it is specified?

What information?

The information can be found crystal clear in the 3095. But sometimes
they are spreaded over the document and crypted, so I'm not able to
specify a section. Sorry.

Could you please provide the section, which disagrees my posting?
I have not so much time...

> Q2. Please clarify whether my understanding is right or wrong. 
>     For AH: 

>     Assume list has only AH packet (IPv4/AH/UDP/RTP). This packet
>     Should compress using Profile-1 (IPv4/UDP/RTP) with List
>     compression for AH.  Initially compressor will send the
>     uncompressed packet format using the Generic scheme using
>     IR/IR-DYN/UOR-2 with EXT-3. After setting the context,
>     compressor make reference list using the uncompressed
>     packet. After that, compressor will compare the received list
>     item with the reference list item to check whether the list has
>     changed or not (by checking SPI value). If the list is not
>     changed, and AH SN can be derived from SN (assume RTP), then no
>     need to sending AH SN by using EXT-3 packet (setting the Aseq
>     bit). If the list has not changed and AH SN cannot derivable
>     from SN (RTP), then compressor has to send the compressed AH SN
>     value using EXT-3 header (setting the Aseq bit).  If the list
>     changes, use Generic Scheme to send the new header information
>     to the decompressor.

I agree.  

Additionally, you have to check the length field in the same way as
SPI.

> Regards,
> Anil Kumar Maguluri

br
Klaus