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

Re: CGA Use with HBA in Shim6 IETF Meeting July 10, 2006



On 11-jul-2006, at 8:01, Pekka Savola wrote:

Recommendation: For now remove HBA and the use of ULID security
specifying HBA and leave it as work to be completed that avoids this IPR problem with CGA. Suggestion is to simply embed ULIDs within the data payload with new option and secure all communications at least for now for IP layer communcatiions with IPsec encryption based on locator pair.

How could this any-to-any IPsec (no prior relation to your peers can be assumed) be made to work?`

I think this potential solution path was hinted at the security directorate review we got some time ago,

And what would that be?

Let me repeat my suggestion from yesterday in a bit more detail:

In the absense of any information on whether there is even a patent claim on HBA itself or only on CGA (is there really no way to determine this?) we keep HBA but rather than make it the only and mandatory security mechanism (I'm unsure about the status for CGA but I'll assume that to be a variation of HBA for these purposes), we add an additional security mechanism.

What I'm thinking of here is not IPsec, as nobody has yet figured out how to run IPsec between two hosts without any prior coordination in the real world, but rather TLS. This could be as simple as doing the shim negotiation inside a TCP session encrypted with TLS. This means more and larger packets, and one end needs to have a certificate that leads back to something the other end trusts, so in some ways it's inferior to HBA, but TLS is widely implemented so adding this should be very simple and then people have a choice between HBA IPR issues or TLS PKI and performance issues. Last but not least, TLS security would make it a good deal easier to implement the shim in a middlebox.

Iljitsch