Subject: Re: [addr-select-dt] Regarding Policy Merge

From: Tim Chown <[email-masked]>
Date: Wed, 4 Mar 2009 17:15:37 +0000

Hi,

Phrasing the issues the way you have, I'm reminded of the (lengthy)
discussions in the DHC WG over the IPv4 and IPv6 DHCP dual stack
issues - how responses from different DHCPv4 and DHCPv6 servers may
be handled by hosts.

And the same questions came up.   What if the v4 and v6 providers are
administratively different?   What is the user wants to manually set
their own configuration?   What if the host has multiple interfaces? etc.

One of the conclusions was that, of course, it's simpler if the responses
come from the same administrative domain, i.e. you can expect the DHCP
settings returned to be consistent, and not to conflict.   But you might
want to do some merging, e.g. to merge IPv4 and IPv6 DNS server info.
Even then, if those are just different addresses (v4 and v6) for the same
DNS servers, the responses the host gets should be the same, whichever
server is used.

I think your proposal to use the preferred interface is the one we
should carry for now, and to discuss.  The 'problem' should only arise
where there's policies in conflict from multiple administrative sources,
which in your 4 cases below is probably only going to be scenario (1).

Tim

On Fri, Feb 27, 2009 at 03:32:04PM +0900, Arifumi Matsumoto wrote:
> All,
> 
> I'm trying to summarize the discussion we recently had at this ML,
> and my personal views on them.
> I hope this helps further discussion.
> 
> * policy originator
> - default built-in policy
> - from an entity in a network
> - a PC user's manual configuration
> - site administrator
> 
> These can lead to *vertical* policy conflict, however, these
> originator should be given priority, and a policy set should be
> chosen exclusively, or merged in accordance with a pre-defined
> rule, or overrider's policy.
> What matters is that multiple same-level originators give policy
> sets. (horizontal conflict) And this case is seemed to usually
> happen for multiple network entities case.
> 
> * how policies conflict happen
> - For a prefix, multiple originators give different labels or
>   precedences.
> - Two or more originators try to give higher precedence for
>   their prefixes (arms race).
> - By accident, a label coincides with another entity's label
>   that is intended for different use.
> 
> IMO, precedence has a relative meaning to all the other entries.
> On the other hand, label has basically a relative meaning to all
> the entries with the same label. So, inserting an policy entry
> into a policy set can change all the meaning of the existing
> entries' precedence. What I mean is that merging different set
> of policies with their precendence meanings unchanged is impossible.
> So, how about taking away precedence value control from a policy
> originator in network, especially if the policy originator is
> not authenticated by another means, such as DHCP-AUTH.
> 
> 
> * where policies conflict happen
> 
>  1) host multi-interface environment
> 
>               +--- server
>   +-+        +-+
>   |R|        |R|
>   +-+        +-+
>    |   +--+   |  VPN
>    +---+PC+---+
>        +--+
> 
>   - Each router R distributes policy.
>   - uRPF does not matter in this case.
>   - Dave Thaler's favorite ;)
>   - One interface can be a VPN interface.
>   - Policy originators can be in different management domain, and
>     can be uncoordinated with each other.
> 
>   Tony mentioned about the possibility of precedence arms race.
>   By doing so, a policy originator can make PC send a packet to
>   a server in his office not through VPN. This happens if the server
>   has both a globally reachable address and intra-site address, such
>   as ULA and if the policy originator puts higher precedence for
>   ::/0 than ULA.
>   IMO, however, in this case the server should not present confidential
>   contents to the PC if the PC is connected through non-VPN address.
>   Otherwise, the confidential contents is accessible from every node.
> 
>   IMO, the policy merge of this case can be implemented by making
>   use of Interface priority/metric, that is often? usually?
>   implemented in the existing OSes. The priority of interface is
>   used for route selection, e.g. in multiple default router case.
>   That is, the policy merge can be implemented in coordinated manner
>   with the routing table. Of course, the precedence values cannot
>   be merged in this case also, so above-mentioned process is needed.
> 
> 2) router multi-interface multi-home
> 
>   +-+        +-+
>   |R|        |R|
>   +-+        +-+
>    |   +--+   |
>    +---+GW+---+
>        +--+
>         |
>        +--+
>        |PC|
>        +--+
> 
>   - Each router distributes policy.
> 
>   Usually, GW makes a decision about routing, e.g. which route
>   to take for the default route. If so, the address selection
>   policy have to be coordinated with the routing policy, and
>   sets of address selection policy should be merged at GW.
>   Then this case of policy merging at GW can come down to case 1).
> 
> 3) one-link multi-router multi-home
> 
>   +-+       +-+
>   |R|       |R|
>   +-+       +-+
>    |         |
>  --+----+----+--
>         |
>        +--+
>        |PC|
>        +--+
> 
>   - Each router distributes policy.
>   - uRPF matters in this case.
> 
>   IMO, in this case, we can assume that these two routers
>   belong to the same administration domain. So, the administrator
>   should and can take care of policy conflicts.
> 
> 4) router one-link multi-home
> 
>   +-+       +-+
>   |R|       |R|
>   +-+       +-+
>    |         |
>  --+----+----+--
>         |
>        +--+
>        |GW|
>        +--+
>         |
>        +--+
>        |PC|
>        +--+
> 
>   This case come down to 3).
> 
> 
> Any comments are welcome.
> 
> Kindest regards,
> 
> --
> Arifumi Matsumoto
>   Secure Communication Project
>   NTT Information Sharing Platform Laboratories
>   E-mail: [email-masked]
> 
> _______________________________________________
> addr-select-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/addr-select-dt

-- 
Tim

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 9 Mar 2009 14:17:52 +0900

Tim,

> DNS servers, the responses the host gets should be the same, whichever

I'm not catching up the dhc ML well, but could you please tell me their
conclusion regarding these two servers come from different
administrative domain ?

Or they've decided to take it out of scope ?

> which in your 4 cases below is probably only going to be scenario (1).

I believe so.
And I guess this is how they, OS vendors, do it now.

Regards,

---

From: Tim Chown <[email-masked]>
Date: Mon, 9 Mar 2009 10:13:53 +0000

> Or they've decided to take it out of scope ?

It was deemed out of scope - instead there was more focus on whether to
run a single DHCPv6 server in dual-stack environments, or to run separate
DHCPv4 and DHCPv6 servers (possibly on the same server) and then either
ensure responses are consistent or devise heuristics to allow differing
responses to be merged.   That's where RFC4477 ended up.   Also there was
then little deployment experience, and the text noted that and suggested
review when experience of issues grew.
 
Tim

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 9 Mar 2009 19:38:51 +0900

> review when experience of issues grew.

Thank you for nice summary.
Regarding deployment experience, which seems to be also important for  
us,
it helps a lot to to take a look at multiple interface handling in some
dhcp client implementation.

Regards,

---

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 13 Mar 2009 19:01:15 +0900

> Regarding deployment experience, which seems to be also important  
> for us,

I found that mif people assembled current practices on major OSes in
the following draft and referenced drafts.
draft-mrw-mif-current-practices-01.txt

I hope we can make use of them.