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

Tom Herbert <tom@herbertland.com> Tue, 02 August 2016 17:03 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 6B38F12D0E5 for <spud@ietfa.amsl.com>; Tue, 2 Aug 2016 10:03:37 -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 AoF2QNShP0A2 for <spud@ietfa.amsl.com>; Tue, 2 Aug 2016 10:03:35 -0700 (PDT)
Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 116A212D0A6 for <spud@ietf.org>; Tue, 2 Aug 2016 10:03:34 -0700 (PDT)
Received: by mail-io0-x22e.google.com with SMTP id q83so219161363iod.1 for <spud@ietf.org>; Tue, 02 Aug 2016 10:03:34 -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=OoaEtL+UuwX1otuypPXGN7Ci8NQtaHXLHZxoW7bt60U=; b=P1wNh/Q47PD0kvoWq6+Sr1w5BTbn8pMJhu6nSdCdpzJh+NAX3nxB/FPIsWwXmhcZM0 /Av6vHCbXHoTCNktcMjY1jMMs3cTxOIE7hTdz5z43nQI6zPWyL9KpY0PHqdK6yuk+wE4 XMQ2HxCDjT0xjgryJIVG0X/W8TKuZJzQsvdtx1SeY/5U55EPFI6de7VnM8R1btk9bU9h xA2ylmCE5tqpu1efMUMgY5bOq0WLzhdoOGsdfmYhd8PozCOD3IHZR2KegaXiYh1KeDel CuNpxabNy+tLdWTpyW1UIHipoyy4dfnsM1y8uQCMSXFy3J4+SO5/V7d5o5UuZe93IAFc 9Dag==
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=OoaEtL+UuwX1otuypPXGN7Ci8NQtaHXLHZxoW7bt60U=; b=gKbzPnYW4izjVq0Km/LY9eLTsp/q9subjxWgnxL3wRnhV0gaLB2p626MsCn8iJhq1E nNq20QfU5jC97rheRjfHCKwnf2VenTFSTdfGITD+wUGitBGoYdT+hCJlHdw8gRV+fv4C aleuCWQ+dCgR5O3k3YxRUzTDy3yvXJ44XitZ5CdjVM8Pu0MuxVQErpjYPyInO2IxuIHO bWB+4hy1IvvB7lpONF8n9ZoyU19gsK4H+K4xDtZ4/QdxQxUwkDvkTqSuUDEnOyKXtGIe 8x6LOUcNtMy4UrG1beJYtIomtl9YxfGDRpshoDSmQqSMN9XjeTAbEPh+cy4u+UankqIo Q4MA==
X-Gm-Message-State: AEkoouvCoJnMyR1vv0kXJ7j9z6DlZyf2mFro4qLe3n2IsnBrvFKPzWS9KNLmjykgOcNVBummGYIhCJLJ9uN1RQ==
X-Received: by 10.107.25.75 with SMTP id 72mr63659271ioz.50.1470157413537; Tue, 02 Aug 2016 10:03:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.21.130 with HTTP; Tue, 2 Aug 2016 10:03:31 -0700 (PDT)
In-Reply-To: <214f5f15-5466-f93c-1d37-cb57398f4d1e@cisco.com>
References: <409B6F52-B637-4333-915B-A8127C80C98B@trammell.ch> <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> <214f5f15-5466-f93c-1d37-cb57398f4d1e@cisco.com>
From: Tom Herbert <tom@herbertland.com>
Date: Tue, 2 Aug 2016 10:03:31 -0700
Message-ID: <CALx6S36r-3QqKUXHJxeQCDam1WVGS4BUjtwUnPtT_btFTNG9yA@mail.gmail.com>
To: Eliot Lear <lear@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/tUKfMAd9bFwRjWhcVVczKtVuz_E>
Cc: 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>, Stephan Neuhaus <sten@artdecode.de>, Brian Trammell <ietf@trammell.ch>, 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: Tue, 02 Aug 2016 17:03:37 -0000

On Tue, Aug 2, 2016 at 12:47 AM, Eliot Lear <lear@cisco.com>; wrote:
> Hi Tom,
>
>
> On 8/1/16 10:06 PM, Tom Herbert wrote:
>
> TOU will negotiate a session identifier (similar to connection
> identifier) in QUIC. With this the TCP endpoints no longer use the
> 5-tuple to identifier the connection, they use the session identifier.
> This provides unambiguous connection identification that is
> independent of addresses or encapsulating UDP ports (the most
> immediate problem this resolves is NAT state remapping). Strong
> security is required to prevent connection hijacking and there are a
> couple of other caveats. Please look as section 3 in
> draft-herbert-transports-over-udp for details.
>
>
> TOU is similar in many ways to what HIP did in the early days, and the HIP
> developers had a pretty cool demo of it.  The threats we faced back then
> were nowhere near as advanced as they are today, nor are they as prevalent.
> There is not a single platform upon which you base your software that hasn't
> been attacked successfully, although some have been attacked more regularly
> than others.
>
> Let me be as clear as I possibly can be: I view a protocol that doesn't
> offer an answer to the question “who initiated the communication” as unsafe

Eliot,

With that view IP is completely unsafe and shouldn't be deployed since
IP source addresses can and are trivially spoofed. Session identifiers
with security that authenticates the peer provide an unambiguous and
far more trustworthy answer to the question about who initiated a
communication.

> to be deployed on the Internet.  I will make another bet with you, that at
> least half of your user base is running on old code with known
> vulnerabilities.  This is even more critical on battery-powered constrained
> devices, where a broad-scaled and sustained DDoS attack could drain those
> batteries and harm a lot of people, in a short period of time.
>
Yes, we all want DDoS prevention. But my application needs to be able
to run securely on _every_ network on the planet. Unless you can prove
that every one of these networks implements some common standard DDoS
mitigation and other required security mechanisms, then I really have
no choice but to treat the network is an insecure black box, assume my
applications are at risk, and implement all of my own security.

> If there are tradeoffs to be made in mobility design because of this, then
> those tradeoffs should be made.  But before you view it in that light,
> lengthy research has demonstrated that RF requires repeated selection
> queries to determine what is available.  That is the work done by SCTP
> researchers such as Randy Stewart, and so mobility isn't being traded off at
> all.
>
> You are seeking formal agreement of network behavior.  I am seeking an
> answer to my question.  If we formalize the answer to that question, then
> you have what you want and I have what I want.  I've been told that QUIC has
> such an answer to my question, which is good.
> I'd like to understand how that is accomplished in a secure manner.
> Certainly integrity protecting the 5-tuple and any sequence #s sounds like a
> good idea, to say the least, if it can be efficiently accomplished.
>

To be clear I am not seeking formal agreement of universal network
behavior (I believe that is supposed to be already covered by
networking layer standards), we are trying to resolve protocol
ossification to move the Internet forward. Protocol ossification
happens in the network when devices anonymous to the endpoints attempt
to interpret transport layer information to some effect and does this
without the auspices of any standard. Usually this is with benevolent
intent, but the problem is that when the end points attempt something
"new" (e.g. TCP fast open, new TCP options, using SCTP, trying sustain
connections between mobile networks) the network can break E2E
communication in a variety of ways because the communication doesn't
match _its_ concept of what a "legal" communication is. Encrypting the
transport layer is the only proposed solution to defeat protocol
ossification.

I don't believe the PLUS proponents will argue against the rationale
of encrypting the transport layer. Protocol ossification is a real
problem and we can demonstrate several examples where it has thwarted
innovation of transport protocols. What is at question is what
transport layer information hosts are either required or should
voluntarily "give back" once the transport layer is encrypted. IMO,
from the perspective of a large application provider, the default
answer is currently none. If signaling transport layer information
were to be explicit between hosts and network devices, and there is an
established trust relationship with an agreement the spells out the
precise use of the information and the scope of information
propagation-- then I think there is a much better chance to achieve
the cooperation necessary to solve things like the mobile DDoS problem
you mentioned above. I think the mobile guidance draft
(draft-flinck-mobile-throughput-guidance) is on the right track in
this regard, it make signals explicit and non-anonymous (although I
don't like the part where they allow middleboxes to parse and modify
TCP options, IMO this, as well as PLUS, should be using HBH options
for host-network signaling). Explicit non-anonymous signaling can also
adhere to the E2E model if network devices are expressly acting on
behalf of a host with specific directives to do that.

All of this is just my opinion, but it is why I had to hum no at the BOF...

Thanks,
Tom

> Eliot
>