Re: [mif-arch-dt] New Version Notification for draft-anipko-mif-mpvd-arch-00.txt
Dmitry Anipko <Dmitry.Anipko@microsoft.com> Sat, 20 July 2013 01:49 UTC
Return-Path: <Dmitry.Anipko@microsoft.com>
X-Original-To: mif-arch-dt@ietfa.amsl.com
Delivered-To: mif-arch-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB67D11E81AA for <mif-arch-dt@ietfa.amsl.com>; Fri, 19 Jul 2013 18:49:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.433
X-Spam-Level:
X-Spam-Status: No, score=0.433 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JSF7Qp9uoR4 for <mif-arch-dt@ietfa.amsl.com>; Fri, 19 Jul 2013 18:49:31 -0700 (PDT)
Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id DF5CE11E818B for <mif-arch-dt@ietf.org>; Fri, 19 Jul 2013 18:49:30 -0700 (PDT)
Received: from mail60-db9-R.bigfish.com (10.174.16.238) by DB9EHSOBE001.bigfish.com (10.174.14.64) with Microsoft SMTP Server id 14.1.225.22; Sat, 20 Jul 2013 01:49:29 +0000
Received: from mail60-db9 (localhost [127.0.0.1]) by mail60-db9-R.bigfish.com (Postfix) with ESMTP id 8E08AE0280 for <mif-arch-dt@ietf.org>; Sat, 20 Jul 2013 01:49:29 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:autodiscover.service.exchange.microsoft.com; EFVD:NLI
X-SpamScore: -20
X-BigFish: VS-20(zz9371I148cI542I1447Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL1de097h8275dhz2fh2a8h683h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh17ej9a9j1155h)
Received-SPF: pass (mail60-db9: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Dmitry.Anipko@microsoft.com; helo=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ;
X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT
Received: from mail60-db9 (localhost.localdomain [127.0.0.1]) by mail60-db9 (MessageSwitch) id 1374284967101574_16372; Sat, 20 Jul 2013 01:49:27 +0000 (UTC)
Received: from DB9EHSMHS002.bigfish.com (unknown [10.174.16.235]) by mail60-db9.bigfish.com (Postfix) with ESMTP id 0476BA004B for <mif-arch-dt@ietf.org>; Sat, 20 Jul 2013 01:49:27 +0000 (UTC)
Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by DB9EHSMHS002.bigfish.com (10.174.14.12) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 20 Jul 2013 01:49:23 +0000
Received: from am1outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.3.136.1; Sat, 20 Jul 2013 01:49:20 +0000
Received: from mail2-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE012.bigfish.com (10.3.207.134) with Microsoft SMTP Server id 14.1.225.22; Sat, 20 Jul 2013 01:49:14 +0000
Received: from mail2-am1 (localhost [127.0.0.1]) by mail2-am1-R.bigfish.com (Postfix) with ESMTP id B907526040D for <mif-arch-dt@ietf.org.FOPE.CONNECTOR.OVERRIDE>; Sat, 20 Jul 2013 01:49:14 +0000 (UTC)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(377454003)(51914003)(52604005)(199002)(189002)(13464003)(83322001)(56816003)(81542001)(76576001)(51856001)(16406001)(76786001)(76796001)(77982001)(54356001)(74502001)(74366001)(74662001)(79102001)(80022001)(76482001)(33646001)(74706001)(53806001)(65816001)(49866001)(59766001)(69226001)(81342001)(19580405001)(46102001)(47446002)(63696002)(47976001)(74876001)(31966008)(4396001)(83072001)(56776001)(54316002)(77096001)(50986001)(47736001)(74316001)(19580395003)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BN1PR03MB069; H:BN1PR03MB072.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::69; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail2-am1 (localhost.localdomain [127.0.0.1]) by mail2-am1 (MessageSwitch) id 1374284951432317_31765; Sat, 20 Jul 2013 01:49:11 +0000 (UTC)
Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.233]) by mail2-am1.bigfish.com (Postfix) with ESMTP id 656FD3A0047; Sat, 20 Jul 2013 01:49:11 +0000 (UTC)
Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sat, 20 Jul 2013 01:49:11 +0000
Received: from BN1PR03MB069.namprd03.prod.outlook.com (10.255.225.153) by BL2PRD0310HT001.namprd03.prod.outlook.com (10.255.97.36) with Microsoft SMTP Server (TLS) id 14.16.329.3; Sat, 20 Jul 2013 01:49:07 +0000
Received: from BN1PR03MB072.namprd03.prod.outlook.com (10.255.225.156) by BN1PR03MB069.namprd03.prod.outlook.com (10.255.225.153) with Microsoft SMTP Server (TLS) id 15.0.731.11; Sat, 20 Jul 2013 01:49:05 +0000
Received: from BN1PR03MB072.namprd03.prod.outlook.com ([169.254.9.65]) by BN1PR03MB072.namprd03.prod.outlook.com ([169.254.9.65]) with mapi id 15.00.0731.000; Sat, 20 Jul 2013 01:49:05 +0000
From: Dmitry Anipko <Dmitry.Anipko@microsoft.com>
To: Ted Lemon <Ted.Lemon@nominum.com>
Thread-Topic: [mif-arch-dt] New Version Notification for draft-anipko-mif-mpvd-arch-00.txt
Thread-Index: AQHOgYbt0yL6lN1HzUmnEc1YXXkThJlszJGQ
Date: Sat, 20 Jul 2013 01:49:04 +0000
Message-ID: <d6c8865484de4a94ace8cd6b875f18bc@BN1PR03MB072.namprd03.prod.outlook.com>
References: <20130714041913.29430.66253.idtracker@ietfa.amsl.com> <e7573b69f58a4f0b903cf7a3ae03cf48@SN2PR03MB077.namprd03.prod.outlook.com> <8D23D4052ABE7A4490E77B1A012B630775211E39@mbx-01.win.nominum.com>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775211E39@mbx-01.win.nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:ed31::69]
x-forefront-prvs: 0913EA1D60
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OrganizationHeadersPreserved: BN1PR03MB069.namprd03.prod.outlook.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-FOPE-CONNECTOR: Id%59$Dn%NOMINUM.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn%
X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com
X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com
X-OriginatorOrg: microsoft.com
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "mif-arch-dt@ietf.org" <mif-arch-dt@ietf.org>, Dmitry Anipko <Dmitry.Anipko@microsoft.com>
Subject: Re: [mif-arch-dt] New Version Notification for draft-anipko-mif-mpvd-arch-00.txt
X-BeenThere: mif-arch-dt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: MIF Architecture Design Team mailing list <mif-arch-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif-arch-dt>, <mailto:mif-arch-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif-arch-dt>
List-Post: <mailto:mif-arch-dt@ietf.org>
List-Help: <mailto:mif-arch-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif-arch-dt>, <mailto:mif-arch-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Jul 2013 01:49:38 -0000
Hi Ted, Thanks for the review and feedback. >> In section 2, I think you should say "classically" rather than "usually," because I think "usually" is true right now, but probably won't be in the future. OK. >> It might be better not to focus on that, and just talk about it in terms of a collection of information. >>So maybe something like this: Ok, I will update along these lines with slight modifications. >> In 4.2.1, I suggest the following change: OK. >> In 5.1, maybe the following change? OK, with an exception, that details about user interface would not be added. I'm concerned it can start a long and unconverging discussion (e.g. in-app interface vs outside of app interface - even in app interface could be provided by the OS without app knowledge), which I don't think will actually move the MPVD discussion forward. >> I'd like to see more text talking about the user interface aspect of this See my comment above. >> Section 5.3 suggests that the information configured by local policy or user interface is not visible to the application. Actually, that's not quite what I meant. What I meant to say is that the parameters, provided by application to affect PVD selection / enumeration, are only respected to the extent which node policies and user choice allows. E.g. node policy may prohibit certain PVD from being used and/or enumerated, and then that will be the behavior, no matter what app has to say. Whether or not those policies/user preferences by themselves are exposed to the app, is a different question to me, and 5.3 currently doesn't say anything about that - I will clarify the text. >>6.1 Untrusted PVDs OK, with one question. In " In order to avoid various forms of misinformation that can be asserted when PVDs are trusted, hosts that implement PVD separation cannot assume that two explicit PVDs with the same identifier are actually the same PVD." . Did you mean "when PVDs are NOT trusted"? I will include the text on trust into the draft as a starting point, but I fully expect that there are better security experts than myself on the team / MIF group, and I encourage review and feedback on the proposed trust schema. Thanks a lot for taking time to come up with suggestions, this is very helpful. I will rev the draft in the next few days (hopefully before the teleconf). Thank you, Dmitry -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Monday, July 15, 2013 11:12 AM To: Dmitry Anipko Cc: mif-arch-dt@ietf.org Subject: Re: [mif-arch-dt] New Version Notification for draft-anipko-mif-mpvd-arch-00.txt Observations about the document: In section 2, I think you should say "classically" rather than "usually," because I think "usually" is true right now, but probably won't be in the future. There's probably a better way to put it, but that's the point I think needs to be gotten across. I think also that the beginning of section 2 doesn't quite capture the definition of PVD because of the classical approach. It might be better not to focus on that, and just talk about it in terms of a collection of information. So maybe something like this: Provisioning Domain: a consistent set of network configuration information. Classically, the entire set available on a single interface is provided by a single source, such as network administrator, and can therefore be treated as a single provisioning domain. In modern IPv6 networks, multihoming can result in more than one provisioning domain being present on a single link. Typical examples of information in a provisioning domain, learned from the network, are: source address prefixes used on the link, IP address of DNS server, name of HTTP proxy server if available, DNS suffixes associated with the network etc. In some cases, other sources, such as e.g. node local policy, user input or other out of band mechanisms may be used to either construct a PVD entirely (analogously to static IP configuration of an interface), or supplement with particular elements all or some PVDs learned from the network. As an example, node administrator could inject a not ISP-specific DNS server into PVDs for any of the networks the node could become attached to. Such creation / augmentation of PVD could be static or dynamic. The particular implementation mechanisms are outside of the scope of this document. PVD-aware node: a node that supports association of network configuration information into PVDs, and using the resultant PVDs to serve requests for network connections in a way, consistent with recommendations of this architecture. In 4.2.1, I suggest the following change: OLD: In either case, by default the node shall use for the following connection request the PVD, where the lookup results were obtained. NEW: 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. For simplicity, when we say that name service lookup results were obtained from a PVD, what we mean is that the name service query was issued against a name service the configuration of which is present in a particular PVD. In that sense, the results are "from" that particular PVD. In 5.1, maybe the following change? OLD: Applications are not PVD-aware in any manner, and only submit connection requests. The node performs PVD selection implicitly, without any otherwise applications participation, and based purely on policies and/or user choice. NEW: Applications are not PVD-aware in any manner, and only submit connection requests. The node performs PVD selection implicitly, without any otherwise applications participation, and based purely on node-specific administrative policies and/or choices made by the user in a user interface provided by the operating environment, not by the application. I'd like to see more text talking about the user interface aspect of this. Section 5.3 suggests that the information configured by local policy or user interface is not visible to the application. This is probably correct, but needs to be explored in more detail, IMHO. I would suggest the following for the trust section, since there's no text yet: 6.1 Untrusted PVDs Implicit and explicit PVDs for which no trust relationship exists are considered untrusted. Only PVDs which meet the requirements in section 6.2 are trusted; any other PVD is untrusted. In order to avoid various forms of misinformation that can be asserted when PVDs are trusted, hosts that implement PVD separation cannot assume that two explicit PVDs with the same identifier are actually the same PVD. A node that did make this assumption would be vulnerable to attacks where for example an open Wifi hotspot might assert that it was part of a well known PVD, and thereby draw traffic intended for that PVD onto its own link. Since implicit PVD identifiers are synthesized by the node, this issue cannot arise with implicit PVDs. Mechanisms exist (for example [RFC6731]) whereby a PVD can provide configuration information that asserts special knowledge about the reachability of resources through that PVD. Such assertions cannot be validated unless the node has a trust relationship with the PVD; assertions of this type therefore must be ignored by hosts that receive them from untrusted PVDs. Failure to ignore such assertions could result in traffic being diverted from legitimate destinations to spoofed destinations. 6.2 Trusted PVDs Trusted PVDs are PVDs for which two conditions apply. First, a trust relationship must exist between the node that is using the PVD configuration and the operator that provided that configuration; this is the authorization portion of the trust relationship. Second, there must be some way to validate the trust relationship. This is the authentication portion of the trust relationship. Two mechanisms for validating the trust relationship are defined. 6.2.1 Authenticated PVDs One way to validate the trust relationship between a node and the operator of a PVD is through the combination of cryptographic authentication and an identifier configured on the node. In some cases, the two could be the same; for example, if authentication is done with a shared secret, the secret would have to be associated with the PVD identifier. Without a (PVD Identifier, shared key) tuple, authentication would be impossible, and hence authentication and authorization are combined. However, if authentication is done using some public key mechanism such as a TLS cert or DANE, authentication by itself isn't enough, since theoretically any PVD could be authenticated in this way. In addition to authentication, the node would need to be configured to trust the identifier being authenticated. Validating the authenticated PVD name against a list of PVD names configured as trusted on the host would constitute the authorization step in this case. 6.2.2 PVDs trusted by attachment In some cases a trust relationship may be validated by some means other than described in 6.2.1, simply by virtue of the connection through which the PVD was obtained. For instance, a handset connected to a mobile network will know through the mobile network infrastructure that it is connected to a trusted PVD, and whatever mechanism was used to validate that connection constitutes the authentication portion of the trust relationship. Presumably such a handset would be configured from the factory, or else through user preference settings, to trust the PVD, and this would constitute the authorization portion of this type of trust relationship. That's all I've got for today-I hope it helps. Thanks for writing this up!
- [mif-arch-dt] FW: New Version Notification for dr… Dmitry Anipko
- Re: [mif-arch-dt] New Version Notification for dr… Ted Lemon
- Re: [mif-arch-dt] New Version Notification for dr… Hui Deng
- Re: [mif-arch-dt] New Version Notification for dr… Ted Lemon
- Re: [mif-arch-dt] New Version Notification for dr… Ted Lemon
- Re: [mif-arch-dt] New Version Notification for dr… Alper Yegin
- Re: [mif-arch-dt] FW: New Version Notification fo… Dapeng Liu
- Re: [mif-arch-dt] FW: New Version Notification fo… Dmitry Anipko
- Re: [mif-arch-dt] New Version Notification for dr… Dmitry Anipko
- Re: [mif-arch-dt] New Version Notification for dr… Dmitry Anipko
- Re: [mif-arch-dt] FW: New Version Notification fo… Dapeng Liu
- Re: [mif-arch-dt] New Version Notification for dr… Ted Lemon
- Re: [mif-arch-dt] New Version Notification for dr… Alper Yegin
- Re: [mif-arch-dt] New Version Notification for dr… Tim Chown
- Re: [mif-arch-dt] New Version Notification for dr… Dmitry Anipko
- [mif-arch-dt] FW: Slide for MIF arch DT Dmitry Anipko
- Re: [mif-arch-dt] New Version Notification for dr… Tim Chown