[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:
FWIW i am not proposing not even defending this approach, just trying to
explore how this would look like...
Makes sense trying to understand the issues and tradeoffs.
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.
I am not sure about that...
I mean, in this case, probably the reachability test will be performed,
because an outage will be detected, and if no reply is received, the the
path exploration process will begin, sending packets with alternative
I mean, failure detection timers should be much shorter than session
lifetime timers, right?
Why would we want to couple the state management aspects of shim6 but
the shim6 test protocol? To me any such coupling seems undesirable,
especially since the parameters for the test protocol (how quickly to
detect failures) might be a function of upper layer advise, as well as
upper layer hints of "working" or "not working".
again i think that this is very much related with the failure detection
mechanism... i mean, in this case, the node that still has the state
(both for the shim and for TCP) will detect an outage and perform the
reachability test process and eventually the path exploration process...
I am wondering if all these issues could be addressed by defining an
error message as a possible response for the reachability test request
message, if you see what i mean.
Even if we decide to couple the state management with the test protocol
there would still be an issue. The test protocol is there to discover a
working locator pair. Just because a locator pair is working doesn't
mean that the peer has any context state for any particular shim6 context.
Thus you'd need a "context alive" probe in addition to the locator pair
I think we can come of with way to do state management which doesn't
require such added complexity.
I think that the problems with potential attacks using an error message
to cause nodes involved in a shim communication to discard their state
could be avoided by defining an error message that cannot be sent
spontaneously by one of the hosts (or an attacker) but that need to be
sent as a reply of a reachability test request message (including some
random seq number or similar)
Or sent in response to a data packet, but including enough of the data
packet (the locator pair and context tag) that are hard for an off-path
attacker to guess.
i am not sure what do you have in mind when stating that the error
message could only be generated by a mitm (considering that one of the
nodes has lost its state, so no previous cookie is available) but i
think that the defining an error message that can only be issued as a
reply of a previous packet could do the trick
I meant sent in response to a packet, so that only an attacker on the
path can construct a forged error message, as above.