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

Re: Shim6 proxies


El 04/04/2006, a las 18:44, Scott Leibrand escribió:

...

locator selecting proxy == rewriting source address by exit routers
That's not how I see it. Since the source locator doesn't influence the 
path a packet takes, source locator rewriting matters most for getting
through source-address filters, and secondarily for influencing the end
hosts to use a different destination locators than they might otherwise.
not really, but i see your point. I think that there is a middle ground here, let me expand on this.
If you don't have source address rewriting, and we assume that ingress filters are in place (which seems the by defualt assumption) then the source address selection actually determines the exit path form the multihomed site. I mean, if a multihomed site wants to avoid that the ISP filters drop packets, then it must make sure that the packet is forwarded through the ISP that corresponds to the prefix included in the source address. So actually when the host selects the source address, it is de facto selecting the site exit ISP. (for more about this see http://www.watersprings.org/pub/id/draft-huitema-shim6-ingress- filtering-00.txt)
So, if you allow site exit router to rewrite the source address prefix, you are actually restoring to the intra site routing system the capability of actually selecting the exit path of a packet _given a destiantion_
So, here i agree with your point, the other part that needs to be taken into account is destiantion locator selection.
So, esd draft off loads part of the locator/path selection i.e. the source address prefix while the other part is still in the host itself.
The nice thing of this approach is that it doesn't need to store per shim context state. It just needs to be aware of the prefixes available in the site.
If we move to a foll locator selection proxy as you mention, we require per shim6 context state in the proxy, agree? 



To me, a full locator selecting proxy would do the entire shim6
negotiation, keep the locator sets internally, choose *both* the source
and destination locators to use, and supply preferences to the far side to influence which ones it uses. IOW, it would perform *all* the functions of the shim. This is substantially different from just rewriting source 
address,


agree that is different


 which doesn't give you any additional TE control unless it
influences the far side's destination locator selection.
but it does provides additional TE control by allowing the selection of the site exit path for a given destiantion, agree? 


the benefit of doing it this way as opposed to provide hints to the
hosts about which source address to use, is that the management of the
policy is in the scope of the routing system/admin, rather than in the
hosts themselves, which seems to be an important management issue for
some sites.


In order for the routing system/admin to have full TE control, he would
have to be in control of the choice of destination locator. By the time he gets the packets, it's too late for that, and all he can do is rewrite 
the source locator


so far agree


and hope that his rewriting sufficiently influences the
end hosts so that they switch to using the locators preferred by the
router.
but the effects of rewriting the source address are more important that just that, since it allows the routing system to actually select the exit path for that destiantion 


If you're going to do a full proxy, you have to go all the way IMO.
That means that for whatever locators the end hosts use, whether they
have multiple locators are not, have to be assumed to be fixed for the 
session, just like ULIDs.  The shim6 proxy would then intercept all
shim6 control traffic to that IP, and perform the shim functions on
behalf of the host. It would have a bunch of its own locators, which
would make up the locator set.  It could also include the ULID as one
of those locators, and intercept traffic to that IP with shim6
headers, or I suppose it could treat the host's IP as a non-routable
identifier for shim6 purposes and just use its own locators in the
locator set.  Either way, the proxy would process all shim6-tagged
traffic for the host, de-shim it as normal, and then pass the traffic
along to the host's IP instead of passing it up to the ULP.

Does that sound reasonable?  What problems do you see with such a
setup?


well at least one issue that needs to be addressed in this model is
about address delegation.
i mean, the shim6 security is based on using HBAs and/or CGAs.
This means that at least the address that is going to be used in the
host must be a CGA or an HBA set.


Couldn't the security simply be moved from the end host to the shim6
proxy?  You're still assuming end-to-end shim6 security, but if the end
host doesn't speak shim6 in the first place, the logical place for shim6 HBA/CGA security is not on the end host, but on the proxy where shim6 is 
actually being performed.


Yes, but that host needs to have at least one address, right?
And this address will be ULID used in the end to end shim6 context, right?
So, if this is so, then this address needs to be whether a HBA or a CGA, hence my previous comment applies.
That is, in the case of the HBA, it would be possible for the proxy to generate the HBA set and use something like dhcp to delegate the address to the host
Now, the host is not aware that there is anything special in that address(es) but the proxy knows that they form an HBA set, so he can use them in the shim6 protocol interchangeably as locators.
If the CGA approach is used, it is a bit more complex, since the ULID must be a CGA. Again the proxy can generate it, and delegate it to the host using dhcp. Now, since the proxy is aware of the private key of the CGA it can perform the shim6 protocol. But in this case, we still need to figure out what would happen if the host needs to use the CGa for some other protocol (e.g. SeND)
In the HBA case, the problem could be addressed if the host obtains the 
addresses from the proxy (e.g. using dhcp) and it configures the whole
HBA set. The point here is that the host cannot have any other
addresses, because if he use the other addresses, then the proxy won't
be able to run the shim6 protocol with those

If we are using CGAs, then the proxy needs to be aware of the private
key associated with the CGA (and the CGA parameter data structure) or
we could define some form of delegating rights from the host to the
proxy.


I'm working under the assumption that the end host *doesn't* do HBA or
CGA, but instead just does IPv6 with a single address (for each
connection).
yes but this address will be the ULID used in the shim6 contexts hence it msut be part of the HBA set or a CGA, see above 


 In this case the shim6 proxy would contain the entire
HBA/CGA set, and would perform all the security functions on behalf of the host. Since the host doesn't even know that this shim6 thing exists, he 
doesn't have to do anything special security-wise.


In any case, we need to figure out how this interacts with other host
based protocols that also use CGAs, like how do you run this with SeND
I can't say I understand CGAs well enough to comment on the implications 
of this...


The most obvious one is that if you use the host's actual IP as one
of the locators, you risk missing some shim6-tagged traffic if there
is more than one route to the host.


yes, but this is in the nature of the proxy approach, i mean, clearly
the shim would become a single point of failure in this case, but i see this as inherent of a solution of this type, and it still provides some additional fault tolerance for these hosts that don't support the shim6 
protocol
Yes, I would agree. And the more we talk about it, the more I think that a full shim6 proxy has to maintain the full locator set locally, and just treat the hosts's IP as a non-routable ULID, not as an additional locator.
ok, but in this case you would need a non routable prefix to assign non routable ULIDs, ULAs? and you would be loosing some referal callback support in this case. 

Regards, marcelo
That could be alleviated by only using local locators in the locator 
set, and treating the host's IP as an unroutable locator in shim6.
If you did that, I guess there's the same problem I complained about
in Erik's esd draft, which is that the host at the other end is forced 
to shim6-tag all packets and maintain shim6 state for the duration of
the session.


-Scott