Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec

Julien Laganier <julien.ietf@gmail.com> Fri, 04 February 2011 23:48 UTC

Return-Path: <julien.ietf@gmail.com>
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36B493A69FA for <mext@core3.amsl.com>; Fri, 4 Feb 2011 15:48:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.576
X-Spam-Level:
X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 iQcf3p5FbKxd for <mext@core3.amsl.com>; Fri, 4 Feb 2011 15:48:25 -0800 (PST)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 0321A3A69DC for <mext@ietf.org>; Fri, 4 Feb 2011 15:48:24 -0800 (PST)
Received: by fxm9 with SMTP id 9so3166501fxm.31 for <mext@ietf.org>; Fri, 04 Feb 2011 15:51:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0O1RDw2YbPu8y0y+dS7LcNiA4tAdukbqCjEOUz9ynzw=; b=gKQClwnPM5V/VtrdqMVa/iZL05jXyfJFzEGzvrNEPuGQiKKDB4QU1tG1GA/jE2w3Jf +ZWaEKVzxhYi0WpGBVbEIxLj9M1d5jlzGF1Q31jc0gMPuEyNbj8WALQDS8nswr0M6p7Q wIGiMi2zmObbSnKs1x/I+WAKFtTwwegBEIi1Y=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CSb5kpuZTzCGO2qUZiPP09pgGrQCIv6SM3E3GWTOrs8/LTb47zw+Vb+JkRb+uuLkeJ 89kq/dn651UsERn/GdbTIhzH61Fzq4PgIIS5wsXWmlxVL5aj+Opv9msKZ+wKQZRrxN8+ ZcaHMtvaser8/gXphxYssjT37weKV3OSFMDXw=
MIME-Version: 1.0
Received: by 10.103.243.16 with SMTP id v16mr8076483mur.57.1296863510477; Fri, 04 Feb 2011 15:51:50 -0800 (PST)
Received: by 10.103.221.9 with HTTP; Fri, 4 Feb 2011 15:51:50 -0800 (PST)
In-Reply-To: <98A16B2D00B5724F81E80EF1927A0297040A7F@nasanexd01e.na.qualcomm.com>
References: <878vyarmku.fsf@natisbad.org> <C963527A.D013%basavaraj.patil@nokia.com> <98A16B2D00B5724F81E80EF1927A029703E3FB@nasanexd01e.na.qualcomm.com> <06CCEF13-4E11-474D-A25E-C1425D5B520A@gmail.com> <98A16B2D00B5724F81E80EF1927A029703EAD4@nasanexd01e.na.qualcomm.com> <98A16B2D00B5724F81E80EF1927A02970409A1@nasanexd01e.na.qualcomm.com> <185D5B42-0A88-4CDB-8FFF-B49FD52D6DD5@gmail.com> <98A16B2D00B5724F81E80EF1927A0297040A1E@nasanexd01e.na.qualcomm.com> <B7C82145-9053-447A-BB4F-AB17D371BF64@gmail.com> <98A16B2D00B5724F81E80EF1927A0297040A7F@nasanexd01e.na.qualcomm.com>
Date: Fri, 04 Feb 2011 15:51:50 -0800
Message-ID: <AANLkTin4yxm9CPPR+09MMTiHNaW98KA0ZKjLJ0ujdxSg@mail.gmail.com>
From: Julien Laganier <julien.ietf@gmail.com>
To: "Laganier, Julien" <julienl@qualcomm.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Jouni <jouni.nospam@gmail.com>, "Basavaraj.Patil@nokia.com" <Basavaraj.Patil@nokia.com>, "jan@go6.si" <jan@go6.si>, "mext@ietf.org" <mext@ietf.org>
Subject: Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Feb 2011 23:48:26 -0000

Jouni,

> Jouni wrote:
>>
>> Hmm.. we do handle SPIs differently and our "ESP" can be absent even if
>> UDP encap is used. Would that be an issue regarding the reuse of
>> existing formats?

The issue with reusing of the ESP syntax outside ESP is that it is
duplication of the same protocol functionality which goes against one
of the Architectural Principles of the Internet again: "If a previous
design, in the Internet context or elsewhere, has successfully solved
the same problem, choose the same solution unless there is a good
technical reason not to.  Duplication of the same protocol
functionality should be avoided as far as possible, without of course
using this argument to reject improvements.choose the same solution
unless there is a good technical reason not to"

So what is your good technical reason not to reuse IPsec ESP and
simply provide an underlying UDP encapsulation?

Also -- turning my earlier statements into questions in case it wasn't
clear I was expecting clarifications / answers :

On Fri, Jan 28, 2011 at 3:10 PM, Laganier, Julien <julienl@qualcomm.com> wrote:
> None of these two points explains to me why you have to duplicate ESP functionality:
>
> 1) You have chosen to handle SPI differently, but I don't know why.

So, why?

> 2) As to ESP being absent, if the goal is to not protect some of the user-plane traffic,
> you can use ESP-NULL, or just the UDP encap...

So why wouldn't that be sufficient?

--julien