marcelo bagnulo braun wrote:
The question is: what does A does when it detect this context confusion?There seems to be reasonable to continue with the new context establishment, using CT(B) for this new context, but what does A does with the old context?There are two proposed approaches: - Discard the old context - try to reestablish the old context with a different context tag for B
I think the requirement on an implementation is that it must not send any shim6 packets using the old context. I think there is an implementation choice whether it does this by just discarding the old context, or whether it discards it and immediately recreates it. (The recreated context would have different context tags, so there wouldn't be any confusion.) One could even envision implementations that would use local information (such as whether there are open sockets) to choose whether it makes sense to recreate the old context or not.
Now, the problem with discarding the old context is that this may open the door to some form of attacks, when an attacker that discovers a context tag and a valid locator of a given peer, can easily, by just sending a I1 message make the victim to discard the state. In other words, if we have the scenario above with A and B having an estasblished context, an attacker can simply send an I1 message to A that includes the CT(B) and an ULID option with B's address and this would cause A to discard the context with B. Of course, it would require that the attacker knows CT(B) and B's address, would this threat be acceptable? An additional option would be to delay context teardown of the old context until a I2 or an R2 packet is received, making sure that we can track down an attacker....
I don't think we need to tare down the old on reception of an I1. An I2 or R1 (don't have to wait for R2) would be better. Thus we'd do the implicit return routability check in addition to the context tag having to match; the combination of those makes it very hard for off-path attackers to cause the taredown.
Erik