Re: source address rewriting and shim6 proxies

[marcelo bagnulo braun <[e-mail]>]

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

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
>