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" <int-area-bounces@xxxxxxxx on behalf of noreply@xxxxxxxx> 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
Int-area@xxxxxxxx
https://www.ietf.org/mailman/listinfo/int-area
