From nobody Wed Apr 2 20:39:44 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7034F1A00AB for ; Wed, 2 Apr 2014 20:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 DRBzHxHf7BXr for ; Wed, 2 Apr 2014 20:39:33 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0139.outbound.protection.outlook.com [207.46.163.139]) by ietfa.amsl.com (Postfix) with ESMTP id 15CAF1A00A3 for ; Wed, 2 Apr 2014 20:39:32 -0700 (PDT) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB080.namprd03.prod.outlook.com (10.255.175.156) with Microsoft SMTP Server (TLS) id 15.0.898.11; Thu, 3 Apr 2014 03:39:26 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.128]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.130]) with mapi id 15.00.0898.005; Thu, 3 Apr 2014 03:39:26 +0000 From: Dmitry Anipko To: Alper Yegin , "mif@ietf.org" Thread-Topic: [mif] Comments on mif-pvd-arch Thread-Index: AQHPR0gx+m72Kgvge0CUY6/4Q6hMJ5r/RbDg Date: Thu, 3 Apr 2014 03:39:25 +0000 Message-ID: <38dc9508d2534d9d80947427e321a16f@SN2PR03MB077.namprd03.prod.outlook.com> References: <53E93173-D69F-492C-9ABB-643AF53CB27D@yegin.org> In-Reply-To: <53E93173-D69F-492C-9ABB-643AF53CB27D@yegin.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] x-forefront-prvs: 0170DAF08C x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(199002)(189002)(74706001)(56776001)(54356001)(98676001)(86362001)(74366001)(59766001)(93136001)(86612001)(51856001)(54316002)(93516002)(53806001)(81342001)(4396001)(74876001)(81686001)(2656002)(50986001)(87266001)(79102001)(77982001)(69226001)(99286001)(94946001)(74316001)(85852003)(87936001)(47976001)(81542001)(19580395003)(77096001)(97336001)(83322001)(83072002)(81816001)(74662001)(95666003)(90146001)(85306002)(97186001)(63696002)(47736001)(76796001)(74502001)(31966008)(95416001)(46102001)(80022001)(76786001)(49866001)(19580405001)(65816001)(80976001)(15202345003)(16236675002)(15975445006)(47446002)(56816005)(20776003)(76482001)(99396002)(76576001)(19300405004)(92566001)(94316002)(33646001)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB080; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:EC30F066.A4FA93D1.B1D13DBB.1AEDF841.2070E; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_38dc9508d2534d9d80947427e321a16fSN2PR03MB077namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/mif/9vLs8x4RoydnXz7TZwitdBFO1qQ Subject: Re: [mif] Comments on mif-pvd-arch X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 03:39:40 -0000 --_000_38dc9508d2534d9d80947427e321a16fSN2PR03MB077namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Alper, Thank you for the comments. >> Default IP gateway deserves to be mentioned here. I believe this topic was raised during the last meeting (in the context of = single RA having info on multiple PVDs), and it seems to me there was an ag= reement that it is a valid requirement, though not fully clear to me, wheth= er it can be implemented w/o protocol changes / new options (but perhaps, t= he latter doesn't have to be discussed in the arch doc). I can add this tex= t in the next revision, though I want to note, that it might re-open the co= ntroversy of "DHCP route option". >> This text mentions auth in the context of using PVD ID across multiple i= nterfaces, as if the auth issue only arises in that case. Auth/z issues arise even with single PVD over single interface case. I'll clarify this. >> Yes, we can declare this out-of scope for this document. But this (s/PVD= s/configuration parameters) in fact is very doable, and commonly used in wi= reless networks. If you're referring to the advertisement of different info to different nod= es, is there a specific text you'd suggest to be included as opposed to the= current out-of-scope? >> This is already available with RA and DHCP today. Can you suggest a specific reference to the corresponding mechanisms in RA/= DHCP? >> This is not trivial. If using serial lookup, how is the order determined= ? If using parallel lookup, one can get multiple answers, in which case how d= oes the selection work? In either case, are we not back to the original problem? There is at least one way, in which the host could avoid ambiguity - use a = specific PVD, per configured policy, for particular destinations, and use o= ne at a time for generic Internet (for example, based on available connecti= vity cost information)****. I can add a reference to that as an example, if= you think that helps. Outside of that, I think we won't converge in this = document, if we try to prescribe a particular host behavior, to fully cover= complicated cases, because different hosts may have different business nee= ds. The original problem had multiple parts. One part is that w/o information f= rom the network, it's generally not possible to know, which network config= uration elements are OK to be used together, and which aren't. The explicit= MPVDs, in my opinion, first of all solve this problem. After that it is st= ill up to the host, how exactly they want to use the multiple connections t= hat they have - but now they can do it in a more structured way. >> So, the DNS server used for lookup dictates where the rest of the config= parameters come from. Now, how we select the DNS server to use becomes the key issue... Not necessarily, in some cases, it could be a proxy server, or a policy, wh= ich prescribes, that for a VOIP app, the particular network should be used.= DNS is just an example (which would be the common case). In those cases, w= here DNS is relevant, the PVD, from which the DNS server is taken, could be= selected based on the mechanism such as above (see ****). >> Given the current practices in the industry, do we still need something = standardized? Do you believe the specific mechanisms would belong to the arch doc? If the= re are particular examples, which are common, we could mention them as exam= ples. >>6.1 Basic (API) is more of a "No API support" (as in legacy apps case). It is expected that ~80% of apps, if not more, would fall into this categor= y, and hence it is important to call out the category. >> Can someone provide examples of requirements/preferences, for the sake o= f discussion and also elaboration in the text? I'll add a couple of sentences with example requirements. >> Is this exactly the same threat we are seeing today with the RA and DHCP= , or is the introduction of PVD-ID making a difference? I think there is a difference, because PVD-ID is making a claim that "the f= ollowing parameters are coming from Operator X". Which can be leveraged for= worse attacks. IMO, PVD makes a difference, because the original source of PVD info is pot= entially different from the router/DHCP server. So I agree with you, and I = think this is an open issue, for which I personally don't know a good solut= ion at this time. >> Or by a (crypto) binding between the L1/L2 and the configuration paramet= ers. Can you provide a bit more elaborated text? -Dmitry From: mif [mailto:mif-bounces@ietf.org] On Behalf Of Alper Yegin Sent: Monday, March 24, 2014 3:02 AM To: mif@ietf.org Subject: [mif] Comments on mif-pvd-arch Helo folks, I went over the draft, and here are my comments: Typical examples of information in a provisioning domain, learned from the network, are: source address prefixes that can be used by connections within the provisioning domain, IP address of DNS server, name of HTTP proxy server if available, DNS suffixes associated with the network etc. Default IP gateway deserves to be mentioned here. Implicit PVDs are limited to network configuration information received on a single interface. Explicit PVDs, in practice will often also be scoped to a configuration related to a particular interface, however per this architecture there is no such requirement or limitation and as defined in this architecture, explicit PVDs may include information related to more than one interfaces, if the node learns presence of the same PVD on those interfaces and the authentication of the PVD ID meets the level required by the node policy. This text mentions auth in the context of using PVD ID across multiple inte= rfaces, as if the auth issue only arises in that case. Auth/z issues arise even with single PVD over single interface case. Possible extensions, where different sets of PVDs may be advertised by the networks to different connected nodes, are out of scope of this document. Yes, we can declare this out-of scope for this document. But this (s/PVDs/c= onfiguration parameters) in fact is very doable, and commonly used in wirel= ess networks. After the PvD information is provided to the host it may be outdated or updated with newer information before the hosts would normally request updates. Thos would require the mchanism to be able to update and/or withdraw all (or some subset) of information related to a given PvD. For efficiency reasons, there should be a way to specify that all the information from the PvD needs to be reconfigured instead of individually updating each item associated with the PvD. This is already available with RA and DHCP today. The node may pick multiple PVDs, if e.g., they are general purpose PVDs providing connectivity to the Internet, and the node desires to maximize chances for connectivity in Happy Eyeballs style. In this case, the node could do the lookups in parallel, or in sequence. Alternatively, the node may use for the lookup only one PVD, based on the PVD connectivity properties, user choice of the preferred Internet PVD, etc. This is not trivial. If using serial lookup, how is the order determined? If using parallel lookup, one can get multiple answers, in which case how d= oes the selection work? In either case, are we not back to the original problem? In either case, by default the node uses information obtained in a name service lookup to establish connections only within the same PVD from which the lookup results were obtained. So, the DNS server used for lookup dictates where the rest of the config pa= rameters come from. Now, how we select the DNS server to use becomes the key issue... An attempt to use such PVD may lead to limited network connectivity or connection failures for applications. To prevent the latter, a PVD-aware node may perform connectivity test for the PVD, before using it to serve network connection requests of the applications. In current implementations, some nodes do that, for instance, by trying to reach a dedicated web server (e.g., see [RFC6419]). Given the current practices in the industry, do we still need something sta= ndardized? 6.1 Basic (API) is more of a "No API support" (as in legacy apps case). 6.2. Intermediate Applications indirectly participate in selection of PVD by specifying hard requirements and soft preferences. The node performs PVD selection, based on applications inputs and policies and/or user preferences. Some / all properties of the resultant PVD may be exposed to applications. Can someone provide examples of requirements/preferences, for the sake of d= iscussion and also elaboration in the text? 7.2.2. PVDs trusted by attachment Not that I expect this to be written down in the draft, but I think this'd = have more applicability than the PSK and CERT-based approaches. Even DHCP i= s secured this way today (not via DHCP AUTH). Tampering with configuration information provided An attacker may attempt to modify the information provided inside the PVD container option. Is this exactly the same threat we are seeing today with the RA and DHCP, o= r is the introduction of PVD-ID making a difference? I think there is a difference, because PVD-ID is making a claim that "the f= ollowing parameters are coming from Operator X". Which can be leveraged for= worse attacks. Replay attacks A compromised configuration source or an on-link attacker may try to capture advertised configuration information and replay it on a different link or at a future point in time. This can be avoided by including some replay protection mechanism such as a timestamp or a nonce inside the PvD container to ensure freshness of the provided information. Or by a (crypto) binding between the L1/L2 and the configuration parameters= . Thank you Dmitry and the other folks who contributed to this I-D. Cheers, Alper --_000_38dc9508d2534d9d80947427e321a16fSN2PR03MB077namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Alper,

 <= /p>

Thank you for the comment= s.

 <= /p>

>> Default IP gateway deserves to = be mentioned here.

 <= /p>

I believe this topic was = raised during the last meeting (in the context of single RA having info on = multiple PVDs), and it seems to me there was an agreement that it is a valid requirement, though not fully clear to me, whether it c= an be implemented w/o protocol changes / new options (but perhaps, the latt= er doesn’t have to be discussed in the arch doc). I can add this text= in the next revision, though I want to note, that it might re-open the controversy of “DHCP route option= 221;.

 <= /p>

>> This text mentions auth in the = context of using PVD ID across multiple interfaces, as if the auth issue only arises in that case.

Auth/z issues arise even with single PVD over single interface case. =

 <= /p>

I’ll clarify this.<= o:p>

 <= /p>

>> Yes, we can declare this out-of= scope for this document. But this (s/PVDs/configuration parameters) in fact is very doable, and commonly used in wireless networks.=

 <= /p>

If you’re referring to the advertisement of different info to diff= erent nodes, is there a specific text you’d suggest to be included as opposed to the current out-of-scope?

 <= /p>

>> This is already available with = RA and DHCP today.

 <= /p>

Can you suggest a specifi= c reference to the corresponding mechanisms in RA/DHCP?

 <= /p>

>> This is not trivial. If using s= erial lookup, how is the order determined?

If using parallel lookup, one can get multiple answers, in which case how = does the selection work?

In either case, are we not back to the original problem?=

 <= /p>

There is at least one way= , in which the host could avoid ambiguity – use a specific PVD, per c= onfigured policy, for particular destinations, and use one at a time for generic Internet (for example, based on available connectivity = cost information)****. I can add a reference to that as an example, if you = think that helps.  Outside of that, I think we won’t converge in= this document, if we try to prescribe a particular host behavior, to fully cover complicated cases, because different hosts m= ay have different business needs.

 <= /p>

The original problem had = multiple parts. One part is that w/o information from the network, it’= ;s generally not  possible to know, which network configuration elements are OK to be used together, and which aren’t. The explicit = MPVDs, in my opinion, first of all solve this problem. After that it is sti= ll up to the host, how exactly they want to use the multiple connections th= at they have – but now they can do it in a more structured way.

 <= /p>

>> So, the DNS server used for loo= kup dictates where the rest of the config parameters come from.<= /span>

Now, how we select the DNS server to use becomes the key issue…=

 

Not necessarily, in some = cases, it could be a proxy server, or a policy, which prescribes, that for = a VOIP app, the particular network should be used. DNS is just an example (which would be the common case). In those cases, where DN= S is relevant, the PVD, from which the DNS server is taken, could be select= ed based on the mechanism such as above (see ****).

 <= /p>

>> Given the current practices in = the industry, do we still need something standardized?

 <= /p>

Do you believe the specif= ic mechanisms would belong to the arch doc? If there are particular example= s, which are common, we could mention them as examples.

 <= /p>

>>6.1 Basic (API) is more of a &qu= ot;No API support" (as in legacy apps case).

 <= /p>

It is expected that ~80% = of apps, if not more, would fall into this category, and hence it is import= ant to call out the category.

 <= /p>

>> Can someone provide examples of= requirements/preferences, for the sake of discussion and also elaboration in the text?

 <= /p>

I’ll add a couple o= f sentences with example requirements.

 <= /p>

>> Is this exactly the same threat= we are seeing today with the RA and DHCP, or is the introduction of PVD-ID making a difference?

I think there is a difference, because PVD-ID is making a claim that "= ;the following parameters are coming from Operator X". Which can be le= veraged for worse attacks.

 <= /p>

IMO, PVD makes a differen= ce, because the original source of PVD info is potentially different from t= he router/DHCP server. So I agree with you, and I think this is an open issue, for which I personally don’t know a good solu= tion at this time.

 <= /p>

>> Or by a (crypto) binding betwee= n the L1/L2 and the configuration parameters.

 <= /p>

Can you provide a bit mor= e elaborated text?

 <= /p>

-Dmitry=

 <= /p>

From: mif [m= ailto:mif-bounces@ietf.org] On Behalf Of Alper Yegin
Sent: Monday, March 24, 2014 3:02 AM
To: mif@ietf.org
Subject: [mif] Comments on mif-pvd-arch

 

Helo folks,

 

I went over the draft, and here are my comments:

 

   Typical examples of information in a provisioning domain, lea= rned

   from the network, are: source address prefixes that can be us= ed by

   connections within the provisioning domain, IP address of DNS= server,

   name of HTTP proxy server if available, DNS suffixes associat= ed with

   the network etc.

 

Default IP gateway deserves to be mentioned here.

 

 

   Implicit PVDs are limited to network configuration informatio= n

   received on a single interface.  Explicit PVDs, in pract= ice will

   often also be scoped to a configuration related to a particul= ar

   interface, however per this architecture there is no such req= uirement

   or limitation and as defined in this architecture, explicit P= VDs may

   include information related to more than one interfaces, if t= he node

   learns presence of the same PVD on those interfaces and the

   authentication of the PVD ID meets the level required by the = node

   policy.

 

This text mentions auth in the context of using PVD ID across multiple int= erfaces, as if the auth issue only arises in that case.

Auth/z issues arise even with single PVD over single interface case. =

 

 

   Possible extensions, where different sets of PVDs may be adve= rtised

   by the networks to different connected nodes, are out of scop= e of

   this document.

 

Yes, we can declare this out-of scope for this document. But this (s/PVDs/= configuration parameters) in fact is very doable, and commonly used in wire= less networks.

 

 

   After the PvD information is provided to the host it may be o= utdated

   or updated with newer information before the hosts would norm= ally

   request updates.  Thos would require the mchanism to be = able to

   update and/or withdraw all (or some subset) of information re= lated to

   a given PvD. For efficiency reasons, there should be a way to= specify

   that all the information from the PvD needs to be reconfigure= d

   instead of individually updating each item associated with th= e PvD.

 

This is already available with RA and DHCP today.

 

 

 

   The node may pick multiple PVDs, if e.g., they are general pu= rpose

   PVDs providing connectivity to the Internet, and the node des= ires to

   maximize chances for connectivity in Happy Eyeballs style.&nb= sp; In this

   case, the node could do the lookups in parallel, or in sequen= ce.

   Alternatively, the node may use for the lookup only one PVD, = based on

   the PVD connectivity properties, user choice of the preferred=

   Internet PVD, etc.

 

 

This is not trivial. If using serial lookup, how is the order determined?<= o:p>

If using parallel lookup, one can get multiple answers, in which case how = does the selection work?

In either case, are we not back to the original problem?=

 

 

   In either case, by default the node uses information obtained= in a

   name service lookup to establish connections only within the = same PVD

   from which the lookup results were obtained.

 

So, the DNS server used for lookup dictates where the rest of the config p= arameters come from.

Now, how we select the DNS server to use becomes the key issue…=

 

 

   An attempt to use such PVD may lead to limited network connec= tivity

   or connection failures for applications.  To prevent the= latter, a

   PVD-aware node may perform connectivity test for the PVD, bef= ore

   using it to serve network connection requests of the applicat= ions.

   In current implementations, some nodes do that, for instance,= by

   trying to reach a dedicated web server (e.g., see [RFC6419]).=

 

 

Given the current practices in the industry, do we still need something st= andardized?

 

 

6.1 Basic (API) is more of a "No API support" (as in legacy apps= case).

 

 

 

6.2.  Intermediate

 

   Applications indirectly participate in selection of PVD by sp= ecifying

   hard requirements and soft preferences.  The node perfor= ms PVD

   selection, based on applications inputs and policies and/or u= ser

   preferences.  Some / all properties of the resultant PVD= may be

   exposed to applications.

 

 

Can someone provide examples of requirements/preferences, for the sake of = discussion and also elaboration in the text?

 

 

 

7.2.2.  PVDs trusted by attachment

 

Not that I expect this to be written down in the draft, but I think this'd= have more applicability than the PSK and CERT-based approaches. Even DHCP = is secured this way today (not via DHCP AUTH).

 

 

 

      Tampering with configuration information provided An = attacker may

      attempt to modify the information provided inside the= PVD

      container option.

 

Is this exactly the same threat we are seeing today with the RA and DHCP, = or is the introduction of PVD-ID making a difference?

I think there is a difference, because PVD-ID is making a claim that "= ;the following parameters are coming from Operator X". Which can be le= veraged for worse attacks.

 

 

      Replay attacks A compromised configuration sourc= e or an on-link

      attacker may try to capture advertised configuration = information

      and replay it on a different link or at a future poin= t in time.

      This can be avoided by including some replay protecti= on mechanism

      such as a timestamp or a nonce inside the PvD contain= er to ensure

      freshness of the provided information.

 

Or by a (crypto) binding between the L1/L2 and the configuration parameter= s.

 

 

Thank you Dmitry and the other folks who contributed to this I-D.

 

Cheers,

 

Alper

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

--_000_38dc9508d2534d9d80947427e321a16fSN2PR03MB077namprd03pro_-- From nobody Tue Apr 22 06:51:28 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD3E1A047D for ; Tue, 22 Apr 2014 06:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 AYIoZwMWtcBn for ; Tue, 22 Apr 2014 06:51:26 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id A309A1A0476 for ; Tue, 22 Apr 2014 06:51:25 -0700 (PDT) Received: from ians-mbp.lan ([62.225.30.33]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MfEMs-1WIAZ100M6-00Or1d; Tue, 22 Apr 2014 15:50:33 +0200 From: Ian Farrer Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <6132CAD1-AE3A-45F5-A718-88D0060FFD57@gmx.com> Date: Tue, 22 Apr 2014 15:50:31 +0200 To: draft-ietf-mif-mpvd-arch@tools.ietf.org, mif@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Provags-ID: V03:K0:hj7XLh5pJgef0wuuILlnrUhDW5u1wCUegrXl5lK4c3FofsQqQ5t yrvDu6rDAxzVm9g9Ou08lZ8fc9FmKU+Vmv49/CNA8K/0tjDtXpC0oGFk1UqdM9C/EsCK6of tqUpWTrzeoFp5M9UHSwZxUwQ0losRAk3VvFA5cgY4ih6lpo1LIFXLNTin30W1f6uqMMSRdM 9PqX+oarFSpRgX6fWJfIA== Archived-At: http://mailarchive.ietf.org/arch/msg/mif/lpm6xZaAvqnsh2Ku3PBT2eq1MzY Subject: [mif] Review of mif-mpvd-arch-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2014 13:51:28 -0000 Hi, I have reviewed of the current draft. Overall, I think it=92s a great = document.=20 Below are some comments and questions. Cheers, Ian Section 2.1 It could be worth making the point that the specific mechanism by which = a PvD is learnt is not related to the PvD itself. (i.e. that PvDs are = globally scoped on the host and there is no 'DHCP learnt PvD table', 'RA = learnt PvD table' etc.)=20 Section 2.2 i) (Raised in London) For mobile, if there's a WLAN and a 4G bearer, = then assuming that they are in different implicit PvDs is probably a = good starting point. Likewise, it works for a HGW which is essentially a = 2-port router (LAN side/WAN side). Where it breaks down is if the HGW is = actually a multi-port router, which is the where the Homenet = architecture is going. In this case, an upstream interface to the SP is = one PvD, but the other interfaces (in all likelihood) belong to the same = PvD. Could the logic for identifying implicit PvDs be improved for multi-port = router? e.g. if routing advertisements from the same routing protocol = (e.g. OSPF LSA with the same Area-ID) were received on more than one = interface, these could be put into the same implicit PVD. There's = probably some other mechanisms that could be used as well. ii) Do implicit PVDs only have local scope, or could they be advertised = to other hosts (where they would be explicit)? Should these be at the interface level, or is finer granularity = necessary (e.g. at the prefix level)? iii) Alignment between sections 2.2 and 2.3 (raised in London). 2.2 = describes creating implicit PvDs for configuration raised on multiple = interfaces. 2.3 states 'Implicit PVDs are limited to network = configuration information received on a single interface.' I guess that the 2.3 wording is meant to be correct. Section 2.4=20 IMHO, It would be better to say 'locally generated with a high = probability of being globally unique' rather than 'locally generated = globally unique' as ensuring actual global uniqueness here is cumbersome = and unnecessary. Section 3.3=20 "Extensions and RAs should be defined in such a manner than unmodified = hosts (i.e. hosts not aware of PvDs) will continue to function as well = as they did before the PvD information got added." Does this mean that (to use a DHCP example), if an IA_PD is received = with some associated PvD information, and the client is not PvD aware, = then it should ignore the PvD information and use the delegated prefix = (which is how it would work if you sent multiple PDs at the moment), or = should it discard PDs with PVD info altogether? I think it's got to be the second of the two, otherwise something that = is currently a problem continues to be a problem. 3.4 By default, a configuration source SHOULD provide information = related to all provisioning domains without expecting the client to = select the PvD(s) it requires. Is the word 'select' correct in this sentence? In context, 'request' = would be a better word. This section also implies that PVD information should be encoded in such = a way that just the PVD info could be discarded, but the provisioned = information is retained by the client. See 3.3 comment above. From nobody Wed Apr 30 21:08:30 2014 Return-Path: X-Original-To: mif@ietfa.amsl.com Delivered-To: mif@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA901A09AD for ; Wed, 30 Apr 2014 21:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 10wigFG2bN0o for ; Wed, 30 Apr 2014 21:08:16 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD781A09B9 for ; Wed, 30 Apr 2014 21:08:16 -0700 (PDT) Received: from SN2PR03MB077.namprd03.prod.outlook.com (10.255.175.153) by SN2PR03MB079.namprd03.prod.outlook.com (10.255.175.155) with Microsoft SMTP Server (TLS) id 15.0.929.12; Thu, 1 May 2014 04:08:07 +0000 Received: from SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.26]) by SN2PR03MB077.namprd03.prod.outlook.com ([169.254.14.26]) with mapi id 15.00.0934.000; Thu, 1 May 2014 04:08:07 +0000 From: Dmitry Anipko To: "ianfarrer@gmx.com" , "mif@ietf.org" Thread-Topic: [mif] Review of mif-mpvd-arch-00 Thread-Index: Ac9k8uHBftlibNDORGuHcUS9eQAsFQ== Date: Thu, 1 May 2014 04:08:06 +0000 Message-ID: <72f3c08bf7f04360b48e8c9c7b0af3d6@SN2PR03MB077.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::5] x-forefront-prvs: 01986AE76B x-forefront-antispam-report: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(74316001)(99286001)(81542001)(83322001)(99396002)(80976001)(15975445006)(4396001)(16236675002)(87936001)(76482001)(80022001)(20776003)(81342001)(19580395003)(76576001)(46102001)(54356999)(15202345003)(77982001)(85852003)(86362001)(101416001)(19300405004)(92566001)(2656002)(31966008)(50986999)(33646001)(74662001)(74502001)(83072002)(3826001)(24736002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB079; H:SN2PR03MB077.namprd03.prod.outlook.com; FPR:EEE1F255.ABEAD312.33DDB28B.8EE8DC41.20563; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (: microsoft.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_72f3c08bf7f04360b48e8c9c7b0af3d6SN2PR03MB077namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/mif/oy8tGz7TaOgQxpTyDAO2iG-RcvU Subject: [mif] Review of mif-mpvd-arch-00 X-BeenThere: mif@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multiple Interface Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 May 2014 04:08:24 -0000 --_000_72f3c08bf7f04360b48e8c9c7b0af3d6SN2PR03MB077namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ian thanks for the review. Sorry for breaking the thread, the original message didn't make to my mailb= ox for some reason, so I'm replying to a copy-paste from the mailing list a= rchive. >>Section 2.1 >>It could be worth making the point that the specific mechanism by which a= PvD is learnt is not related to the PvD itself. (i.e. that PvDs are global= ly scoped on the host and there is no 'DHCP learnt PvD table', 'RA learnt P= vD table' etc.) [danipko] OK, assuming there are no objections from the WG members. >>Section 2.2 >>i) (Raised in London) For mobile, if there's a WLAN and a 4G bearer, then= assuming that they are in different implicit PvDs is probably a good start= ing point. Likewise, it works for a HGW which is essentially a 2-port route= r (LAN side/WAN side). Where it breaks down is if the HGW is actually a mul= ti-port router, which is the where the Homenet architecture is going. In th= is case, an upstream interface to the SP is one PvD, but the other interfac= es (in all likelihood) belong to the same PvD. >>Could the logic for identifying implicit PvDs be improved for multi-port = router? e.g. if routing advertisements from the same routing protocol (e.g.= OSPF LSA with the same Area-ID) were received on more than one interface, = these could be put into the same implicit PVD. There's probably some other = mechanisms that could be used as well. [danipko] In that scenario, is the expectation that hosts participate in a = routing protocol? Or you're talking about internal HG routers? >>ii) Do implicit PVDs only have local scope, or could they be advertised t= o other hosts (where they would be explicit)? >>Should these be at the interface level, or is finer granularity necessary= (e.g. at the prefix level)? [danipko] I think both cases are possible. In some scenarios existing today (e.g. tethering from a Phone to a Tablet) = the configuration, which would be grouped into implicit PVDs, could be re-a= dvertised to other hosts w/o explicit PVD marking. Since MPVD architecture = doesn't prohibit such existing scenarios, on the final recepient the same c= onfiguration independently could be grouped into an implicit PVD. Separately, if the re-advertising device is PVD-aware and is capable of for= ming explicit PVDs from the original implicit based on some OOB information= I don't think this is prohibited, but I'm not sure we'd need to specify th= at either. >>iii) Alignment between sections 2.2 and 2.3 (raised in London). 2.2 descr= ibes creating implicit PvDs for configuration raised on multiple interfaces= . 2.3 states 'Implicit PVDs are limited to network configuration informatio= n received on a single interface.' >>I guess that the 2.3 wording is meant to be correct. [danipko] Correct, I will try to make the wording in 2.2 less confusing. >>Section 2.4 IMHO, It would be better to say 'locally generated with a high probability = of being globally unique' rather than 'locally generated globally unique' a= s ensuring actual global uniqueness here is cumbersome and unnecessary. [danipko] OK. >>Section 3.3 "Extensions and RAs should be defined in such a manner than unmodified host= s (i.e. hosts not aware of PvDs) will continue to function as well as they= did before the PvD information got added." >>Does this mean that (to use a DHCP example), if an IA_PD is received with= some associated PvD information, and the client is not PvD aware, then it = should ignore the PvD information and use the delegated prefix (which is ho= w it would work if you sent multiple PDs at the moment), or should it disca= rd PDs with PVD info altogether? >>I think it's got to be the second of the two, otherwise something that is= currently a problem continues to be a problem. [danipko] My understanding is that the principle is that the PVD-unaware cl= ient should be able to discard all PVD information. It doesn't necessarily = mean that it discards the complete packet - e.g. if there is non-PVD inform= ation in the same packet. Depending on the protocol, the extension could be= done in either way - either by adding PVD info together with non-PVD info = into single packet, or by adding more PVD-only packets. In either case, for that particular protocol, behavior of PVD-unaware clien= t should not be affected. In terms of your example, I think it would be the= former, not the latter. Can you elaborate on what you believe is the prole= m with the former? >>3.4 By default, a configuration source SHOULD provide information related= to all provisioning domains without expecting the client to select the PvD= (s) it requires. >>Is the word 'select' correct in this sentence? In context, 'request' woul= d be a better word. [danipko] OK. >>This section also implies that PVD information should be encoded in such = a way that just the PVD info could be discarded, but the provisioned inform= ation is retained by the client. See 3.3 comment above. [danipko] I think there may be confusing wording in the text, because I don= 't believe it was meant to say this. Can you point to the specific sentence= s, which you read in this way? Thank you, Dmitry --_000_72f3c08bf7f04360b48e8c9c7b0af3d6SN2PR03MB077namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ian thanks for the review.

 

Sorry for breaking the thread, the original message = didn't make to my mailbox for some reason, so I'm replying to a copy-paste = from the mailing list archive.

 

>>Section 2.1

>>It could be worth making the point that the = specific mechanism by which a PvD is learnt is not related to the PvD itsel= f. (i.e. that PvDs are globally scoped on the host and there is no 'DHCP le= arnt PvD table', 'RA learnt PvD table' etc.)

 

[danipko] OK, assuming there are no objections from = the WG members.

 

>>Section 2.2

>>i) (Raised in London) For mobile, if there's= a WLAN and a 4G bearer, then assuming that they are in different implicit = PvDs is probably a good starting point. Likewise, it works for a HGW which = is essentially a 2-port router (LAN side/WAN side). Where it breaks down is if the HGW is actually a multi-port router,= which is the where the Homenet architecture is going. In this case, an ups= tream interface to the SP is one PvD, but the other interfaces (in all like= lihood) belong to the same PvD.

>>Could the logic for identifying implicit PvD= s be improved for multi-port router? e.g. if routing advertisements from th= e same routing protocol (e.g. OSPF LSA with the same Area-ID) were received= on more than one interface, these could be put into the same implicit PVD. There's probably some other mechanisms = that could be used as well.

 

[danipko] In that scenario, is the expectation that = hosts participate in a routing protocol?  Or you're talking about inte= rnal HG routers?

 

>>ii) Do implicit PVDs only have local scope, = or could they be advertised to other hosts (where they would be explicit)?<= o:p>

>>Should these be at the interface level, or i= s finer granularity necessary (e.g. at the prefix level)?

 

[danipko] I think both cases are possible.

In some scenarios existing today (e.g. tethering fro= m a Phone to a Tablet) the configuration, which would be grouped into impli= cit PVDs, could be re-advertised to other hosts w/o explicit PVD marking. S= ince MPVD architecture doesn't prohibit such existing scenarios, on the final recepient the same configuration ind= ependently could be grouped into an implicit PVD.

Separately, if the re-advertising device is PVD-awar= e and is capable of forming explicit PVDs from the original implicit based = on some OOB information I don't think this is prohibited, but I'm not sure = we'd need to specify that either.

 

>>iii) Alignment between sections 2.2 and 2.3 = (raised in London). 2.2 describes creating implicit PvDs for configuration = raised on multiple interfaces. 2.3 states 'Implicit PVDs are limited to net= work configuration information received on a single interface.'

>>I guess that the 2.3 wording is meant to be = correct.

 

[danipko] Correct, I will try to make the wording in= 2.2 less confusing.

 

>>Section 2.4

IMHO, It would be better to say 'locally generated w= ith a high probability of being globally unique' rather than 'locally gener= ated globally unique' as ensuring actual global uniqueness here is cumberso= me and unnecessary.

 

[danipko] OK.

 

>>Section 3.3

"Extensions and RAs should be defined in such a= manner than unmodified hosts (i.e.  hosts not aware of PvDs) will con= tinue to function as well as they did before the PvD information got added.= "

>>Does this mean that (to use a DHCP example),= if an IA_PD is received with some associated PvD information, and the clie= nt is not PvD aware, then it should ignore the PvD information and use the = delegated prefix (which is how it would work if you sent multiple PDs at the moment), or should it discard PDs wit= h PVD info altogether?

>>I think it's got to be the second of the two= , otherwise something that is currently a problem continues to be a problem= .

 

[danipko] My understanding is that the principle is = that the PVD-unaware client should be able to discard all PVD information. = It doesn't necessarily mean that it discards the complete packet - e.g. if = there is non-PVD information in the same packet. Depending on the protocol, the extension could be done in eit= her way - either by adding PVD info together with non-PVD info into single = packet, or by adding more PVD-only packets.

In either case, for that particular protocol, behavi= or of PVD-unaware client should not be affected. In terms of your example, = I think it would be the former, not the latter. Can you elaborate on what y= ou believe is the prolem with the former?

 

>>3.4 By default, a configuration source SHOUL= D provide information related to all provisioning domains without expecting= the client to select the PvD(s) it requires.

>>Is the word 'select' correct in this sentenc= e? In context, 'request' would be a better word.

 

[danipko] OK.

 

>>This section also implies that PVD informati= on should be encoded in such a way that just the PVD info could be discarde= d, but the provisioned information is retained by the client. See 3.3 comme= nt above.

 

[danipko] I think there may be confusing wording in = the text, because I don't believe it was meant to say this. Can you point t= o the specific sentences, which you read in this way?

 

Thank you,

Dmitry

--_000_72f3c08bf7f04360b48e8c9c7b0af3d6SN2PR03MB077namprd03pro_--