From julien.ietf@gmail.com Fri Feb 4 15:48:26 2011 Return-Path: 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 ; 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 ; 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 ; Fri, 4 Feb 2011 15:48:24 -0800 (PST) Received: by fxm9 with SMTP id 9so3166501fxm.31 for ; 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> <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> <98A16B2D00B5724F81E80EF1927A0297040A7F@nasanexd01e.na.qualcomm.com> Date: Fri, 4 Feb 2011 15:51:50 -0800 Message-ID: From: Julien Laganier To: "Laganier, Julien" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Jouni , "Basavaraj.Patil@nokia.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=A0there 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 wr= ote: > None of these two points explains to me why you have to duplicate ESP fun= ctionality: > > 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 From jouni.nospam@gmail.com Sat Feb 5 01:31:10 2011 Return-Path: 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 882583A68A2 for ; Sat, 5 Feb 2011 01:31:10 -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 XjOAvMbA22YE for ; Sat, 5 Feb 2011 01:31:08 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id A12513A6888 for ; Sat, 5 Feb 2011 01:31:07 -0800 (PST) Received: by bwz12 with SMTP id 12so3861399bwz.31 for ; Sat, 05 Feb 2011 01:34:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=go3WAES5yAppDVvZaqb5+PPNuu3aNPgYwu10qXkOhxo=; b=DTESK0LddNruACOLEO8hL864ussDX5WD+xOLnRUy9l8J15G7XM9KlyceGW0Yy633H7 KFMc5a7MuYvnUpKFSvtLm5j+NNVz8Uh3wDaAmYyaC7cLKhf7g0FhBJ3PCTubgvSNDWmP nXIaeGXOYAxr4WWqB9TB6iG+V8JF7XaIEVSPo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=JbMga9cjmQXJT+FQcGBdRXaZZkHChkjpStQ2xp4K3pS4Ie4W/1u9Yy1ZEidT+Mttjx wESAnmORP3Z2kznhyeYZHTObp3KB28jRVXv459A+gc3dRf/wUN7Js9SfP4ZO/LrLkaZa dNlgrC1M6ywktwN5LY/4zuqQFRkHBVzbUwqDY= Received: by 10.204.59.8 with SMTP id j8mr12447850bkh.26.1296898472418; Sat, 05 Feb 2011 01:34:32 -0800 (PST) Received: from [192.168.0.82] (c83-249-112-207.bredband.comhem.se [83.249.112.207]) by mx.google.com with ESMTPS id 12sm884635bki.19.2011.02.05.01.34.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 05 Feb 2011 01:34:31 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: <98A16B2D00B5724F81E80EF1927A0297040A7F@nasanexd01e.na.qualcomm.com> Date: Sat, 5 Feb 2011 11:34:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <878vyarmku.fsf@natisbad.org> <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> <98A16B2D00B5724F81E80EF1927A0297040A7F@nasanexd01e.na.qualcomm.com> To: "Laganier, Julien" X-Mailer: Apple Mail (2.1078) Cc: "mext@ietf.org" , "jan@go6.si" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Feb 2011 09:31:10 -0000 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: >=20 > 1) You have chosen to handle SPI differently, but I don't know why.=20 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. > 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? - JOuni >=20 > --julien >=20 > None of the above explains why you need to=20 >=20 > Jouni wrote: >>=20 >> 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? >>=20 >> - Jouni >>=20 >>=20 >> On Jan 29, 2011, at 12:29 AM, Laganier, Julien wrote: >>=20 >>> Either. >>>=20 >>> 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) >>>=20 >>> --julien >>>=20 >>> Jouni wrote: >>>>=20 >>>> 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? >>>>=20 >>>> - JOuni >>>>=20 >>>>=20 >>>> On Jan 28, 2011, at 9:18 PM, Laganier, Julien wrote: >>>>=20 >>>>> Hello again, >>>>>=20 >>>>> Thought that maybe making my question a bit more specific would >> help: >>>>>=20 >>>>> So, why don't you simply define a UDP encapsulation to ESP, = instead >>>> of duplicating ESP functionality into your framework? >>>>>=20 >>>>> --julien >>>>>=20 >>>>> Laganier, Julien wrote: >>>>>>=20 >>>>>> Hi Jouni, >>>>>>=20 >>>>>> 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: >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> Would you mind enlightening us? >>>>>>=20 >>>>>> --julien >>>>>>=20 >>>>>> jouni korhonen wrote: >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> - Jouni >>>>>>>=20 >>>>>>>=20 >>>>>>> On Jan 26, 2011, at 12:48 AM, Laganier, Julien wrote: >>>>>>>=20 >>>>>>>> Hi Raj, >>>>>>>>=20 >>>>>>>>> Inline: >>>>>>>>>=20 >>>>>>>>> On 1/24/11 3:58 PM, "ext Arnaud Ebalard" >>>>>> wrote: >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> We are specifying an encapsulation method in the I-D. To say >> that >>>>>>> one >>>>>>>>> has to reimplement ESP in userspace is incorrect. >>>>>>>>=20 >>>>>>>> The encapsulation format you have in the I-D is: >>>>>>>>=20 >>>>>>>> 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=3DXa, dst- >> addr=3DYa) : >>>>>>>> | >> | >>>>>>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> + >>>>>>>> | >> | >>>>>>>> : UDP header (src-port=3DXp,dst- >> port=3DYp) : >>>>>>>> | >> | >>>>>>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> + >>>> - >>>>>> -- >>>>>>> --- >>>>>>>> |PType=3D8| 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) >> | >>>>>>>> : >> : >>>>>>>> | >> | >>>>>>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> + >>>>>>>>=20 >>>>>>>> Figure 7: UDP Encapsulated Binding Management Message Format >>>>>>>>=20 >>>>>>>> Which looks like a copy/paste of the ESP specification >> [RFC4303]: >>>>>>>>=20 >>>>>>>> 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) >> | >>>>>>>> ~ >> ~ >>>>>>>> | >> | >>>>>>>> = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> + >>>>>>>>=20 >>>>>>>> Figure 1. Top-Level Format of an ESP Packet >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> 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? >>>>>>>>=20 >>>>>>>> --julien >>>>>>>> _______________________________________________ >>>>>>>> MEXT mailing list >>>>>>>> MEXT@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/mext >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> 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 >>>=20 >=20 From julien.ietf@gmail.com Mon Feb 7 13:10:40 2011 Return-Path: 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 555053A6F2E for ; Mon, 7 Feb 2011 13:10:40 -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 cZgq+h-awUT1 for ; Mon, 7 Feb 2011 13:10:37 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 61C173A6F2C for ; Mon, 7 Feb 2011 13:10:37 -0800 (PST) Received: by eyd10 with SMTP id 10so2879564eyd.31 for ; Mon, 07 Feb 2011 13:10:41 -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=TbW27BFfAuutL4P1xE4eLamegiS3+1Ptq/h201mRvD0=; b=AFc0oD9IDra9hAC7yvobY2vuNeuKAvz7Kf6pwr90EiDyYeRGMmqSneVNUN/F51sOHs d4rIktGcQksEvcNqMIQgXuSVwS+QKE4bWFu/9OmMW5VfVES9dWwQgTrByhsY+I4KfRRR R3bZhsHFrtCnREtW8VuYUMCQFHSe7KQMvnAaA= 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=lC3khJSl/D5xW5z9+AYE81Uj7ksfV1uzh3nP90xRu7/6h3407UDkRM45itYUGknm3m TjujYsahS1tuRxH/qat0PSVjRaKzq+tfNwKqIrnKSOmclA8piUyaRj4EIF/OyL2+/IDH FlWeKnGoY3C/pIO6l5GJCR0QOeZUhQPcd2AI0= MIME-Version: 1.0 Received: by 10.103.233.4 with SMTP id k4mr11438782mur.129.1297113041409; Mon, 07 Feb 2011 13:10:41 -0800 (PST) Received: by 10.103.221.9 with HTTP; Mon, 7 Feb 2011 13:10:41 -0800 (PST) In-Reply-To: References: <878vyarmku.fsf@natisbad.org> <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> <98A16B2D00B5724F81E80EF1927A0297040A7F@nasanexd01e.na.qualcomm.com> Date: Mon, 7 Feb 2011 13:10:41 -0800 Message-ID: From: Julien Laganier To: jouni korhonen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Basavaraj.Patil@nokia.com" , "Laganier, Julien" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 21:10:40 -0000 Hi Jouni, On Sat, Feb 5, 2011 at 1:34 AM, jouni korhonen wro= te: > 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 fu= nctionality: >> >> 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 paylo= ad. 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 m= uch. Therefore, we just dedicated few bits of the SPI for additional inform= ation. 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. >> 2) As to ESP being absent, if the goal is to not protect some of the use= r-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 prote= cted, 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 g= ot ESP-NULL, you still need to do additional processing like integrity chec= k (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 othe= r 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 is the problem with the rest of the ESP rules? --julien From jouni.nospam@gmail.com Mon Feb 7 14:14:47 2011 Return-Path: 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 ; 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 ; 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 ; 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 In-Reply-To: Date: Tue, 8 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> <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> <98A16B2D00B5724F81E80EF1927A0297040A7F@nasanexd01e.na.qualcomm.com> To: Julien Laganier X-Mailer: Apple Mail (2.1082) X-Antivirus: VAMS Cc: "Basavaraj.Patil@nokia.com Patil" , Jouni , Julien Laganier , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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, >=20 > On Sat, Feb 5, 2011 at 1:34 AM, jouni korhonen = wrote: >> Hi Julien, >>=20 >>=20 >> On Jan 29, 2011, at 1:10 AM, Laganier, Julien wrote: >>=20 >>> None of these two points explains to me why you have to duplicate = ESP functionality: >>>=20 >>> 1) You have chosen to handle SPI differently, but I don't know why. >>=20 >> 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. >=20 > 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. >=20 >>> 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... >>=20 >> 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. >>=20 >> 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? >=20 > 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 >=20 > --julien From jouni.nospam@gmail.com Tue Feb 8 03:49:33 2011 Return-Path: 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 C0AD63A7121 for ; Tue, 8 Feb 2011 03:49:33 -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 4CX2HQlmCf-j for ; Tue, 8 Feb 2011 03:49:33 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id A90323A6EDA for ; Tue, 8 Feb 2011 03:49:32 -0800 (PST) Received: by eyd10 with SMTP id 10so3138765eyd.31 for ; Tue, 08 Feb 2011 03:49:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:cc:to:mime-version:x-mailer; bh=tKBy+0GQXzA77qlZXBExwj/7JuN/FZdGLxkbtCKF5Ug=; b=EfYq21KhxaQWmeY608HuYtqQH5Qn5Jz22lOEGfrHPF5/vUYxFcOdlTtbEEqtfnDhgG TgJZ9+jeUD9lcJFkcO39x03ynTuokzIcT2lPYcV7xYZujNkWwiD5z6gSy13fX1/+J/L1 zIhYi+Jn3Bzf9TuY6I3+oRSF8UopkHh3bxNt0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; b=hsXLMeJdpbMUZi31BQu8l5L0TCkbnj0J+FkNcOCPP1o7b3KSrLWJvaqGDN/cp0m+/R Olcp9uoOCypAKoOWZjpy+XWuHIC8/pWxC/IHwao6PvP9ep8sgVWICfA/rSfWNfWRusQi IrWbAc1vdsWGgCmYGJKzdxTaOU7AVFzIsjlqc= Received: by 10.14.119.16 with SMTP id m16mr1257495eeh.8.1297165778570; Tue, 08 Feb 2011 03:49:38 -0800 (PST) Received: from [10.255.133.33] ([192.100.123.77]) by mx.google.com with ESMTPS id b52sm3939009eei.13.2011.02.08.03.49.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 08 Feb 2011 03:49:37 -0800 (PST) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 8 Feb 2011 13:49:32 +0200 Message-Id: To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Cc: Julien Laganier Subject: [MEXT] review of draft-laganier-mext-cga-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 11:49:33 -0000 Hello, In Beijing I volunteered to review draft-laganier-mext-cga-01. Nits: o Some RFC2119 inconsistencies - s/MUST not/MUST NOT o Some typos - s/mecanism/mechanism (several times) - s/AGent/Agent - s/Crypgraphically/Cryptographically o Abstract and Introduction are the ~same.. I would expect the abstract to be a short abstract. Comments: I would summarize the draft as "the ingredients are there but the presentation is incomplete". Basically, the idea is imho workable and actually rather nice. I did not spot any immediate technical show stopper. However, the draft definitely *needs* an update to make its idea and protocol aspect to become readable. Current referencing around few RFCs and assuming the reader to remember every detail of reused options is quite overwhelming. At minimum exact pointers to specific sections in referenced RFCs would help a lot. Especially I would like to see more text regarding the constriction of the BA message. For example exactly stating which mobility options go where.. Also the draft should be clear how the proposed solution affects route optimization. Now it is not clear whether I would need to do route optimization based on RFC3775 or RFC4866. Section 8 regarding IPv4 support does not really seem to fit in this document. Not at least how it is currently presented. - Jouni From Internet-Drafts@ietf.org Tue Feb 8 11:15:02 2011 Return-Path: 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 5E12D3A682F; Tue, 8 Feb 2011 11:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 8uMe1ZJ7IocY; Tue, 8 Feb 2011 11:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9802D3A683C; Tue, 8 Feb 2011 11:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110208191501.24763.12970.idtracker@localhost> Date: Tue, 08 Feb 2011 11:15:01 -0800 Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-11.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobility Support in IPv6 Author(s) : C. Perkins, et al. Filename : draft-ietf-mext-rfc3775bis-11.txt Pages : 176 Date : 2011-02-08 This document specifies Mobile IPv6, a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-rfc3775bis-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-08110400.I-D@ietf.org> --NextPart-- From charles.perkins@earthlink.net Tue Feb 8 11:22:02 2011 Return-Path: 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 0CD203A680A for ; Tue, 8 Feb 2011 11:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 172PBx44z9zj for ; Tue, 8 Feb 2011 11:22:01 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by core3.amsl.com (Postfix) with ESMTP id EBFE13A672E for ; Tue, 8 Feb 2011 11:21:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=aSNSzjwgf7h5xjFnSPpIzpvPG7YMj+HaVIqaXTvDQ0EQ1P8w7YfrffU6taKiWMpz; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [138.111.58.2] (helo=[172.17.96.31]) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Pmt8Z-000476-3t for mext@ietf.org; Tue, 08 Feb 2011 14:22:07 -0500 Message-ID: <4D5197DD.6010708@earthlink.net> Date: Tue, 08 Feb 2011 11:22:05 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: mext@ietf.org References: <20110208191501.24763.12970.idtracker@localhost> In-Reply-To: <20110208191501.24763.12970.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52fdf7fad98dfb62970287c7174f832662350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Subject: Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-11.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:22:02 -0000 Hello folks, Please wait a few minutes, while I check to see whether or not draft-ietf-mext-rfc3775bis-11.txt might be missing a few minor updates. I'll write the mailing list again soon once I'm able to verify. Regards, Charlie P. On 2/8/2011 11:15 AM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. > > > Title : Mobility Support in IPv6 > Author(s) : C. Perkins, et al. > Filename : draft-ietf-mext-rfc3775bis-11.txt > Pages : 176 > Date : 2011-02-08 > > This document specifies Mobile IPv6, a protocol which allows nodes to > remain reachable while moving around in the IPv6 Internet. Each > mobile node is always identified by its home address, regardless of > its current point of attachment to the Internet. While situated away > from its home, a mobile node is also associated with a care-of > address, which provides information about the mobile node's current > location. IPv6 packets addressed to a mobile node's home address are > transparently routed to its care-of address. The protocol enables > IPv6 nodes to cache the binding of a mobile node's home address with > its care-of address, and to then send any packets destined for the > mobile node directly to it at this care-of address. To support this > operation, Mobile IPv6 defines a new IPv6 protocol and a new > destination option. All IPv6 nodes, whether mobile or stationary, > can communicate with mobile nodes. This document obsoletes RFC 3775. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-11.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From julien.ietf@gmail.com Tue Feb 8 11:23:48 2011 Return-Path: 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 6CAA23A681B; Tue, 8 Feb 2011 11:23:48 -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 tI49DR7-WpoX; Tue, 8 Feb 2011 11:23:47 -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 1D31B3A672E; Tue, 8 Feb 2011 11:23:46 -0800 (PST) Received: by ewy8 with SMTP id 8so3511197ewy.31 for ; Tue, 08 Feb 2011 11:23:54 -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=CSF6U3zmMsCfhvjCK3aAWbvSwvLABjYzH7oSOhARRG8=; b=UnNf5VJT6toOnwvpGyM2BqH8nGENlAkibiEYS3it7dwNgrp22FN5Y87BXSkTKsrQkn Cg8pVDXfA4xPObWsh7RYNa4woFFpbSVSU2waDyxuUbRvhg5pXvzTq4nExSjvv/M8kbA7 lqMuEv6z3wtlsYeXc7XVg8TEiREaeyxeDp/3A= 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=gGmX9WnOiL+NswZ8DplYzG3/6HCW+ypOLnX9mH6hlDsNJplgWMhcFndbhDa/Wqt0vr q0EKP6wpomI88r26K31YHMqQ8t6TW0isrZBNQ9kbuh6Q0E9Xmjwj9s31Rd3RklUEBpkE IrScyEh6MQju7f4Z06hpibP3g4wxutEG6Wvpg= MIME-Version: 1.0 Received: by 10.103.199.3 with SMTP id b3mr1832628muq.93.1297193033701; Tue, 08 Feb 2011 11:23:53 -0800 (PST) Received: by 10.103.221.9 with HTTP; Tue, 8 Feb 2011 11:23:53 -0800 (PST) In-Reply-To: <20110208191501.24763.12970.idtracker@localhost> References: <20110208191501.24763.12970.idtracker@localhost> Date: Tue, 8 Feb 2011 11:23:53 -0800 Message-ID: From: Julien Laganier To: charles.perkins@earthlink.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org, i-d-announce@ietf.org Subject: Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-11.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:23:48 -0000 Charlie - What triggered moving the IKEv2 reference moved from normative to informati= ve? --julien On Tue, Feb 8, 2011 at 11:15 AM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Mobility EXTensions for IPv6 Working Gro= up of the IETF. > > > =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Mobility Support in IPv6 > =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : C. Perkins, et al. > =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-mext-rfc3775bis-11.tx= t > =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 176 > =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-02-08 > > This document specifies Mobile IPv6, a protocol which allows nodes to > remain reachable while moving around in the IPv6 Internet. =A0Each > mobile node is always identified by its home address, regardless of > its current point of attachment to the Internet. =A0While situated away > from its home, a mobile node is also associated with a care-of > address, which provides information about the mobile node's current > location. =A0IPv6 packets addressed to a mobile node's home address are > transparently routed to its care-of address. =A0The protocol enables > IPv6 nodes to cache the binding of a mobile node's home address with > its care-of address, and to then send any packets destined for the > mobile node directly to it at this care-of address. =A0To support this > operation, Mobile IPv6 defines a new IPv6 protocol and a new > destination option. =A0All IPv6 nodes, whether mobile or stationary, > can communicate with mobile nodes. =A0This document obsoletes RFC 3775. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-11.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From charles.perkins@earthlink.net Tue Feb 8 11:47:25 2011 Return-Path: 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 ACD0F3A67C3 for ; Tue, 8 Feb 2011 11:47:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 1Z0sFpO1BC9S for ; Tue, 8 Feb 2011 11:47:24 -0800 (PST) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id A92453A681B for ; Tue, 8 Feb 2011 11:47:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=iYWlIFfOHWQSpMj0HmDLDILjQpP84Z05CwkzyanZZjzPgX9FS5u9fIPzA4amt013; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [138.111.58.2] (helo=[172.17.96.31]) by elasmtp-galgo.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1PmtXA-0003zy-3I; Tue, 08 Feb 2011 14:47:32 -0500 Message-ID: <4D519DD2.5030700@earthlink.net> Date: Tue, 08 Feb 2011 11:47:30 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Julien Laganier References: <20110208191501.24763.12970.idtracker@localhost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f52d384c8185359a369bb013c2dd5f6f135350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 138.111.58.2 Cc: mext@ietf.org Subject: Re: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-11.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 19:47:25 -0000 Hello Julien, That was one of the results of the mistake I alluded to in my earlier email to the list. It's fixed now, but not yet submitted while I'm checking some other details. Regards, Charlie P. On 2/8/2011 11:23 AM, Julien Laganier wrote: > Charlie - > > What triggered moving the IKEv2 reference moved from normative to informative? > > --julien > > On Tue, Feb 8, 2011 at 11:15 AM, wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. >> >> >> Title : Mobility Support in IPv6 >> Author(s) : C. Perkins, et al. >> Filename : draft-ietf-mext-rfc3775bis-11.txt >> Pages : 176 >> Date : 2011-02-08 >> >> This document specifies Mobile IPv6, a protocol which allows nodes to >> remain reachable while moving around in the IPv6 Internet. Each >> mobile node is always identified by its home address, regardless of >> its current point of attachment to the Internet. While situated away >> from its home, a mobile node is also associated with a care-of >> address, which provides information about the mobile node's current >> location. IPv6 packets addressed to a mobile node's home address are >> transparently routed to its care-of address. The protocol enables >> IPv6 nodes to cache the binding of a mobile node's home address with >> its care-of address, and to then send any packets destined for the >> mobile node directly to it at this care-of address. To support this >> operation, Mobile IPv6 defines a new IPv6 protocol and a new >> destination option. All IPv6 nodes, whether mobile or stationary, >> can communicate with mobile nodes. This document obsoletes RFC 3775. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-11.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> >> > From Internet-Drafts@ietf.org Tue Feb 8 14:15:02 2011 Return-Path: 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 3328C3A68A6; Tue, 8 Feb 2011 14:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 pxfUuXDaAbNq; Tue, 8 Feb 2011 14:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E2753A6884; Tue, 8 Feb 2011 14:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110208221501.15294.47303.idtracker@localhost> Date: Tue, 08 Feb 2011 14:15:01 -0800 Cc: mext@ietf.org Subject: [MEXT] I-D Action:draft-ietf-mext-rfc3775bis-12.txt X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 22:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility EXTensions for IPv6 Working Group of the IETF. Title : Mobility Support in IPv6 Author(s) : C. Perkins, et al. Filename : draft-ietf-mext-rfc3775bis-12.txt Pages : 177 Date : 2011-02-08 This document specifies Mobile IPv6, a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, can communicate with mobile nodes. This document obsoletes RFC 3775. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mext-rfc3775bis-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mext-rfc3775bis-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-08140751.I-D@ietf.org> --NextPart-- From jouni.nospam@gmail.com Wed Feb 9 02:40:28 2011 Return-Path: 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 C165B3A6921 for ; Wed, 9 Feb 2011 02:40:28 -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 RSPMopP7Rmzr for ; Wed, 9 Feb 2011 02:40:28 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id A8E0E3A67DF for ; Wed, 9 Feb 2011 02:40:27 -0800 (PST) Received: by bwz12 with SMTP id 12so858476bwz.31 for ; Wed, 09 Feb 2011 02:40:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=gm1+Kl8UgJH88Xa4pvE6O+jcBQTC/+zzD2o+GoOQkls=; b=Vnj5CnRUI/PCcuCFdMeRS0sgAu53N87OPxCr8j3z7AOFycETG8KEZdLulMkOh0Z3w+ prito0zVC4Ped66duZdEVer+vchjDtMRz4RYer2NKDf4B7917iSnay5zBraWdjXGqNlc eIgz2Uu7SYUtamlkm7dOLXD8unlP82J90sXXs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=mPwkFxYiE9TgUz+QNL24X4qzdFq8C+LfeLg5pwn7tTisIYdOVgPoG7fYYTanCHUfDL YKd4wS+HqfI9p5S4gm4z/6sp0hSGeB81HtUMON85Ap2vKZJp/LsKtxSqVz8+LJVUrxfk UxLGHfyHppCkmqeUSws0+bVoaLuY4f/0dlrxI= Received: by 10.204.52.138 with SMTP id i10mr12786986bkg.23.1297248034644; Wed, 09 Feb 2011 02:40:34 -0800 (PST) Received: from a88-112-143-79.elisa-laajakaista.fi (a88-112-143-79.elisa-laajakaista.fi [88.112.143.79]) by mx.google.com with ESMTPS id z18sm107875bkf.20.2011.02.09.02.40.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 02:40:33 -0800 (PST) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Feb 2011 12:40:29 +0200 Message-Id: To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [MEXT] review of draft-gundavelli-mext-dsmip-ipv4-overlap-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 10:40:28 -0000 Hi, In beijing meeting I volunteered to review = draft-gundavelli-mext-dsmip-ipv4-overlap-01. Some content concerning comments follow. address is not uniquely assigned to a single mobile node. The home agent MUST make the forwarding decision based on the context identifier that is associated with the received packet and the context identifier in the Binding Cache entry. This is an implementation issue.. entirely. It can be a context = identifier (any kind that suffices for the purpose) or the whole HA = instance can be running in a separate routing context. o In deployments where the home agent is supporting hosted home agent service model, the context identifier field of the Binding Cache entry MUST be set to the identifier of the tunnel established between the home agent and the enterprise gateway. Implementation issue again. I do not see why the HA or binding cache = internal implementation is enforced here using RFC2119 language.=20 Actually most material in Section 4.1.2. Signaling Considerations are = purely internal to HA implementation. I do not really see a compelling = reason why to document these. In past when we standardized GRE encap for = PMIP6 that had similar concerns regarding the LMA. However, that was a = different case as we got an impact also on wire and specification of new = signaling. In Section 4.2. Mobile Node Considerations it is stated: This specification does not introduce any new considerations for the mobile node implementation. The IPv4 private address assigned from If this document has no on wire protocol implications, then there is no = interoperability issues from the protocol point of view. The HA product = either supports overlapping private addresses or does not. Therefore, I = cannot really see why the document aims to be a Proposed Standard? It = could be Informational if these points of the HA internal workings has = to be documented. So, I would say that Informational without any RFC2119 = language is OK. However, the assigned addresses MUST be unique within the 3GPP APN scope (Ex: @internetsvcs.cisco.com). The default value for this I would give a reference to APN and a short description of it as APN is = such an alien concept within IETF. Also the example = "@internetsvcs.cisco.com" is incorrect if it attempts to give an example = of an APN (there is no '@' in APN). - Jouni= From julien.ietf@gmail.com Wed Feb 9 11:06:01 2011 Return-Path: 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 ; 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 ; 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 ; Wed, 9 Feb 2011 11:05:59 -0800 (PST) Received: by ewy8 with SMTP id 8so370107ewy.31 for ; 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> <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> <98A16B2D00B5724F81E80EF1927A0297040A7F@nasanexd01e.na.qualcomm.com> <28A14846-F134-47E7-8A50-A0C30356DF2A@gmail.com> Date: Wed, 9 Feb 2011 11:05:25 -0800 Message-ID: From: Julien Laganier To: Jouni Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org, arnaud@natisbad.org, Julien Laganier , jan@go6.si, "Basavaraj.Patil@nokia.com Patil" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 = 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 pay= load. In some other cases folks have used algorithms, hash functions and su= ch 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 info= rmation. >> >> 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 u= ser-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 pro= tected, then after dispatching the packet (that is based on our SPI with ty= pe 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 ch= eck (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 ot= her 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 t= he 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 From jouni.nospam@gmail.com Wed Feb 9 13:19:39 2011 Return-Path: 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 76FDE3A67F0 for ; Wed, 9 Feb 2011 13:19:39 -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 8Q4ZIvqoRFsJ for ; Wed, 9 Feb 2011 13:19:38 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 5DC783A67C3 for ; Wed, 9 Feb 2011 13:19:38 -0800 (PST) Received: by bwz12 with SMTP id 12so1524949bwz.31 for ; Wed, 09 Feb 2011 13:19:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=YY4q7i+gMd+ZZDhNuBllV5axVTEapOjfrGdmXXclW0M=; b=wnTNxfyWB+x4H/RCXozuy/67AVqXxlzSihqIAas8psPiytn9Mz19ETzoynSzNnhjZq IVsucqID8kpuC2UcOktgkDqC9GA9ARGSNP+jHSU2wyh+hVvnH2YFW4eePCpNh5PtuoDm wJNYyLUQa+xiEw+aLbv3PWL09E03yK6BNPlls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=pacLzuYFba4njDyiFFE0s24ujmAYHo4dEHqT5evlZxsPNmS8X7Fgy3g9cYfuU1D160 YUCdWcAp6Y1708E1j/xmQp4w4/pEvB9JZtDaiYbHdk8Vvb9CG/puNpivK+mLIOwx84Lf eDJc4JKrtM9WMDByr75QKCNem/sPTBL8ktuDI= Received: by 10.204.0.65 with SMTP id 1mr7897160bka.111.1297286387638; Wed, 09 Feb 2011 13:19:47 -0800 (PST) Received: from a88-112-143-79.elisa-laajakaista.fi (a88-112-143-79.elisa-laajakaista.fi [88.112.143.79]) by mx.google.com with ESMTPS id rc9sm511817bkb.14.2011.02.09.13.19.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 13:19:46 -0800 (PST) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Feb 2011 23:19:45 +0200 Message-Id: <5ECC386B-CD36-45AE-943D-01F39264242D@gmail.com> To: mext@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [MEXT] review of draft-bajko-mext-sod-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 21:19:39 -0000 Hi, In Beijing meeting I volunteered to review draft-bajko-mext-sod-01. I'll skip the editorials and such. The text would need some editing for = sure ;) * Section 1 As per the current MIP6 [RFC3775] specification, only the MN has the ability to enable security for user-plane traffic. The HA has no ability to force the MN to secure user traffic. Strictly based on rfc3775 yes. However, if IKE is used as the key = management protocol, then it is possible to have some level of security = level negotiation between the MN and the HA. That approach would not be = as dynamic as proposed in the I-D but still.. * Section 2 This section would definitely benefit from having more references to the = different technologies/elements listed. Also expanding some of the = acronyms would not make harm. * Section 3 response acknowledging the request and setting the flag for user plane traffic security to Null indicating to the MN that the traffic on the link between the MN and HA will not be encrypted. Setting to "Null"..? Do you rather mean the HA modifies the SPD for = HA->MN direction accordingly and makes the MN destined user traffic to = bypass IPsec? And a similar action needs to be done on the MN for the = MN->HA direction. * Section 4.1 S When set, this flag indicates HA acknowledges, or strongly recommends, use of user plane encryption. When clear, HA does not support or allow use of user plane encryption. This also means that the MN has no way of knowing whether the S was = unset because a) HA policy said so, or b) HA did not understand the = whole thing. In case of b) the MN might want to detach from this = particular HA and try to find a HA that supports the feature proposed in = this I-D. I see this as an issue that needs to be solved somehow.=20 * Section 4.2 I understand the introduction of this option but would still consider it = not being an essential part of the on-demand security enhancement = proposed by this I-D. * Section 5 This document does not require actions by IANA. I kind of disagree ;) As a summary. The proposed solution seems useful. Some work on the I-D = is though needed. - Jouni From julien.ietf@gmail.com Wed Feb 9 13:53:27 2011 Return-Path: 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 03D0E3A6A06 for ; Wed, 9 Feb 2011 13:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 HldpWL98aqWe for ; Wed, 9 Feb 2011 13:53:26 -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 644193A6A10 for ; Wed, 9 Feb 2011 13:53:16 -0800 (PST) Received: by ewy8 with SMTP id 8so491860ewy.31 for ; Wed, 09 Feb 2011 13:53:26 -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=sPcz1y32nXj7+eOdi26NgBlcOymY9rJt2red/ZJbe2M=; b=tWdqVBnBIkUnxZD+sXyQ+/JPcfnMCmt23Nc93s8cXl0JXCiZosOMqm7VYGevMb9InJ goV5vCE4FQUzoMHx2fmTWaplwFnJ6eMjiA5wq2qby+QhjRjFOnnGgUfsZ/nMKJAqKtE6 TfCTYRYjmBgvZPtc0FFDNK2t5/Fr3iz3z/uI8= 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=gAddTPsLvgvvliBJFovfuxOhSm0XWugFc7LcdzDLffrMUHKdp5rtIO/hKV/BNrZXCS PSZ4t587vObu1GQ2rKVmXq25g4duEx/TMQTPGyMPyRYtik+9AYmXyYH7qptXLnHXyQq7 SvSqqqpCKvpT//LSwC4HQ16RQnYZbRddmJn1E= MIME-Version: 1.0 Received: by 10.103.192.12 with SMTP id u12mr12082622mup.75.1297288405555; Wed, 09 Feb 2011 13:53:25 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 9 Feb 2011 13:53:25 -0800 (PST) In-Reply-To: <5ECC386B-CD36-45AE-943D-01F39264242D@gmail.com> References: <5ECC386B-CD36-45AE-943D-01F39264242D@gmail.com> Date: Wed, 9 Feb 2011 13:53:25 -0800 Message-ID: From: Julien Laganier To: jouni korhonen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-bajko-mext-sod@tools.ietf.org, mext@ietf.org Subject: Re: [MEXT] review of draft-bajko-mext-sod-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 21:53:27 -0000 Jouni - Thanks for the review! Please see some comments below: On Wed, Feb 9, 2011 at 1:19 PM, jouni korhonen wro= te: > Hi, > > In Beijing meeting I volunteered to review draft-bajko-mext-sod-01. > > I'll skip the editorials and such. The text would need some editing for s= ure ;) > > > * Section 1 > > =A0 As per the current MIP6 [RFC3775] specification, only the MN has the > =A0 ability to enable security for user-plane traffic. The HA has no > =A0 ability to force the MN to secure user traffic. > > Strictly based on rfc3775 yes. However, if IKE is used as the key managem= ent protocol, then it is possible to have some level of security level nego= tiation between the MN and the HA. That approach would not be as dynamic as= proposed in the I-D but still.. My understanding of IKE is that although it can be used to update the SPD, changing the fundamentals of a bypass or protect rules that applies to user plane traffic wouldn't fall in the scope of IKE -- see quote from RFC 5996: When an RFC4301-compliant IPsec subsystem receives an IP packet that matches a "protect" selector in its Security Policy Database (SPD), the subsystem protects that packet with IPsec. When no SA exists yet, it is the task of IKE to create it. Maintenance of a system's SPD is outside the scope of IKE, although some implementations might update their SPD in connection with the running of IKE (for an example scenario, see Section 1.1.3). Traffic Selector (TS) payloads allow endpoints to communicate some of the information from their SPD to their peers. These must be communicated to IKE from the SPD (for example, the PF_KEY API [PFKEY] uses the SADB_ACQUIRE message). TS payloads specify the selection criteria for packets that will be forwarded over the newly set up SA. This can serve as a consistency check in some scenarios to assure that the SPDs are consistent. In others, it guides the dynamic update of the SPD. Would you disagree? > * Section 2 > > This section would definitely benefit from having more references to the = different technologies/elements listed. Also expanding some of the acronyms= would not make harm. > > * Section 3 > > =A0 response acknowledging the request and setting the flag for user > =A0 plane traffic security to Null indicating to the MN that the traffic > =A0 on the link between the MN and HA will not be encrypted. > > Setting to "Null"..? Do you rather mean the HA modifies the SPD for HA->M= N direction accordingly and makes the MN destined user traffic to bypass IP= sec? And a similar action needs to be done on the MN for the MN->HA directi= on. I think so. > * Section 4.1 > > =A0 S =A0 =A0When set, this flag indicates HA acknowledges, or strongly > =A0 recommends, use of user plane encryption. When clear, HA does not > =A0 support or allow use of user plane encryption. > > This also means that the MN has no way of knowing whether the S was unset= because a) HA policy said so, or b) HA did not understand the whole thing.= In case of b) the MN might want to detach from this particular HA and try = to find a HA that supports the feature proposed in this I-D. I see this as = an issue that needs to be solved somehow. I agree with Jouni. And actually I've commented many times ;-) that the flag should go away and a new mobility option should be included that carries to flag, an 'I' for integrity protection, and a 'C' for confidentiality protection since these are different capabilities. Also having it in a mobility option would avoid the issue outline since a HA that doesn' t understand the option would not send it back and the MN wouldn't have to guess what happened. > * Section 4.2 > > I understand the introduction of this option but would still consider it = not being an essential part of the on-demand security enhancement proposed = by this I-D. Agree. > * Section 5 > > =A0 This document does not require actions by IANA. > > I kind of disagree ;) I think we need action by IANA to register new mobility option. > As a summary. The proposed solution seems useful. Some work on the I-D is= though needed. Agree. --julien From Basavaraj.Patil@nokia.com Wed Feb 9 13:55:34 2011 Return-Path: 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 E12B03A687D for ; Wed, 9 Feb 2011 13:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, 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 RvwzviRLZkhx for ; Wed, 9 Feb 2011 13:55:33 -0800 (PST) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id C328B3A6823 for ; Wed, 9 Feb 2011 13:55:33 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p19LtdYC013545; Wed, 9 Feb 2011 23:55:41 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 23:55:35 +0200 Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Wed, 9 Feb 2011 22:55:35 +0100 Received: from 008-AM1MPN1-005.mgdnok.nokia.com ([169.254.4.149]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi; Wed, 9 Feb 2011 22:55:34 +0100 From: To: , Thread-Topic: [MEXT] review of draft-bajko-mext-sod-01 Thread-Index: AQHLyJ8dSCK9a2QbvUK4pM+P3yniPJP5pYuA//+cAgA= Date: Wed, 9 Feb 2011 21:55:32 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 Content-Type: text/plain; charset="us-ascii" Content-ID: <1743c08a-19a2-44a2-8488-66a89724de05> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Feb 2011 21:55:35.0677 (UTC) FILETIME=[14A572D0:01CBC8A4] X-Nokia-AV: Clean Cc: draft-bajko-mext-sod@tools.ietf.org, mext@ietf.org Subject: Re: [MEXT] review of draft-bajko-mext-sod-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 21:55:35 -0000 Thanks for the reviews and comments. We are cognizant of Julien's comments regarding the flag (from the past two meetings :) ) and will make the necessary changes in the next rev. -Raj On 2/9/11 3:53 PM, "ext Julien Laganier" wrote: >Jouni - > >Thanks for the review! > >Please see some comments below: > >On Wed, Feb 9, 2011 at 1:19 PM, jouni korhonen >wrote: >> Hi, >> >> In Beijing meeting I volunteered to review draft-bajko-mext-sod-01. >> >> I'll skip the editorials and such. The text would need some editing for >>sure ;) >> >> >> * Section 1 >> >> As per the current MIP6 [RFC3775] specification, only the MN has the >> ability to enable security for user-plane traffic. The HA has no >> ability to force the MN to secure user traffic. >> >> Strictly based on rfc3775 yes. However, if IKE is used as the key >>management protocol, then it is possible to have some level of security >>level negotiation between the MN and the HA. That approach would not be >>as dynamic as proposed in the I-D but still.. > >My understanding of IKE is that although it can be used to update the >SPD, changing the fundamentals of a bypass or protect rules that >applies to user plane traffic wouldn't fall in the scope of IKE -- >see quote from RFC 5996: > > When an RFC4301-compliant IPsec subsystem receives an IP packet that > matches a "protect" selector in its Security Policy Database (SPD), > the subsystem protects that packet with IPsec. When no SA exists > yet, it is the task of IKE to create it. Maintenance of a system's > SPD is outside the scope of IKE, although some implementations might > update their SPD in connection with the running of IKE (for an > example scenario, see Section 1.1.3). > > Traffic Selector (TS) payloads allow endpoints to communicate some of > the information from their SPD to their peers. These must be > communicated to IKE from the SPD (for example, the PF_KEY API [PFKEY] > uses the SADB_ACQUIRE message). TS payloads specify the selection > criteria for packets that will be forwarded over the newly set up SA. > This can serve as a consistency check in some scenarios to assure > that the SPDs are consistent. In others, it guides the dynamic > update of the SPD. > >Would you disagree? > >> * Section 2 >> >> This section would definitely benefit from having more references to >>the different technologies/elements listed. Also expanding some of the >>acronyms would not make harm. >> >> * Section 3 >> >> response acknowledging the request and setting the flag for user >> plane traffic security to Null indicating to the MN that the traffic >> on the link between the MN and HA will not be encrypted. >> >> Setting to "Null"..? Do you rather mean the HA modifies the SPD for >>HA->MN direction accordingly and makes the MN destined user traffic to >>bypass IPsec? And a similar action needs to be done on the MN for the >>MN->HA direction. > >I think so. > >> * Section 4.1 >> >> S When set, this flag indicates HA acknowledges, or strongly >> recommends, use of user plane encryption. When clear, HA does not >> support or allow use of user plane encryption. >> >> This also means that the MN has no way of knowing whether the S was >>unset because a) HA policy said so, or b) HA did not understand the >>whole thing. In case of b) the MN might want to detach from this >>particular HA and try to find a HA that supports the feature proposed in >>this I-D. I see this as an issue that needs to be solved somehow. > >I agree with Jouni. And actually I've commented many times ;-) that >the flag should go away and a new mobility option should be included >that carries to flag, an 'I' for integrity protection, and a 'C' for >confidentiality protection since these are different capabilities. >Also having it in a mobility option would avoid the issue outline >since a HA that doesn' t understand the option would not send it back >and the MN wouldn't have to guess what happened. > >> * Section 4.2 >> >> I understand the introduction of this option but would still consider >>it not being an essential part of the on-demand security enhancement >>proposed by this I-D. > >Agree. > >> * Section 5 >> >> This document does not require actions by IANA. >> >> I kind of disagree ;) > >I think we need action by IANA to register new mobility option. > >> As a summary. The proposed solution seems useful. Some work on the I-D >>is though needed. > >Agree. > >--julien From jouni.nospam@gmail.com Wed Feb 9 14:22:48 2011 Return-Path: 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 CA9D33A67CF for ; Wed, 9 Feb 2011 14:22:48 -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 xGFwKW4Yetod for ; Wed, 9 Feb 2011 14:22:48 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id A66F43A67A7 for ; Wed, 9 Feb 2011 14:22:47 -0800 (PST) Received: by bwz12 with SMTP id 12so1589624bwz.31 for ; Wed, 09 Feb 2011 14:22:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=Ywt02BBcmN691rVfk+6F5uoms/MF6Z3QmoHJrH7PpBg=; b=PAluH7rfnXU5PaL9PaxHVxONKv/cNT6Xm6S9Ylfw04ue9IJKcFFGfr+y97V3eBinrE 5YEk68L16Dwa4ygvEtNSPcbyhuS4oh4p27/OnIX2zzYgjcI7DNoVDkqHnqdZECXyNo2u PaNediE4EbeioCDALlsySulRt/uWkWIKylh6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=KcrIW1HibbV6qsGHjaUFeumMIAPHPVZiaX7HOpwJPiqnsN1S4661njDgefYqseDtoi gIKz091jiPZ9sptUYayHqRmnFUXpA0oqjJ4ZCqMfbUneJsr3d49/nUkgoA7uG9/ZsPK8 GL1epEDfOHzKcGHs18qLc65foTHUSUrx9RhGI= Received: by 10.204.117.10 with SMTP id o10mr20086929bkq.10.1297290177549; Wed, 09 Feb 2011 14:22:57 -0800 (PST) Received: from a88-112-143-79.elisa-laajakaista.fi (a88-112-143-79.elisa-laajakaista.fi [88.112.143.79]) by mx.google.com with ESMTPS id v1sm551324bkt.5.2011.02.09.14.22.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 14:22:56 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 10 Feb 2011 00:22:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <40F7FF8A-2462-4FFC-A77A-D528DC1FD7D0@gmail.com> References: <5ECC386B-CD36-45AE-943D-01F39264242D@gmail.com> To: Julien Laganier X-Mailer: Apple Mail (2.1078) Cc: draft-bajko-mext-sod@tools.ietf.org, mext@ietf.org Subject: Re: [MEXT] review of draft-bajko-mext-sod-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 22:22:48 -0000 Julien, On Feb 9, 2011, at 11:53 PM, Julien Laganier wrote: > Jouni - >=20 > Thanks for the review! >=20 > Please see some comments below: >>=20 >> * Section 1 >>=20 >> As per the current MIP6 [RFC3775] specification, only the MN has = the >> ability to enable security for user-plane traffic. The HA has no >> ability to force the MN to secure user traffic. >>=20 >> Strictly based on rfc3775 yes. However, if IKE is used as the key = management protocol, then it is possible to have some level of security = level negotiation between the MN and the HA. That approach would not be = as dynamic as proposed in the I-D but still.. >=20 > My understanding of IKE is that although it can be used to update the > SPD, changing the fundamentals of a bypass or protect rules that > applies to user plane traffic wouldn't fall in the scope of IKE -- > see quote from RFC 5996: I should have written my thoughts clearer. What I meant here is that a = MN and a HA may have a bunch of proposals to agree on. The MN and the HA = can agree on a transform that provides no encryption. And this is = essentially for the HA to enforce. I know it is somewhat far fetched but = doable to some extent. - JOuni >=20 > When an RFC4301-compliant IPsec subsystem receives an IP packet that > matches a "protect" selector in its Security Policy Database (SPD), > the subsystem protects that packet with IPsec. When no SA exists > yet, it is the task of IKE to create it. Maintenance of a system's > SPD is outside the scope of IKE, although some implementations might > update their SPD in connection with the running of IKE (for an > example scenario, see Section 1.1.3). >=20 > Traffic Selector (TS) payloads allow endpoints to communicate some = of > the information from their SPD to their peers. These must be > communicated to IKE from the SPD (for example, the PF_KEY API = [PFKEY] > uses the SADB_ACQUIRE message). TS payloads specify the selection > criteria for packets that will be forwarded over the newly set up = SA. > This can serve as a consistency check in some scenarios to assure > that the SPDs are consistent. In others, it guides the dynamic > update of the SPD. >=20 > Would you disagree? >=20 From julien.ietf@gmail.com Wed Feb 9 14:36:09 2011 Return-Path: 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 B07C63A6819 for ; Wed, 9 Feb 2011 14:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.477 X-Spam-Level: X-Spam-Status: No, score=-3.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 EVots-8dX6Up for ; Wed, 9 Feb 2011 14:36:08 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 63C023A672F for ; Wed, 9 Feb 2011 14:36:08 -0800 (PST) Received: by bwz12 with SMTP id 12so1601955bwz.31 for ; Wed, 09 Feb 2011 14:36:18 -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=VyestoIqjeS0OjTGNekexWLc/ZndJPOsMUOQ61iFEvs=; b=L7KUGsY7Fz28/7NHM9yt8g6F5LfL0s6H/Dds4pPdBVhW8/GJp1ZbkfVgF+Q19aZkP3 OJd4LQd17i3rgo0+tUeuF+uJU168W6O4NPj25EZOikURCEST9OoM9blPWAN+PQRmibV5 w2A+g6c7/gukO196TrbWx/y4P/NFvdTljHWO0= 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=ndckOJC2rZAHTphyQJv7DSVeCSplPXZFvHPtCocoDnk/qSsSPDRKaiy9Rr+1ItPixw rRdp3yHDyoL6wg3/ahpUgN70NRDucD8hUG30XTIDu+UvwdZh2D2PMiSL8UaC67iMFvxX Wru3+CRZI2txXMelJz+f9kCXAXmGzdiHfR6ew= MIME-Version: 1.0 Received: by 10.103.243.16 with SMTP id v16mr14785422mur.57.1297290977861; Wed, 09 Feb 2011 14:36:17 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 9 Feb 2011 14:36:17 -0800 (PST) In-Reply-To: <40F7FF8A-2462-4FFC-A77A-D528DC1FD7D0@gmail.com> References: <5ECC386B-CD36-45AE-943D-01F39264242D@gmail.com> <40F7FF8A-2462-4FFC-A77A-D528DC1FD7D0@gmail.com> Date: Wed, 9 Feb 2011 14:36:17 -0800 Message-ID: From: Julien Laganier To: jouni korhonen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-bajko-mext-sod@tools.ietf.org, mext@ietf.org Subject: Re: [MEXT] review of draft-bajko-mext-sod-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 22:36:09 -0000 Jouni, On Wed, Feb 9, 2011 at 2:22 PM, jouni korhonen wro= te: > Julien, > > On Feb 9, 2011, at 11:53 PM, Julien Laganier wrote: > >> Jouni - >> >> Thanks for the review! >> >> Please see some comments below: >>> >>> * Section 1 >>> >>> =A0 As per the current MIP6 [RFC3775] specification, only the MN has th= e >>> =A0 ability to enable security for user-plane traffic. The HA has no >>> =A0 ability to force the MN to secure user traffic. >>> >>> Strictly based on rfc3775 yes. However, if IKE is used as the key manag= ement protocol, then it is possible to have some level of security level ne= gotiation between the MN and the HA. That approach would not be as dynamic = as proposed in the I-D but still.. >> >> My understanding of IKE is that although it can be used to update the >> SPD, =A0changing the fundamentals of a bypass or protect rules that >> applies to user plane traffic wouldn't =A0fall in the scope of IKE -- >> see quote from RFC 5996: > > I should have written my thoughts clearer. What I meant here is that a MN= and a HA may have a bunch of proposals to agree on. The MN and the HA can = agree on a transform that provides no encryption. And this is essentially f= or the HA to enforce. I know it is somewhat far fetched but doable to some = extent. Hmm. If for a single MN-HA pair there might be situations in which confidentiality protection is to be afforded and other in which it is not, the SPD will have to be modified. Quoting RFC 4301: o Processing info -- which action is required -- PROTECT, BYPASS, or DISCARD. There is just one action that goes with all the selector sets, not a separate action for each set. If the required processing is PROTECT, the entry contains the following information. [...] - algorithms -- which ones to use for AH, which ones to use for ESP, which ones to use for combined mode, ordered by decreasing priority Would it be correct to interpret your statement as having on the HA a PROTECT rule with algorithms as follows and in that order: AES_CBC + HMAC-SHA1-96 followed by HMAC-SHA1-96 would allow the the MN to negotiate Confidentiality protection and Integrity Protection vs. Integrity protection only by changing its local SPD only to contain either AES_CBC + HMAC-SHA1-96 (Confidentiality protection and Integrity Protection) or HMAC-SHA1-96 (Intergrity protection only) and thus no MIPv6 signaling extension is needed in this case because IKE would do the job? I'd agree. However, the SPD would have to be modified in case the userplane is to be passed cleartext, and that means the HA SPD has to say BYPASS, and IKE doen't allow to negotiate this. Comments? --julien From sfaccin@rim.com Wed Feb 9 14:44:02 2011 Return-Path: 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 1870A3A67F3 for ; Wed, 9 Feb 2011 14:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.095 X-Spam-Level: X-Spam-Status: No, score=-6.095 tagged_above=-999 required=5 tests=[AWL=0.504, 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 TRI19pFjZtTt for ; Wed, 9 Feb 2011 14:44:00 -0800 (PST) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 56CAD3A672F for ; Wed, 9 Feb 2011 14:44:00 -0800 (PST) X-AuditID: 0a401fcb-b7b53ae000000a61-b7-4d5318bae64f Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs03ykf.rim.net (RIM Mail) with SMTP id 06.D7.02657.AB8135D4; Wed, 9 Feb 2011 17:44:10 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Feb 2011 17:44:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" content-transfer-encoding: base64 Date: Wed, 9 Feb 2011 16:43:53 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC05EFEE0A@XCH02DFW.rim.net> In-Reply-To: <5ECC386B-CD36-45AE-943D-01F39264242D@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] review of draft-bajko-mext-sod-01 Thread-Index: AcvInxklqyt7NTwATDyTyfqz82uUrwABy34A References: <5ECC386B-CD36-45AE-943D-01F39264242D@gmail.com> From: "Stefano Faccin" To: X-OriginalArrivalTime: 09 Feb 2011 22:44:10.0170 (UTC) FILETIME=[DDD1C9A0:01CBC8AA] X-Brightmail-Tracker: AAAAAgAAAZEXVNa5 Subject: [MEXT] review of draft-bajko-mext-sod-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 22:44:02 -0000 SGVsbG8gYWxsLA0KSSBmaW5hbGx5IGdvdCB0byByZXZpZXcgdGhlIGRyYWZ0IGFzIHByb21p c2VkIGluIEJlaWppbmcuIEl0IHNlZW1zIEpvdW5pIGFuZCBJIGNvbXBsZXRlZCB0aGUgcmV2 aWV3IGF0IHRoZSBzYW1lIHRpbWUuIEkgaGF2ZSBub3QgeWV0IHJlYWQgYWxsIHRoZSByZXBs aWVzLg0KDQo9PT0gU2VjdGlvbiAxOg0KDQoiICAgQXMgcGVyIHRoZSBjdXJyZW50IHNwZWNp ZmljYXRpb25zIGZvciBNSVA2IGFuZCBEU01JUDYsIHNlY3VyaXR5IG9mIA0KICAgdGhlIHVz ZXIgcGxhbmUgdHJhZmZpYyBpcyBvcHRpb25hbC4gV2hlbiB0aGUgTU4gaXMgYXR0YWNoZWQg dG8gM0cvNEcgDQogICBuZXR3b3JrIHN1Y2ggYXMgSFNQQSwgTFRFIG9yIEVWLURPLCB0aGUg TU4gbWF5IG5vdCByZXF1aXJlIHNlY3VyaXR5IA0KICAgZm9yIHRoZSB1c2VyIHBsYW5lIHRy YWZmaWMgc2luY2UgdGhlc2UgbmV0d29ya3MgYWxyZWFkeSBwcm92aWRlIA0KICAgY2lwaGVy aW5nIG92ZXIgdGhlIGFpci1pbnRlcmZhY2UgYW5kIGRlcGxveSBob3AtYnktaG9wIHNlY3Vy aXR5LCANCiAgIHdoaWNoIG1ha2VzIHRoZXNlIG5ldHdvcmtzIHNlY3VyZS4gSG93ZXZlciB0 aGUgTU4gbWF5IGF0dGFjaCB0byBsZXNzIA0KICAgc2VjdXJlIG9yIHVuc2VjdXJlZCBhY2Nl c3NlcyBzdWNoIGFzIHdpcmVsZXNzIGxhbiAoV0xBTikgb3IgaXQgbWF5IA0KICAgcm9hbSBp biBjb3VudHJpZXMgd2hlcmUgdGhlIHVzZXIgbWF5IHByZWZlciB0aGUgZGF0YSBiZXR3ZWVu IHRoZSBNTiANCiAgIGFuZCB0aGUgSEEgdG8gYmUgZW5jcnlwdGVkIChldmVuIHdoZW4gdXNp bmcgY2VsbHVsYXIgYWNjZXNzZXMpLiANCiAgIFRoZXJlIGlzIG5vIHNvbHV0aW9uIGluIHRo ZSBwcm90b2NvbCBzcGVjaWZpY2F0aW9uIHRvZGF5IHdoaWNoIA0KICAgcHJvdmlkZXMgdGhl IGNhcGFiaWxpdHkgdG8gdHJpZ2dlciB0aGUgc2VjdXJpdHkgZm9yIHRoZSB1c2VyIHBsYW5l IA0KICAgdHJhZmZpYyBvbiBhIG5lZWQgYmFzaXMuIg0KW1N0ZWZhbm9dIHdoZW4gdGhlIE1O IGF0dGFjaGVzIGluIG9uZSBvZiB0aGUgc2NlbmFyaW9zIGluZGljYXRlZCAoZWl0aGVyIHRo ZSBNTiBpcyBjb25uZWN0aW5nIG92ZXIgYWNjZXNzIHRlY2hub2xvZ3kvbmV0d29yayB0aGF0 IGl0IGRvZXMgbm90IGNvbnNpZGVyIHNlY3VyZSBvciBpdCBpcyBjb25uZWN0aW5nIHRocm91 Z2ggYSBuZXR3b3JrIOKAkyBlLmcuIHJvYW1pbmcgY2VsbHVsYXIgbmV0d29yayDigJMgdGhh dCBpdCBkb2VzIG5vdCBjb25zaWRlciBzZWN1cmUpLCB0aGUgTU4ga25vd3MgdGhpcyBmYWN0 IChpLmUuIHRoYXQgaXQgaXMgbm90IHNlY3VyZSkuIEZ1cnRoZXIgZG93biBpbiB0aGUgZHJh ZnQgdGhpcyBpcyBzdGF0ZWQgYWxzbyBieSB0aGUgYXV0aG9ycy4gVGhlbiwgc2luY2UgdGhl IE1OIGtub3dzIG9mIHRoZSBsYWNrIG9mIHNlY3VyaXR5IGF0IGF0dGFjaG1lbnQsIHdoeSBj YW4ndCB0aGUgTU4gZGVjaWRlIHRvIGVzdGFibGlzaCB0aGUgdXNlciBwbGFuZSBzZWN1cml0 eSByaWdodCBhd2F5IHVwb24gZXN0YWJsaXNobWVudCBvZiB0aGUgY29ubmVjdGlvbj8gVGhl IHRleHQgaW4gdGhlIGludHJvZHVjdGlvbiBzZWVtcyB0byBpbXBseSB0aGFuIGluIHN1Y2gg Y2FzZXMgdGhlIE1OIHdvdWxkIHdhaXQgYW5kIHRoZW4gYSBuZXcgbWVjaGFuaXNtIGlzIG5l ZWRlZC4NCg0KPT09IFNlY3Rpb24gMQ0KDQoiICAgVGhlIE1JUDYvRFNNSVA2IHByb3RvY29s cyBvbmx5IHByb3ZpZGUgYSBtZWFucyB0byBzZWN1cmUgdGhlIHVzZXIgDQogICBwbGFuZSB0 cmFmZmljIGJ1dCBkbyBub3QgcHJvdmlkZSBhbnkgbWVjaGFuaXNtcyBieSB3aGljaCB0aGUg DQogICBzZWN1cml0eSBpcyB0cmlnZ2VyZWQgYXMgYSByZXN1bHQgb2YgbW9iaWxpdHkgb3Ig dGhlIE1OIGF0dGFjaGluZyANCiAgIHZpYSBkaWZmZXJlbnQgYWNjZXNzIG5ldHdvcmtzLiIN Cg0KW1N0ZWZhbm9dIGluIG15IHVuZGVyc3RhbmRpbmcsIFJGQzQ4NzcgYWxsb3dzIHRoZSBN TiB0byBlc3RhYmxpc2ggdGhlIHNlY3VyaXR5IGZvciB0aGUgdXNlciBwbGFuZSB0cmFmZmlj IGF0IGFueSB0aW1lIChhcyB0aGUgYXV0aG9ycyBhbHNvIHN0YXRlIGluIHNlY3Rpb24gMiku IFdoYXQgdHJpZ2dlcnMgdGhlIE1OIHRvIGRvIHNvIGlzIG9mIGNvdXJzZSBvdXRzaWRlIHRo ZSBzY29wZSBvZiBSRkM0ODc3LCBidXQgaXQgc2hvdWxkIGJlIG91dHNpZGUgdGhlIHNjb3Bl IG9mIHRoaXMgZHJhZnQgYWxzby4gSWYgd2UgZG9uJ3QgY29uc2lkZXIgd2hhdCB0cmlnZ2Vy cyB0aGUgTU4gdG8gZXN0YWJsaXNoIHRoZSBTQSBmb3IgdGhlIHVzZXIgcGxhbmUsIGl0IHNl ZW1zIHRvIG1lIHRoYXQgUkY0ODc3IGlzIHN1ZmZpY2llbnQuIFBsZWFzZSBub3RlIHRoYXQg YXMgYSBleGFtcGxlIDNHUFAgaGFzIGFscmVhZHkgYWRvcHRlZCBSRkM0ODc3IGZvciBzZWN1 cmluZyB0aGUgdXNlciBwbGFuZSBvbiB0aGUgUzJjIGludGVyZmFjZSAoRFNNSVB2Nikgd2hl cmUgdGhlIE1OIG9yIHRoZSBIQSBhdCBhbnkgdGltZSBjYW4gZXN0YWJsaXNoIGEgY2hpbGQg U0EgZm9yIHNlY3VyaW5nIHRoZSB1c2VyIHBsYW5lLiBUaGF0IGlzIHRvIG1lIGNsZWFybHkg b24tZGVtYW5kIHVzZXIgcGxhbmUgc2VjdXJpdHkgYmFzZWQgb24gd2hhdGV2ZXIgY3JpdGVy aWEgdGhlIE1OIGFuZCB0aGUgSEEgaW1wbGVtZW50IHRvIHRyaWdnZXIgdGhlIHNlY3VyaXR5 IGVzdGFibGlzaG1lbnQuIA0KDQoNCj09PSBTZWN0aW9uIDINCg0KIiAgIFRoZSBNTiBoYXMg ZWl0aGVyIGEgc3RvcmVkIHBvbGljeSBhYm91dCB0cnVzdGVkIGFuZCB1bnRydXN0ZWQgYWNj ZXNzIA0KICAgbmV0d29ya3Mgb3IgaXQgbWF5IGJlIHByb3ZpZGVkIHdpdGggc3VjaCBpbmZv cm1hdGlvbiBmcm9tIHBvbGljeSANCiAgIHN0b3JlcyBzdWNoIGFzIHRoZSBBTkRTRiBbMjMu NDAyXSBvciBBQUEgc2VydmVyIGF0IHRoZSB0aW1lIG9mIA0KICAgbmV0d29yayBhdHRhY2ht ZW50LiIgDQoNCltTdGVmYW5vXSB1bmZvcnR1bmF0ZWx5IEkgYmVsaWV2ZSB0aGF0IHF1b3Rp bmcgQU5EU0YgYXMgc3BlY2lmaWVkIGluIDNHUFAgaW4gMjMuNDAyIGFzIHRoZSBlbnRpdHkg dGhhdCBtYXkgcHJvdmlkZSBpbmZvcm1hdGlvbiB0byB0aGUgTU4gb24gd2hldGhlciBhIG5l dHdvcmsgaXMgdHJ1c3RlZCBvciB1bnRydXN0ZWQgaXMgaW5jb3JyZWN0LiAyMy40MDIgKGFu ZCBpbiBwYXJ0aWN1bGFyIHRoZSBzdGFnZSAzIGluIDI0LjMwMiBhbmQgMjQuMzEyKSBkbyBu b3QgY29udGFpbiBzdWNoIGluZm9ybWF0aW9uIHRoYXQgY2FuIGJlIGNvbnZleWVkIHRvIHRo ZSBNTi4NCg0KPT09IFNlY3Rpb24gMg0KDQoiQW4gaW50ZXJmYWNlIGV4aXN0cyBnZW5lcmFs bHkgYmV0d2VlbiB0aGUgcG9saWN5IA0KICAgc3RvcmUgc3VjaCBhcyBBQUEgb3IgQU5EU0Yg YW5kIHRoZSBIb21lIEFnZW50IChIQSkuIiAgIA0KDQpbU3RlZmFub10gSSBuZWVkIHRvIGRp c2FncmVlIHdpdGggdGhpcyBzdGF0ZW1lbnQsIGFzIGluZGljYXRlZCBpbiBCZWlqaW5nLiBU aGVyZSBpcyBubyBpbnRlcmZhY2UgaW4gM0dQUCBkZWZpbmVkIGJldHdlZW4gdGhlIEFORFNG IGFuZCB0aGUgSEEsIHRoZXJlZm9yZSB0aGUgc3RhdGVtZW50IGlzIGluY29ycmVjdC4NCg0K PT09IFNlY3Rpb24gMg0KDQoiVGhlIE1OIG9yIEhBIGNhbiAgZGV0ZXJtaW5lIHdoZW4gdG8g dXNlIHNlY3VyaXR5IGZvciB0aGUgdXNlciBwbGFuZSANCiAgIHRyYWZmaWMgdXNpbmcgc3Rh dGljIHBvbGljaWVzIG9yIGR5bmFtaWMgcG9saWNpZXMgd2hpY2ggY2FuIGJlIA0KICAgb2J0 YWluZWQgYXQgdGhlIHRpbWUgb2YgbmV0d29yayBhdHRhY2htZW50OyBvciBlLmcuIHdoaWNo IGFyZSANCiAgIHByb3Zpc2lvbmVkIGFuZCBtYWludGFpbmVkIG9uIGEgc21hcnRjYXJkIChl ZywgYSBVSUNDIG9yIFNJTSkuIDNHUFAgDQogICBwb2xpY3kgc3RvcmVzIHN1Y2ggYXMgdGhl IEFORFNGIGNhbiBhbHNvIHByb3ZpZGUgaW5mb3JtYXRpb24gYWJvdXQgDQogICB0aGUgYWNj ZXNzIG5ldHdvcmtzIHRvIHdoaWNoIGFuIE1OIGlzIGF0dGFjaGVkLiBMb2NhdGlvbiBvZiB0 aGUgTU4gDQogICBjYW4gYWxzbyBiZSB1c2VkIGFzIGlucHV0LiAiDQoNCltTdGVmYW5vXSBm b3Igc2FrZSBvZiBjbGFyaXR5LCBjYW4gd2Ugc2F5ICIzR1BQIA0KICAgcG9saWN5IHN0b3Jl cyBzdWNoIGFzIHRoZSBBTkRTRiBjYW4gYWxzbyBwcm92aWRlIHRvIHRoZSBNTiBpbmZvcm1h dGlvbiBhYm91dCANCiAgIHRoZSBhY2Nlc3MgbmV0d29ya3MgdG8gd2hpY2ggYW4gTU4gaXMg YXR0YWNoZWQgIg0KDQo9PT0gU2VjdGlvbiAzDQoNCiIgICBUaGlzIGRvY3VtZW50IHByb3Bv c2VzIGV4dGVuc2lvbnMgdG8gTUlQdjYvRFNNSVB2NiBwcm90b2NvbCwgDQogICBhbGxvd2lu ZyB0aGUgTU4gdG8gc2lnbmFsIHRvIHRoZSBIQSBpdHMgcHJlZmVyZW5jZSBmb3IgdXNlciBw bGFuZSANCiAgIHRyYWZmaWMgc2VjdXJpdHkNCiINCg0KW1N0ZWZhbm9dIEkgYW0gd29uZGVy aW5nIHdoeSB0aGUgTU4gbmVlZHMgdG8gc2lnbmFsIGl0cyBwcmVmZXJlbmNlLiBJZiB0aGUg TU4gYXQgYW55IHRpbWUgd2FudHMgdG8gc2V0dXAgYSBjaGlsZCBTQSwgd2h5IGNhbuKAmXQg dGhlIE1OIGRpcmVjdGx5IGRvIGl0IHdpdGhvdXQgaW5kaWNhdGluZyB0aGUgcHJlZmVyZW5j ZT8NCg0KPT09IFNlY3Rpb24gMw0KDQoiICBhbmQgZm9yIHRoZSBIQSB0byBvdmVycmlkZSB0 aGF0IHByZWZlcmVuY2UgYmFzZWQgDQogICBvbiB0aGUgcG9saWN5IHNldHRpbmdzLiAiDQpb U3RlZmFub10gSW4gdGhlIHNhbWUgd2F5LCBpZiB0aGUgTU4gYXQgYW55IHRpbWUgZGVjaWRl cyB0byBlc3RhYmxpc2ggYW4gU0EgZm9yIHRoZSB1c2VyIHBsYW5lLCB3aHkgY2Fu4oCZdCBp dCBkbyBpdCBiYXNlZCBvbiBSRkMgNDg3Nywgc2luY2UgdGhlIEhBIGNhbiBhY2NlcHQgaXQg b3IgZGVueSB0aGUgTU4gcmVxdWVzdCBhbnl3YXk/DQoNCg0KSW4gZ2VuZXJhbCwgSSBoYXZl IHRoZSBzYW1lIGNvbmNlcm4gZXhwcmVzc2VkIGluIEJlaWppbmcgYXMgdG8gaG93IHRoZSBI QSBrbm93cyB3aGV0aGVyIGFuIGFjY2VzcyBpcyB0cnVzdGVkL3VudHJ1c3RlZCBhbmQgd2hl dGhlciB0aGVyZSBpcyB0aGUgbmVlZCBmb3IgdXNlciBwbGFuZSBzZWN1cml0eSwgYW5kIHRo ZXJlZm9yZSBob3cgdGhlIEhBIGNhbiBkZWNpZGUgdG8gdHJpZ2dlciB0aGUgc2VjdXJpdHkg ZXN0YWJsaXNobWVudCBpbiBhIG1lYW5pbmdmdWwvZWR1Y2F0ZWQgd2F5LiBUcnVzdGVkL3Vu dHJ1c3RlZCBpcyBub3QganVzdCBhIGRlY2lzaW9uIGJhc2VkIG9uIHRoZSBhdmFpbGFibGUg ZW5jcnlwdGlvbiBvdmVyIHRoZSByYWRpbyBpbnRlcmZhY2UsIGJ1dCBhbHNvIGEgcm9hbWlu ZyBhZ3JlZW1lbnQuIEUuZy4gYSBnaXZlbiBXTEFOIGNhbiBiZSB0cnVzdGVkIGZvciBvbmUg b3BlcmF0b3IgYnV0IHVudHJ1c3RlZCBmb3IgYW5vdGhlciBvbmUsIGFuZCBpdCBjb3VsZCBl dmVuIGJlIHRydXN0ZWQgZm9yIG9uZSB1c2VyIChlLmcuIGEgdXNlciB0aGF0IGFueXdheSBr bm93cyBpdCBuZWVkcyB0byBydW4gVlBOIHRvIGNvbm5lY3QgdG8gdGhlIGRlc2lyZWQgc2Vy dmljZXMpIGJ1dCB1bnRydXN0ZWQgZm9yIGFub3RoZXIgb25lLiBUaGUgSEEgY2Fubm90IGtu b3cgc3VjaCBpbmZvcm1hdGlvbi4gSW4gdGhlIGNhc2Ugb2YgM0dQUCBuZXR3b3JrcywgYXMg aXQgd2FzIGRpc2N1c3NlZCBpbiBCZWlqaW5nLCB0aGUgdHJ1c3RlZC91bnRydXN0ZWQgZGVj aXNpb24gaXMgcGVyZm9ybWVkIGVpdGhlciBieSB0aGUgTU4gKGJhc2VkIG9uIHByZWNvbmZp Z3VyZWQgaW5mb3JtYXRpb24pIG9yIGJ5IHRoZSBBQUEgaW5mcmFzdHJ1Y3R1cmUgdGhhdCBh dXRoZW50aWNhdGVzIHRoZSBNTiBhY2Nlc3MgdG8gdGhlIHNwZWNpZmljIGFjY2VzcyBuZXR3 b3JrLiBQbGVhc2Ugbm90ZSB0aGF0IHN1Y2ggYXV0aGVudGljYXRpb24gaXMgc2VwYXJhdGUg Zm9yIHRoZSBEU01JUHY2IGF1dGhlbnRpY2F0aW9uIGluIDNHUFAsIGFuZCB0aGF0IHRoZSB0 cnVzdGVkL3VudHJ1c3RlZCBkZWNpc2lvbiBwZXJmb3JtZWQgZHVyaW5nIHRoZSBmaXJzdCBh dXRoZW50aWNhdGlvbiBpcyBub3Qgc3RvcmVkIGFuZCAicmVtZW1iZXJlZCIgc28gdGhhdCBp dCBjYW4gYmUgcHJvdmlkZWQgdG8gdGhlIEhBLiBBZ2FpbiwgdGhpcyB3ZXJlIHRoZSBjb21t ZW50cyBJIHJhaXNlZCBpbiBCZWlqaW5nLg0KDQpPdmVyYWxsLCBhcyBJIGV4cHJlc3NlZCBp biBCZWlqaW5nLCBJIGFtIG5vdCBzdXJlIEkgc2VlIHRoZSBuZWVkIGZvciB0aGlzIHNvbHV0 aW9uIGFuZCBpdHMgYXBwbGljYWJpbGl0eSB0byBlLmcuIDNHUFAsIGFzIGluZGljYXRlZCBp biB0aGUgZHJhZnQuIFBlcmhhcHMgSSBuZWVkIHRvIGJlIGZ1cnRoZXIgZWR1Y2F0ZWQsIGJ1 dCB0aGUgZHJhZnQgYXQgcHJlc2VudCBkb2VzIG5vdCBjbGFyaWZ5IHdoeSBhbiBhZGRpdGlv bmFsIHNvbHV0aW9uIGlzIG5lZWRlZC4gDQoNCkNoZWVycywNClN0ZWZhbm8gRmFjY2luDQoN ClN0YW5kYXJkcyBNYW5hZ2VyDQpSZXNlYXJjaCBJbiBNb3Rpb24gQ29ycG9yYXRpb24gDQo1 MDAwIFJpdmVyc2lkZSBEcml2ZSANCkJ1aWxkaW5nIDYsIEJyYXpvcyBFYXN0LCBTdGUuIDEw MA0KSXJ2aW5nLCBUZXhhcyA3NTAzOSBVU0EgDQpPZmZpY2U6ICg5NzIpIDkxMCAzNDUxwqAg DQpJbnRlcm5hbDogODIwLjYzNDUxDQo6ICg1MTApIDIzMCA4NDIyDQp3d3cucmltLmNvbTsg d3d3LmJsYWNrYmVycnkuY29tIA0KDQoNCg0K74GQIENvbnNpZGVyIHRoZSBlbnZpcm9ubWVu dCBiZWZvcmUgcHJpbnRpbmcuDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tClRoaXMgdHJhbnNtaXNz aW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlh bCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJs ZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBB bnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGlu dGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRv IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0 ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24g b2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBh dXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuDQo= From jouni.nospam@gmail.com Wed Feb 9 14:55:55 2011 Return-Path: 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 748DF3A67F3 for ; Wed, 9 Feb 2011 14:55:55 -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 50y+cOv77o7x for ; Wed, 9 Feb 2011 14:55:54 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id DAC773A672E for ; Wed, 9 Feb 2011 14:55:53 -0800 (PST) Received: by bwz12 with SMTP id 12so1619666bwz.31 for ; Wed, 09 Feb 2011 14:56:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=MVcpSXwZF2vPeHIYwgXf3EdCHnDgmZvl5YBQnoaE5E4=; b=atJdz1Xd4kdeNh3ioDsEw0AjmjnRE2VTvJ9OVlXtEP4Qo745HyYTtu1Rn1JXio0Dfu BuZ7HSVFttGnu2PlWBtKshngKBndEOoBBy3Ierwsd+n911YC4mM5GAk+egNkQ/hHvNgi wKnKewAiwunk/X3DIj1xZ8TOEXMYtPbiHHp5s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=bFXbD1gvmHb9nH60K5j2uJnwAVRjYAj5ewi7o+7c2Sc5EO8nVxU7Q9qafb9oRsB9go /yFmYLWULpQlYx8UN9HOhwVI+4bZ3bH3dRD0O4JOEEqYeXCyaK36gajRZyaAIrNDvd17 WloiP10OPpbKvKeBVEPqiPjP9Yf6EJUPVqMJE= Received: by 10.204.100.82 with SMTP id x18mr1034024bkn.20.1297292163729; Wed, 09 Feb 2011 14:56:03 -0800 (PST) Received: from a88-112-143-79.elisa-laajakaista.fi (a88-112-143-79.elisa-laajakaista.fi [88.112.143.79]) by mx.google.com with ESMTPS id z18sm564791bkf.20.2011.02.09.14.56.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 14:56:03 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 10 Feb 2011 00:56:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <23F651D0-DADF-44DD-860D-D8ED773C5044@gmail.com> References: <5ECC386B-CD36-45AE-943D-01F39264242D@gmail.com> <40F7FF8A-2462-4FFC-A77A-D528DC1FD7D0@gmail.com> To: Julien Laganier X-Mailer: Apple Mail (2.1078) Cc: draft-bajko-mext-sod@tools.ietf.org, mext@ietf.org Subject: Re: [MEXT] review of draft-bajko-mext-sod-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 22:55:55 -0000 Hi again, GOTO the end of mail. On Feb 10, 2011, at 12:36 AM, Julien Laganier wrote: > Jouni, >=20 > On Wed, Feb 9, 2011 at 2:22 PM, jouni korhonen = wrote: >> Julien, >>=20 >> On Feb 9, 2011, at 11:53 PM, Julien Laganier wrote: >>=20 >>> Jouni - >>>=20 >>> Thanks for the review! >>>=20 >>> Please see some comments below: >>>>=20 >>>> * Section 1 >>>>=20 >>>> As per the current MIP6 [RFC3775] specification, only the MN has = the >>>> ability to enable security for user-plane traffic. The HA has no >>>> ability to force the MN to secure user traffic. >>>>=20 >>>> Strictly based on rfc3775 yes. However, if IKE is used as the key = management protocol, then it is possible to have some level of security = level negotiation between the MN and the HA. That approach would not be = as dynamic as proposed in the I-D but still.. >>>=20 >>> My understanding of IKE is that although it can be used to update = the >>> SPD, changing the fundamentals of a bypass or protect rules that >>> applies to user plane traffic wouldn't fall in the scope of IKE -- >>> see quote from RFC 5996: >>=20 >> I should have written my thoughts clearer. What I meant here is that = a MN and a HA may have a bunch of proposals to agree on. The MN and the = HA can agree on a transform that provides no encryption. And this is = essentially for the HA to enforce. I know it is somewhat far fetched but = doable to some extent. >=20 > Hmm. If for a single MN-HA pair there might be situations in which > confidentiality protection is to be afforded and other in which it is > not, the SPD will have to be modified. Quoting RFC 4301: >=20 > o Processing info -- which action is required -- PROTECT, > BYPASS, or DISCARD. There is just one action that goes > with all the selector sets, not a separate action for each > set. If the required processing is PROTECT, the entry > contains the following information. > [...] > - algorithms -- which ones to use for AH, which ones to > use for ESP, which ones to use for combined mode, > ordered by decreasing priority >=20 > Would it be correct to interpret your statement as having on the HA a > PROTECT rule with algorithms as follows and in that order: >=20 > AES_CBC + HMAC-SHA1-96 followed by HMAC-SHA1-96 >=20 > would allow the the MN to negotiate Confidentiality protection and > Integrity Protection vs. Integrity protection only by changing its > local SPD only to contain either AES_CBC + HMAC-SHA1-96 > (Confidentiality protection and Integrity Protection) or HMAC-SHA1-96 > (Intergrity protection only) and thus no MIPv6 signaling extension is > needed in this case because IKE would do the job? >=20 > I'd agree. >=20 > However, the SPD would have to be modified in case the userplane is to > be passed cleartext, and that means the HA SPD has to say BYPASS, and > IKE doen't allow to negotiate this. >=20 > Comments? My original comment was to point out that the statement "The HA has no = ability to force the MN to secure user traffic." is not so black and = white in all cases. Using IKE definitely is not as slick as the solution = proposed in the I-D. I am completely happy if the earlier statement is = modified e.g. "The HA has limited abilities, if any, to force the MN to = secure user traffic." And the probably referencing to RFC4877. - JOuni >=20 > --julien From julien.ietf@gmail.com Wed Feb 9 15:22:31 2011 Return-Path: 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 5D5973A65A6 for ; Wed, 9 Feb 2011 15:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=-0.861, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 ITIcSrG1iNwh for ; Wed, 9 Feb 2011 15:22:30 -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 B614E3A67AC for ; Wed, 9 Feb 2011 15:22:29 -0800 (PST) Received: by fxm9 with SMTP id 9so804522fxm.31 for ; Wed, 09 Feb 2011 15:22:39 -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=y7sThkexvWEeeRO7NTKknw+yZXpeWDGJsCTaUQhkZx4=; b=nFTjOSqv0GbFRYxqJeMd29yg1FXzxRqYhWak/IQmy0L5DKfVmoMR8w1M5WdEMs22eM ll4N/iesp3jgONjqY+zTzZaqY4A8rUCjTq/fcoY+uV7opQ2iEh3a5eOi49QfZSNN6xlW r6zZK5ROuxgbxSfzZ1q3Q05XM8PIcVezfDNaM= 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=ITGtMcBhJHdGEAua5HCjTgRr3FfEcMTsOW//xTU0aoLWNJWHOV+UlNXFPhHkTUQ0DA V3wP0c8X7qFWm+PeuOqzgjJsPC7ZjXP/HzxenzjH95OYfAqI+WTolul6r5eQ4KcbgAv8 YRIAIx1gQiaTh94w84N7Of4NPUF0EDRQfM4VA= MIME-Version: 1.0 Received: by 10.103.124.3 with SMTP id b3mr1012251mun.3.1297293759718; Wed, 09 Feb 2011 15:22:39 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 9 Feb 2011 15:22:39 -0800 (PST) In-Reply-To: <680854867F7FD04BB9B06EB8ACA8D5AC05EFEE0A@XCH02DFW.rim.net> References: <5ECC386B-CD36-45AE-943D-01F39264242D@gmail.com> <680854867F7FD04BB9B06EB8ACA8D5AC05EFEE0A@XCH02DFW.rim.net> Date: Wed, 9 Feb 2011 15:22:39 -0800 Message-ID: From: Julien Laganier To: Stefano Faccin Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] review of draft-bajko-mext-sod-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 23:22:31 -0000 Hi Stefano, Thanks for the review! I am following up on your comments inline below: On Wed, Feb 9, 2011 at 2:43 PM, Stefano Faccin wrote: > Hello all, > I finally got to review the draft as promised in Beijing. It seems Jouni = and I completed the review at the same time. I have not yet read all the re= plies. > > =3D=3D=3D Section 1: > > " =A0 As per the current specifications for MIP6 and DSMIP6, security of > =A0 the user plane traffic is optional. When the MN is attached to 3G/4G > =A0 network such as HSPA, LTE or EV-DO, the MN may not require security > =A0 for the user plane traffic since these networks already provide > =A0 ciphering over the air-interface and deploy hop-by-hop security, > =A0 which makes these networks secure. However the MN may attach to less > =A0 secure or unsecured accesses such as wireless lan (WLAN) or it may > =A0 roam in countries where the user may prefer the data between the MN > =A0 and the HA to be encrypted (even when using cellular accesses). > =A0 There is no solution in the protocol specification today which > =A0 provides the capability to trigger the security for the user plane > =A0 traffic on a need basis." > [Stefano] when the MN attaches in one of the scenarios indicated (either = the MN is connecting over access technology/network that it does not consid= er secure or it is connecting through a network =96 e.g. roaming cellular n= etwork =96 that it does not consider secure), the MN knows this fact (i.e. = that it is not secure). Further down in the draft this is stated also by th= e authors. Then, since the MN knows of the lack of security at attachment, = why can't the MN decide to establish the user plane security right away upo= n establishment of the connection? The text in the introduction seems to im= ply than in such cases the MN would wait and then a new mechanism is needed= . If the HA has an SPD entry for the user-plane traffic with action set to PROTECT, the MN will not be able to send cleartext user-plane packets when the access network it attached to is deemed secure and thus no user-plane confidentiality protection would be needed. Conversely, if the HA has an SPD entry for the user-plane traffic with action set to BYPASS, the MN will not be able to send IPsec protected user-plane packets when the access network it attached to is deemed insecure and thus user-plane confidentiality protection would be needed. Does the above manages to shed some light on why is the mechanism needed? > =3D=3D=3D Section 1 > > " =A0 The MIP6/DSMIP6 protocols only provide a means to secure the user > =A0 plane traffic but do not provide any mechanisms by which the > =A0 security is triggered as a result of mobility or the MN attaching > =A0 via different access networks." > > [Stefano] in my understanding, RFC4877 allows the MN to establish the sec= urity for the user plane traffic at any time (as the authors also state in = section 2). What triggers the MN to do so is of course outside the scope of= RFC4877, but it should be outside the scope of this draft also. If we don'= t consider what triggers the MN to establish the SA for the user plane, it = seems to me that RF4877 is sufficient. Please note that as a example 3GPP h= as already adopted RFC4877 for securing the user plane on the S2c interface= (DSMIPv6) where the MN or the HA at any time can establish a child SA for = securing the user plane. That is to me clearly on-demand user plane securit= y based on whatever criteria the MN and the HA implement to trigger the sec= urity establishment. Although it is true establishment of IPsec SAs affording confidentiality and/or integrity protection to user plane packets can be initiated by the MN at any time, establishment of these SAs is contingent to the IPsec SPD on both the MN and the HA specifying that such protection be afforded to user plane traffic. Further, in the presence of such SPD entries on the MN and HA, absence of the IPsec SAs means not that traffic will be past clear text. On the contrary, traffic will be buffered and/or discarded while the MN attempt to establish the IPsec SAs required as per the SPD. Conversely, in the absence of such SPD entries, the MN and HA will never attempt establishment of IPsec SAs affording protection to user plane packets. Further, if only the MN changes its SPD to require protection but the HA hasn't (based on the signaling hereby proposed), IKEv2 exchange will not lead to the HA accepting to establish such SAs. > =3D=3D=3D Section 2 > > " =A0 The MN has either a stored policy about trusted and untrusted acces= s > =A0 networks or it may be provided with such information from policy > =A0 stores such as the ANDSF [23.402] or AAA server at the time of > =A0 network attachment." > > [Stefano] unfortunately I believe that quoting ANDSF as specified in 3GPP= in 23.402 as the entity that may provide information to the MN on whether = a network is trusted or untrusted is incorrect. 23.402 (and in particular t= he stage 3 in 24.302 and 24.312) do not contain such information that can b= e conveyed to the MN. Agree that in its current form the ANDSF takes no position on whether or not a network should be considered as trusted. This may change however, so maybe rewording into "[...] from extensions to policy stores such as the ANDSF [23.402] or AAA server at the time of network attachment." would ease your concern? Another thing I'd like to see reference in this draft is the possibility to use the presence or the absence of link layer confidentiality protection as an input to the MN requesting confidentiality protection. In wireless system, the first over-the-air hop is the most vulnerable to eavesdropping. > =3D=3D=3D Section 2 > > "An interface exists generally between the policy > =A0 store such as AAA or ANDSF and the Home Agent (HA)." > > [Stefano] I need to disagree with this statement, as indicated in Beijing= . There is no interface in 3GPP defined between the ANDSF and the HA, there= fore the statement is incorrect. > > =3D=3D=3D Section 2 > > "The MN or HA can =A0determine when to use security for the user plane > =A0 traffic using static policies or dynamic policies which can be > =A0 obtained at the time of network attachment; or e.g. which are > =A0 provisioned and maintained on a smartcard (eg, a UICC or SIM). 3GPP > =A0 policy stores such as the ANDSF can also provide information about > =A0 the access networks to which an MN is attached. Location of the MN > =A0 can also be used as input. " > > [Stefano] for sake of clarity, can we say "3GPP > =A0 policy stores such as the ANDSF can also provide to the MN informatio= n about > =A0 the access networks to which an MN is attached " > > =3D=3D=3D Section 3 > > " =A0 This document proposes extensions to MIPv6/DSMIPv6 protocol, > =A0 allowing the MN to signal to the HA its preference for user plane > =A0 traffic security > " > > [Stefano] I am wondering why the MN needs to signal its preference. If th= e MN at any time wants to setup a child SA, why can=92t the MN directly do = it without indicating the preference? Hopefully I have managed to answer that question with my earlier comment on the need to have coordinated SPD on the MN and HA. Since IKE doesn't allow modification to the SPD, this has to be coordinated through MIPv6 signaling, > =3D=3D=3D Section 3 > > " =A0and for the HA to override that preference based > =A0 on the policy settings. " > [Stefano] In the same way, if the MN at any time decides to establish an = SA for the user plane, why can=92t it do it based on RFC 4877, since the HA= can accept it or deny the MN request anyway? > > > In general, I have the same concern expressed in Beijing as to how the HA= knows whether an access is trusted/untrusted and whether there is the need= for user plane security, and therefore how the HA can decide to trigger th= e security establishment in a meaningful/educated way. Trusted/untrusted is= not just a decision based on the available encryption over the radio inter= face, but also a roaming agreement. E.g. a given WLAN can be trusted for on= e operator but untrusted for another one, and it could even be trusted for = one user (e.g. a user that anyway knows it needs to run VPN to connect to t= he desired services) but untrusted for another one. The HA cannot know such= information. In the case of 3GPP networks, as it was discussed in Beijing,= the trusted/untrusted decision is performed either by the MN (based on pre= configured information) or by the AAA infrastructure that authenticates the= MN access to the specific access network. Please note that such authentica= tion is separate for the DSMIPv6 authentication in 3GPP, and that the trust= ed/untrusted decision performed during the first authentication is not stor= ed and "remembered" so that it can be provided to the HA. Again, this were = the comments I raised in Beijing. >From my side, I believe the main usecase is one in which the MN unilaterally decide whether to use encryption or not (based on L2 encryption being ON or OFF, and possibly whitelists pulled through ANDSF or other policy store extensions, or user preferences) and informs the HA about its choice so that the SPD are aligned on both sides, thus resulting in IKEv2 establishing or not the required IPsec SAs to afford protection to user plane packets. > Overall, as I expressed in Beijing, I am not sure I see the need for this= solution and its applicability to e.g. 3GPP, as indicated in the draft. Pe= rhaps I need to be further educated, but the draft at present does not clar= ify why an additional solution is needed. Hopefully I have clarified why I think this is useful. --julien From sfaccin@rim.com Wed Feb 9 15:42:22 2011 Return-Path: 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 288D33A672E for ; Wed, 9 Feb 2011 15:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.167 X-Spam-Level: X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[AWL=0.432, 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 fTMRn7hUgiQv for ; Wed, 9 Feb 2011 15:42:20 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id 3FD3F3A65A6 for ; Wed, 9 Feb 2011 15:42:20 -0800 (PST) X-AuditID: 0a666446-b7bbeae000000a35-30-4d532666c509 Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs04ykf.rim.net (RIM Mail) with SMTP id 49.FA.02613.666235D4; Wed, 9 Feb 2011 18:42:30 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Feb 2011 18:42:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" content-transfer-encoding: base64 Date: Wed, 9 Feb 2011 17:41:33 -0600 Message-ID: <680854867F7FD04BB9B06EB8ACA8D5AC05EFEE48@XCH02DFW.rim.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MEXT] review of draft-bajko-mext-sod-01 Thread-Index: AcvIsEAENi+HyehxQxKSP2WgwMFyJwAAddWA References: <5ECC386B-CD36-45AE-943D-01F39264242D@gmail.com><680854867F7FD04BB9B06EB8ACA8D5AC05EFEE0A@XCH02DFW.rim.net> From: "Stefano Faccin" To: "Julien Laganier" X-OriginalArrivalTime: 09 Feb 2011 23:42:30.0500 (UTC) FILETIME=[042DC240:01CBC8B3] X-Brightmail-Tracker: AAAAAgAAAZEXVNa5 Cc: mext@ietf.org Subject: Re: [MEXT] review of draft-bajko-mext-sod-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 23:42:22 -0000 SnVsaWVuLA0KVGhhbmtzIGZvciB0aGUgcmVwbHkuDQoNClNvLCBmb3IgbXkgY2xhcmlmaWNh dGlvbiwgYmFzZWQgb24geW91ciBmaXJzdCBjb21tZW50LCB3aGF0IDNHUFAgaGFzIGFkb3B0 ZWQgZm9yIHNlY3VyaW5nIHRoZSB1c2VyIHBsYW5lIHRyYWZmaWMgZm9yIFMyYyAoRFNNSVB2 NikgaXMgaW5jb3JyZWN0LCBzaW5jZSBpdCBpcyBiYXNlZCBvbiBSRkM0ODc3IGFuZCB0aGUg ZmFjdCB0aGF0IHRoZSBVRSBhbmQgdGhlIEhBIGF0IGFueSB0aW1lIGNhbiByZXF1ZXN0IHRo ZSBlc3RhYmxpc2htZW50IG9mIGEgY2hpbGQgU0E/DQoNCkkgYW0gbm90IHN1cmUgd2Ugd2Fu dCB0byByZWZlcmVuY2Ugc29tZXRoaW5nIGFib3V0IEFORFNGIHRoYXQgaGFzIG5vdCBiZWVu IGRlZmluZWQgbm9yIGRpc2N1c3NlZCB5ZXQuIEl0IHdvdWxkIGJlIHB1cmUgc3BlY3VsYXRp b24sIGVzcGVjaWFsbHkgY29uc2lkZXJpbmcgM0dQUCBhbHJlYWR5IGhhcyBkZWZpbmVkIHNv bHV0aW9ucyBmb3IgdGhhdC4gSSB3b3VsZCBkcm9wIHRoZSByZWZlcmVuY2UgdG8gQU5EU0Yg YWx0b2dldGhlci4NCg0KU3RlZmFubyBGYWNjaW4NCg0KU3RhbmRhcmRzIE1hbmFnZXINClJl c2VhcmNoIEluIE1vdGlvbiBDb3Jwb3JhdGlvbiANCjUwMDAgUml2ZXJzaWRlIERyaXZlIA0K QnVpbGRpbmcgNiwgQnJhem9zIEVhc3QsIFN0ZS4gMTAwDQpJcnZpbmcsIFRleGFzIDc1MDM5 IFVTQSANCk9mZmljZTogKDk3MikgOTEwIDM0NTHCoCANCkludGVybmFsOiA4MjAuNjM0NTEN CjogKDUxMCkgMjMwIDg0MjINCnd3dy5yaW0uY29tOyB3d3cuYmxhY2tiZXJyeS5jb20gDQoN Cg0KDQrvgZAgQ29uc2lkZXIgdGhlIGVudmlyb25tZW50IGJlZm9yZSBwcmludGluZy4NCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSnVsaWVuIExhZ2FuaWVyIFtt YWlsdG86anVsaWVuLmlldGZAZ21haWwuY29tXSANClNlbnQ6IFdlZG5lc2RheSwgRmVicnVh cnkgMDksIDIwMTEgMzoyMyBQTQ0KVG86IFN0ZWZhbm8gRmFjY2luDQpDYzogbWV4dEBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtNRVhUXSByZXZpZXcgb2YgZHJhZnQtYmFqa28tbWV4dC1z b2QtMDENCg0KSGkgU3RlZmFubywNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3IQ0KDQpJIGFt IGZvbGxvd2luZyB1cCBvbiB5b3VyIGNvbW1lbnRzIGlubGluZSBiZWxvdzoNCg0KT24gV2Vk LCBGZWIgOSwgMjAxMSBhdCAyOjQzIFBNLCBTdGVmYW5vIEZhY2NpbiA8c2ZhY2NpbkByaW0u Y29tPiB3cm90ZToNCj4gSGVsbG8gYWxsLA0KPiBJIGZpbmFsbHkgZ290IHRvIHJldmlldyB0 aGUgZHJhZnQgYXMgcHJvbWlzZWQgaW4gQmVpamluZy4gSXQgc2VlbXMgSm91bmkgYW5kIEkg Y29tcGxldGVkIHRoZSByZXZpZXcgYXQgdGhlIHNhbWUgdGltZS4gSSBoYXZlIG5vdCB5ZXQg cmVhZCBhbGwgdGhlIHJlcGxpZXMuDQo+DQo+ID09PSBTZWN0aW9uIDE6DQo+DQo+ICIgwqAg QXMgcGVyIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb25zIGZvciBNSVA2IGFuZCBEU01JUDYs IHNlY3VyaXR5IG9mDQo+IMKgIHRoZSB1c2VyIHBsYW5lIHRyYWZmaWMgaXMgb3B0aW9uYWwu IFdoZW4gdGhlIE1OIGlzIGF0dGFjaGVkIHRvIDNHLzRHDQo+IMKgIG5ldHdvcmsgc3VjaCBh cyBIU1BBLCBMVEUgb3IgRVYtRE8sIHRoZSBNTiBtYXkgbm90IHJlcXVpcmUgc2VjdXJpdHkN Cj4gwqAgZm9yIHRoZSB1c2VyIHBsYW5lIHRyYWZmaWMgc2luY2UgdGhlc2UgbmV0d29ya3Mg YWxyZWFkeSBwcm92aWRlDQo+IMKgIGNpcGhlcmluZyBvdmVyIHRoZSBhaXItaW50ZXJmYWNl IGFuZCBkZXBsb3kgaG9wLWJ5LWhvcCBzZWN1cml0eSwNCj4gwqAgd2hpY2ggbWFrZXMgdGhl c2UgbmV0d29ya3Mgc2VjdXJlLiBIb3dldmVyIHRoZSBNTiBtYXkgYXR0YWNoIHRvIGxlc3MN Cj4gwqAgc2VjdXJlIG9yIHVuc2VjdXJlZCBhY2Nlc3NlcyBzdWNoIGFzIHdpcmVsZXNzIGxh biAoV0xBTikgb3IgaXQgbWF5DQo+IMKgIHJvYW0gaW4gY291bnRyaWVzIHdoZXJlIHRoZSB1 c2VyIG1heSBwcmVmZXIgdGhlIGRhdGEgYmV0d2VlbiB0aGUgTU4NCj4gwqAgYW5kIHRoZSBI QSB0byBiZSBlbmNyeXB0ZWQgKGV2ZW4gd2hlbiB1c2luZyBjZWxsdWxhciBhY2Nlc3Nlcyku DQo+IMKgIFRoZXJlIGlzIG5vIHNvbHV0aW9uIGluIHRoZSBwcm90b2NvbCBzcGVjaWZpY2F0 aW9uIHRvZGF5IHdoaWNoDQo+IMKgIHByb3ZpZGVzIHRoZSBjYXBhYmlsaXR5IHRvIHRyaWdn ZXIgdGhlIHNlY3VyaXR5IGZvciB0aGUgdXNlciBwbGFuZQ0KPiDCoCB0cmFmZmljIG9uIGEg bmVlZCBiYXNpcy4iDQo+IFtTdGVmYW5vXSB3aGVuIHRoZSBNTiBhdHRhY2hlcyBpbiBvbmUg b2YgdGhlIHNjZW5hcmlvcyBpbmRpY2F0ZWQgKGVpdGhlciB0aGUgTU4gaXMgY29ubmVjdGlu ZyBvdmVyIGFjY2VzcyB0ZWNobm9sb2d5L25ldHdvcmsgdGhhdCBpdCBkb2VzIG5vdCBjb25z aWRlciBzZWN1cmUgb3IgaXQgaXMgY29ubmVjdGluZyB0aHJvdWdoIGEgbmV0d29yayDigJMg ZS5nLiByb2FtaW5nIGNlbGx1bGFyIG5ldHdvcmsg4oCTIHRoYXQgaXQgZG9lcyBub3QgY29u c2lkZXIgc2VjdXJlKSwgdGhlIE1OIGtub3dzIHRoaXMgZmFjdCAoaS5lLiB0aGF0IGl0IGlz IG5vdCBzZWN1cmUpLiBGdXJ0aGVyIGRvd24gaW4gdGhlIGRyYWZ0IHRoaXMgaXMgc3RhdGVk IGFsc28gYnkgdGhlIGF1dGhvcnMuIFRoZW4sIHNpbmNlIHRoZSBNTiBrbm93cyBvZiB0aGUg bGFjayBvZiBzZWN1cml0eSBhdCBhdHRhY2htZW50LCB3aHkgY2FuJ3QgdGhlIE1OIGRlY2lk ZSB0byBlc3RhYmxpc2ggdGhlIHVzZXIgcGxhbmUgc2VjdXJpdHkgcmlnaHQgYXdheSB1cG9u IGVzdGFibGlzaG1lbnQgb2YgdGhlIGNvbm5lY3Rpb24/IFRoZSB0ZXh0IGluIHRoZSBpbnRy b2R1Y3Rpb24gc2VlbXMgdG8gaW1wbHkgdGhhbiBpbiBzdWNoIGNhc2VzIHRoZSBNTiB3b3Vs ZCB3YWl0IGFuZCB0aGVuIGEgbmV3IG1lY2hhbmlzbSBpcyBuZWVkZWQuDQoNCklmIHRoZSBI QSBoYXMgYW4gU1BEIGVudHJ5IGZvciB0aGUgdXNlci1wbGFuZSB0cmFmZmljIHdpdGggYWN0 aW9uIHNldA0KdG8gUFJPVEVDVCwgdGhlIE1OIHdpbGwgbm90IGJlIGFibGUgdG8gc2VuZCBj bGVhcnRleHQgdXNlci1wbGFuZQ0KcGFja2V0cyB3aGVuIHRoZSBhY2Nlc3MgbmV0d29yayBp dCBhdHRhY2hlZCB0byBpcyBkZWVtZWQgc2VjdXJlIGFuZA0KdGh1cyBubyB1c2VyLXBsYW5l IGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0aW9uIHdvdWxkIGJlIG5lZWRlZC4NCg0KQ29udmVy c2VseSwgaWYgdGhlIEhBIGhhcyBhbiBTUEQgZW50cnkgZm9yIHRoZSB1c2VyLXBsYW5lIHRy YWZmaWMgd2l0aA0KYWN0aW9uIHNldCB0byBCWVBBU1MsIHRoZSBNTiB3aWxsIG5vdCBiZSBh YmxlIHRvIHNlbmQgSVBzZWMgcHJvdGVjdGVkDQp1c2VyLXBsYW5lIHBhY2tldHMgd2hlbiB0 aGUgYWNjZXNzIG5ldHdvcmsgaXQgYXR0YWNoZWQgdG8gaXMgZGVlbWVkDQppbnNlY3VyZSBh bmQgdGh1cyB1c2VyLXBsYW5lIGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0aW9uIHdvdWxkIGJl DQpuZWVkZWQuDQoNCkRvZXMgdGhlIGFib3ZlIG1hbmFnZXMgdG8gc2hlZCBzb21lIGxpZ2h0 IG9uIHdoeSBpcyB0aGUgbWVjaGFuaXNtIG5lZWRlZD8NCg0KPiA9PT0gU2VjdGlvbiAxDQo+ DQo+ICIgwqAgVGhlIE1JUDYvRFNNSVA2IHByb3RvY29scyBvbmx5IHByb3ZpZGUgYSBtZWFu cyB0byBzZWN1cmUgdGhlIHVzZXINCj4gwqAgcGxhbmUgdHJhZmZpYyBidXQgZG8gbm90IHBy b3ZpZGUgYW55IG1lY2hhbmlzbXMgYnkgd2hpY2ggdGhlDQo+IMKgIHNlY3VyaXR5IGlzIHRy aWdnZXJlZCBhcyBhIHJlc3VsdCBvZiBtb2JpbGl0eSBvciB0aGUgTU4gYXR0YWNoaW5nDQo+ IMKgIHZpYSBkaWZmZXJlbnQgYWNjZXNzIG5ldHdvcmtzLiINCj4NCj4gW1N0ZWZhbm9dIGlu IG15IHVuZGVyc3RhbmRpbmcsIFJGQzQ4NzcgYWxsb3dzIHRoZSBNTiB0byBlc3RhYmxpc2gg dGhlIHNlY3VyaXR5IGZvciB0aGUgdXNlciBwbGFuZSB0cmFmZmljIGF0IGFueSB0aW1lIChh cyB0aGUgYXV0aG9ycyBhbHNvIHN0YXRlIGluIHNlY3Rpb24gMikuIFdoYXQgdHJpZ2dlcnMg dGhlIE1OIHRvIGRvIHNvIGlzIG9mIGNvdXJzZSBvdXRzaWRlIHRoZSBzY29wZSBvZiBSRkM0 ODc3LCBidXQgaXQgc2hvdWxkIGJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZHJhZnQg YWxzby4gSWYgd2UgZG9uJ3QgY29uc2lkZXIgd2hhdCB0cmlnZ2VycyB0aGUgTU4gdG8gZXN0 YWJsaXNoIHRoZSBTQSBmb3IgdGhlIHVzZXIgcGxhbmUsIGl0IHNlZW1zIHRvIG1lIHRoYXQg UkY0ODc3IGlzIHN1ZmZpY2llbnQuIFBsZWFzZSBub3RlIHRoYXQgYXMgYSBleGFtcGxlIDNH UFAgaGFzIGFscmVhZHkgYWRvcHRlZCBSRkM0ODc3IGZvciBzZWN1cmluZyB0aGUgdXNlciBw bGFuZSBvbiB0aGUgUzJjIGludGVyZmFjZSAoRFNNSVB2Nikgd2hlcmUgdGhlIE1OIG9yIHRo ZSBIQSBhdCBhbnkgdGltZSBjYW4gZXN0YWJsaXNoIGEgY2hpbGQgU0EgZm9yIHNlY3VyaW5n IHRoZSB1c2VyIHBsYW5lLiBUaGF0IGlzIHRvIG1lIGNsZWFybHkgb24tZGVtYW5kIHVzZXIg cGxhbmUgc2VjdXJpdHkgYmFzZWQgb24gd2hhdGV2ZXIgY3JpdGVyaWEgdGhlIE1OIGFuZCB0 aGUgSEEgaW1wbGVtZW50IHRvIHRyaWdnZXIgdGhlIHNlY3VyaXR5IGVzdGFibGlzaG1lbnQu DQoNCkFsdGhvdWdoIGl0IGlzIHRydWUgZXN0YWJsaXNobWVudCBvZiBJUHNlYyBTQXMgYWZm b3JkaW5nDQpjb25maWRlbnRpYWxpdHkgYW5kL29yIGludGVncml0eSBwcm90ZWN0aW9uIHRv IHVzZXIgcGxhbmUgcGFja2V0cyBjYW4NCmJlIGluaXRpYXRlZCBieSB0aGUgTU4gYXQgYW55 IHRpbWUsIGVzdGFibGlzaG1lbnQgb2YgdGhlc2UgU0FzIGlzDQpjb250aW5nZW50IHRvIHRo ZSBJUHNlYyBTUEQgb24gYm90aCB0aGUgTU4gYW5kIHRoZSBIQSBzcGVjaWZ5aW5nIHRoYXQN CnN1Y2ggcHJvdGVjdGlvbiBiZSBhZmZvcmRlZCB0byB1c2VyIHBsYW5lIHRyYWZmaWMuIEZ1 cnRoZXIsIGluIHRoZQ0KcHJlc2VuY2Ugb2Ygc3VjaCBTUEQgZW50cmllcyBvbiB0aGUgTU4g YW5kIEhBLCBhYnNlbmNlIG9mIHRoZSBJUHNlYw0KU0FzIG1lYW5zIG5vdCB0aGF0IHRyYWZm aWMgd2lsbCBiZSBwYXN0IGNsZWFyIHRleHQuIE9uIHRoZSBjb250cmFyeSwNCnRyYWZmaWMg d2lsbCBiZSBidWZmZXJlZCBhbmQvb3IgZGlzY2FyZGVkIHdoaWxlIHRoZSBNTiBhdHRlbXB0 IHRvDQplc3RhYmxpc2ggdGhlIElQc2VjIFNBcyByZXF1aXJlZCBhcyBwZXIgdGhlIFNQRC4N Cg0KQ29udmVyc2VseSwgaW4gdGhlIGFic2VuY2Ugb2Ygc3VjaCBTUEQgZW50cmllcywgdGhl IE1OIGFuZCBIQSB3aWxsDQpuZXZlciBhdHRlbXB0IGVzdGFibGlzaG1lbnQgb2YgSVBzZWMg U0FzIGFmZm9yZGluZyBwcm90ZWN0aW9uIHRvIHVzZXINCnBsYW5lIHBhY2tldHMuIEZ1cnRo ZXIsIGlmIG9ubHkgdGhlIE1OIGNoYW5nZXMgaXRzIFNQRCB0byByZXF1aXJlDQpwcm90ZWN0 aW9uIGJ1dCB0aGUgSEEgaGFzbid0IChiYXNlZCBvbiB0aGUgc2lnbmFsaW5nIGhlcmVieSBw cm9wb3NlZCksDQpJS0V2MiBleGNoYW5nZSB3aWxsIG5vdCBsZWFkIHRvIHRoZSBIQSBhY2Nl cHRpbmcgdG8gZXN0YWJsaXNoIHN1Y2gNClNBcy4NCg0KPiA9PT0gU2VjdGlvbiAyDQo+DQo+ ICIgwqAgVGhlIE1OIGhhcyBlaXRoZXIgYSBzdG9yZWQgcG9saWN5IGFib3V0IHRydXN0ZWQg YW5kIHVudHJ1c3RlZCBhY2Nlc3MNCj4gwqAgbmV0d29ya3Mgb3IgaXQgbWF5IGJlIHByb3Zp ZGVkIHdpdGggc3VjaCBpbmZvcm1hdGlvbiBmcm9tIHBvbGljeQ0KPiDCoCBzdG9yZXMgc3Vj aCBhcyB0aGUgQU5EU0YgWzIzLjQwMl0gb3IgQUFBIHNlcnZlciBhdCB0aGUgdGltZSBvZg0K PiDCoCBuZXR3b3JrIGF0dGFjaG1lbnQuIg0KPg0KPiBbU3RlZmFub10gdW5mb3J0dW5hdGVs eSBJIGJlbGlldmUgdGhhdCBxdW90aW5nIEFORFNGIGFzIHNwZWNpZmllZCBpbiAzR1BQIGlu IDIzLjQwMiBhcyB0aGUgZW50aXR5IHRoYXQgbWF5IHByb3ZpZGUgaW5mb3JtYXRpb24gdG8g dGhlIE1OIG9uIHdoZXRoZXIgYSBuZXR3b3JrIGlzIHRydXN0ZWQgb3IgdW50cnVzdGVkIGlz IGluY29ycmVjdC4gMjMuNDAyIChhbmQgaW4gcGFydGljdWxhciB0aGUgc3RhZ2UgMyBpbiAy NC4zMDIgYW5kIDI0LjMxMikgZG8gbm90IGNvbnRhaW4gc3VjaCBpbmZvcm1hdGlvbiB0aGF0 IGNhbiBiZSBjb252ZXllZCB0byB0aGUgTU4uDQoNCkFncmVlIHRoYXQgaW4gaXRzIGN1cnJl bnQgZm9ybSB0aGUgQU5EU0YgdGFrZXMgbm8gcG9zaXRpb24gb24gd2hldGhlcg0Kb3Igbm90 IGEgbmV0d29yayBzaG91bGQgYmUgY29uc2lkZXJlZCBhcyB0cnVzdGVkLiBUaGlzIG1heSBj aGFuZ2UNCmhvd2V2ZXIsIHNvIG1heWJlIHJld29yZGluZyBpbnRvICJbLi4uXSAgZnJvbSBl eHRlbnNpb25zIHRvIHBvbGljeQ0Kc3RvcmVzIHN1Y2ggYXMgdGhlIEFORFNGIFsyMy40MDJd IG9yIEFBQSBzZXJ2ZXIgYXQgdGhlIHRpbWUgb2YgbmV0d29yaw0KYXR0YWNobWVudC4iIHdv dWxkIGVhc2UgeW91ciBjb25jZXJuPw0KDQpBbm90aGVyIHRoaW5nIEknZCBsaWtlIHRvIHNl ZSByZWZlcmVuY2UgaW4gdGhpcyBkcmFmdCBpcyB0aGUNCnBvc3NpYmlsaXR5IHRvIHVzZSB0 aGUgcHJlc2VuY2Ugb3IgdGhlIGFic2VuY2Ugb2YgbGluayBsYXllcg0KY29uZmlkZW50aWFs aXR5IHByb3RlY3Rpb24gYXMgYW4gaW5wdXQgdG8gdGhlIE1OIHJlcXVlc3RpbmcNCmNvbmZp ZGVudGlhbGl0eSBwcm90ZWN0aW9uLiBJbiB3aXJlbGVzcyBzeXN0ZW0sIHRoZSBmaXJzdCBv dmVyLXRoZS1haXINCmhvcCBpcyB0aGUgbW9zdCB2dWxuZXJhYmxlIHRvIGVhdmVzZHJvcHBp bmcuDQoNCj4gPT09IFNlY3Rpb24gMg0KPg0KPiAiQW4gaW50ZXJmYWNlIGV4aXN0cyBnZW5l cmFsbHkgYmV0d2VlbiB0aGUgcG9saWN5DQo+IMKgIHN0b3JlIHN1Y2ggYXMgQUFBIG9yIEFO RFNGIGFuZCB0aGUgSG9tZSBBZ2VudCAoSEEpLiINCj4NCj4gW1N0ZWZhbm9dIEkgbmVlZCB0 byBkaXNhZ3JlZSB3aXRoIHRoaXMgc3RhdGVtZW50LCBhcyBpbmRpY2F0ZWQgaW4gQmVpamlu Zy4gVGhlcmUgaXMgbm8gaW50ZXJmYWNlIGluIDNHUFAgZGVmaW5lZCBiZXR3ZWVuIHRoZSBB TkRTRiBhbmQgdGhlIEhBLCB0aGVyZWZvcmUgdGhlIHN0YXRlbWVudCBpcyBpbmNvcnJlY3Qu DQo+DQo+ID09PSBTZWN0aW9uIDINCj4NCj4gIlRoZSBNTiBvciBIQSBjYW4gwqBkZXRlcm1p bmUgd2hlbiB0byB1c2Ugc2VjdXJpdHkgZm9yIHRoZSB1c2VyIHBsYW5lDQo+IMKgIHRyYWZm aWMgdXNpbmcgc3RhdGljIHBvbGljaWVzIG9yIGR5bmFtaWMgcG9saWNpZXMgd2hpY2ggY2Fu IGJlDQo+IMKgIG9idGFpbmVkIGF0IHRoZSB0aW1lIG9mIG5ldHdvcmsgYXR0YWNobWVudDsg b3IgZS5nLiB3aGljaCBhcmUNCj4gwqAgcHJvdmlzaW9uZWQgYW5kIG1haW50YWluZWQgb24g YSBzbWFydGNhcmQgKGVnLCBhIFVJQ0Mgb3IgU0lNKS4gM0dQUA0KPiDCoCBwb2xpY3kgc3Rv cmVzIHN1Y2ggYXMgdGhlIEFORFNGIGNhbiBhbHNvIHByb3ZpZGUgaW5mb3JtYXRpb24gYWJv dXQNCj4gwqAgdGhlIGFjY2VzcyBuZXR3b3JrcyB0byB3aGljaCBhbiBNTiBpcyBhdHRhY2hl ZC4gTG9jYXRpb24gb2YgdGhlIE1ODQo+IMKgIGNhbiBhbHNvIGJlIHVzZWQgYXMgaW5wdXQu ICINCj4NCj4gW1N0ZWZhbm9dIGZvciBzYWtlIG9mIGNsYXJpdHksIGNhbiB3ZSBzYXkgIjNH UFANCj4gwqAgcG9saWN5IHN0b3JlcyBzdWNoIGFzIHRoZSBBTkRTRiBjYW4gYWxzbyBwcm92 aWRlIHRvIHRoZSBNTiBpbmZvcm1hdGlvbiBhYm91dA0KPiDCoCB0aGUgYWNjZXNzIG5ldHdv cmtzIHRvIHdoaWNoIGFuIE1OIGlzIGF0dGFjaGVkICINCj4NCj4gPT09IFNlY3Rpb24gMw0K Pg0KPiAiIMKgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgZXh0ZW5zaW9ucyB0byBNSVB2Ni9E U01JUHY2IHByb3RvY29sLA0KPiDCoCBhbGxvd2luZyB0aGUgTU4gdG8gc2lnbmFsIHRvIHRo ZSBIQSBpdHMgcHJlZmVyZW5jZSBmb3IgdXNlciBwbGFuZQ0KPiDCoCB0cmFmZmljIHNlY3Vy aXR5DQo+ICINCj4NCj4gW1N0ZWZhbm9dIEkgYW0gd29uZGVyaW5nIHdoeSB0aGUgTU4gbmVl ZHMgdG8gc2lnbmFsIGl0cyBwcmVmZXJlbmNlLiBJZiB0aGUgTU4gYXQgYW55IHRpbWUgd2Fu dHMgdG8gc2V0dXAgYSBjaGlsZCBTQSwgd2h5IGNhbuKAmXQgdGhlIE1OIGRpcmVjdGx5IGRv IGl0IHdpdGhvdXQgaW5kaWNhdGluZyB0aGUgcHJlZmVyZW5jZT8NCg0KSG9wZWZ1bGx5IEkg aGF2ZSBtYW5hZ2VkIHRvIGFuc3dlciB0aGF0IHF1ZXN0aW9uIHdpdGggbXkgZWFybGllcg0K Y29tbWVudCBvbiB0aGUgbmVlZCB0byBoYXZlIGNvb3JkaW5hdGVkIFNQRCBvbiB0aGUgTU4g YW5kIEhBLiBTaW5jZQ0KSUtFIGRvZXNuJ3QgYWxsb3cgbW9kaWZpY2F0aW9uIHRvIHRoZSBT UEQsIHRoaXMgaGFzIHRvIGJlIGNvb3JkaW5hdGVkDQp0aHJvdWdoIE1JUHY2IHNpZ25hbGlu ZywNCg0KDQo+ID09PSBTZWN0aW9uIDMNCj4NCj4gIiDCoGFuZCBmb3IgdGhlIEhBIHRvIG92 ZXJyaWRlIHRoYXQgcHJlZmVyZW5jZSBiYXNlZA0KPiDCoCBvbiB0aGUgcG9saWN5IHNldHRp bmdzLiAiDQo+IFtTdGVmYW5vXSBJbiB0aGUgc2FtZSB3YXksIGlmIHRoZSBNTiBhdCBhbnkg dGltZSBkZWNpZGVzIHRvIGVzdGFibGlzaCBhbiBTQSBmb3IgdGhlIHVzZXIgcGxhbmUsIHdo eSBjYW7igJl0IGl0IGRvIGl0IGJhc2VkIG9uIFJGQyA0ODc3LCBzaW5jZSB0aGUgSEEgY2Fu IGFjY2VwdCBpdCBvciBkZW55IHRoZSBNTiByZXF1ZXN0IGFueXdheT8NCj4NCj4NCj4gSW4g Z2VuZXJhbCwgSSBoYXZlIHRoZSBzYW1lIGNvbmNlcm4gZXhwcmVzc2VkIGluIEJlaWppbmcg YXMgdG8gaG93IHRoZSBIQSBrbm93cyB3aGV0aGVyIGFuIGFjY2VzcyBpcyB0cnVzdGVkL3Vu dHJ1c3RlZCBhbmQgd2hldGhlciB0aGVyZSBpcyB0aGUgbmVlZCBmb3IgdXNlciBwbGFuZSBz ZWN1cml0eSwgYW5kIHRoZXJlZm9yZSBob3cgdGhlIEhBIGNhbiBkZWNpZGUgdG8gdHJpZ2dl ciB0aGUgc2VjdXJpdHkgZXN0YWJsaXNobWVudCBpbiBhIG1lYW5pbmdmdWwvZWR1Y2F0ZWQg d2F5LiBUcnVzdGVkL3VudHJ1c3RlZCBpcyBub3QganVzdCBhIGRlY2lzaW9uIGJhc2VkIG9u IHRoZSBhdmFpbGFibGUgZW5jcnlwdGlvbiBvdmVyIHRoZSByYWRpbyBpbnRlcmZhY2UsIGJ1 dCBhbHNvIGEgcm9hbWluZyBhZ3JlZW1lbnQuIEUuZy4gYSBnaXZlbiBXTEFOIGNhbiBiZSB0 cnVzdGVkIGZvciBvbmUgb3BlcmF0b3IgYnV0IHVudHJ1c3RlZCBmb3IgYW5vdGhlciBvbmUs IGFuZCBpdCBjb3VsZCBldmVuIGJlIHRydXN0ZWQgZm9yIG9uZSB1c2VyIChlLmcuIGEgdXNl ciB0aGF0IGFueXdheSBrbm93cyBpdCBuZWVkcyB0byBydW4gVlBOIHRvIGNvbm5lY3QgdG8g dGhlIGRlc2lyZWQgc2VydmljZXMpIGJ1dCB1bnRydXN0ZWQgZm9yIGFub3RoZXIgb25lLiBU aGUgSEEgY2Fubm90IGtub3cgc3VjaCBpbmZvcm1hdGlvbi4gSW4gdGhlIGNhc2Ugb2YgM0dQ UCBuZXR3b3JrcywgYXMgaXQgd2FzIGRpc2N1c3NlZCBpbiBCZWlqaW5nLCB0aGUgdHJ1c3Rl ZC91bnRydXN0ZWQgZGVjaXNpb24gaXMgcGVyZm9ybWVkIGVpdGhlciBieSB0aGUgTU4gKGJh c2VkIG9uIHByZWNvbmZpZ3VyZWQgaW5mb3JtYXRpb24pIG9yIGJ5IHRoZSBBQUEgaW5mcmFz dHJ1Y3R1cmUgdGhhdCBhdXRoZW50aWNhdGVzIHRoZSBNTiBhY2Nlc3MgdG8gdGhlIHNwZWNp ZmljIGFjY2VzcyBuZXR3b3JrLiBQbGVhc2Ugbm90ZSB0aGF0IHN1Y2ggYXV0aGVudGljYXRp b24gaXMgc2VwYXJhdGUgZm9yIHRoZSBEU01JUHY2IGF1dGhlbnRpY2F0aW9uIGluIDNHUFAs IGFuZCB0aGF0IHRoZSB0cnVzdGVkL3VudHJ1c3RlZCBkZWNpc2lvbiBwZXJmb3JtZWQgZHVy aW5nIHRoZSBmaXJzdCBhdXRoZW50aWNhdGlvbiBpcyBub3Qgc3RvcmVkIGFuZCAicmVtZW1i ZXJlZCIgc28gdGhhdCBpdCBjYW4gYmUgcHJvdmlkZWQgdG8gdGhlIEhBLiBBZ2FpbiwgdGhp cyB3ZXJlIHRoZSBjb21tZW50cyBJIHJhaXNlZCBpbiBCZWlqaW5nLg0KDQpGcm9tIG15IHNp ZGUsIEkgYmVsaWV2ZSB0aGUgbWFpbiB1c2VjYXNlIGlzIG9uZSBpbiB3aGljaCB0aGUgTU4N CnVuaWxhdGVyYWxseSBkZWNpZGUgd2hldGhlciB0byB1c2UgZW5jcnlwdGlvbiBvciBub3Qg KGJhc2VkIG9uIEwyDQplbmNyeXB0aW9uIGJlaW5nIE9OIG9yIE9GRiwgYW5kIHBvc3NpYmx5 IHdoaXRlbGlzdHMgcHVsbGVkIHRocm91Z2gNCkFORFNGIG9yIG90aGVyIHBvbGljeSBzdG9y ZSBleHRlbnNpb25zLCBvciB1c2VyIHByZWZlcmVuY2VzKSBhbmQNCmluZm9ybXMgdGhlIEhB IGFib3V0IGl0cyBjaG9pY2Ugc28gdGhhdCB0aGUgU1BEIGFyZSBhbGlnbmVkIG9uIGJvdGgN CnNpZGVzLCB0aHVzIHJlc3VsdGluZyBpbiBJS0V2MiBlc3RhYmxpc2hpbmcgb3Igbm90IHRo ZSByZXF1aXJlZCBJUHNlYw0KU0FzIHRvIGFmZm9yZCBwcm90ZWN0aW9uIHRvIHVzZXIgcGxh bmUgcGFja2V0cy4NCg0KPiBPdmVyYWxsLCBhcyBJIGV4cHJlc3NlZCBpbiBCZWlqaW5nLCBJ IGFtIG5vdCBzdXJlIEkgc2VlIHRoZSBuZWVkIGZvciB0aGlzIHNvbHV0aW9uIGFuZCBpdHMg YXBwbGljYWJpbGl0eSB0byBlLmcuIDNHUFAsIGFzIGluZGljYXRlZCBpbiB0aGUgZHJhZnQu IFBlcmhhcHMgSSBuZWVkIHRvIGJlIGZ1cnRoZXIgZWR1Y2F0ZWQsIGJ1dCB0aGUgZHJhZnQg YXQgcHJlc2VudCBkb2VzIG5vdCBjbGFyaWZ5IHdoeSBhbiBhZGRpdGlvbmFsIHNvbHV0aW9u IGlzIG5lZWRlZC4NCg0KSG9wZWZ1bGx5IEkgaGF2ZSBjbGFyaWZpZWQgd2h5IEkgdGhpbmsg dGhpcyBpcyB1c2VmdWwuDQoNCi0tanVsaWVuDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpUaGlzIHRy YW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29u ZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcg bWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFw cGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1h dGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFu IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBy ZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlv dXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9k dWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBp cyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0K From julien.ietf@gmail.com Wed Feb 9 16:14:47 2011 Return-Path: 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 0692A3A67AD for ; Wed, 9 Feb 2011 16:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 4pPMe0JfqjLU for ; Wed, 9 Feb 2011 16:14:45 -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 989153A65A6 for ; Wed, 9 Feb 2011 16:14:44 -0800 (PST) Received: by fxm9 with SMTP id 9so855273fxm.31 for ; Wed, 09 Feb 2011 16:14:54 -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=fZgFKvD9cZ4NdNM4AWcv42DTr+gEwA/EaJE9To6t0nc=; b=R8ExSxEEJKvUkLubN6X5L54yttfg2KER3tRsYaOtLSYOUSCcv1DhivoXLChDBzCXQl 7V4HUWXDDF5XmUGWFb1XshxtT1mFSLDij/3HkleFHC1TstKdLV0X10cV26wOBNC2AxEA 2NeUmrTaMK9UXa22tYCViy4RzFlqeYdv05FPY= 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=urdV/3Pm9LfRRLqyKGRMHenMBJLjDX6qF3QSRobe1R474K5bONma3fSlOxNp3icFTE CGUC8eQGf2P+ZjX9QSwjXdfPbzhjC0UlYXkZv4JC0GtV/RLL39B91nu88v0d45spg7A/ J3kj7XEBYis1+446dQ1dVb8cQvoeTLYRflIT8= MIME-Version: 1.0 Received: by 10.103.192.12 with SMTP id u12mr12231724mup.75.1297296894674; Wed, 09 Feb 2011 16:14:54 -0800 (PST) Received: by 10.103.221.9 with HTTP; Wed, 9 Feb 2011 16:14:54 -0800 (PST) In-Reply-To: <680854867F7FD04BB9B06EB8ACA8D5AC05EFEE48@XCH02DFW.rim.net> References: <5ECC386B-CD36-45AE-943D-01F39264242D@gmail.com> <680854867F7FD04BB9B06EB8ACA8D5AC05EFEE0A@XCH02DFW.rim.net> <680854867F7FD04BB9B06EB8ACA8D5AC05EFEE48@XCH02DFW.rim.net> Date: Wed, 9 Feb 2011 16:14:54 -0800 Message-ID: From: Julien Laganier To: Stefano Faccin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: mext@ietf.org Subject: Re: [MEXT] review of draft-bajko-mext-sod-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 00:14:47 -0000 Stefano, The last 3GPP TS 23.402 I've seen is at least incomplete. The reference to 4877 and the statement that "the UE and the HA at any time can request the establishment of a child SA" hold on as long as the MN and HA are in sync regarding what protection to afford to user plane which this draft provides a mean to. --julien On Wed, Feb 9, 2011 at 3:41 PM, Stefano Faccin wrote: > Julien, > Thanks for the reply. > > So, for my clarification, based on your first comment, what 3GPP has adop= ted for securing the user plane traffic for S2c (DSMIPv6) is incorrect, sin= ce it is based on RFC4877 and the fact that the UE and the HA at any time c= an request the establishment of a child SA? > > I am not sure we want to reference something about ANDSF that has not bee= n defined nor discussed yet. It would be pure speculation, especially consi= dering 3GPP already has defined solutions for that. I would drop the refere= nce to ANDSF altogether. > > Stefano Faccin > > Standards Manager > Research In Motion Corporation > 5000 Riverside Drive > Building 6, Brazos East, Ste. 100 > Irving, Texas 75039 USA > Office: (972) 910 3451 > Internal: 820.63451 > : (510) 230 8422 > www.rim.com; www.blackberry.com > > > > =EF=81=90 Consider the environment before printing. > > > -----Original Message----- > From: Julien Laganier [mailto:julien.ietf@gmail.com] > Sent: Wednesday, February 09, 2011 3:23 PM > To: Stefano Faccin > Cc: mext@ietf.org > Subject: Re: [MEXT] review of draft-bajko-mext-sod-01 > > Hi Stefano, > > Thanks for the review! > > I am following up on your comments inline below: > > On Wed, Feb 9, 2011 at 2:43 PM, Stefano Faccin wrote: >> Hello all, >> I finally got to review the draft as promised in Beijing. It seems Jouni= and I completed the review at the same time. I have not yet read all the r= eplies. >> >> =3D=3D=3D Section 1: >> >> " =C2=A0 As per the current specifications for MIP6 and DSMIP6, security= of >> =C2=A0 the user plane traffic is optional. When the MN is attached to 3G= /4G >> =C2=A0 network such as HSPA, LTE or EV-DO, the MN may not require securi= ty >> =C2=A0 for the user plane traffic since these networks already provide >> =C2=A0 ciphering over the air-interface and deploy hop-by-hop security, >> =C2=A0 which makes these networks secure. However the MN may attach to l= ess >> =C2=A0 secure or unsecured accesses such as wireless lan (WLAN) or it ma= y >> =C2=A0 roam in countries where the user may prefer the data between the = MN >> =C2=A0 and the HA to be encrypted (even when using cellular accesses). >> =C2=A0 There is no solution in the protocol specification today which >> =C2=A0 provides the capability to trigger the security for the user plan= e >> =C2=A0 traffic on a need basis." >> [Stefano] when the MN attaches in one of the scenarios indicated (either= the MN is connecting over access technology/network that it does not consi= der secure or it is connecting through a network =E2=80=93 e.g. roaming cel= lular network =E2=80=93 that it does not consider secure), the MN knows thi= s fact (i.e. that it is not secure). Further down in the draft this is stat= ed also by the authors. Then, since the MN knows of the lack of security at= attachment, why can't the MN decide to establish the user plane security r= ight away upon establishment of the connection? The text in the introductio= n seems to imply than in such cases the MN would wait and then a new mechan= ism is needed. > > If the HA has an SPD entry for the user-plane traffic with action set > to PROTECT, the MN will not be able to send cleartext user-plane > packets when the access network it attached to is deemed secure and > thus no user-plane confidentiality protection would be needed. > > Conversely, if the HA has an SPD entry for the user-plane traffic with > action set to BYPASS, the MN will not be able to send IPsec protected > user-plane packets when the access network it attached to is deemed > insecure and thus user-plane confidentiality protection would be > needed. > > Does the above manages to shed some light on why is the mechanism needed? > >> =3D=3D=3D Section 1 >> >> " =C2=A0 The MIP6/DSMIP6 protocols only provide a means to secure the us= er >> =C2=A0 plane traffic but do not provide any mechanisms by which the >> =C2=A0 security is triggered as a result of mobility or the MN attaching >> =C2=A0 via different access networks." >> >> [Stefano] in my understanding, RFC4877 allows the MN to establish the se= curity for the user plane traffic at any time (as the authors also state in= section 2). What triggers the MN to do so is of course outside the scope o= f RFC4877, but it should be outside the scope of this draft also. If we don= 't consider what triggers the MN to establish the SA for the user plane, it= seems to me that RF4877 is sufficient. Please note that as a example 3GPP = has already adopted RFC4877 for securing the user plane on the S2c interfac= e (DSMIPv6) where the MN or the HA at any time can establish a child SA for= securing the user plane. That is to me clearly on-demand user plane securi= ty based on whatever criteria the MN and the HA implement to trigger the se= curity establishment. > > Although it is true establishment of IPsec SAs affording > confidentiality and/or integrity protection to user plane packets can > be initiated by the MN at any time, establishment of these SAs is > contingent to the IPsec SPD on both the MN and the HA specifying that > such protection be afforded to user plane traffic. Further, in the > presence of such SPD entries on the MN and HA, absence of the IPsec > SAs means not that traffic will be past clear text. On the contrary, > traffic will be buffered and/or discarded while the MN attempt to > establish the IPsec SAs required as per the SPD. > > Conversely, in the absence of such SPD entries, the MN and HA will > never attempt establishment of IPsec SAs affording protection to user > plane packets. Further, if only the MN changes its SPD to require > protection but the HA hasn't (based on the signaling hereby proposed), > IKEv2 exchange will not lead to the HA accepting to establish such > SAs. > >> =3D=3D=3D Section 2 >> >> " =C2=A0 The MN has either a stored policy about trusted and untrusted a= ccess >> =C2=A0 networks or it may be provided with such information from policy >> =C2=A0 stores such as the ANDSF [23.402] or AAA server at the time of >> =C2=A0 network attachment." >> >> [Stefano] unfortunately I believe that quoting ANDSF as specified in 3GP= P in 23.402 as the entity that may provide information to the MN on whether= a network is trusted or untrusted is incorrect. 23.402 (and in particular = the stage 3 in 24.302 and 24.312) do not contain such information that can = be conveyed to the MN. > > Agree that in its current form the ANDSF takes no position on whether > or not a network should be considered as trusted. This may change > however, so maybe rewording into "[...] =C2=A0from extensions to policy > stores such as the ANDSF [23.402] or AAA server at the time of network > attachment." would ease your concern? > > Another thing I'd like to see reference in this draft is the > possibility to use the presence or the absence of link layer > confidentiality protection as an input to the MN requesting > confidentiality protection. In wireless system, the first over-the-air > hop is the most vulnerable to eavesdropping. > >> =3D=3D=3D Section 2 >> >> "An interface exists generally between the policy >> =C2=A0 store such as AAA or ANDSF and the Home Agent (HA)." >> >> [Stefano] I need to disagree with this statement, as indicated in Beijin= g. There is no interface in 3GPP defined between the ANDSF and the HA, ther= efore the statement is incorrect. >> >> =3D=3D=3D Section 2 >> >> "The MN or HA can =C2=A0determine when to use security for the user plan= e >> =C2=A0 traffic using static policies or dynamic policies which can be >> =C2=A0 obtained at the time of network attachment; or e.g. which are >> =C2=A0 provisioned and maintained on a smartcard (eg, a UICC or SIM). 3G= PP >> =C2=A0 policy stores such as the ANDSF can also provide information abou= t >> =C2=A0 the access networks to which an MN is attached. Location of the M= N >> =C2=A0 can also be used as input. " >> >> [Stefano] for sake of clarity, can we say "3GPP >> =C2=A0 policy stores such as the ANDSF can also provide to the MN inform= ation about >> =C2=A0 the access networks to which an MN is attached " >> >> =3D=3D=3D Section 3 >> >> " =C2=A0 This document proposes extensions to MIPv6/DSMIPv6 protocol, >> =C2=A0 allowing the MN to signal to the HA its preference for user plane >> =C2=A0 traffic security >> " >> >> [Stefano] I am wondering why the MN needs to signal its preference. If t= he MN at any time wants to setup a child SA, why can=E2=80=99t the MN direc= tly do it without indicating the preference? > > Hopefully I have managed to answer that question with my earlier > comment on the need to have coordinated SPD on the MN and HA. Since > IKE doesn't allow modification to the SPD, this has to be coordinated > through MIPv6 signaling, > > >> =3D=3D=3D Section 3 >> >> " =C2=A0and for the HA to override that preference based >> =C2=A0 on the policy settings. " >> [Stefano] In the same way, if the MN at any time decides to establish an= SA for the user plane, why can=E2=80=99t it do it based on RFC 4877, since= the HA can accept it or deny the MN request anyway? >> >> >> In general, I have the same concern expressed in Beijing as to how the H= A knows whether an access is trusted/untrusted and whether there is the nee= d for user plane security, and therefore how the HA can decide to trigger t= he security establishment in a meaningful/educated way. Trusted/untrusted i= s not just a decision based on the available encryption over the radio inte= rface, but also a roaming agreement. E.g. a given WLAN can be trusted for o= ne operator but untrusted for another one, and it could even be trusted for= one user (e.g. a user that anyway knows it needs to run VPN to connect to = the desired services) but untrusted for another one. The HA cannot know suc= h information. In the case of 3GPP networks, as it was discussed in Beijing= , the trusted/untrusted decision is performed either by the MN (based on pr= econfigured information) or by the AAA infrastructure that authenticates th= e MN access to the specific access network. Please note that such authentic= ation is separate for the DSMIPv6 authentication in 3GPP, and that the trus= ted/untrusted decision performed during the first authentication is not sto= red and "remembered" so that it can be provided to the HA. Again, this were= the comments I raised in Beijing. > > From my side, I believe the main usecase is one in which the MN > unilaterally decide whether to use encryption or not (based on L2 > encryption being ON or OFF, and possibly whitelists pulled through > ANDSF or other policy store extensions, or user preferences) and > informs the HA about its choice so that the SPD are aligned on both > sides, thus resulting in IKEv2 establishing or not the required IPsec > SAs to afford protection to user plane packets. > >> Overall, as I expressed in Beijing, I am not sure I see the need for thi= s solution and its applicability to e.g. 3GPP, as indicated in the draft. P= erhaps I need to be further educated, but the draft at present does not cla= rify why an additional solution is needed. > > Hopefully I have clarified why I think this is useful. > > --julien > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > From sgundave@cisco.com Wed Feb 9 17:41:21 2011 Return-Path: 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 E66F23A682C for ; Wed, 9 Feb 2011 17:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.07 X-Spam-Level: X-Spam-Status: No, score=-10.07 tagged_above=-999 required=5 tests=[AWL=0.529, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 JVhAlcq8gPi9 for ; Wed, 9 Feb 2011 17:41:21 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 12B853A682B for ; Wed, 9 Feb 2011 17:41:21 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPrQUk2rR7Ht/2dsb2JhbAClanOfT5suhVwEhH+GcYM4gwQ X-IronPort-AV: E=Sophos;i="4.60,449,1291593600"; d="scan'208";a="257877891" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 10 Feb 2011 01:41:32 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1A1fWq6028760; Thu, 10 Feb 2011 01:41:32 GMT Received: from xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 17:41:31 -0800 Received: from 10.32.243.23 ([10.32.243.23]) by xmb-sjc-21b.amer.cisco.com ([171.70.151.143]) with Microsoft Exchange Server HTTP-DAV ; Thu, 10 Feb 2011 01:41:31 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Wed, 09 Feb 2011 17:42:16 -0800 From: Sri Gundavelli To: jouni korhonen , Message-ID: Thread-Topic: [MEXT] review of draft-gundavelli-mext-dsmip-ipv4-overlap-01 Thread-Index: AcvIw78SVoJiiEENSkaEbYRLwxAgFg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 Feb 2011 01:41:31.0947 (UTC) FILETIME=[A4D017B0:01CBC8C3] Subject: Re: [MEXT] review of draft-gundavelli-mext-dsmip-ipv4-overlap-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 01:41:22 -0000 Hi Jouni: Thanks for the review. Response below. On 2/9/11 2:40 AM, "jouni korhonen" wrote: > Hi, > > In beijing meeting I volunteered to review > draft-gundavelli-mext-dsmip-ipv4-overlap-01. > > Some content concerning comments follow. > > address is not uniquely assigned to a single mobile node. The > home agent MUST make the forwarding decision based on the context > identifier that is associated with the received packet and the > context identifier in the Binding Cache entry. > > This is an implementation issue.. entirely. It can be a context identifier > (any kind that suffices for the purpose) or the whole HA instance can be > running in a separate routing context. > Ok. Can be reworded. > o In deployments where the home agent is supporting hosted home > agent service model, the context identifier field of the Binding > Cache entry MUST be set to the identifier of the tunnel > established between the home agent and the enterprise gateway. > > Implementation issue again. I do not see why the HA or binding cache internal > implementation is enforced here using RFC2119 language. > We need additional parameters in the BCE state. BCE is a conceptual entry, an implementation may choose to build it differently. Fine. Will reword it to reflect general guidance. > Actually most material in Section 4.1.2. Signaling Considerations are purely > internal to HA implementation. I do not really see a compelling reason why to > document these. In past when we standardized GRE encap for PMIP6 that had > similar concerns regarding the LMA. However, that was a different case as we > got an impact also on wire and specification of new signaling. > There is some behavior expected from the home agent. We need to specify how to implement the feature and this needed, IMO. > In Section 4.2. Mobile Node Considerations it is stated: > > This specification does not introduce any new considerations for the > mobile node implementation. The IPv4 private address assigned from > > If this document has no on wire protocol implications, then there is no > interoperability issues from the protocol point of view. The HA product either > supports overlapping private addresses or does not. Therefore, I cannot really > see why the document aims to be a Proposed Standard? It could be Informational > if these points of the HA internal workings has to be documented. So, I would > say that Informational without any RFC2119 language is OK. > Fair Point. We can have that discussion. > However, the assigned addresses MUST be unique within the 3GPP APN > scope (Ex: @internetsvcs.cisco.com). The default value for this > > I would give a reference to APN and a short description of it as APN is such > an alien concept within IETF. Also the example "@internetsvcs.cisco.com" is > incorrect if it attempts to give an example of an APN (there is no '@' in > APN). > Not after Service Selection Option was standardized and draft-korhonen-v6ops was published, I thought ? Sure, I can add. Thanks again for the review. Regards Sri > > - Jouni > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext From kleung@cisco.com Wed Feb 9 20:04:56 2011 Return-Path: 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 D722B3A6850 for ; Wed, 9 Feb 2011 20:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 i3DHbMcgbxK6 for ; Wed, 9 Feb 2011 20:04:51 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 9A68C3A6867 for ; Wed, 9 Feb 2011 20:04:51 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAPfyUk2rRN+J/2dsb2JhbACCSqMgc59amyyFXASEf4op X-IronPort-AV: E=Sophos;i="4.60,450,1291593600"; d="scan'208,217";a="257905301" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 10 Feb 2011 04:05:02 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p1A452lt013599 for ; Thu, 10 Feb 2011 04:05:02 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 Feb 2011 20:05:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC8D7.B108492F" Date: Wed, 9 Feb 2011 20:03:15 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520E0A8085@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-bajko-mext-sod-01 Thread-Index: AcvI13EVOsLIM6H0RGuabPoQ0C4Syw== From: "Kent Leung (kleung)" To: X-OriginalArrivalTime: 10 Feb 2011 04:05:02.0602 (UTC) FILETIME=[B129C6A0:01CBC8D7] Subject: [MEXT] draft-bajko-mext-sod-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 04:04:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC8D7.B108492F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the last IETF meeting, I signed up to review this draft and provide my comments to the WG. Some may already be discussed. =20 1) Sect. 1: s/cellular accesses/cellular access networks/ 2) Sect. 1: "that would unnecessarily consume resources on the HA and radio resources on the access network" 3) Sect. 1: HA control is mentioned in "Furthermore, the operator of HA may have policies .. security is to be used". But later "HA has no ability to force the MN to secure user traffic". Clarify if SoD is designed to include HA control in addition to MN control. 4) Sect. 2: s/wifi_SSID/WiFi SSID/ 5) Sect. 2: Why MAC_address of the wifi network? Generally, it's the WIFI SSID. Probably better to cover general logic and not get into specific features. 6) Sect. 2: "MN has either a stored policy ... or it may be provided with such information from policy stores such as ANDSF [23.402] or AAA server ..." There is no interface between MN and AAA server. So not clear how MN is able to obtain info stored on AAA server. Also, PCRF may be another policy store. 7) Sect. 2: "HA may require that the user plane traffic be encrypted on the MN-HA link". No description of how this can be accomplished. 8) Sect. 3: 'S' bit indicates encryption for user traffic. But it's not clear how encryption can be applied? =20 9) Sect. 3: What happens if MN does not encrypt after HA overwrites with S bit set to one? 10) Sect. 3: What happens if MN encrypt when HA does not want that? 11) Sect. 3: There is no description of HA triggered SoD, though HA control was implied in Sect. 1. 12) Sect 4.2: What this option is in the draft? Location information can be used for many types of operation, not specific to SoD 13) Sect. 5.: Hmm, Type value reservation needs IANA. 14) Sect. 6: It's not clear if there is no impact to the security model until further explanation provided on how the encryption is applied. =20 Overall, the I-D is a good start on the idea of SoD. It needs more clarification on how the S bit interact with the mechanism that actually provides the encryption/decryption function. Also, how does SoD work when IKE/IPSec is providing the encryption/decryption. =20 =20 Kent =20 ------_=_NextPart_001_01CBC8D7.B108492F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the = last IETF meeting, I signed up to review this draft and provide my = comments to the WG.  Some may already be = discussed.

 

1)      = Sect. 1: s/cellular accesses/cellular access = networks/

2)      = Sect. 1: “that would unnecessarily consume = resources on the HA and radio resources on the access = network”

3)      = Sect. 1: HA control is mentioned in = “Furthermore, the operator of HA may have policies .. security is = to be used”.  But later “HA has no ability to force the = MN to secure user traffic”.  Clarify if SoD is designed to = include HA control in addition to MN control.

4)      = Sect. 2: s/wifi_SSID/WiFi SSID/

5)      = Sect. 2: Why MAC_address of the wifi = network?  Generally, it’s the WIFI SSID.  Probably = better to cover general logic and not get into specific = features.

6)      = Sect. 2: “MN has either a stored policy = … or it may be provided with such information from policy stores = such as ANDSF [23.402] or AAA server …” There is no = interface between MN and AAA server.  So not clear how MN is able = to obtain info stored on AAA server.  Also, PCRF may be another = policy store.

7)      = Sect. 2: “HA may require that the user = plane traffic be encrypted on the MN-HA link”.  No = description of how this can be accomplished.

8)      = Sect. 3: ‘S’ bit indicates = encryption for user traffic.  But it’s not clear how = encryption can be applied? 

9)      = Sect. 3: What happens if MN does not encrypt = after HA overwrites with S bit set to one?

10)   = Sect. 3: What happens if MN encrypt when HA does = not want that?

11)   = Sect. 3: There is no description of HA triggered = SoD, though HA control was implied in Sect. 1.

12)   = Sect 4.2: What  this option is in the = draft?  Location information can be used for many types of = operation, not specific to SoD

13)   = Sect. 5.: Hmm, Type value reservation needs = IANA.

14)   = Sect. 6: It’s not clear if there is no = impact to the security model until further explanation provided on how = the encryption is applied.

 

Overall, the = I-D is a good start on the idea of SoD.  It needs more = clarification on how the S bit interact with the mechanism that actually = provides the encryption/decryption function.  Also, how does SoD = work when IKE/IPSec is providing the encryption/decryption.  =

 

Kent

 

------_=_NextPart_001_01CBC8D7.B108492F-- From jouni.nospam@gmail.com Wed Feb 9 23:48:50 2011 Return-Path: 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 271633A68CB for ; Wed, 9 Feb 2011 23:48:50 -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 tOuNst3fqAx2 for ; Wed, 9 Feb 2011 23:48:47 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 9708F3A68AE for ; Wed, 9 Feb 2011 23:48:47 -0800 (PST) Received: by bwz12 with SMTP id 12so1961653bwz.31 for ; Wed, 09 Feb 2011 23:48:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=zHQvJwkUdMafSPoHEMyLAhSAJsYS+9sOcfhZe68m/qU=; b=SKMkcMgZ7Vp/hVvvVXPHbMaBqSS16XyL7bDkdeQ21ILOnsOX8yIu+lPs4J+vfEvYIh CdHStSP04KqAzrapUErwE36aG9aof/MEhZDRAYlyf5cS9N+q0k895K3BhUSe9l+aaQk1 JILceomQF5XCq8JkR1eRHmsupFr36cIa7mjL4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=qtrg9oCQj+MscGaCgyNhuPMO/7PfzwT0+LkkdBokjWfA7MbaRKk4D/P/nuuYrEDs60 GwnVYxYN3/IOyXVxYBx787xeLIW/pg0wwelu3Kg8kLK+843+Nv01DgVINPUIoSvAEGpC aLmYGVOERNeBVQXm6jba68Pvm87pd7b49IF6M= Received: by 10.204.138.142 with SMTP id a14mr1166614bku.197.1297324138350; Wed, 09 Feb 2011 23:48:58 -0800 (PST) Received: from a88-112-143-79.elisa-laajakaista.fi (a88-112-143-79.elisa-laajakaista.fi [88.112.143.79]) by mx.google.com with ESMTPS id z18sm768698bkf.8.2011.02.09.23.48.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 09 Feb 2011 23:48:57 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Thu, 10 Feb 2011 09:48:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sri Gundavelli X-Mailer: Apple Mail (2.1078) Cc: mext@ietf.org Subject: Re: [MEXT] review of draft-gundavelli-mext-dsmip-ipv4-overlap-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 07:48:50 -0000 Hi Sri, On Feb 10, 2011, at 3:42 AM, Sri Gundavelli wrote: >=20 >> However, the assigned addresses MUST be unique within the 3GPP = APN >> scope (Ex: @internetsvcs.cisco.com). The default value for this >>=20 >> I would give a reference to APN and a short description of it as APN = is such >> an alien concept within IETF. Also the example = "@internetsvcs.cisco.com" is >> incorrect if it attempts to give an example of an APN (there is no = '@' in >> APN). >>=20 >=20 > Not after Service Selection Option was standardized and = draft-korhonen-v6ops > was published, I thought ? Sure, I can add. Right ;) A reference to draft-korhonen-v6ops section 2.2 would probably = do.. - JOuni >=20 > Thanks again for the review. >=20 > Regards > Sri >=20 >=20 >>=20 >> - Jouni >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >=20 From alper.yegin@yegin.org Sat Feb 12 01:17:51 2011 Return-Path: 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 78F583A6A70 for ; Sat, 12 Feb 2011 01:17:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.149 X-Spam-Level: X-Spam-Status: No, score=-101.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449, 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 XphyyMs3-6Yj for ; Sat, 12 Feb 2011 01:17:48 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 8F5203A691E for ; Sat, 12 Feb 2011 01:17:48 -0800 (PST) Received: from ibm (dsl88-247-34762.ttnet.net.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0Lb441-1QYqB41gXB-00kMfZ; Sat, 12 Feb 2011 04:18:04 -0500 From: "Alper Yegin" To: , Date: Sat, 12 Feb 2011 11:17:59 +0200 Message-ID: <14fc01cbca95$c1fd9370$45f8ba50$@yegin@yegin.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_14FD_01CBCAA6.85866370" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvKlbYpTSAY67aUS3Gy33tPKL0w4w== Content-Language: en-us x-cr-hashedpuzzle: AkI7 C2cb Eza5 FPne FQlf Humb JdMd J+4t K3LD Okha QeQv UOYB VA07 V3bJ WAVi WGys; 2; agB1AGwAaQBlAG4AbABAAHEAdQBhAGwAYwBvAG0AbQAuAGMAbwBtADsAbQBlAHgAdABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {CEDF1DC2-1DDB-45B1-BC52-44557AC27068}; YQBsAHAAZQByAC4AeQBlAGcAaQBuAEAAeQBlAGcAaQBuAC4AbwByAGcA; Sat, 12 Feb 2011 09:17:46 GMT; bQBlAHgAdAAtAGMAZwBhAC0AMAAxAA== x-cr-puzzleid: {CEDF1DC2-1DDB-45B1-BC52-44557AC27068} X-Provags-ID: V02:K0:YCkjViCVRlQWvRL++EmoPZigV7t3VQJwIBtu8AQRLPd mPl3K26x4RM8hCzx6sCFao6mI0LWt0X4qSp/pt1VpDf9I5HHj2 MMnZ3PTJrSO8hzTTwKgtuIFTpsPlHtDMT3f4sFIBDOh0ldXfsV jHcM2xMBMJIYhy9DOCJ2G2seC+81a/XMxIlhnaPRs1UYkMOzg9 g+xpt+ZlzCr2MQg8Hz1uRinchmgnl4lhIdINdApjTI= Subject: [MEXT] mext-cga-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Feb 2011 09:17:51 -0000 This is a multipart message in MIME format. ------=_NextPart_000_14FD_01CBCAA6.85866370 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Julien, and MEXT members, I can have a MN that simply generates a CGA-based HoA by knowing the prefix served by the HA implementing this I-D, and get its BU accepted. The HA has no way to know whether this MN is authorized to be served (irrespective of the choice of HoA) or not. So, although I see this I-D serves a purpose by ensuring HoA ownership, I don't see how it achieves general "BU authorization". Probably this solution's applicability shall reflect that, or some complimentary technique needs to be identified in order to complete the picture. Alper ------=_NextPart_000_14FD_01CBCAA6.85866370 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Julien, and MEXT members,

 

 

I can have a MN that simply generates a CGA-based = HoA by knowing the prefix served by the HA implementing this I-D, and get its = BU accepted.

The HA has no way to know whether this MN is = authorized to be served (irrespective of the choice of HoA) or not.

 

So, although I see this I-D serves a purpose by = ensuring HoA ownership, I don’t see how it achieves general “BU = authorization”.

 

Probably this solution’s applicability shall = reflect that, or some complimentary technique needs to be identified in order to complete the picture.

 

Alper

 

 

 

 

 

 

------=_NextPart_000_14FD_01CBCAA6.85866370-- From julien.ietf@gmail.com Wed Feb 16 22:41:06 2011 Return-Path: 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 438143A6CE6 for ; Wed, 16 Feb 2011 22:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.182 X-Spam-Level: X-Spam-Status: No, score=-3.182 tagged_above=-999 required=5 tests=[AWL=0.417, 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 cGuZthKnXjjp for ; Wed, 16 Feb 2011 22:41:02 -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 277C63A6CDB for ; Wed, 16 Feb 2011 22:41:01 -0800 (PST) Received: by fxm9 with SMTP id 9so2380275fxm.31 for ; Wed, 16 Feb 2011 22:41:31 -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=jtBWRl6yue4zWmmgl3bXbDOymycqser4YNsHOhB1Z+g=; b=QlDh+Vz+KXnDV4uCl8tqWAqV9h2p8tVVSsdzIkTROKx6wMbwEybXHlZCibec2DK8BP /UIxnFvjCz3o65qmjX5ELfZQibf5F73Ok0S7BWHeb76NJHxk1ELKzrXPb3f4tCEz/xxJ 9K4lTWNquA0pArsw9eFBdD0yQMQOx/PAWkub8= 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=URNqOMmkf7jdmC/BIPioWJ3bHm0nQm3SIwwMB64tS0ndMtOpazuhkqA3/3e+7y2CZj L2kf06lbWW/ZPaqLzbr3i0cAQW0VwavWRJ19OT1owveDUHOTna07yA5NbyDBySwvCHVg ChoTseGK+stV1DqRVmRrJT/AsHVjg55k6PZaQ= MIME-Version: 1.0 Received: by 10.223.71.200 with SMTP id i8mr1905793faj.142.1297924890345; Wed, 16 Feb 2011 22:41:30 -0800 (PST) Received: by 10.223.74.142 with HTTP; Wed, 16 Feb 2011 22:41:30 -0800 (PST) In-Reply-To: <6734441090350776921@unknownmsgid> References: <6734441090350776921@unknownmsgid> Date: Wed, 16 Feb 2011 22:41:30 -0800 Message-ID: From: Julien Laganier To: Alper Yegin Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: julienl@qualcomm.com, mext@ietf.org Subject: Re: [MEXT] mext-cga-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 06:41:06 -0000 Hello Alper, This is an important point about how we authorize a MN to create a BCE in the first place. I've hinted at a couple of ways of doing so during the IETF meeting: - only MN that is on-home-link can create initial BCE, and then it can update from wherever. This would be applicable when we know the MN (almost) always has attachment to home link, e.g., dual mode MN with always on cellular. - only MN that has CoA in some prefix block can create initial BCE, and then it can update from wherever. This would be applicable when we know the MN at some point booted-up in its provider network. We can and should discuss this more. --julien On Sat, Feb 12, 2011 at 1:17 AM, Alper Yegin wrote: > Hello Julien, and MEXT members, > > > > > > I can have a MN that simply generates a CGA-based HoA by knowing the pref= ix > served by the HA implementing this I-D, and get its BU accepted. > > The HA has no way to know whether this MN is authorized to be served > (irrespective of the choice of HoA) or not. > > > > So, although I see this I-D serves a purpose by ensuring HoA ownership, I > don=92t see how it achieves general =93BU authorization=94. > > > > Probably this solution=92s applicability shall reflect that, or some > complimentary technique needs to be identified in order to complete the > picture. > > > > Alper > > > > > > > > > > > > > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > > From maxpassion@gmail.com Thu Feb 17 02:21:46 2011 Return-Path: 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 9476B3A6C77; Thu, 17 Feb 2011 02:21:46 -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 AZV8I2p9EV-I; Thu, 17 Feb 2011 02:21:45 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 7CEFB3A6B75; Thu, 17 Feb 2011 02:21:45 -0800 (PST) Received: by iwc10 with SMTP id 10so2469752iwc.31 for ; Thu, 17 Feb 2011 02:22:15 -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; bh=TroPgW5XeZKS+mOLikMQY6pA8RBCjIYiGGbQ+jjEL3s=; b=i+MUkXuK0PzvgjnFyGAWZLCXnUoD4XLxTdfnu30hoWbvMn0MF323gbRE/Rt2j34gIY RA9uBVzpu/KYPxMTkDIZnOZtsC1B5v0qmbsv1bvOe6PhmUsyJTGinMT7d4U5aOgTYAgF irg3GI0ZGR30aKpFbNGdN6ilv3Ace2/p96/AA= 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; b=HMMinwnGRmKanvfCWWTffpn1IHqQwNPEOOEHYuauC1NiTRGkSlMAzAZh2q4H5pcfBQ ZV2MdClOMtRm+CKoNinARMVVWLr0+K5/ceHcoD/rtv8VPDTQR0nxGdimJX1kvKXJSrcb UnEYocd1fyI9o8iMOqw/oL2XJXvnI8HifKKIA= MIME-Version: 1.0 Received: by 10.42.241.70 with SMTP id ld6mr2494351icb.124.1297938135883; Thu, 17 Feb 2011 02:22:15 -0800 (PST) Received: by 10.42.219.6 with HTTP; Thu, 17 Feb 2011 02:22:15 -0800 (PST) In-Reply-To: <4D388641.7060405@piuha.net> References: <4D388641.7060405@piuha.net> Date: Thu, 17 Feb 2011 18:22:15 +0800 Message-ID: From: liu dapeng To: Jari Arkko Content-Type: text/plain; charset=ISO-8859-1 Cc: dmm@ietf.org, "mext@ietf.org" Subject: Re: [MEXT] suggest charter item for distributed mobility work X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 10:21:46 -0000 Hi Jari, May I ask whether the charter allowing to do problem/scenarios/gap analysis of DMM? Thanks. Best regards, Dapeng Liu 2011/1/21, Jari Arkko : > The IESG has approved the change to the charter in our telechat today. > > Jari > > _______________________________________________ > MEXT mailing list > MEXT@ietf.org > https://www.ietf.org/mailman/listinfo/mext > From julien.ietf@gmail.com Thu Feb 17 10:47:57 2011 Return-Path: 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 AAF083A6E4E; Thu, 17 Feb 2011 10:47:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[AWL=0.405, 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 5qV2SNWUxMTL; Thu, 17 Feb 2011 10:47:56 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 0CD243A6E52; Thu, 17 Feb 2011 10:47:55 -0800 (PST) Received: by eyd10 with SMTP id 10so1705005eyd.31 for ; Thu, 17 Feb 2011 10:48:27 -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; bh=M1i4Y1GhrEdLBN0PQbBdBlXKyYyvwFaPwAc8E6l0rtk=; b=t/TsZ+s7GJiBxG/xv1mpR9sJaxMHsUN08PnvPVG3r1cUZw+S/rBuGRgSevDqPmXiB1 yUOC2MRdAdkdcR1DDB4AxIB7zG45kR+f+BJFwoKDl5l3Wrv63K0UbpdgNmLVvxuWZpRf 1Fco7dOHpvwD9cyY6IizZ171Mw25H5CdmCLBc= 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; b=KTs8X4P22kwZYv2PlXCBSPW7ISKVZB7TjA7O5pGJcK0NBSCDp3bEpicTv/FrNA5jeQ cmU/x5ul8Q/cbyWGvsHTIpwgYxvC4y25Uj/CESDvcgIfXahwx1IqOCqEOJ4Ly1XkdZP8 k3lPDBpioV81/FCUvPORYRT/MFGJYjAjNh0IM= MIME-Version: 1.0 Received: by 10.223.74.15 with SMTP id s15mr2812640faj.28.1297968506950; Thu, 17 Feb 2011 10:48:26 -0800 (PST) Received: by 10.223.74.142 with HTTP; Thu, 17 Feb 2011 10:48:26 -0800 (PST) In-Reply-To: References: <4D388641.7060405@piuha.net> Date: Thu, 17 Feb 2011 10:48:26 -0800 Message-ID: From: Julien Laganier To: liu dapeng Content-Type: text/plain; charset=ISO-8859-1 Cc: Jari Arkko , dmm@ietf.org, "mext@ietf.org" Subject: Re: [MEXT] [dmm] suggest charter item for distributed mobility work X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 18:47:57 -0000 Hi Dapeng, It's at the usual location: http://www.ietf.org/dyn/wg/charter/mext-charter --julien On Thu, Feb 17, 2011 at 2:22 AM, liu dapeng wrote: > Hi Jari, > > May I ask whether the charter allowing to do problem/scenarios/gap > analysis of DMM? Thanks. > > Best regards, > Dapeng Liu > > 2011/1/21, Jari Arkko : >> The IESG has approved the change to the charter in our telechat today. >> >> Jari >> >> _______________________________________________ >> MEXT mailing list >> MEXT@ietf.org >> https://www.ietf.org/mailman/listinfo/mext >> > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From maxpassion@gmail.com Fri Feb 18 02:48:56 2011 Return-Path: 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 A52993A6C77; Fri, 18 Feb 2011 02:48:56 -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 skfKvaR8rNLB; Fri, 18 Feb 2011 02:48:55 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 06DEF3A6C41; Fri, 18 Feb 2011 02:48:54 -0800 (PST) Received: by iym1 with SMTP id 1so3610043iym.31 for ; Fri, 18 Feb 2011 02:49:28 -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; bh=21t1uMfjczXEr0nQ+O8izE4yMfBvVTw6KDrhG11mV/Q=; b=bO6WUALwgDd3944grsKuZyAj0N3CpD7yQWf0V+cUqQcx5O9PU6WjXSSJW7vd0+mJea T5zxm7qWn4fLppp/TgZP5k670aHqnOwtvL47o+0sfJ3YZsKQ7qx1fcIthomL26nP7q0I +CQjDSgJEKs/Cd2/KAR94FhKBVJ85pNT46O1Y= 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; b=Y2CLOIHCSvnxC0MMztK7SefwyIZhD9zpkTecq3ZUNCBd0xs4bDwxLms638nwbGkZcA TUsXRFE33eJoEV/GPEmBDAFdMe14Ty0JBxmNmkQi3pIFjazCuKNZonMa1/xrJ62LciZw mG4T2yFi6SoM25HKVr2ddoOoHQ2gZFbyuTHQA= MIME-Version: 1.0 Received: by 10.42.230.2 with SMTP id jk2mr677223icb.392.1298026167148; Fri, 18 Feb 2011 02:49:27 -0800 (PST) Received: by 10.42.219.6 with HTTP; Fri, 18 Feb 2011 02:49:26 -0800 (PST) In-Reply-To: References: <4D388641.7060405@piuha.net> Date: Fri, 18 Feb 2011 18:49:26 +0800 Message-ID: From: liu dapeng To: Julien Laganier Content-Type: text/plain; charset=ISO-8859-1 Cc: Jari Arkko , dmm@ietf.org, "mext@ietf.org" Subject: Re: [MEXT] [dmm] suggest charter item for distributed mobility work X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 10:48:56 -0000 Hello Julien, Thanks for the information. But my question is: since the charter is extended to "work on operational considerations on setting up Mobile IPv6 networks so that traffic is distributed in an optimal way". Does it mean that the extended charter include problem/gap/scenario analysis of distributing the mobility anchor (DMM)? I remember it seem that people agreed to do the analysis work of DMM as the first step in Beijing meeting? Regards, Dapeng Liu 2011/2/18, Julien Laganier : > Hi Dapeng, > > It's at the usual location: > > http://www.ietf.org/dyn/wg/charter/mext-charter > > --julien > > On Thu, Feb 17, 2011 at 2:22 AM, liu dapeng wrote: >> Hi Jari, >> >> May I ask whether the charter allowing to do problem/scenarios/gap >> analysis of DMM? Thanks. >> >> Best regards, >> Dapeng Liu >> >> 2011/1/21, Jari Arkko : >>> The IESG has approved the change to the charter in our telechat today. >>> >>> Jari >>> >>> _______________________________________________ >>> MEXT mailing list >>> MEXT@ietf.org >>> https://www.ietf.org/mailman/listinfo/mext >>> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> > From behcetsarikaya@yahoo.com Fri Feb 18 08:30:26 2011 Return-Path: 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 695093A6CA1 for ; Fri, 18 Feb 2011 08:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.466 X-Spam-Level: X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599] 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 648cOqrEGYph for ; Fri, 18 Feb 2011 08:30:25 -0800 (PST) Received: from nm19-vm0.bullet.mail.sp2.yahoo.com (nm19-vm0.bullet.mail.sp2.yahoo.com [98.139.91.216]) by core3.amsl.com (Postfix) with SMTP id 87F243A6FA5 for ; Fri, 18 Feb 2011 08:30:24 -0800 (PST) Received: from [98.139.91.61] by nm19.bullet.mail.sp2.yahoo.com with NNFMP; 18 Feb 2011 16:30:58 -0000 Received: from [98.139.91.10] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 18 Feb 2011 16:30:58 -0000 Received: from [127.0.0.1] by omp1010.mail.sp2.yahoo.com with NNFMP; 18 Feb 2011 16:30:58 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 745364.14941.bm@omp1010.mail.sp2.yahoo.com Received: (qmail 23343 invoked by uid 60001); 18 Feb 2011 16:30:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1298046658; bh=LKcFA4kYRpjX2mnKwu8gWX4DcBCcDb0FnXnjobjnMpw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=3j476ZMMOyeproWfBsC5qumL7CFRN6EqUPBw1/8lrCeN+GeRV+oZDsM33N+tRg+HK0uJC60uGPnGHLuLeevE7e80/R0XlPLT2UwzI4sBtV+oLTng/fXEqPCy/+Dhmf043mP5IQInqY8aO15ZUrzvhFV0NYYeNgohcxJQuYs4Qds= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=m4HK4ntGCUs6D0hWfV52Hy3GGxM0iXMnqFFhkYo/LyV9oHSWALu2EfUa/9OR9rvGd4zC4LXj09AD0Duqw2oN0YYuBQgqDfBxherg1ZP5GQUXuYtiA8yaP31HsKYjAAuhEG/xCYV+9lvfagDfBqX93XHoVjgzDatAylyj1ZS0ulk=; Message-ID: <339086.13026.qm@web111412.mail.gq1.yahoo.com> X-YMail-OSG: K1Qe5EwVM1nEoBXMKKopz1u0Kr1yls4H7wF2CkKlNEdvAV_ iNq8kFa1BkdhutEUl2vn2ZldBSeftlNluFtPG1ctJlWEwRs_6YoR0QzRNTWM qSDSFwJsxMUtMm7JxkMrJiM8ibqfD.79c9xbr7UDw.SxVnE9oLGVtRp_1w1l NKXD06C4.y05zTAYOkOuorj4zvzUaKSSBkaVS.diNRsBzYT_nmvCBqUXGaXf mrWqvmu.123Jr_7h91QSlF2Stohyt_7WLy1IgjFJzgy04ne_KV6mJG1_KpKr 4xykK6yQvwVrCktKUjNRbn.GB0ORWQvD5N.OxyHoBYEauJEk6e1DJWn3.CZT VzJA_LPocQBnE0S0Cusp2mRNShXC88Jt_tXFR9tWb.ESOIjgWtlGmt.SZYb1 bo8LH6KaBGC6P Received: from [206.16.17.212] by web111412.mail.gq1.yahoo.com via HTTP; Fri, 18 Feb 2011 08:30:58 PST X-Mailer: YahooMailRC/555 YahooMailWebService/0.8.109.292656 References: <4D388641.7060405@piuha.net> Date: Fri, 18 Feb 2011 08:30:58 -0800 (PST) From: Behcet Sarikaya To: liu dapeng In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jari Arkko , dmm@ietf.org, "mext@ietf.org" Subject: Re: [MEXT] [dmm] suggest charter item for distributed mobility work X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 16:30:26 -0000 Hi Dapeng, > > Hello Julien, > > Thanks for the information. But my question is: since the charter is > extended to "work on operational considerations on setting up Mobile > IPv6 networks so that traffic is distributed in an optimal way". Does > it mean that the extended charter include problem/gap/scenario > analysis of distributing the mobility anchor (DMM)? > > I remember it seem that people agreed to do the analysis work of DMM > as the first step in Beijing meeting? My understanding is that the new informational document will be inline with Julien's presentation he had in Beijing mext additional session we had on dmm and explain how MIPv6 as defined currently can be used to distribute the traffic in an optimal way. I suggest that you take the lead in this effort. Regards, Behcet From julien.ietf@gmail.com Fri Feb 18 11:28:43 2011 Return-Path: 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 13B6C3A6FA4; Fri, 18 Feb 2011 11:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 hca2KSWHg3tL; Fri, 18 Feb 2011 11:28:41 -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 726E83A6A0F; Fri, 18 Feb 2011 11:28:39 -0800 (PST) Received: by fxm15 with SMTP id 15so477059fxm.31 for ; Fri, 18 Feb 2011 11:29:13 -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; bh=CA9hyjBiaDs+J5KjHZUEKZvLN0wiz4SMHduWhRxd7LI=; b=ovRl2jIbFtZANsCq7FU5iDZb23ZuzsTNOpLg3K03NYxPIYgpaXeLgT2XNtn+/8i2Zg xY57GwzELB6Qg9kM7VHySBs7pyPEorx2r+s53doKQksu10pyab2l1HxxXfQAwZWcDsD+ myL+P8BbZ1Es6U0Mk3I/VPhpZayThPtWsk8ec= 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; b=QEWMPSv3ahjCYNN636QbCBsvL1UzvL17gHuAs/SvbUaop3lFB8wP2PI6yejLAnIkjB 1BlgnUnq0mgA4KmzgilnQPmEN+s35Xev0tMmdO4VdCHRIwh8EdvoiETeyy/XhN8nqlHa QPXlt4BBuwyVJrHkFc3BAe1c63e/odee2/5ds= MIME-Version: 1.0 Received: by 10.223.103.8 with SMTP id i8mr1453335fao.47.1298057305465; Fri, 18 Feb 2011 11:28:25 -0800 (PST) Received: by 10.223.74.142 with HTTP; Fri, 18 Feb 2011 11:28:25 -0800 (PST) In-Reply-To: References: <4D388641.7060405@piuha.net> Date: Fri, 18 Feb 2011 11:28:25 -0800 Message-ID: From: Julien Laganier To: liu dapeng Content-Type: text/plain; charset=ISO-8859-1 Cc: Jari Arkko , dmm@ietf.org, "mext@ietf.org" Subject: Re: [MEXT] [dmm] suggest charter item for distributed mobility work X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 19:28:43 -0000 Hello Dapeng, The problem/gap/scenario analysis would serve as a basis to decide on what are the "operational considerations on setting up Mobile IPv6 networks so that traffic is distributed in an optimal way." --julien On Fri, Feb 18, 2011 at 2:49 AM, liu dapeng wrote: > Hello Julien, > > Thanks for the information. But my question is: since the charter is > extended to "work on operational considerations on setting up Mobile > IPv6 networks so that traffic is distributed in an optimal way". Does > it mean that the extended charter include problem/gap/scenario > analysis of distributing the mobility anchor (DMM)? > > I remember it seem that people agreed to do the analysis work of DMM > as the first step in Beijing meeting? > > Regards, > > Dapeng Liu > 2011/2/18, Julien Laganier : >> Hi Dapeng, >> >> It's at the usual location: >> >> http://www.ietf.org/dyn/wg/charter/mext-charter >> >> --julien >> >> On Thu, Feb 17, 2011 at 2:22 AM, liu dapeng wrote: >>> Hi Jari, >>> >>> May I ask whether the charter allowing to do problem/scenarios/gap >>> analysis of DMM? Thanks. >>> >>> Best regards, >>> Dapeng Liu >>> >>> 2011/1/21, Jari Arkko : >>>> The IESG has approved the change to the charter in our telechat today. >>>> >>>> Jari >>>> >>>> _______________________________________________ >>>> MEXT mailing list >>>> MEXT@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mext >>>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>> >> > From jari.arkko@piuha.net Fri Feb 18 12:25:41 2011 Return-Path: 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 8F8753A6F18; Fri, 18 Feb 2011 12:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, 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 22A05yGZ3fGK; Fri, 18 Feb 2011 12:25:40 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 8CA2F3A6DF1; Fri, 18 Feb 2011 12:25:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 163CA2CC32; Fri, 18 Feb 2011 22:26:14 +0200 (EET) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+ai8yJskidM; Fri, 18 Feb 2011 22:26:13 +0200 (EET) Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 9229B2CC28; Fri, 18 Feb 2011 22:26:13 +0200 (EET) Message-ID: <4D5ED5E5.3080905@piuha.net> Date: Fri, 18 Feb 2011 22:26:13 +0200 From: Jari Arkko User-Agent: Thunderbird 2.0.0.24 (X11/20101027) MIME-Version: 1.0 To: Julien Laganier References: <4D388641.7060405@piuha.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dmm@ietf.org, liu dapeng , "mext@ietf.org" Subject: Re: [MEXT] [dmm] suggest charter item for distributed mobility work X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 20:25:41 -0000 I think the focus should be on determining how to use the existing protocols for optimal distribution. If you start from a gap analysis it would set the focus on finding some case where this isn't possible. Jari From julien.ietf@gmail.com Fri Feb 18 12:35:56 2011 Return-Path: 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 CD7283A6F9B; Fri, 18 Feb 2011 12:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.205 X-Spam-Level: X-Spam-Status: No, score=-3.205 tagged_above=-999 required=5 tests=[AWL=0.394, 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 AwAwiOBqQPTh; Fri, 18 Feb 2011 12:35:56 -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 A48EF3A6E4D; Fri, 18 Feb 2011 12:35:55 -0800 (PST) Received: by fxm15 with SMTP id 15so536456fxm.31 for ; Fri, 18 Feb 2011 12:36:29 -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; bh=kUyZvaeaw39fVry6qBfnBqIpdf08nXY2tRHKyOArMos=; b=AsqJn2ypHo4yk3Z5TfralvmO8kUfSq40YsxrFNOaijA8RzWctEXzN0qDbN7VhM8I+v erwAySTpCYvaFLVrL6r/9Q1IwzXeaQI0AbhM6IgLmLzL23P/I4pdLFXY/z5f5WCL3d8W fQ8wMdQJNvd2XwUyTT10zUYBjy8Vx3buM0LnE= 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; b=Xnt8tQPAK2L58/gZmIJOBvCzVDpHYxVGwofBZX374TWxOTZwO336kM0szJk1sg0GpB kfEwmCrE0nwoWRCOGY+AGgDc+fgrHAAWeqSLiU5XNhnDUVli7HOCZIs6KvDmc6jShLsv qEN79MyrbYAMElhSY4h+5fe6nOIot5txwqYxs= MIME-Version: 1.0 Received: by 10.223.103.8 with SMTP id i8mr1543421fao.47.1298061324279; Fri, 18 Feb 2011 12:35:24 -0800 (PST) Received: by 10.223.74.142 with HTTP; Fri, 18 Feb 2011 12:35:24 -0800 (PST) In-Reply-To: <4D5ED5E5.3080905@piuha.net> References: <4D388641.7060405@piuha.net> <4D5ED5E5.3080905@piuha.net> Date: Fri, 18 Feb 2011 12:35:24 -0800 Message-ID: From: Julien Laganier To: Jari Arkko Content-Type: text/plain; charset=ISO-8859-1 Cc: dmm@ietf.org, liu dapeng , "mext@ietf.org" Subject: Re: [MEXT] [dmm] suggest charter item for distributed mobility work X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 20:35:56 -0000 On Fri, Feb 18, 2011 at 12:26 PM, Jari Arkko wrote: > I think the focus should be on determining how to use the existing protocols > for optimal distribution. If you start from a gap analysis it would set the > focus on finding some case where this isn't possible. That makes sense. --julien From cjbc@it.uc3m.es Tue Feb 22 11:20:36 2011 Return-Path: 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 EC2813A6813 for ; Tue, 22 Feb 2011 11:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, 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 4rPFMiK43gzE for ; Tue, 22 Feb 2011 11:20:34 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 4070B3A6800 for ; Tue, 22 Feb 2011 11:20:33 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id AF4C59959B1; Tue, 22 Feb 2011 20:21:08 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: mext@ietf.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-km04lukWLIO0CSVCAkBt" Organization: Universidad Carlos III de Madrid Date: Tue, 22 Feb 2011 20:22:27 +0100 Message-ID: <1298402547.4584.105.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.5.0.1024-17972.000 Cc: Julien Laganier Subject: [MEXT] Review of draft-laganier-mext-cga-01 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 19:20:37 -0000 --=-km04lukWLIO0CSVCAkBt Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Dear Julien, With a huge delay from my side (I volunteered to do this in the last IETF meeting), here is my review of your draft. Apologies for the delay. - I agree with most of the comments from Jouni and Alper. In particular, I think the draft is a useful piece that is worth to be improved and get published. Major aspects IMHO to be improved: * Terminology section and in general the document: references to other documents are provided and it's a bit hard to follow all the details about how the protocol works. It's true that the protocol is probably defined as is in the detail enough for a developer to implement it, but for the reader is hard to understand everything without going back and forth to check the relevant references. Maybe it'd be good to include some of these details in your draft as well (even if this means we are repeating text that is already there in another IETF document). * Section 5 (Usage scenarios). I think it'd be useful to describe/refer to some real examples where your solution is useful. * The BU authorization issue pointed by Alper is definitely a very good one. - There is another comment that is probably out-of-the-scope of your document and more related to MIPv6. I've always wondered why there is no test on the care-of address of the MN during the home registration. I do not know why it is assumed that a MN cannot try to fool its HA sending a BU containing a fake CoA. Jari raised this issue in the MEXT interim meeting that took place in Madrid (focused on NEMO RO) but somehow I missed the outcome of that discussion. I see this more relevant to your draft, because of the BU authorization issue pointed above. - I also think that section on IPv4 support (at least in its current form) does not really fit well in the document. Thanks, Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-km04lukWLIO0CSVCAkBt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1kDPMACgkQNdy6TdFwT2eL5ACfUJs+q4fu3AiJiFqlB5Plamcb VtgAoKJmbyVU/sD3fwGYsYzFRHCG7YPj =i8gz -----END PGP SIGNATURE----- --=-km04lukWLIO0CSVCAkBt-- From georg.hampel@alcatel-lucent.com Wed Feb 23 11:50:29 2011 Return-Path: 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 CF94D3A6813 for ; Wed, 23 Feb 2011 11:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 RieE98lgGLw5 for ; Wed, 23 Feb 2011 11:50:28 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 8DCB63A67ED for ; Wed, 23 Feb 2011 11:50:26 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p1NJpBNo015886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 23 Feb 2011 13:51:11 -0600 (CST) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p1NJos1W018669 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 23 Feb 2011 13:51:11 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.127]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Wed, 23 Feb 2011 13:50:54 -0600 From: "Hampel, K Georg (K Georg)" To: "mext@ietf.org" Date: Wed, 23 Feb 2011 13:50:53 -0600 Thread-Topic: New Version Notification for draft-hampel-mext-ro-without-ha-00 Thread-Index: AcvTgYw0h7/C7j7fQliou3LOrGFKpAAEM4ew Message-ID: <154773479ED2314980CB638A48FC443483612A78@USNAVSXCHMBSA2.ndc.alcatel-lucent.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-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [MEXT] FW: New Version Notification for draft-hampel-mext-ro-without-ha-00 X-BeenThere: mext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mobile IPv6 EXTensions WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 19:50:29 -0000 All, I have submitted a draft on RO without HA to the repository. http://www.ietf.org/id/draft-hampel-mext-ro-without-ha-00.txt Regards, Georg Hampel From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Wednesday, February 23, 2011 12:45 PM To: Hampel, K Georg (K Georg) Cc: Klein, Thierry E (Thierry) Subject: New Version Notification for draft-hampel-mext-ro-without-ha-00=20 A new version of I-D, draft-hampel-mext-ro-without-ha-00.txt has been succe= ssfully submitted by Georg Hampel and posted to the IETF repository. Filename: draft-hampel-mext-ro-without-ha Revision: 00 Title: Mobile IPv6 Route Optimization without Home Agent Creation_date: 2011-02-23 WG ID: Independent Submission Number_of_pages: 10 Abstract: This document describes extensions to Mobile IPv6 (MIPv6), which=20 permit hosts to conduct route optimization (RO) without home agent. These extensions add robustness and flexibility to MIPv6 since=20 mobility can be supported when the home agent becomes temporarily unavailable or when home-agent support is not desirable. These=20 extensions are compliant with all peer-to-peer signaling=20 solutions that are currently supported for RO. = =20 The IETF Secretariat.