Re: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec
"Laganier, Julien" <julienl@qualcomm.com> Fri, 28 January 2011 22:26 UTC
Return-Path: <julienl@qualcomm.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 6C8363A697E for <mext@core3.amsl.com>; Fri, 28 Jan 2011 14:26:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.415
X-Spam-Level:
X-Spam-Status: No, score=-106.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 c2-LItoUA0YU for <mext@core3.amsl.com>; Fri, 28 Jan 2011 14:26:43 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 7C6313A6939 for <mext@ietf.org>; Fri, 28 Jan 2011 14:26:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1296253790; x=1327789790; h=from:to:cc:subject:thread-topic:thread-index:date: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: x-originating-ip:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20Jouni=20<jouni.nospam@gmail.com>|CC:=20"Basavaraj. Patil@nokia.com"=20<Basavaraj.Patil@nokia.com>,=20"jan@go 6.si"=0D=0A=09<jan@go6.si>,=20"mext@ietf.org"=20<mext@iet f.org>,=20"arno@natisbad.org"=0D=0A=09<arno@natisbad.org> |Subject:=20RE:=20[MEXT]=20Call=20for=20WG=20adoption=20o f=09I-D:=0D=0A=20draft-korhonen-mext-mip6-altsec |Thread-Topic:=20[MEXT]=20Call=20for=20WG=20adoption=20of =09I-D:=0D=0A=20draft-korhonen-mext-mip6-altsec |Thread-Index:=20AQHLvzov3JMqMUYi50SJ29cdxJAzppPm9iVA |Date:=20Fri,=2028=20Jan=202011=2022:29:50=20+0000 |Message-ID:=20<98A16B2D00B5724F81E80EF1927A0297040A1E@na sanexd01e.na.qualcomm.com>|References:=20<878vyarmku.fsf@ natisbad.org>=0D=0A=20<C963527A.D013%basavaraj.patil@noki a.com>=0D=0A=20<98A16B2D00B5724F81E80EF1927A029703E3FB@na sanexd01e.na.qualcomm.com>=0D=0A=20<06CCEF13-4E11-474D-A2 5E-C1425D5B520A@gmail.com>=0D=0A=20<98A16B2D00B5724F81E80 EF1927A029703EAD4@nasanexd01e.na.qualcomm.com>=0D=0A=20<9 8A16B2D00B5724F81E80EF1927A02970409A1@nasanexd01e.na.qual comm.com>=0D=0A=20<185D5B42-0A88-4CDB-8FFF-B49FD52D6DD5@g mail.com>|In-Reply-To:=20<185D5B42-0A88-4CDB-8FFF-B49FD52 D6DD5@gmail.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|x-originating-ip:=20[172.30.39.5] |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=i2aLsPP90xWk2fkbKyApdCElAa/xNQbxYJJ/xpzdhYQ=; b=LWdczLjIieb4uW1BfhWyOk8qWbdiaPBYpbmLWXQ/969k/GOr1txt9sdV 4OpMM8qKRRoWEKl6Y1O0ePdUf0wEpz/NRsduXl4DYO38OyImZXDulkFqL 1ObQ54ZltwDGbZs8zjHwD/iI19wredUSFYZJhVNyiAPgs1bvREdgdpFG5 I=;
X-IronPort-AV: E=McAfee;i="5400,1158,6240"; a="72182487"
Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 28 Jan 2011 14:29:50 -0800
X-IronPort-AV: E=Sophos;i="4.60,392,1291622400"; d="scan'208";a="45539865"
Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/AES128-SHA; 28 Jan 2011 14:29:50 -0800
Received: from NASANEXD01E.na.qualcomm.com ([fe80::6555:8c37:4ee3:efc4]) by nasanexhc08.na.qualcomm.com ([::1]) with mapi id 14.01.0218.012; Fri, 28 Jan 2011 14:29:50 -0800
From: "Laganier, Julien" <julienl@qualcomm.com>
To: Jouni <jouni.nospam@gmail.com>
Thread-Topic: [MEXT] Call for WG adoption of I-D: draft-korhonen-mext-mip6-altsec
Thread-Index: AQHLvzov3JMqMUYi50SJ29cdxJAzppPm9iVA
Date: Fri, 28 Jan 2011 22:29:50 +0000
Message-ID: <98A16B2D00B5724F81E80EF1927A0297040A1E@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>
In-Reply-To: <185D5B42-0A88-4CDB-8FFF-B49FD52D6DD5@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.30.39.5]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 28 Jan 2011 14:27:27 -0800
Cc: "mext@ietf.org" <mext@ietf.org>, "jan@go6.si" <jan@go6.si>, "Basavaraj.Patil@nokia.com" <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: Fri, 28 Jan 2011 22:26:47 -0000
Either. IMHO both would be cleaner that the current approach. I understand the latter might also have some caveat but maybe they can be dealt with in an elegant manner, without introducing too much complexity, e.g., see Arnaud's m6t (http://tools.ietf.org/html/draft-ebalard-mext-m6t-02.txt) --julien Jouni wrote: > > Just a question for my clarification. Do you mean simply taking the UDP > encap + ESP format or also inheriting everything those respective RFCs > say about their processing etc? > > - JOuni > > > On Jan 28, 2011, at 9:18 PM, Laganier, Julien wrote: > > > Hello again, > > > > Thought that maybe making my question a bit more specific would help: > > > > So, why don't you simply define a UDP encapsulation to ESP, instead > of duplicating ESP functionality into your framework? > > > > --julien > > > > Laganier, Julien wrote: > >> > >> Hi Jouni, > >> > >> I understand you "follow the ESP format but feel no shame on > changing > >> it if we see a reason to do so", but I am (shamelessly ;) wondering > >> about the actual reason to do so, as per one of the famous > >> Architectural Principles of the Internet documented in RFC 1958: > >> > >> 3.2 If there are several ways of doing the same thing, choose one. > >> 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. > >> > >> Would you mind enlightening us? > >> > >> --julien > >> > >> jouni korhonen wrote: > >>> > >>> Few things. The draft already states that "The Padding, Pad Length, > >>> Next Header and ICV fields follow the rules of Section 2.4 to 2.8 > of > >>> [RFC4303] unless otherwise stated in this document." So, we follow > >>> the ESP format but feel no shame on changing it if we see a reason > >>> to do so. > >>> > >>> The reason why we chose to do it like this was two fold: 1) some > >>> ciphers etc when used would need ~equivalent encapsulation anyway. > >>> 2) if we had come up with our very own format the question on the > >>> list would have been "why not using RFC4303 encapsulation format". > >>> Actually.. the latter already happened offline. > >>> > >>> - Jouni > >>> > >>> > >>> On Jan 26, 2011, at 12:48 AM, Laganier, Julien wrote: > >>> > >>>> Hi Raj, > >>>> > >>>>> Inline: > >>>>> > >>>>> On 1/24/11 3:58 PM, "ext Arnaud Ebalard" <arno@natisbad.org> > >> wrote: > >>>>> > >>>>>> > >>>>>> To me, what the draft describes is a patchwork based on MIPv6, > >> ESP > >>> and > >>>>>> TLS. Instead of building on top of those protocols (read > >> modularity > >>>>> and > >>>>>> interoperability), it reuses (hijacks) various blocks of > >> associated > >>>>>> standards in a non-modular way. For instance, one has to > >>> reimplement > >>>>> ESP > >>>>>> in userspace to support the protocol. > >>>>> > >>>>> We are specifying an encapsulation method in the I-D. To say that > >>> one > >>>>> has to reimplement ESP in userspace is incorrect. > >>>> > >>>> The encapsulation format you have in the I-D is: > >>>> > >>>> 0 1 2 3 > >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> | | > >>>> : IPv4 or IPv6 header (src-addr=Xa, dst-addr=Ya) : > >>>> | | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> | | > >>>> : UDP header (src-port=Xp,dst-port=Yp) : > >>>> | | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > - > >> -- > >>> --- > >>>> |PType=8| SPI | > >>> ^Int. > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> |Cov- > >>>> | Sequence Number | > >>> |ered > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > >> - > >>> --- > >>>> | Payload Data* (variable) | > | > >>> ^ > >>>> : : > | > >>> | > >>>> | | > >>> |Conf. > >>>> + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> |Cov- > >>>> | | Padding (0-255 bytes) | > >>> |ered* > >>>> +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > >>> | > >>>> | | Pad Length | Next Header | > v > >>> v > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > - > >> -- > >>> --- > >>>> | Integrity Check Value-ICV (variable) | > >>>> : : > >>>> | | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> > >>>> Figure 7: UDP Encapsulated Binding Management Message Format > >>>> > >>>> Which looks like a copy/paste of the ESP specification [RFC4303]: > >>>> > >>>> 0 1 2 3 > >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > - > >> -- > >>> - > >>>> | Security Parameters Index (SPI) | > >>> ^Int. > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> |Cov- > >>>> | Sequence Number | > >>> |ered > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > >> - > >>> --- > >>>> | Payload Data* (variable) | > | > >>> ^ > >>>> ~ ~ > | > >>> | > >>>> | | > >>> |Conf. > >>>> + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> |Cov- > >>>> | | Padding (0-255 bytes) | > >>> |ered* > >>>> +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | > >>> | > >>>> | | Pad Length | Next Header | > v > >>> v > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > - > >> -- > >>> --- > >>>> | Integrity Check Value-ICV (variable) | > >>>> ~ ~ > >>>> | | > >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>> > >>>> Figure 1. Top-Level Format of an ESP Packet > >>>> > >>>> > >>>> So the question is: Is your intent to provide a UDP encapsulation > >>> format for the already specified ESP protocol, or to provide an > >>> alternative encapsulation format to ESP? > >>>> > >>>> --julien > >>>> _______________________________________________ > >>>> MEXT mailing list > >>>> MEXT@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/mext > >>> > >>> _______________________________________________ > >>> MEXT mailing list > >>> MEXT@ietf.org > >>> https://www.ietf.org/mailman/listinfo/mext > >> _______________________________________________ > >> MEXT mailing list > >> MEXT@ietf.org > >> https://www.ietf.org/mailman/listinfo/mext
- 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