El 20/07/2006, a las 14:15, Iljitsch van Beijnum escribió:
On 20-jul-2006, at 10:57, marcelo bagnulo braun wrote: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 PKIWe already have an infrastructure for TLS.
yes but the pki for issuing client certificates that bind IP addresses with public keys may be significatly different from the one available for TLS server certificates. In particular, the type of verification that is needed is different since in one case you must verify that the fqdn contained in the certificate actually belongs to the server, while in the other case you need to verify that the particular IP address belongs to a given person, which imho may be harder (since today addresses are not assigned as a unit but prefixes are allocated to lirs and lirs assign prefixes to end sites and then end sites assign addresses to hosts, so the verification of the trust chain may be harder imho
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.
this implies quite a few heuristics and special rules and interaction between the shim and the ulps... it may be possible but it may quite complex as well and it may require support from ulp
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.
agree, but from the shim perspective this is as good a nothing... i mean, it is clear that ipv6 hosts can communicate without using 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.
fwiw i don't expect patent problemsHBA technology is not one where the inventor of the technology is trying to push this technology in the standards so he can make profit out of it. Instead is the case where the HBA technology happens to fall inside a very broad patent claim made by other company. BEsides, the patent holder of this broad claim is claiming that it will not charge for the patent in case of HBA implementations.
The CGA case is a bit different since the inventor of the CGA technology has patented it, but still the patent holder is claiming that they will allow free of charge usage of the CGA technology for the shim protocol
regards, marcelo