Re: [Spud] The reset middleboxes attack
Yoav Nir <ynir.ietf@gmail.com> Sun, 29 March 2015 20:11 UTC
Return-Path: <ynir.ietf@gmail.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 5F3EF1A88C1
for <spud@ietfa.amsl.com>; Sun, 29 Mar 2015 13:11:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,
DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,
FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 FEnwTmwK_AeJ for <spud@ietfa.amsl.com>;
Sun, 29 Mar 2015 13:11:22 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com
[IPv6:2a00:1450:400c:c00::230])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 95D861A88BD
for <spud@ietf.org>; Sun, 29 Mar 2015 13:11:22 -0700 (PDT)
Received: by wgbgs4 with SMTP id gs4so58791692wgb.0
for <spud@ietf.org>; Sun, 29 Mar 2015 13:11:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=content-type:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=i3WXQYfWsWlZYqx/0ZKfBRonWRyR/plJE518sBkIOTg=;
b=thzi4VC5kNIH/vScSGwVnOWtbaWNrVjli+Tr/47gl81NGrhF4IJ4j5RPjc2SA9MhCe
CQ3wOVZ4p8+jaDpw41Lj9Wy15JeJ8dPzePclMtY1ZrBAUCkvlnFkLfbidJURAiuuQk1W
jpBIQPrA/wfSvu/jU1iaKwce2Uh8C1ew1muoR62ja6BiVtiFmM81Tl2p2VTElUHfCW3j
XzjhZTYxv5wMPG+S0PFkdwwW1tn99BIIMmh6iHK8Qr/Mr3XAIUJX9qcdTNlduMAe0Dt4
1mnpHHtei0i+1X8muJQOP0X6yyVvteb17O2GyzgnJzCmkvTu183FbI7G8oXQpH9/7YWr
sQqA==
X-Received: by 10.194.78.231 with SMTP id e7mr54988612wjx.33.1427659881370;
Sun, 29 Mar 2015 13:11:21 -0700 (PDT)
Received: from [192.168.1.17] ([46.120.13.132])
by mx.google.com with ESMTPSA id gt4sm12535639wib.21.2015.03.29.13.11.19
(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
Sun, 29 Mar 2015 13:11:20 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <55184896.70504@nexenta.com>
Date: Sun, 29 Mar 2015 23:11:17 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <4166DC99-D326-48EB-A3A8-EB752669CBE7@gmail.com>
References: <DM2PR0301MB0655748F52C0984FB6BF8E93A8F60@DM2PR0301MB0655.namprd03.prod.outlook.com>
<33962F88-F1E9-4ED7-863A-97AED7836A75@gmail.com>
<CAMm+LwgsuvTzR9yMKZC00U8C+z_qwOL_FhKKNqbd4yxHYZQjQQ@mail.gmail.com>
<5789869D-9108-42D1-AA40-79C1BF46464B@gmail.com> <55184896.70504@nexenta.com>
To: Caitlin Bestler <caitlin.bestler@nexenta.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/0BvIyf9vM0VG9dqmoB-CkKmJJWk>
Cc: spud@ietf.org
Subject: Re: [Spud] The reset middleboxes attack
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Sun, 29 Mar 2015 20:11:24 -0000
> On Mar 29, 2015, at 9:46 PM, Caitlin Bestler <caitlin.bestler@nexenta.com> wrote: > > > > On 3/29/15 9:15 AM, Yoav Nir wrote: >> Routing on the internet can change at any time, so you can’t trust that for a particular TCP connection, a UDP flow or a “tube” all packets are going to follow the same path and pass through the same intermediaries. >> >> Fortunately, the stateful intermediaries, such a firewalls, QoS boxes and NATs tend to be placed at such choke points that all packets do flow through them. The exception is when one endpoint gets reconfigured, such as a mobile device moving from one network to another. TCP handles this gracefully by closing the connection (OK, that’s not really “gracefully”), and for UDP it didn’t matter, because there was no meta-data in the packets. >> >> With SPUD the “tube” will have meta-data in the packet, so either we copy TCP’s breakage when something changes, or we do something else. In the BoF we talked about the intermediaries being able to inject packets into the tube. I guess we could have them inject a “need-state” command when they detect what appears to be an already-open tube. In response the endpoints can send a special packet with the parameters needed at the OPEN command, affirming that this is indeed an open tube. endpoints whose address has changed could proactively send such packets to avoid getting blocked for a round-trip. >> >> > If a middlebox is doing something stateful then routing an existing TCP connection through it will not work. > That is how middleboxes work today. Right, but endpoints help along by resetting the connections when their IP address changes. SPUD being UDP, this will not happen unless we require it. > I cannot think of why a middlebox would be doing something stateful if they were not at some form of > check point. Middleboxes do not take on per-connection state because they are bored. True, but not all “stateful” means having to see all packets from the start. One of the use cases mentioned at the BoF was a video stream specifying its bitrate. If the address of an endpoint changes, that information can be retransmitted. Of course an anti-virus box scanning QUIC streams will not be able to continue from the middle. > Having a set of middleboxes somehow be aware that they form alternative routes to a protected domain, > and automatically share state and responsibility for protecting said domain is, to put it mildly, too ambitious > of a project for standardization. I hope nobody is suggesting that. Yoav
- [Spud] The reset middleboxes attack Christian Huitema
- Re: [Spud] The reset middleboxes attack Tirumaleswar Reddy (tireddy)
- Re: [Spud] The reset middleboxes attack Eric Rescorla
- Re: [Spud] The reset middleboxes attack Yoav Nir
- Re: [Spud] The reset middleboxes attack Phillip Hallam-Baker
- Re: [Spud] The reset middleboxes attack Yoav Nir
- Re: [Spud] The reset middleboxes attack Dave Dolson
- Re: [Spud] The reset middleboxes attack Caitlin Bestler
- Re: [Spud] The reset middleboxes attack Yoav Nir
- Re: [Spud] The reset middleboxes attack Bless, Roland (TM)
- Re: [Spud] The reset middleboxes attack Christian Huitema
- Re: [Spud] The reset middleboxes attack Bless, Roland (TM)