Subject: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt

From: [email-masked]
Date: Sat, 03 May 2014 20:42:18 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Multiple Interfaces Working Group of the IETF.

        Title           : Multiple Provisioning Domain Architecture
        Author          : Dmitry Anipko
	Filename        : draft-ietf-mif-mpvd-arch-01.txt
	Pages           : 19
	Date            : 2014-05-03

Abstract:
   This document is a product of the work of MIF architecture design
   team.  It outlines a solution framework for some of the issues,
   experienced by nodes that can be attached to multiple networks.  The
   framework defines the notion of a Provisioning Domain (PVD) - a
   consistent set of network configuration information, and PVD-aware
   nodes - nodes which learn PVDs from the attached network(s) and/or
   other sources and manage and use multiple PVDs for connectivity
   separately and consistently.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-mif-mpvd-arch/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mif-mpvd-arch-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-mif-mpvd-arch-01

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Dmitry Anipko <[email-masked]>
Date: Sun, 4 May 2014 03:51:01 +0000

This revision has changes supposed to address most comments made in London as well as agreed changes from Alper's and Ian's reviews.

For reference topologies / propagation of PVD info through intermediate routers from ISP uplinks (e.g. Homenet) more changes are needed, it would be great to see more inputs / discussion on the list around that.

-Dmitry

________________________________
From: [email-masked]
Sent: 5/3/2014 8:42 PM
To: [email-masked]
Cc: [email-masked]
Subject: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt

Abstract:

_______________________________________________
mif mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mif

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 5 May 2014 08:21:06 +0200

> For reference topologies / propagation of PVD info through intermediate routers from ISP uplinks (e.g. Homenet) more changes are needed, it would be great to see more inputs / discussion on the lis…

After some thinking on this topic, I think that implicit PVDs noted on homenet edge towards ISPs have to be converted to explicit ones to be offered to clients, if no information is to be lost. At least in IPv6 case, IPv4 I’m not sure how it should be even handled, perhaps as fallback PVD-less potentially broken by two+ different NATs connectivity :p

As a random example, during the weekend we had a discussion on IRC about some ISPs being sensitive about which source address is used with their DNS server. This information isn’t currently propagated in the information available _from_ the ISPs explicitly (it’s implicit by definition), yet for even homenet routers to work correctly if there’s multiple upstream ISPs, the information needs to be available within the homenet (e.g. ‘we got this delegated prefix and this DNS address, use them together’) for the DNS resolution to work consistently.  Obviously, this can be also fixed by the homenet routers and then presenting just themselves as DNS servers to the clients.

As another random example, even if the ISP at end of 3G dongle isn’t providing explicit PVD, implicit PVD information should be bundled into explicit one with the extra information available (in this case, that it is not wired connection and has speed roughly of X, perhaps).

So I’m not really sure the text in 2.3 is that reasonable, because it seems to assume implicit PVDs are generated (only?) on hosts, but in case of homenet, I don’t see the point in non-explicit PVDs coming _to_ hosts except perhaps in case of IPv4 (too much magic related to possibly more than one NAT needs to happen, and I’m not sure we really want to go there).

Some other thoughts..

5.2.3.1:

Also, I’d just rather treat PVD-bind as per-interface or per-address one; if we can determine packet doesn’t belong to it (outside the application), application shouldn’t know, and remote node shouldn’t know application is listening to some other PVD. So connection refused/equivalent.

Cheers,

-Markus

---

From: Dmitry Anipko <[email-masked]>
Date: Sat, 10 May 2014 02:51:43 +0000

Hi Markus,

Thank you for the comments. In the Homenet scenario you described, I agree on the substance with what you wrote - if the router can do such formation of explicit PVDs, it should do that to prevent mix-up of configuration. Such text can be added into the section 4, example network configuration and number of PVDs. That said, I don't think it contradicts to 2.3, because Implicit PVDs by definition in 2.2. apply only when there the network is non-PVD aware:

<Quote>
   It is likely that for a long time there may be networks which do not
   advertise explicit PVD information, since deployment of any new
   features in networking protocols is a relatively slow process.

   When connected to networks, which don't advertise explicit PVD
   information, PVD-aware node shall automatically create separate PVDs
   for received configuration.  Such PVDs are referred to in this
   document as "implicit".
</quote>

So from the host perspective, presence of a router, which can/does advertise PVDs, makes it a scenario with explicit PVDs, and not implicit ones.

>>, I don't see the point in non-explicit PVDs coming _to_ hosts except perhaps in case of IPv4

My understanding, is that the main reason we introduced the notion of implicit PVD is to be able to handle configurations received on multiple interfaces (which typically are connected to different networks) in the same way as in the case of multiple explicit PVDs, basically to unify and simplify conceptual host implementation. The acknowledged limitation is that we don't know well how to form multiple implicit PVDs on one interface (or form implicit PVDs, spanning multiple interface).

>> Also, I'd just rather treat PVD-bind as per-interface or per-address one; if we can determine packet doesn't belong to it (outside the application), application shouldn't know, and remote node shouldn't know application is listening to some other PVD. So connection refused/equivalent.

The current text is
<quote>

  If the determined receiving PVD of the packet is not in the allowed

   subset of PVDs for the particular app/transport API object, the

   packet should be handled in the same way as if there were no listener

   (alternatives - error message 'administratively prohibited', or just

   refer to pre-PVD behavior for legacy behavior for interface-scoped

   binds).
</quiote>

It seems the case you described would be where the "allowed subset of PVDs" contains only one PVD. If you think the current text is not sufficient, can you please suggest the change?

-Dmitry

From: Markus Stenberg [mailto:[email-masked]]
Sent: Sunday, May 4, 2014 11:21 PM
To: Dmitry Anipko
Cc: Markus Stenberg; [email-masked]
Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt

On 4.5.2014, at 5.51, Dmitry Anipko <[email-masked]<mailto:[email-masked]>> wrote:
This revision has changes supposed to address most comments made in London as well as agreed changes from Alper's and Ian's reviews.

After some thinking on this topic, I think that implicit PVDs noted on homenet edge towards ISPs have to be converted to explicit ones to be offered to clients, if no information is to be lost. At least in IPv6 case, IPv4 I'm not sure how it should be even handled, perhaps as fallback PVD-less potentially broken by two+ different NATs connectivity :p

As a random example, during the weekend we had a discussion on IRC about some ISPs being sensitive about which source address is used with their DNS server. This information isn't currently propagated in the information available _from_ the ISPs explicitly (it's implicit by definition), yet for even homenet routers to work correctly if there's multiple upstream ISPs, the information needs to be available within the homenet (e.g. 'we got this delegated prefix and this DNS address, use them together') for the DNS resolution to work consistently.  Obviously, this can be also fixed by the homenet routers and then presenting just themselves as DNS servers to the clients.

As another random example, even if the ISP at end of 3G dongle isn't providing explicit PVD, implicit PVD information should be bundled into explicit one with the extra information available (in this case, that it is not wired connection and has speed roughly of X, perhaps).

So I'm not really sure the text in 2.3 is that reasonable, because it seems to assume implicit PVDs are generated (only?) on hosts, but in case of homenet, I don't see the point in non-explicit PVDs coming _to_ hosts except perhaps in case of IPv4 (too much magic related to possibly more than one NAT needs to happen, and I'm not sure we really want to go there).

Some other thoughts..

5.2.3.1:

Also, I'd just rather treat PVD-bind as per-interface or per-address one; if we can determine packet doesn't belong to it (outside the application), application shouldn't know, and remote node shouldn't know application is listening to some other PVD. So connection refused/equivalent.

Cheers,

-Markus

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 12 May 2014 10:59:36 +0300

On 10.5.2014, at 5.51, Dmitry Anipko <[email-masked]> wrote:
> Thank you for the comments. In the Homenet scenario you described, I agree on the substance with what you wrote – if the router can do such formation of explicit PVDs, it should do that to prevent mix-up of configuration. Such text can be added into the section 4, example network configuration and number of PVDs. That said, I don’t think it contradicts to 2.3, because Implicit PVDs by definition in 2.2. apply only when there the network is non-PVD aware:
>  
> <Quote>

2.2 has also that mixed implicit+explicit mode which I’d rather see die in fire, because it makes the definition just more complicated. I think interface should be either fully explicit, or fully implicit, because mixed mode is a) more complicated, and b) possible to fail (implicit in general does, and mixed doesn’t help here).

> >>, I don’t see the point in non-explicit PVDs coming _to_ hosts except perhaps in case of IPv4 
> My understanding, is that the main reason we introduced the notion of implicit PVD is to be able to handle configurations received on multiple interfaces (which typically are connected to different networks) in the same way as in the case of multiple explicit PVDs, basically to unify and simplify conceptual host implementation. The acknowledged limitation is that we don’t know well how to form multiple implicit PVDs on one interface (or form implicit PVDs, spanning multiple interface).

See my comment above about fail - I’m not convinced implicit PVDs work well in any case. BCP38-ish filtering by upstream ISPs on either normal data traffic or DNS requests, etc => you can’t just pool parameters together implicitly and hope they work.

> It seems the case you described would be where the “allowed subset of PVDs” contains only one PVD. If you think the current text is not sufficient, can you please suggest the change?

Well, I’m mostly concerned about complexity of that whole section - having dealt with brokenness of cross-platform dual AF IPv6 sockets recently[1], I’m not very keen to have very complicated semantics anywhere. All of that reverse-RPF stuff etc sounds just overkill to me (and potentially harmful, if you assume someone actually has PI address space coming from multiple connections). If it was up to me, I’d get rid of cross-PVD filtering stuff altogether and leave it as exercise to firewall vendor or whoever really cares. I don’t see it affecting the PVD semantics in any way, except adding extra text. 

So: concrete proposal - nuke second paragraph, remove alternatives from third paragraph.

Cheers,

-Markus

---

From: Dmitry Anipko <[email-masked]>
Date: Sun, 18 May 2014 02:08:36 +0000

Hi Markus,

thank you for the discussion, please find my responses below:

>>I think interface should be either fully explicit, or fully implicit, because mixed mode is a) more complicated, and b) possible to fail (implicit in general does, and mixed doesn’t help here).

I’d be happy to kill the mix mode :-), but basically here is the line of reasoning which lead to to it:

1. In practice, can the node encounter the mixed scenario - e.g. where the node has an interface, connected to a link, with a PVD-aware and non-PVD aware routers? My default assumption is that it can, since it seems to me technically possible, and I couldn’t think of any strong reason, why that would not happen in practice. If you think the node won’t encounter such configuration, please elaborate why. 

2. If you agree that the node can encounter such configuration, then should the document describe a suggested node behavior, or leave it out of scope? If the latter, why? If the former, what should the behavior be, if it is different from what currently is in the text?

>>See my comment above about fail - I’m not convinced implicit PVDs work well in any case. BCP38-ish filtering by upstream ISPs on either normal data traffic or DNS requests, etc => you can’t just po…

Somehow it seems on this item we’re talking past each other. From my previous email:

<quote>the main reason we introduced the notion of implicit PVD is to be able to handle configurations received on multiple interfaces (which typically are connected to different networks)</quote>

Do you agree that in the scenario in the quote, where the node has interface 1 connected to ISP A, and interface 2 connected to ISP B, implicit PVDs can improve the behavior? (because config from the different ISPs is not accidentally mixed across interfaces) 

If you disagree, please elaborate why. (If this is what the BCP38 text was referring to, please elaborate, because I could not follow how it would relate to this scenario) 

If you agree, then if the implicit PVDs do help in this scenario, and don’t help and don’t harm in other scenarios (such as the one you seem to be describing), it seems that it is appropriate to let them be? Additional potential benefit is that having implicit PVDs allows for the node to have a common “PVD-aware” code path to handle all cases, instead of having special “PVD” and “non-PVD” code scattered around).

>>So: concrete proposal - nuke second paragraph, remove alternatives from third paragraph.

Thanks. I’ll remove the alternatives from the third paragraph, and replace the second paragraph with a phrase along the lines, that a node OS or middleware, such as firewall, may apply more complex techniques for incoming traffic filtering, but that ’s out of scope for this document. Will that work?

-Dmitry
________________________________________
From: Markus Stenberg <[email-masked]>
Sent: Monday, May 12, 2014 12:59 AM
To: Dmitry Anipko
Cc: Markus (Old) Stenberg; [email-masked]
Subject: Re: [mif] I-D Action: draft-ietf-mif-mpvd-arch-01.txt

Cheers,

-Markus