Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec
Julien Laganier <julien.ietf@gmail.com> Wed, 09 February 2011 19:06 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 607303A6838 for <mext@core3.amsl.com>; Wed, 9 Feb 2011 11:06:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.52
X-Spam-Level:
X-Spam-Status: No, score=-3.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 NxK5kRguNzXL for <mext@core3.amsl.com>; Wed, 9 Feb 2011 11:06:00 -0800 (PST)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id EE2F23A6809 for <mext@ietf.org>; Wed, 9 Feb 2011 11:05:59 -0800 (PST)
Received: by ewy8 with SMTP id 8so370107ewy.31 for <mext@ietf.org>; Wed, 09 Feb 2011 11:06:09 -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=pXfjEMbkdZkbR1BPJLdVJ08fYWgvKAeT7x6TxipYFyI=; b=Q0HK6E3a0hZFXianrfp22b7Py+Msd1L5cEh43ppj3gixqkfxxRq93IdY/d4F+CzMTJ p/koKn1fuZcZ079dyQyOgQm3U2RHKIHpcbosRgARsP9zXhM+P/pWXQ+Y8gZY+zUsdLWQ 8Tg7hxN2Da06D/u9YPdqqdBwNoGqzk0gt6KWU=
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=Ftd+ixWmkfLGLKpBsXnSCRdlhitleDqDmQtAbR/RUXGo+jGKcnv0tpZq9WmZBrjwAr n1KFtZIxBvzXDfrN61DVS6xSCFSBgwQ4fcrNfEKA9gLVzN9OQzIpJXljND1SCZbD2vpa jyf42+iXM0IQC/I7MRmfguHwoX+C1v2W2Zmpo=
MIME-Version: 1.0
Received: by 10.103.108.10 with SMTP id k10mr3058653mum.39.1297278328119; Wed, 09 Feb 2011 11:05:28 -0800 (PST)
Received: by 10.103.221.9 with HTTP; Wed, 9 Feb 2011 11:05:25 -0800 (PST)
In-Reply-To: <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> <28A14846-F134-47E7-8A50-A0C30356DF2A@gmail.com>
Date: Wed, 09 Feb 2011 11:05:25 -0800
Message-ID: <AANLkTimYjUxXdpuBq6FG3L81gy2BPWdvF1BS7OnJhyVL@mail.gmail.com>
From: Julien Laganier <julien.ietf@gmail.com>
To: Jouni <jouni.nospam@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: mext@ietf.org, arnaud@natisbad.org, Julien Laganier <julienl@qualcomm.com>, jan@go6.si, "Basavaraj.Patil@nokia.com Patil" <Basavaraj.Patil@nokia.com>
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: Wed, 09 Feb 2011 19:06:01 -0000
Hello Jouni, Please see inline: On Mon, Feb 7, 2011 at 2:14 PM, Jouni <jouni.nospam@gmail.com> wrote: > 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. That's a possibility too. What I had in mind was that you define a new UDP encapsulation (as is done in Arnaud's M6t draft) on top of which you have IPsec SAs to protect DSMIPv6 signaling, and possibly different IPsec SAs to protect user plane. If user plane needs not to be protected it would just be layered cleartext on top of the UDP encapsulation. If you need to indicate which UDP packets contains what for the scheme to work, you can pick a fixed number of the first bytes of the payload to encode whatever you need. Then you define a new key exchange as you've been doing, based on TLS, but that key exchange establish IPsec SAs in the stack, instead of your protocol / software duplicating ESP functionality. Security wise it is safer, and implementation wise it is easier. On Linux, *BSD, SunOS, PFKEY is there. Having it in Linux already covers Android, Maemo, Meego, etc. If we do this, you simplify the interactions between IPsec and DSMIPv6. You no longer have interactions with IKEv2. Your system is modular and cleaner. I believe that it would satisfy the goals you set when working out this approach. >>>> 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. See above. If you provide the UDP encapsulation under IPsec ala M6t, IPsec processing and DSMIPv6 processing is decoupled to the point that your DSMIPv6 UDP tunneling code only need to check the CoA in outbound packets (any address for BU, only registered CoA for data.) There seems to be nothing left to run away from :-) Please let me know what you think. --julien
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Hidetoshi Yokota
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Laganier, Julien
- [MEXT] Call for WG adoption of I-D: draft-korhone… marcelo bagnulo braun
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Jan Zorz @ go6.si
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Arnaud Ebalard
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Basavaraj.Patil
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Behcet Sarikaya
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Jan Zorz @ go6.si
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Arnaud Ebalard
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… jouni korhonen
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Domagoj Premec
- [MEXT] IRON - a new approach to mobility manageme… Templin, Fred L
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Laganier, Julien
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Suresh Krishnan
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Ahmad Muhanna
- Re: [MEXT] Call for WG adoption ofI-D: draft-korh… Templin, Fred L
- Re: [MEXT] IRON - a new approach to mobility mana… Templin, Fred L
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Jouni
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Laganier, Julien
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Laganier, Julien
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Jouni
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Laganier, Julien
- Re: [MEXT] IRON - a new approach to mobility mana… Templin, Fred L
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… liu dapeng
- Re: [MEXT] IRON - a new approach to mobility mana… Templin, Fred L
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Julien Laganier
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… jouni korhonen
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Julien Laganier
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Jouni
- Re: [MEXT] Call for WG adoption of I-D: draft-kor… Julien Laganier