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

From: Carl Knutsson <[email-masked]>
Date: Mon, 03 Dec 2007 16:55:20 +0100

Kristofer, Anders, all

I promised you a solution to the issue with the trailer length and
inferred fields.

One solution is to add a field, trailer_length, in the esp_null_dynamic
and esp_null_irregular compressed formats. The field will carry the
length of the whole trailer, including the ICV, Next Header, Pad Length
and Padding.

An alternative solution is to split the trailer_length field in the
above suggestion into padding_length and ivc_length. Send both field in
dynamic chain and only padding_length in irregular chain and default
encode ivc_length so that the decompressor can calculated the trailer
length.

I prefer the second solution, were we only one octet is added to the
irregular chain. It is also unlikely that the ICV length is changing
between packets. Opinions?

I can draft changes in the document for this solution, if we have
consensus for it...

/Calle

Carl Knutsson wrote:
> Hi Kristofer, Anders,
> 
> inline...
> 
> Kristofer Sandlund wrote:
>> 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.
> 
> 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
> 
>> Btw, thanks for finding this issue!
>>
>> /Kristofer
>>
>> Anders Edqvist <mailto:[email-masked]> wrote on den 23
>> november 2007 15:57 :
>>
>>> 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
>>>
>>>
>>> Carl Knutsson wrote:
>>>> 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
>>>>
>>>> Kristofer Sandlund wrote:
>>>>
>>>>> 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 : 
>>>>>
>>>>>
>>>>>> 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
>>>>>>
>>>>> _______________________________________________
>>>>> Rohc mailing list
>>>>> [email-masked]
>>>>> https://www1.ietf.org/mailman/listinfo/rohc
>>>>>
>>>> _______________________________________________
>>>> Rohc mailing list
>>>> [email-masked]
>>>> https://www1.ietf.org/mailman/listinfo/rohc
> 
> 

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

---

From: "Kristofer Sandlund" <[email-masked]>
Date: Mon, 3 Dec 2007 17:42:52 +0100

Hi Calle,

the more I think about this, the more I come to belive that we don't
really want to compress this. I've always thought this was a not-so-good
idea, but since I stupidly thought that the next-header was the only
issue, I thought we might as well do it. But, now that we need to know
the trailer length as well, and we need to be able to transmit that one
in the static-chain part, is it really worth the effort?

To first get back to 3095, that assumes that it can compress if
the ICV=12 octets AND the padding is a certain pattern. (this
pretty much requires a priori knowledge for it to be useful)
With 4815, we restricted it further by saying that only one such
header per flow could be compressed to avoid the quite insane behavior
of tunneling these. So it wasn't very generic there.
And AFAIK, the ESP-null compression has never been interoptested, which
I think speaks volumes about its popularity :)

With v2, my design criteria has been that the decompressor should never
have to care about inspecting the trailer so that an implementer
can decide to keep a clean implementation even if it encounters
a compressor that feels the need to implement support for this
craziness.
But to accomplish that, we now need one octet next_header (static),
we need at least 2 octets of length (dynamic, possibly irregular as per 
your suggestion) and we also added one octet to the ESP profile
(protocol field, static chain) for this.
And how often do we belive that the compressor will be able to know
a priori that a header is null-encrypted, and even more unlikely,
know that more than one in a tunnel scenario are ESP-null
(not that this will happen)?

My only reason for wanting to fix this "bug" is that I'm too 
lazy to remove all the text/code in the draft for this, and I don't
think 
that goes very far as an argument, so please let us stop the madness
before it gets out of hand :)

So my question to the list is: Do you see any use for compressing
the ESP-null header? Can we please get rid of this and force the use
of the ESP profile on these headers?
If you disagree, please try to motivate why this is possible and
why it is needed.

/Kristofer

Carl Knutsson <mailto:[email-masked]> wrote on den 3 december
2007 16:55 :

> One solution is to add a field, trailer_length, in the
> esp_null_dynamic and esp_null_irregular compressed formats. The field
> will carry the length of the whole trailer, including the ICV, Next
> Header, 
> Pad Length
> and Padding.
> 
>>> 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 
>> 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
>> 
>>>> 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 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
>>>>> 
>>>>>> 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. 
>>>>>> 
>>>>>> Anders Edqvist <mailto:[email-masked]> wrote on den
>>>>>> 22 november 2007 13:23 : 
>>>>>> 
>>>>>> 
>>>>>>> Hi all,
>>>>>>> 
>>>>>>> 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. 
>>>>>>>