[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 20-jul-2006, at 10:57, marcelo bagnulo braun wrote:
Same for DNS (X could check whether reverse A -> forward A -> B) but this is pretty weak also, as long as we don't have DNSSEC.
well, in addition is the added cost/latency of the additional DNS query
Since shim setup happens when communication is already ongoing, latency isn't an issue and as for cost... Well, I can afford it, I hope you can too. :-)
I guess I could live with either requiring a client certificate (especially as this could be one proxy certificate for a proxy that handles a bunch of clients) 


this is one option, yes, but it requires PKI


We already have an infrastructure for TLS.
or that new sessions may only be initiated by the client (server dumps all shim state when it needs to set up a session towards the client).
besides, this is kind of messy because the shime needs to be able to tell what a ulp session is, so that it is possible to distinguish which packets are part of a new session. In the case of TCP it may be easy, but in the case of unconnected UDP this is much harder... 

Yes, this is a good point.
So then it boils down to administratively controlling whether locator updates from unauthenticated clients are allowed (in the case of a server that never connects to a client) or not.
I expect nearly everyone to implement HBA anyway, but if some people really don't want it at least they have SOMETHING this way. Not having a mandatory security mechanism is possible here, IMO, as this simply means no multihoming benefits.
Not sure i understand this last sentence.... why would anyone want to implement the shim if no multihoming benefits are achieved?
If group A implements shim6+HBA and group B implements shim6+TLS, then members of A can still communicate with members of B, but without being able to activate the shim. While this is suboptimal, it's not problematic, so there is no reason to _require_ a certain security mechanism, especially if we expect patent problems.