Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks

Tom Herbert <tom@herbertland.com> Mon, 01 August 2016 20:52 UTC

Return-Path: <tom@herbertland.com>
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 8196312D8A5 for <spud@ietfa.amsl.com>; Mon, 1 Aug 2016 13:52:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 vXtiLJsOpuWN for <spud@ietfa.amsl.com>; Mon, 1 Aug 2016 13:52:16 -0700 (PDT)
Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 4233212D9F9 for <spud@ietf.org>; Mon, 1 Aug 2016 13:52:15 -0700 (PDT)
Received: by mail-it0-x230.google.com with SMTP id f6so255693093ith.1 for <spud@ietf.org>; Mon, 01 Aug 2016 13:52:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=t53FGuZ0ongnqELsjOCiE5I50wwsm8DGXIHZA0eUQP4=; b=bIEIbGW3dmu4gOSVpkFxq+56KgcnVTH4BRscQFxE7faiEpYE0G/2cAZJ+yH4bH3OXG 2LaYG5QknqsH6wUBsQGJr1GfhGJIHxOkwf/uuPf3cJX/+mRzz71dwmt1VEsneFXGSP72 b/J9ntjZqmjYjgfwvRq3b5jy0okSkpzLU8+ioatOnmKntVBExUfMtL186Kz2pL1Uny+5 oi7YFxA978M1jrxLKjKxAPyozi1jNU7845TLYJr3rk7GWSLoWWr1iKdpOBXBTMlZXUM7 iD9V7e7jtB/Zw5ROOnAxgE1xYCPjK+PJeiVZFCUDes7aHV7ULweVjIIgbLyb24ejDeox Ab0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=t53FGuZ0ongnqELsjOCiE5I50wwsm8DGXIHZA0eUQP4=; b=nKXbJNOp+juNrl8FMpspMzKWRInVZUjoHTxsx4fRG3q3EzrU8EHSHCr1m9hSENtgIO TGao4yu8LssCdOYOjvHXpG+zXdu5jM3QzVDlFU2i7pRHt3losASbbJlvwkdJry6+Euyu 07hiFaNoI9Z1RTE7qwNEg2692NHe833mwlmlFzM14S3NTf2WQ8y4N5HhlBfMnawOXzxr H67f22s0AqdSuzsaXE1dq6/SYVjY4HCPNyCGUwiTlPExZERsBTWi2Ta0DEu3zClNkQE7 Ladrkvy7wwpRMfQF/wrwiu/QF7Zd7KXUJyEzRZ0alXcaIJ2jWPFFqCIYFVieO4J33s3E lNpw==
X-Gm-Message-State: AEkooutGhZoyGb4DC19+h6PyTR/9Mw0Y86vURL3Zd0Q4mJ1mFah3KHfWVDzYmno6gv4jnmrcYarVvp2BY+SiBA==
X-Received: by 10.36.194.65 with SMTP id i62mr16262846itg.91.1470084734575; Mon, 01 Aug 2016 13:52:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.21.130 with HTTP; Mon, 1 Aug 2016 13:52:12 -0700 (PDT)
In-Reply-To: <BN6PR03MB26752FBA8655DA802A769450A8040@BN6PR03MB2675.namprd03.prod.outlook.com>
References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <d27266cf-87f6-17b1-3038-e0f614c6c773@cs.tcd.ie> <84F6AEC6-7DE3-4D1F-9014-201279F70E56@tik.ee.ethz.ch> <5194f988-0e25-7f5a-75cf-6ed3646e012d@cs.tcd.ie> <402A30BB-1A20-4D54-95CA-7C50D8C0F26B@tik.ee.ethz.ch> <dc29fa73-88fd-3dc4-7497-f1bd2fa60422@cs.tcd.ie> <8722FE8E-1026-43D5-BE17-1D6B4031C0D8@tik.ee.ethz.ch> <1b261e1e-a543-53df-8a2a-7dddae415a14@cs.tcd.ie> <D2CEDF13-E508-4732-B8F6-98FBBDDC7EE6@tik.ee.ethz.ch> <CALx6S34gVFDJ6mV=GVrfK5doTK2BbRRWXvxeqFUtidfPp5XGKg@mail.gmail.com> <5717b856-eaf9-4142-72fa-7e58b4cd61a5@artdecode.de> <CALx6S36zv4=S8tgRNqwee0j973Y_gJ7RBnnnV+0vBq_4kn7PVw@mail.gmail.com> <aa2afa2c-23d0-bf50-a82e-654fd08f373a@cisco.com> <CALx6S375si8km=8NhMfgWAtqE09Xju3CH1k3ktuae6gi8XT5ww@mail.gmail.com> <a2426583-22d7-85a1-e7a5-791c755f9209@cisco.com> <CALx6S37Ni=qA-BcnNQepRwe3ZC48RNmirRVjCe1fv2bT3gQnWw@mail.gmail.com> <CAKKJt-d02CmE7cW59s=A68SL=EQVTEVYOBzP74bnVXsEmfsY=A@mail.gmail.com> <CALx6S36paAxPP317aDGybkrPWtJ9L+ZuTYOHTQ11ejwUgJ7vFg@mail.gmail.com> <CAKKJt-efM3k5jL6EJmMP-t69SGNUyDxPu_xurvnGNtLSFZ87VQ@mail.gmail.com> <BN6PR03MB26752FBA8655DA802A769450A8040@BN6PR03MB2675.namprd03.prod.outlook.com>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 1 Aug 2016 13:52:12 -0700
Message-ID: <CALx6S34oC+OZuMpdzJ49f8Ew0qEnMOxxKX=mqDsausEsbWt0Ug@mail.gmail.com>
To: Christian Huitema <huitema@microsoft.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/FXWMWimf6IcYZNiBAWVAd505qYE>
Cc: Eliot Lear <lear@cisco.com>, spud <spud@ietf.org>, =?UTF-8?Q?Mirja_K=C3=BChlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, Brian Trammell <ietf@trammell.ch>, Stephan Neuhaus <sten@artdecode.de>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [Spud] [Privsec-program] Detecting and Defeating TCP/IP Hypercookie Attacks
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: Mon, 01 Aug 2016 20:52:17 -0000

On Mon, Aug 1, 2016 at 1:15 PM, Christian Huitema <huitema@microsoft.com>; wrote:
> On Monday, August 1, 2016 1:10 PM, Spencer Dawkins wrote:
>>
>> AH - I didn't realize you were talking about your proposal. I've read that. I lost any
>> reference to it in the post I replied to - hence my confusion.
>
> The question was whether it is a good idea to have special marks for packets that "start a connection," and specifically for packets sent over UDP by encrypted transports. Tom's point is that this will create breakage in many conditions, such as multi-homed nodes. I can see at least two scenarios in which we could see breakage with QUIC:
>
> 1) Client is sitting behind a nonplussed NAT. The QUIC session with the server becomes silent for a short period, and the client's NAT releases the UDP mapping. The client then sends more data. The NAT will assign a different port mapping. The server will use the connection-ID field in the QUIC header to route the packets to the right server, and automatically repair the connection. Suppose now that somewhere on path, maybe at the ISP router, some piece of software traces the connections and relies on "start of connection" marks. The "repair" packet comes from a different UDP port, and does not carry any "start" mark. Will it be dropped?
>
> 2) Client is sitting on a multi-homed network, managed by outgoing NAT. At some point, NAT management causes the packets to the server to be routed through the "fall back" ISP. The packets reach the server, the connection-ID filed does its magic, and the connection is automatically repaired. But of course, the routers on the new path don't see any "start of connection" mark.
>
> There are probably more cases, but these two can happen today, with shipping code and existing hardware. The NAT mapping refresh, in particular, is quite common. This is why I much prefer "implicit start" processes to "explicit marks."
>
The question is also whether we need to send an explicit "end
connection" signal. Network devices want this to know when to free
their connection tracking state, but in a multipath Internet I don't
readily how this would be a useful signal either.

Tom