Entropy in headers for connection identification at a stateful firewall

Töma Gavrichenkov <ximaera@gmail.com> Tue, 06 November 2018 08:39 UTC

Return-Path: <ximaera@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 72FEA1277C8 for <quic@ietfa.amsl.com>; Tue, 6 Nov 2018 00:39:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 FGJvG0EkPlnZ for <quic@ietfa.amsl.com>; Tue, 6 Nov 2018 00:39:25 -0800 (PST)
Received: from mail-yw1-xc34.google.com (mail-yw1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) (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 35D21130DCB for <quic@ietf.org>; Tue, 6 Nov 2018 00:39:25 -0800 (PST)
Received: by mail-yw1-xc34.google.com with SMTP id w135-v6so4836577ywd.2 for <quic@ietf.org>; Tue, 06 Nov 2018 00:39:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=4vonO9ohs0dChWj3gRzYgvlzEv20OeG6adgeEFlc4gE=; b=uiNey05Cnsic24oLeHQ22hEOR/3UEydwKp36E4hlN/sViWtiGV9NLDpIt5nHNzg+Kw hPOIR9BXtj+A1FqsErN1kKtKaz74ruD/1ufpzo9/3hCZ+NtVeI5M12YWDY23tLwF7T/P yftHN8ObjhJmI86NqpXkHbkN0uR2BGnPJdH6P+ffQRUTBpNAp62ytAPdadeAs69ra8Bp tTw11DSd47luxoC8edcYR3geDMkQAW0iacgYW1Hy2bQsRaeDAN+cMyfhlMZQhXNGr0CS T2KMZOxCQ4nqXhgfGMswRSoT54Q0aYzSi+aukmLG2vjOR4NpkKbvo7t817kjvHgXF6Dw AUPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=4vonO9ohs0dChWj3gRzYgvlzEv20OeG6adgeEFlc4gE=; b=AGGsxl0Ljdf6Ka5FP4rtLXOhH/J/vo5CRgS6nfWKE/azBKXBklZuqKnt42BJsUck3p Z7lAEZCsHH5pdINBIAeJ8dH/D87hRAeF6xmfmMV1u+KWRClePMMoey1lyoevSPUOjUno miQazcHrCdVH96UChFHOJS206mT4T/lfoAXzDEWi6FsrTQhP2AtfJRHZZwJMr01n1+si Ahw7pp4PJEyDxNZr3NoW5Lupa7eNCPlJHQ6u937bfmD+iMuetLmIUFzr1ynkZoLX4bFP 6ubMfHq+WKP+iFdxK0kuO0Ew5I567w0pB3zDqglNVXNpV5c4yiGqI534Y2yABcxSTt1W GlOQ==
X-Gm-Message-State: AGRZ1gJhKOO2RWl5FQZg7yPkxsGopIPbiPmcHSrpREe7v+cJS9eiZp8F dHIsAq8JVpScgpx0hJ8jHROTPIK77MuWXO6qReebT70vNOIOPg==
X-Google-Smtp-Source: AJdET5fK9bIJ/98m9Rg9068R1j9c8tJ7aF+WhMp0DP4up8k5Y5x35OKxaVPkItwUGabmKgJNnwTL7d04RfrjyVIDqtU=
X-Received: by 2002:a81:7cd:: with SMTP id 196-v6mr24358444ywh.178.1541493564003; Tue, 06 Nov 2018 00:39:24 -0800 (PST)
MIME-Version: 1.0
From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= <ximaera@gmail.com>
Date: Tue, 6 Nov 2018 15:39:11 +0700
Message-ID: <CALZ3u+ZXhEtkLUiebQq=uy+cTU+k5sG9Hbe4eaKKcdm-usGiqQ@mail.gmail.com>
Subject: Entropy in headers for connection identification at a stateful firewall
To: quic@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ZqPF68ouXg3U0Y2hsvTX0QTLyuk>
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 08:39:28 -0000

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