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

From: Markus Stenberg <[email-masked]>
Date: Tue, 3 Feb 2015 10:44:56 +0200

I am not sure if this document has been really thought through in terms of IPv4, or the dual-stack case. 

Notably, in section 2:
* Source address prefixes for use by connections within the provisioning domain

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

My proposal:

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

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.

My proposal (but I can live without too, this is mostly just elegance-of-design criteria for me):

- unbundle dual-stack case so that IPv4 PVD comes from DHCPv4, and IPv6 PVD from DHCPv6/RA. Or at least make bundling optional; in case of e.g. IKEv2, having both from same source makes still sense.

Nit: In section 7.2.1, where does TLS come from? Does DHCPv6 or RA have TLS transport? (X.509 certificate would fit better.)

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

Cheers,

-Markus

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Feb 2015 07:47:04 -0500

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

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 P…

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!

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 3 Feb 2015 17:09:59 +0200

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

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 :)

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Feb 2015 12:26:48 -0600

> 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, th…

To be clear, the authentication we're talking about here, at least generally, is not intended to assert that the node receiving it can trust it without question.   It merely asserts that the information came from a particular source, which the node may or may not trust.   That's what the text you were commenting on was for, actually.

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

I'm skeptical about this--I think it's good to mention DANE.   DNSSEC is in effect a PKI, but it's quite a bit different than the other common PKI example.   How about "a PKI, for example DNSSEC/DANE or X.509?"   That way we don't lose the mention of DNSSEC, but keep it open to other PKIs.

---

From: Dmitry Anipko <[email-masked]>
Date: Wed, 4 Feb 2015 20:25:09 -0800

My reading is that there is a consensus to fix the name misspelling :-),
but I could not quite read whether the PKI question got resolved. Markus,
can you please comment whether the modification Ted worded would address
your concern?

On Tue, Feb 3, 2015 at 10:26 AM, Ted Lemon <[email-masked]> wrote:

> > 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 :)
>
> To be clear, the authentication we're talking about here, at least
> generally, is not intended to assert that the node receiving it can trust
> it without question.   It merely asserts that the information came from a
> particular source, which the node may or may not trust.   That's what the
> text you were commenting on was for, actually.
>
> > 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.
>
> I'm skeptical about this--I think it's good to mention DANE.   DNSSEC is
> in effect a PKI, but it's quite a bit different than the other common PKI
> example.   How about "a PKI, for example DNSSEC/DANE or X.509?"   That way
> we don't lose the mention of DNSSEC, but keep it open to other PKIs.
>
> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 5 Feb 2015 11:13:20 +0200

On 5.2.2015, at 6.25, Dmitry Anipko <[email-masked]> wrote:
> My reading is that there is a consensus to fix the name misspelling :-), but I could not quite read whether the PKI question got resolved. Markus, can you please comment whether the modification Ted worded would address your concern?

Sorry, I got sidetracked to writing security a audit document and never got back. We all have our guilty pleasures..

Anyway, haha ;) Guess we agree about something at least!

> I'm skeptical about this--I think it's good to mention DANE.   DNSSEC is in effect a PKI, but it's quite a bit different than the other common PKI example.   How about "a PKI, for example DNSSEC/DANE or X.509?"   That way we don’t lose the mention of DNSSEC, but keep it open to other PKIs.

If simplification is not desired, I guess we can work that in too.

DANE is just about binding a (DNS) label + port + protocol using various selectors to a X.509 certificate (either CA or end node one).

Text in question:

   If authentication is done using a public key mechanism such as a TLS
   certificate or DANE, authentication by itself is not enough since
   theoretically any PvD could be authenticated in this way.  In
   addition to authentication, the node would need configuration to
   …

I am not sure where this DNS label + port + protocol combination would be derived from this case, but admittedly (say) using DHCPv6 or something might make sense in this case.

So.. my proposed version:

   If authentication is done using a public key mechanism such as 
   PKI certificate chain validation or DANE, authentication by itself is not enough since
   theoretically any PvD could be authenticated in this way.  In
   addition to authentication, the node would need configuration to

As the text talks of public key authentication mechanisms, I think PKI certificate chain validation and DANE both qualify. The old text’s ’TLS certificate’ is just weird to me, although I understand the idea is fundamentally the same.

Cheers,

-Markus

---

From: Ted Lemon <[email-masked]>
Date: Mon, 9 Feb 2015 13:35:10 -0500

> My reading is that there is a consensus to fix the name misspelling :-), but I could not quite read whether the PKI question got resolved. Markus, can you please comment whether the modification Te…

It looks like you got an answer from Markus.   This document is currently scheduled for the 2/19 telechat, so it would be great if we could get an update in the next day or so that incorporates the agreed-upon changes, or if you don't yet feel that you have what you need, we should figure out how to address that.   The document has to be finished and ready for IETF review with enough lead time that people can meaningfully comment on it and discuss it.