Re: [Spud] The reset middleboxes attack

Yoav Nir <ynir.ietf@gmail.com> Sun, 29 March 2015 16:15 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 9590A1A890E for <spud@ietfa.amsl.com>; Sun, 29 Mar 2015 09:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.101
X-Spam-Level:
X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 pZkTZIuqPKIg for <spud@ietfa.amsl.com>; Sun, 29 Mar 2015 09:15:35 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (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 13C621A890B for <spud@ietf.org>; Sun, 29 Mar 2015 09:15:35 -0700 (PDT)
Received: by wibg7 with SMTP id g7so72636420wib.1 for <spud@ietf.org>; Sun, 29 Mar 2015 09:15:33 -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=o43m5JIcMLmtmBgq5GevCvs/D1W8guFnRoR/VvJRSjI=; b=JBqsdBcQpD40IVDGBxrmBqJ/5Vm3z61GlwKb+bh/hmsE2NDf3ViULQ/nCZoFaigsqv h2P+pv49aRtx+z3L0IdjyS4pyGXRTRJBtSbBVS44HH17hNn36cqkb6+l30p9duB28Lxi CnVuhecboQuGwYtmSpuzJnWS5rCvoH2HFyh5fguGbUWiE1nv6mu+NCAlJZhxwFXyBrIN /THFKoRM+nR3Ts/92wHA/1nrFlOeHu49WhKrSTajzZ7PuI6UUpENSx+M8Tej9OHrTWKR dUgW0VtlEJWrWncOR8wmOZbOdOvXA87lQ9gbyUzeVoS3QhpCpO1+XYfVCsBGJ2U5yiK9 zxhQ==
X-Received: by 10.180.102.130 with SMTP id fo2mr14353665wib.30.1427645733770; Sun, 29 Mar 2015 09:15:33 -0700 (PDT)
Received: from [192.168.1.17] ([46.120.13.132]) by mx.google.com with ESMTPSA id fm10sm11774245wib.7.2015.03.29.09.15.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Mar 2015 09:15:32 -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: <CAMm+LwgsuvTzR9yMKZC00U8C+z_qwOL_FhKKNqbd4yxHYZQjQQ@mail.gmail.com>
Date: Sun, 29 Mar 2015 19:15:30 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <5789869D-9108-42D1-AA40-79C1BF46464B@gmail.com>
References: <DM2PR0301MB0655748F52C0984FB6BF8E93A8F60@DM2PR0301MB0655.namprd03.prod.outlook.com> <33962F88-F1E9-4ED7-863A-97AED7836A75@gmail.com> <CAMm+LwgsuvTzR9yMKZC00U8C+z_qwOL_FhKKNqbd4yxHYZQjQQ@mail.gmail.com>
To: Phillip Hallam-Baker <phill@hallambaker.com>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/0UqtBECvUqHHLrd21hLOz-C_w3o>
Cc: Christian Huitema <huitema@microsoft.com>, Eric Rescorla <ekr@rtfm.com>, "spud@ietf.org" <spud@ietf.org>, Jana Iyengar <jri@google.com>
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 16:15:36 -0000

> On Mar 29, 2015, at 2:58 PM, Phillip Hallam-Baker <phill@hallambaker.com> wrote:
> 
> On Sun, Mar 29, 2015 at 4:28 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
> 
>> Hi, Christian
>> 
>> I understand the issue. Is this something we are really worried about? It has always been possible to do this with TCP by sending a RST, and that worked on the endpoints as well, and TLS has never protected us from that attack.
>> 
>> To get the solution to work, presumably the initiator generates a secret and sends its has in the OPEN command. This allows the initiator to close the connection by sending the pre-image. But what if we want both sides to be able to close the connection? We either need to transmit the pre-image in the encrypted part of the protocol (what Joe’s architecture diagram calls “transport”), or we need a per-endpoint hash, requiring the responder to also send a hash in the ACK command. The latter doubles the state on the middlebox.
> 
> The problem with state these days is not size. It is the fact you need
> state because once a path is stateful it is fixed.

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.

Yoav