[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