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 of
Ls(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 a
source 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?