Re: [mif] Last Call: <draft-ietf-mif-mpvd-arch-09.txt> (Multiple Provisioning Domain Architecture) to Informational RFC

[Ted Lemon <[e-mail]>]

On Feb 3, 2015, at 3:44 AM, Markus Stenberg <[e-mail]> 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.

> 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.

> Nit: In section 9, I am Markus, not Marcus ;)

Sorry about that.   Thanks for the thorough review!