Subject: [rohc] ESP-NULL in v2-O2

From: Anders Edqvist <[email-masked]>
Date: Thu, 22 Nov 2007 13:23:09 +0100

Hi all,

There is a problem in the spec for rohc v2 (-O2) concerning ESP-NULL
extension headers.

6.7 for esp_null is says:

"next_header_value: Set to the value of the Next header field located in
the ESP trailer, usually 12 octets from the end of the packet.
Compression of null-encrypted ESP headers should only be performed when
the compressor has prior knowledge of the exact location of the next
header field."

The above formulation suggests that the size of the Authentication Data
field in the ESP trailer doesn't have to be 12 octets as long as the
compressor knows how large it is. The problem is that the compressor
never sends this information to the decompressor. The decompressor on
the other hand must know this to for example infer the length of the
inner IP4 packet in IP4/ESP-NULL/IP4.

To fix this I suggest that either "auth_data_len" is included in the static/dynamic chain for ESP-NULL or that the text is updated to say that the Authentication Data field MUST be 12 octets if ESP-NULL compression is to be performed.

Regards,
Anders Edqvist

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

---

From: "Kristofer Sandlund" <[email-masked]>
Date: Fri, 23 Nov 2007 08:25:59 +0100

Hi Anders,

without thinking too much of this, I don't think it is an issue. 
In v2, we no longer compress the trailer and we instead duplicate
the next header field and insert "nh_field" into the esp_static in
esp_null (which is also the reason why 'regular' esp has a
discriminator.
So the decompressor should never have to inspect the trailer
and therefore it does not have to know the length of the auth
data. I don't see a problem here, but if you still disagree, let me
know.

Btw, I always thought the trailer compression on the ESP null in 3095
was a terrible mistake, since it made implementation into a mess.
Therefore, removing this behavior was a priority for v2.

BR,
   Kristofer

Anders Edqvist <mailto:[email-masked]> wrote on den 22
november 2007 13:23 :

> "next_header_value: Set to the value of the Next header field located
> in the ESP trailer, usually 12 octets from the end of the packet.
> To fix this I suggest that either "auth_data_len" is included
> in the static/dynamic chain for ESP-NULL or that the text is
> updated to say that the Authentication Data field MUST be 12
> octets if ESP-NULL compression is to be performed.
> 
> Regards,
> Anders Edqvist
> 
> 
>

---

From: Carl Knutsson <[email-masked]>
Date: Fri, 23 Nov 2007 09:13:01 +0100

Kristofer, Anders,

The issue is not about compressing the ESP null trailer. I think we can
 all agree that removing the ESP trailer compression was a very good
WG/author decision (your suggestion). Especially from an implementer's
point of view.

What Anders is trying to point out, is it impossible to calculate the
length of the payload for ESP null encapsulated headers without knowing
the length of the ESP null trailer. This makes it impossible to
calculate inferred length fields for ESP encapsulated headers.

Example:

Uncompressed Header
+------------+
| Outer IP   |
+------------+
| ESP null   |
+------------+
| Inner IPv4 |
+------------+
| IP payload |
|     +      |
| ESP trailer|
+------------+

Compressed Header
+------------+
| ROHC header|
+------------+
| IP payload |
|     +      |
| ESP trailer|
+------------+

We only know how long the 'inner IPv4 payload + ESP trailer' is after
removing a rohc header. How should the decompressor calculate IPv4
'Total Length' field for the inner IPv4 header?

Cheers,

/Calle

---

From: Anders Edqvist <[email-masked]>
Date: Fri, 23 Nov 2007 15:56:30 +0100

Kristofer,

I'm still convinced there is a problem. I think Calle clarified the
issue with this response so I won't go into it again.

In my previous email I suggested two methods to fix this but from
reading your' and Calle's responses I see that they both broke the
intension for the decompressor not to have to "muck around" with the
trailer in v2.

Calle pointed out (off-list) that it is possible to use a much simpler
approach and send the length of the entire esp-null trailer in every
single packet (remember that padding can differ from packet to packet).
The decompressor could then calculate the length of the payload for
encapsulated headers easily without having to inspect the trailer.

It would only require adding a 1-2 byte "esp_null_trailer_len" field in
the dynamic and irregular chains for ESP-NULL extension headers.

Regards,
/anders

---

From: "Kristofer Sandlund" <[email-masked]>
Date: Mon, 26 Nov 2007 08:33:06 +0100

Hi Anders,

from Calle's explanation, I can see what the problem is, I thought you
were talking about the protocol field, and not about how to infer
the length in encapsulated headers.

So I agree that something needs to be done. IMO, the best solution would
be to stop allowing compression the ESP-null, but that's probably not
an option at this stage. So I think we should just not try to do more
than 3095 does in this case, so we should say something like:
"ESP-NULL headers MUST NOT be compressed if the length of
the authentication data does not equal 12 octets"
(I will rephrase that, but that's the message I'd like to give)
Let me know if you still prefer a more generic solution.

Btw, thanks for finding this issue!

/Kristofer

Anders Edqvist <mailto:[email-masked]> wrote on den 23
november 2007 15:57 :

>> The issue is not about compressing the ESP null trailer. I think we
>>  can all agree that removing the ESP trailer compression was a very
>> good WG/author decision (your suggestion). Especially from an
>> implementer's point of view. 
>> 
>> length of the payload for ESP null encapsulated headers without
>> knowing the length of the ESP null trailer. This makes it impossible
>> to calculate inferred length fields for ESP encapsulated headers.
>> 
>> Example:
>> 
>> Uncompressed Header
>> +------------+
>>> Outer IP   |
>> +------------+
>>> ESP null   |
>> +------------+
>>> Inner IPv4 |
>> +------------+
>>> IP payload |
>>>     +      |
>>> ESP trailer|
>> +------------+
>> 
>> Compressed Header
>> +------------+
>>> ROHC header|
>> +------------+
>>> IP payload |
>>>     +      |
>>> ESP trailer|
>> +------------+
>> 
>> 
>>> discriminator. So the decompressor should never have to inspect the
>>> trailer 
>>> Btw, I always thought the trailer compression on the ESP null in
>>> 3095 was a terrible mistake, since it made implementation into a
>>> mess. Therefore, removing this behavior was a priority for v2.
>>> 
>>> BR,
>>>    Kristofer
>>> 
>>>> There is a problem in the spec for rohc v2 (-O2) concerning
>>>> ESP-NULL extension headers. 
>>>> 
>>>> "next_header_value: Set to the value of the Next header field
>>>> located in the ESP trailer, usually 12 octets from the end of the
>>>> packet. Compression of null-encrypted ESP headers should only be
>>>> performed when the compressor has prior knowledge of the exact
>>>> location of the next header field." 
>>>> 
>>>> The above formulation suggests that the size of the Authentication
>>>> Data field in the ESP trailer doesn't have to be 12 octets as long
>>>> as the compressor knows how large it is. The problem is that the
>>>> compressor never sends this information to the decompressor. The
>>>> decompressor on the other hand must know this to for example infer
>>>> the length of the inner IP4 packet in IP4/ESP-NULL/IP4.
>>>>

---

From: Carl Knutsson <[email-masked]>
Date: Mon, 26 Nov 2007 14:29:56 +0100

Hi Kristofer, Anders,

inline...

> Let me know if you still prefer a more generic solution.

The problem with this approach is that the decompressor still need to
inspect the trailer in order to find the size of the padding field.
Sending the trailer/payload length in irregular & dynamic chain could be
a better solution. I will investigate this approach and get back to the
list with conclusions and hopefully some sort of solution.

Cheers,

/Calle