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

Brian Trammell <ietf@trammell.ch> Mon, 14 November 2016 01:56 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C21F1293EE for <spud@ietfa.amsl.com>; Sun, 13 Nov 2016 17:56:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level:
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3WV28mRSbtWu for <spud@ietfa.amsl.com>; Sun, 13 Nov 2016 17:56:18 -0800 (PST)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1537E1295F2 for <spud@ietf.org>; Sun, 13 Nov 2016 17:56:18 -0800 (PST)
Received: from dhcp-8920.meeting.ietf.org (unknown [31.133.138.32]) by trammell.ch (Postfix) with ESMTPSA id BB5701A06A1; Mon, 14 Nov 2016 02:55:45 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_A1A4F83A-4318-4C5F-9888-E3377D29137A"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <E8355113905631478EFF04F5AA706E9831159645@wtl-exchp-2.sandvine.com>
Date: Mon, 14 Nov 2016 10:55:42 +0900
Message-Id: <835E355C-0AF1-4660-B0FF-8BEE0C54788D@trammell.ch>
References: <E8355113905631478EFF04F5AA706E9831159645@wtl-exchp-2.sandvine.com>
To: Dave Dolson <ddolson@sandvine.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/CtQzTwcBLfn1zjrqS3WYDSei3C0>
Cc: "hildjj@cursive.net" <hildjj@cursive.net>, "mirja.kuehlewind@tik.ee.ethz.ch" <mirja.kuehlewind@tik.ee.ethz.ch>, "spud@ietf.org" <spud@ietf.org>
Subject: Re: [Spud] States in draft-trammell-plus-statefulness-00
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Nov 2016 01:56:20 -0000

hi Dave,

Thanks for the feedback! Responses inline...

> On 11 Nov 2016, at 19:55, Dave Dolson <ddolson@sandvine.com> wrote:
> 
> 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 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.
> 
> As an alternative to adding a state, you could enter the bi-flow state only when the TCP 3-way handshake is complete.

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