Re: Shim6 proxies

[Scott Leibrand <sleibrand@internap.com>]

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.

> 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.

> 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.)

> 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.

> 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?  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?

> > 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.

> and you would be losing some referral callback support in this case.

I'm not familiar with was referral callback is in this context...

-Scott