source address rewriting and shim6 proxies

[Erik Nordmark <[e-mail]>]

Paul Jakma wrote:
> On Tue, 27 Sep 2005, Brian E Carpenter wrote:
> 
>> Shim6 is not 8+8; the address changes take place in the end system.
> 
> 
> 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.

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 ISP

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

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