Re: Rewriting and proxies

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

El 23/08/2005, a las 17:42, Iljitsch van Beijnum escribió:

> Hi,
>
> As I wrote a response to one of Paul's messages a few days ago it 
> occurred to me that if we add a demultiplexing header ("if" in the 
> sense that sometimes we do, but when we don't want/need it we don't) 
> we don't really need the source address in the packet for 
> demultiplexing anymore, so source address rewriting by routers would 
> be easy to do.
>
> Since the destination address is of very little use for multiplexing, 
> this means that pretty much all demultiplexing must be done based on 
> the demux tag, and also that these tags can't overlap between 
> different correspondents, which means that they must be allocated by 
> the receiver and not the sender. But I think 24 to 32 bits is enough 
> for this. We can add another two 4 bit or so fields that point to the 
> source and destination ULIDs so it becomes possible to have sessions 
> to/from different ULIDs share a demux tag.
>
> Are there any security problems with ignoring the source address on 
> demux? I guess it's slightly less secure than also considering the 
> source address, as someone who doesn't have the capability to spoof 
> the source address but does manage to find the source/dest-demux field 
> mapping can now spoof, while that person previously could not.
>
> With HBA/CGA we must depend on the lower 64 bits of the source address 
> for security, which makes implementation of the shim in a proxy or 
> middlebox harder, as we still need to get the real host (which doesn't 
> know about the shim) to use the HBA/CGA compatible address.
>
> One way around this would be for the shim proxy to intercept packets 
> from the hosts that don't implement the shim, and immediately try to 
> set up a shim-enabled session using an HBA/CGA compatible address. So 
> host A sends out a packet to host B with address A1(eui64), and the 
> proxy immediately rewrites this into A1(hba). If the shim negotiation 
> then completes, the proxy can inform the other side that the ULID is 
> actually A1(eui64) and everything works completely transparently. If 
> the shim negotiations fail, the proxy can either continue the session 
> and keep rewriting, which is faster but not very clean, or send the 
> original A1(eui64) packet.

But in this case, the ULID used by the proxied host and the ULID 
perceived the peer would be different wouldn't they?

If so, this would imply that the rewriting is no longer transparent to 
the upper layers, which i think we agreed that was not such a good idea 
(all the nat implications an so on)

An alternative that we discussed a while ago was to let the proxy 
assign the HBA/CGA addresses to the proxied host (through dhcp for 
instance) so that the proxied host has the correct addresses 
configured, and the proxy can use the security features of such 
addresses to secure the shim protocol locator exchange even if the 
proxied host ois not aware of it.

regards, marcelo


> In any case, there will be a slight delay. Of course, the proxy may 
> cache remote capabilities and not try to do any shimming towards 
> correspondents that didn't support the shim earlier. The main thing 
> that we lose here is the ability to upgrade a non-shim session to a 
> shim session.
>
> Alternatively, we can add an additional security mechanism that allows 
> correspondents to authenticate proxies without relying on HBA/CGA.
> Since presumably, having a shim proxy is something that will appeal to 
> non-tiny organizations, it could be ok to use a standard SSL (like) 
> certificate for this.
>
> Thoughts?
>
> Iljitsch