Re: Entropy in headers for connection identification at a stateful firewall

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Tue, 06 November 2018 09:16 UTC

Return-Path: <mikkelfj@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5A7130F3C for <quic@ietfa.amsl.com>; Tue, 6 Nov 2018 01:16:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.998
X-Spam-Level:
X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zcwSiezbjoYJ for <quic@ietfa.amsl.com>; Tue, 6 Nov 2018 01:16:03 -0800 (PST)
Received: from mail-it1-x12b.google.com (mail-it1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 15912130E6E for <quic@ietf.org>; Tue, 6 Nov 2018 01:16:03 -0800 (PST)
Received: by mail-it1-x12b.google.com with SMTP id j79-v6so4737830itb.2 for <quic@ietf.org>; Tue, 06 Nov 2018 01:16:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=VV3miMvYtIlHVRAeFynYfOw5NJpHU8MOPDJmGVzXY34=; b=EZd0zCx4yxILbMLcrJ3JKpgXonXsyr4T/k/mbmYmdUxqHrJiMEAp9QBJ5ylIksDYcE +uORyvnaxpNbQWkhNOSXDfYC2MMpOqcJ9DHk94REVkfdjMshbrAgK6CFp7FPFzFR1Von w2gIo6vDsmdP8T5x3AcM6xquvQDBIBsrQX854XOMKA/th7k+ju1c6yXtmJD00SGmCqhd 7GMpZDjrPFI3M1JJ96hVsSoCFZSq+Zpo9yWeegU1954mrxRcUSxe+TXiu3JNqR9r853E mRd2Ex6xop2g60uejgT66dEK8ONp8aeX3XCSIs2dZ6ANg4Xq5ryEPmDEougP1l3pGKaR Bwhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=VV3miMvYtIlHVRAeFynYfOw5NJpHU8MOPDJmGVzXY34=; b=V0AifqaOhVStbTASUbTI1ReSXISnD/t6KXnpNEPVrXBZaR11/VszUSI9KTeB97x4gf aCmjEPwg32QhROGMYmnkmAnpgUtv2Ze4qF/nsQJxP+DaQFstUCHBJO8BEVZ7fVJ4LaZc pnYxviqFdfwhwTRPBhTOrdlqZrfjYr8svckUx4EriidqJ3WY/q4rEgtD0yn06n7Fo8Eg RyQYkEEJnwYXGtVv0nIUx4b7vICJZuJoR1ddQar2oyXEg4VxQHaBHcvuPFoyhcWMa4LR aGOqXo2iy0W7oU8G/OmFkVSKAsRyDCF8JDmelO7uuASKI9xeQ6ytjxDjxasOmra98x4I dpEg==
X-Gm-Message-State: AGRZ1gKxF28eEDhQLXYeIM3CsJvVah2By23erXphYnpsy4z8tcmZvCfy ssC+2kGZer/ItFFd95mABa1ft1sofizm0Kcim/fRmA==
X-Google-Smtp-Source: AJdET5cgNTZHYLDfiaEGxe9qHSoJUA3E+GAECeXc6VGzqoGSHEajeyFeXmUjS/8cgtbTQoHKqy3xq/9ouBm8b5B4sMs=
X-Received: by 2002:a24:1c85:: with SMTP id c127-v6mr1237118itc.148.1541495762372; Tue, 06 Nov 2018 01:16:02 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 6 Nov 2018 01:16:01 -0800
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
In-Reply-To: <CAN1APddd06DLjPMT2ZHCedgk_DnqGmv8DW+vtqOZa2juc4ndig@mail.gmail.com>
References: <CALZ3u+ZXhEtkLUiebQq=uy+cTU+k5sG9Hbe4eaKKcdm-usGiqQ@mail.gmail.com> <CAN1APddd06DLjPMT2ZHCedgk_DnqGmv8DW+vtqOZa2juc4ndig@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Tue, 6 Nov 2018 01:16:01 -0800
Message-ID: <CAN1APdftce=VFePqEMiMSAbthZSMPBEQg5XShYDs3s4_XME6DQ@mail.gmail.com>
Subject: Re: Entropy in headers for connection identification at a stateful firewall
To: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= <ximaera@gmail.com>, quic@ietf.org
Content-Type: multipart/alternative; boundary="00000000000056cf7a0579fb73cb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/5shawaY29EaJNmkhVSYqJVogZdE>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Nov 2018 09:16:09 -0000

I forgot to mention that in the case of a second RETRY, the client would
likely not start over but rather attempt to stick with the last attempt.
The middelbox RETRY will then be ignored. We recent had a discussion on
whether to drop or abort in this case - usually drop is the best action to
prevent abuse, but I’m not sure it is in all cases. Either way, the
connection setup is always vulnerable to attacks and QUIC does not presume
to be able to prevent all of these - it only picks low hanging fruits. Once
the handshake is in progress, it becomes much harder to interfere with the
connection (for both evil and well meaning devices).

Mikkel


On 6 November 2018 at 10.08.43, Mikkel Fahnøe Jørgensen (mikkelfj@gmail.com)
wrote:

Hi Töma

there is not much hope for the scenario you describe unless your firewall
cooperates with the endpoints on how the connection ID is generated.

QUIC actively seeks to prevent middleboxes from having insight into the
packet context for privacy reasons and to prevent ossifications (such as
one of your modules stop working on next QUIC version upgrade). You cannot
verify if a connection ID is valid without additional context.

QUIC allows for multiple connections on the same 5-tuple even if they
belong to different users with respect to access permissions.

The solution is to create an algorithm for the connection ID. This is
discussed in the QUIC draft but it only discusses servers. Server
coordination with firewalls are relatively easy because an organisation can
deploy those together. A connection ID can have a signature or pattern
known only to these deployments.

In your scenario you want to protect traffic towards the client (the user).
Typically clients cannot easily coordinate with a firewall. It would
technically be possible if the client sort of signed in with the
infrastructure, but the QUIC implemention needs to be aware and this most
likely forces a specific QUIC version and implementation.

If a middlebox experience excessive load on some 5-tuples or connection
ID’s it can issue a RETRY on new connections. If a client gives up a
connection due to timeouts etc. it might try to create a new connection.
This new connection might land on the same problematic middlebox. This
middlebox then issues a RETRY that informs the client to try to connect to
another server which hopefully lands it a on path that is not subject to
attack. A RETRY only has one level, so if the new location is also under
attack, the client must abort the connection attempt altogether and start
over from scratch. It might then get lucky for example by choosing a random
IP from a DNS record.

hope this helps
Mikkel


On 6 November 2018 at 09.39.44, Töma Gavrichenkov (ximaera@gmail.com) wrote:

Hello WG,

Consider, please, the following use case in your spare time:

An access network (to simplify things) doesn't host any listening
ports but rather just provides access to individual users. Some of the
users, or the network itself, have DDoS attacks in their threat model.
To address that, the network deploys a stateful firewall on or close
to its border, far away from the last mile that could get congested.

The said firewall doesn't allow incoming traffic towards the user
machines, except for the packets belonging to connections initiated
from the inside.

For the sake of simplicity, let's treat the bandwidth on the border
and computational resources of the firewall to be sufficient for
processing any incoming traffic.

With the Internet transport protocols of 1970s, one of the possible
attack scenarios would then be to generate a large number of packers
per second with a 5-tuple equal to a connection already existing on
the firewall. In real life scenarios, an off-path attacker already
knows 4 of 5-tuple parameters and just needs to guess the source port
number a client has chosen to connect. The entropy is then generally
limited to just 15 bits, which is believed to be not enough for proper
protection of long-living sessions given the attack bandwidth levels
observed today.

In theory, the attacker also needs a side channel to figure out
whether or not they have guessed the port already. In practice, the
attacker usually does have such a side channel. E.g. during an online
gaming tournament if one of the competing players experiences a
connectivity problem it almost immediately becomes obvious for anyone.

However, with TCP, we have SEQ and ACK numbers, which both add greatly
to the entropy of a 5-tuple. (And, yes, in reality you cannot rely on
proper SEQ randomness of a network client or server, but that's
another story).

The issue might be UDP, but in practice either the UDP "session" is
expected to be very short-lived (DNS, NTP, etc.), or the protocol is
not mission critical, or the protocol exposes a stable part in the
layer 7 header which could also be used for reliable connection
tracking. You'll have, however, to implement specific modules for each
such a protocol. (In fact, the rest of the protocols you don't know
what to do with could then just go through a fixed pipe with a
bandwidth rate limit much below anything that you might have at the
last mile.)

What I was going to ask for is an advice on how could such a threat
model be addressed if a client connects to a QUIC server. My first
intention was to write down connection IDs, but it turns out those may
change at will. The rest of the (long, let alone short) header is
fixed.

(I'm also present onsite in BKK, if that's easier for someone to ask
for any clarifications or explanations this way)

Thanks,

| Töma Gavrichenkov
| gpg: 2deb 97b1 0a3c 151d b67f 1ee5 00e7 94bc 4d08 9191
| mailto: ximaera@gmail.com
| fb: ximaera
| telegram: xima_era
| skype: xima_era
| tel. no: +7 916 515 49 58