Re: Shim6 proxies

[marcelo bagnulo braun <[e-mail]>]

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
>