Re: Shim6 proxies

[Scott Leibrand <sleibrand@internap.com>]

On 03/28/06 at 8:57am +0300, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:

> Hi Scott,
>
> This topic has been discussed several times on this ml.

Cool.

> My understanding of this topic is that there can be basically two
> flavors of proxy-like devices:
> - on one hand, a proxy that basically performs locator selection on
> behalf of the host. In this case, the security functions are still end
> to end, but the locator selection is performed by another device,
> likely a router, that has more information about available routes
> and/or is managed by the network admins. This is basically what is
> described in draft-nordmark-shim6-esd-00.

That's not the impression I got.  It looks to me like
draft-nordmark-shim6-esd-00 provides similar functionality, in that the
routers can provide hints to the shim6 hosts that certain locators would
be preferred, but they don't actually perform the locator selection in any
direct manner...

> This seems an architecturally clean approach, since the locator
> selection function can be cleanly off loaded from the host itself, as
> long as the security remains e2e.

Perhaps, but I'm not sure what benefits a locator-selecting proxy would
have over simply rewriting the source locators in each direction, thereby
providing hints to the shim6-capable hosts of what they should do.

>  - on the other hand, there is the full proxy. this was discussed
> several times (most of times by Iljitsch). In this case, there is a
> proxy that establishes shim contexts on behalf of a non-shim capable
> node. In this case, the proxy performs all the functions of the shim.

This is more what I was thinking.

> Now, this seems to be an useful tool, especially for facilitating the
> deployment and providing some benefits of the shim to legacy hosts.
> However there seems to be certain questions that need to be answered in
> this scenario. For instance, does the host has one or many addresses? i
> mean is the host aware that it has multiple addresses or not? depending
> on the assumption here, different problems appear. Let's start by this
> point... what did you have in mind for this?

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?
The most obvious one is that if you use the hosts'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.  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

> El 27/03/2006, a las 22:54, Scott Leibrand escribió:
>
> > Has there been any consideration of the interaction of the proposed
> > shim6 protocol with a potential shim6 proxy?  I'm thinking it would be
> > quite useful to be able to place a device on-path near one end of a
> > TCP connection (i.e. on the default router), and have the device
> > perform shim6 functions (and possibly other multihoming duties) on
> > behalf of one or more host(s) behind it.
> >
> > -Scott
> >