Re: Shim6 proxies

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

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

> On 04/05/06 at 10:05am +0300, marcelo bagnulo braun  
> <[e-mail]> 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 default assumption) then the
>> source address selection actually determines the exit path form the
>> multihomed site.
>
> Not in today's networks.  Currently routers route on destination  
> address,
> not source address, so the destination address selection determines  
> which
> route is used to route the packets, which in turn determines which  
> source
> address you have to use if you want your packets to get out.
>

agree, but in case of a site with multiple prefixes delegated by  
different providers and where the providers perform ingress filtering,  
you need something like this...
It is not that i like it, but i haven't heard any better option yet...  
any ideas?

>> 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)
>
> I've seen assertions that sites implementing shim6 will want to choose
> their egress path based on source address.  But in today's deployed
> production networks, the only way to do that is by manually configuring
> something like PBR or VRF, which is roughly equivalent to static source
> routing.  There's no such thing yet AFAIK as a dynamic source routing
> protocol.

i know that this is not the way it is done today and i know that there  
is no dynamic support for this (at least the last time i checked)
still some form of source address based routing as the ones described  
in the draft seems to be the available options to deal with this.
please note that the shim6 protocol assumes that changing the source  
address somehow affects the exit path. I mean the shim6 host only can  
change the addresses, so the assumption is that a change in the address  
affects the path. If you consider the case of a host that has two  
addresses and it is communicating with a peer that has only one  
address, then all he can do is to change the source address, and this  
should imply some change in the path....


>
>> 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 full locator selection proxy as you mention, we  
>> require
>> per shim6 context state in the proxy, agree?
>
> Correct.
>
>>>> 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?
>
> Yes, although it would be equivalent to a non-routable identifier, and
> *not* part of the shim6 locator set.  (Strictly speaking, the ULID is
> still routable, but we wouldn't be using it for routing.)
>

but they would be placed in the DNS right?
i mean these are the IP level identifiers of the hosts, the IP  
identity, right?

>> And this address will be ULID used in the end to end shim6 context,
>> right?
>
> Correct.
>
>> 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
>
> Yuck.  That eliminates a lot of possibilities.

not sure what you had in mind, but maybe there is some way to make it  
work :-)

>
>> 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.
>
> Why must a ULID not used as a locator be a CGA or HBA?

Yes, what is more, a locator may not be included in the HBA set and may  
not be a CGA, as long it is signed by the CGA.
OTOH, the ULID must always be a HBA or a CGA. This is basically because  
the ULID is what you want to protect the most, since it is the identity  
of the host. We need to prove identifier ownership in order to prevent  
redirection attacks (see the threat analysis RFC4218)

>   If the end hosts
> don't support shim6, CGA, or HBA to begin with, why can't the proxy  
> just
> use HBA/CGA to generate a self-consistent locator set, and leave the  
> ULID
> (end host IP) out of that set?

no, the ULID must be part of the HBA set or the CGA

but, again, the host may acquire the address from the proxy, using  
DHCP, i guess

>
>>> 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 host'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?
>
> Not really.  What I'm thinking is that for initial pre-shim  
> communication,
> hosts would use the ULIDs directly.  Then, when shim6 negotiation is
> successfully performed, the locator set exchanged *does not* contain  
> the
> ULID as a locator.  The ULID is still routable in the general sense,  
> but
> since it's not a locator under the proxy's control, it is treated as  
> just
> an identifier and not a locator.

so the ulid is a routable/valid locator, but is simply not included in  
the locator set of the shim6 context?

what is the goal of this configuration?

>
>> and you would be losing some referral callback support in this case.
>
> I'm not familiar with was referral callback is in this context...
>

see http://www.watersprings.org/pub/id/draft-ietf-shim6-app-refer-00.txt

regards, marcelo


> -Scott
>