Re: Shim6 proxies

[Scott Leibrand <sleibrand@internap.com>]

On 04/04/06 at 11:21am +0300, marcelo bagnulo braun <marcelo@it.uc3m.es> wrote:

>
> El 30/03/2006, a las 19:46, Scott Leibrand escribió:
>
> > On 03/28/06 at 8:57am +0300, marcelo bagnulo braun
> > <marcelo@it.uc3m.es> wrote:
> >
> >> - 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...
>
> not sure what part are you referring to, but i was talking section  3.4
>    Locator Rewriting by Routers , which basically extends the shim6
> protocol so that exit routers rewrite the source locator. This basically
> implies offloading the source locator selection to the site exit
> routers, agree?

Yes, but since source locators aren't used for routing (just for
filtering), to me that's less important than the influence the source
locator rewriting has on the choice of destination locator on the return
path.

> >> 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.
>
> i am not sure if i following you... for me
>
> 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.

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, which doesn't give you any additional TE control unless it
influences the far side's destination locator selection.

> 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 and hope that his rewriting sufficiently influences the
end hosts so that they switch to using the locators preferred by the
router.

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

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

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