Hello all

http://www.ietf.org/proceedings/89= /minutes/minutes-89-mif

Please feel free t= o let us know whether any revision is needed.

thanks a lot

-cochairs

--20cf307f32569ec90904f4bb1803-- From nobody Mon Mar 24 03:02:35 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 583461A018A for ; Mon, 24 Mar 2014 03:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_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 INTsYWxXAews for ; Mon, 24 Mar 2014 03:02:28 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 46D7C1A0186 for ; Mon, 24 Mar 2014 03:02:28 -0700 (PDT) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MU0ld-1WbCn61pyL-00QvJj; Mon, 24 Mar 2014 06:02:26 -0400 From: Alper Yegin Content-Type: multipart/alternative; boundary="Apple-Mail=_F78EE642-64B3-4CF4-8386-45EAD4DDF3A6" Date: Mon, 24 Mar 2014 12:02:18 +0200 Message-Id: <53E93173-D69F-492C-9ABB-643AF53CB27D@yegin.org> To: mif@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:mOFaENIUb/Y+O0/pbd9jJY7ophgRvMnJIYQ+mlRLOPN ZhUijCf+l4jU73llUyZN3wGkZLX+I1dbU122iGRUXAJ0NLjyLx gLjLMYmk0Dh2D8bqKkS/d8iWPed0vc5mr7vGrON62b4RBFHZSX LWgRSgvsCMB0+FfJnsaEezJvZ/fGYvZetn4Lekn6lvIFMpNaxQ LC3pbl7O4hnOLhHoLZxXFsh2xMHWpPLbVYGNQ3JyQwIKrkxeGR 1u4s4lex2trJ6CAGS+wAZS9SFgW5jPk3wHrcu8BXq03g3Ff4xp EdwCeQJLDDO2OxQ2v/mh5YU4eyRgYAKsqBA3lz/iWEO87wS9A0 X+UevDaN85SuIXXynTVIQUCAUmlB0NW54ZAFrSZy8XU1pKBpfP 7Ql52LMpP0Kmg== Archived-At: http://mailarchive.ietf.org/arch/msg/mif/Pvem-OkaOpTE0tuaT0oDUmhIu8o Subject: [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: Mon, 24 Mar 2014 10:02:31 -0000 --Apple-Mail=_F78EE642-64B3-4CF4-8386-45EAD4DDF3A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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 = interfaces, as if the auth issue only arises in that case. Auth/z issues arise even with single PVD over single interface case.=20 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/configuration parameters) in fact is very doable, and commonly = used in wireless 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 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 = parameters come from. Now, how we select the DNS server to use becomes the key issue=85 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 = standardized? 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 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 = 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 =20 --Apple-Mail=_F78EE642-64B3-4CF4-8386-45EAD4DDF3A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Helo = folks,

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

Typical examples of = information in a provisioning domain, learned

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

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

Implicit PVDs are = limited to network configuration information

often also be scoped to a = configuration related to a particular

interface, = however per this architecture there is no such requirement

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 interfaces, 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

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 wireless networks.

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

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

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

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.

PVDs providing connectivity to the = Internet, and the node desires to

maximize chances for = connectivity in Happy Eyeballs style. In this

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 = 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

from which the lookup results were = obtained.

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=85

An attempt to use such = PVD may lead to limited network connectivity

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

using it to = serve network connection requests of the applications.

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

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

hard requirements and soft = preferences. The node performs PVD

selection, = based on applications inputs and policies and/or user

exposed to = applications.

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

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 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.

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

= --Apple-Mail=_F78EE642-64B3-4CF4-8386-45EAD4DDF3A6--