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

Jouni <jouni.nospam@gmail.com> Mon, 07 February 2011 22:14 UTC

Return-Path: <jouni.nospam@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 EAE043A6E6D for <mext@core3.amsl.com>; Mon, 7 Feb 2011 14:14:47 -0800 (PST)
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 TYlzrB0s-KQm for <mext@core3.amsl.com>; Mon, 7 Feb 2011 14:14:47 -0800 (PST)
Received: from vs11.mail.saunalahti.fi (vs11.mail.saunalahti.fi [195.197.172.106]) by core3.amsl.com (Postfix) with ESMTP id B62F83A6D96 for <mext@ietf.org>; Mon, 7 Feb 2011 14:14:46 -0800 (PST)
Received: from saunalahti-vams (localhost [127.0.0.1]) by vs11.mail.saunalahti.fi (Postfix) with SMTP id 43B181A505C; Tue, 8 Feb 2011 00:14:50 +0200 (EET)
Received: from vs11.mail.saunalahti.fi ([127.0.0.1]) by vs11.mail.saunalahti.fi ([195.197.172.106]) with SMTP (gateway) id A026B340CAD; Tue, 08 Feb 2011 00:14:50 +0200
Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by vs11.mail.saunalahti.fi (Postfix) with ESMTP id 35DC81A505C; Tue, 8 Feb 2011 00:14:50 +0200 (EET)
Received: from a88-114-174-127.elisa-laajakaista.fi (a88-114-174-127.elisa-laajakaista.fi [88.114.174.127]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 75D2113966C; Tue, 8 Feb 2011 00:14:43 +0200 (EET)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Jouni <jouni.nospam@gmail.com>
In-Reply-To: <AANLkTi=xn7i_NNdu3QFuHWSj4CgQrsYuE_SSx8tqJHKs@mail.gmail.com>
Date: Tue, 08 Feb 2011 00:14:42 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <28A14846-F134-47E7-8A50-A0C30356DF2A@gmail.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> <FEF1DA1D-91DF-4AE4-8C10-7B12A4D4CF36@gmail.com> <AANLkTi=xn7i_NNdu3QFuHWSj4CgQrsYuE_SSx8tqJHKs@mail.gmail.com>
To: Julien Laganier <julien.ietf@gmail.com>
X-Mailer: Apple Mail (2.1082)
X-Antivirus: VAMS
Cc: "Basavaraj.Patil@nokia.com Patil" <Basavaraj.Patil@nokia.com>, Jouni <jouni.nospam@gmail.com>, Julien Laganier <julienl@qualcomm.com>, jan@go6.si, 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: Mon, 07 Feb 2011 22:14:48 -0000

Hello Julien,

On Feb 7, 2011, at 11:10 PM, Julien Laganier wrote:

> Hi Jouni,
> 
> On Sat, Feb 5, 2011 at 1:34 AM, jouni korhonen <jouni.nospam@gmail.com> wrote:
>> Hi Julien,
>> 
>> 
>> On Jan 29, 2011, at 1:10 AM, Laganier, Julien 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.
>> 
>> That was a design decision for easily to detect the type of the UDP payload. In some other cases folks have used algorithms, hash functions and such to encode more information into the SPI but we thought that would an too much. Therefore, we just dedicated few bits of the SPI for additional information.
> 
> Can't you use some bits at the beginning of the UDP payload instead of
> overloading the SPI semantic? If so that would remove the different
> SPI handling point.

Do you mean like RFC3948? And then e.g. reusing the non-esp marker place holder but just in different ports..? That could most likely work.

> 
>>> 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...
>> 
>> Well, yes-ish. However, if I decided to send a packet without being protected, then after dispatching the packet (that is based on our SPI with type information) why would I need to do any further processing on it? If you got ESP-NULL, you still need to do additional processing like integrity check (if I were to follow ESP rules). I admit it might be "minor" but still.
>> 
>> So, I'll just ask once more. If I were to use ESP format laid out in other RFC and reference to them to make sure the format processing goes right, is it OK for me then to go against all MUSTs and SHALLs for the rest of the ESP rules, for example when it comes to handling of ESP-NULL?
> 
> Forget about ESP-NULL. The solution to pass user-plane traffic
> unprotected is to pass it clear text over your UDP encapsulation. What

Good.

> is the problem with the rest of the ESP rules?

Not a problem with ESP rules per se but I just want to be sure that using RFC4303 as-is does not imply the rest of the stuff we purposely ran away.


- Jouni



> 
> --julien