Subject: [rohc] ESP NULL header & CRC coverage

From: Kristofer Sandlund <[email-masked]>
Date: Thu, 04 Sep 2003 13:41:04 +0200

Hi all,

I have a question on how to interpret the list compression.

Since the interops so far have not gone into extension header list 
compression, we have not been able to verify the CRC coverage of the ESP 
NULL header, which I feel is not fully clear from RFC3095.

Section 5.8.7 (CRC coverage for extension headers) says that: the 
"Entire ESP header" is CRC-dynamic (It does not matter if it is 
CRC-dynamic or CRC-static, but this speaks of the CRC coverage). And 
section 5.8.4.3 shows a picture "ESP header" as being the entire packet 
until the end of the payload. So the statment "Entire ESP header" should 
be equivalent to the picture labeled "ESP header", right?

Taking these pieces of information, one _could_ interpret it the 
following ways:

1) The text cited above seems to indicate that we should CRC everything 
from the the picture mentioned above, including all the headers 
following the ESP header, payload, padding etc. But this does not really 
seem to make sense (why do CRC on the payload?), so one could interpret 
it a few other ways, namely:

2) Take the same approach as in 5.7.7.7 (Initialization of ESP Header) 
where the following is stated:

 >  Note: No encrypted data is considered to be part of the header for
 >  purposes of computing the CRC, i.e., octets after the eight octet are
 >  not considered part of the header.

But since 5.7.7.7 also says that:
 >  This is for the case when the NULL encryption algorithm [NULL] is NOT
 >  being used with ESP, so that subheaders after the ESP header are
 >  encrypted (see 5.12).  See 5.8.4.3 for compression of the ESP header
 >  when NULL encryption is being used.

So therefore the "Note" above should not apply to the ESP NULL header.
Also, this does not seem really correct, since all the other extension 
headers have the next header field covered by the CRC.

3) Use all the ESP NULL header fields for the CRC (i.e. SPI, SN, 
Padding, Pad length, Next Header, Authentication data), but exclude 
payload/other headers. But do we want to do CRC over the fields at the 
end of the packet?
One could also consider variants of this, such as CRC:ing all the fields 
above except the padding etc.

So, what is the opinion of the group/authors?

/Kristofer Sandlund, Effnet AB

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

---

From: "Lars-Erik Jonsson (LU/EAB)" <[email-masked]>
Date: Thu, 11 Sep 2003 11:25:08 +0200

Some comments inline...

> -----Original Message-----
> From: Kristofer Sandlund [mailto:[email-masked]]
> Sent: den 4 september 2003 13:41
> To: [email-masked]
> Subject: [rohc] ESP NULL header & CRC coverage
> 
> 
> Hi all,
> 
> 1) The text cited above seems to indicate that we should CRC 
> everything from the the picture mentioned above, including all
> the headers following the ESP header, payload, padding etc. But
> this does not really seem to make sense (why do CRC on the
> payload?), so one could interpret it a few other ways, namely:

Agree!

> 2) Take the same approach as in 5.7.7.7 (Initialization of 
> ESP Header) where the following is stated:
> 
>  >  Note: No encrypted data is considered to be part of the
>  >  header for purposes of computing the CRC, i.e., octets
>  >  after the eight octet are not considered part of the header.
> 
>  >  This is for the case when the NULL encryption algorithm
>  >  [NULL] is NOT being used with ESP, so that subheaders after
>  >  the ESP header are encrypted (see 5.12).  See 5.8.4.3 for
>  >  compression of the ESP header when NULL encryption is being used.
> 
> Also, this does not seem really correct, since all the other
> extension headers have the next header field covered by the CRC.

Sounds reasonable!

> payload/other headers. But do we want to do CRC over the 
> fields at the end of the packet?
> One could also consider variants of this, such as CRC:ing all 
> the fields above except the padding etc.

I wonder if this is really needed...

> So, what is the opinion of the group/authors?

To me, 2) seems to be a reasonable interpretation. What do others think?

/L-E