Philip, Thank you again for the time spent on reviewing our draft. After some discussion with the authors, please see below our comments, look for EV>.
Also, expect a next revision in the coming days taking in to account a couple of your comments. Regards -éric for the authors On 23/05/2019, 17:29, "Int-area on behalf of Phillip Hallam-Baker via Datatracker" <[email protected] on behalf of [email protected]> wrote: 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: EV> this is indeed a use case that we have in mind, all the work is based on the multiple interface defunct MIF WG. We may want to add more descriptive text to our I-D. Not to mention that there are case when a single W/LAN has upstream connectivity via multiple provider. EV> our next rev will include a use case section. 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. EV> IPsec VPNs are already considered Explicit PvDs in RFC7556. You are perfectly correct about multiple interfaces including pseudo VPN ones. And, indeed the scope of this document does not include re-routing traffic based on upstream availability but when selecting a new upstream, the PvD allows for a consistent set of information (recursive DNS server, IPv6 prefix, ...) to be used. 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). EV> We do not mind either way, our flow was more focused on the chronology of operations (bottom-up). Our original intent is that we emphasize that the key point of the draft is fleshing out the requirements for explicit PvD discovery via local router mechanisms, as predicted by RFC 7556, it becomes more clear. Except if other reviewers want to change the order, then we prefer to keep it the way it is. If majority of reviewers want the order reverse, then for clarity we will change the text order. 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. EV> pretty much like the RDNSS option in the IPv6 RA as specified by RFC 8106 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. EV> there is indeed some integrity and trust within the access (esp when using WiFI & WPA2) but the draft does not rely too much on this level of integrity when checking for the additional information (the JSON file) 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. EV> The extended information does not replace any locally provisioned information, and does not supersede it. EV> Beside the .well-known path which is well-known and does not present any security issue, I am unsure whether I am following you. EV> When receiving a RA containing the the PvD ID example.net, then TLS is used to fetch https://example.net/.well-known/pvd.json and NOT any other URL. So, at least the client node can check that the server is the correct one (and transitively that the JSON file is correct). Of course, if hacker.net is sending PvD pretending to be example.net PvD while on hacker.net, the TLS session will work to example.net and the JSON will be downloaded but will NOT be used by the PvD client because the JSON includes a set of covering IPv6 prefix under the key 'prefixes' and obviously the prefix used by hacket.net will not be covered. Even if hacket.net uses NPTv6 or NAT66 (she/he is evil after all!), then it is up to the example.net web server to refuse connections from an unauthorized prefix outside of example.net prefixes. EV> Quite a long explanation, but, please have a look to https://download.ernw-insight.de/troopers/tr18/slides/TR18_NGI_IPv6_Security-and-Privacy-Multi-Prefix.pdf (at the end in the 'Rogue PvD' section) for a better explanation. EV> in all case, we never state that this approach is 'secure' or more secure than plain 'RA' (with RA guard of course). It is merely slightly improving the security but more important provided information to the application; it is the sole objective. 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. EV> We though about JOSE and signature as well but then we cannot 'defeat' easily the attack of hacker.net announced example.net prefixes, doing NAT66, with a cached JSON. EV> JOSE was attractive as well because PvD additional information could be cached without sharing the web server keys; but, in authors' opinion is that there are many more TLS implementation than JOSE. Moreover, with TLS there is a distribution & caching infrastructure 'for free' while with JOSE there is a need to build this infrastructure to distribute the JOSE blobs. 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. EV> I agree integrity and availability are more important in this context. Confidentiality is mostly impossible to achieve in our proposal as any host in the example.net network with the right prefix can access the TLS server and its information. 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. EV> indeed, we got the same comment from Erik Kline and the next rev will replace the HTTP header X-* but a more standard mechanism. Thank you again for the extensive review -éric _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
