Re: [rohc] IP-ID of ROHCv2

Carl Knutsson <carl.knutsson@effnet.com> Thu, 23 July 2009 07:08 UTC

Return-Path: <carl.knutsson@effnet.com>
X-Original-To: rohc@core3.amsl.com
Delivered-To: rohc@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01FEA3A68CB for <rohc@core3.amsl.com>; Thu, 23 Jul 2009 00:08:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QezRSD3-7-Q1 for <rohc@core3.amsl.com>; Thu, 23 Jul 2009 00:08:21 -0700 (PDT)
Received: from lists.levonline.com (lists.levonline.com [217.70.33.37]) by core3.amsl.com (Postfix) with ESMTP id 16C343A6894 for <rohc@ietf.org>; Thu, 23 Jul 2009 00:08:19 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by lists.levonline.com (Postfix) with ESMTP id 44D1A29C1F4; Thu, 23 Jul 2009 08:30:14 +0200 (CEST)
X-Virus-Scanned: By http://levonline.com - free virus scanning for all customers
Received: from lists.levonline.com ([127.0.0.1]) by localhost (lists.levonline.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2Rh0u3KZgoj; Thu, 23 Jul 2009 08:30:13 +0200 (CEST)
Received: from truck2.fordonnet.levonline.com (gw-uu-virtual.levonline.com [217.70.32.2]) by lists.levonline.com (Postfix) with ESMTP id EAD9129C1F0; Thu, 23 Jul 2009 08:30:12 +0200 (CEST)
Received: from [192.168.101.28] (c-6a0471d5.04-205-6c756c1.cust.bredbandsbolaget.se [213.113.4.106]) (authenticated bits=0) by truck2.fordonnet.levonline.com (8.12.11.20060308/8.12.11) with ESMTP id n6N6UBXH002276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jul 2009 08:30:12 +0200
Message-ID: <4A680371.5080503@effnet.com>
Date: Thu, 23 Jul 2009 08:30:09 +0200
From: Carl Knutsson <carl.knutsson@effnet.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: "Lee, Jiwoong" <jiwoongl@qualcomm.com>
References: <29F0770B56D6A94794A647432F9A9EF06B2A7D501C@NALASEXMB14.na.qualcomm.com>
In-Reply-To: <29F0770B56D6A94794A647432F9A9EF06B2A7D501C@NALASEXMB14.na.qualcomm.com>
X-Enigmail-Version: 0.95.7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Cc: "rohc@ietf.org" <rohc@ietf.org>
Subject: Re: [rohc] IP-ID of ROHCv2
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Robust Header Compression <rohc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rohc>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jul 2009 07:08:22 -0000

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
> 
>    …
> 
>    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.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Rohc mailing list
> Rohc@ietf.org
> https://www.ietf.org/mailman/listinfo/rohc