Minutes taker: Stuart Cheshire Jabber scribe: Maaz Rehan 1310 MIF architecture (Design team) draft-anipko-mif-mpvd-arch-00 Slide: Potential next items for elaboration Lorenzo Colitti: Is this for v4, v6 or both? Cao Zhen: Both. Erik Nordmark: Assumption is different Provisioning Domain per interface. Multiple interfaces could share a common Provisioning Domain. Lorenzo Colitti: What does "existing processes" mean? Cao Zhen: Existing IETF work, including algorithms, drafts, and RFCs. Erik Nordmark: Is there any existing code that does this? Lorenzo Colitti: Sadly yes. Andrew Yourtchenko: VPN does this. Dave Thaler: For apps that use existing connect-by-name APIs, OS vendor improvements could transparently improve a lot of apps. Dave Thaler: Is trusted/untrusted a property of a Provisioning Domain, or a property of a configuration element within a Provisioning Domain? i.e. is trust all-or-nothing for a Provisioning Domain, or can there be selective trust within a Provisioning Domain? Lorenzo Colitti: What would clients do with this information? Ted Lemon: There may be cases where there are untrusted elements in a Provisioning Domain, but we don't care, because we don't use them. Need to be very careful when assuming that two interfaces could share a common Provisioning Domain, if one or both is partially or completely untrusted. Lorenzo Colitti: A use case or two would be nice. Juan Carlos Zuniga: 802.1X is not rock solid. We may be playing a dangerous chicken-and-egg game here. Dave Thaler: Two examples: Two routers, one legitimate and one rogue. If legitimate is trusted, it should preferred over rogue one, regardless of RA attributes. Local configuration information should override network configuration information. Ted Lemon: On trains here, there are Wi-Fi hotspots, but no way to tell if they are legitimate or rogue. Andrew Yourtchenko: Example of VNP vs local network. Lorenzo Colitti: A trusted/untrusted boolean may not be sufficient. Erik Nordmark: Is there a containment hierarchy for these things? Per interface, per link, per host, per ISP, etc. Margaret Wasserman: We have discussed containment hierarchy. The problem is that there is no clear hierarchy. We used to think per interface was good, but that't too simple. An interface can have more than one Provisioning Domain. A Provisioning Domain can have more than one interface. The concept of Provisioning Domain exists to give us an entity to name. Erik Nordmark: Life gets easier if we can define this as a hierarchy. For things that don't fit the hierarchy, treat those as virtual interfaces. It might help to force things into a hierarchy. Dave Thaler: Relationship between Provisioning Domains and interfaces can be arbitrary. Margaret Wasserman: We did consider virtual interfaces, but some things don't fit that model. Erik Nordmark: It doesn't have to be literally a virtual interface, but can be treated somewhat like that. Lorenzo Colitti: Using the interface as the unit for this -- which is what Android does -- does not work well. It would be nice to avoid hierarchy. Suresh Krishnan: Some properties, like Ethernet link speed, do not belong to any Provisioning Domain. Erik Nordmark: I don't know how to do trust without hierarchical names. Margaret Wasserman: We'll need hierarchical names. Dave Thaler: No, we won't. Erik Nordmark: We'll want to use our existing (X.509 and similar) certificate hierarchy. Dave Thaler: It is not required to have hierarchy to have trust. DNS uses hierarchy, but other things don't, like self-signed certs, or PGP. Lorenzo Colitti: Network operators assume they have complete control of device. Provisioning Domains let devices act *as if* network operators actually do have complete control of device. The masters on the network need to reveal who they are (i.e. under what authority they claim to operate). Erik Nordmark: Do we need a namespace that is able to support hierarchical names? I think we do. Each Deutsche Telekom hotspot is its own Provisioning Domain, but also belongs to the overall Deutsche Telekom authority. Various people: No, the overall Deutsche Telekom authority is its own Provisioning Domain. Suresh Krishnan: We have a separation between configuration sources (e.g. DHCP vs. RA) and Provisioning Domains. Ted Lemon: One RA can contain two Provisioning Domains, right? Various people: No Ted Lemon: I'd like that to be possible on my home network. Lorenzo Colitti: You need to use two RAs, one for each Provisioning Domain. Dave Thaler: Multiple configuration messages can belong to the same Provisioning Domain. A single configuration message cannot contain data from more than one Provisioning Domain, because of trust issues. Erik Nordmark: Combining data from more than one Provisioning Domain is just an efficiency issue. Ted Lemon: Another problem is that ISP may have private key to sign DHCP message, but I don't have private key to re-sign same data when I put it in RAs. dmitry.anipko (via Jabber): 2 Ted: you can't re-sign, but it may be not needed, it may be possible to pass the signed record all the way down Margaret Wasserman: If the router is passing on smaller delegated prefixes, you need to trust the router too. Slide: Some issues raised in the discussions Erik Nordmark: Provisioning Domains should have user-meaningful names dmitry.anipko (via Jabber): More typical example of app configuration in question is SIP server Dave Thaler: How should one deal with multiple Provisioning Domains? Depends on the configuration element. A few may be mergable. Perhaps divide configuration element into three (or so) classes by mergability. Lorenzo Colitti: Configuration elements do not stand alone. They are used together, like address + default route. Dave Thaler: There are still a small number of plausible ways to combine most configuration elements. dmitry.anipko (via Jabber): 2 Dave: the reason we're talking of Provisioning Domains is because generally merging doesn't work today in some specific cases merging may be possible but I think default safe start is that stuff is not mergable unless explicitly known otherwise. Tim Chown: Provisioning Domain selection could be user choice. Could be triggered off connectivity checks. Lorenzo Colitti: Often cannot usefully pick and mix configuration elements. Erik Nordmark: Proposal: Should *never* combine configuration elements from different Provisioning Domains. Dave Thaler: Maybe we need a different word instead of "merge"? Some applications may want *all* configuration elements available, and will make their own choice what to trust. dmitry.anipko (via Jabber): 2 Dave: and one of the default routes points to walled garden another example where merge is not safe safe approach for routes: use them in the way such as they were different routing tables whether or not they are in the same hash table / list / container is just implementation specific preferences dont' work, walled garden may have high pref default route. Mikael Abrahamsson: Secure Corporate Provisioning Domain may want to disallow any use of other Provisioning Domains Lorenzo Colitti: Device operator has to make he final decision Tim Chown: How do you incrementally deploy this? Tim Chown: Russel Square problem: Multiple "EDUROAM" Wi-Fi access points and no way to choose the one you want. dmitry.anipko (via Jabber): Agreed with Lorenzo, and that's what draft currently says :) (about ultimately being node decision, and PVDs can't directly affect each other) Al Morton: Will need multiple local Provisioning Domains. Andrew Yourtchenko: One was to help adoption would be to use user interface as a driver -- i.e. let the user pick desired Provisioning Domain. Erik Nordmark: The only way to solve multiple default routes is with separate routing tables. The problem is lack of transparency. Walled gardens. Ingress filtering. Differing usage costs. Dave Thaler: Using "send data using same PVD as where answer to name lookup came from" helps solve this for many applications. It will be easier to deploy something if it immediately helps existing applications. Lorenzo Colitti: A device belongs to multiple masters. When it talks with one master, it does not reveal existence of other masters. The current state of software is so bad dmitry.anipko (via Jabber): 2 Lorenzo: completely agree with the principles on implementation - starting point is implicit PVDs formed per interface but surely significant changed to implementations may be needed Erik Nordmark: The bubble analogy is a useful way to think about this. A given connect-by-name invocation ends up in a particular bubble. How do we make this easy to deploy incrementally? Lorenzo Colitti: Android has a "default bubble". Mikael Abrahamsson: Right. The MMS application lives in the "MMS bubble". Corporate app only works in "corporate bubble". VPN code uses "Internet bubble" and makes a "corporate bubble". -- Margaret Wasserman: Next steps? Lorenzo Colitti: This is good work. Erik Nordmark: If design team still has energy they should continue. Lorenzo Colitti: Design team should post frequent updates so their progress and thinking is visible. Ted Lemon: Are more design team members welcome? Margaret Wasserman: We have not refused anyone yet. Margaret Wasserman: Do we need to recharter? Ted Lemon: Not sure, but if we do it's not a problem. -- Problem Statement for Flow Control of MIF Hosts draft-liu-mif-flow-control Dapeng Liu Any comments from the room? No. Margaret Wasserman: How many people have read this? Three END