On 3.2.2015, at 14.47, Ted Lemon <ted.le...@nominum.com> wrote: > On Feb 3, 2015, at 3:44 AM, Markus Stenberg <markus.stenb...@iki.fi> wrote: >> If we have a home router, which does NAT (and I dare you to find one that >> does not), the e.g. potential authentication mentioned in Section 2.3 >> becomes invalid in case of IPv4 as the source address prefix information has >> to change (or be omitted) for it to be useful. Section 2.5 further advocates >> combining both IPv4 and IPv6 PVDs, and as a result, whole authentication >> scheme becomes more or less invalid if not directly connected to the network >> PVD lives in. (And IPv4 source address prefix information has to change.) > I think this is future work. The MIF working group did consider whether to > separate IPv4 and IPv6 PVDs; my belief was that we should, but the consensus > was that they should be able to be kept together. I think it's true that > the capability to authenticate an explicit provisioning domain's container > across a home gateway that is doing NAT for IPv4 is unlikely to work without > some care. However, it's not clear to me that this is even a use case that > we care about. If it is, then it can be addressed by treating the NATted > provisioning domain as a different provisioning domain than the external IPv4 > provisioning domain. It's actually not usual however for HGs to even pass > the external PVD information into the home network on IPv4 NATs. Instead, > it sets up a DNS proxy and advertises that, and passes nothing else through > at all. > >> - make use of source address specific optional with IPv4? (or note somewhere >> that prefix should be 0.0.0.0/0 if any use of NAT is ever thought reasonable >> using the PVD) > > This is another alternative, but it would only be necessary in the case where > you wanted to advertise a translated prefix internally and have that be > treated as the same PVD as the externally advertised prefix. Since the > current architecture document doesn't make specific recommendations about > this, I don't think that we need to add anything, but if you think it's > worthwhile we could add text that just explains the issue you've raised and > talks about your proposed solution and possibly the one I've suggested. > > I don't really want to add text about this, because I don't think it's been > thought through carefully, and there are some holes in it that I can see. > For example, there's no way to prove that an advertised NAT prefix actually > reaches the PVD that it is claimed to reach. So you are pretty much at the > mercy of the HG anyway.
Fair enough; I guess just splitting the dual stack PVDs if encountered (IPv4+IPv6 -> NATted IPv4 + IPv6 as-is) is sufficient answer to that. As I personally consider authentication mostly bogus, this is not really a problem for me :) >> On not so serious note, as PvD has (more or less) binding to the protocol it >> was used to acquire the configuration information (e.g. DHCPv4, DHCPv6, or >> RA), I would much rather advocate single-AF PvDs so their lifetime would map >> to the lifetime of the other network information received/updated via that >> particular protocol. > Me too, but I think that ship has already sailed. And if you think about > it, your point about RA and DHCPv6 is clearly an implementation issue: the > implementation for explicit PVDs has to make it possible to connect them, > because in practice they are related. So there’s no technical reason why > this can't also work for DHCPv4 and explicit PVDs. >> Nit: In section 7.2.1, where does TLS come from? Does DHCPv6 or RA have TLS >> transport? (X.509 certificate would fit better.) > How about "PKI" instead of "TLS"? I know PKI generally means X.509, but it > isn’t restricted to X.509. PKI is more generic, yes. I also wondered about doing ‘authentication using .. DANE’, as _that_ also just uses X.509 certificates (and would be covered under PKI certificate using authentication). So final suggestion - get rid of DANE, get rid of TLS, and probably rework the text in that paragraph a bit to make it simpler. As-is, both DANE and TLS mention seem superfluous. Cheers, -Markus _______________________________________________ mif mailing list mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
