Subject: [rohc] IP-ID of ROHCv2

From: "Lee, Jiwoong" <[email-masked]>
Date: Wed, 22 Jul 2009 11:13:20 -0700

Dear ROHC WG,

Today I want to raise a concern and learn your comments about one section of RFC 5225. I see a potential violation of transparency and integrity concept of compression in red colored sentence.

Basically IP-ID of tunneling headers is decided by the tunnel ingress/egress nodes but not by a compressor/decompressor pair in the middle of transit.  Does the red colored sentence require the overwriting of IP-ID field?

I guess it shouldn't. Otherwise it may cause non-conformance to security protocols.

Thank you,
Jiwoong

6.3.3.  IP-ID Behavior
   ...
   ROHCv2 profiles MUST NOT assign a sequential behavior (network byte
   order or byte-swapped) to any IP-ID but the one in the innermost IP
   header when compressing more than one level of IP headers.  This is
   because only the IP-ID of the innermost IP header is likely to have a
   sufficiently close correlation with the MSN to compress it as a
   sequentially changing field.  Therefore, a compressor MUST assign
   either the constant zero IP-ID or the random IP-ID behavior to
   tunneling headers.

---

From: Carl Knutsson <[email-masked]>
Date: Thu, 23 Jul 2009 08:30:09 +0200

Hi Jiwoong,

ROHCv2 is transparent for IP-ID. The IP-ID behavior specifies the
compression method used for the IPv4 identification field. It doesn't
change or modify the field in the incoming header.

The IP-ID behavior can be seen estimate of how the IPv4 identification
changes between packet in a flow. Even with the "wrong" IP-ID behavior,
the decompresssor will still recreate the field as arrived at the
compressor. A badly choosen IP-ID behavior, will decrease compression
efficiency.

Of course, in some scenarios, you may not be able to pick some of the
compress packet formats because they will fail according to the rules of
ROHC-FN.

Cheers,

/Carl Knutsson

Lee, Jiwoong wrote:
> Dear ROHC WG,
> 
>  
> 
> Today I want to raise a concern and learn your comments about one
> section of RFC 5225. I see a potential violation of transparency and
> integrity concept of compression in red colored sentence.
> 
>  
> 
> Basically IP-ID of tunneling headers is decided by the tunnel
> ingress/egress nodes but not by a compressor/decompressor pair in the
> middle of transit.  Does the red colored sentence require the
> overwriting of IP-ID field?
> 
>  
> 
> I guess it shouldn’t. Otherwise it may cause non-conformance to security
> protocols.
> 
>  
> 
> Thank you,
> 
> Jiwoong
> 
>  
> 
>  
> 
> 6.3.3.  IP-ID Behavior
> 
>    …
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rohc