Re: Entropy in headers for connection identification at a stateful firewall
Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Tue, 06 November 2018 09:08 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 AAC87130DDF for <quic@ietfa.amsl.com>; Tue, 6 Nov 2018 01:08:47 -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 5y8iYQX_tAZV for <quic@ietfa.amsl.com>; Tue, 6 Nov 2018 01:08:46 -0800 (PST)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 D0E431277C8 for <quic@ietf.org>; Tue, 6 Nov 2018 01:08:45 -0800 (PST)
Received: by mail-io1-xd2d.google.com with SMTP id t81-v6so8666759iod.10 for <quic@ietf.org>; Tue, 06 Nov 2018 01:08:45 -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=/Sc2s+aoZWhkVLtjlhDWk8brngvgyTQMMH++2OdE2o0=; b=bTFLPWw3HE4g2d5o/28sb0vHMnA2ssdMNmoH4cDkBrS5skfbzsQ1ND2D+Stylnoxrz cjF4QHuq+YPsz/8v9diyAHyoBDxGmHmoQ+Lsd/u7OxrwbxFfdkowD6rRPX1G/lBHhA7q Tk1X9jLqTxb7hAgy384I/XbrJqxh7XdJkAXoOCHp6hLidbuPMT9Q9rzdUwOkt7g45pZx LuI4ChcfA6a9pFHPCJApq9s7KAj2ZDqIxw24NPgyHZl4ZHzGKlapdnd2FeHkwE355HgP 1COqcsFe3bhiN6J5gGnEYLmyA/VymZHVKlfHVNDuSx7ZXV+w0ozKW6xVuRWlT0N78ZDr MYHQ==
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=/Sc2s+aoZWhkVLtjlhDWk8brngvgyTQMMH++2OdE2o0=; b=XhQnAjcW/j0EhhkemmfbQExS1Odk5hQrROANQ6WR/Yzkh3rZSZB+PiwvJnGryN5M3G 4SH2kyk7AlURwGQm2/NdwzqW7L4lwzl9d9k75VeMaemiohfVd+lsjk1BgDXkBT+gPPoG nwx3hNc8y6K8Ngu+TJtLR3u9V5hRFPSZxIOe0+O0v0myN7tkVcop1w1L7kYfiUpf5E90 R2u7bdWi1+DMpUbtstMVPFDQmwfunR9C8k3X6AcPB7xXOXZZt1cMB35f9fmsQn7cmMPC GfOcoCFFbWzncgoT93AGr50arvrQqN84tr4JdDCgF6YF+9qljQEzhEj0ZPwDHMUar0aV osMQ==
X-Gm-Message-State: AGRZ1gIpeKMv6wgeiBi1pO/mJ6f0yda2kgrQHDj20v+AzFQND5YZXWxc gUzx65CgizZIhqo2BgByvUWfSyFXFWsasHZgFr5BVA==
X-Google-Smtp-Source: AJdET5d2v7sYLVG7Ic23FCU5HdeaDm9SD12IFSv2Yk0Bs8uyN3Kv2WpDObflSVJ1M6fSjp3R3TFxZHZSs7ODxksz1TE=
X-Received: by 2002:a6b:ed04:: with SMTP id n4-v6mr7175739iog.106.1541495324690; Tue, 06 Nov 2018 01:08:44 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 6 Nov 2018 01:08:43 -0800
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
In-Reply-To: <CALZ3u+ZXhEtkLUiebQq=uy+cTU+k5sG9Hbe4eaKKcdm-usGiqQ@mail.gmail.com>
References: <CALZ3u+ZXhEtkLUiebQq=uy+cTU+k5sG9Hbe4eaKKcdm-usGiqQ@mail.gmail.com>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Tue, 06 Nov 2018 01:08:43 -0800
Message-ID: <CAN1APddd06DLjPMT2ZHCedgk_DnqGmv8DW+vtqOZa2juc4ndig@mail.gmail.com>
Subject: Re: Entropy in headers for connection identification at a stateful firewall
To: quic@ietf.org, Töma Gavrichenkov <ximaera@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000404e9d0579fb599a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/WYC0_FqH-REas7_AcmQX9M5FD_k>
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:08:48 -0000
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
- Entropy in headers for connection identification … Töma Gavrichenkov
- Re: Entropy in headers for connection identificat… Mikkel Fahnøe Jørgensen
- Re: Entropy in headers for connection identificat… Mikkel Fahnøe Jørgensen
- Re: Entropy in headers for connection identificat… Töma Gavrichenkov
- Re: Entropy in headers for connection identificat… Mikkel Fahnøe Jørgensen
- Re: Entropy in headers for connection identificat… Töma Gavrichenkov