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

Re: Shim6 proxies


El 05/04/2006, a las 15:44, Scott Leibrand escribió:
On 04/05/06 at 10:05am +0300, marcelo bagnulo braun <marcelo@it.uc3m.es> 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