[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