On 3.2.2015, at 14.47, Ted Lemon <Ted(_dot_)Lemon(_at_)nominum(_dot_)com> wrote:
On Feb 3, 2015, at 3:44 AM, Markus Stenberg
<markus(_dot_)stenberg(_at_)iki(_dot_)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