Re: Shim6 proxies

[Brian E Carpenter <[e-mail]>]

Excuse front posting but these comments are quite general.

What Scott is describing is essentially full offload of the
shim and the bottom part of the stack. We'd actually end
up with two IP stacks - one in the host which just sends
packets to the offload device, and a second one in the
offload device which has a shim on top of it. I'd want to
see a complete architecture for that including a demonstration
that the security architecture of shim6 isn't damaged,
and analysis of the trust model and threat model
between the host and the offload device. But if it can be
done, it has a very nice property - it actually offers
a practical way to implement something that works much like
8+8. The offload device will be state-heavy though; it will
need to carry state per session for every host it's supporting.

Whether that offload device is in the same rack as a few tens of
servers that it supports, or is a separate proxy for a few hundred
hosts, or is built into a site border router, seems secondary
in the architecture.

      Brian


marcelo bagnulo braun wrote:
> 
> 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
>>
> 
> 
> 
>