El 31/07/2006, a las 13:11, Iljitsch van Beijnum escribió:
On 31-jul-2006, at 11:44, marcelo bagnulo braun wrote:it's possible that an implementation supports a certain security mechanism for authenticating its own stuff but not for checking the authentication of the other side,i am not following this...a host don't need security to check its own locator set, we assume that it has some local means to verify which its own locators are... (but i guess this is not what you were thinking about...)No, what I mean is: suppose only generating a HBA/CGA iid is covered by the claimed Ericsson patent, but checking the HBA/CGA isn't. Or the other way around.
that would be really strange imho.... i don't think we should be designing solutions based on possible applications of the IPR...
Then someone may want to implement only the part that isn't covered by the patent. Obviously in this case that's unlikely and not very useful because we need something that both ends can handle, but in the case of PKI-derived security this is a normal situation: if I don't have certificate for myself but I do have the root certificates I can check someone else's certificate but I can't protect my own locators with this security mechanism.
this otoh, seems a perfectly possible scenario, but basically what you are saying is that a peer can support different validation mechanisms (in particular other than the one it uses for its own locator set...)
So when we exchange capabilities, for the security stuff we need to have separate lists for what we support for outgoing locator sets and what we support for incoming locator sets.
but i think we can do this with the current spec (or at least sort of) since when you receive the locator set from the peer, the validation method may be different than the one the local host is using for its locator set, but still the local host can accept them, so i am not sure if we need to change anything here...
(the reception of packet is done solely based on the context tag, so it doesn't matter which source locator is used).I don't like this assumption...why not?Because then you can't get rid of the context tag.
you need some information to do the demux, and currently is the context tag. If we use other information, then you would look for this alternative information.... i guess it is coherent with current specs...
Does it make sense to have different authentication mechanisms for different locators?well, i think sosuppose you have a CGA/HBA addressyou can use the HBA mechanisms to move among a stable set of locators and you can use the CGA method to add new locators that were not present initially to the locator setOk.But is it worth the trouble to support this? We could say that if you want to add any locators outside your HBA set you must use CGA for the whole set. This way all locators share the same security mechanism which should make life a bit simpler. :-)
maybethe difference would be that instead of having a validation mechanism for each locator, you have it for the whole set.... but what if the next update message is using a different validation method? do we accpt that? is that an error?
regards, marcelo
On the other hand the trouble with CGA is that you need to send a challenge to make sure the other side really holds the secret key so validating the HBA locators using HBA has the advantage that you can use those while waiting for the response to your challenge to validate the CGA-only locators.Iljitsch