IETF Logo Mail Archive

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

Brian Trammell <ietf@trammell.ch> Tue, 15 November 2016 05:08 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 2B0BB129473 for <spud@ietfa.amsl.com>; Mon, 14 Nov 2016 21:08:01 -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 xaJXRcTIHBvp for <spud@ietfa.amsl.com>; Mon, 14 Nov 2016 21:07:58 -0800 (PST)
Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4908B129A0E for <spud@ietf.org>; Mon, 14 Nov 2016 21:07:50 -0800 (PST)
Received: from dhcp-8920.meeting.ietf.org (unknown [31.133.138.32]) by trammell.ch (Postfix) with ESMTPSA id D6D851A1052; Tue, 15 Nov 2016 06:07:16 +0100 (CET)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_1A6D4A49-009B-4EA6-8794-4C5219D6BE3D"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail
From: Brian Trammell <ietf@trammell.ch>
In-Reply-To: <CALx6S34Vp3B3O9tHD4Q17-DJsa+3dsEnonm6Gq9J=hgVNFwH0A@mail.gmail.com>
Date: Tue, 15 Nov 2016 14:07:13 +0900
Message-Id: <52FC4F6A-73DF-436B-8A91-ADBA1A911DC6@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> <CALx6S34Vp3B3O9tHD4Q17-DJsa+3dsEnonm6Gq9J=hgVNFwH0A@mail.gmail.com>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/nu1U2yaf9qQMa-06y4HUNbESq3s>
Cc: hildjj@cursive.net, Eliot Lear <lear@cisco.com>, Christian Huitema <huitema@huitema.net>, spud <spud@ietf.org>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Dave Dolson <ddolson@sandvine.com>
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 05:08:01 -0000

Hi, Tom,


> On 15 Nov 2016, at 12:10, Tom Herbert <tom@herbertland.com> wrote:
> 
> 
> 
> On Tue, Nov 15, 2016 at 3:56 AM, 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.  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.
> 
> 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

> 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
> 
> 
> 
> _______________________________________________
> Spud mailing list
> Spud@ietf.org
> https://www.ietf.org/mailman/listinfo/spud
>

v2.23.0 | Report a Bug | By Email