Reviewer: Phillip Hallam-Baker Review result: Serious Issues This draft gives some long overdue attention to an issue that has become increasingly problematic in real world contexts. Since this is an early review, I am focusing on the types of issues that need to be addressed during development. One issue that had me somewhat confused at first is the initial sentence. "An increasing number of hosts access the Internet via multiple interfaces". Reading the draft, there appears to be an implicit assumption that the access is sequential (mobile device going from one coffee shop to another) even though the referenced document is very much focused on parallel. It would be helpful if there was some grounding context early on in the document to provide this context, something like: If Alice has a mobile phone provider and a broadband provider in her home, her devices should be capable of seamlessly transitioning from one to the other. So that if the broadband fails, the Internet service can gracefully failover to the mobile and vice versa for upgrades. This draft isn't going to solve that problem but providing the basic information necessary to make this choice intelligently is going to be crucial to any solution. There are similar concerns for IPSEC VPN. This particular proposal is situated at a very low level in the stack but is making use of application level protocols to achieve its effect. I think this is a perfectly valid approach but does mean that the issue of recursive dependencies have to be considered and in particular in the security considerations. At present, the draft is structured to describe an IP packet format and then the data that can be accessed. I suggest reversing these and presenting the PvD schema first and then the IP packet as one choice of binding, we are likely to want to add more. If I am provisioning an IPSEC VPN configuration to a client, it would be logical to either include the PvD in the IPSEC connection description or vice versa. This is particularly the case if we end up signing the data (see later). Turning to the security concerns, it is usually helpful to consider these in terms of Confidentiality, Integrity and Availability and the network layer at which the protocol operates. In this case, the proposal appears to be link layer since it is providing information to a host connecting to a network. But the information provided includes (potentially) DNS services and so it is going to affect the whole stack from the link up to the application layer. Since this is link layer, there is a certain degree of implicit integrity achieved because the host has either a direct physical connection or at least proximity to the network. It is probably prudent to distinguish the cases of hosts connecting wirelessly and physically since a physical connection provides a higher degree of implicit integrity than wireless. Taking the most important consideration first, what is the potential for (ab)using this approach to perform a service attack? Here we should consider the possibility of an attack on the host itself and the use of the mechanism to relay attacks onto other hosts. I have not thought of any attacks of this type yet but this is the area that gives me the most concern. Integrity presents two considerations, first there is the question of whether the data has been modified, the second is where it came from in the first place. The use of TLS does not necessarily provide a strong binding to the domain. At the very least, data would have to be retrieved from a URL in some portion of the address space that is reserved for administrative use. While ..well-known is often used for this purpose, it is not always valid. Another issue with TLS is that we start off with a fairly strong implicit integrity from the link and discard that for a repudiable authentication via TLS. I would prefer to keep both if we can. Rather than relying on TLS, a shorter distance between the two points would be to sign the PvD specification with JOSE. This need not be too onerous. A client that wants to rely on just the TLS integrity can simply Base64 decode and trust the data as being implicitly authentic because of the means of retrieval. The bigger payoff from signing the PvD is that we no longer need to worry about how it is retrieved. The killer app for DNSSEC is turning out to be the ability to divorce DNS data from DNS transport. There are certain situations in which the fact that the PvD is delivered over a particular link is significant but there are other situations in which it might not. For example, I have 12 smoke alarms in my ceilings, one of which I can only (safely) reach by erecting scaffolding. These smoke alarms are all connected to a WiFi router that failed and the only option the manufacturer (which I won't name but rhymes with sproogle) gives for updating the SSID is to reconfigure each one in turn. It would be really nice if I could program multiple SSIDs into the devices to provide failover. Contrawise, this capability could be extended to facilitate the initial connection of the devices to my network. While this is not a feature the WG is likely interested in right now, it is one that I am working on for the Mathematical Mesh and it is obviously a good idea if we have as much commonality between the top down and bottom up configs. Confidentiality is not generally a direct concern at the link layer but corruption of the data (i.e. an integrity attack) might allow a disclosure breach. But this should be stated explicitly. Finally, as a gen-art issue, the use of x-options is generally deprecated as it at best ends up with a situation where every client has to accept headers in both the prefixed and unprefixed form. An IANA registry with first-come, first-served registration fulfills the goal of preventing accidental collisions more effectively.
