Hi Erik, nice summary some comments below... El 28/09/2005, a las 21:08, Erik Nordmark escribió:
Paul Jakma wrote:On Tue, 27 Sep 2005, Brian E Carpenter wrote:There is not as yet any technical reason why this should be so. And if shim6 is to work with ULP's like UDP, then there isn't any good technical reason why the connection between ULP and the shim must be on the same host. If a technical reason comes along to restrict shim6 to having to be on same host, fine. If it doesn't, no reason to be arbitrary.Shim6 is not 8+8; the address changes take place in the end system.There are technical reasons that make this hard relating to the interaction of the shim, the way things are secured with HBA/CGA, and IPv6 address assignment.But we could actually talk about two different things in this space:1. A shim aware host sitting in a site and the host defers "source address selection" to the border routers.2. A legacy IPv6 host in a site and there is some shim6 proxy mechanism in the site that provides shim6 capabilities on behalf of the unmodified host.I and Tony Li explored the former a bit and one way to do such border router rewriting is in the NOID draft (which is probably expired by now).A couple of difficulties came up with border router rewriting:1. It is far from clear that there is a well-defined border router between a site and the Internet. Take a Univerisity and ask three people where the border router is and see if they have the same idea:- the network admin for one of the departments - the central IT organization - the ISP2. Blind border router rewriting (just replace the top N bits of the source address) assumes the host is configured with an IPv6 address in each prefix that the border routers know about, and is capable of "proving" that this is one of its locators. ("proving" using whatever means a shim solution uses to prevent attackers from redirecting your packets somewhere else). Thus there has to be some coordination between the allowable rewriting by the border router and the hosts; worst-case this implies rewriting rules on a per-host granularity.3. Folks have raised privacy concerns around shim6 (for small sites) if a host is using the same low-order 64 bits on all paths, and desire that different bit patterns be used for different prefixes. Such a requirement would conflict with blind rewriting by the border routers. The WG could of course decide which of such conflicting requirements one wants to handle and which one to skip.
The shim scheme currently proposed could perhaps accommodate something to support this flavor of proxy that you are analyzing here with some of the restrictions that you mention.
Suppose that we keep the shim protocol (whatever that is, but essentially a protocol with the e2e capabilities to establish a shim session, exchange a verify a locator set)
Suppose that we impose the additional restriction that he lower 64 bits must be the same for the different prefixes available in the host. (this can be easily done with HBA and CGAs) (this would imply as you mention that we loose privacy features indeed)
Suppose that we mark data packets belonging to established shim sessions, so that border routers can distinguish packets that can be rewritten (the shim bit)
Now, all these can be easily accomplished with current view of the shim protocol
Once that the shim session is established, it doesn't matter who actually selects the prefix included in the source address i.e. it can be selected by the source host or it can be selected/changed by any device on-path, as long as the prefix used is included in the prefix set negotiated for the particular shim session
I guess that the potential difficulty here is how the perceived prefix sets are coordinated between the host and the exit routers. I guess that the host needs to be aware of all the prefixes available, since he is the one that is providing the security for the association between them. So, the host needs to be know all the potential prefixes. If a border router uses a prefix that the host is not aware of, then this will be perceived as an attack and the packet discarded.
The routers don't need to know all the prefixes, just the one that they will stuff in the source address of the shim marked packets.
I am not sure i can see any difficulty with this... I mean in current multihomed site scenario, where the prefixes are quite stable and they change because of renumbering events associated to changes in the ISPs, the coordination of the prefix set perceived by the host and the prefix used by the routers seems feasible to me... In more dynamic scenarios, this may be require further analysis.
As i see it, we could support source address prefix renumbering by exit routers with current shim approach. the key for this would be to let security be handled by the shim hosts and not by the exit routers (i guess this is why this case is much more easy to approach that the proy case). the price would be privacy, since all iids for a host would be the same (supporting different iids would be quite more complex, since we would need to inform the exit routers about the available addresses...)
Of course, in this scenario, ingress filtering compatibility would be provided by rewriting of the source address, but only for the packets marked as shim packets. Failures would be handled different now, since the hosts would no longer have the capability of selecting the exit path (since the source address would be rewritten, instead of accommodating the path to the selected source address). I mean, the assumption that changing the source address would result in a change of exit path would be broken, so alternative mechanisms for selecting the exit path would be needed. This of course could be handled by the routing system i.e. injecting bgp information in the multihomed site
this approach would look more like current multihoming, i guess, since exit path selection is performed by the routing system
what difficulties am i missing? regards, marcelo
There are actually two approaches that can avoid the above issues, but as usual there is no free lunch. A. (I think Paul Francis suggested something like this a while back) Add an option to every data packet which indicates the allowed alternative source addresses. Thus the host says "I'm sending this with source address A1, but it's OK if a border router rewrites the source address to be one of A2, A3, or A4".This would make every packet header bigger.B. Put a hook in the RFC 3484 address selection mechanism to ask a site-wide oracle for advise on which <source, destination> addresses to prefer. This presumably only handles things when a new connection is setup thus can't deal with dynamic changes. Doing it for every (short-lived) connection might imply a lot of overhead and high load on the oracle.If you were thinking about the legacy IPv6 hosts and shim6 proxies, then there was some discussion on the mailing list (shim6 or multi6?) a while back. I can try to restate things on that front if there is interest.Erik