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

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 27 Feb 2009 15:32:04 +0900

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]