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

Re: Shim6 proxies




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:

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

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 basiclly implies offloading the source locator selection to the site exit routers, agree?

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

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 managment issue for some sites.


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


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. 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, becuase 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 coudl define some form of delegating rights from the host to the proxy.

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

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.

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

Regards, marcelo


  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