IETF Logo Mail Archive

Re: [Spud] The reset middleboxes attack

"Bless, Roland (TM)" <roland.bless@kit.edu> Mon, 30 March 2015 14:35 UTC

Return-Path: <roland.bless@kit.edu>
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 F385B1A1EEA for <spud@ietfa.amsl.com>; Mon, 30 Mar 2015 07:35:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level:
X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3] 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 SIOINFOIHbah for <spud@ietfa.amsl.com>; Mon, 30 Mar 2015 07:35:21 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E3471A1BFE for <spud@ietf.org>; Mon, 30 Mar 2015 07:35:19 -0700 (PDT)
Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtp port 25 iface 141.3.10.81 id 1Ycamb-0002ox-O1; Mon, 30 Mar 2015 16:35:17 +0200
Received: from [IPv6:::1] (ip6-localhost [IPv6:::1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id A821DB0073B; Mon, 30 Mar 2015 16:35:17 +0200 (CEST)
Message-ID: <55195F25.8000007@kit.edu>
Date: Mon, 30 Mar 2015 16:35:17 +0200
From: "Bless, Roland (TM)" <roland.bless@kit.edu>
Organization: Institute of Telematics, Karlsruhe Institute of Technology
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Christian Huitema <huitema@microsoft.com>, "spud@ietf.org" <spud@ietf.org>
References: <DM2PR0301MB0655748F52C0984FB6BF8E93A8F60@DM2PR0301MB0655.namprd03.prod.outlook.com>
In-Reply-To: <DM2PR0301MB0655748F52C0984FB6BF8E93A8F60@DM2PR0301MB0655.namprd03.prod.outlook.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de 1427726117.
Archived-At: <http://mailarchive.ietf.org/arch/msg/spud/9YzToBmz6nNptdac1xnrlZ0bCpk>
Cc: Jana Iyengar <jri@google.com>, Eric Rescorla <ekr@rtfm.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: Mon, 30 Mar 2015 14:35:26 -0000

Hi,

> I can see that implementers may not be enthusiastic with the
> additional complexity. But we would be naïve to just dismiss the
> attack. We do see attackers capable of eavesdropping traffic, and
> then injecting packets "from the side." I am sure that these
> attackers would find good use of a capability to nuke connections at
> will.

The described approach would be still vulnerable to on-path
attackers, right? Furthermore, middleboxes must be prepared
that route changes may occur and they may see only the start
packet and maybe some data packets, but never the end packet.

Regards,
 Roland

v2.8.7 | Report a Bug | By Email