From nobody Fri Aug 1 00:11:02 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C8F41A0417 for ; Fri, 1 Aug 2014 00:11:00 -0700 (PDT) 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=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqugLeJs68wY for ; Fri, 1 Aug 2014 00:10:58 -0700 (PDT) Received: from out46-ams.mf.surf.net (out46-ams.mf.surf.net [145.0.1.46]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C5401A041B for ; Fri, 1 Aug 2014 00:10:57 -0700 (PDT) Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s717Aspp004155; Fri, 1 Aug 2014 09:10:54 +0200 Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.3.181.6; Fri, 1 Aug 2014 09:11:01 +0200 Received: from EXMBX24.ad.utwente.nl ([169.254.4.146]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.03.0181.006; Fri, 1 Aug 2014 09:10:54 +0200 From: To: , Thread-Topic: [netext] Interest to review the Logical Interface ID Thread-Index: AQHPrFsdid6QhDPT+ESQw8VQLKrIm5u7VmK0 Date: Fri, 1 Aug 2014 07:10:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.64.32.138] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F5D57D512EXMBX24adutwent_" MIME-Version: 1.0 X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.49; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0vMxjaSQz - 41be052df03b - 20140801 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/netext/AnRhzPHcXoVNQUebhRXoDnynURE Cc: netext-chairs@ietf.org Subject: Re: [netext] Interest to review the Logical Interface ID X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 07:11:00 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F5D57D512EXMBX24adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Rajeev, Please note that I am interested in reviewing the draft! However, please note that this will happen after the 15th of August! Best regards, Georgios ________________________________ Van: netext [netext-bounces@ietf.org] namens Rajeev Koodli [rajeev.koodli@g= mail.com] Verzonden: donderdag 31 juli 2014 3:02 Aan: netext@ietf.org Onderwerp: [netext] Interest to review the Logical Interface ID Hi, as discussed at the Toronto meeting, we are looking for at least three peop= le who are interested in reviewing the ID: http://tools.ietf.org/html/draft= -ietf-netext-logical-interface-support-09 Please respond if you are interested, and Cc the chairs: netext-chairs@ietf= .org Thanks. -Rajeev --_000_FF1A9612A94D5C4A81ED7DE1039AB80F5D57D512EXMBX24adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Rajeev,

 

Please note that I am interested in reviewing the draft!

However, please note that this will happen after the 15th of August!

 

Best regards,

Georgios

Van: netext [netext-bounces@ietf.org] name= ns Rajeev Koodli [rajeev.koodli@gmail.com]
Verzonden: donderdag 31 juli 2014 3:02
Aan: netext@ietf.org
Onderwerp: [netext] Interest to review the Logical Interface ID


Hi,

as discussed at the Toronto meeting, we are looking for at least three= people who are interested in reviewing the ID: http://tools.ietf.org/html/draft-ietf-netext-logical-interface-suppo= rt-09

Please respond if you are interested, and Cc the chairs: netext-chairs@ietf.org

Thanks.

-Rajeev


--_000_FF1A9612A94D5C4A81ED7DE1039AB80F5D57D512EXMBX24adutwent_-- From nobody Fri Aug 1 01:35:51 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 792A51A010D for ; Fri, 1 Aug 2014 01:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otn8y8SMCh91 for ; Fri, 1 Aug 2014 01:35:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C842B1A00EA for ; Fri, 1 Aug 2014 01:35:47 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 0CC042DC601; Fri, 1 Aug 2014 10:35:46 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C51BE238055; Fri, 1 Aug 2014 10:35:45 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0181.006; Fri, 1 Aug 2014 10:35:45 +0200 From: To: "karagian@cs.utwente.nl" , "rajeev.koodli@gmail.com" , "netext@ietf.org" Thread-Topic: [netext] Interest to review the Logical Interface ID Thread-Index: AQHPrFsbW0Xp5AjmtUqF9854pV7CLJu7NTiAgAA5EtA= Date: Fri, 1 Aug 2014 08:35:44 +0000 Message-ID: <22894_1406882145_53DB5161_22894_8388_1_81C77F07008CA24F9783A98CFD706F7114276615@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F7114276615PEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.1.74819 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/i-VJv_NMgvTlmQ_jxlbzWpzXRaI Cc: "netext-chairs@ietf.org" Subject: Re: [netext] Interest to review the Logical Interface ID X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 08:35:50 -0000 --_000_81C77F07008CA24F9783A98CFD706F7114276615PEXCVZYM12corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I volunteer to review this draft Pierrick De : netext [mailto:netext-bounces@ietf.org] De la part de karagian@cs.utwe= nte.nl Envoy=E9 : vendredi 1 ao=FBt 2014 09:11 =C0 : rajeev.koodli@gmail.com; netext@ietf.org Cc : netext-chairs@ietf.org Objet : Re: [netext] Interest to review the Logical Interface ID Hi Rajeev, Please note that I am interested in reviewing the draft! However, please note that this will happen after the 15th of August! Best regards, Georgios ________________________________ Van: netext [netext-bounces@ietf.org] namens Rajeev Koodli [rajeev.koodli@g= mail.com] Verzonden: donderdag 31 juli 2014 3:02 Aan: netext@ietf.org Onderwerp: [netext] Interest to review the Logical Interface ID Hi, as discussed at the Toronto meeting, we are looking for at least three peop= le who are interested in reviewing the ID: http://tools.ietf.org/html/draft= -ietf-netext-logical-interface-support-09 Please respond if you are interested, and Cc the chairs: netext-chairs@ietf= .org Thanks. -Rajeev ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_81C77F07008CA24F9783A98CFD706F7114276615PEXCVZYM12corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

I voluntee= r to review this draft

 = ;

Pierrick

 = ;

De : nete= xt [mailto:netext-bounces@ietf.org] De la part de karagian@cs.utwente.nl
Envoy=E9 : vendredi 1 ao=FBt 2014 09:11
=C0 : rajeev.koodli@gmail.com; netext@ietf.org
Cc : netext-chairs@ietf.org
Objet : Re: [netext] Interest to review the Logical Interface I= D

 

Hi Rajeev,

 

Please note that I am interested in reviewing th= e draft!

However, please note that this will happen after= the 15th of August!

 

Best regards,

Georgios

Van: netext [netext-bounces@ietf.o= rg] namens Rajeev Koodli [rajeev.koodli@gmail.com]
Verzonden: donderdag 31 juli 2014 3:02
Aan: netext@ietf.org
Onderwerp: [netext] Interest to review the Logical Interface ID

 =

Hi,

 =

as discussed at the Toro= nto meeting, we are looking for at least three people who are interested in= reviewing the ID: http://tools.ietf.org/= html/draft-ietf-netext-logical-interface-support-09

 =

Please respond if you ar= e interested, and Cc the chairs: netext-chairs@i= etf.org

 =

Thanks.

 =

-Rajeev

 =

 = 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_81C77F07008CA24F9783A98CFD706F7114276615PEXCVZYM12corpo_-- From nobody Mon Aug 4 10:56:21 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7551A0091; Mon, 4 Aug 2014 10:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZefSEyJQ8qE; Mon, 4 Aug 2014 10:56:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CD71A00A3; Mon, 4 Aug 2014 10:56:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Adrian Farrel" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140804175615.16238.14171.idtracker@ietfa.amsl.com> Date: Mon, 04 Aug 2014 10:56:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/-F5lcqP5Xh925xfbN2Us9ySqpGc Cc: netext@ietf.org, draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org, netext-chairs@tools.ietf.org Subject: [netext] Adrian Farrel's No Objection on draft-ietf-netext-pmip-cp-up-separation-05: (with COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 17:56:18 -0000 Adrian Farrel has entered the following ballot position for draft-ietf-netext-pmip-cp-up-separation-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I don't object to this document, but I found... > No known implementations of the protocol exist at this time. No > vendors have expressly stated a plan to implement this > specification either. ...a little odd for a Standard Track document, especially since there was apparently such clear consensus that this is a problem that needs to be solved. I guess I am old-fashioned enough to hope for running code from time to time. From nobody Mon Aug 4 13:15:40 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FBE1A0201; Mon, 4 Aug 2014 13:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mp-1O5ZKVu80; Mon, 4 Aug 2014 13:15:34 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4EBB1A01E8; Mon, 4 Aug 2014 13:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2451; q=dns/txt; s=iport; t=1407183334; x=1408392934; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=poXkUqUx0PwJvd5SzXAHgS+Y89Nycgiih+nxSYRh2Bk=; b=aYyUctz02T4+NyH+PMepHQ/pTVzEQYJ/2n/N+igsP3xtvdR3W1ov8f5j kiDHzpaI5Ca0wUTOoVLyYcM+pfsefiNpT8Khv5j3BhbOZZMZVXVtbfy4S gruL8+MZLtIz8ujdePOJs3eql3rFg/jBDXeWak7k+p9pd1FIu668GSJ37 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAKfo31OtJV2Q/2dsb2JhbABbgw1SVwTMMAyGdVMBgRIWd4QEAQEDAQEBATc0CwUNAQg2BTILJQIEAQ0FCYgxCA3EQxeMHYJNEQFQAgWESwWcBoFUkwuCB4FGbAGBDDk X-IronPort-AV: E=Sophos;i="5.01,800,1400025600"; d="scan'208";a="66452876" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP; 04 Aug 2014 20:15:33 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s74KFWvg007381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 20:15:33 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.126]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 15:15:32 -0500 From: "Sri Gundavelli (sgundave)" To: Adrian Farrel , The IESG Thread-Topic: [netext] Adrian Farrel's No Objection on draft-ietf-netext-pmip-cp-up-separation-05: (with COMMENT) Thread-Index: AQHPsCDX3fFbgAeTbkO8iw+b+jOTrA== Date: Mon, 4 Aug 2014 20:15:31 +0000 Message-ID: In-Reply-To: <20140804175615.16238.14171.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.219] Content-Type: text/plain; charset="us-ascii" Content-ID: <643BEF894417A14DA2034D4E88AD3C8A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/Wkjcly18dpET0yvpRLmCwrNK1m4 Cc: "netext@ietf.org" , "netext-chairs@tools.ietf.org" , "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" Subject: Re: [netext] Adrian Farrel's No Objection on draft-ietf-netext-pmip-cp-up-separation-05: (with COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 20:15:36 -0000 Hi Adrian, > a little odd for a Standard Track document, especially since there was >apparently such clear > consensus that this is a problem that needs to be solved. I guess I am >old-fashioned enough > to hope for running code from time to time. The comment in the chair-writeup, "No vendors have expressly stated a plan to implement this specification either" is not entirely accurate. AFAIK, we do not have a process where the WG asks vendors to provide implementation plans. So, the question was never asked and there was no reason for any one to specially come forward and publicly announce their intent to implement a specific draft and publish a time line. I'm not suggesting the WG should ask such information either as that is touching vendor product roadmaps and will be too intrusive. Now that IESG is asking this question and my response is yes. Talking on behalf of my company, we absolutely have plans to use this option in our product line.=20 Regards Sri On 8/4/14 10:56 AM, "Adrian Farrel" wrote: >Adrian Farrel has entered the following ballot position for >draft-ietf-netext-pmip-cp-up-separation-05: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >I don't object to this document, but I found... >> No known implementations of the protocol exist at this time. No >> vendors have expressly stated a plan to implement this >> specification either. >...a little odd for a Standard Track document, especially since there was >apparently such clear consensus that this is a problem that needs to be >solved. >I guess I am old-fashioned enough to hope for running code from time to >time. > > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From nobody Mon Aug 4 14:37:18 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0C791A0331; Mon, 4 Aug 2014 14:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aog1RUGIrw5q; Mon, 4 Aug 2014 14:37:08 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 945981A033C; Mon, 4 Aug 2014 14:37:08 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s74LM6kH001244; Mon, 4 Aug 2014 22:22:07 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s74LLcwV001094 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Aug 2014 22:21:56 +0100 From: "Adrian Farrel" To: "'Sri Gundavelli \(sgundave\)'" , "'The IESG'" References: <20140804175615.16238.14171.idtracker@ietfa.amsl.com> In-Reply-To: Date: Mon, 4 Aug 2014 22:36:40 +0100 Message-ID: <058a01cfb02c$3b76e150$b264a3f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJKguwBtuvwU0b8ZbkwWA1BglzQ7JrLS78g Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-20860.002 X-TM-AS-Result: No--26.071-10.0-31-10 X-imss-scan-details: No--26.071-10.0-31-10 X-TMASE-MatchedRID: PL66URbwWA+s7uBvvd6Amd35+5/2RxqmINC+F8tjh5XX2Vi54E0YjMLm p4jPUF8t4bw3qGt9FmCql22yJrFTEvUe3cF58v23mlaAItiONP0PRI8ISSLxYlj/amLs8rQSu36 L4aDmI3wxJ6rawp6j1hnXKu8rGlRWUv4rCBFxg7/Yd2+/8wYTdXN3sLsG0mhuJHCYQwMS7BmjCX M0UbexO/nLgYpU4F/+eIBxpIRNIUlM9z2aFscF3c+F1coRRWRyjX0BChis2L194c+e7fWIcGX9D FIJTs1HVCZDigcS1PmbMaVv+2ll8S0kxsNYPyneneIQmu8UmaHSde/CNbaZJWso23uKlCJjE7or XnCF9AyI7qXZddSBHa0Pj/9cOH4sCAKizYVJv3/K09/T6AzbViIBy2vbJcliuqWf6Nh7tmGzP/m FbCCOqJyujR9JCXlarpXz4X+0dnCwQEC6hpSor2gws6g0ewz2kk5xcxBziMER34ro7k23nTpbfd TAcNXm4vM1YF6AJbZcLc3sLtjOt1ZFWWuOwo7w3QfwsVk0UbslCGssfkpInQ== Archived-At: http://mailarchive.ietf.org/arch/msg/netext/4U-wvymaWpeHfUUn34PWh-iHN1U Cc: netext@ietf.org, netext-chairs@tools.ietf.org, draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org Subject: Re: [netext] Adrian Farrel's No Objection on draft-ietf-netext-pmip-cp-up-separation-05: (with COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 21:37:14 -0000 OK Sri, that's clear. A shepherd write-up might more usefully say "We didn't ask, and no-one told us". A > -----Original Message----- > From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com] > Sent: 04 August 2014 21:16 > To: Adrian Farrel; The IESG > Cc: netext@ietf.org; draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org; > netext-chairs@tools.ietf.org > Subject: Re: [netext] Adrian Farrel's No Objection on draft-ietf-netext-pmip-cp- > up-separation-05: (with COMMENT) > > Hi Adrian, > > > a little odd for a Standard Track document, especially since there was > >apparently such clear > > consensus that this is a problem that needs to be solved. I guess I am > >old-fashioned enough > > to hope for running code from time to time. > > > > The comment in the chair-writeup, "No vendors have expressly stated a plan > to implement this specification either" is not entirely accurate. > > AFAIK, we do not have a process where the WG asks vendors to provide > implementation plans. So, the question was never asked and there was no > reason for any one to specially come forward and publicly announce their > intent to implement a specific draft and publish a time line. I'm not > suggesting the WG should ask such information either as that is touching > vendor product roadmaps and will be too intrusive. > > Now that IESG is asking this question and my response is yes. Talking on > behalf of my company, we absolutely have plans to use this option in our > product line. > > > Regards > Sri > > > > > > > > > On 8/4/14 10:56 AM, "Adrian Farrel" wrote: > > >Adrian Farrel has entered the following ballot position for > >draft-ietf-netext-pmip-cp-up-separation-05: No Objection > > > >When responding, please keep the subject line intact and reply to all > >email addresses included in the To and CC lines. (Feel free to cut this > >introductory paragraph, however.) > > > > > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > >for more information about IESG DISCUSS and COMMENT positions. > > > > > >The document, along with other ballot positions, can be found here: > >http://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ > > > > > > > >---------------------------------------------------------------------- > >COMMENT: > >---------------------------------------------------------------------- > > > >I don't object to this document, but I found... > >> No known implementations of the protocol exist at this time. No > >> vendors have expressly stated a plan to implement this > >> specification either. > >...a little odd for a Standard Track document, especially since there was > >apparently such clear consensus that this is a problem that needs to be > >solved. > >I guess I am old-fashioned enough to hope for running code from time to > >time. > > > > > >_______________________________________________ > >netext mailing list > >netext@ietf.org > >https://www.ietf.org/mailman/listinfo/netext From nobody Wed Aug 6 11:41:06 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4438D1B27AA; Wed, 6 Aug 2014 11:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scpD4ut_Vil3; Wed, 6 Aug 2014 11:41:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 753A91A0390; Wed, 6 Aug 2014 11:41:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140806184100.22074.85630.idtracker@ietfa.amsl.com> Date: Wed, 06 Aug 2014 11:41:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/KvkGMJJU-4DxzYcR9fkJCFFKAsM Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-10.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 18:41:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : EAP Attributes for Wi-Fi - EPC Integration Authors : Ravi Valmikam Rajeev Koodli Filename : draft-ietf-netext-wifi-epc-eap-attributes-10.txt Pages : 16 Date : 2014-08-06 Abstract: With Wi-Fi emerging as a trusted access network for service providers, it has become important to provide functions commonly available in 3G and 4G networks in Wi-Fi access networks as well. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections, and seamless mobility between Wi-Fi and 3G/4G networks. The EAP/AKA (and EAP/AKA') protocol is required for mobile devices to access the mobile Evolved Packet Core (EPC) via trusted Wi-Fi networks. This document defines a few new EAP attributes to enable the above-mentioned functions in trusted Wi-Fi access networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-wifi-epc-eap-attributes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-wifi-epc-eap-attributes-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-wifi-epc-eap-attributes-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 6 11:48:25 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1836F1ACD01; Wed, 6 Aug 2014 11:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3_xukXPkAS3; Wed, 6 Aug 2014 11:48:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5C71A053B; Wed, 6 Aug 2014 11:48:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140806184819.18177.51969.idtracker@ietfa.amsl.com> Date: Wed, 06 Aug 2014 11:48:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/8ikI2dsUvcXsr__SNUZ_iS9Bq6Q Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-wifi-epc-eap-attributes-11.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Aug 2014 18:48:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : EAP Attributes for Wi-Fi - EPC Integration Authors : Ravi Valmikam Rajeev Koodli Filename : draft-ietf-netext-wifi-epc-eap-attributes-11.txt Pages : 16 Date : 2014-08-06 Abstract: With Wi-Fi emerging as a trusted access network for service providers, it has become important to provide functions commonly available in 3G and 4G networks in Wi-Fi access networks as well. Such functions include Access Point Name (APN) Selection, multiple Packet Data Network (PDN) connections, and seamless mobility between Wi-Fi and 3G/4G networks. The EAP/AKA (and EAP/AKA') protocol is required for mobile devices to access the mobile Evolved Packet Core (EPC) via trusted Wi-Fi networks. This document defines a few new EAP attributes to enable the above-mentioned functions in trusted Wi-Fi access networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-wifi-epc-eap-attributes/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-wifi-epc-eap-attributes-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-wifi-epc-eap-attributes-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 6 20:59:42 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2EC1A0AA6; Wed, 6 Aug 2014 20:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwqmmcRwl8gu; Wed, 6 Aug 2014 20:59:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9B41A0A99; Wed, 6 Aug 2014 20:59:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140807035939.14978.80901.idtracker@ietfa.amsl.com> Date: Wed, 06 Aug 2014 20:59:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/W6_PAPfcobOwzyGaM5uFemifxEA Cc: netext@ietf.org, draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org, netext-chairs@tools.ietf.org Subject: [netext] Pete Resnick's No Objection on draft-ietf-netext-pmip-cp-up-separation-05: (with COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 03:59:41 -0000 Pete Resnick has entered the following ballot position for draft-ietf-netext-pmip-cp-up-separation-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few weirdnesses in section 4: There can be multiple instances of the LMA User Plane Address mobility option present in the message, one for IPv4 and the other for IPv6 transport. Do you really mean "there can be multiple instances", or do you rather mean "there can be either one or two instances: One for IPv4, one for IPv6, or one for each of them"? ...the IP address field in the option can be either a zero-length field, or... Two instances of the above. Should that "can" be a MUST? ...the IP address field in the option MUST be set... In the above and the two bullet items below it: Shouldn't the "MUST be" in each one instead be "is"? There's no protocol requirement there. What else *could* an implementation do? From nobody Thu Aug 7 05:50:41 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 052BC1B28AD; Thu, 7 Aug 2014 05:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bszx1Wytffbe; Thu, 7 Aug 2014 05:50:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE2B1A0048; Thu, 7 Aug 2014 05:50:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: The IESG X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140807125031.22597.56137.idtracker@ietfa.amsl.com> Date: Thu, 07 Aug 2014 05:50:31 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/MxFcPIu9QKpV9zH_wY7ouIDsxds Cc: netext@ietf.org, draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org, netext-chairs@tools.ietf.org Subject: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 12:50:36 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-netext-pmip-cp-up-separation-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have two questions. They could be easy or hard, I'm not sure:-) Apologies in advance if I've forgotten what little I ever knew about PMIPv6 and gotten stuff wrong here. (1) PMIPv6 traffic between MAG and LMA is generally assumed to be protected via IPsec, right? Assuming that's actually done, does figure 1 here indicate a weakening of security since it shows that IP encapsulation is used between MAG-UP and LMA-UP without any mention of IPsec. Is that downgrading security? I get that the binding messages are the most important and will presumably continue on the control plane but what else changes? (2) How does the rest of the Internet know to use the LMA-UP for the MN and not the LMA-CP? Sorry for being dense but I don't see how packets from a random Internet node for the MN end up going down the user plane. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Did you need to say somewhere which PMIPv6 messages are to be sent in the control plane and which in the user plane? That might be obvious to some, but its not to me and I guess there are a bunch of PMIPv6 extensions so I could imagine that someone somewhere might get it wrong. From nobody Thu Aug 7 08:45:00 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77551B2D79 for ; Thu, 7 Aug 2014 08:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogTydAgntdJO for ; Thu, 7 Aug 2014 08:44:55 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by ietfa.amsl.com (Postfix) with ESMTP id 15E211B2D16 for ; Thu, 7 Aug 2014 08:44:55 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 07 Aug 2014 08:39:05 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,818,1400050800"; d="scan'208,217";a="555215647" Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35]) by orsmga001.jf.intel.com with ESMTP; 07 Aug 2014 08:44:02 -0700 Received: from fmsmsx153.amr.corp.intel.com (10.18.125.6) by FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 7 Aug 2014 08:44:00 -0700 Received: from hasmsx105.ger.corp.intel.com (10.184.198.19) by FMSMSX153.amr.corp.intel.com (10.18.125.6) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 7 Aug 2014 08:44:00 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.205]) by HASMSX105.ger.corp.intel.com ([10.184.198.19]) with mapi id 14.03.0195.001; Thu, 7 Aug 2014 18:43:57 +0300 From: "Moses, Danny" To: "netext@ietf.org" Thread-Topic: Logical Interface draft Thread-Index: Ac+yVmY6uhvOqdhyQiOA2rAVoQjeHA== Date: Thu, 7 Aug 2014 15:43:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.10] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC2811C14DCFFHASMSX106gercor_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/qya7e9ojyapsMBOeK-sWmr-xw8M Subject: [netext] Logical Interface draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 15:44:58 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC2811C14DCFFHASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, In the last meeting there was a discussion about whether or not to publish = the 'Logical Interface' draft (http://datatracker.ietf.org/doc/draft-ietf-n= etext-logical-interface-support/). At the end of the discussion it was agre= ed that if at least three new reviewers review the draft and state that it = is useful, the WG will publish it. Well, I reviewed it (and it was the first time for me to read it) and found= the draft to be useful as a guide for OS developers (and/or network stack = developers) who wish to implement a logical interface for supporting PMIPv6. I found the draft to be clear, short and useful and recommend to publish it= . I found a few minor typos that should be corrected and sent my comments = to Sri. Regards, /Danny --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC2811C14DCFFHASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
Hi,
 
In the last meeting there was a discussion about whether or not to pub= lish the 'Logical Interface' draft (http://datatracker.ietf.org/doc= /draft-ietf-netext-logical-interface-support/)= . At the end= of the discussion it was agreed that if at least three new reviewers revie= w the draft and state that it is useful, the WG will publish it.
 
Well, I reviewed it= (and it was the first time for me to read it) and found the draft to be us= eful as a guide for OS developers (and/or network stack developers) who wis= h to implement a logical interface for supporting PMIPv6.
 
I found the draft t= o be clear, short and useful and recommend to publish it. I found a few min= or typos that should be corrected  and sent my comments to Sri.=
 
Regards,
   &= nbsp;    /Danny
 
 

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_F0CF5715D3D1884BAC731EA1103AC2811C14DCFFHASMSX106gercor_-- From nobody Fri Aug 8 04:07:56 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4629C1B2A6A for ; Fri, 8 Aug 2014 04:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpW1OtLI5SnS for ; Fri, 8 Aug 2014 04:07:46 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B5E1B2ABE for ; Fri, 8 Aug 2014 04:07:37 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 5FC4F374399; Fri, 8 Aug 2014 13:07:35 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 3F36C15805E; Fri, 8 Aug 2014 13:07:35 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0195.001; Fri, 8 Aug 2014 13:07:35 +0200 From: To: "Moses, Danny" , "netext@ietf.org" Thread-Topic: Logical Interface draft Thread-Index: Ac+yVmY6uhvOqdhyQiOA2rAVoQjeHAAlhFwg Date: Fri, 8 Aug 2014 11:07:34 +0000 Message-ID: <15424_1407496055_53E4AF77_15424_4456_1_81C77F07008CA24F9783A98CFD706F71142826EF@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F71142826EFPEXCVZYM12corpo_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.8.8.101820 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/rzl3nltFttb4e57miyLY4idwEfg Subject: Re: [netext] Logical Interface draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 11:07:53 -0000 --_000_81C77F07008CA24F9783A98CFD706F71142826EFPEXCVZYM12corpo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I've reviewed http://datatracker.ietf.org/doc/draft-ietf-netext-logical-int= erface-support/and I have no particular issue to raise, just few editorial = suggestions (please see below). So, I agree with Danny; this doc is useful = and ready for publication. BR, Pierrick --- OLD ABSTRACT ------------- A Logical Interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. The Logical Interface support is required on the mobile node operating in a Proxy Mobile IPv6 domain, for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming and flow mobility support. This document explains the operational details of Logical Interface construct and the specifics on how the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in context with various mobility management features. ------------- NEW ABSTRACT ------------- A Logical Interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and, when the terminal is equipped with more than one = interface, it can be used to hide the physical interfaces from the IP stack= . The logical interface thus allows various network-based mobility management features such as inter-technology handoffs, multihoming and flow mobility support. This document explains how the Logical Interface hides the physical interfaces from the IP stack and from the network nodes on the attached access networks. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in context with various mobility management features. - Old text ----------- Specifically, it explores the use of the Logical Interface support, a semantic available on most operating systems. - New text ---------- Specifically, it explores the use of the Logical Interface support, availab= le on most operating systems. Section 3.1: =AB an 802.11 STA =BB - please expand STA s/ within the same domain/ within the same IP subnet/ s/ the IEEE 802.11 MAC layer takes care of the mobility/ the IEEE 802.11 MA= C layer handles mobility between access points s/ A logical interface denotes a mechanism that that logically group/bond s= everal/ A logical interface denotes a mechanism that logically group several --------- OLD text ---------- Depending on the type of access technologies, it might be possible to use more than one physical interface at a time -- such that the node is simultaneously attached via different access technologies -- or just to perform handovers across a variety of physical interfaces. . Not: It does not depent on the access technology but on the OS and the term= inal implementation, so I suggest: ----------- NEW text ---------- Depending on the system, it might be possible to use more than one physical interface at a time -- such that the node is simultaneously attached via different access technologies -- or just to perform handovers across a variety of physical interfaces. ------ OLD text --------- The configuration is typically handled via a connection manager, and based on a combination of user preferences on one hand, and operator preferences such as those provisionned by the Access Network Discovery and Selection Function (ANDSF) [TS23402] on the other hand. -------- NEW text -------- The configuration is typically handled via a connection manager, and based on a combination of user preferences, application characteristics, quality of communicati= ons, operator preferences (e.g. provisioned by the Access Network Discovery= and Selection Function (ANDSF) [TS23402]), and so on. S/3.2.1 link layer support/link layer mobility support/ s/ in the same subnet with a common IP layer configuration (DHCP server, de= fault router, etc.)/ in the same IP subnet with a common configuration obje= cts (DHCP server, default gateway, etc.) s/ In this case the handover across access points need not to be hidden/ In= this case the handover across access points does not need to be hidden Last paragraph of 3.2.1 should be removed since the use-case is covered by = 3.2.2. Or rewrite as: -+-------- OLD TEXT --------- Since this type of link layer technology does not typically allow for simultaneous attachment to different access networks of the same technology, the logical interface would not be used to provide simultaneous access for purposes of multihoming or flow mobility. Note: actually, there is no multihoming or flow mobility since there is no = more than one simultaneous attachment ;-) Instead, the logical interface can be used to provide inter-access technology handover between this type of link layer technology and another link layer technology, e.g., between IEEE 802.11 and IEEE 802.16. Note: this covered in the following section section ... this is the motivat= ion of the logical interface.... - NEW TEXT ---------- When the access technology does not allow a single interface to be simultan= eous attach to more than one IP network (subnet and associated configuratio= n objects), logical interface support is not required. -------- OLD TEXT --------- Doing so allows to hide inter-access technology handovers or application flow handovers across different physical interfaces. --- NEW TEXT ------------ Doing so allows to hide inter-access technology handovers, or application flow handovers across different physical interfaces, from the IP stack which is by nature tight to a sin= gle interface. -----------Question --------------- Section 4 states: In some UE implementations the wireless connection setup is based on creation of a PPP interface between the IP layer and the wireless modem that is configured with the IPCP and IPv6CP protocol [RFC5072]. In this case the PPP interface does not have any L2 address assigned. In some other implementations the wireless modem is presented to the IP layer as a virtual Ethernet interface. So what? What do you want to stress here? - - - - ---- Section 5: What do you mean by "The sub-interfaces attached to a Logical interface ar= e not visible to the IP and upper layers." The node can use either the logical or physical interfaces, I mean, an appl= ication can be bound to the LI and another application bound to one of the = physical interface available. Section 5.1: The IP layer should be configured with a default router reachable via the l= ogical interface. The IP layer should be also configured with DNS, DHCP server. Right? Section 5.2: In Fig.2 ::flow table : s/ Physical_Intf_Id/PIF_ID on section n 6.3: maybe add a reference to the draft netext-flow-mob? General comment: In the doc, we find either =AB Logical Interface =BB, or = =AB logical interface =BB, or =AB Logical interface =BB.... Would be better= to pick only one of these terms.... De : netext [mailto:netext-bounces@ietf.org] De la part de Moses, Danny Envoy=E9 : jeudi 7 ao=FBt 2014 17:44 =C0 : netext@ietf.org Objet : [netext] Logical Interface draft Hi, In the last meeting there was a discussion about whether or not to publish = the 'Logical Interface' draft (http://datatracker.ietf.org/doc/draft-ietf-n= etext-logical-interface-support/). At the end of the discussion it was agre= ed that if at least three new reviewers review the draft and state that it = is useful, the WG will publish it. Well, I reviewed it (and it was the first time for me to read it) and found= the draft to be useful as a guide for OS developers (and/or network stack = developers) who wish to implement a logical interface for supporting PMIPv6. I found the draft to be clear, short and useful and recommend to publish it= . I found a few minor typos that should be corrected and sent my comments = to Sri. Regards, /Danny --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_81C77F07008CA24F9783A98CFD706F71142826EFPEXCVZYM12corpo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

I’ve= reviewed http://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface-= support/and I have no particular issue to raise, just few editorial suggestions (pleas= e see below). So, I agree with Danny; this doc is useful and ready for publ= ication.

 =

BR, Pierrick

 = ;

 = ;

--- OLD AB= STRACT  -------------

A Logical Interface is a software semantic = internal to the host

   operating system.  This s= emantic is available in all popular

   operating systems and is used = in various protocol implementations.

   The Logical Interface support = is required on the mobile node

  operating in a Proxy Mobile IPv= 6 domain, for leveraging various

   network-based mobility managem= ent features such as inter-technology

   handoffs, multihoming and flow= mobility support.  This document

   explains the operational detai= ls of Logical Interface construct and

   the specifics on how the link-= layer implementations hide the physical

   interfaces from the IP stack a= nd from the network nodes on the

   attached access networks. = ; Furthermore, this document identifies the

   applicability of this approach= to various link-layer technologies and

   analyzes the issues around it = when used in context with various

   mobility management features.

 <= /p>

 <= /p>

-------------  NEW A= BSTRACT -------------

 <= /p> 

A Logical Interface is a software semantic intern=
al to the host
   operating system.  This semanti=
c is available in all popular
   operating systems and, when the term=
inal is equipped with more than one interface, it can be used to hide the p=
hysical interfaces from the IP stack. The logical interface thus allows var=
ious
   network-based mobility management fe=
atures such as inter-technology
   handoffs, multihoming and flow mobil=
ity support.  This document
   explains how the Logical Interface h=
ides the physical
   interfaces from the IP stack and fro=
m the network nodes on the
   attached access networks.  Furt=
hermore, this document identifies the
   applicability of this approach to va=
rious link-layer technologies and
   analyzes the issues around it when u=
sed in context with various
   mobility management features.=

 <= /p>

 <= /p>

- = ;         Old text --------= ---

 <= /p> 

Specifically, it explores the use of the Logical =
Interface support, a
   semantic available on most operating=
 systems.

 = ;

 = ;

-          Ne= w text ----------

Specifically, it explores the use of the Logical =
Interface support, available on most operating systems.

 =
;


 =
;


 =
;


Section 3.=
1:


 =
;


=AB an 802.11 STA =BB - please expand S=
TA


 =
;


s/ within the same domain/ within the same IP subnet/

 

s/ the IEEE 802.11 MAC layer takes care of the mobility/ the IEEE 802.11 MA=
C layer handles mobility between access points


 


s/ A logical interface denotes a mechanism that t=
hat logically group/bond several/ A logical interface denotes a mechanism t=
hat logically group several


 


--------- OLD text ----------

 


Depending on the type of


      access technologie=
s, it might be possible to use more than one


      physical interface=
 at a time -- such that the node is


      simultaneously att=
ached via different access technologies -- or


      just to perform ha=
ndovers across a variety of physical interfaces.


.


 


Not: It does not depent on the access technology =
but on the OS and the terminal implementation, so I suggest:


 


----------- NEW text ----------=



 


Depending on the system, it might be possible to =
use more than one


      physical interface=
 at a time -- such that the node is


      simultaneously att=
ached via different access technologies -- or


      just to perform ha=
ndovers across a variety of physical interfaces.


 


 


 


------ OLD text ---------


 


The configuration is typically<=
/pre>

      handled via a conn=
ection manager, and based on a combination of


      user preferences o=
n one hand, and operator preferences such as


      those provisionned=
 by the Access Network Discovery and Selection


      Function (ANDSF) [=
TS23402] on the other hand.


 


 


-------- NEW text --------


 


The configuration is typically<=
/pre>

      handled via a conn=
ection manager, and based on a combination of


      user preferences, =
application characteristics, quality of communications, operator preference=
s (e.g. provisioned by the Access Network Discovery and Selection Function =
(ANDSF) [TS23402]), and so on.


 


 


S/3.2.1 li=
nk layer support/link layer mobility support/


 =
;


s/ in the same subnet with a common IP layer configuration (DHCP server, de=
fault router, etc.)/ in the same IP subnet with a common configuration obje=
cts (DHCP server, default gateway, etc.)


 


s/ In this case the handover across access points need not to be hidden/ In=
 this case the handover across access points does not need to be hidden &nb=
sp;


 


 


 


Last parag=
raph of 3.2.1 should be removed since the use-case is covered by 3.2.2. Or =
rewrite as:


 =
;


-+----=
---- OLD TEXT ---------


Since this type of link layer technology does not=
 typically allow for


   simultaneous attachment to different=
 access networks of the same


   technology, the logical interface wo=
uld not be used to provide


   simultaneous acces=
s for purposes of multihoming or flow mobility.


 


Note: actu=
ally, there is no multihoming or flow mobility since there is no more than =
one simultaneous attachment ;-)


 


   Instead, the logical interface can b=
e used to provide inter-access


   technology handover between this typ=
e of link layer technology and


   another link layer technology, e.g.,=
 between IEEE 802.11 and IEEE


   802.16.


 =
;


Note: this=
 covered in the following section section … this is the motivation of=
 the logical interface….


 =
;


-         
NE=
W TEXT ----------


 


When the a=
ccess technology does not allow a single interface to be simultaneous attac=
h to more than one IP network (subnet and associated configuration
 objects), logical interface support is not required.


 =
;


-------- O=
LD TEXT ---------


 =
;


Doing so allows to hide inter-access


   technology handovers or application =
flow handovers across different


   physical interfaces.


 =
;


--- NEW TE=
XT ------------


 =
;


Doing so allows to hide inter-access


   technology handovers, or application=
 flow handovers across different


   physical interfaces, from the IP sta=
ck which is by nature tight to a single interface.


 =
;


----------=
-Question ---------------


 =
;


 =
;


Section 4 =
states:


 =
;


In some UE implementations the wireless connectio=
n setup is based on


   creation of a PPP interface between =
the IP layer and the wireless


   modem that is configured with the IP=
CP and IPv6CP protocol [RFC5072].


   In this case the PPP interface does =
not have any L2 address assigned.


   In some other implementations the wi=
reless modem is presented to the


   IP layer as a virtual Ethernet inter=
face.


 =
;


 =
;


So what? W=
hat do you want to stress here?


-         
- =
- -  ----


 =
;


 =
;


Section 5:=



 =
;


What do you mean by  “The sub-interfac=
es attached to a Logical interface are not visible to the IP and upper laye=
rs.”


The node can use either the logical or physical i=
nterfaces, I mean, an application can be bound to the LI and another applic=
ation bound to one of the physical interface available.

 


 


 


 


Section 5.=
1:


 =
;


The IP layer should be configured with a default =
router reachable via the logical interface.


 


The IP layer should be also configured with DNS, =
DHCP server. Right?


 


Section 5.2:


 


In Fig.2 :=
:flow table :


 =
;


s/ Physical_Intf_Id/PIF_ID


 =
;


on section=
 n 6.3: maybe add a reference to the draft netext-flow-mob?


 =
;


 =
;


General co=
mment: In the doc, we find either =AB Logical Interface =BB, or =
=AB logical interface =BB, or =AB Logical interface =BB=
…. Would be better to pick
 only one of these terms….


 =
;


 =
;








De : nete=
xt [mailto:netext-bounces@ietf.org]
De la part de Moses, Danny

Envoy=E9 : jeudi 7 ao=FBt 2014 17:44

=C0 : netext@ietf.org

Objet : [netext] Logical Interface draft






 




Hi,






 






In the last meeting there was a discuss=
ion about whether or not to publish the 'Logical Interface' draft (http://datatracker.ietf.org/doc/dra=
ft-ietf-netext-logical-interface-support/).
 At the end of the discussion it was agreed that if at least three new revi=
ewers review the draft and state that it is useful, the WG will publish it.=







 






Well, I reviewed it (and it was the fir=
st time for me to read it) and found the draft to be useful as a guide for =
OS developers (and/or network stack developers) who wish
 to implement a logical interface for supporting PMIPv6.






 






I found the draft to be clear, short an=
d useful and recommend to publish it. I found a few minor typos that should=
 be corrected  and sent my comments to Sri.






 






Regards,=







      &nb=
sp; /Danny






 






 




---------------------------------------------------------------------

A member of the Intel Corporation group of companies


This e-mail and any attachments may contain confidential material for

the sole use of the intended recipient(s). Any review or distribution

by others is strictly prohibited. If you are not the intended

recipient, please contact the sender and delete all copies.




______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_81C77F07008CA24F9783A98CFD706F71142826EFPEXCVZYM12corpo_-- From nobody Sat Aug 9 09:54:32 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B67C11A0020; Sat, 9 Aug 2014 09:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.469 X-Spam-Level: X-Spam-Status: No, score=-12.469 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id To0aObcuWpqf; Sat, 9 Aug 2014 09:54:25 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E83B1A0035; Sat, 9 Aug 2014 09:54:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4386; q=dns/txt; s=iport; t=1407603263; x=1408812863; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=HoJe7wShrtlHFY4btkbNldsqrHRNwwqzCol1TSIN9IE=; b=UYgcDHDu5yBmQFiLjrfpUMZ+IAENCFGP5SRqZlAFJlPc45Li7nKsmUS1 483RDS+xDMCYC96bZy+XThQ/tOfFPRpxYerXqpBvgLuRO2yfFcL45zVMR uNj6VRBdnrGLlMWP35MI2Cw5mwJwh0Gn1UY6UqsGy52JOPdNqwG97h3e9 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAMdR5lOtJA2I/2dsb2JhbABYgw1SW80NDIZzUwGBCBZ3hAQBAQQBAQE3NAsSAQgOKAUyCyUCBAENBQmIOQ3FBReMHYJNEQFQAgWETAWGD4sKhCWGcYFXiiqIeoIWgUZsAYENOQ X-IronPort-AV: E=Sophos;i="5.01,833,1400025600"; d="scan'208";a="67886401" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP; 09 Aug 2014 16:54:23 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s79GsMKx013732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 9 Aug 2014 16:54:22 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.251]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Sat, 9 Aug 2014 11:54:22 -0500 From: "Sri Gundavelli (sgundave)" To: Pete Resnick , The IESG Thread-Topic: [netext] Pete Resnick's No Objection on draft-ietf-netext-pmip-cp-up-separation-05: (with COMMENT) Thread-Index: AQHPs/KRzTLoFyChrkGU8CY7ut7DRg== Date: Sat, 9 Aug 2014 16:54:21 +0000 Message-ID: In-Reply-To: <20140807035939.14978.80901.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.222] Content-Type: text/plain; charset="us-ascii" Content-ID: <5AC7D8FB7D4BA446A32F8138AE67E6D1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/4ZjTsCBbpfWFLE_QctNIEQLRv1s Cc: "netext@ietf.org" , "netext-chairs@tools.ietf.org" , "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" Subject: Re: [netext] Pete Resnick's No Objection on draft-ietf-netext-pmip-cp-up-separation-05: (with COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 16:54:26 -0000 Hi Pete, Thanks for the review. Please see inline. On 8/6/14 8:59 PM, "Pete Resnick" wrote: >Pete Resnick has entered the following ballot position for >draft-ietf-netext-pmip-cp-up-separation-05: No Objection > >When responding, please keep the subject line intact and reply to all >email addresses included in the To and CC lines. (Feel free to cut this >introductory paragraph, however.) > > >Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >for more information about IESG DISCUSS and COMMENT positions. > > >The document, along with other ballot positions, can be found here: >http://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ > > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > >A few weirdnesses in section 4: > > There can be multiple > instances of the LMA User Plane Address mobility option present in > the message, one for IPv4 and the other for IPv6 transport. > =20 >Do you really mean "there can be multiple instances", or do you rather >mean "there can be either one or two instances: One for IPv4, one for >IPv6, or one for each of them"? We tried to say there can be one or two instance of the option (option format in Section 4), one for each IP version. OLD: The LMA User Plane Address mobility option is a new mobility header option defined for use with PBU and PBA messages exchanged between the LMA and the MAG. This option is used for notifying the MAG about the LMA's user plane IPv6 or IPv4 address. There can be multiple instances of the LMA User Plane Address mobility option present in the message, one for IPv4 and the other for IPv6 transport. NEW: The LMA User Plane Address mobility option is a new mobility header option defined for use with PBU and PBA messages exchanged between the LMA and the MAG. This option is used for notifying the MAG about the LMA's user plane IPv6 or IPv4 address. There can be zero, one or two instances of the LMA User Plane Address mobility option present in the message. When two instances of the option are present, one instance of the option must be for IPv4 transport and the other instance must be for IPv6 transport. (Or, please suggest text) > > ...the IP address field > in the option can be either a zero-length field, or... > >Two instances of the above. Should that "can" be a MUST? >' Yes. Thanks. OLD: o When using IPv4 transport for the user-plane, the IP address field in the option can be either a zero-length field, or a 4-octet field with ALL_ZERO value. o When using IPv6 transport for the user-plane, the IP address field in the option can be either a zero-length field, or a 16-octet field with ALL_ZERO value. NEW: o When using IPv4 transport for the user-plane, the IP address field in the option MUST be either a zero-length field, or a 4-octet field with ALL_ZERO value. o When using IPv6 transport for the user-plane, the IP address field in the option MUST be either a zero-length field, or a 16-octet field with ALL_ZERO value. > ...the IP address field in the option MUST be set... > >In the above and the two bullet items below it: Shouldn't the "MUST be" >in each one instead be "is"? There's no protocol requirement there. What >else *could* an implementation do? > Ok. OLD: o When using IPv4 transport for the user-plane, the IP address field in the option MUST be the IPv4 address carrying user-plane traffic. o When using IPv6 transport for the user-plane, the IP address field in the option MUST be the IPv6 address carrying user-plane traffic. NEW: o When using IPv4 transport for the user-plane, the IP address field in the option is the IPv4 address carrying user-plane traffic. o When using IPv6 transport for the user-plane, the IP address field in the option is the IPv6 address carrying user-plane traffic. Regards Sri > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From nobody Sat Aug 9 09:54:46 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4981A004E; Sat, 9 Aug 2014 09:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.469 X-Spam-Level: X-Spam-Status: No, score=-12.469 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7lT19t0XZnE; Sat, 9 Aug 2014 09:54:35 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A07D01A0033; Sat, 9 Aug 2014 09:54:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3097; q=dns/txt; s=iport; t=1407603276; x=1408812876; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CFhwCJyFZHy7CIFtTwOLLLmBf0Q1C2FRHibzZKTB+sM=; b=A6mLd294AEP7SJST7ys3/daEfDCvZhPSvScMX668CehpSOmO1HWUY465 44AEXam+uwzc1xQuqucCx4glqrF64ONhhyAU/SzvNYPjeIWBQgy0nXEXq /Y24znw5LXDqkiQhayeQE8xpAilBRLIJu/Ng74kc//uINaGYmpU7nUHPS U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAMdR5lOtJA2H/2dsb2JhbABYgw1SW80NCoZ1UwGBCBZ3hAQBAQQBAQE3NAsSAQg2BTILJQIEAQ0FiEINxQUTBIwdgnwzB4RMBYYPiwqLFowBiHqCFoFGbIFH X-IronPort-AV: E=Sophos;i="5.01,833,1400025600"; d="scan'208";a="343203885" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-9.cisco.com with ESMTP; 09 Aug 2014 16:54:35 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s79GsYFJ001822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 9 Aug 2014 16:54:34 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.251]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Sat, 9 Aug 2014 11:54:34 -0500 From: "Sri Gundavelli (sgundave)" To: Stephen Farrell , The IESG Thread-Topic: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT) Thread-Index: AQHPs/KYPGye9+SND0qnD+DkG+NETQ== Date: Sat, 9 Aug 2014 16:54:34 +0000 Message-ID: In-Reply-To: <20140807125031.22597.56137.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.222] Content-Type: text/plain; charset="us-ascii" Content-ID: <28B815A64E812649AF84BBC894D12564@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/faHa2V27CjufcU0lHCWtNkHMx7w Cc: "netext@ietf.org" , "netext-chairs@tools.ietf.org" , "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" Subject: Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 16:54:38 -0000 Hi Stephen, Thanks for the review. Please see inline. On 8/7/14 5:50 AM, "Stephen Farrell" wrote: > >I have two questions. They could be easy or hard, I'm not >sure:-) Apologies in advance if I've forgotten what little I >ever knew about PMIPv6 and gotten stuff wrong here. Not at all. Thanks for the discussion. > >(1) PMIPv6 traffic between MAG and LMA is generally assumed to >be protected via IPsec, right? Assuming that's actually done, >does figure 1 here indicate a weakening of security since it >shows that IP encapsulation is used between MAG-UP and LMA-UP >without any mention of IPsec. Is that downgrading security? I >get that the binding messages are the most important and will >presumably continue on the control plane but what else changes? Yes. PMIPv6 allows the use of IPsec security (Tunnel Mode ESP) protection for the user-plane traffic. This is optional and is based on standard IPsec security. It requires no special interaction between IPsec and the Proxy Mobile IPv6 entities. In the split mode (LMA =3D=3D> LMA-CP & LMA-DP), the MAG (or MAG-DP) and th= e LMA-DP can optionally enable IPsec security on the user-plane traffic. MAG-DP establishes a layer-3 p2p tunnel to LMA-DP and both these peers can be configured to apply IPsec security on the tunneled traffic. So, there is no loss of functionality here and the CP/DP split approach is not resulting in weakened security. > >(2) How does the rest of the Internet know to use the LMA-UP >for the MN and not the LMA-CP? Sorry for being dense but I >don't see how packets from a random Internet node for the MN >end up going down the user plane. The IP address of the mobile node is topologically anchored on the LMA-DP. >From the point of view of Routing, the LMA-DP owns that larger IP prefix block from which it allocates to IP prefixes/address to individual mobility sessions. The LMA-DP is in the path for the user-plane traffic and is the entry point into the mobile network. However, the LMA-CP is only terminating the control signaling from the MAG and is not in the path for the user-plane traffic. =20 > > >---------------------------------------------------------------------- >COMMENT: >---------------------------------------------------------------------- > > >Did you need to say somewhere which PMIPv6 messages are to be >sent in the control plane and which in the user plane? That >might be obvious to some, but its not to me and I guess there >are a bunch of PMIPv6 extensions so I could imagine that >someone somewhere might get it wrong. > The signaling messages {IPv6 with Mobility Header, or IPv4 UDP Port 5436) traffic is exchanged between MAG-CP and LMA-CP. There is no implication on the use/non-use of other mobility options. The tunneled traffic with L3 encapsulation is between MAG-DP and LMA-DP. Regards Sri > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From nobody Sun Aug 10 18:40:41 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF051A01E2 for ; Sun, 10 Aug 2014 18:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuNg-lov0tu3 for ; Sun, 10 Aug 2014 18:40:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3350A1A01E0 for ; Sun, 10 Aug 2014 18:40:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml406-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BLC06088; Mon, 11 Aug 2014 01:40:35 +0000 (GMT) Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 11 Aug 2014 02:40:35 +0100 Received: from NKGEML507-MBX.china.huawei.com ([169.254.5.39]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.03.0158.001; Mon, 11 Aug 2014 09:40:29 +0800 From: Weixinpeng To: "netext@ietf.org" Thread-Topic: Re: [netext] I-D Action: draft-ietf-netext-ani-location-01.txt Thread-Index: Ac+1BTjd0V5D4EEKTWaop9FgUcl3PQ== Date: Mon, 11 Aug 2014 01:40:28 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.76.176] Content-Type: multipart/alternative; boundary="_000_C5C3BB522B1DDF478AA09545169155B46D82BBC9nkgeml507mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/netext/TZ_XqjfqU50C3NoZqDh17yP-Rlw Subject: Re: [netext] I-D Action: draft-ietf-netext-ani-location-01.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 01:40:39 -0000 --_000_C5C3BB522B1DDF478AA09545169155B46D82BBC9nkgeml507mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I think this document is well written, and here are some of my comments: (1) For Civic-Location Sub-Option: I was wondering if that is easy to make the packet fragmented if RFC5139 de= fines civic-location in XML format (PIDF-LO) is used? (2) If the LMA should check the validity of civic-location included in PBU = to prevent MAG to send an incorrect location information, especially in cas= e if PIDF-LO is used, and LMA's action regarding this should be specified? --_000_C5C3BB522B1DDF478AA09545169155B46D82BBC9nkgeml507mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I think this document is wel= l written, and here are some of my comments:

 

(1) For Civic-Location Sub-O= ption:

I was wondering if that is e= asy to make the packet fragmented if RFC5139 defines civic-location in XML = format (PIDF-LO) is used?

(2) If the LMA should check = the validity of civic-location included in PBU to prevent MAG to send an in= correct location information, especially in case if PIDF-LO is used, and LM= A's action regarding this should be specified?

 

--_000_C5C3BB522B1DDF478AA09545169155B46D82BBC9nkgeml507mbxchi_-- From nobody Tue Aug 12 16:05:58 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75681A0A86; Tue, 12 Aug 2014 16:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lBEBDIY8iEB; Tue, 12 Aug 2014 16:05:44 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31DD61A0A83; Tue, 12 Aug 2014 16:05:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1407884744; x=1439420744; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=baFkOODrfq3bDjr2Zp2cFGfs64GNpC3V50RYqbhOSqc=; b=pd8b3lFuQNx2bJuSFjpaOyVJCC17MLYMFxy4idxFZFknpk65KscOIpQj zv/KlF6HSublbM2rwmf6OiXJUL60SajmhT3MHTg2xnsPL7WJV4Lq2lF14 K93CwaQzOBhsZCFf4BaqMds+Nx8VkGLcVu53HW3oHO/8pyJLjmPqH5GPA c=; X-IronPort-AV: E=McAfee;i="5600,1067,7528"; a="72782520" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth02.qualcomm.com with ESMTP; 12 Aug 2014 16:05:43 -0700 X-IronPort-AV: E=Sophos;i="5.01,852,1400050800"; d="scan'208";a="690640146" Received: from nasanexhc07.na.qualcomm.com ([172.30.39.190]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Aug 2014 16:05:43 -0700 Received: from resnick2.qualcomm.com (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.190) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 12 Aug 2014 16:05:42 -0700 Message-ID: <53EA9DC1.3080901@qti.qualcomm.com> Date: Tue, 12 Aug 2014 18:05:37 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: "Sri Gundavelli (sgundave)" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [172.30.39.5] Archived-At: http://mailarchive.ietf.org/arch/msg/netext/UsCLPOhjg2Jia3QTFirxI-2z0j4 Cc: "netext@ietf.org" , The IESG , "netext-chairs@tools.ietf.org" , "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" Subject: Re: [netext] Pete Resnick's No Objection on draft-ietf-netext-pmip-cp-up-separation-05: (with COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 23:05:47 -0000 The changes look fine. Thanks. pr On 8/9/14 11:54 AM, Sri Gundavelli (sgundave) wrote: > Hi Pete, > > Thanks for the review. Please see inline. > > > > On 8/6/14 8:59 PM, "Pete Resnick" wrote: > > >> Pete Resnick has entered the following ballot position for >> draft-ietf-netext-pmip-cp-up-separation-05: No Objection >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> A few weirdnesses in section 4: >> >> There can be multiple >> instances of the LMA User Plane Address mobility option present in >> the message, one for IPv4 and the other for IPv6 transport. >> >> Do you really mean "there can be multiple instances", or do you rather >> mean "there can be either one or two instances: One for IPv4, one for >> IPv6, or one for each of them"? >> > > We tried to say there can be one or two instance of the option (option > format in Section 4), one for each IP version. > > OLD: > > The LMA User Plane Address mobility option is a new mobility header > option defined for use with PBU and PBA messages exchanged between > the LMA and the MAG. This option is used for notifying the MAG about > the LMA's user plane IPv6 or IPv4 address. There can be multiple > instances of the LMA User Plane Address mobility option present in > the message, one for IPv4 and the other for IPv6 transport. > > NEW: > > The LMA User Plane Address mobility option is a new mobility header > option defined for use with PBU and PBA messages exchanged between > the LMA and the MAG. This option is used for notifying the MAG about > the LMA's user plane IPv6 or IPv4 address. There can be zero, one or > two instances of the LMA User Plane Address mobility option present in > the message. When two instances of the option are present, one instance > of the option must be for IPv4 transport and the other instance must be > for IPv6 transport. > > > (Or, please suggest text) > > > > > > > >> ...the IP address field >> in the option can be either a zero-length field, or... >> >> Two instances of the above. Should that "can" be a MUST? >> ' >> > > Yes. Thanks. > > > OLD: > > o When using IPv4 transport for the user-plane, the IP address field > in the option can be either a zero-length field, or a 4-octet > field with ALL_ZERO value. > > o When using IPv6 transport for the user-plane, the IP address field > in the option can be either a zero-length field, or a 16-octet > field with ALL_ZERO value. > > > > NEW: > > o When using IPv4 transport for the user-plane, the IP address field > in the option MUST be either a zero-length field, or a 4-octet > field with ALL_ZERO value. > > o When using IPv6 transport for the user-plane, the IP address field > in the option MUST be either a zero-length field, or a 16-octet > field with ALL_ZERO value. > > > > > > > > >> ...the IP address field in the option MUST be set... >> >> In the above and the two bullet items below it: Shouldn't the "MUST be" >> in each one instead be "is"? There's no protocol requirement there. What >> else *could* an implementation do? >> >> > Ok. > > OLD: > > o When using IPv4 transport for the user-plane, the IP address field > in the option MUST be the IPv4 address carrying user-plane > traffic. > > o When using IPv6 transport for the user-plane, the IP address field > in the option MUST be the IPv6 address carrying user-plane > traffic. > > > NEW: > > o When using IPv4 transport for the user-plane, the IP address field > in the option is the IPv4 address carrying user-plane > traffic. > > o When using IPv6 transport for the user-plane, the IP address field > in the option is the IPv6 address carrying user-plane > traffic. > > > > > > Regards > Sri > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Aug 12 16:09:16 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D501A0478; Tue, 12 Aug 2014 16:09:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVxRdKHV5B7B; Tue, 12 Aug 2014 16:09:04 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F62F1A036D; Tue, 12 Aug 2014 16:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5049; q=dns/txt; s=iport; t=1407884944; x=1409094544; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=lgtZKZR8tiS2FIeElu2hByMcRiEoOe7RhgIMAY8F0gI=; b=SWHzw0G4OIZA/9g8yb+LKHMaiAyIRVMx3uqXCNJ/JN97J6WsEWAH7sag 9zm2Z5ye0fQd6p07ci+AFnixyfdbsTUzFBe9X+0rQXUnBrotC8SsWJgih asWmNwyC4LKtKUd5IPOS85hoNcGEHYDNce3H5RJ4rxVdBet+1l4phkyqB Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAG2d6lOtJV2a/2dsb2JhbABXAxaCd1JXBM0yh0YBgRIWd4QEAQEEOj8SAQgOCh4FPSUCBA4FCYg5DcUZF4wdgk0RAUAQAgURhDsFhhCLDYQmhnaBV4oqiH2CFoFGbAGBDjk X-IronPort-AV: E=Sophos;i="5.01,852,1400025600"; d="scan'208";a="347018221" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 12 Aug 2014 23:09:03 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7CN93xA020210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Aug 2014 23:09:03 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.223]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 12 Aug 2014 18:09:03 -0500 From: "Sri Gundavelli (sgundave)" To: Pete Resnick Thread-Topic: [netext] Pete Resnick's No Objection on draft-ietf-netext-pmip-cp-up-separation-05: (with COMMENT) Thread-Index: AQHPtoJoRXmqoJQltkmx34u+0H5IQw== Date: Tue, 12 Aug 2014 23:09:02 +0000 Message-ID: In-Reply-To: <53EA9DC1.3080901@qti.qualcomm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.222] Content-Type: text/plain; charset="us-ascii" Content-ID: <478DDCFA7916F14F8093FA698E327914@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/1QA7NXPVywefQoI-5BynmyVFxTU Cc: "netext@ietf.org" , The IESG , "netext-chairs@tools.ietf.org" , "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" Subject: Re: [netext] Pete Resnick's No Objection on draft-ietf-netext-pmip-cp-up-separation-05: (with COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 23:09:07 -0000 Ok. Thanks Pete. Regards Sri On 8/12/14 4:05 PM, "Pete Resnick" wrote: >The changes look fine. Thanks. > >pr > >On 8/9/14 11:54 AM, Sri Gundavelli (sgundave) wrote: >> Hi Pete, >> >> Thanks for the review. Please see inline. >> >> >> >> On 8/6/14 8:59 PM, "Pete Resnick" wrote: >> >> =20 >>> Pete Resnick has entered the following ballot position for >>> draft-ietf-netext-pmip-cp-up-separation-05: No Objection >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to >>>http://www.ietf.org/iesg/statement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>>=20 >>>http://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> COMMENT: >>> ---------------------------------------------------------------------- >>> >>> A few weirdnesses in section 4: >>> >>> There can be multiple >>> instances of the LMA User Plane Address mobility option present in >>> the message, one for IPv4 and the other for IPv6 transport. >>> >>> Do you really mean "there can be multiple instances", or do you rather >>> mean "there can be either one or two instances: One for IPv4, one for >>> IPv6, or one for each of them"? >>> =20 >> >> We tried to say there can be one or two instance of the option (option >> format in Section 4), one for each IP version. >> >> OLD: >> >> The LMA User Plane Address mobility option is a new mobility header >> option defined for use with PBU and PBA messages exchanged between >> the LMA and the MAG. This option is used for notifying the MAG >>about >> the LMA's user plane IPv6 or IPv4 address. There can be multiple >> instances of the LMA User Plane Address mobility option present in >> the message, one for IPv4 and the other for IPv6 transport. >> >> NEW: >> >> The LMA User Plane Address mobility option is a new mobility header >> option defined for use with PBU and PBA messages exchanged between >> the LMA and the MAG. This option is used for notifying the MAG >>about >> the LMA's user plane IPv6 or IPv4 address. There can be zero, one or >> two instances of the LMA User Plane Address mobility option present in >> the message. When two instances of the option are present, one instance >> of the option must be for IPv4 transport and the other instance must be >> for IPv6 transport. >> >> >> (Or, please suggest text) >> >> >> >> >> >> >> =20 >>> ...the IP address field >>> in the option can be either a zero-length field, or... >>> >>> Two instances of the above. Should that "can" be a MUST? >>> ' >>> =20 >> >> Yes. Thanks. >> >> >> OLD: >> >> o When using IPv4 transport for the user-plane, the IP address field >> in the option can be either a zero-length field, or a 4-octet >> field with ALL_ZERO value. >> >> o When using IPv6 transport for the user-plane, the IP address >>field >> in the option can be either a zero-length field, or a 16-octet >> field with ALL_ZERO value. >> >> >> >> NEW: >> >> o When using IPv4 transport for the user-plane, the IP address field >> in the option MUST be either a zero-length field, or a 4-octet >> field with ALL_ZERO value. >> >> o When using IPv6 transport for the user-plane, the IP address field >> in the option MUST be either a zero-length field, or a 16-octet >> field with ALL_ZERO value. >> >> >> >> >> >> >> >> =20 >>> ...the IP address field in the option MUST be set... >>> >>> In the above and the two bullet items below it: Shouldn't the "MUST be" >>> in each one instead be "is"? There's no protocol requirement there. >>>What >>> else *could* an implementation do? >>> >>> =20 >> Ok. >> >> OLD: >> >> o When using IPv4 transport for the user-plane, the IP address field >> in the option MUST be the IPv4 address carrying user-plane >> traffic. >> >> o When using IPv6 transport for the user-plane, the IP address >>field >> in the option MUST be the IPv6 address carrying user-plane >> traffic. >> >> >> NEW: >> >> o When using IPv4 transport for the user-plane, the IP address field >> in the option is the IPv4 address carrying user-plane >> traffic. >> >> o When using IPv6 transport for the user-plane, the IP address >>field >> in the option is the IPv6 address carrying user-plane >> traffic. >> >> >> >> >> >> Regards >> Sri >> =20 > >--=20 >Pete Resnick >Qualcomm Technologies, Inc. - +1 (858)651-4478 > From nobody Tue Aug 12 16:25:40 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1242B1A0AD4; Tue, 12 Aug 2014 16:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uP9o-qN7JW5W; Tue, 12 Aug 2014 16:25:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C41201A0086; Tue, 12 Aug 2014 16:25:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140812232535.10148.6540.idtracker@ietfa.amsl.com> Date: Tue, 12 Aug 2014 16:25:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/nShcyrMqd7bOaRMjfo8LZ6hp7co Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip-cp-up-separation-06.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 23:25:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Separation of Control and User Plane for Proxy Mobile IPv6 Authors : Ryuji Wakikawa Rajesh S. Pazhyannur Sri Gundavelli Charles E. Perkins Filename : draft-ietf-netext-pmip-cp-up-separation-06.txt Pages : 11 Date : 2014-08-12 Abstract: This document specifies a method to split the Control Plane (CP) and User Plane (UP) for a Proxy Mobile IPv6 based network infrastructure. Existing specifications allow a mobile access gateway (MAG) to separate its control and user plane using the Alternate Care of address mobility option for IPv6, or Alternate IPv4 Care of Address option for IPv4. However, the current specification does not provide any mechanism allowing the local mobility anchor (LMA) to perform an analogous functional split. To remedy that shortcoming, this document specifies a mobility option enabling a LMA to provide an alternate LMA address to be used for the bi-directional user plane traffic between the MAG and LMA. With this new option, a LMA will be able to use an IP address for its user plane which is different than the IP address used for the control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmip-cp-up-separation-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip-cp-up-separation-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 12 16:25:42 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C141A0AD4 for ; Tue, 12 Aug 2014 16:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOa1jbr4CrtK; Tue, 12 Aug 2014 16:25:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EEFF11A0712; Tue, 12 Aug 2014 16:25:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: netext-chairs@tools.ietf.org, draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org, netext@ietf.org, brian@innovationslab.net, stephen.farrell@cs.tcd.ie X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140812232535.10148.33389.idtracker@ietfa.amsl.com> Date: Tue, 12 Aug 2014 16:25:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/nHdkxGbmL0BExMuEbZndqwBmWR4 Subject: [netext] New Version Notification - draft-ietf-netext-pmip-cp-up-separation-06.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 23:25:38 -0000 A new version (-06) has been submitted for draft-ietf-netext-pmip-cp-up-separation: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip-cp-up-separation-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip-cp-up-separation-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Wed Aug 13 05:21:24 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 957631A0852; Wed, 13 Aug 2014 05:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXkGUqTNiBvm; Wed, 13 Aug 2014 05:21:18 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 16EA71A0826; Wed, 13 Aug 2014 05:21:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 178D7BE16; Wed, 13 Aug 2014 13:21:14 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlB0e0oNBtzV; Wed, 13 Aug 2014 13:21:13 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E75C0BE13; Wed, 13 Aug 2014 13:21:13 +0100 (IST) Message-ID: <53EB583A.5070901@cs.tcd.ie> Date: Wed, 13 Aug 2014 13:21:14 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Sri Gundavelli (sgundave)" , The IESG References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netext/sMdX2y02BwZicZ3Fa7ROKKXjDL8 Cc: "netext@ietf.org" , "netext-chairs@tools.ietf.org" , "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" Subject: Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 12:21:21 -0000 Hiya, A few follow ups... On 09/08/14 17:54, Sri Gundavelli (sgundave) wrote: > Hi Stephen, > > Thanks for the review. Please see inline. > > > > On 8/7/14 5:50 AM, "Stephen Farrell" wrote: > >> >> I have two questions. They could be easy or hard, I'm not >> sure:-) Apologies in advance if I've forgotten what little I >> ever knew about PMIPv6 and gotten stuff wrong here. > > Not at all. Thanks for the discussion. > >> >> (1) PMIPv6 traffic between MAG and LMA is generally assumed to >> be protected via IPsec, right? Assuming that's actually done, >> does figure 1 here indicate a weakening of security since it >> shows that IP encapsulation is used between MAG-UP and LMA-UP >> without any mention of IPsec. Is that downgrading security? I >> get that the binding messages are the most important and will >> presumably continue on the control plane but what else changes? > > Yes. PMIPv6 allows the use of IPsec security (Tunnel Mode ESP) protection "allows"? Do you happen to know if that's really used or not in practice? (That's not a DISCUSS point, but I do wonder.) > for the user-plane traffic. This is optional and is based on standard > IPsec security. It requires no special interaction between IPsec and the > Proxy Mobile IPv6 entities. > > In the split mode (LMA ==> LMA-CP & LMA-DP), What's LMA-DP? That's not mentioned in the draft? I assume you mean what the draft calls LMA-UP? (I.e. DP = data plane being the same as UP = user plane?) > the MAG (or MAG-DP) and the > LMA-DP can optionally enable IPsec security on the user-plane traffic. Hmm. So you're saying IPsec can be on for the control plane and off for the user plane independently? Is that a good plan? I guess it'd be a bad plan if it were the other way around? > MAG-DP establishes a layer-3 p2p tunnel to LMA-DP and both these peers can > be configured to apply IPsec security on the tunneled traffic. So, there > is no loss of functionality here and the CP/DP split approach is not > resulting in weakened security. Well, it might if IPsec is on for one and off for the other. Or, if say MAG-CP and MAG-UP are from different vendors, then I don't know how they signal to one another to turn on/off IPsec if what we want is for IPsec to be on for both or off for both. >> (2) How does the rest of the Internet know to use the LMA-UP >> for the MN and not the LMA-CP? Sorry for being dense but I >> don't see how packets from a random Internet node for the MN >> end up going down the user plane. > > The IP address of the mobile node is topologically anchored on the LMA-DP. You mean LMA-UP there right? > From the point of view of Routing, the LMA-DP owns that larger IP prefix > block from which it allocates to IP prefixes/address to individual > mobility sessions. The LMA-DP is in the path for the user-plane traffic > and is the entry point into the mobile network. However, the LMA-CP is > only terminating the control signaling from the MAG and is not in the path > for the user-plane traffic. Is that written down somewhere? If say the LMA-UP and LMA-CP had utterly different addresses then it couldn't work could it? >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> Did you need to say somewhere which PMIPv6 messages are to be >> sent in the control plane and which in the user plane? That >> might be obvious to some, but its not to me and I guess there >> are a bunch of PMIPv6 extensions so I could imagine that >> someone somewhere might get it wrong. >> > > > The signaling messages {IPv6 with Mobility Header, or IPv4 UDP Port 5436) > traffic is exchanged between MAG-CP and LMA-CP. There is no implication on > the use/non-use of other mobility options. Sure. My question is: where is it written down which are signalling messages and which are not? Ta, S. > > The tunneled traffic with L3 encapsulation is between MAG-DP and LMA-DP. > > > Regards > Sri > > > > > > > >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > From nobody Wed Aug 13 09:45:32 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 649311A00F6; Wed, 13 Aug 2014 09:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huUfT4Yw4YuH; Wed, 13 Aug 2014 09:45:21 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43CCC1A00C6; Wed, 13 Aug 2014 09:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35275; q=dns/txt; s=iport; t=1407948321; x=1409157921; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=JN499lX/15kIdvjtzx871QjaoqUyaIiicFFlukRJfRc=; b=AFZdvtWNlGgJZI0TbQB6UEihAXqP38YdjdP81B/YmBHpRpfhpHEHgb8P eBVJTSpyed8UhU3nng//FHOyZvdSJPuFzUCysMBHOkw0z1jJIP5NazLXk woAg8X07WyCzXEXx+ShardYCyYwC0Jab/2yf3mUk077uqRcCV/jLjyv1F s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAFAGSV61OtJA2D/2dsb2JhbABEFoJHRlJXBIQSxzOBWQENhnFTAYEUFneEBAEBBAEBAWsLEgEIOAECBC4LFBECBAENBYhCDcZiF4wdgkZlBAYBhEwFhQMCgQoBiHqCE4QmhnaBV4oqghyGYYIWgUZsAQGBRg X-IronPort-AV: E=Sophos; i="5.01,857,1400025600"; d="scan'208,217"; a="68963786" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-8.cisco.com with ESMTP; 13 Aug 2014 16:45:19 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s7DGjJVM019258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Aug 2014 16:45:20 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.223]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Wed, 13 Aug 2014 11:45:19 -0500 From: "Sri Gundavelli (sgundave)" To: Stephen Farrell , The IESG Thread-Topic: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT) Thread-Index: AQHPtxX3ZO0YXSnk60yjpGKdxZ8H5w== Date: Wed, 13 Aug 2014 16:45:18 +0000 Message-ID: In-Reply-To: <53EB583A.5070901@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.213] Content-Type: multipart/alternative; boundary="_000_D010C9E9158B79sgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/n-qmvvrj6Afs71hJhRS6uoT93qA Cc: "netext@ietf.org" , "netext-chairs@tools.ietf.org" , "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" Subject: Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 16:45:26 -0000 --_000_D010C9E9158B79sgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI Stephen, Please see inline. On 8/13/14 5:21 AM, "Stephen Farrell" > wrote: Hiya, A few follow ups... On 09/08/14 17:54, Sri Gundavelli (sgundave) wrote: Hi Stephen, Thanks for the review. Please see inline. On 8/7/14 5:50 AM, "Stephen Farrell" > wrote: I have two questions. They could be easy or hard, I'm not sure:-) Apologies in advance if I've forgotten what little I ever knew about PMIPv6 and gotten stuff wrong here. Not at all. Thanks for the discussion. (1) PMIPv6 traffic between MAG and LMA is generally assumed to be protected via IPsec, right? Assuming that's actually done, does figure 1 here indicate a weakening of security since it shows that IP encapsulation is used between MAG-UP and LMA-UP without any mention of IPsec. Is that downgrading security? I get that the binding messages are the most important and will presumably continue on the control plane but what else changes? Yes. PMIPv6 allows the use of IPsec security (Tunnel Mode ESP) protection "allows"? Do you happen to know if that's really used or not in practice? (That's not a DISCUSS point, but I do wonder.) Security for user-plane traffic protection is used in very few deployments.= Taking the Service Provider Wi-Fi deployment as an example, there is 802.1= x security on the air interface, and then there is typical end to end appli= cation security (even a Google search is HTTPS protected). Now requiring s= ecurity on the user plane traffic between two points in the operator networ= k (LMA and MAG) is some what redundant, IMO. Use of IPsec for UP traffic pr= otection is optional per MIPv6/PMIPv6 specs. I'd say banking type applicat= ions/deployments requires such multi-layer security. for the user-plane traffic. This is optional and is based on standard IPsec security. It requires no special interaction between IPsec and the Proxy Mobile IPv6 entities. In the split mode (LMA =3D=3D> LMA-CP & LMA-DP), What's LMA-DP? That's not mentioned in the draft? I assume you mean what the draft calls LMA-UP? (I.e. DP =3D data plane being the same as UP =3D user plane?) Apologies for the terminology mix up. Yes. LMA-DP (Data Plane) should be th= e LMA-UP (User Plane) the MAG (or MAG-DP) and the LMA-DP can optionally enable IPsec security on the user-plane traffic. Hmm. So you're saying IPsec can be on for the control plane and off for the user plane independently? Is that a good plan? I guess it'd be a bad plan if it were the other way around? I'd say this is the approach in use for today's integrated LMA (LMA-UP + LM= A-CP) based deployments. IPsec security is enabled for CP traffic by defaul= t, as it is mandated by PMIPv6 specs. However, the IPsec security for UP is= a optional requirement and most deployments don't enable IPsec for UP traf= fic protection. MAG-DP establishes a layer-3 p2p tunnel to LMA-DP and both these peers can be configured to apply IPsec security on the tunneled traffic. So, there is no loss of functionality here and the CP/DP split approach is not resulting in weakened security. Well, it might if IPsec is on for one and off for the other. Or, if say MAG-CP and MAG-UP are from different vendors, then I don't know how they signal to one another to turn on/off IPsec if what we want is for IPsec to be on for both or off for both. I'd look at IPsec as a security policy between two peers. Use of IPsec for = CP messages between two CP nodes (Ex: MAP-CP and LMA-CP) should not have an= y bearing on the use/non-use of IPsec security between two UP nodes (Ex: MA= G-UP and LMA-UP). The security policy on the two UP nodes strictly determin= e the use/non-use of IPsec for tunnel traffic protection. But, if the hint = is that this policy should be controlled by the respective CP entity, I'd s= ay yes, but that CP to UP interface is out of scope for this work. The cont= roller/CP entity may have a provisioning interface to the UP nodes and that= interface may dictate this aspect, but has not implication on this draft. (2) How does the rest of the Internet know to use the LMA-UP for the MN and not the LMA-CP? Sorry for being dense but I don't see how packets from a random Internet node for the MN end up going down the user plane. The IP address of the mobile node is topologically anchored on the LMA-DP. You mean LMA-UP there right? Yes. Sorry for the terminology mix-up. >From the point of view of Routing, the LMA-DP owns that larger IP prefix block from which it allocates to IP prefixes/address to individual mobility sessions. The LMA-DP is in the path for the user-plane traffic and is the entry point into the mobile network. However, the LMA-CP is only terminating the control signaling from the MAG and is not in the path for the user-plane traffic. Is that written down somewhere? If say the LMA-UP and LMA-CP had utterly different addresses then it couldn't work could it? This was captured in Section 5.6.2 for IPv6 http://tools.ietf.org/html/rfc5213#page-38 Section 3.1.3 for IPv4 http://tools.ietf.org/html/rfc5844#page-15 When we separate the functionality, the user plane (or the IP address/prefi= xes allocated to the MN) must be anchored on the LMA-UP. I think we missed = capturing this in the spec. Thanks for pointing this out. OLD: The LMA Control Plane and the LMA User Plane functions are typically deployed on the same IP node and in such scenario the interface between these functions is internal to the implementation. Deployments may also choose to deploy the LMA Control Plane and the LMA User Plane functions on seperate IP nodes. In such deployment models, there needs to be a protocol interface between these two functions and which is outside the scope of this document. Possible options for such interface include OpenFlow [OpenFlow-Spec-v1.4.0 ], FORCES [RFC5810 ], use of routing infra= structure [I-D.matsushima-stateless-uplane-vepc = ] or vendor specific approaches. This specification does not mandate a specific protocol interface and views this interface as a generic interface relevant more broadly for many other protocol systems in addition to Proxy Mobile IPv6. NEW: The LMA Control Plane and the LMA User Plane functions are typically deployed on the same IP node and in such scenario the interface between these functions is internal to the implementation. Deployments may also choose to deploy the LMA Control Plane and the LMA User Plane functions on seperate IP nodes. In such deployment models, there needs to be a protocol interface between these two functions and which is outside the scope of this document. Possible options for such interface include OpenFlow [OpenFlow-Spec-v1.4.0 ], FORCES [RFC5810 ], use of routing infra= structure [I-D.matsushima-stateless-uplane-vepc = ] or vendor specific approaches. This specification does not mandate a specific protocol interface and views this interface as a generic interface relevant more broadly for many other protocol systems in addition to Proxy Mobile IPv6. When the LMA Control Plane and the LMA User Plane functions are deployed on separate IP nodes, the requirement related to user-plane address anchoring specified in Section 5.6.2 [RFC-5213] and Section 3.1.3 [RFC5844]= must be met by the node hosting the LMA user plane functionality. The LMA user = plane node must be topological anchor point for the IP address/prefixes allocated to the mobile node. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Did you need to say somewhere which PMIPv6 messages are to be sent in the control plane and which in the user plane? That might be obvious to some, but its not to me and I guess there are a bunch of PMIPv6 extensions so I could imagine that someone somewhere might get it wrong. The signaling messages {IPv6 with Mobility Header, or IPv4 UDP Port 5436) traffic is exchanged between MAG-CP and LMA-CP. There is no implication on the use/non-use of other mobility options. Sure. My question is: where is it written down which are signalling messages and which are not? PMIPv6 Signaling messages (aka control plane messages) are PBU/PBA, BRI/BRA= and UPN/UPA messages. The formats for these messages are specified in RFC = 5213, 5844, 5846, 5847, 7077. Ex: http://tools.ietf.org/html/rfc5213#page-69 http://tools.ietf.org/html/rfc6275#page-42 The identification of any of these CP messages is the use of the following = selector. 1. Any IPv4-UDP packets with UDP port 5436 2. Any IPv6 packets with Mobility Header messages Existing specs clearly explain this and I think its sufficiently clear for = the implementors on what traffic goes to LMA-CP and what goes to the LMA-UP= . Regards Sri Ta, S. The tunneled traffic with L3 encapsulation is between MAG-DP and LMA-DP. Regards Sri _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --_000_D010C9E9158B79sgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9A10219450E87C4BBAB54924707570B4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
HI Stephen,

Please see inline.


On 8/13/14 5:21 AM, "Stephen Farr= ell" <stephen.farrell@= cs.tcd.ie> wrote:


Hiya,

A few follow ups...

On 09/08/14 17:54, Sri Gundavelli (sgundave) wrote:
Hi Stephen,
Thanks for the review. Please see inline.
On 8/7/14 5:50 AM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:

I have two questions. They could be easy or hard, I'm not
sure:-) Apologies in advance if I've forgotten what little I
ever knew about PMIPv6 and gotten stuff wrong here.
Not at all. Thanks for the discussion.

(1) PMIPv6 traffic between MAG and LMA is generally assumed to
be protected via IPsec, right? Assuming that's actually done,
does figure 1 here indicate a weakening of security since it
shows that IP encapsulation is used between MAG-UP and LMA-UP
without any mention of IPsec. Is that downgrading security? I
get that the binding messages are the most important and will
presumably continue on the control plane but what else changes?
Yes. PMIPv6 allows the use of IPsec security (Tunnel Mode ESP) protect= ion

"allows"? Do you happen to know if that's really used or not=
in practice? (That's not a DISCUSS point, but I do wonder.)

Security for user-plane traffic protection is used in very = few deployments. Taking the Service Provider Wi-Fi deployment as an example= , there is 802.1x security on the air interface, and then there is typical end to end application security (even= a Google search is HTTPS protected).  Now requiring security on the u= ser plane traffic between two points in the operator network (LMA and MAG) = is some what redundant, IMO. Use of IPsec for UP traffic protection is optional per MIPv6/PMIPv6 specs.  = I'd say banking type applications/deployments requires such multi-layer sec= urity. 



for the user-plane traffic. This is optional and is based on standard<= /div>
IPsec security. It requires no special interaction between IPsec and t= he
Proxy Mobile IPv6 entities.
In the split mode (LMA =3D=3D> LMA-CP & LMA-DP),

What's LMA-DP? That's not mentioned in the draft? I assume you
mean what the draft calls LMA-UP? (I.e. DP =3D data plane being
the same as UP =3D user plane?)

Apologies for the terminology mix up. Yes. LMA-DP (Data Pla= ne) should be the LMA-UP (User Plane)



the MAG (or MAG-DP) and the
LMA-DP can optionally enable IPsec security on the user-plane traffic.=

Hmm. So you're saying IPsec can be on for the control plane and
off for the user plane independently? Is that a good plan? I
guess it'd be a bad plan if it were the other way around?


I'd say this is the approach in use for today's integrated = LMA (LMA-UP + LMA-CP) based deployments. IPsec security is enabled for = CP traffic by default, as it is mandated by PMIPv6 specs. However, the IPsec security for UP is a optional requirement= and most deployments don't enable IPsec for UP traffic protection.




MAG-DP establishes a layer-3 p2p tunnel to LMA-DP and both these peers= can
be configured to apply IPsec security on the tunneled traffic. So, the= re
is no loss of functionality here and the CP/DP split approach is not
resulting in weakened security.

Well, it might if IPsec is on for one and off for the other.

Or, if say MAG-CP and MAG-UP are from different vendors, then
I don't know how they signal to one another to turn on/off
IPsec if what we want is for IPsec to be on for both or off
for both.


I'd look at IPsec as a security policy between two peers. U= se of IPsec for CP messages between two CP nodes (Ex: MAP-CP and LMA-CP) sh= ould not have any bearing on the use/non-use of IPsec security between two UP nodes (Ex: MAG-UP and LMA-UP). The securi= ty policy on the two UP nodes strictly determine the use/non-use of IPsec f= or tunnel traffic protection. But, if the hint is that this policy should b= e controlled by the respective CP entity, I'd say yes, but that CP to UP interface is out of scope for this = work. The controller/CP entity may have a provisioning interface to the UP = nodes and that interface may dictate this aspect, but has not implication o= n this draft.




(2) How does the rest of the Internet know to use the LMA-UP
for the MN and not the LMA-CP? Sorry for being dense but I
don't see how packets from a random Internet node for the MN
end up going down the user plane.
The IP address of the mobile node is topologically anchored on the LMA= -DP.

You mean LMA-UP there right?


Yes. Sorry for the terminology mix-up.


From the point of view of Routing, the LMA-DP owns that larger IP pref= ix
block from which it allocates to IP prefixes/address to individual
mobility sessions. The LMA-DP is in the path for the user-plane traffi= c
and is the entry point into the mobile network.  However, th= e LMA-CP is
only terminating the control signaling from the MAG and is not in the = path
for the user-plane traffic.

Is that written down somewhere? If say the LMA-UP and LMA-CP had
utterly different addresses then it couldn't work could it?


This was captured in Section 5.6.2 for IPv6=

Section 3.1.3 for IPv4

When we separate the functionality, the user plane (or the = IP address/prefixes allocated to the MN) must be anchored on the LMA-UP. I = think we missed capturing this in the spec. Thanks for pointing this out. 


OLD:

The LMA Control Pla= ne and the LMA User Plane functions are typically
deployed on the sam= e IP node and in such scenario the interface
between these funct= ions is internal to the implementation.
Deployments may als= o choose to deploy the LMA Control Plane and the
LMA User Plane func= tions on seperate IP nodes. In such deployment
models, there needs= to be a protocol interface between these two
functions and which= is outside the scope of this document. Possible
options for such in= terface include OpenFlow [OpenFlow-Spec-v1.4.0 <http://tools.ietf.org/ht= ml/draft-ietf-netext-pmip-cp-up-separation-06#ref-OpenFlow-Spec-v1.4.0>]= ,
FORCES [RFC5810 <= ;http://tools.ietf.org/html/rfc5810>], use of routing infrastructure
[I-D.matsushima-sta= teless-uplane-vepc <http://tools.ietf.org/html/draft-ietf-netext-pmip-cp= -up-separation-06#ref-I-D.matsushima-stateless-uplane-vepc>] or vendor s= pecific approaches.
This specification = does not mandate a specific protocol interface and
views this interfac= e as a generic interface relevant more broadly for
many other protocol= systems in addition to Proxy Mobile IPv6.


NEW:

The LMA Control Pla= ne and the LMA User Plane functions are typically
deployed on the sam= e IP node and in such scenario the interface
between these funct= ions is internal to the implementation.
Deployments may als= o choose to deploy the LMA Control Plane and the
LMA User Plane func= tions on seperate IP nodes. In such deployment
models, there needs= to be a protocol interface between these two
functions and which= is outside the scope of this document. Possible
options for such in= terface include OpenFlow [OpenFlow-Spec-v1.4.0 <http://tools.ietf.org/ht= ml/draft-ietf-netext-pmip-cp-up-separation-06#ref-OpenFlow-Spec-v1.4.0>]= ,
FORCES [RFC5810 <= ;http://tools.ietf.org/html/rfc5810>], use of routing infrastructure
[I-D.matsushima-sta= teless-uplane-vepc <http://tools.ietf.org/html/draft-ietf-netext-pmip-cp= -up-separation-06#ref-I-D.matsushima-stateless-uplane-vepc>] or vendor s= pecific approaches.
This specification = does not mandate a specific protocol interface and
views this interfac= e as a generic interface relevant more broadly for
many other protocol= systems in addition to Proxy Mobile IPv6.
When the LMA Control Plane and the LMA User Plane func= tions are deployed
on separate IP nodes, the requirement related to user-plane= address
anchoring specified in Section 5.6.2 [RFC-5213] and Se= ction 3.1.3 [RFC5844] must 
be met by the  node hosting the LMA user plane f= unctionality. The LMA user plane node
must be topological anchor point for the IP address/prefixe= s allocated
to the mobile node. 

 



----------------------------------------------------------------------=
COMMENT:
----------------------------------------------------------------------=


Did you need to say somewhere which PMIPv6 messages are to be
sent in the control plane and which in the user plane? That
might be obvious to some, but its not to me and I guess there
are a bunch of PMIPv6 extensions so I could imagine that
someone somewhere might get it wrong.

The signaling messages {IPv6 with Mobility Header, or IPv4 UDP Port 54= 36)
traffic is exchanged between MAG-CP and LMA-CP. There is no implicatio= n on
the use/non-use of other mobility options.

Sure. My question is: where is it written down which are
signalling messages and which are not?


PMIPv6 Signaling messages (aka control plane messages)= are PBU/PBA, BRI/BRA and UPN/UPA messages. The formats for these mess= ages are specified in RFC 5213, 5844, 5846, 5847, 7077. 

Ex:
http://tools.iet= f.org/html/rfc5213#page-69
http://tools.iet= f.org/html/rfc6275#page-42

The identification of any of these CP messages is the use o= f the following selector.

1. Any IPv4-UDP packets with UDP port 5436
2. Any IPv6 packets with Mobility Header messages 

Existing specs c= learly explain this and I think its sufficiently clear for the implementors= on what traffic goes to LMA-CP and what goes to the LMA-UP. 


Regards
Sri




Ta,
S.

The tunneled traffic with L3 encapsulation is between MAG-DP and LMA-D= P.
Regards
Sri

_______________________________________________
netext mailing list

--_000_D010C9E9158B79sgundaveciscocom_-- From nobody Thu Aug 21 02:01:23 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597021A00D5 for ; Thu, 21 Aug 2014 02:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.57 X-Spam-Level: X-Spam-Status: No, score=-0.57 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, J_CHICKENPOX_32=0.6, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPAs9rmQDfCi for ; Thu, 21 Aug 2014 02:01:18 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 248041A00D1 for ; Thu, 21 Aug 2014 02:01:16 -0700 (PDT) Received: from itav234.av.it.pt (account dcorujo@av.it.pt [193.136.93.234] verified) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 75859201 for netext@ietf.org; Thu, 21 Aug 2014 10:01:15 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Daniel Corujo In-Reply-To: <15424_1407496055_53E4AF77_15424_4456_1_81C77F07008CA24F9783A98CFD706F71142826EF@PEXCVZYM12.corporate.adroot.infra.ftgroup> Date: Thu, 21 Aug 2014 10:01:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <15FF7213-1157-4109-BBFD-5DBCE84E4690@av.it.pt> References: <15424_1407496055_53E4AF77_15424_4456_1_81C77F07008CA24F9783A98CFD706F71142826EF@PEXCVZYM12.corporate.adroot.infra.ftgroup> To: "netext@ietf.org" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netext/IjlWdof2oWvKvDl4VYHNS7xbwP4 Subject: Re: [netext] Logical Interface draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 09:01:21 -0000 Dear all, Please kindly accept my review on this draft. Overall, I think that it provides a very useful initial description for = the topic, but, IMHO, it is really demanding for some added details. = Please consider: 1 - The document focuses on PMIPv6. Although it is currently the = de-facto mobility management protocol, there are currently other efforts = underway, particularly DMM. I am sure that there are a lot of people who = would be interested in analysing the impact that the logical interface = would have in such architectures (or be impacted by them). As such, not = only a specific section addressing other mobility management schemes, = but actually shifting PMIPv6 to a specific scenario within this draft, = rather than than its focus, would allow the draft to be more = informatively broad and future-proof. 2 - In section 3.2.1 it is indicated that =93the handover across access = points need not to be hidden to the IP layer since the IP layer = configuration remains the same after a handover=94. However, IP = configuration steps are still triggered, such as sending out Router = Solicitations and collecting Router Advertisements, in the case of IPv6 = Stateless Autoconfiguration. This will impact the terminal, even in = intra-technology handovers. 3 - Point 2) in this email also raises an issue which should be = interesting to cover in this draft. One can consider that the identified = interface to realize PMIPv6 proceedings would be the Logical Interface. = However, in a handover situation, how would the mechanism chose through = which physical sub-interface the Router Solicitation would be sent? Each = sub-interface has a different MAC address and, in the case of IPv6 = Stateless Autoconfiguration, the requested suffix would be different. I = might be missing something, so please correct me if I am wrong. = Nonetheless, this also hints that the scenarios shown in sections 6.1 = and 6.2 could use a little bit of more information and detail. 4 - Also in section 3.2.1, in the 2nd paragraph, regarding =93the = logical interface would not be used to provide simultaneous access for = purposes of multihoming or flow mobility=94: would it be interesting to = consider load balancing or reliability aspects, considering a Single IP = Address / Multiple physical interfaces case? 5 - I think that section 4, which is called =93Technology Use Cases=94 = should be enhanced with more examples. Basically all the examples = indicated in this section have been hinted in text here and there in the = previous sections, so it does not explicitly add nothing new. 6 - In section 5, regarding the 1st property of the logical interface, = it would be interesting to add a bit more information on how its = relationship with the set of physical interfaces is done. Is it just the = LIF and FLOW tables? 7 - In section 5.1, regarding the =93logical router that in turns = decides which physical interface is to be used to transmit packets=94, = seems to me to be very interesting and could be further extended to = encompass rule-based configuration. For example, besides the usual = =93default=94 rule, a sequential list, just to name an example. 8 - In section 5.2, the PIF table is mentioned, but Figure 2 addresses = the LIF table and FLOW table. 9 - In section 5.2, is it possible to add indication on how the tables = can handle several LIF=92s? Or each LIF has its own set of tables? If = so, whenever packets are received, does the =93Connection Manager=94 = need to check each table from each LIF, as per =93In case traffic of an = existing flow is suddenly received from the network on a different = sub-interface than the one locally stored, the logical interface should = interprete the event as an explicit flow mobility trigger from the = network (=85)=94. Seems to me that this would cause some performance = issues=85 10 - In Sections 6.1 and 6.2, as indicated before, more details should = be given about each procedure. For example, beyond the LMA=92s Binding = Table, it would be interesting to see the dynamics of the LIF and FLOW = tables before and after the handover. This is important to evaluate the = behaviour aspects of the LIF in particular situations as well, such as = handovering a flow to an interface that has been connected for sometime.=20= 11 - The remainder of my comments are just editorial: - Abstract, line8, should be =93 (=85) details of THE logical interface = (=85) =93. - Page 3, 3rd paragraph, line 1, there is no need for =93network=94 = before =93network-based=94. - Page 3, 3rd paragraph, line 4, suggestion of replacing =93afford=94 = with =93allow=94 - Page 5, 1st paragraph, line 2, should be =93 (=85) or movement from = THE host IP layer.=94 - Page 5, Section 3.1, 2nd bullet, line 1, should be =93 (=85) that = logically groupS/bondS (=85) =93 - Page 8, Section 4, 1st paragraph, line 4, it it really =93available = devices=94 or should it be =93available accesses=94 or =93available = interfaces=94? - Page 8, Section 4, 3rd paragraph, line 1, should be =93 (=85) setup = is based on THE creation (=85) =93 - Page 10, Section 5.1, 2nd paragraph, line 3, should be =93 (=85) that = in turn decides (=85) =93 - Page 10, Section 5.2, 1st paragraph, missing =93.=94 after =93Figure = 2=94. Hope these comments support the draft. Any comments on suggestions are = welcome! Best regards, Daniel Corujo, Ph.D., Research Fellow Universidade de Aveiro, Portugal=09 http://re.vu/dcorujo Advanced Telecommunications and Networks Group - http://atnog.av.it.pt Follow us - @ATNoG_ITAv On 08 Aug 2014, at 12:07 , pierrick.seite@orange.com wrote: > Hi, > =20 > I=92ve reviewed = http://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface-suppor= t/and I have no particular issue to raise, just few editorial = suggestions (please see below). So, I agree with Danny; this doc is = useful and ready for publication. > =20 > BR, Pierrick > =20 > =20 > --- OLD ABSTRACT ------------- > A Logical Interface is a software semantic internal to the host > operating system. This semantic is available in all popular > operating systems and is used in various protocol implementations. > The Logical Interface support is required on the mobile node > operating in a Proxy Mobile IPv6 domain, for leveraging various > network-based mobility management features such as inter-technology > handoffs, multihoming and flow mobility support. This document > explains the operational details of Logical Interface construct and > the specifics on how the link-layer implementations hide the = physical > interfaces from the IP stack and from the network nodes on the > attached access networks. Furthermore, this document identifies = the > applicability of this approach to various link-layer technologies = and > analyzes the issues around it when used in context with various > mobility management features. > =20 > =20 > ------------- NEW ABSTRACT ------------- > =20 > A Logical Interface is a software semantic internal to the host > operating system. This semantic is available in all popular > operating systems and, when the terminal is equipped with more than = one interface, it can be used to hide the physical interfaces from the = IP stack. The logical interface thus allows various > network-based mobility management features such as inter-technology > handoffs, multihoming and flow mobility support. This document > explains how the Logical Interface hides the physical > interfaces from the IP stack and from the network nodes on the > attached access networks. Furthermore, this document identifies = the > applicability of this approach to various link-layer technologies = and > analyzes the issues around it when used in context with various > mobility management features. > =20 > =20 > - Old text ----------- > =20 > Specifically, it explores the use of the Logical Interface support, a > semantic available on most operating systems. > =20 > =20 > - New text ---------- > Specifically, it explores the use of the Logical Interface support, = available on most operating systems. > =20 > =20 > =20 > Section 3.1: > =20 > =AB an 802.11 STA =BB - please expand STA > =20 > s/ within the same domain/ within the same IP subnet/ > =20 > s/ the IEEE 802.11 MAC layer takes care of the mobility/ the IEEE = 802.11 MAC layer handles mobility between access points > =20 > s/ A logical interface denotes a mechanism that that logically = group/bond several/ A logical interface denotes a mechanism that = logically group several > =20 > --------- OLD text ---------- > =20 > Depending on the type of > access technologies, it might be possible to use more than one > physical interface at a time -- such that the node is > simultaneously attached via different access technologies -- or > just to perform handovers across a variety of physical = interfaces. > . > =20 > Not: It does not depent on the access technology but on the OS and the = terminal implementation, so I suggest: > =20 > ----------- NEW text ---------- > =20 > Depending on the system, it might be possible to use more than one > physical interface at a time -- such that the node is > simultaneously attached via different access technologies -- or > just to perform handovers across a variety of physical = interfaces. > =20 > =20 > =20 > ------ OLD text --------- > =20 > The configuration is typically > handled via a connection manager, and based on a combination of > user preferences on one hand, and operator preferences such as > those provisionned by the Access Network Discovery and Selection > Function (ANDSF) [TS23402] on the other hand. > =20 > =20 > -------- NEW text -------- > =20 > The configuration is typically > handled via a connection manager, and based on a combination of > user preferences, application characteristics, quality of = communications, operator preferences (e.g. provisioned by the Access = Network Discovery and Selection Function (ANDSF) [TS23402]), and so on. > =20 > =20 > S/3.2.1 link layer support/link layer mobility support/ > =20 > s/ in the same subnet with a common IP layer configuration (DHCP = server, default router, etc.)/ in the same IP subnet with a common = configuration objects (DHCP server, default gateway, etc.) > =20 > s/ In this case the handover across access points need not to be = hidden/ In this case the handover across access points does not need to = be hidden =20 > =20 > =20 > =20 > Last paragraph of 3.2.1 should be removed since the use-case is = covered by 3.2.2. Or rewrite as: > =20 > -+-------- OLD TEXT --------- > Since this type of link layer technology does not typically allow for > simultaneous attachment to different access networks of the same > technology, the logical interface would not be used to provide > simultaneous access for purposes of multihoming or flow mobility. > =20 > Note: actually, there is no multihoming or flow mobility since there = is no more than one simultaneous attachment ;-) > =20 > Instead, the logical interface can be used to provide inter-access > technology handover between this type of link layer technology and > another link layer technology, e.g., between IEEE 802.11 and IEEE > 802.16. > =20 > Note: this covered in the following section section =85 this is the = motivation of the logical interface=85. > =20 > - NEW TEXT ---------- > =20 > When the access technology does not allow a single interface to be = simultaneous attach to more than one IP network (subnet and associated = configuration objects), logical interface support is not required. > =20 > -------- OLD TEXT --------- > =20 > Doing so allows to hide inter-access > technology handovers or application flow handovers across different > physical interfaces. > =20 > --- NEW TEXT ------------ > =20 > Doing so allows to hide inter-access > technology handovers, or application flow handovers across = different > physical interfaces, from the IP stack which is by nature tight to = a single interface. > =20 > -----------Question --------------- > =20 > =20 > Section 4 states: > =20 > In some UE implementations the wireless connection setup is based on > creation of a PPP interface between the IP layer and the wireless > modem that is configured with the IPCP and IPv6CP protocol = [RFC5072]. > In this case the PPP interface does not have any L2 address = assigned. > In some other implementations the wireless modem is presented to = the > IP layer as a virtual Ethernet interface. > =20 > =20 > So what? What do you want to stress here? > - - - - ---- > =20 > =20 > Section 5: > =20 > What do you mean by =93The sub-interfaces attached to a Logical = interface are not visible to the IP and upper layers.=94 > The node can use either the logical or physical interfaces, I mean, an = application can be bound to the LI and another application bound to one = of the physical interface available. > =20 > =20 > =20 > =20 > Section 5.1: > =20 > The IP layer should be configured with a default router reachable via = the logical interface. > =20 > The IP layer should be also configured with DNS, DHCP server. Right? > =20 > Section 5.2: > =20 > In Fig.2 ::flow table : > =20 > s/ Physical_Intf_Id/PIF_ID > =20 > on section n 6.3: maybe add a reference to the draft netext-flow-mob? > =20 > =20 > General comment: In the doc, we find either =AB Logical Interface =BB, = or =AB logical interface =BB, or =AB Logical interface =BB=85. Would be = better to pick only one of these terms=85. > =20 > =20 > De : netext [mailto:netext-bounces@ietf.org] De la part de Moses, = Danny > Envoy=E9 : jeudi 7 ao=FBt 2014 17:44 > =C0 : netext@ietf.org > Objet : [netext] Logical Interface draft > =20 > Hi, > =20 > In the last meeting there was a discussion about whether or not to = publish the 'Logical Interface' draft = (http://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface-suppo= rt/). At the end of the discussion it was agreed that if at least three = new reviewers review the draft and state that it is useful, the WG will = publish it. > =20 > Well, I reviewed it (and it was the first time for me to read it) and = found the draft to be useful as a guide for OS developers (and/or = network stack developers) who wish to implement a logical interface for = supporting PMIPv6. > =20 > I found the draft to be clear, short and useful and recommend to = publish it. I found a few minor typos that should be corrected and sent = my comments to Sri. > =20 > Regards, > /Danny > =20 > =20 > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies >=20 > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext From nobody Fri Aug 22 15:52:01 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2512B1A6F73; Fri, 22 Aug 2014 15:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCMwGMJmypnz; Fri, 22 Aug 2014 15:51:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4517F1A6F6D; Fri, 22 Aug 2014 15:51:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D86ABBE00; Fri, 22 Aug 2014 23:51:48 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pbqgw6UnwGV3; Fri, 22 Aug 2014 23:51:46 +0100 (IST) Received: from [10.87.48.11] (unknown [86.46.28.247]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4210CBDFD; Fri, 22 Aug 2014 23:51:46 +0100 (IST) Message-ID: <53F7C980.6060902@cs.tcd.ie> Date: Fri, 22 Aug 2014 23:51:44 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Sri Gundavelli (sgundave)" , The IESG References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netext/PWGt6iHhjoy1csA67MC5Zxd-FI8 Cc: "netext@ietf.org" , "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" , "netext-chairs@tools.ietf.org" Subject: Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 22:51:54 -0000 Hiya, Sorry for the slow response... The indentation below is a bit messed up, I hope its clear who's saying what. On 13/08/14 17:45, Sri Gundavelli (sgundave) wrote: > HI Stephen, > > Please see inline. > > > On 8/13/14 5:21 AM, "Stephen Farrell" > > wrote: > > > Hiya, > > A few follow ups... > > On 09/08/14 17:54, Sri Gundavelli (sgundave) wrote: Hi Stephen, > Thanks for the review. Please see inline. On 8/7/14 5:50 AM, "Stephen > Farrell" > > wrote: > > I have two questions. They could be easy or hard, I'm not sure:-) > Apologies in advance if I've forgotten what little I ever knew about > PMIPv6 and gotten stuff wrong here. Not at all. Thanks for the > discussion. > > (1) PMIPv6 traffic between MAG and LMA is generally assumed to be > protected via IPsec, right? Assuming that's actually done, does > figure 1 here indicate a weakening of security since it shows that IP > encapsulation is used between MAG-UP and LMA-UP without any mention > of IPsec. Is that downgrading security? I get that the binding > messages are the most important and will presumably continue on the > control plane but what else changes? Yes. PMIPv6 allows the use of > IPsec security (Tunnel Mode ESP) protection > > "allows"? Do you happen to know if that's really used or not in > practice? (That's not a DISCUSS point, but I do wonder.) > > Security for user-plane traffic protection is used in very few > deployments. Ah. > Taking the Service Provider Wi-Fi deployment as an > example, there is 802.1x security on the air interface, and then > there is typical end to end application security (even a Google > search is HTTPS protected). Now requiring security on the user plane > traffic between two points in the operator network (LMA and MAG) is > some what redundant, IMO. Use of IPsec for UP traffic protection is > optional per MIPv6/PMIPv6 specs. I'd say banking type > applications/deployments requires such multi-layer security. Hmm. I don't see that it makes any sense to assume IPsec is done differently per-application. So I guess we ought assume that IPsec isn't used for user traffic. Is it really used for control plane traffic do you know? But in a sense this spec is lowering the bar a little. 5213 requires implementation of IPsec on the node that carries the UP traffic, even if it doesn't require its use. In this case, you're not even requiring implementation. So if say, a MAG-UP were to talk to a LMA that is both CP and UP, then the latter node would support IPsec for UP, if so configured, but the MAG-UP might not even implement IPsec. Does that mean that you need to a a requirement here to make IPsec MTI for the MAG-UP and LMA-UP, so that they can interop with non-split MAGs and LMAs? I'd assume that'd be easy enough and it'd clear up that discuss point. > for the user-plane traffic. This is optional and is based on > standard IPsec security. It requires no special interaction between > IPsec and the Proxy Mobile IPv6 entities. In the split mode (LMA ==> > LMA-CP & LMA-DP), > > What's LMA-DP? That's not mentioned in the draft? I assume you mean > what the draft calls LMA-UP? (I.e. DP = data plane being the same as > UP = user plane?) > > Apologies for the terminology mix up. Yes. LMA-DP (Data Plane) should > be the LMA-UP (User Plane) > > > > the MAG (or MAG-DP) and the LMA-DP can optionally enable IPsec > security on the user-plane traffic. > > Hmm. So you're saying IPsec can be on for the control plane and off > for the user plane independently? Is that a good plan? I guess it'd > be a bad plan if it were the other way around? > > > I'd say this is the approach in use for today's integrated LMA > (LMA-UP + LMA-CP) based deployments. IPsec security is enabled for CP > traffic by default, as it is mandated by PMIPv6 specs. However, the > IPsec security for UP is a optional requirement and most deployments > don't enable IPsec for UP traffic protection. > > > > MAG-DP establishes a layer-3 p2p tunnel to LMA-DP and both these > peers can be configured to apply IPsec security on the tunneled > traffic. So, there is no loss of functionality here and the CP/DP > split approach is not resulting in weakened security. > > Well, it might if IPsec is on for one and off for the other. > > Or, if say MAG-CP and MAG-UP are from different vendors, then I don't > know how they signal to one another to turn on/off IPsec if what we > want is for IPsec to be on for both or off for both. > > > I'd look at IPsec as a security policy between two peers. Use of > IPsec for CP messages between two CP nodes (Ex: MAP-CP and LMA-CP) > should not have any bearing on the use/non-use of IPsec security > between two UP nodes (Ex: MAG-UP and LMA-UP). The security policy on > the two UP nodes strictly determine the use/non-use of IPsec for > tunnel traffic protection. But, if the hint is that this policy > should be controlled by the respective CP entity, I'd say yes, but > that CP to UP interface is out of scope for this work. The > controller/CP entity may have a provisioning interface to the UP > nodes and that interface may dictate this aspect, but has not > implication on this draft. > > > > > (2) How does the rest of the Internet know to use the LMA-UP for the > MN and not the LMA-CP? Sorry for being dense but I don't see how > packets from a random Internet node for the MN end up going down the > user plane. The IP address of the mobile node is topologically > anchored on the LMA-DP. > > You mean LMA-UP there right? > > > Yes. Sorry for the terminology mix-up. > > >> From the point of view of Routing, the LMA-DP owns that larger IP >> prefix > block from which it allocates to IP prefixes/address to individual > mobility sessions. The LMA-DP is in the path for the user-plane > traffic and is the entry point into the mobile network. However, the > LMA-CP is only terminating the control signaling from the MAG and is > not in the path for the user-plane traffic. > > Is that written down somewhere? If say the LMA-UP and LMA-CP had > utterly different addresses then it couldn't work could it? > > > This was captured in Section 5.6.2 for IPv6 > http://tools.ietf.org/html/rfc5213#page-38 > > Section 3.1.3 for IPv4 http://tools.ietf.org/html/rfc5844#page-15 > > When we separate the functionality, the user plane (or the IP > address/prefixes allocated to the MN) must be anchored on the LMA-UP. > I think we missed capturing this in the spec. Thanks for pointing > this out. > > > OLD: > > The LMA Control Plane and the LMA User Plane functions are typically > deployed on the same IP node and in such scenario the interface > between these functions is internal to the implementation. > Deployments may also choose to deploy the LMA Control Plane and the > LMA User Plane functions on seperate IP nodes. In such deployment > models, there needs to be a protocol interface between these two > functions and which is outside the scope of this document. Possible > options for such interface include OpenFlow [OpenFlow-Spec-v1.4.0 > ], > > FORCES [RFC5810 ], use of routing infrastructure > [I-D.matsushima-stateless-uplane-vepc > ] > or vendor specific approaches. This specification does not mandate a > specific protocol interface and views this interface as a generic > interface relevant more broadly for many other protocol systems in > addition to Proxy Mobile IPv6. > > > NEW: > > The LMA Control Plane and the LMA User Plane functions are typically > deployed on the same IP node and in such scenario the interface > between these functions is internal to the implementation. > Deployments may also choose to deploy the LMA Control Plane and the > LMA User Plane functions on seperate IP nodes. In such deployment > models, there needs to be a protocol interface between these two > functions and which is outside the scope of this document. Possible > options for such interface include OpenFlow [OpenFlow-Spec-v1.4.0 > ], > > FORCES [RFC5810 ], use of routing infrastructure > [I-D.matsushima-stateless-uplane-vepc > ] > or vendor specific approaches. This specification does not mandate a > specific protocol interface and views this interface as a generic > interface relevant more broadly for many other protocol systems in > addition to Proxy Mobile IPv6. When the LMA Control Plane and the LMA > User Plane functions are deployed on separate IP nodes, the > requirement related to user-plane address anchoring specified in > Section 5.6.2 [RFC-5213] and Section 3.1.3 [RFC5844] must be met by > the node hosting the LMA user plane functionality. The LMA user > plane node must be topological anchor point for the IP > address/prefixes allocated to the mobile node. I'm not quite sure if that does sort out the issue or not, but I'm willing to believe you and Brian if you're telling me it does. So with that OLD/NEW and adding IPsec as MTI for the *-UP nodes, I think we'd be done. Cheers, S. > > > > > > ---------------------------------------------------------------------- > > COMMENT: > ---------------------------------------------------------------------- > > > > Did you need to say somewhere which PMIPv6 messages are to be sent in > the control plane and which in the user plane? That might be obvious > to some, but its not to me and I guess there are a bunch of PMIPv6 > extensions so I could imagine that someone somewhere might get it > wrong. > > The signaling messages {IPv6 with Mobility Header, or IPv4 UDP Port > 5436) traffic is exchanged between MAG-CP and LMA-CP. There is no > implication on the use/non-use of other mobility options. > > Sure. My question is: where is it written down which are signalling > messages and which are not? > > > PMIPv6 Signaling messages (aka control plane messages) are PBU/PBA, > BRI/BRA and UPN/UPA messages. The formats for these messages are > specified in RFC 5213, 5844, 5846, 5847, 7077. > > Ex: http://tools.ietf.org/html/rfc5213#page-69 > http://tools.ietf.org/html/rfc6275#page-42 > > The identification of any of these CP messages is the use of the > following selector. > > 1. Any IPv4-UDP packets with UDP port 5436 2. Any IPv6 packets with > Mobility Header messages > > Existing specs clearly explain this and I think its sufficiently > clear for the implementors on what traffic goes to LMA-CP and what > goes to the LMA-UP. > > > Regards Sri > > > > > Ta, S. > > The tunneled traffic with L3 encapsulation is between MAG-DP and > LMA-DP. Regards Sri > > _______________________________________________ netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > From nobody Fri Aug 22 16:09:01 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05DA1A03E9; Fri, 22 Aug 2014 16:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwDFmgdaLhoF; Fri, 22 Aug 2014 16:08:37 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 823751A070A; Fri, 22 Aug 2014 16:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33343; q=dns/txt; s=iport; t=1408748918; x=1409958518; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=m85gWRRNqLaGWz6HqfMx16qfwG8FYkVovBV3ckSKIPY=; b=ig7/5xse6KdL/eDH3HK4ERqhm153ilRWdPg6YvLJvFbHT8yHpihxL8sJ VG+/dgvYq0iXcZ0M3iarW4hTLtKazHiJMuvKQHpaHD/VTofVtUnhu/LFi VQvqh+Z7v/qdVjWzM3wAQmSq1GI/buNT/9nN/7YMpMuBdTY8001o+NbW9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYNAOPM91OtJA2F/2dsb2JhbABDFoJHRlNXBIQUxmWBWQENhnZTAYEOFneEBAEBAwEBAQEXTQcLBQ0BCDgDBC4LFBECBAENBYg6CA3EcheMHYJGZQQGAYRMBYUEAoEKAYkCghOEKYZ6gViKNIIchmSCGIFGbAEBgUaBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,384,1406592000"; d="scan'208,217";a="349620855" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP; 22 Aug 2014 23:08:36 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id s7MN8aRp016689 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 22 Aug 2014 23:08:36 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.223]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Fri, 22 Aug 2014 18:08:35 -0500 From: "Sri Gundavelli (sgundave)" To: Stephen Farrell , The IESG Thread-Topic: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT) Thread-Index: AQHPvl4AaoCuodshIEuqOa9a/u8Gsw== Date: Fri, 22 Aug 2014 23:08:35 +0000 Message-ID: In-Reply-To: <53F7C980.6060902@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.213] Content-Type: multipart/alternative; boundary="_000_D01D191715B2BFsgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/50H0sYGAENgQxC9DpGpHtizmACI Cc: "netext@ietf.org" , "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" , "netext-chairs@tools.ietf.org" Subject: Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 23:08:45 -0000 --_000_D01D191715B2BFsgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stephen, Thanks for the review. > In this case, you're not even requiring implementation. So if say, a MAG-UP were to talk to a LMA that is both CP and UP, then the latter node would support IPsec for UP, if so configured, but the MAG-UP might not even implement IPsec. > Does that mean that you need to a a requirement here to make IPsec MTI for the MAG-UP and LMA-UP, so that they can interop with non-split MAGs and LMAs? Requiring IPsec implementation on both the MAG-UP and LMA-UP nodes is a fai= r requirement. We can certainly state that. If an operator chooses to do so= they can configures IPSec policy on LMA-UP and MAG-UP for PMIP tunnel traf= fic protection. This will keep the spec consistent with the base RFC5213. The signaling between LMA-CP and MAG-CP needs to be protected by IPsec and= that is a mandatory requirement in RFC5213. No change there. This specific= ation still requires IPsec protection for control plane traffic between MAG= -CP and LMA-CP. We will draft some text to reflect this and post it for your review. Regards Sri On 8/22/14 3:51 PM, "Stephen Farrell" > wrote: Hiya, Sorry for the slow response... The indentation below is a bit messed up, I hope its clear who's saying what. On 13/08/14 17:45, Sri Gundavelli (sgundave) wrote: HI Stephen, Please see inline. On 8/13/14 5:21 AM, "Stephen Farrell" > wrote: Hiya, A few follow ups... On 09/08/14 17:54, Sri Gundavelli (sgundave) wrote: Hi Stephen, Thanks for the review. Please see inline. On 8/7/14 5:50 AM, "Stephen Farrell" > wrote: I have two questions. They could be easy or hard, I'm not sure:-) Apologies in advance if I've forgotten what little I ever knew about PMIPv6 and gotten stuff wrong here. Not at all. Thanks for the discussion. (1) PMIPv6 traffic between MAG and LMA is generally assumed to be protected via IPsec, right? Assuming that's actually done, does figure 1 here indicate a weakening of security since it shows that IP encapsulation is used between MAG-UP and LMA-UP without any mention of IPsec. Is that downgrading security? I get that the binding messages are the most important and will presumably continue on the control plane but what else changes? Yes. PMIPv6 allows the use of IPsec security (Tunnel Mode ESP) protection "allows"? Do you happen to know if that's really used or not in practice? (That's not a DISCUSS point, but I do wonder.) Security for user-plane traffic protection is used in very few deployments. Ah. Taking the Service Provider Wi-Fi deployment as an example, there is 802.1x security on the air interface, and then there is typical end to end application security (even a Google search is HTTPS protected). Now requiring security on the user plane traffic between two points in the operator network (LMA and MAG) is some what redundant, IMO. Use of IPsec for UP traffic protection is optional per MIPv6/PMIPv6 specs. I'd say banking type applications/deployments requires such multi-layer security. Hmm. I don't see that it makes any sense to assume IPsec is done differently per-application. So I guess we ought assume that IPsec isn't used for user traffic. Is it really used for control plane traffic do you know? But in a sense this spec is lowering the bar a little. 5213 requires implementation of IPsec on the node that carries the UP traffic, even if it doesn't require its use. In this case, you're not even requiring implementation. So if say, a MAG-UP were to talk to a LMA that is both CP and UP, then the latter node would support IPsec for UP, if so configured, but the MAG-UP might not even implement IPsec. Does that mean that you need to a a requirement here to make IPsec MTI for the MAG-UP and LMA-UP, so that they can interop with non-split MAGs and LMAs? I'd assume that'd be easy enough and it'd clear up that discuss point. for the user-plane traffic. This is optional and is based on standard IPsec security. It requires no special interaction between IPsec and the Proxy Mobile IPv6 entities. In the split mode (LMA =3D=3D> LMA-CP & LMA-DP), What's LMA-DP? That's not mentioned in the draft? I assume you mean what the draft calls LMA-UP? (I.e. DP =3D data plane being the same as UP =3D user plane?) Apologies for the terminology mix up. Yes. LMA-DP (Data Plane) should be the LMA-UP (User Plane) the MAG (or MAG-DP) and the LMA-DP can optionally enable IPsec security on the user-plane traffic. Hmm. So you're saying IPsec can be on for the control plane and off for the user plane independently? Is that a good plan? I guess it'd be a bad plan if it were the other way around? I'd say this is the approach in use for today's integrated LMA (LMA-UP + LMA-CP) based deployments. IPsec security is enabled for CP traffic by default, as it is mandated by PMIPv6 specs. However, the IPsec security for UP is a optional requirement and most deployments don't enable IPsec for UP traffic protection. MAG-DP establishes a layer-3 p2p tunnel to LMA-DP and both these peers can be configured to apply IPsec security on the tunneled traffic. So, there is no loss of functionality here and the CP/DP split approach is not resulting in weakened security. Well, it might if IPsec is on for one and off for the other. Or, if say MAG-CP and MAG-UP are from different vendors, then I don't know how they signal to one another to turn on/off IPsec if what we want is for IPsec to be on for both or off for both. I'd look at IPsec as a security policy between two peers. Use of IPsec for CP messages between two CP nodes (Ex: MAP-CP and LMA-CP) should not have any bearing on the use/non-use of IPsec security between two UP nodes (Ex: MAG-UP and LMA-UP). The security policy on the two UP nodes strictly determine the use/non-use of IPsec for tunnel traffic protection. But, if the hint is that this policy should be controlled by the respective CP entity, I'd say yes, but that CP to UP interface is out of scope for this work. The controller/CP entity may have a provisioning interface to the UP nodes and that interface may dictate this aspect, but has not implication on this draft. (2) How does the rest of the Internet know to use the LMA-UP for the MN and not the LMA-CP? Sorry for being dense but I don't see how packets from a random Internet node for the MN end up going down the user plane. The IP address of the mobile node is topologically anchored on the LMA-DP. You mean LMA-UP there right? Yes. Sorry for the terminology mix-up. >From the point of view of Routing, the LMA-DP owns that larger IP prefix block from which it allocates to IP prefixes/address to individual mobility sessions. The LMA-DP is in the path for the user-plane traffic and is the entry point into the mobile network. However, the LMA-CP is only terminating the control signaling from the MAG and is not in the path for the user-plane traffic. Is that written down somewhere? If say the LMA-UP and LMA-CP had utterly different addresses then it couldn't work could it? This was captured in Section 5.6.2 for IPv6 http://tools.ietf.org/html/rfc5213#page-38 Section 3.1.3 for IPv4 http://tools.ietf.org/html/rfc5844#page-15 When we separate the functionality, the user plane (or the IP address/prefixes allocated to the MN) must be anchored on the LMA-UP. I think we missed capturing this in the spec. Thanks for pointing this out. OLD: The LMA Control Plane and the LMA User Plane functions are typically deployed on the same IP node and in such scenario the interface between these functions is internal to the implementation. Deployments may also choose to deploy the LMA Control Plane and the LMA User Plane functions on seperate IP nodes. In such deployment models, there needs to be a protocol interface between these two functions and which is outside the scope of this document. Possible options for such interface include OpenFlow [OpenFlow-Spec-v1.4.0 ], FORCES [RFC5810 ], use of routing infrastructure [I-D.matsushima-stateless-uplane-vepc ] or vendor specific approaches. This specification does not mandate a specific protocol interface and views this interface as a generic interface relevant more broadly for many other protocol systems in addition to Proxy Mobile IPv6. NEW: The LMA Control Plane and the LMA User Plane functions are typically deployed on the same IP node and in such scenario the interface between these functions is internal to the implementation. Deployments may also choose to deploy the LMA Control Plane and the LMA User Plane functions on seperate IP nodes. In such deployment models, there needs to be a protocol interface between these two functions and which is outside the scope of this document. Possible options for such interface include OpenFlow [OpenFlow-Spec-v1.4.0 ], FORCES [RFC5810 ], use of routing infrastructure [I-D.matsushima-stateless-uplane-vepc ] or vendor specific approaches. This specification does not mandate a specific protocol interface and views this interface as a generic interface relevant more broadly for many other protocol systems in addition to Proxy Mobile IPv6. When the LMA Control Plane and the LMA User Plane functions are deployed on separate IP nodes, the requirement related to user-plane address anchoring specified in Section 5.6.2 [RFC-5213] and Section 3.1.3 [RFC5844] must be met by the node hosting the LMA user plane functionality. The LMA user plane node must be topological anchor point for the IP address/prefixes allocated to the mobile node. I'm not quite sure if that does sort out the issue or not, but I'm willing to believe you and Brian if you're telling me it does. So with that OLD/NEW and adding IPsec as MTI for the *-UP nodes, I think we'd be done. Cheers, S. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Did you need to say somewhere which PMIPv6 messages are to be sent in the control plane and which in the user plane? That might be obvious to some, but its not to me and I guess there are a bunch of PMIPv6 extensions so I could imagine that someone somewhere might get it wrong. The signaling messages {IPv6 with Mobility Header, or IPv4 UDP Port 5436) traffic is exchanged between MAG-CP and LMA-CP. There is no implication on the use/non-use of other mobility options. Sure. My question is: where is it written down which are signalling messages and which are not? PMIPv6 Signaling messages (aka control plane messages) are PBU/PBA, BRI/BRA and UPN/UPA messages. The formats for these messages are specified in RFC 5213, 5844, 5846, 5847, 7077. Ex: http://tools.ietf.org/html/rfc5213#page-69 http://tools.ietf.org/html/rfc6275#page-42 The identification of any of these CP messages is the use of the following selector. 1. Any IPv4-UDP packets with UDP port 5436 2. Any IPv6 packets with Mobility Header messages Existing specs clearly explain this and I think its sufficiently clear for the implementors on what traffic goes to LMA-CP and what goes to the LMA-UP. Regards Sri Ta, S. The tunneled traffic with L3 encapsulation is between MAG-DP and LMA-DP. Regards Sri _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --_000_D01D191715B2BFsgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <81D7669F8942B84B8D48E1906A836AF7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Stephen,

Thanks for the review.


> In this case, you're not even requiring implementation.
So if say, a MAG-UP were to talk to a LMA that is both
CP and UP, then the latter node would support IPsec for
UP, if so configured, but the MAG-UP might not even
implement IPsec.

> Does that mean that you need to a a requirement here to
make IPsec MTI for the MAG-UP and LMA-UP, so that they
can interop with non-split MAGs and LMAs?


Requiring IPsec = implementation on both the MAG-UP and LMA-UP nodes is a fair requirement. W= e can certainly state that. If an operator chooses to do so they can config= ures IPSec policy on LMA-UP and MAG-UP for PMIP tunnel traffic protection. This will keep the spec consistent wit= h the base RFC5213.

The signaling be= tween LMA-CP and MAG-CP  needs to be protected by IPsec and that is a = mandatory requirement in RFC5213. No change there. This specification still= requires IPsec protection for control plane traffic between MAG-CP and LMA-CP. 

We will draft so= me text to reflect this and post it for your review. 



Regards
Sri



On 8/22/14 3:51 PM, "Stephen Farr= ell" <stephen.farrell@= cs.tcd.ie> wrote:


Hiya,

Sorry for the slow response...

The indentation below is a bit messed up, I hope its clear
who's saying what.

On 13/08/14 17:45, Sri Gundavelli (sgundave) wrote:
HI Stephen,
Please see inline.
On 8/13/14 5:21 AM, "Stephen Farrell"
Hiya,
A few follow ups...
On 09/08/14 17:54, Sri Gundavelli (sgundave) wrote: Hi Stephen,
Thanks for the review. Please see inline. On 8/7/14 5:50 AM, "Ste= phen
Farrell"
I have two questions. They could be easy or hard, I'm not sure:-)
Apologies in advance if I've forgotten what little I ever knew about
PMIPv6 and gotten stuff wrong here. Not at all. Thanks for the
discussion.
(1) PMIPv6 traffic between MAG and LMA is generally assumed to be
protected via IPsec, right? Assuming that's actually done, does
figure 1 here indicate a weakening of security since it shows that IP<= /div>
encapsulation is used between MAG-UP and LMA-UP without any mention
of IPsec. Is that downgrading security? I get that the binding
messages are the most important and will presumably continue on the
control plane but what else changes? Yes. PMIPv6 allows the use of
IPsec security (Tunnel Mode ESP) protection
"allows"? Do you happen to know if that's really used or not= in
practice? (That's not a DISCUSS point, but I do wonder.)
Security for user-plane traffic protection is used in very few
deployments.

Ah.

Taking the Service Provider Wi-Fi deployment as an
example, there is 802.1x security on the air interface, and then
there is typical end to end application security (even a Google
search is HTTPS protected).  Now requiring security on the u= ser plane
traffic between two points in the operator network (LMA and MAG) is
some what redundant, IMO. Use of IPsec for UP traffic protection is
optional per MIPv6/PMIPv6 specs.  I'd say banking type
applications/deployments requires such multi-layer security.

Hmm. I don't see that it makes any sense to assume IPsec is
done differently per-application. So I guess we ought assume
that IPsec isn't used for user traffic.

Is it really used for control plane traffic do you know?

But in a sense this spec is lowering the bar a little.
5213 requires implementation of IPsec on the node that
carries the UP traffic, even if it doesn't require its
use.

In this case, you're not even requiring implementation.
So if say, a MAG-UP were to talk to a LMA that is both
CP and UP, then the latter node would support IPsec for
UP, if so configured, but the MAG-UP might not even
implement IPsec.

Does that mean that you need to a a requirement here to
make IPsec MTI for the MAG-UP and LMA-UP, so that they
can interop with non-split MAGs and LMAs?

I'd assume that'd be easy enough and it'd clear up
that discuss point.

for the user-plane traffic. This is optional and is based on
standard IPsec security. It requires no special interaction between
IPsec and the Proxy Mobile IPv6 entities. In the split mode (LMA =3D= =3D>
LMA-CP & LMA-DP),
What's LMA-DP? That's not mentioned in the draft? I assume you mean
what the draft calls LMA-UP? (I.e. DP =3D data plane being the same as=
UP =3D user plane?)
Apologies for the terminology mix up. Yes. LMA-DP (Data Plane) should<= /div>
be the LMA-UP (User Plane)
the MAG (or MAG-DP) and the LMA-DP can optionally enable IPsec
security on the user-plane traffic.
Hmm. So you're saying IPsec can be on for the control plane and off
for the user plane independently? Is that a good plan? I guess it'd
be a bad plan if it were the other way around?
I'd say this is the approach in use for today's integrated LMA
(LMA-UP + LMA-CP) based deployments. IPsec security is enabled for= CP
traffic by default, as it is mandated by PMIPv6 specs. However, the
IPsec security for UP is a optional requirement and most deployments
don't enable IPsec for UP traffic protection.
MAG-DP establishes a layer-3 p2p tunnel to LMA-DP and both these
peers can be configured to apply IPsec security on the tunneled
traffic. So, there is no loss of functionality here and the CP/DP
split approach is not resulting in weakened security.
Well, it might if IPsec is on for one and off for the other.
Or, if say MAG-CP and MAG-UP are from different vendors, then I don't<= /div>
know how they signal to one another to turn on/off IPsec if what we
want is for IPsec to be on for both or off for both.
I'd look at IPsec as a security policy between two peers. Use of
IPsec for CP messages between two CP nodes (Ex: MAP-CP and LMA-CP)
should not have any bearing on the use/non-use of IPsec security
between two UP nodes (Ex: MAG-UP and LMA-UP). The security policy on
the two UP nodes strictly determine the use/non-use of IPsec for
tunnel traffic protection. But, if the hint is that this policy
should be controlled by the respective CP entity, I'd say yes, but
that CP to UP interface is out of scope for this work. The
controller/CP entity may have a provisioning interface to the UP
nodes and that interface may dictate this aspect, but has not
implication on this draft.
(2) How does the rest of the Internet know to use the LMA-UP for the
MN and not the LMA-CP? Sorry for being dense but I don't see how
packets from a random Internet node for the MN end up going down the
user plane. The IP address of the mobile node is topologically
anchored on the LMA-DP.
You mean LMA-UP there right?
Yes. Sorry for the terminology mix-up.
From the point of view of Routing, the LMA-DP owns that larger IP
prefix
block from which it allocates to IP prefixes/address to individual
mobility sessions. The LMA-DP is in the path for the user-plane
traffic and is the entry point into the mobile network.  How= ever, the
LMA-CP is only terminating the control signaling from the MAG and is
not in the path for the user-plane traffic.
Is that written down somewhere? If say the LMA-UP and LMA-CP had
utterly different addresses then it couldn't work could it?
This was captured in Section 5.6.2 for IPv6
When we separate the functionality, the user plane (or the IP
address/prefixes allocated to the MN) must be anchored on the LMA-UP.<= /div>
I think we missed capturing this in the spec. Thanks for pointing
this out.
OLD:
The LMA Control Plane and the LMA User Plane functions are typically <= /div>
deployed on the same IP node and in such scenario the interface
between these functions is internal to the implementation.
Deployments may also choose to deploy the LMA Control Plane and the
LMA User Plane functions on seperate IP nodes. In such deployment
models, there needs to be a protocol interface between these two
functions and which is outside the scope of this document. Possible
options for such interface include OpenFlow [OpenFlow-Spec-v1.4.0
infrastructure
[I-D.matsushima-stateless-uplane-vepc
or vendor specific approaches. This specification does not mandate a
specific protocol interface and views this interface as a generic
interface relevant more broadly for many other protocol systems in
addition to Proxy Mobile IPv6.
NEW:
The LMA Control Plane and the LMA User Plane functions are typically <= /div>
deployed on the same IP node and in such scenario the interface
between these functions is internal to the implementation.
Deployments may also choose to deploy the LMA Control Plane and the
LMA User Plane functions on seperate IP nodes. In such deployment
models, there needs to be a protocol interface between these two
functions and which is outside the scope of this document. Possible
options for such interface include OpenFlow [OpenFlow-Spec-v1.4.0
FORCES [RFC5810 <http://tools.ietf.org/html/rfc5810>], use of routing
infrastructure
[I-D.matsushima-stateless-uplane-vepc
or vendor specific approaches. This specification does not mandate a
specific protocol interface and views this interface as a generic
interface relevant more broadly for many other protocol systems in
addition to Proxy Mobile IPv6. When the LMA Control Plane and the LMA<= /div>
User Plane functions are deployed on separate IP nodes, the
requirement related to user-plane address anchoring specified in
Section 5.6.2 [RFC-5213] and Section 3.1.3 [RFC5844] must be met by
the  node hosting the LMA user plane functionality. The LMA = user
plane node must be topological anchor point for the IP
address/prefixes allocated to the mobile node.

I'm not quite sure if that does sort out the issue or not,
but I'm willing to believe you and Brian if you're telling
me it does.

So with that OLD/NEW and adding IPsec as MTI for the
*-UP nodes, I think we'd be done.

Cheers,
S.

----------------------------------------------------------------------=

COMMENT:
----------------------------------------------------------------------=

Did you need to say somewhere which PMIPv6 messages are to be sent in<= /div>
the control plane and which in the user plane? That might be obvious
to some, but its not to me and I guess there are a bunch of PMIPv6
extensions so I could imagine that someone somewhere might get it
wrong.
The signaling messages {IPv6 with Mobility Header, or IPv4 UDP Port
5436) traffic is exchanged between MAG-CP and LMA-CP. There is no
implication on the use/non-use of other mobility options.
Sure. My question is: where is it written down which are signalling
messages and which are not?
PMIPv6 Signaling messages (aka control plane messages) are PBU/PBA,
BRI/BRA and UPN/UPA messages. The formats for these messages are
specified in RFC 5213, 5844, 5846, 5847, 7077.
The identification of any of these CP messages is the use of the
following selector.
1. Any IPv4-UDP packets with UDP port 5436 2. Any IPv6 packets with
Mobility Header messages
Existing specs clearly explain this and I think its sufficiently
clear for the implementors on what traffic goes to LMA-CP and what
goes to the LMA-UP.
Regards Sri
Ta, S.
The tunneled traffic with L3 encapsulation is between MAG-DP and
LMA-DP. Regards Sri
_______________________________________________ netext mailing list

--_000_D01D191715B2BFsgundaveciscocom_-- From nobody Fri Aug 22 16:10:59 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE0A1A070A; Fri, 22 Aug 2014 16:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 297La19uL_4l; Fri, 22 Aug 2014 16:10:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A14CC1A6F85; Fri, 22 Aug 2014 16:10:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EE9AFBE00; Sat, 23 Aug 2014 00:10:30 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k478bgpscxMP; Sat, 23 Aug 2014 00:10:28 +0100 (IST) Received: from [10.87.48.11] (unknown [86.46.28.247]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5C0A0BDFD; Sat, 23 Aug 2014 00:10:28 +0100 (IST) Message-ID: <53F7CDE4.6000800@cs.tcd.ie> Date: Sat, 23 Aug 2014 00:10:28 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Sri Gundavelli (sgundave)" , The IESG References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netext/pc0kMI6ICOB7IjYTt1zbgZWb64I Cc: "netext@ietf.org" , "netext-chairs@tools.ietf.org" , "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" Subject: Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 23:10:42 -0000 On 23/08/14 00:08, Sri Gundavelli (sgundave) wrote: > Hi Stephen, > > Thanks for the review. > > >> In this case, you're not even requiring implementation. > So if say, a MAG-UP were to talk to a LMA that is both > CP and UP, then the latter node would support IPsec for > UP, if so configured, but the MAG-UP might not even > implement IPsec. > >> Does that mean that you need to a a requirement here to > make IPsec MTI for the MAG-UP and LMA-UP, so that they > can interop with non-split MAGs and LMAs? > > > Requiring IPsec implementation on both the MAG-UP and LMA-UP nodes is a fair requirement. We can certainly state that. If an operator chooses to do so they can configures IPSec policy on LMA-UP and MAG-UP for PMIP tunnel traffic protection. This will keep the spec consistent with the base RFC5213. > > The signaling between LMA-CP and MAG-CP needs to be protected by IPsec and that is a mandatory requirement in RFC5213. No change there. This specification still requires IPsec protection for control plane traffic between MAG-CP and LMA-CP. > > We will draft some text to reflect this and post it for your review. Great thanks, S. > > > > Regards > Sri > > > > On 8/22/14 3:51 PM, "Stephen Farrell" > wrote: > > > Hiya, > > Sorry for the slow response... > > The indentation below is a bit messed up, I hope its clear > who's saying what. > > On 13/08/14 17:45, Sri Gundavelli (sgundave) wrote: > HI Stephen, > Please see inline. > On 8/13/14 5:21 AM, "Stephen Farrell" > > wrote: > Hiya, > A few follow ups... > On 09/08/14 17:54, Sri Gundavelli (sgundave) wrote: Hi Stephen, > Thanks for the review. Please see inline. On 8/7/14 5:50 AM, "Stephen > Farrell" > > wrote: > I have two questions. They could be easy or hard, I'm not sure:-) > Apologies in advance if I've forgotten what little I ever knew about > PMIPv6 and gotten stuff wrong here. Not at all. Thanks for the > discussion. > (1) PMIPv6 traffic between MAG and LMA is generally assumed to be > protected via IPsec, right? Assuming that's actually done, does > figure 1 here indicate a weakening of security since it shows that IP > encapsulation is used between MAG-UP and LMA-UP without any mention > of IPsec. Is that downgrading security? I get that the binding > messages are the most important and will presumably continue on the > control plane but what else changes? Yes. PMIPv6 allows the use of > IPsec security (Tunnel Mode ESP) protection > "allows"? Do you happen to know if that's really used or not in > practice? (That's not a DISCUSS point, but I do wonder.) > Security for user-plane traffic protection is used in very few > deployments. > > Ah. > > Taking the Service Provider Wi-Fi deployment as an > example, there is 802.1x security on the air interface, and then > there is typical end to end application security (even a Google > search is HTTPS protected). Now requiring security on the user plane > traffic between two points in the operator network (LMA and MAG) is > some what redundant, IMO. Use of IPsec for UP traffic protection is > optional per MIPv6/PMIPv6 specs. I'd say banking type > applications/deployments requires such multi-layer security. > > Hmm. I don't see that it makes any sense to assume IPsec is > done differently per-application. So I guess we ought assume > that IPsec isn't used for user traffic. > > Is it really used for control plane traffic do you know? > > But in a sense this spec is lowering the bar a little. > 5213 requires implementation of IPsec on the node that > carries the UP traffic, even if it doesn't require its > use. > > In this case, you're not even requiring implementation. > So if say, a MAG-UP were to talk to a LMA that is both > CP and UP, then the latter node would support IPsec for > UP, if so configured, but the MAG-UP might not even > implement IPsec. > > Does that mean that you need to a a requirement here to > make IPsec MTI for the MAG-UP and LMA-UP, so that they > can interop with non-split MAGs and LMAs? > > I'd assume that'd be easy enough and it'd clear up > that discuss point. > > for the user-plane traffic. This is optional and is based on > standard IPsec security. It requires no special interaction between > IPsec and the Proxy Mobile IPv6 entities. In the split mode (LMA ==> > LMA-CP & LMA-DP), > What's LMA-DP? That's not mentioned in the draft? I assume you mean > what the draft calls LMA-UP? (I.e. DP = data plane being the same as > UP = user plane?) > Apologies for the terminology mix up. Yes. LMA-DP (Data Plane) should > be the LMA-UP (User Plane) > the MAG (or MAG-DP) and the LMA-DP can optionally enable IPsec > security on the user-plane traffic. > Hmm. So you're saying IPsec can be on for the control plane and off > for the user plane independently? Is that a good plan? I guess it'd > be a bad plan if it were the other way around? > I'd say this is the approach in use for today's integrated LMA > (LMA-UP + LMA-CP) based deployments. IPsec security is enabled for CP > traffic by default, as it is mandated by PMIPv6 specs. However, the > IPsec security for UP is a optional requirement and most deployments > don't enable IPsec for UP traffic protection. > MAG-DP establishes a layer-3 p2p tunnel to LMA-DP and both these > peers can be configured to apply IPsec security on the tunneled > traffic. So, there is no loss of functionality here and the CP/DP > split approach is not resulting in weakened security. > Well, it might if IPsec is on for one and off for the other. > Or, if say MAG-CP and MAG-UP are from different vendors, then I don't > know how they signal to one another to turn on/off IPsec if what we > want is for IPsec to be on for both or off for both. > I'd look at IPsec as a security policy between two peers. Use of > IPsec for CP messages between two CP nodes (Ex: MAP-CP and LMA-CP) > should not have any bearing on the use/non-use of IPsec security > between two UP nodes (Ex: MAG-UP and LMA-UP). The security policy on > the two UP nodes strictly determine the use/non-use of IPsec for > tunnel traffic protection. But, if the hint is that this policy > should be controlled by the respective CP entity, I'd say yes, but > that CP to UP interface is out of scope for this work. The > controller/CP entity may have a provisioning interface to the UP > nodes and that interface may dictate this aspect, but has not > implication on this draft. > (2) How does the rest of the Internet know to use the LMA-UP for the > MN and not the LMA-CP? Sorry for being dense but I don't see how > packets from a random Internet node for the MN end up going down the > user plane. The IP address of the mobile node is topologically > anchored on the LMA-DP. > You mean LMA-UP there right? > Yes. Sorry for the terminology mix-up. >>From the point of view of Routing, the LMA-DP owns that larger IP > prefix > block from which it allocates to IP prefixes/address to individual > mobility sessions. The LMA-DP is in the path for the user-plane > traffic and is the entry point into the mobile network. However, the > LMA-CP is only terminating the control signaling from the MAG and is > not in the path for the user-plane traffic. > Is that written down somewhere? If say the LMA-UP and LMA-CP had > utterly different addresses then it couldn't work could it? > This was captured in Section 5.6.2 for IPv6 > http://tools.ietf.org/html/rfc5213#page-38 > Section 3.1.3 for IPv4 http://tools.ietf.org/html/rfc5844#page-15 > When we separate the functionality, the user plane (or the IP > address/prefixes allocated to the MN) must be anchored on the LMA-UP. > I think we missed capturing this in the spec. Thanks for pointing > this out. > OLD: > The LMA Control Plane and the LMA User Plane functions are typically > deployed on the same IP node and in such scenario the interface > between these functions is internal to the implementation. > Deployments may also choose to deploy the LMA Control Plane and the > LMA User Plane functions on seperate IP nodes. In such deployment > models, there needs to be a protocol interface between these two > functions and which is outside the scope of this document. Possible > options for such interface include OpenFlow [OpenFlow-Spec-v1.4.0 > ], > > FORCES [RFC5810 ], use of routing > infrastructure > [I-D.matsushima-stateless-uplane-vepc > ] > or vendor specific approaches. This specification does not mandate a > specific protocol interface and views this interface as a generic > interface relevant more broadly for many other protocol systems in > addition to Proxy Mobile IPv6. > NEW: > The LMA Control Plane and the LMA User Plane functions are typically > deployed on the same IP node and in such scenario the interface > between these functions is internal to the implementation. > Deployments may also choose to deploy the LMA Control Plane and the > LMA User Plane functions on seperate IP nodes. In such deployment > models, there needs to be a protocol interface between these two > functions and which is outside the scope of this document. Possible > options for such interface include OpenFlow [OpenFlow-Spec-v1.4.0 > ], > > FORCES [RFC5810 ], use of routing > infrastructure > [I-D.matsushima-stateless-uplane-vepc > ] > or vendor specific approaches. This specification does not mandate a > specific protocol interface and views this interface as a generic > interface relevant more broadly for many other protocol systems in > addition to Proxy Mobile IPv6. When the LMA Control Plane and the LMA > User Plane functions are deployed on separate IP nodes, the > requirement related to user-plane address anchoring specified in > Section 5.6.2 [RFC-5213] and Section 3.1.3 [RFC5844] must be met by > the node hosting the LMA user plane functionality. The LMA user > plane node must be topological anchor point for the IP > address/prefixes allocated to the mobile node. > > I'm not quite sure if that does sort out the issue or not, > but I'm willing to believe you and Brian if you're telling > me it does. > > So with that OLD/NEW and adding IPsec as MTI for the > *-UP nodes, I think we'd be done. > > Cheers, > S. > > ---------------------------------------------------------------------- > > COMMENT: > ---------------------------------------------------------------------- > > Did you need to say somewhere which PMIPv6 messages are to be sent in > the control plane and which in the user plane? That might be obvious > to some, but its not to me and I guess there are a bunch of PMIPv6 > extensions so I could imagine that someone somewhere might get it > wrong. > The signaling messages {IPv6 with Mobility Header, or IPv4 UDP Port > 5436) traffic is exchanged between MAG-CP and LMA-CP. There is no > implication on the use/non-use of other mobility options. > Sure. My question is: where is it written down which are signalling > messages and which are not? > PMIPv6 Signaling messages (aka control plane messages) are PBU/PBA, > BRI/BRA and UPN/UPA messages. The formats for these messages are > specified in RFC 5213, 5844, 5846, 5847, 7077. > Ex: http://tools.ietf.org/html/rfc5213#page-69 > http://tools.ietf.org/html/rfc6275#page-42 > The identification of any of these CP messages is the use of the > following selector. > 1. Any IPv4-UDP packets with UDP port 5436 2. Any IPv6 packets with > Mobility Header messages > Existing specs clearly explain this and I think its sufficiently > clear for the implementors on what traffic goes to LMA-CP and what > goes to the LMA-UP. > Regards Sri > Ta, S. > The tunneled traffic with L3 encapsulation is between MAG-DP and > LMA-DP. Regards Sri > _______________________________________________ netext mailing list > netext@ietf.org > https://www.ietf.org/mailman/listinfo/netext > > From nobody Tue Aug 26 22:47:50 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64EE1A03FE for ; Tue, 26 Aug 2014 22:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.869 X-Spam-Level: X-Spam-Status: No, score=-11.869 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULIUqUI2f5Da for ; Tue, 26 Aug 2014 22:47:42 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE3C81A03FA for ; Tue, 26 Aug 2014 22:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17316; q=dns/txt; s=iport; t=1409118463; x=1410328063; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=ey5cYuAZGgfsOahu9tfU6GCMTmAaWcd9jT+wkFqGUyA=; b=VdeRwi77Wehe26vSY8hU4pRoO1pHRW7fQt307UH02mEpqz7ieiE+Ud7T 4EGhIQVD6kAEfL3fTtUC3mxXueauaOBgAN7slPOWakImY0NorUI6Pljtq VlWMm0vaX8eHGkNIIdE5BqnrGTk7M5kP0XStHYd4efWXwC5zCCtKxtj2G s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAGtw/VOtJA2K/2dsb2JhbABbgw1TUwQEzFQMhndTAYEWFneEBAEBBAEBAWsEGQEIDgonLgsUEQIEARKIQggFv0YXiX+EaxEBHTqETAWGE4QehnyEK4Z8gViNCIY0g15sgQ85gQcBAQE X-IronPort-AV: E=Sophos;i="5.04,408,1406592000"; d="scan'208";a="350557685" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP; 27 Aug 2014 05:47:40 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s7R5lc05032409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Aug 2014 05:47:38 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.223]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0195.001; Wed, 27 Aug 2014 00:47:38 -0500 From: "Sri Gundavelli (sgundave)" To: Daniel Corujo , "netext@ietf.org" Thread-Topic: [netext] Logical Interface draft Thread-Index: AQHPwbpoarg5c9pgAk6QfqRZdY1N3A== Date: Wed, 27 Aug 2014 05:47:38 +0000 Message-ID: In-Reply-To: <15FF7213-1157-4109-BBFD-5DBCE84E4690@av.it.pt> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.213] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/xoLlimt5wLfkzsdqhqWQ7qKSiRE Subject: Re: [netext] Logical Interface draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 05:47:48 -0000 Hi Daniel, Apologies for the delay in responding to this thread. Thanks for the detailed review feedback. We will review and respond to these comments. Regards Sri Thanks a lot=20 On 8/21/14 2:01 AM, "Daniel Corujo" wrote: >Dear all, > >Please kindly accept my review on this draft. > >Overall, I think that it provides a very useful initial description for >the topic, but, IMHO, it is really demanding for some added details. >Please consider: > >1 - The document focuses on PMIPv6. Although it is currently the de-facto >mobility management protocol, there are currently other efforts underway, >particularly DMM. I am sure that there are a lot of people who would be >interested in analysing the impact that the logical interface would have >in such architectures (or be impacted by them). As such, not only a >specific section addressing other mobility management schemes, but >actually shifting PMIPv6 to a specific scenario within this draft, rather >than than its focus, would allow the draft to be more informatively broad >and future-proof. > >2 - In section 3.2.1 it is indicated that =B3the handover across access >points need not to be hidden to the IP layer since the IP layer >configuration remains the same after a handover=B2. However, IP >configuration steps are still triggered, such as sending out Router >Solicitations and collecting Router Advertisements, in the case of IPv6 >Stateless Autoconfiguration. This will impact the terminal, even in >intra-technology handovers. > >3 - Point 2) in this email also raises an issue which should be >interesting to cover in this draft. One can consider that the identified >interface to realize PMIPv6 proceedings would be the Logical Interface. >However, in a handover situation, how would the mechanism chose through >which physical sub-interface the Router Solicitation would be sent? Each >sub-interface has a different MAC address and, in the case of IPv6 >Stateless Autoconfiguration, the requested suffix would be different. I >might be missing something, so please correct me if I am wrong. >Nonetheless, this also hints that the scenarios shown in sections 6.1 and >6.2 could use a little bit of more information and detail. > >4 - Also in section 3.2.1, in the 2nd paragraph, regarding =B3the logical >interface would not be used to provide simultaneous access for purposes >of multihoming or flow mobility=B2: would it be interesting to consider >load balancing or reliability aspects, considering a Single IP Address / >Multiple physical interfaces case? > >5 - I think that section 4, which is called =B3Technology Use Cases=B2 sho= uld >be enhanced with more examples. Basically all the examples indicated in >this section have been hinted in text here and there in the previous >sections, so it does not explicitly add nothing new. > >6 - In section 5, regarding the 1st property of the logical interface, it >would be interesting to add a bit more information on how its >relationship with the set of physical interfaces is done. Is it just the >LIF and FLOW tables? > >7 - In section 5.1, regarding the =B3logical router that in turns decides >which physical interface is to be used to transmit packets=B2, seems to me >to be very interesting and could be further extended to encompass >rule-based configuration. For example, besides the usual =B3default=B2 rul= e, >a sequential list, just to name an example. > >8 - In section 5.2, the PIF table is mentioned, but Figure 2 addresses >the LIF table and FLOW table. > >9 - In section 5.2, is it possible to add indication on how the tables >can handle several LIF=B9s? Or each LIF has its own set of tables? If so, >whenever packets are received, does the =B3Connection Manager=B2 need to >check each table from each LIF, as per =B3In case traffic of an existing >flow is suddenly received from the network on a different sub-interface >than the one locally stored, the logical interface should interprete the >event as an explicit flow mobility trigger from the network (=8A)=B2. Seem= s >to me that this would cause some performance issues=8A > >10 - In Sections 6.1 and 6.2, as indicated before, more details should be >given about each procedure. For example, beyond the LMA=B9s Binding Table, >it would be interesting to see the dynamics of the LIF and FLOW tables >before and after the handover. This is important to evaluate the >behaviour aspects of the LIF in particular situations as well, such as >handovering a flow to an interface that has been connected for sometime. > >11 - The remainder of my comments are just editorial: > - Abstract, line8, should be =B3 (=8A) details of THE logical interface (= =8A) >=B3. > - Page 3, 3rd paragraph, line 1, there is no need for =B3network=B2 befor= e >=B3network-based=B2. > - Page 3, 3rd paragraph, line 4, suggestion of replacing =B3afford=B2 wit= h >=B3allow=B2 > - Page 5, 1st paragraph, line 2, should be =B3 (=8A) or movement from THE >host IP layer.=B2 > - Page 5, Section 3.1, 2nd bullet, line 1, should be =B3 (=8A) that >logically groupS/bondS (=8A) =B3 > - Page 8, Section 4, 1st paragraph, line 4, it it really =B3available >devices=B2 or should it be =B3available accesses=B2 or =B3available interf= aces=B2? > - Page 8, Section 4, 3rd paragraph, line 1, should be =B3 (=8A) setup is >based on THE creation (=8A) =B3 > - Page 10, Section 5.1, 2nd paragraph, line 3, should be =B3 (=8A) that i= n >turn decides (=8A) =B3 > - Page 10, Section 5.2, 1st paragraph, missing =B3.=B2 after =B3Figure 2= =B2. > >Hope these comments support the draft. Any comments on suggestions are >welcome! > >Best regards, > > >Daniel Corujo, Ph.D., Research Fellow >Universidade de Aveiro, Portugal=09 >http://re.vu/dcorujo >Advanced Telecommunications and Networks Group - http://atnog.av.it.pt >Follow us - @ATNoG_ITAv > > >On 08 Aug 2014, at 12:07 , pierrick.seite@orange.com wrote: > >> Hi, >> =20 >> I=B9ve reviewed=20 >>http://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface-suppo >>rt/and I have no particular issue to raise, just few editorial >>suggestions (please see below). So, I agree with Danny; this doc is >>useful and ready for publication. >> =20 >> BR, Pierrick >> =20 >> =20 >> --- OLD ABSTRACT ------------- >> A Logical Interface is a software semantic internal to the host >> operating system. This semantic is available in all popular >> operating systems and is used in various protocol implementations. >> The Logical Interface support is required on the mobile node >> operating in a Proxy Mobile IPv6 domain, for leveraging various >> network-based mobility management features such as inter-technology >> handoffs, multihoming and flow mobility support. This document >> explains the operational details of Logical Interface construct and >> the specifics on how the link-layer implementations hide the physical >> interfaces from the IP stack and from the network nodes on the >> attached access networks. Furthermore, this document identifies the >> applicability of this approach to various link-layer technologies and >> analyzes the issues around it when used in context with various >> mobility management features. >> =20 >> =20 >> ------------- NEW ABSTRACT ------------- >> =20 >> A Logical Interface is a software semantic internal to the host >> operating system. This semantic is available in all popular >> operating systems and, when the terminal is equipped with more than >>one interface, it can be used to hide the physical interfaces from the >>IP stack. The logical interface thus allows various >> network-based mobility management features such as inter-technology >> handoffs, multihoming and flow mobility support. This document >> explains how the Logical Interface hides the physical >> interfaces from the IP stack and from the network nodes on the >> attached access networks. Furthermore, this document identifies the >> applicability of this approach to various link-layer technologies and >> analyzes the issues around it when used in context with various >> mobility management features. >> =20 >> =20 >> - Old text ----------- >> =20 >> Specifically, it explores the use of the Logical Interface support, a >> semantic available on most operating systems. >> =20 >> =20 >> - New text ---------- >> Specifically, it explores the use of the Logical Interface support, >>available on most operating systems. >> =20 >> =20 >> =20 >> Section 3.1: >> =20 >> =AB an 802.11 STA =BB - please expand STA >> =20 >> s/ within the same domain/ within the same IP subnet/ >> =20 >> s/ the IEEE 802.11 MAC layer takes care of the mobility/ the IEEE >>802.11 MAC layer handles mobility between access points >> =20 >> s/ A logical interface denotes a mechanism that that logically >>group/bond several/ A logical interface denotes a mechanism that >>logically group several >> =20 >> --------- OLD text ---------- >> =20 >> Depending on the type of >> access technologies, it might be possible to use more than one >> physical interface at a time -- such that the node is >> simultaneously attached via different access technologies -- or >> just to perform handovers across a variety of physical interfaces. >> . >> =20 >> Not: It does not depent on the access technology but on the OS and the >>terminal implementation, so I suggest: >> =20 >> ----------- NEW text ---------- >> =20 >> Depending on the system, it might be possible to use more than one >> physical interface at a time -- such that the node is >> simultaneously attached via different access technologies -- or >> just to perform handovers across a variety of physical interfaces. >> =20 >> =20 >> =20 >> ------ OLD text --------- >> =20 >> The configuration is typically >> handled via a connection manager, and based on a combination of >> user preferences on one hand, and operator preferences such as >> those provisionned by the Access Network Discovery and Selection >> Function (ANDSF) [TS23402] on the other hand. >> =20 >> =20 >> -------- NEW text -------- >> =20 >> The configuration is typically >> handled via a connection manager, and based on a combination of >> user preferences, application characteristics, quality of >>communications, operator preferences (e.g. provisioned by the Access >>Network Discovery and Selection Function (ANDSF) [TS23402]), and so on. >> =20 >> =20 >> S/3.2.1 link layer support/link layer mobility support/ >> =20 >> s/ in the same subnet with a common IP layer configuration (DHCP >>server, default router, etc.)/ in the same IP subnet with a common >>configuration objects (DHCP server, default gateway, etc.) >> =20 >> s/ In this case the handover across access points need not to be >>hidden/ In this case the handover across access points does not need to >>be hidden =20 >> =20 >> =20 >> =20 >> Last paragraph of 3.2.1 should be removed since the use-case is covered >>by 3.2.2. Or rewrite as: >> =20 >> -+-------- OLD TEXT --------- >> Since this type of link layer technology does not typically allow for >> simultaneous attachment to different access networks of the same >> technology, the logical interface would not be used to provide >> simultaneous access for purposes of multihoming or flow mobility. >> =20 >> Note: actually, there is no multihoming or flow mobility since there is >>no more than one simultaneous attachment ;-) >> =20 >> Instead, the logical interface can be used to provide inter-access >> technology handover between this type of link layer technology and >> another link layer technology, e.g., between IEEE 802.11 and IEEE >> 802.16. >> =20 >> Note: this covered in the following section section =8A this is the >>motivation of the logical interface=8A. >> =20 >> - NEW TEXT ---------- >> =20 >> When the access technology does not allow a single interface to be >>simultaneous attach to more than one IP network (subnet and associated >>configuration objects), logical interface support is not required. >> =20 >> -------- OLD TEXT --------- >> =20 >> Doing so allows to hide inter-access >> technology handovers or application flow handovers across different >> physical interfaces. >> =20 >> --- NEW TEXT ------------ >> =20 >> Doing so allows to hide inter-access >> technology handovers, or application flow handovers across different >> physical interfaces, from the IP stack which is by nature tight to a >>single interface. >> =20 >> -----------Question --------------- >> =20 >> =20 >> Section 4 states: >> =20 >> In some UE implementations the wireless connection setup is based on >> creation of a PPP interface between the IP layer and the wireless >> modem that is configured with the IPCP and IPv6CP protocol [RFC5072]. >> In this case the PPP interface does not have any L2 address assigned. >> In some other implementations the wireless modem is presented to the >> IP layer as a virtual Ethernet interface. >> =20 >> =20 >> So what? What do you want to stress here? >> - - - - ---- >> =20 >> =20 >> Section 5: >> =20 >> What do you mean by =B3The sub-interfaces attached to a Logical >>interface are not visible to the IP and upper layers.=B2 >> The node can use either the logical or physical interfaces, I mean, an >>application can be bound to the LI and another application bound to one >>of the physical interface available. >> =20 >> =20 >> =20 >> =20 >> Section 5.1: >> =20 >> The IP layer should be configured with a default router reachable via >>the logical interface. >> =20 >> The IP layer should be also configured with DNS, DHCP server. Right? >> =20 >> Section 5.2: >> =20 >> In Fig.2 ::flow table : >> =20 >> s/ Physical_Intf_Id/PIF_ID >> =20 >> on section n 6.3: maybe add a reference to the draft netext-flow-mob? >> =20 >> =20 >> General comment: In the doc, we find either =AB Logical Interface =BB, o= r =AB >>logical interface =BB, or =AB Logical interface =BB=8A. Would be better t= o pick >>only one of these terms=8A. >> =20 >> =20 >> De : netext [mailto:netext-bounces@ietf.org] De la part de Moses, Danny >> Envoy=E9 : jeudi 7 ao=FBt 2014 17:44 >> =C0 : netext@ietf.org >> Objet : [netext] Logical Interface draft >> =20 >> Hi, >> =20 >> In the last meeting there was a discussion about whether or not to >>publish the 'Logical Interface' draft >>(http://datatracker.ietf.org/doc/draft-ietf-netext-logical-interface-supp >>ort/). At the end of the discussion it was agreed that if at least three >>new reviewers review the draft and state that it is useful, the WG will >>publish it. >> =20 >> Well, I reviewed it (and it was the first time for me to read it) and >>found the draft to be useful as a guide for OS developers (and/or >>network stack developers) who wish to implement a logical interface for >>supporting PMIPv6. >> =20 >> I found the draft to be clear, short and useful and recommend to >>publish it. I found a few minor typos that should be corrected and sent >>my comments to Sri. >> =20 >> Regards, >> /Danny >> =20 >> =20 >> --------------------------------------------------------------------- >> A member of the Intel Corporation group of companies >>=20 >> This e-mail and any attachments may contain confidential material for >> the sole use of the intended recipient(s). Any review or distribution >> by others is strictly prohibited. If you are not the intended >> recipient, please contact the sender and delete all copies. >>=20 >>=20 >>_________________________________________________________________________ >>________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations >>confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme >>ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or privileged >>information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >>delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >>been modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > >_______________________________________________ >netext mailing list >netext@ietf.org >https://www.ietf.org/mailman/listinfo/netext From nobody Tue Aug 26 22:49:37 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B33B71A03FE for ; Tue, 26 Aug 2014 22:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sz0IS2r3IcvL for ; Tue, 26 Aug 2014 22:49:33 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151951A03FA for ; Tue, 26 Aug 2014 22:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5755; q=dns/txt; s=iport; t=1409118573; x=1410328173; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=Mo0qODDLNFpf0/0hp/UUDsQ5Or+lQ3dtr4w34aZ7lp0=; b=SpJxfHMCHGp28Ueg5WBC3DotVE7i+GJIKYOv2JO+mFUH5o3sNdG3V0ct AE0ohr2xhu1ITawU457fBER6A7a7edcGHo+ZYPpv5BY2Vafcu9GnLtJd0 4LjPP00DpxUtPtrfnZ7QbIsJLJKQOEoTnQYvuH3XoWZTczYhfbBuZ7lRy 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsFACtw/VOtJA2J/2dsb2JhbABbgkdGU1cEsliYIoFmh0oBgRYWd4QDAQIELV4BCBEDAQIoORQJCAIEARKIQg2/RRePFRMTGIRMBYYThB6GfIQrhnyBWJM8g15sgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,408,1406592000"; d="scan'208,217";a="350554211" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP; 27 Aug 2014 05:49:32 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s7R5nW9O012063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Aug 2014 05:49:32 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.223]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Wed, 27 Aug 2014 00:49:32 -0500 From: "Sri Gundavelli (sgundave)" To: "Moses, Danny" , "netext@ietf.org" Thread-Topic: [netext] Logical Interface draft Thread-Index: AQHPwbqsXWp/E8dnukSelTJgSexszw== Date: Wed, 27 Aug 2014 05:49:31 +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.3.120616 x-originating-ip: [10.32.246.213] Content-Type: multipart/alternative; boundary="_000_D022BF1A15B84Fsgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/7hZ8k-Ta3RSZnYPTDj0lgVAxg2I Subject: Re: [netext] Logical Interface draft X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 05:49:34 -0000 --_000_D022BF1A15B84Fsgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Danny/Pierrick, Thanks for the reviews. We will address your comments. Regards Sri From: , Danny > Date: Thursday, August 7, 2014 8:43 AM To: "netext@ietf.org" > Subject: [netext] Logical Interface draft Hi, In the last meeting there was a discussion about whether or not to publish = the 'Logical Interface' draft (http://datatracker.ietf.org/doc/draft-ietf-n= etext-logical-interface-support/). At the end of the discussion it was agre= ed that if at least three new reviewers review the draft and state that it = is useful, the WG will publish it. Well, I reviewed it (and it was the first time for me to read it) and found= the draft to be useful as a guide for OS developers (and/or network stack = developers) who wish to implement a logical interface for supporting PMIPv6= . I found the draft to be clear, short and useful and recommend to publish it= . I found a few minor typos that should be corrected and sent my comments = to Sri. Regards, /Danny --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_D022BF1A15B84Fsgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <1D899F87926E6C4FBADC08E028037086@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Danny/Pierrick,

Thanks  for the reviews. We will address your comments.



Regards
Sri


From: <Moses>, Danny <danny.moses@intel.com>
Date: Thursday, August 7, 2014 8:43= AM
To: "netext@ietf.org" <= netext@ietf.org>
Subject: [netext] Logical Interface= draft

Hi,
 
In the last meeting there was a discussion about whether or not to pub= lish the 'Logical Interface' draft (http://datatracker.ietf.org/doc= /draft-ietf-netext-logical-interface-support/)= . At the en= d of the discussion it was agreed that if at least three new reviewers revi= ew the draft and state that it is useful, the WG will publish it.
 
Well, I reviewed it= (and it was the first time for me to read it) and found the draft to be us= eful as a guide for OS developers (and/or network stack developers) who wis= h to implement a logical interface for supporting PMIPv6.
 
I found the draft t= o be clear, short and useful and recommend to publish it. I found a few min= or typos that should be corrected  and sent my comments to Sri.=
 
Regards,
   &= nbsp;    /Danny
 
 

--------------------------------------------------------------------- A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

 --_000_D022BF1A15B84Fsgundaveciscocom_-- From nobody Wed Aug 27 07:27:16 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A09D1A06E3 for ; Wed, 27 Aug 2014 07:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YZ3gK45-VHZ for ; Wed, 27 Aug 2014 07:27:13 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FF621A0655 for ; Wed, 27 Aug 2014 07:27:13 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id i7so219971oag.4 for ; Wed, 27 Aug 2014 07:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=n9JiOF/moEV3Ur5bx46WPgABoVHXL2cP+i+p3jpP7pA=; b=m9Cb8vFeJkoL+yraUUe+qZsCNh3cCIYlCVlYvo9TzinbLsFvxUXxeycm4qnqx2F/lO hZhDMxoIzPgFQWFFf19OFp6TDAuetApA4Q6f7b3rIzmN62UQ4nD70R+1p6hetBWtZG3f gLAcNfN+81PWCKNDPkU35QYDBkgDIP3OQiKSrVEezUi6qL4Rp5PrWntS51/DTrWQOxzL hgIa0YpwNhF4u+Bbs0DrhMXpmkJv7b52xOSTntveW14Au4gnR1FfxTBO/RF0rRTttunM CEkCckzpqyIF002/sc7ptEl9koc43lBwxNK6ZtCcxVBoL1wbA96qBSSgjycks8ht99mp sbjw== MIME-Version: 1.0 X-Received: by 10.60.73.10 with SMTP id h10mr2812806oev.2.1409149632881; Wed, 27 Aug 2014 07:27:12 -0700 (PDT) Received: by 10.182.74.1 with HTTP; Wed, 27 Aug 2014 07:27:12 -0700 (PDT) Date: Wed, 27 Aug 2014 10:27:12 -0400 Message-ID: From: Basavaraj Patil To: "netext@ietf.org" Content-Type: multipart/alternative; boundary=001a1134b49a4dabb505019d37ba Archived-At: http://mailarchive.ietf.org/arch/msg/netext/6QCgl9FNZn0-lhachdw4gLaNRNI Cc: draft-ietf-netext-logical-interface-support-09@tools.ietf.org Subject: [netext] WGLC: I-D draft-ietf-netext-logical-interface-support-09 X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 14:27:14 -0000 --001a1134b49a4dabb505019d37ba Content-Type: text/plain; charset=UTF-8 Hello, The WG I-D: Logical Interface Support for multi-mode IP Hosts is ready for working group last call. This I-D is intended to be published as an Informational RFC. Please treat this email as the start of the WGLC for this I-D. The WGLC will end on Sept 15th, 2014. Please send your review comments to the WG mailing list or the authors directly. -Chairs -- Basavaraj Patil --001a1134b49a4dabb505019d37ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello,

The WG= I-D: Logical Interface Support for multi-mode IP Hosts
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <draft-ietf-netext-logical-interface-= support-09>
is ready for working group last call.

This I-D is intended to be published as an Informationa= l RFC.

Please treat this email as the start of the= WGLC for this I-D.=C2=A0
The WGLC will end on Sept 15th, 2014. P= lease send your review comments to the WG mailing list or the authors direc= tly.

-Chairs

--
Basavaraj Patil
--001a1134b49a4dabb505019d37ba-- From nobody Wed Aug 27 14:47:55 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC491A0051; Wed, 27 Aug 2014 14:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fn9MjMrV8ILH; Wed, 27 Aug 2014 14:47:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D56C1A0022; Wed, 27 Aug 2014 14:47:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140827214751.10521.98724.idtracker@ietfa.amsl.com> Date: Wed, 27 Aug 2014 14:47:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/dmS0VRhqeOtr1yB99pfHluSoY3A Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-ani-location-02.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 21:47:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Extensions to the PMIPv6 Access Network Identifier Option Authors : Rajesh S. Pazhyannur Sebastian Speicher Sri Gundavelli Jouni Korhonen John Kaippallimalil Filename : draft-ietf-netext-ani-location-02.txt Pages : 11 Date : 2014-08-27 Abstract: Access Network Identifier (ANI) Mobility option was introduced in [RFC6757] enabling a MAG to convey identifiers like network identifier, geolocation, and operator identifier. This specification extends the Access Network Identifier mobility option with sub- options to carry civic location and MAG group Identifier. This specification also defines a ANI Update timer sub-option that determines when and how often the ANI will be updated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-ani-location/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-ani-location-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-ani-location-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 27 18:04:14 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA4C1A03C5; Wed, 27 Aug 2014 18:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.168 X-Spam-Level: X-Spam-Status: No, score=-15.168 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhZKjHo0jyXJ; Wed, 27 Aug 2014 18:03:59 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041B01A0328; Wed, 27 Aug 2014 18:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42843; q=dns/txt; s=iport; t=1409187839; x=1410397439; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=DCzt9kFVyGZ/0+QHSn5DpL2XGgVlQIk4QYzHJjs1yL4=; b=ZfwAh3SRrGfC4UIE1qWxPTFjEi5klv6hh6JOhoClEeLbR7xSoWK9dWAu bmPiLbIRDNR+CVKnjj4+wiOpN15VrkAxGbrPaIt6LsG6sKa8nCjLm1Dye 5C72vnCmrOz3xw95c5TxXaiiFShbaj4wiAHOp7Cv8tMK5z49ZmhDoSCbq 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQNAFR//lOtJV2a/2dsb2JhbABFFoJHRlNXBIQUxiuBWwENhnhTAYEUFneEBAEBBAEBARcBTAcLEgEIOAECBC4LFBECBAENBYhCDb9VF4wdgkZlBAYBhEwFhQQCgQwBiQiCFIQthnyBW4o6gh+GZoIYgUZsAQEBAYFEgQcBAQE X-IronPort-AV: E=Sophos; i="5.04,414,1406592000"; d="scan'208,217"; a="72999097" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-8.cisco.com with ESMTP; 28 Aug 2014 01:03:57 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s7S13vfR032207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 01:03:57 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.223]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Wed, 27 Aug 2014 20:03:57 -0500 From: "Sri Gundavelli (sgundave)" To: Stephen Farrell , The IESG Thread-Topic: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT) Thread-Index: AQHPwlvx+OeeHus8aEmDnP3e/n1ViA== Date: Thu, 28 Aug 2014 01:03:56 +0000 Message-ID: In-Reply-To: <53F7CDE4.6000800@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.213] Content-Type: multipart/alternative; boundary="_000_D023CBF315BFFFsgundaveciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/h-hTSEEFX_egvJ6GErUbsq_P0xo Cc: "netext@ietf.org" , "netext-chairs@tools.ietf.org" , "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" Subject: Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 01:04:05 -0000 --_000_D023CBF315BFFFsgundaveciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stephen, Please see the below text on security considerations for CP and UP traffic = protection. On thinking about this further, I have a feeling we are adding = a additional requirement here on User-Plane node on IPsec implementation. The base line text in RFC 5213 requires IPSec as mandatory-to-implment mech= anism. However, it does not require the same for user -plane traffic protec= tion. But, one can argue that IPSec was implemented for CP traffic protecti= on and therefore implementation on that UP (UP-CP combo) node already exist= ed. I cannot beat that argument, but that was not surely the original inten= t in RFC5213. Any ways, I'm fine having IPsec as a mandatory-to-implement o= n both CP and UP nodes. Please see the below text. NEW: The Proxy Mobile IPv6 specification [RFC5213] requires the signaling messag= es between the MAG and the LMA to be protected using end-to-end security as= sociation(s) offering integrity and data origin authentication. The base sp= ecification also requires IPsec a mandatory-to-implement security mechanism= . In deployments where the Control and User Plane functions on the MAG and LM= A are separated and hosted on different IP nodes, the nodes hosting those r= espective Control Plane functions have to still meet the above the security= requirement. The Proxy Mobile IPv6 signaling messages exchanged between th= ese entities MUST be protected using end-to-end security association(s) off= ering integrity and data origin authentication. Furthermore, IPsec is a man= datory-to-implement security mechanism for the nodes hosting the Control Pl= ane function of the MAG and LMA. Additional documents may specify alternati= ve mechanisms and the mobility entities can enable a specific mechanism for= securing Proxy Mobile IPv6 signaling messages, based on either a static co= nfiguration or after a dynamic negotiation using any standard security nego= tiation protocols. As per the Proxy Mobile IPv6 specification, the use of IPsec for protecting= the mobile node's user plane traffic is optional. This specification exten= ds the same requirement and therefore requires the nodes hosting the User P= lane functions of the MAG and the LMA to have IPsec as a mandatory-to-imple= ment security mechanism, but make the use of IPsec as optional for User Pla= ne traffic protection. Text in RFC5213: The signaling messages, Proxy Binding Update, and Proxy Binding Acknowledgement, exchanged between the mobile access gateway and the local mobility anchor, MUST be protected using end-to-end security association(s) offering integrity and data origin authentication. The mobile access gateway and the local mobility anchor MUST implement IPsec for protecting the Proxy Mobile IPv6 signaling messages [RFC4301]. IPsec is a mandatory-to-implement security mechanism. However, additional documents may specify alternative mechanisms and the mobility entities can enable a specific mechanism for securing Proxy Mobile IPv6 signaling messages, based on either a static configuration or after a dynamic negotiation using any standard security negotiation protocols. As in Mobile IPv6 [RFC3775], the use of IPsec for protecting a mobile node's data traffic is optional. Regards Sri On 8/22/14 4:10 PM, "Stephen Farrell" > wrote: On 23/08/14 00:08, Sri Gundavelli (sgundave) wrote: Hi Stephen, Thanks for the review. In this case, you're not even requiring implementation. So if say, a MAG-UP were to talk to a LMA that is both CP and UP, then the latter node would support IPsec for UP, if so configured, but the MAG-UP might not even implement IPsec. Does that mean that you need to a a requirement here to make IPsec MTI for the MAG-UP and LMA-UP, so that they can interop with non-split MAGs and LMAs? Requiring IPsec implementation on both the MAG-UP and LMA-UP nodes is a fai= r requirement. We can certainly state that. If an operator chooses to do so= they can configures IPSec policy on LMA-UP and MAG-UP for PMIP tunnel traf= fic protection. This will keep the spec consistent with the base RFC5213. The signaling between LMA-CP and MAG-CP needs to be protected by IPsec and= that is a mandatory requirement in RFC5213. No change there. This specific= ation still requires IPsec protection for control plane traffic between MAG= -CP and LMA-CP. We will draft some text to reflect this and post it for your review. Great thanks, S. Regards Sri On 8/22/14 3:51 PM, "Stephen Farrell" > wrote: Hiya, Sorry for the slow response... The indentation below is a bit messed up, I hope its clear who's saying what. On 13/08/14 17:45, Sri Gundavelli (sgundave) wrote: HI Stephen, Please see inline. On 8/13/14 5:21 AM, "Stephen Farrell" > wrote: Hiya, A few follow ups... On 09/08/14 17:54, Sri Gundavelli (sgundave) wrote: Hi Stephen, Thanks for the review. Please see inline. On 8/7/14 5:50 AM, "Stephen Farrell" > wrote: I have two questions. They could be easy or hard, I'm not sure:-) Apologies in advance if I've forgotten what little I ever knew about PMIPv6 and gotten stuff wrong here. Not at all. Thanks for the discussion. (1) PMIPv6 traffic between MAG and LMA is generally assumed to be protected via IPsec, right? Assuming that's actually done, does figure 1 here indicate a weakening of security since it shows that IP encapsulation is used between MAG-UP and LMA-UP without any mention of IPsec. Is that downgrading security? I get that the binding messages are the most important and will presumably continue on the control plane but what else changes? Yes. PMIPv6 allows the use of IPsec security (Tunnel Mode ESP) protection "allows"? Do you happen to know if that's really used or not in practice? (That's not a DISCUSS point, but I do wonder.) Security for user-plane traffic protection is used in very few deployments. Ah. Taking the Service Provider Wi-Fi deployment as an example, there is 802.1x security on the air interface, and then there is typical end to end application security (even a Google search is HTTPS protected). Now requiring security on the user plane traffic between two points in the operator network (LMA and MAG) is some what redundant, IMO. Use of IPsec for UP traffic protection is optional per MIPv6/PMIPv6 specs. I'd say banking type applications/deployments requires such multi-layer security. Hmm. I don't see that it makes any sense to assume IPsec is done differently per-application. So I guess we ought assume that IPsec isn't used for user traffic. Is it really used for control plane traffic do you know? But in a sense this spec is lowering the bar a little. 5213 requires implementation of IPsec on the node that carries the UP traffic, even if it doesn't require its use. In this case, you're not even requiring implementation. So if say, a MAG-UP were to talk to a LMA that is both CP and UP, then the latter node would support IPsec for UP, if so configured, but the MAG-UP might not even implement IPsec. Does that mean that you need to a a requirement here to make IPsec MTI for the MAG-UP and LMA-UP, so that they can interop with non-split MAGs and LMAs? I'd assume that'd be easy enough and it'd clear up that discuss point. for the user-plane traffic. This is optional and is based on standard IPsec security. It requires no special interaction between IPsec and the Proxy Mobile IPv6 entities. In the split mode (LMA =3D=3D> LMA-CP & LMA-DP), What's LMA-DP? That's not mentioned in the draft? I assume you mean what the draft calls LMA-UP? (I.e. DP =3D data plane being the same as UP =3D user plane?) Apologies for the terminology mix up. Yes. LMA-DP (Data Plane) should be the LMA-UP (User Plane) the MAG (or MAG-DP) and the LMA-DP can optionally enable IPsec security on the user-plane traffic. Hmm. So you're saying IPsec can be on for the control plane and off for the user plane independently? Is that a good plan? I guess it'd be a bad plan if it were the other way around? I'd say this is the approach in use for today's integrated LMA (LMA-UP + LMA-CP) based deployments. IPsec security is enabled for CP traffic by default, as it is mandated by PMIPv6 specs. However, the IPsec security for UP is a optional requirement and most deployments don't enable IPsec for UP traffic protection. MAG-DP establishes a layer-3 p2p tunnel to LMA-DP and both these peers can be configured to apply IPsec security on the tunneled traffic. So, there is no loss of functionality here and the CP/DP split approach is not resulting in weakened security. Well, it might if IPsec is on for one and off for the other. Or, if say MAG-CP and MAG-UP are from different vendors, then I don't know how they signal to one another to turn on/off IPsec if what we want is for IPsec to be on for both or off for both. I'd look at IPsec as a security policy between two peers. Use of IPsec for CP messages between two CP nodes (Ex: MAP-CP and LMA-CP) should not have any bearing on the use/non-use of IPsec security between two UP nodes (Ex: MAG-UP and LMA-UP). The security policy on the two UP nodes strictly determine the use/non-use of IPsec for tunnel traffic protection. But, if the hint is that this policy should be controlled by the respective CP entity, I'd say yes, but that CP to UP interface is out of scope for this work. The controller/CP entity may have a provisioning interface to the UP nodes and that interface may dictate this aspect, but has not implication on this draft. (2) How does the rest of the Internet know to use the LMA-UP for the MN and not the LMA-CP? Sorry for being dense but I don't see how packets from a random Internet node for the MN end up going down the user plane. The IP address of the mobile node is topologically anchored on the LMA-DP. You mean LMA-UP there right? Yes. Sorry for the terminology mix-up. >From the point of view of Routing, the LMA-DP owns that larger IP prefix block from which it allocates to IP prefixes/address to individual mobility sessions. The LMA-DP is in the path for the user-plane traffic and is the entry point into the mobile network. However, the LMA-CP is only terminating the control signaling from the MAG and is not in the path for the user-plane traffic. Is that written down somewhere? If say the LMA-UP and LMA-CP had utterly different addresses then it couldn't work could it? This was captured in Section 5.6.2 for IPv6 http://tools.ietf.org/html/rfc5213#page-38 Section 3.1.3 for IPv4 http://tools.ietf.org/html/rfc5844#page-15 When we separate the functionality, the user plane (or the IP address/prefixes allocated to the MN) must be anchored on the LMA-UP. I think we missed capturing this in the spec. Thanks for pointing this out. OLD: The LMA Control Plane and the LMA User Plane functions are typically deployed on the same IP node and in such scenario the interface between these functions is internal to the implementation. Deployments may also choose to deploy the LMA Control Plane and the LMA User Plane functions on seperate IP nodes. In such deployment models, there needs to be a protocol interface between these two functions and which is outside the scope of this document. Possible options for such interface include OpenFlow [OpenFlow-Spec-v1.4.0 ], FORCES [RFC5810 ], use of routing infrastructure [I-D.matsushima-stateless-uplane-vepc ] or vendor specific approaches. This specification does not mandate a specific protocol interface and views this interface as a generic interface relevant more broadly for many other protocol systems in addition to Proxy Mobile IPv6. NEW: The LMA Control Plane and the LMA User Plane functions are typically deployed on the same IP node and in such scenario the interface between these functions is internal to the implementation. Deployments may also choose to deploy the LMA Control Plane and the LMA User Plane functions on seperate IP nodes. In such deployment models, there needs to be a protocol interface between these two functions and which is outside the scope of this document. Possible options for such interface include OpenFlow [OpenFlow-Spec-v1.4.0 ], FORCES [RFC5810 ], use of routing infrastructure [I-D.matsushima-stateless-uplane-vepc ] or vendor specific approaches. This specification does not mandate a specific protocol interface and views this interface as a generic interface relevant more broadly for many other protocol systems in addition to Proxy Mobile IPv6. When the LMA Control Plane and the LMA User Plane functions are deployed on separate IP nodes, the requirement related to user-plane address anchoring specified in Section 5.6.2 [RFC-5213] and Section 3.1.3 [RFC5844] must be met by the node hosting the LMA user plane functionality. The LMA user plane node must be topological anchor point for the IP address/prefixes allocated to the mobile node. I'm not quite sure if that does sort out the issue or not, but I'm willing to believe you and Brian if you're telling me it does. So with that OLD/NEW and adding IPsec as MTI for the *-UP nodes, I think we'd be done. Cheers, S. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Did you need to say somewhere which PMIPv6 messages are to be sent in the control plane and which in the user plane? That might be obvious to some, but its not to me and I guess there are a bunch of PMIPv6 extensions so I could imagine that someone somewhere might get it wrong. The signaling messages {IPv6 with Mobility Header, or IPv4 UDP Port 5436) traffic is exchanged between MAG-CP and LMA-CP. There is no implication on the use/non-use of other mobility options. Sure. My question is: where is it written down which are signalling messages and which are not? PMIPv6 Signaling messages (aka control plane messages) are PBU/PBA, BRI/BRA and UPN/UPA messages. The formats for these messages are specified in RFC 5213, 5844, 5846, 5847, 7077. Ex: http://tools.ietf.org/html/rfc5213#page-69 http://tools.ietf.org/html/rfc6275#page-42 The identification of any of these CP messages is the use of the following selector. 1. Any IPv4-UDP packets with UDP port 5436 2. Any IPv6 packets with Mobility Header messages Existing specs clearly explain this and I think its sufficiently clear for the implementors on what traffic goes to LMA-CP and what goes to the LMA-UP. Regards Sri Ta, S. The tunneled traffic with L3 encapsulation is between MAG-DP and LMA-DP. Regards Sri _______________________________________________ netext mailing list netext@ietf.org https://www.ietf.org/mailman/listinfo/netext --_000_D023CBF315BFFFsgundaveciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8C200C83EA1B9E499BE511EF705EFF77@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Stephen,

Please see the below text on security considerations for CP and UP traffic = protection. On thinking about this further, I have a feeling we are adding = a additional requirement here on User-Plane node on IPsec implementation.

The base line text in RFC 5213 requires IPSec as mandatory-to-implment mech= anism. However, it does not require the same for user -plane traffic protec= tion. But, one can argue that IPSec was implemented for CP traffic protecti= on and therefore implementation on that UP (UP-CP combo) node already existed. I cannot beat that argument= , but that was not surely the original intent in RFC5213. Any ways, I'm fin= e having IPsec as a mandatory-to-implement on both CP and UP nodes. Please = see the below text.



NEW:

The Proxy Mobile= IPv6 specification [RFC5213] requires the signaling messages between the M= AG and the LMA to be protected using end-to-end security association(s) off= ering integrity and data origin authentication. The base specification also requires IPsec a mandatory-to-implement securi= ty mechanism.

In deployments w= here the Control and User Plane functions on the MAG and LMA are separated = and hosted on different IP nodes, the nodes hosting those respective Contro= l Plane functions have to still meet the above the security requirement. The Proxy Mobile IPv6 signaling messag= es exchanged between these entities MUST be protected using end-to-end secu= rity association(s) offering integrity and data origin authentication. Furt= hermore, IPsec is a mandatory-to-implement security mechanism for the nodes hosting the Control Plane function of the= MAG and LMA. Additional documents may specify alternative mechanisms and t= he mobility entities can enable a specific mechanism for securing Proxy Mob= ile IPv6 signaling messages, based on either a static configuration or after a dynamic negotiation using any = standard security negotiation protocols.

As per the Proxy= Mobile IPv6 specification, the use of IPsec for protecting the mobile node= 's user plane traffic is optional. This specification extends the same requ= irement and therefore requires the nodes hosting the User Plane functions of the MAG and the LMA to have IPsec as a= mandatory-to-implement security mechanism, but make the use of IPsec as op= tional for User Plane traffic protection.



Text in RFC5213:


   The signaling messages, Proxy Binding Update, and = Proxy Binding
   Acknowledgement, exchanged between the mobile acce= ss gateway and the
   local mobility anchor, MUST be protected using end= -to-end security
   association(s) offering integrity and data origin = authentication.

   The mobile access gateway and the local mobility a= nchor MUST
   implement IPsec for protecting the Proxy Mobile IP= v6 signaling
   messages [RFC4301].  IPsec is a mandatory-to-= implement security
   mechanism.  However, additional documents may= specify alternative
   mechanisms and the mobility entities can enable a = specific mechanism
   for securing Proxy Mobile IPv6 signaling messages,= based on either a
   static configuration or after a dynamic negotiatio= n using any
   standard security negotiation protocols.  As = in Mobile IPv6
   [RFC3775], the use of IPsec for protecting a mobil= e node's data
   traffic is optional.


Regards
Sri




On 8/22/14 4:10 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote:

Hi Stephen,
Thanks for the review.
In this case, you're not even requiring implementation.
So if say, a MAG-UP were to talk to a LMA that is both
CP and UP, then the latter node would support IPsec for
UP, if so configured, but the MAG-UP might not even
implement IPsec.
Does that mean that you need to a a requirement here to
make IPsec MTI for the MAG-UP and LMA-UP, so that they
can interop with non-split MAGs and LMAs?
Requiring IPsec implementation on both the MAG-UP and LMA-UP nodes is = a fair requirement. We can certainly state that. If an operator chooses to = do so they can configures IPSec policy on LMA-UP and MAG-UP for PMIP tunnel= traffic protection. This will keep the spec consistent with the base RFC5213.
The signaling between LMA-CP and MAG-CP  needs to be protect= ed by IPsec and that is a mandatory requirement in RFC5213. No change there= . This specification still requires IPsec protection for control plane traf= fic between MAG-CP and LMA-CP.
We will draft some text to reflect this and post it for your review.

Great thanks,
S.


Regards
Sri
On 8/22/14 3:51 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@cs.tcd.ie>&= gt; wrote:
Hiya,
Sorry for the slow response...
The indentation below is a bit messed up, I hope its clear
who's saying what.
On 13/08/14 17:45, Sri Gundavelli (sgundave) wrote:
HI Stephen,
Please see inline.
On 8/13/14 5:21 AM, "Stephen Farrell"
Hiya,
A few follow ups...
On 09/08/14 17:54, Sri Gundavelli (sgundave) wrote: Hi Stephen,
Thanks for the review. Please see inline. On 8/7/14 5:50 AM, "Ste= phen
Farrell"
I have two questions. They could be easy or hard, I'm not sure:-)
Apologies in advance if I've forgotten what little I ever knew about
PMIPv6 and gotten stuff wrong here. Not at all. Thanks for the
discussion.
(1) PMIPv6 traffic between MAG and LMA is generally assumed to be
protected via IPsec, right? Assuming that's actually done, does
figure 1 here indicate a weakening of security since it shows that IP<= /div>
encapsulation is used between MAG-UP and LMA-UP without any mention
of IPsec. Is that downgrading security? I get that the binding
messages are the most important and will presumably continue on the
control plane but what else changes? Yes. PMIPv6 allows the use of
IPsec security (Tunnel Mode ESP) protection
"allows"? Do you happen to know if that's really used or not= in
practice? (That's not a DISCUSS point, but I do wonder.)
Security for user-plane traffic protection is used in very few
deployments.
Ah.
Taking the Service Provider Wi-Fi deployment as an
example, there is 802.1x security on the air interface, and then
there is typical end to end application security (even a Google
search is HTTPS protected).  Now requiring security on the u= ser plane
traffic between two points in the operator network (LMA and MAG) is
some what redundant, IMO. Use of IPsec for UP traffic protection is
optional per MIPv6/PMIPv6 specs.  I'd say banking type
applications/deployments requires such multi-layer security.
Hmm. I don't see that it makes any sense to assume IPsec is
done differently per-application. So I guess we ought assume
that IPsec isn't used for user traffic.
Is it really used for control plane traffic do you know?
But in a sense this spec is lowering the bar a little.
5213 requires implementation of IPsec on the node that
carries the UP traffic, even if it doesn't require its
use.
In this case, you're not even requiring implementation.
So if say, a MAG-UP were to talk to a LMA that is both
CP and UP, then the latter node would support IPsec for
UP, if so configured, but the MAG-UP might not even
implement IPsec.
Does that mean that you need to a a requirement here to
make IPsec MTI for the MAG-UP and LMA-UP, so that they
can interop with non-split MAGs and LMAs?
I'd assume that'd be easy enough and it'd clear up
that discuss point.
for the user-plane traffic. This is optional and is based on
standard IPsec security. It requires no special interaction between
IPsec and the Proxy Mobile IPv6 entities. In the split mode (LMA =3D= =3D>
LMA-CP & LMA-DP),
What's LMA-DP? That's not mentioned in the draft? I assume you mean
what the draft calls LMA-UP? (I.e. DP =3D data plane being the same as=
UP =3D user plane?)
Apologies for the terminology mix up. Yes. LMA-DP (Data Plane) should<= /div>
be the LMA-UP (User Plane)
the MAG (or MAG-DP) and the LMA-DP can optionally enable IPsec
security on the user-plane traffic.
Hmm. So you're saying IPsec can be on for the control plane and off
for the user plane independently? Is that a good plan? I guess it'd
be a bad plan if it were the other way around?
I'd say this is the approach in use for today's integrated LMA
(LMA-UP + LMA-CP) based deployments. IPsec security is enabled for= CP
traffic by default, as it is mandated by PMIPv6 specs. However, the
IPsec security for UP is a optional requirement and most deployments
don't enable IPsec for UP traffic protection.
MAG-DP establishes a layer-3 p2p tunnel to LMA-DP and both these
peers can be configured to apply IPsec security on the tunneled
traffic. So, there is no loss of functionality here and the CP/DP
split approach is not resulting in weakened security.
Well, it might if IPsec is on for one and off for the other.
Or, if say MAG-CP and MAG-UP are from different vendors, then I don't<= /div>
know how they signal to one another to turn on/off IPsec if what we
want is for IPsec to be on for both or off for both.
I'd look at IPsec as a security policy between two peers. Use of
IPsec for CP messages between two CP nodes (Ex: MAP-CP and LMA-CP)
should not have any bearing on the use/non-use of IPsec security
between two UP nodes (Ex: MAG-UP and LMA-UP). The security policy on
the two UP nodes strictly determine the use/non-use of IPsec for
tunnel traffic protection. But, if the hint is that this policy
should be controlled by the respective CP entity, I'd say yes, but
that CP to UP interface is out of scope for this work. The
controller/CP entity may have a provisioning interface to the UP
nodes and that interface may dictate this aspect, but has not
implication on this draft.
(2) How does the rest of the Internet know to use the LMA-UP for the
MN and not the LMA-CP? Sorry for being dense but I don't see how
packets from a random Internet node for the MN end up going down the
user plane. The IP address of the mobile node is topologically
anchored on the LMA-DP.
You mean LMA-UP there right?
Yes. Sorry for the terminology mix-up.
From the point of view of Routing, the LMA-DP owns that larger IP
prefix
block from which it allocates to IP prefixes/address to individual
mobility sessions. The LMA-DP is in the path for the user-plane
traffic and is the entry point into the mobile network.  How= ever, the
LMA-CP is only terminating the control signaling from the MAG and is
not in the path for the user-plane traffic.
Is that written down somewhere? If say the LMA-UP and LMA-CP had
utterly different addresses then it couldn't work could it?
This was captured in Section 5.6.2 for IPv6
When we separate the functionality, the user plane (or the IP
address/prefixes allocated to the MN) must be anchored on the LMA-UP.<= /div>
I think we missed capturing this in the spec. Thanks for pointing
this out.
OLD:
The LMA Control Plane and the LMA User Plane functions are typically
deployed on the same IP node and in such scenario the interface
between these functions is internal to the implementation.
Deployments may also choose to deploy the LMA Control Plane and the
LMA User Plane functions on seperate IP nodes. In such deployment
models, there needs to be a protocol interface between these two
functions and which is outside the scope of this document. Possible
options for such interface include OpenFlow [OpenFlow-Spec-v1.4.0
<http://tools.ietf.org/html/dra= ft-ietf-netext-pmip-cp-up-separation-06#ref-OpenFlow-Spec-v1.4.0>],<= /div>
FORCES [RFC5810 <http://tools.ietf.org/html/rfc5810>], use of routing
infrastructure
[I-D.matsushima-stateless-uplane-vepc
or vendor specific approaches. This specification does not mandate a
specific protocol interface and views this interface as a generic
interface relevant more broadly for many other protocol systems in
addition to Proxy Mobile IPv6.
NEW:
The LMA Control Plane and the LMA User Plane functions are typically
deployed on the same IP node and in such scenario the interface
between these functions is internal to the implementation.
Deployments may also choose to deploy the LMA Control Plane and the
LMA User Plane functions on seperate IP nodes. In such deployment
models, there needs to be a protocol interface between these two
functions and which is outside the scope of this document. Possible
options for such interface include OpenFlow [OpenFlow-Spec-v1.4.0
<http://tools.ietf.org/html/dra= ft-ietf-netext-pmip-cp-up-separation-06#ref-OpenFlow-Spec-v1.4.0>],<= /div>
FORCES [RFC5810 <http://tools.ietf.org/html/rfc5810>], use of routing
infrastructure
[I-D.matsushima-stateless-uplane-vepc
or vendor specific approaches. This specification does not mandate a
specific protocol interface and views this interface as a generic
interface relevant more broadly for many other protocol systems in
addition to Proxy Mobile IPv6. When the LMA Control Plane and the LMA<= /div>
User Plane functions are deployed on separate IP nodes, the
requirement related to user-plane address anchoring specified in
Section 5.6.2 [RFC-5213] and Section 3.1.3 [RFC5844] must be met by
the  node hosting the LMA user plane functionality. The LMA = user
plane node must be topological anchor point for the IP
address/prefixes allocated to the mobile node.
I'm not quite sure if that does sort out the issue or not,
but I'm willing to believe you and Brian if you're telling
me it does.
So with that OLD/NEW and adding IPsec as MTI for the
*-UP nodes, I think we'd be done.
Cheers,
S.
----------------------------------------------------------------------=
COMMENT:
----------------------------------------------------------------------=
Did you need to say somewhere which PMIPv6 messages are to be sent in<= /div>
the control plane and which in the user plane? That might be obvious
to some, but its not to me and I guess there are a bunch of PMIPv6
extensions so I could imagine that someone somewhere might get it
wrong.
The signaling messages {IPv6 with Mobility Header, or IPv4 UDP Port
5436) traffic is exchanged between MAG-CP and LMA-CP. There is no
implication on the use/non-use of other mobility options.
Sure. My question is: where is it written down which are signalling
messages and which are not?
PMIPv6 Signaling messages (aka control plane messages) are PBU/PBA,
BRI/BRA and UPN/UPA messages. The formats for these messages are
specified in RFC 5213, 5844, 5846, 5847, 7077.
The identification of any of these CP messages is the use of the
following selector.
1. Any IPv4-UDP packets with UDP port 5436 2. Any IPv6 packets with
Mobility Header messages
Existing specs clearly explain this and I think its sufficiently
clear for the implementors on what traffic goes to LMA-CP and what
goes to the LMA-UP.
Regards Sri
Ta, S.
The tunneled traffic with L3 encapsulation is between MAG-DP and
LMA-DP. Regards Sri

--_000_D023CBF315BFFFsgundaveciscocom_-- From nobody Thu Aug 28 02:01:01 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604661A0435; Thu, 28 Aug 2014 02:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSh8gC3FrMaT; Thu, 28 Aug 2014 02:00:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D2C4D1A06F6; Thu, 28 Aug 2014 02:00:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A3A27BEBC; Thu, 28 Aug 2014 10:00:51 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xQOz6BLtCEG; Thu, 28 Aug 2014 10:00:51 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 704A6BEB6; Thu, 28 Aug 2014 10:00:51 +0100 (IST) Message-ID: <53FEEFC4.9030206@cs.tcd.ie> Date: Thu, 28 Aug 2014 10:00:52 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Charlie Perkins , "Sri Gundavelli (sgundave)" , The IESG References: <53FEB333.3090108@earthlink.net> In-Reply-To: <53FEB333.3090108@earthlink.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netext/RJVQr_G8IB2CwBSTNnfqoJ-YGGs Cc: netext@ietf.org, netext-chairs@tools.ietf.org, draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org Subject: Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 09:00:57 -0000 On 28/08/14 05:42, Charlie Perkins wrote: > > Hello folks, > > I am basically O.K. with the suggested. Same here. Thanks. > A couple of minor points: > > - "any standard security negotiation protocols" -- should this be > restricted to IETF > protocols? What is the difference between a "security negotiation > protocol" > and a "security protocol"? Shouldn't we allow static configuration > in some > circumstances for some installations? Right. In a sense there's no need to say that at all. For interop with pmipv6 that doesn't split the cp/up, you gotta use IPsec as that's all the spec'd now. If that's not what concerns you as an implementer (e.g. between your very own cp/up devices) then you're as free as ever to do whatever. (Modulo customer RFQs etc.) So not sure there's that much value in flexibility there. Cheers, S. > > - "make the use of IPsec as optional" --> "does not require the use of > IPsec" > or, maybe, "specifies that the use of IPsec is optional" > > Is it the consensus of those involved here that this change does not > require > input from the working group? > > Regards, > Charlie P. > > > > On 8/27/2014 6:03 PM, Sri Gundavelli (sgundave) wrote: >> Hi Stephen, >> >> Please see the below text on security considerations for CP and UP >> traffic protection. On thinking about this further, I have a feeling >> we are adding a additional requirement here on User-Plane node on >> IPsec implementation. >> >> The base line text in RFC 5213 requires IPSec as mandatory-to-implment >> mechanism. However, it does not require the same for user -plane >> traffic protection. But, one can argue that IPSec was implemented for >> CP traffic protection and therefore implementation on that UP (UP-CP >> combo) node already existed. I cannot beat that argument, but that was >> not surely the original intent in RFC5213. Any ways, I'm fine having >> IPsec as a mandatory-to-implement on both CP and UP nodes. Please see >> the below text. >> >> >> >> NEW: >> >> *The Proxy Mobile IPv6 specification [RFC5213] requires the signaling >> messages between the MAG and the LMA to be protected using end-to-end >> security association(s) offering integrity and data origin >> authentication. The base specification also requires IPsec a >> mandatory-to-implement security mechanism. * >> * >> * >> *In deployments where the Control and User Plane functions on the MAG >> and LMA are separated and hosted on different IP nodes, the nodes >> hosting those respective Control Plane functions have to still meet >> the above the security requirement. The Proxy Mobile IPv6 signaling >> messages exchanged between these entities MUST be protected using >> end-to-end security association(s) offering integrity and data origin >> authentication. Furthermore, IPsec is a mandatory-to-implement >> security mechanism for the nodes hosting the Control Plane function of >> the MAG and LMA. Additional documents may specify alternative >> mechanisms and the mobility entities can enable a specific mechanism >> for securing Proxy Mobile IPv6 signaling messages, based on either a >> static configuration or after a dynamic negotiation using any standard >> security negotiation protocols. * >> * >> * >> *As per the Proxy Mobile IPv6 specification, the use of IPsec for >> protecting the mobile node's user plane traffic is optional. This >> specification extends the same requirement and therefore requires the >> nodes hosting the User Plane functions of the MAG and the LMA to have >> IPsec as a mandatory-to-implement security mechanism, but make the use >> of IPsec as optional for User Plane traffic protection.* >> >> >> >> _Text in RFC5213:_ >> >> >> * The signaling messages, Proxy Binding Update, and Proxy Binding* >> * Acknowledgement, exchanged between the mobile access gateway and the* >> * local mobility anchor, MUST be protected using end-to-end security* >> * association(s) offering integrity and data origin authentication.* >> * >> * >> * The mobile access gateway and the local mobility anchor MUST* >> * implement IPsec for protecting the Proxy Mobile IPv6 signaling* >> * messages [RFC4301]. IPsec is a mandatory-to-implement security* >> * mechanism. However, additional documents may specify alternative* >> * mechanisms and the mobility entities can enable a specific mechanism* >> * for securing Proxy Mobile IPv6 signaling messages, based on either a* >> * static configuration or after a dynamic negotiation using any* >> * standard security negotiation protocols. As in Mobile IPv6* >> * [RFC3775], the use of IPsec for protecting a mobile node's data* >> * traffic is optional.* >> >> >> Regards >> Sri >> >> >> >> >> On 8/22/14 4:10 PM, "Stephen Farrell" > > wrote: >> >> >> >> On 23/08/14 00:08, Sri Gundavelli (sgundave) wrote: >> >> Hi Stephen, >> Thanks for the review. >> >> In this case, you're not even requiring implementation. >> >> So if say, a MAG-UP were to talk to a LMA that is both >> CP and UP, then the latter node would support IPsec for >> UP, if so configured, but the MAG-UP might not even >> implement IPsec. >> >> Does that mean that you need to a a requirement here to >> >> make IPsec MTI for the MAG-UP and LMA-UP, so that they >> can interop with non-split MAGs and LMAs? >> Requiring IPsec implementation on both the MAG-UP and LMA-UP >> nodes is a fair requirement. We can certainly state that. If >> an operator chooses to do so they can configures IPSec policy >> on LMA-UP and MAG-UP for PMIP tunnel traffic protection. This >> will keep the spec consistent with the base RFC5213. >> The signaling between LMA-CP and MAG-CP needs to be protected >> by IPsec and that is a mandatory requirement in RFC5213. No >> change there. This specification still requires IPsec >> protection for control plane traffic between MAG-CP and LMA-CP. >> We will draft some text to reflect this and post it for your >> review. >> >> >> Great thanks, >> S. >> >> >> Regards >> Sri >> On 8/22/14 3:51 PM, "Stephen Farrell" >> > >> >> > wrote: >> Hiya, >> Sorry for the slow response... >> The indentation below is a bit messed up, I hope its clear >> who's saying what. >> On 13/08/14 17:45, Sri Gundavelli (sgundave) wrote: >> HI Stephen, >> Please see inline. >> On 8/13/14 5:21 AM, "Stephen Farrell" >> > >> >> >> >> > >> >> wrote: >> Hiya, >> A few follow ups... >> On 09/08/14 17:54, Sri Gundavelli (sgundave) wrote: Hi Stephen, >> Thanks for the review. Please see inline. On 8/7/14 5:50 AM, >> "Stephen >> Farrell" >> > >> >> >> >> > >> >> wrote: >> I have two questions. They could be easy or hard, I'm not sure:-) >> Apologies in advance if I've forgotten what little I ever knew >> about >> PMIPv6 and gotten stuff wrong here. Not at all. Thanks for the >> discussion. >> (1) PMIPv6 traffic between MAG and LMA is generally assumed to be >> protected via IPsec, right? Assuming that's actually done, does >> figure 1 here indicate a weakening of security since it shows >> that IP >> encapsulation is used between MAG-UP and LMA-UP without any >> mention >> of IPsec. Is that downgrading security? I get that the binding >> messages are the most important and will presumably continue >> on the >> control plane but what else changes? Yes. PMIPv6 allows the >> use of >> IPsec security (Tunnel Mode ESP) protection >> "allows"? Do you happen to know if that's really used or not in >> practice? (That's not a DISCUSS point, but I do wonder.) >> Security for user-plane traffic protection is used in very few >> deployments. >> Ah. >> Taking the Service Provider Wi-Fi deployment as an >> example, there is 802.1x security on the air interface, and then >> there is typical end to end application security (even a Google >> search is HTTPS protected). Now requiring security on the >> user plane >> traffic between two points in the operator network (LMA and >> MAG) is >> some what redundant, IMO. Use of IPsec for UP traffic >> protection is >> optional per MIPv6/PMIPv6 specs. I'd say banking type >> applications/deployments requires such multi-layer security. >> Hmm. I don't see that it makes any sense to assume IPsec is >> done differently per-application. So I guess we ought assume >> that IPsec isn't used for user traffic. >> Is it really used for control plane traffic do you know? >> But in a sense this spec is lowering the bar a little. >> 5213 requires implementation of IPsec on the node that >> carries the UP traffic, even if it doesn't require its >> use. >> In this case, you're not even requiring implementation. >> So if say, a MAG-UP were to talk to a LMA that is both >> CP and UP, then the latter node would support IPsec for >> UP, if so configured, but the MAG-UP might not even >> implement IPsec. >> Does that mean that you need to a a requirement here to >> make IPsec MTI for the MAG-UP and LMA-UP, so that they >> can interop with non-split MAGs and LMAs? >> I'd assume that'd be easy enough and it'd clear up >> that discuss point. >> for the user-plane traffic. This is optional and is based on >> standard IPsec security. It requires no special interaction >> between >> IPsec and the Proxy Mobile IPv6 entities. In the split mode >> (LMA ==> >> LMA-CP & LMA-DP), >> What's LMA-DP? That's not mentioned in the draft? I assume you >> mean >> what the draft calls LMA-UP? (I.e. DP = data plane being the >> same as >> UP = user plane?) >> Apologies for the terminology mix up. Yes. LMA-DP (Data Plane) >> should >> be the LMA-UP (User Plane) >> the MAG (or MAG-DP) and the LMA-DP can optionally enable IPsec >> security on the user-plane traffic. >> Hmm. So you're saying IPsec can be on for the control plane >> and off >> for the user plane independently? Is that a good plan? I guess >> it'd >> be a bad plan if it were the other way around? >> I'd say this is the approach in use for today's integrated LMA >> (LMA-UP + LMA-CP) based deployments. IPsec security is enabled >> for CP >> traffic by default, as it is mandated by PMIPv6 specs. >> However, the >> IPsec security for UP is a optional requirement and most >> deployments >> don't enable IPsec for UP traffic protection. >> MAG-DP establishes a layer-3 p2p tunnel to LMA-DP and both these >> peers can be configured to apply IPsec security on the tunneled >> traffic. So, there is no loss of functionality here and the CP/DP >> split approach is not resulting in weakened security. >> Well, it might if IPsec is on for one and off for the other. >> Or, if say MAG-CP and MAG-UP are from different vendors, then >> I don't >> know how they signal to one another to turn on/off IPsec if >> what we >> want is for IPsec to be on for both or off for both. >> I'd look at IPsec as a security policy between two peers. Use of >> IPsec for CP messages between two CP nodes (Ex: MAP-CP and >> LMA-CP) >> should not have any bearing on the use/non-use of IPsec security >> between two UP nodes (Ex: MAG-UP and LMA-UP). The security >> policy on >> the two UP nodes strictly determine the use/non-use of IPsec for >> tunnel traffic protection. But, if the hint is that this policy >> should be controlled by the respective CP entity, I'd say yes, >> but >> that CP to UP interface is out of scope for this work. The >> controller/CP entity may have a provisioning interface to the UP >> nodes and that interface may dictate this aspect, but has not >> implication on this draft. >> (2) How does the rest of the Internet know to use the LMA-UP >> for the >> MN and not the LMA-CP? Sorry for being dense but I don't see how >> packets from a random Internet node for the MN end up going >> down the >> user plane. The IP address of the mobile node is topologically >> anchored on the LMA-DP. >> You mean LMA-UP there right? >> Yes. Sorry for the terminology mix-up. >> >> From the point of view of Routing, the LMA-DP owns that >> larger IP >> >> prefix >> block from which it allocates to IP prefixes/address to >> individual >> mobility sessions. The LMA-DP is in the path for the user-plane >> traffic and is the entry point into the mobile >> network. However, the >> LMA-CP is only terminating the control signaling from the MAG >> and is >> not in the path for the user-plane traffic. >> Is that written down somewhere? If say the LMA-UP and LMA-CP had >> utterly different addresses then it couldn't work could it? >> This was captured in Section 5.6.2 for IPv6 >> http://tools.ietf.org/html/rfc5213#page-38 >> Section 3.1.3 for IPv4 >> http://tools.ietf.org/html/rfc5844#page-15 >> >> When we separate the functionality, the user plane (or the IP >> address/prefixes allocated to the MN) must be anchored on the >> LMA-UP. >> I think we missed capturing this in the spec. Thanks for pointing >> this out. >> OLD: >> The LMA Control Plane and the LMA User Plane functions are >> typically >> deployed on the same IP node and in such scenario the interface >> between these functions is internal to the implementation. >> Deployments may also choose to deploy the LMA Control Plane >> and the >> LMA User Plane functions on seperate IP nodes. In such deployment >> models, there needs to be a protocol interface between these two >> functions and which is outside the scope of this document. >> Possible >> options for such interface include OpenFlow [OpenFlow-Spec-v1.4.0 >> >> >> >> >> ], >> >> FORCES [RFC5810 >> ], use of routing >> infrastructure >> [I-D.matsushima-stateless-uplane-vepc >> >> >> >> >> ] >> >> or vendor specific approaches. This specification does not >> mandate a >> specific protocol interface and views this interface as a generic >> interface relevant more broadly for many other protocol >> systems in >> addition to Proxy Mobile IPv6. >> NEW: >> The LMA Control Plane and the LMA User Plane functions are >> typically >> deployed on the same IP node and in such scenario the interface >> between these functions is internal to the implementation. >> Deployments may also choose to deploy the LMA Control Plane >> and the >> LMA User Plane functions on seperate IP nodes. In such deployment >> models, there needs to be a protocol interface between these two >> functions and which is outside the scope of this document. >> Possible >> options for such interface include OpenFlow [OpenFlow-Spec-v1.4.0 >> >> >> >> >> ], >> >> FORCES [RFC5810 >> ], use of routing >> infrastructure >> [I-D.matsushima-stateless-uplane-vepc >> >> >> >> >> ] >> >> or vendor specific approaches. This specification does not >> mandate a >> specific protocol interface and views this interface as a generic >> interface relevant more broadly for many other protocol >> systems in >> addition to Proxy Mobile IPv6. When the LMA Control Plane and >> the LMA >> User Plane functions are deployed on separate IP nodes, the >> requirement related to user-plane address anchoring specified in >> Section 5.6.2 [RFC-5213] and Section 3.1.3 [RFC5844] must be >> met by >> the node hosting the LMA user plane functionality. The LMA user >> plane node must be topological anchor point for the IP >> address/prefixes allocated to the mobile node. >> I'm not quite sure if that does sort out the issue or not, >> but I'm willing to believe you and Brian if you're telling >> me it does. >> So with that OLD/NEW and adding IPsec as MTI for the >> *-UP nodes, I think we'd be done. >> Cheers, >> S. >> >> ---------------------------------------------------------------------- >> COMMENT: >> >> ---------------------------------------------------------------------- >> Did you need to say somewhere which PMIPv6 messages are to be >> sent in >> the control plane and which in the user plane? That might be >> obvious >> to some, but its not to me and I guess there are a bunch of >> PMIPv6 >> extensions so I could imagine that someone somewhere might get it >> wrong. >> The signaling messages {IPv6 with Mobility Header, or IPv4 UDP >> Port >> 5436) traffic is exchanged between MAG-CP and LMA-CP. There is no >> implication on the use/non-use of other mobility options. >> Sure. My question is: where is it written down which are >> signalling >> messages and which are not? >> PMIPv6 Signaling messages (aka control plane messages) are >> PBU/PBA, >> BRI/BRA and UPN/UPA messages. The formats for these messages are >> specified in RFC 5213, 5844, 5846, 5847, 7077. >> Ex: http://tools.ietf.org/html/rfc5213#page-69 >> http://tools.ietf.org/html/rfc6275#page-42 >> The identification of any of these CP messages is the use of the >> following selector. >> 1. Any IPv4-UDP packets with UDP port 5436 2. Any IPv6 packets >> with >> Mobility Header messages >> Existing specs clearly explain this and I think its sufficiently >> clear for the implementors on what traffic goes to LMA-CP and >> what >> goes to the LMA-UP. >> Regards Sri >> Ta, S. >> The tunneled traffic with L3 encapsulation is between MAG-DP and >> LMA-DP. Regards Sri >> _______________________________________________ netext mailing >> list >> netext@ietf.org >> >> > > >> https://www.ietf.org/mailman/listinfo/netext >> >> >> >> >> _______________________________________________ >> netext mailing list >> netext@ietf.org >> https://www.ietf.org/mailman/listinfo/netext > > From nobody Thu Aug 28 05:03:07 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238EB1A038A; Thu, 28 Aug 2014 05:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVWLDbRRVy_3; Thu, 28 Aug 2014 05:02:56 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440291A038B; Thu, 28 Aug 2014 05:02:54 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 22CA2880E5; Thu, 28 Aug 2014 05:02:54 -0700 (PDT) Received: from 1025210111.rude2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 2982671B0001; Thu, 28 Aug 2014 05:02:53 -0700 (PDT) Message-ID: <53FF1A6C.5060602@innovationslab.net> Date: Thu, 28 Aug 2014 08:02:52 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Charlie Perkins , "Sri Gundavelli (sgundave)" , Stephen Farrell , The IESG References: <53FEB333.3090108@earthlink.net> In-Reply-To: <53FEB333.3090108@earthlink.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XBSHtft5LwHbb23g6Q2dFp92pvhcHDTwr" Archived-At: http://mailarchive.ietf.org/arch/msg/netext/3iIO2xbZRazsJdNIUdCbXhDq__s Cc: netext@ietf.org, netext-chairs@tools.ietf.org, draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org Subject: Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 12:02:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XBSHtft5LwHbb23g6Q2dFp92pvhcHDTwr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Charlie, On 8/28/14 12:42 AM, Charlie Perkins wrote: >=20 > Hello folks, >=20 > I am basically O.K. with the suggested. A couple of minor points: >=20 > - "any standard security negotiation protocols" -- should this be > restricted to IETF > protocols? What is the difference between a "security negotiation > protocol" > and a "security protocol"? Shouldn't we allow static configuration= > in some > circumstances for some installations? >=20 > - "make the use of IPsec as optional" --> "does not require the use o= f > IPsec" > or, maybe, "specifies that the use of IPsec is optional" >=20 > Is it the consensus of those involved here that this change does not > require > input from the working group? Not at all, that is why the WG mailing list is copied on these discussions. As the shepherding AD, I want to make sure that the discussion with the dissenting AD is resolved. If WG members disagree with the proposed changes, they are free to raise that disagreement. If the resulting changes are substantive, I will ask the chairs to review those changes with the WG prior to any publication approval. Regards, Brian --XBSHtft5LwHbb23g6Q2dFp92pvhcHDTwr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT/xpsAAoJEBOZRqCi7goq9RgH+gPbSmF8m21k6++mxudyI1bB 6xxAogG+qHJn/ZWiGC9XL5BstEc10ZfEy/EGmLR9b2lIUeCKAVQIxr2nQvG5RPzh EpUaJhhlSK04ouN49nCBUZ66JowCqUs9R3hFnBqTUUIKYaOIaI7GjX/9i73tU4fU 3Brf6/G59v1WgxVHV0NWA0eo37pHI+GowHIWjTPv1+PiShQmxOh5rdDuyC1iHYvp vHIlV2z9U0nK5P3eqGTyqV457871MmSj/aUjJNZaFnQr4ppt3ZdZDjjD81rKWfyx J9T+H1i7v97E50bPLzOuPgrX7o/9ZhV8hqtr8Id96BJauJLy0O+PVdMNT7E0oKk= =Ap25 -----END PGP SIGNATURE----- --XBSHtft5LwHbb23g6Q2dFp92pvhcHDTwr-- From nobody Thu Aug 28 07:32:15 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305671A06C5; Thu, 28 Aug 2014 07:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01W6gz0NhBmz; Thu, 28 Aug 2014 07:32:12 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6702D1A055D; Thu, 28 Aug 2014 07:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2839; q=dns/txt; s=iport; t=1409236332; x=1410445932; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9Tlt5NjEP2ckX/n+nlolJ6pTsB/QYHY0QMKlBj8PQ80=; b=TkBwcofdGceOAwcd/pVUHpKwf6HunAcAZ3iLsI774oPCPFFi6b4rUUWA 98DpickgYlYYjkR8+cWvRHqY9wdzZQJQ3pqUzlT3VFMe0HV1N/TTF0Sg6 2+c/+D5mopnw17lQ5DWYomefTSe9G5zepw8xUdhwt00QHLVcnCApSuQpQ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFABE8/1OtJA2N/2dsb2JhbABbgw2BKgTTdgGBGRZ3hAQBAQMBOj8FDQEIEiQFPRcOAgQBDQWIOgi/QheMHYMvB4RMAQSRL4srjBiJBYIYgUZsgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,418,1406592000"; d="scan'208";a="73140156" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-8.cisco.com with ESMTP; 28 Aug 2014 14:32:11 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s7SEWBsV020921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 14:32:11 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.223]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 28 Aug 2014 09:32:11 -0500 From: "Sri Gundavelli (sgundave)" To: Brian Haberman , Charlie Perkins , Stephen Farrell , The IESG Thread-Topic: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT) Thread-Index: AQHPwszZxeWgT3fAO0GWwqdK0/n2nw== Date: Thu, 28 Aug 2014 14:32:10 +0000 Message-ID: In-Reply-To: <53FF1A6C.5060602@innovationslab.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.213] Content-Type: text/plain; charset="us-ascii" Content-ID: <636C161FBE00494891AF64C49DC517B7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/j0oyzOkZS7IVoliXcPHoosrGK5s Cc: "netext@ietf.org" , "netext-chairs@tools.ietf.org" , "draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org" Subject: Re: [netext] Stephen Farrell's Discuss on draft-ietf-netext-pmip-cp-up-separation-05: (with DISCUSS and COMMENT) X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 14:32:14 -0000 Thanks Stephen. We will go with that text then. On 8/28/14 5:02 AM, "Brian Haberman" wrote: > If WG members disagree >with the proposed changes, they are free to raise that disagreement. If >the resulting changes are substantive, I will ask the chairs to review >those changes with the WG prior to any publication approval. The proposed text on IPsec is inline with the base spec. We kept the following original agreements. 1.) Protection for PMIPv6 signaling messages with end-to-end security association(s) offering integrity and data origin authentication. 2.) IPsec is a mandatory to implement on CP nodes 3.) IPsec is mandatory to implement on UP nodes 4.) Use of IPsec for user plane traffic protection is optional 5.) New specifications can be define alternative security mechanisms for protecting signaling messages This is inline with the text in RFC-5213. My comment was on #3, where the implementation of IPsec was mandated indirectly by having a requirement for CP traffic protection. Nothing substantial. Explicit statements on the protocol security for the split CP/DP architecture. Working Group: Any comments on the below text, please speak up. NEW: The Proxy Mobile IPv6 specification [RFC5213] requires the signaling messages between the MAG and the LMA to be protected using end-to-end security association(s) offering integrity and data origin authentication. The base specification also requires IPsec a mandatory-to-implement security mechanism. In deployments where the Control and User Plane functions on the MAG and LMA are separated and hosted on different IP nodes, the nodes hosting those respective Control Plane functions have to still meet the above the security requirement. The Proxy Mobile IPv6 signaling messages exchanged between these entities MUST be protected using end-to-end security association(s) offering integrity and data origin authentication. Furthermore, IPsec is a mandatory-to-implement security mechanism for the nodes hosting the Control Plane function of the MAG and LMA. Additional documents may specify alternative mechanisms and the mobility entities can enable a specific mechanism for securing Proxy Mobile IPv6 signaling messages, based on either a static configuration or after a dynamic negotiation using any standard security negotiation protocols. As per the Proxy Mobile IPv6 specification, the use of IPsec for protecting the mobile node's user plane traffic is optional. This specification extends the same requirement and therefore requires the nodes hosting the User Plane functions of the MAG and the LMA to have IPsec as a mandatory-to-implement security mechanism, but make the use of IPsec as optional for User Plane traffic protection. Regards Sri From nobody Sat Aug 30 17:26:03 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3161A6F0A; Sat, 30 Aug 2014 17:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJy1XykVJbfi; Sat, 30 Aug 2014 17:25:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B31951A6F01; Sat, 30 Aug 2014 17:25:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140831002559.29345.59127.idtracker@ietfa.amsl.com> Date: Sat, 30 Aug 2014 17:25:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/ZRewyN4bcCByHIn6Ms0xxFz1fKc Cc: netext@ietf.org Subject: [netext] I-D Action: draft-ietf-netext-pmip-cp-up-separation-07.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 00:26:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network-Based Mobility Extensions Working Group of the IETF. Title : Separation of Control and User Plane for Proxy Mobile IPv6 Authors : Ryuji Wakikawa Rajesh S. Pazhyannur Sri Gundavelli Charles E. Perkins Filename : draft-ietf-netext-pmip-cp-up-separation-07.txt Pages : 12 Date : 2014-08-30 Abstract: This document specifies a method to split the Control Plane (CP) and User Plane (UP) for a Proxy Mobile IPv6 based network infrastructure. Existing specifications allow a mobile access gateway (MAG) to separate its control and user plane using the Alternate Care of address mobility option for IPv6, or Alternate IPv4 Care of Address option for IPv4. However, the current specification does not provide any mechanism allowing the local mobility anchor (LMA) to perform an analogous functional split. To remedy that shortcoming, this document specifies a mobility option enabling a LMA to provide an alternate LMA address to be used for the bi-directional user plane traffic between the MAG and LMA. With this new option, a LMA will be able to use an IP address for its user plane which is different than the IP address used for the control plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netext-pmip-cp-up-separation-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip-cp-up-separation-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Aug 30 17:26:06 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C26A11A6F01 for ; Sat, 30 Aug 2014 17:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xy4a20NpKeAW; Sat, 30 Aug 2014 17:26:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D241A6F03; Sat, 30 Aug 2014 17:25:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: netext-chairs@tools.ietf.org, draft-ietf-netext-pmip-cp-up-separation@tools.ietf.org, netext@ietf.org, brian@innovationslab.net, stephen.farrell@cs.tcd.ie X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140831002559.29345.26389.idtracker@ietfa.amsl.com> Date: Sat, 30 Aug 2014 17:25:59 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netext/01sZTZGUTRWX4qdQ9gzjUCFM53E Subject: [netext] New Version Notification - draft-ietf-netext-pmip-cp-up-separation-07.txt X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 00:26:01 -0000 A new version (-07) has been submitted for draft-ietf-netext-pmip-cp-up-separation: http://www.ietf.org/internet-drafts/draft-ietf-netext-pmip-cp-up-separation-07.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-cp-up-separation/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-netext-pmip-cp-up-separation-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Sat Aug 30 23:43:38 2014 Return-Path: X-Original-To: netext@ietfa.amsl.com Delivered-To: netext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3090D1A8778 for ; Sat, 30 Aug 2014 23:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PUS6YRdP5T5 for ; Sat, 30 Aug 2014 23:43:33 -0700 (PDT) Received: from out23-ams.mf.surf.net (out23-ams.mf.surf.net [145.0.1.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEC3B1A6F51 for ; Sat, 30 Aug 2014 23:43:32 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id s7V6hM57005730; Sun, 31 Aug 2014 08:43:22 +0200 Received: from EXMBX32.ad.utwente.nl (130.89.4.147) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.3.181.6; Sun, 31 Aug 2014 08:43:28 +0200 Received: from EXMBX31.ad.utwente.nl (130.89.4.146) by EXMBX32.ad.utwente.nl (130.89.4.147) with Microsoft SMTP Server (TLS) id 15.0.913.22; Sun, 31 Aug 2014 08:43:21 +0200 Received: from EXMBX31.ad.utwente.nl ([130.89.4.146]) by EXMBX31.ad.utwente.nl ([130.89.4.146]) with mapi id 15.00.0913.011; Sun, 31 Aug 2014 08:43:21 +0200 From: To: , Thread-Topic: [netext] Interest to review the Logical Interface ID Thread-Index: AQHPrFsdid6QhDPT+ESQw8VQLKrIm5u7VmK0///2iwCALyccCg== Date: Sun, 31 Aug 2014 06:43:20 +0000 Message-ID: <6f082f1af6234f779cec63e50baadfa3@EXMBX31.ad.utwente.nl> References: , <22894_1406882145_53DB5161_22894_8388_1_81C77F07008CA24F9783A98CFD706F7114276615@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <22894_1406882145_53DB5161_22894_8388_1_81C77F07008CA24F9783A98CFD706F7114276615@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: nl-NL, nl-BE, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.91.134.3] Content-Type: multipart/alternative; boundary="_000_6f082f1af6234f779cec63e50baadfa3EXMBX31adutwentenl_" MIME-Version: 1.0 X-Bayes-Prob: 0.0001 (Score 0, tokens from: utwente-out:default, base:default, @@RPTN) X-CanIt-Geo: ip=130.89.5.48; country=NL; region=Provincie Overijssel; city=Enschede; latitude=52.2195; longitude=6.8912; http://maps.google.com/maps?q=52.2195,6.8912&z=6 X-CanItPRO-Stream: utwente-out:default (inherits from utwente:default, base:default) X-Canit-Stats-ID: 0uMJiHmuI - 11ef4d99247f - 20140831 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Archived-At: http://mailarchive.ietf.org/arch/msg/netext/xRzjiwonVLYAn4sMKLGGlLy2FKs Cc: netext@ietf.org, netext-chairs@ietf.org Subject: Re: [netext] Interest to review the Logical Interface ID X-BeenThere: netext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Aug 2014 06:43:36 -0000 --_000_6f082f1af6234f779cec63e50baadfa3EXMBX31adutwentenl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Telemaco, Hi Sri, Sorry for the delay on sending my comments on the draft-ietf-netext-logical= -interface-support-09. Here are my comments! First of all I would like to mention that the draft is useful for the IETF,= since it provides a solution in the context of Proxy Mobile IPv6 that can = be used to afford inter-technology handover, multihoming, and/or flow mobi= lity without requiring from the mobile node IP stack specific support to th= at effect. My comments are: Comment_1: Emphasize in the Applicability Statement section (3.2) the main = differences between the work provided by this document and the work done in= IETF Multiple Interfaces (mif) WG! Comment_2: Section 6.3: Provide a figure that can be used to describe the F= low Mobility Support scenario more clearly. Comment_3: Section 6.3: In the second paragraph of this section, emphasize = that the mechanisms required by the LMA to decide on which is the best MAG = to be used for the forwarding of a particular flow is out of the scope of t= his document. Comment_4: Provide a caption to Figure 2. Comment_5: The document contains many editorials. The main ones are: Section 3.1, page 5, first bullet: please include an empty space between "S= ystem" and "[TS23401]". Section 3.1, page 5, second bullet, the word "that" is used twice in sequen= ce, please remove one of them ("A logical interface denotes a mechanism tha= t that logically" Section 5.2,page 10, the paragraph should be ended with a "."! ("are depict= ed in Figure 2.") Best regards, Georgios De : netext [mailto:netext-bounces@ietf.org] De la part de karagian@cs.utwe= nte.nl Envoy? : vendredi 1 ao?t 2014 09:11 ? : rajeev.koodli@gmail.com; netext@ietf.org Cc : netext-chairs@ietf.org Objet : Re: [netext] Interest to review the Logical Interface ID Hi Rajeev, Please note that I am interested in reviewing the draft! However, please note that this will happen after the 15th of August! Best regards, Georgios ________________________________ Van: netext [netext-bounces@ietf.org] namens Rajeev Koodli [rajeev.koodli@g= mail.com] Verzonden: donderdag 31 juli 2014 3:02 Aan: netext@ietf.org Onderwerp: [netext] Interest to review the Logical Interface ID Hi, as discussed at the Toronto meeting, we are looking for at least three peop= le who are interested in reviewing the ID: http://tools.ietf.org/html/draft= -ietf-netext-logical-interface-support-09 Please respond if you are interested, and Cc the chairs: netext-chairs@ietf= .org Thanks. -Rajeev ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6f082f1af6234f779cec63e50baadfa3EXMBX31adutwentenl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Telemaco, Hi Sri,

 

Sorry for the delay on sending my comments o= n the draft-ietf-netext-logical-interface-support-09.
Here are my comments!


First of all I would like to mention that the draft is useful for the IETF,= since it provides a solution in the context of Proxy Mobile IPv6 that can = be used to afford inter-technology handover, multihoming, and/or  flow= mobility without requiring from the mobile node IP stack specific support to that effect.

 

My comments are:

 

Comment_1: Emphasize in the Applicability St= atement section (3.2) the main differences between the work provided by thi= s document and the work done in IETF Multiple Interfaces (mif) WG!

 
Comment_2: Section 6.3: Provide a figure that can be used to describe the F= low Mobility Support scenario more clearly.

 

Comment_3: Section 6.3: In the second paragr= aph of this section, emphasize that the mechanisms required by the LMA to d= ecide on which is the best MAG to be used for the forwarding of a particula= r flow is out of the scope of this document.

 

Comment_4: Provide a caption to Figure 2.

 

Comment_5: The document contains many editor= ials. The main ones are:

Section 3.1, page 5, first bullet: please in= clude an empty space between "System" and "[TS23401]".<= /p>

 

Section 3.1, page 5, second bullet, the word= "that" is used twice in sequence, please remove one of them (&qu= ot;A logical interface denotes a mechanism that that logically"

 

Section 5.2,page 10, the paragraph should be= ended with a "."! ("are depicted in Figure 2.")

 

Best regards,
Georgios

 

De : = netext [mailto:netext-bounces@ietf.org] De la part de karagian@cs.utwente.nl
Envoyé : vendredi 1 août 2014 09:11
À : rajeev.koodli@gmail.com; netext@ietf.org
Cc : netext-chairs@ietf.org
Objet : Re: [netext] Interest to review the Logical Interface I= D

 

Hi Rajeev,

 

Please note that I am interested in reviewin= g the draft!

However, please note that this will happen a= fter the 15th of August!

 

Best regards,

Georgios

Van: netext [netext-bounce= s@ietf.org] namens Rajeev Koodli [rajeev.koodli@gmail.com]
Verzonden: donderdag 31 juli 2014 3:02
Aan: netext@ietf.org
Onderwerp: [netext] Interest to review the Logical Interface ID

 

Hi,

 

as discussed at the To= ronto meeting, we are looking for at least three people who are interested = in reviewing the ID: http://tools.ietf.or= g/html/draft-ietf-netext-logical-interface-support-09

 

Please respond if you = are interested, and Cc the chairs: netext-chairs@i= etf.org

 

Thanks.

 

-Rajeev

 

 

______________________________________________________________________=
___________________________________________________=0A=
=0A=
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc=0A=
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler=0A=
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,=0A=
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.=0A=
=0A=
This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;=0A=
they should not be distributed, used or copied without authorisation.=0A=
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.=0A=
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.=0A=
Thank you.=0A=
--_000_6f082f1af6234f779cec63e50baadfa3EXMBX31adutwentenl_--