IETF Logo Mail Archive

Re: [rohc] Last call comments for ROHCoIPsec: draft-ietf-rohc-hcoipsec, draft-ietf-rohc-ikev2-extensions-hcoipsec, draft-ietf-rohc-ipsec-extensions-hcoipsec

<Pasi.Eronen@nokia.com> Fri, 25 September 2009 16:03 UTC

Return-Path: <Pasi.Eronen@nokia.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 2CF653A67A7; Fri, 25 Sep 2009 09:03:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.456
X-Spam-Level:
X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 pZPSCIFz1XXV; Fri, 25 Sep 2009 09:03:32 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 1AD0F3A68D4; Fri, 25 Sep 2009 09:03:31 -0700 (PDT)
Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n8PG4ESY008714; Fri, 25 Sep 2009 19:04:32 +0300
Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 19:04:34 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 25 Sep 2009 19:04:29 +0300
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Fri, 25 Sep 2009 18:04:29 +0200
From: Pasi.Eronen@nokia.com
To: emreertekin.ietf@gmail.com
Date: Fri, 25 Sep 2009 18:04:24 +0200
Thread-Topic: [rohc] Last call comments for ROHCoIPsec: draft-ietf-rohc-hcoipsec, draft-ietf-rohc-ikev2-extensions-hcoipsec, draft-ietf-rohc-ipsec-extensions-hcoipsec
Thread-Index: Aco95BXABnbnwAZxQ7+ojAOrtDOyRAAFUQhA
Message-ID: <808FD6E27AD4884E94820BC333B2DB773C097582C6@NOK-EUMSG-01.mgdnok.nokia.com>
References: <e13d6ad60909202013q406f98e3w2ed4f9a896f3d9de@mail.gmail.com> <808FD6E27AD4884E94820BC333B2DB773C0965263C@NOK-EUMSG-01.mgdnok.nokia.com> <D73A14AC-5A34-484A-88C9-968839D2E48F@tzi.org> <808FD6E27AD4884E94820BC333B2DB773C09652723@NOK-EUMSG-01.mgdnok.nokia.com> <e13d6ad60909250628kca90682hfdd6ea35b1951ea4@mail.gmail.com>
In-Reply-To: <e13d6ad60909250628kca90682hfdd6ea35b1951ea4@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 25 Sep 2009 16:04:29.0723 (UTC) FILETIME=[DCFD76B0:01CA3DF9]
X-Nokia-AV: Clean
Cc: cabo@tzi.org, rohc@ietf.org, ietf@ietf.org
Subject: Re: [rohc] Last call comments for ROHCoIPsec: draft-ietf-rohc-hcoipsec, draft-ietf-rohc-ikev2-extensions-hcoipsec, draft-ietf-rohc-ipsec-extensions-hcoipsec
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: Fri, 25 Sep 2009 16:03:33 -0000

Emre Ertekin wrote:

> > Well, the current drafts don't specify any such behavior, so the
> > feature as it's currently written does not work. (Also, using the
> > ESP/AH sequence number this way would be very unusual -- there
> > might be some complications...)
> 
> If we include text that states this behavior, does this address your
> concern?

Depends on the text (certainly more than 1-2 sentences are needed
here)... but it's possible it could address my concern.

> FWIW, I could also think of deployment scenarios where packet
> reordering is minimal (e.g., ROHCOIPsec is instantiated over a single
> [bandwidth constrained] link).  Such scenarios may not even require
> the use of the ESP/AH sequence number to reconstruct ROHC segments.

Perhaps; but in general, IPsec runs over IP, and doesn't know about
the properties of the underlying links (even if it's only one hop,
not all links preserve order always).

Best regards,
Pasi

v2.23.0 | Report a Bug | By Email