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

Brian Trammell <ietf@trammell.ch> Tue, 15 November 2016 02:57 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 0C4DE1299B6 for <spud@ietfa.amsl.com>; Mon, 14 Nov 2016 18:57:08 -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 n1vCzb8spn3D for <spud@ietfa.amsl.com>; Mon, 14 Nov 2016 18:57:06 -0800 (PST)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 202F712968C for <spud@ietf.org>; Mon, 14 Nov 2016 18:57:06 -0800 (PST)
Received: from dhcp-8920.meeting.ietf.org (unknown [31.133.138.32]) by trammell.ch (Postfix) with ESMTPSA id 22B581A05C6; Tue, 15 Nov 2016 03:57:02 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_6396A05C-0049-4B03-8E61-842679816711"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <013401d23ea8$c4d113f0$4e733bd0$@huitema.net>
Date: Tue, 15 Nov 2016 11:56:57 +0900
Message-Id: <BF78D471-9377-41A2-9233-2BE0937BDAB8@trammell.ch>
References: <E8355113905631478EFF04F5AA706E9831159645@wtl-exchp-2.sandvine.com> <835E355C-0AF1-4660-B0FF-8BEE0C54788D@trammell.ch> <03b101d23e9b$7c883540$75989fc0$@huitema.net> <dcefd280-3e2b-9b92-b333-ee87d7fb0aab@cisco.com> <013401d23ea8$c4d113f0$4e733bd0$@huitema.net>
To: Christian Huitema <huitema@huitema.net>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/IYcMdhOCpiScMURW_NaRL0KKE8E>
Cc: hildjj@cursive.net, mirja.kuehlewind@tik.ee.ethz.ch, Dave Dolson <ddolson@sandvine.com>, Eliot Lear <lear@cisco.com>, 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: Tue, 15 Nov 2016 02:57:08 -0000

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 <huitema@huitema.net>; 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
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud