Re: [Spud] States in draft-trammell-plus-statefulness-00

[Brian Trammell <[e-mail]>]

hi Christian, Eliot, all,

We really need to go off and define a plus-protocol document that shows bits on the wire, so we can have this discussion with something more concrete to point at. (We'll be putting together an design and editorial team for that at the aforementioned side meeting today, and expect a first strawman -00 before the end of the year.)

But in the meantime...

> On 15 Nov 2016, at 03:56, Christian Huitema <[e-mail]> wrote:
> 
> On Monday, November 14, 2016 9:58 AM, Eliot Lear wrote:
>> The nice thing about TCP being stateful, however, is that the middlebox
>> has reason to trust how an end device is going to handle something that
>> is outside the state machine.  It's really well defined.  That's the
>> good part.

I'll take the opposite side of this argument, with respect to the state machine in -statefulness:

The signals in this state machine are *explicitly* only for the usage of the path. The association signals are exposed when the overlying transport decides they should be.

>>  The bad part is that then the state machine is ossified.
> 
> That's not the only bad part. Looking for SYN/SYN-ACK won't work if packets follow a new path after a route change, as could easily happen with multi-homing.

This state machine will continue to work as long as *every* packet, not just "first packets", carries enough information to extract an association signal.

> Also, the lack of authentication allows for the "spoofed RST" attack, in which injecting a single packet can cause connections to be dropped.

If the for-the-path stop signal is (1) integrity protected at the endpoints and (2) carries enough information to be non-spoofable (as in TCP, RSTs must be in-window, giving you 16ish bits of off-path guess protection; we'd want at least 32 bits), then off-path attacks are unlikely. The for-the-path stop signal is separate in this case from the (confidentiality and integrity protected) connection stop signal. On-path attacks remain, as with TCP, possible. But if every packet contains enough information to extract an association signal, the on-path state will simply cycle through closing-zero-uniflow and return to biflow.

How much state is lost and has to be re-established here is a different, and application-specific, question.

Cheers,

Brian

> That's why I would rather see mechanisms in which the magic packets have to flow in both directions. For example, a middlebox sees "drop me" coming from the left, and simply marks the state as "drop from left requested". If it receives a corresponding "drop me" from the right, the state is dropped. If on the contrary it receives a regular packet from the left, then it suspects spoofing and the state reverts to normal.
> 
> -- Christian Huitema
> 
> 
> 
> _______________________________________________
> Spud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spud