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

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

marcelo bagnulo braun wrote:

> FWIW i am not proposing not even defending this approach, just trying to 
> explore how this would look like...

ok
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 
> locators, right?
>
> 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 
test message.

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.

   Erik