Re: soft state (was Re: shim6 and bit errors in data packet headers

[Erik Nordmark <erik.nordmark@sun.com>]

marcelo bagnulo braun wrote:
>


> But, the state can be rebuild using the initial exchange again, right?

How will A know in a timely manner that B has lost state, if B never 
responds?

> I mean, i am thinking in the following scenario (that i think Brian 
> suggested some time ago)
>
> Node A and Node B start a communication using IPA1 and IPA2 respectively,
>
> A while after, they decide to create a SHIM context, for this 
> communication. For that, the perform the initial exchange and the 
> continue the communication for a while.
>
> At this points i can think about 3 scenarios:
>
> 1- the "normal" situation i.e. there no abrupt lost of context for 
> external reasons. In this case, each packet received corresponding to 
> that context would extend the lifetime of the context information. If no 
> packets are exchanged for a given period T, then both ends discard the 
> state. I guess T should defined in a conservative way, i.e. long enough.

Such an approach isn't robust in the presence of packet loss.
A could be sending a few packets, but B might never receive them due to 
random packet loss. So you end up with B discarding the state while A 
thinks B should still have the state, since A sent packets to B.

FWIW the CLOSE exchange in draft-ietf-hip-base-02.txt avoids this 
problem by basing the "should I time this out" on the receipt of 
packets, and not due to packets being sent.
I think you'd need a similar approach in a semi-hard-state approach to 
shim6.

> 2- One of the nodes reboots and all state is lost. In this case, it 
> doesn't make much sense to rebuild the context, i think, because the 
> upper layer state has also been lost, so i guess it doesn't make much 
> sense to try to resume the SHIM context when there is no upper layer 
> that wants to preserve a communication

The problem if you do nothing, is that the upper layer would not find 
out in a timely manner. For instance, TCP would not receive a reset 
packet when the peer has rebooted, because the shim layer would pass up 
a TCP packet with a bad checksum (due to not having replaced the 
locators with the ULIDs).

So if you do nothing you are most likely making the notification of a 
upper layer state loss a lot worse than it is without shim6.

> 3- There is some abrupt lost of context state in one of the nodes (and 
> only the context state. (i am not sure how likely this is, i mean i 
> guess it could happen when because of the soft state, one of the nodes 
> discards the state before its peer, and after that the peer wants to 
> resume the communication associated with this context. I guess the 
> occurrence of such situation becomes less likely, as the inactive time 
> required to discard the context grows). In any case, suppose that 
> suddenly node A losses its state about the SHIM context. At this point, 
> node B would detect that the context has been lost. How this is 
> detected, is to be analyzed in depth.
>    - If the communication was still using the ULIDs as locators,
>      then data packets will flow without problems and no problem
>      is detected. I guess that for this case, a SHIM keepalive
>      may be needed to detect this case
>    - If the communication is using locators that differ from ULIDs
>      then, i guess that upper layers will send an error message
>      back, like port unreachable or similar, so that the context
>      loss can be detected

NO, NO, NO.
The upper layer packets will be silently discarded with a checksum error.

>    - If SHIM signaling packets are sent by node B, the absence
>      of replies would indicate that an the context has been lost
>
> At this point, when node B detects that the context state has been lost, 
> node B can try to perform the initial exchange again, using the same 
> information that was used during the initial exchange the first time. I 
> think this would permit node A to rebuild the lost state
>
> I think this soft state could work without requiring the error message.

And I think it is at least very hard. The protocol would be more robust 
with an error message.

And since we are not trying to build a security protocol - we just don't 
want to make things less secure than they are today - an error message 
which will only be believed when generated by an on-path node, should be 
ok even if it makes the peers re-establish the shim6 state.

> But in any case, note that through error message spoofing the attacker 
> may manage to impose that the context is re initiated while the 
> communication still flows (in the case that the ULIDs are still being 
> used as locators) That would allow an attacker that has a compatible CGA 
> parameter data structure for instance to place himself in the middle of 
> an ongoing communication.

But getting a compatible CGA structure is hard.

   Erik