Hi Jari, In your review of the shim6 protocol spec you mentioned:
o Other control messages (Update, Keepalive, Probe): Deliver to the context with CT(local) equal to the Receiver Context Tag included in the packet. Verify that the IPv6 source address field is part of Ls(peer) and that the IPv6 destination address field is part ofLs(local). If not, send a R1bis message.Does this prevent properly handling a Probe if the peer did not bother to / did not have time to report the address as its own? I would expect that hosts might not report all addresses, if they have many, and if there's a sudden rehoming to a previously unknown prefix, the host HAS to send a Probe from this previously unknown address. This appears OK from a security perspective, at least if we are using CGAs and not HBAs.
later on, you mention that:
o An attacker which is present on the path so that it can find out the context tags, can generate a R1bis message after it has moved off the path. For this packet to be effective it needs to have asource locator which belongs to the context,Really? What if CGA is used, must the R1bis even then come from a previously known address?
In the shim6 protocol as currently defined, all shim6 control messages (after R2) must come from locators contained in the locator set known by the peer. this applies once the context has been established. For I1,R1,I2 and R2 other constraints apply. So, basically, Update messages, probe messages, R1bis messages, must come from a locator included in the locator set known by the peer.
I guess the motivation for this is that the shim6 protocol design was focused on multihoming and not in mobility
So, i guess it would be possible to update the spec in order to support receiving those messages from previously unkown locators. In the case of UPDATE messages could be easy, because we could require that the update message must contain the new locator that is being used as source address, signed. In the case of the probe message, it may be ok to receive messages from an unknown locator, but it wouldn't be possible to send packets to it until it hasn't been properly verified i.e. an update message signed has been received For the R1bis message, it would result in a reduction of security, since anyone knowing the context tag value could tear down a context even if he is not located along the path. this could be enough, though
So, the question is general for all the spec, should we support control messages from unknown locators?
Regards, marcelo