Multiple security mechanisms

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

[BTW: I'm reposting three messages from last week that I don't think  
made it to the list.]

How about the following to move forward in the dicussion on HBA/CGA  
patent issues and the need/want for other security mechanisms:

I still have to do a full review of the shim6 proto spec, but the way  
I understand it, today, the security mechanism (HBA) is either an  
integral part of the signalling, or it's encapsulated into the shim6  
signalling protocol.

What if we make this the other way around? So we isolate the shim6  
signalling from the security and then allow multiple security  
mechanisms to encapsulate the signalling and send it over the wire  
using appropriate mechanisms. For the current stuff this would look  
like this:

[shim header][shim signalling][HBA/CGA]

or

[shim header][HBA/CGA][shim signalling]

The changes, if needed, should be minimal: just move the HBA/CGA  
stuff and the shim6 signalling to opposite ends of the packet so they  
can be easily separated.

Then, if someone were to take it upon themselves to specify shim6  
with TLS security or shim6 with IPsec security, that would look like  
this:

[tcp][tls([shim signalling])]

[esp([udp][shim6 signalling])]

[ah][udp][shim6 signalling]

Additionally, the TLS/IKE people can define extensions to their  
protocols to signal the capability to do shim6 and if both sides  
support it and the necessary prerequisites are met (certificates at  
both ends, for instance), they can trigger a shim signalling exchange  
protected by TLS or IPsec so we wouldn't need to implement complex  
capability negotiations in shim6, and if desired, the shim6  
signalling can be encrypted for additional security.