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

Wrap-up discussion about: Re: about the protection against on path attackers



Hi Iljitsch,

I am trying to close the issues that were discussed previously and i am not sure how to deal with this one...

El 02/01/2007, a las 15:04, Iljitsch van Beijnum escribió:

On 28-dec-2006, at 18:57, marcelo bagnulo braun wrote:

Also, for CGA verification, don't we need to send the other side a challenge to avoid replays?

I don't know if this is necessary...

Ah, ok, so the updates are their own challenge.

What I was thinking about was that the correspondent claims to have the secret key belonging to the public key, but you don't know that unless you see some data signed with the secret key that is particular to the session at hand.

context. In this case, we are in the Context confusion situation, and the host MUST NOT use the old context to send any packets. It
      MAY just discard the old context (after all, the peer has
discarded it), or it MAY attempt to re-establish the old context by sending a new I1 message and moving its state to I1-SENT. In any case, once that this situation is detected, the host MUST NOT keep two contexts with overlapping Ls(peer) locator sets and the same context tag in ESTABLISHED state, since this would result in
      demultiplexing problems on the peer.

What if an attacker is trying to interfere with legitimate communication? We must be VERY sure that the new shim messages come from the same host as the one that created the existing state if we're going to mess with that existing state.

THe current security level is that we don't provide protection against on path attackers. If an attacker learns the context tag, then it can do some nasty stuff, including destroying the established context. this is the level of security that we have defined for the protocol. We can discuss whether this security level is approapriate, but i would like to have a high level discussion on the issue.

I guess you're right. But as an added measure, I'd like to see that the old context isn't torn down until the new one is set up completely. This way, an attacker that somehow finds out a context tag needs to have return routability and do the full 4-way handshake to destroy a context, which is almost certainly not worth that much trouble.




This seems reasonable, but the problem with this is that in order to do that, you need to actually have two contexts for the same ULID pair and the same FII simoultaneously (even if they are in different states) I am not sure how would this work, and if this would work properly. I think it is much clear the case that there is only one context for a given ULID pair and FII which seems a basic assumption on the spec. so, again, current mechanism only provides protection to contexts from off path attackers and it is based on learning the context tag. If this is discovered by an attacker, it can tear down the context. OTOH, the spec just states a may tear down the context. If the node thinks he is under attack, it can keep the context (as long as it doesn't create a new one)

my proposal is to leave it as it is since introducing the possibility to have two context with the same ULID pair and FII may introduce some incosistencies in the spec, since the uniqueness of a context with a given ULID pair and FII was a basic assumption on the spec

Regards, marcelo