[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Rewriting and proxies



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