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

From: Dave Dolson <[email-masked]>
Date: Fri, 11 Nov 2016 10:55:34 +0000

Mirja, Brian, Joe,

I think it is an interesting idea to formalize/standardize the state machine that should be used by flow-stateful network equipment.

But having read about the four states and three timeouts, I feel you are missing a state after biflow that represents a fully proven connection.

I'm thinking of the problem of source-spoofed SYN attack packets that attempt to consume state memory in servers and flow-stateful network devices.
A network device may see client SYN and server SYN-ACK but never the completed 3-way handshake because the client is not real.

Until the 3-way handshake is completed, only short timeouts should be used. This is true for server as well as stateful network devices.

The nice thing about the client's ACK of the server's SYN flag is that it echoes back (in the ACK field) the SYN sequence number, which is unlikely to be guessed by an attacking node that doesn't own the address it used in the SYN packet. The ACK packet also carries the original client sequence# + 1, proving it has a stateful connection.

As an alternative to adding a state, you could enter the bi-flow state only when the TCP 3-way handshake is complete.

Does QUIC carry a network-observable signal indicating receipt of the server packet?

-Dave

---

From: Brian Trammell <[email-masked]>
Date: Mon, 14 Nov 2016 10:55:42 +0900

hi Dave,

Thanks for the feedback! Responses inline...

> On 11 Nov 2016, at 19:55, Dave Dolson <[email-masked]> wrote:
> 
> Mirja, Brian, Joe,
> 
> I’m thinking of the problem of source-spoofed SYN attack packets that attempt to consume state memory in servers and flow-stateful network devices.

The 3-way handshake is TCP-specific; other protocols will have different patterns. However, to generalize, it may make sense to require a two-way association signal before entering the biflow state, i.e.

[zero] --packet fwd--> [uniflow] --association rev--> [associating] --association fwd--> [biflow]

with the timeout remaining t1 for the associating state.

> The nice thing about the client’s ACK of the server’s SYN flag is that it echoes back (in the ACK field) the SYN sequence number, which is unlikely to be guessed by an attacking node that doesn’t own the address it used in the SYN packet. The ACK packet also carries the original client sequence# + 1, proving it has a stateful connection.
> 

We'd need an additional state to do this anyway, as above.

> Does QUIC carry a network-observable signal indicating receipt of the server packet?

Not yet defined; I'll be talking about this in QUIC tomorrow; see also my slides for that talk at https://www.ietf.org/proceedings/97/slides/slides-97-quic-flow-state-signaling-and-quic-00.pdf

Cheers,

Brian

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 14 Nov 2016 09:21:05 -0800

On Sunday, November 13, 2016 5:56 PM, Brian Trammell wrote:
>...
> Not yet defined; I'll be talking about this in QUIC tomorrow; see also my slides for that talk at 
> https://www.ietf.org/proceedings/97/slides/slides-97-quic-flow-state-signaling-and-quic-00.pdf

The basic connection state machine can be informed by arrival of packets in either direction and timeouts. This is indeed how most NAT handle UDP today, and it is independent of the protocol on top of UDP. It is also fairly robust to route changes, as the new traffic will naturally open the flows in the new route. The main drawbacks come from the use of timers. Too long and they use too much resource in the middle, too short and they require inefficient keep-alive traffic. On the other hand, since endpoints may well just drop off a route without notice, we know that timers are needed in any case. So, we could frame the problem simply as "can we find an alternative to timers for state management." 

My preference would be for standardizing some well-known magic packets with meanings like "keep me alive for another N minutes" or "drop me now", and to rely on bidirectionality to avoid vulnerability to spoofing attacks. Then, the onus would be on end to end protocol to incorporate or work around these magic packets.

The natural temptation is to go analyze the end-to-end protocol, but it can lead to complex code and ossification. I really wonder whether PLUS should do specific work for QUIC, by opposition to "generic work applicable to any UDP based protocol."  I am concerned that implementing protocol-specific logic in the middle of the network leads to ossification of that protocol, and in fact we saw hints of that with boxes that tried to recognize the version number field in QUIC. When the version number changes, these boxes detected an error and started blocking packets. Of course, this was incorrect behavior, but ossification precisely starts there, incorrect behavior distributed all around the network. 

The other concern is that if all the logic is protocol specific, then you need different logic for QUIC, DTLS, RTP, COAP and what have you. This makes the boxes more complex and more error prone, not to mention potential attack surface if these boxes attempt to parse complex protocols. Also, it creates another form of ossification, in which it becomes very hard for our grandchildren to develop the successor to QUIC.

- -- Christian Huitema

---

From: Eliot Lear <[email-masked]>
Date: Mon, 14 Nov 2016 18:58:26 +0100

Hi Christian,

On 11/14/16 6:21 PM, Christian Huitema wrote:
> On the other hand, since endpoints may well just drop off a route
> without notice, we know that timers are needed in any case. 

Yes, needing them and waiting for them to fire off are two different
things, right?  It's better to have a mechanism that cleans up sooner
than later.  If we have that mechanism then we use fewer resources
(memory) per flow on average and that in turn means supporting more flows...

> So, we could frame the problem simply as "can we find an alternative
> to timers for state management."
>
Yes.

> My preference would be for standardizing some well-known magic packets
> with meanings like "keep me alive for another N minutes" or "drop me
> now", and to rely on bidirectionality to avoid vulnerability to
> spoofing attacks. Then, the onus would be on end to end protocol to
> incorporate or work around these magic packets.

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.  The bad part is that then the state machine is ossified.

Eliot

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Mon, 14 Nov 2016 18:18:14 +0000

On 14/11/2016 17:21, "Spud on behalf of Christian Huitema"
<[email-masked] on behalf of [email-masked]> wrote:
>The natural temptation is to go analyze the end-to-end protocol, but it
>can lead to complex code and ossification. I really wonder whether PLUS
>should do specific work for QUIC, by opposition to "generic work
>applicable to any UDP based protocol."  I am concerned that implementing
>protocol-specific logic in the middle of the network leads to
>ossification of that protocol,

Premise: I agree that PLUS should be properly separated from QUIC.

I am concerned that making QUIC (standard) depend on PLUS (experimental)
for this pretty essential function can be tricky.

How do you think this should be handled?

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 14 Nov 2016 10:56:10 -0800

> good part.  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. 

Also, the lack of authentication allows for the "spoofed RST" attack, in which injecting a single packet can cause connections to be dropped. 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

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 14 Nov 2016 11:01:00 -0800

> How do you think this should be handled?

Realistically, although I don't like it, I assume that middleboxes will just
start inspecting packets and recognizing QUIC. On the other hand, QUIC
specifies an "abrupt disconnect" packet that looks pretty much like what we
would want a "drop me" packet to do. Aligning PLUS with that one way or
another could be helpful.

-- Christian Huitema

---

From: Brian Trammell <[email-masked]>
Date: Tue, 15 Nov 2016 11:56:57 +0900

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 <[email-masked]> wrote:
> 
>> 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.
> 

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spud

---

From: Tom Herbert <[email-masked]>
Date: Tue, 15 Nov 2016 12:10:51 +0900

On Tue, Nov 15, 2016 at 3:56 AM, Christian Huitema <[email-masked]>
wrote:

> 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.
>
> Networking maintaining state and multihoming was raised as a concern in
the BOF in Berlin. Has there been any work on how to resolve that in PLUS?

Thanks,
Tom

Also, the lack of authentication allows for the "spoofed RST" attack, in
> which injecting a single packet can cause connections to be dropped. 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
>
>
>

---

From: Brian Trammell <[email-masked]>
Date: Tue, 15 Nov 2016 14:07:13 +0900

Hi, Tom,

> On 15 Nov 2016, at 12:10, Tom Herbert <[email-masked]> wrote:
> 
> 
> 
> On Tue, Nov 15, 2016 at 3:56 AM, Christian Huitema <[email-masked]> wrote:
> Networking maintaining state and multihoming was raised as a concern in the BOF in Berlin. Has there been any work on how to resolve that in PLUS?

The current scope reduced to focusing on how to maintain state and the state machine defined in draft-trammell-plus-statefulness. This state machine, when driven by association signals derivable from each packet, will resynchronize state when a route changes on a multihomed network. (For multipath protocols, the transport association is made up of multiple flows, and the state is maintained on a per-flow basis).

Cheers,

Brian