[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on draft-ietf-shim6-proto-03

Jason Schiller (schiller@uu.net) wrote:


The problem here is not not the multiple addresses, but rather a partial
ID / locator split.  As long as DNS contains information about both the
identity of the host and the location of the host then the ID and the
locator are not completely split.  This creates the problem of sifting
through DNS, and making the solution non-useful for short lived
sessions.  Also, this problem is what is creating the push for provider
independent (PI) IPv6 space to avoid "provider lock-in".
I'm not convinced. HIP provides complete separation between identity and location, yet it doesn't provide for any more network policy input than shim6. 


Imagine instead DNS only has knowledge of the identity, say the host
address, local subnetting and a way to uniquely identify the site.  The
source host builds a packet and kicks it to the network without the
locator information.  The network needs some mechinism to map the site
identity to one or more locators.  In this model the source host,
destination host, and DNS system don't care about location.  This is left
up to some protocol in the network.  On ingress this could be easy for the
source, just pre-pend your routing locator.  For the destination there
would need to be some mapping of site ID to one or more locators.  The
network could pick the most convient locator for the destination.
So we have a domain name to ID lookup using the DNS, and then be have some new system/mechanism for looking up an ID and find one or more locators, and that new mechanism takes network policy into account. Did I get that correct? Or does the new system also take reachability, available bandwidth, etc into account? 

Has anybody thought about the scaling requirements for this new system?
I would assume one should plan for success, and since the ID/locator separation will help with renumbering in addition to multihoming, this probably means that the system should scale to every site in the future internet using it. (I think during IPng discussion folks were throwing around 10^12 "networks" as the requirement, with 3 orders of magnitude more hosts.)
We have a system we think can scale to such scales; the DNS, so it is probably useful to look at how it scales: - hierarchical name space (and when that breaks down as with .com, operating the service becomes quite expensive) 
 - caching
This is why I think my above question about what information the mechanism takes into account is absolutely critical. If it is more or less static policy (which can be cached for hours) there is a chance that it can be made to scale. But we might also need the ID name space to have several levels of hierarchical allocation to scale the lookup.
But if we need to take into account information that changes more frequently, I think we're likely to end up with something that has the same scaling issues as BGP. There is no such thing as a free lunch as Noel likes to say.
FWIW, once we have the above, we still need a protocol that can provide the end-to-end locator agility (without creating a large security hole).
So the question in my mind, while we explore the above, is whether we would do shim6 any differently if we had the above ID lookup system. (Note that there is nothing in shim6 the protocol that assumes that the ULIDs are indeed routable addresses; it is merely a convenient way to deploy things and it doesn't have the overhead of doing some extra lookups for ID->loc mappings.) 


This same site ID to locator mapping protocol could be used by transit
ASes to rewrite the destination locator information and forward the
packet towards the destination at an alternate location.  Transit ASes
that don't wich to perform TE can simply forward the packet and do not
require the added site/locator state.


Are you assuming that
1) every packet would carry IDs (in addition to the locators)?
2) that the routers would do some lookups on the ID?
There is potentially a simpler way for routers to influence the locators, which is just having them do source locator rewriting (as in Mike O'Dell's GSE.) Shim6 already allows this on data packets, and maybe we should make shim6 allow that on its "control" packets as well. *If* we allow this, and such rewriting is useful, we can get that aspect of GSE behavior while having the "first, do no harm" security level present in shim6. 


I'm not sure this scales any better than de-aggregation as all ingress
routers and any transit routers that want TE will need state to map one or
more locators to every site.
The total size of the policy would be large. But if it is mostly static then it might be manageable. We can still do load spreading and primary/fallback with a static policy; the policy can be expressed akin to DNS SRV records with a priority (for primary/fallback) and a weight (for load spreading), and the client of the policy evaluates this.
If you want the policy to change due to dynamic events, even if it is just based on different policies for different times of day, then things get hard.
But this also assumes that anybody that connects is allowed to see the policy to be able to do the evaluation of what locator to use. That might run into trouble with existing practices.
An alternative would be to have some TBD mechanism (some new DHCP option?) for the destination site to distribute its policy (e.g., in the form of priorities and weights) to all the hosts in the site, and then use shim6 to express those to every peer that connects to a host in the site. 

Thus at a gross level I see two different ways to factor the system:
A. An ID->loc lookup system which takes some policy into account.

B. An ID->loc lookup system without policy, plus
   policy distribution within each end site and host-to-host exchanging
   of preferences when they start communicating.
For both approaches there is the question how useful it is to allow routers to rewrite the source locators.
I know how to build B out of existing components. But B doesn't allow a transit ISP to express their policy; only the end sites can do it.
On the other hand, I have no idea what the threat model is for A; how to make a distinction between a legitimate ISP on the path, and an attacker? 

Hmm - perhaps we should write this up in an I-D?
I'm sure there are more details to discuss, and I'd really like to explore this more to determine whether we need to do shim6 differently. And, from my understanding of approach B, the only open question in my mind is whether we need to make shim6 allow locator rewriting on its I1, R1, etc control messages. 

   Erik