Rewriting and proxies

[Iljitsch van Beijnum <iljitsch@muada.com>]

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.

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