Re: shim6 control packets coming from unkown locators

[Jari Arkko <jari.arkko@piuha.net>]

Marcelo,

>>
>>> 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?

We don't want to turn shim6 into a mobility protocol (at least
not in this RFC; if research projects have an interest in
looking at that they should feel free to do so and report
back to us later).

However, I think there are legitimate reasons for wanting to
update to a previously unreported locator even in multihoming.
As a result, I would be interested in seeing the Update capable
of doing that.

But this does not imply that we'd have to support such changes
in the middle of context buildup.

The Update change is easy. The one thing that worries me though
is Probe.

Making that work would need some extra logic.

Hm.

Lets make this a future extension.

Jari