[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: soft state (was Re: shim6 and bit errors in data packet headers
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
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
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.