Subject: [rohc] Encapsulating ESPnull header in ESP profile (ROHCv2 profile draft)

From: Carl Knutsson <[email-masked]>
Date: Wed, 06 Dec 2006 14:33:30 +0100

Kristofer and Ghyslain,

In draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt, it is impossible to fully
compress an ESPnull encapsulated ESP flow. The decompressor will not be able to
parse the static chain for IP/ESPnull/IP/ESP.

When parsing the static chain the for the header above, the decompressor have no
way of knowing if the ESP null header is the end-point header or an encapsulating
header. My only conclusion is that only the IP/ESPnull part of the header can be
compressed for the ESP profile. Is this correct?

If not, please explain how to parse the static chain for this flow.

/Calle

esp_null(next_header_value)
   {
     UNCOMPRESSED {
       spi             [ 32 ];
       sequence_number [ 32 ];
     }

     CONTROL {
       nh_field [ 8 ];
     }

     DEFAULT {
       spi             =:= static;
       sequence_number =:= static;
       nh_field        =:= static;
     }

     COMPRESSED esp_static {
       nh_field =:= compressed_value(8, next_header_value) [ 8 ];
       spi      =:= irregular(32)                          [ 32 ];
     }
  }

esp(profile)
   {
     UNCOMPRESSED {
       spi             [ 32 ];
       sequence_number [ 32 ];
       ENFORCE(profile == PROFILE_ESP_0103);
     }

     DEFAULT {
       spi             =:= static;
       sequence_number =:= static;
     }

     COMPRESSED esp_static {
       spi =:= irregular(32) [ 32 ];
     }
  }

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

---

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Wed, 6 Dec 2006 16:06:11 +0100

Hi Calle,

thanks for catching that, this is actually a problem with the current
draft
that I hadn't noticed.

I see three alternative ways of solving this:
1) Add an extra indicator byte to espnull_static and to esp_static. To
keep
the compatibility of extension headers with ROHC-TCP and also to avoid
this
extra overhead, I'm not very fond of this solution.
2) Make some dirty tricks with the protocol numbers so that ESP NULL
uses
a different protocol number in the compressed headers and the
decompressor
maps this back to the actual protocol number. I think this can be made
to work,
but since it requires doing changes in the previous header in the chain
and
such evil, I don't think this is a good idea even though it is
efficient.
3) Disallow the ESP profile to compress ESPnull headers in the chain
preceeding
the "actual" ESP header. Not the most efficient way of doing things, but
since this is a corner-case, it would be in line with or design
principle
(keep it simple this time!) to go with this solution. If this is the
chosen
solution, I can ban this with a simple ENFORCE-statement.

So clearly, I'd say number 3 of the above.
Does anyone have any other smart ideas here or have any preferences
w.r.t.
a solution?

/Kristofer

Carl Knutsson <mailto:[email-masked]> wrote on den 6 december
2006 14:34 :

> Kristofer and Ghyslain,
> 
> In draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt, it is
> impossible to fully compress an ESPnull encapsulated ESP flow. The
> decompressor 
> will not be able to
> When parsing the static chain the for the header above, the
> decompressor have no way of knowing if the ESP null header is the
> end-point header 
> or an encapsulating
>   } }

---

From: Carl Knutsson <[email-masked]>
Date: Wed, 06 Dec 2006 16:37:21 +0100

Thanks Kristofer,

There is a fourth alternative. As in 1), but only add the field to esp_static.
This field must differ from all the allowed next header/protocol values of all the
IP extension headers. It will add one octet to all IR packets for the ESP profile.
This alternative does not affect the compatibility with the TCP profile.

I haven't decided which alternative I prefer. I will get back to the list when I
have:)

/Calle