From owner-freebsd-net@freebsd.org Sun Apr 11 21:44:11 2021 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6B4C35DFAEB for ; Sun, 11 Apr 2021 21:44:11 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4FJQP64Kb3z4fQT for ; Sun, 11 Apr 2021 21:44:10 +0000 (UTC) (envelope-from kudzu@tenebras.com) Received: by mail-lf1-x131.google.com with SMTP id v140so18223029lfa.4 for ; Sun, 11 Apr 2021 14:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tenebras-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=a5QJDJhCMe1aN+kGqbezSzH1BzKYwnK2m9qkfLQqqi0=; b=oTL7ovgn6nGYf8Ygv1sw6u5MUcTXhd6vwaJYKw2HsJWdJeOWn9/hUhMg79GfMnbTmq 4pn9hZf1rboIzJ8GYrwoVnLzrDWNEgMJSTe/HxGYJ2BfLVqmPIIK5cnvywGH5B7Sqw9T 56jp72EEcYp9lDym6gINSaErOZDb7EpDsxLKs4y8+5r9qQhgTouPSyXXlqXUFmKABORZ IkokIsozhdihnJGVg+QKihyB5FUusr39mLm+4jyh2JTz6AWN7Mr0pACH721cgK66fiX4 1/ypSj3Xo4SJdvD1FUcQeOZhWq98uwx0/B1VzctHl9wOBx/i5YlRypC3bT4dLfyFJVD1 0pJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=a5QJDJhCMe1aN+kGqbezSzH1BzKYwnK2m9qkfLQqqi0=; b=kr0OQy1CNZB1/0zvQaYwr36WdC/di1IhopRoX2TBNKKjDmFgRXOFVucr4qQq3mn+zl jxa8mE8TF8x3yD53VIba1lzDB/85Ld1dhkzuczSo4pbYCEgXeKc7KMD9aXs5lLtj+1IJ WcF0jeUUmah/vkPn/Ffq0tmCqM9+DnUJvc+zY46gDWj/OQJ6Pqdh5loieBnsx566nkbn Bzwnvub1hjNio0Z8zqhIh6rO40dOGT7CMlZ+wccrrtjDR7w+/9rTsQ6yCqBXMUpo9ju6 lMRt510i1HdB8rvJTAYlYURrj59q5Xd+87c25hxorEzd4E1mTVNxgshVurXK+J0Lva/b bqiA== X-Gm-Message-State: AOAM533cnL100S9ufca6D0wGMPEwe9+SV/UOfXCCrWnabPFOSqbMniny QVk16yKm49cuydpq8KxCUE6S5+0fP0a/p8JyrfG1sg== X-Google-Smtp-Source: ABdhPJywFWjWyRB4GJV8i4xaWbVOmMzh3G0Trp3Sc6/ALDFTZ38xtlqew3GdMI6aChexZ9YCyMsDhl8+Fm1N62vIpUw= X-Received: by 2002:a19:f70d:: with SMTP id z13mr11806760lfe.275.1618177448629; Sun, 11 Apr 2021 14:44:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Michael Sierchio Date: Sun, 11 Apr 2021 14:43:32 -0700 Message-ID: Subject: Re: How to support QUIC with ipfw To: Matt Joras Cc: "freebsd-ipfw@freebsd.org" , FreeBSD Net X-Rspamd-Queue-Id: 4FJQP64Kb3z4fQT X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tenebras-com.20150623.gappssmtp.com header.s=20150623 header.b=oTL7ovgn; dmarc=none; spf=none (mx1.freebsd.org: domain of kudzu@tenebras.com has no SPF policy when checking 2a00:1450:4864:20::131) smtp.mailfrom=kudzu@tenebras.com X-Spamd-Result: default: False [0.77 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DKIM_TRACE(0.00)[tenebras-com.20150623.gappssmtp.com:+]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::131:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.93)[-0.925]; R_DKIM_ALLOW(-0.20)[tenebras-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(1.00)[1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; DMARC_NA(0.00)[tenebras.com]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::131:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::131:from]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-net] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2021 21:44:11 -0000 Sadly, no. That would be a great feature. The sysctl setting for dynamic rule lifetime is for all UDP. But since the firewall itself is responsible for most of the DNS and NTP traffic, I can write non-stateful rules for that. The recursive resolver on that port won't respond to outside queries for DNS, and NTP ignores commands from strangers. On Sun, Apr 11, 2021 at 2:32 PM Matt Joras wrote: > Hi Michael, > > On Sun, Apr 11, 2021 at 2:27 PM Michael Sierchio > wrote: > > > > On Sun, Apr 11, 2021 at 2:20 PM Matt Joras wrote: > > > > > Hi Michael, > > > > > > On Sun, Apr 11, 2021, 1:25 PM Michael Sierchio > wrote: > > > > > >> Hi, all. I noticed my firewall was dropping what seemed to be > unsolicited > > >> UDP connections from Google and Facebook, but this turned out to be > QUIC > > >> traffic. The traffic can be initiated by the browser (or other > supporting > > >> software) or the server. The problem is that dynamic rules generall= y > > >> don't > > >> cut it =E2=80=93 udp traffic here is predominantly NTP and DNS, and = the > dynamic > > >> rule lifetime for UDP is very short (3-6 s). And of course they don= 't > > >> work > > >> at all for traffic initiated by the server side. > > >> > > > > > > QUIC connections aren't initiated by the server. The browser is > initiating > > > these connections. I'm not an ipfw user, the best generic firewall > strategy > > > would be to have some sort of flow tracking for ~30s for UDP flows > > > associated with tuples originating on the client for remote port 443. > 443 > > > will cover the vast majority of Internet cases, as QUIC is only being > used > > > at scale for HTTP/3. > > > > > > > > Hej, Matt. Thanks. That's a solution that occurred to me, but it means = a > > ton of dynamic rules will get instantiated for ephemeral DNS lookups = =E2=80=93 3 > > seconds is a very long time for a conversation with a DNS server, becau= se > > it has probably recursed from the root zone all the way to the A record > in > > a fraction of that time. 30 seconds is forever =E2=80=93 well, since U= DP doesn't > > have an analogue to a FIN or RST, the rule doesn't go away when the > > conversation does. > > Is it not possible to do the dynamic rule instantiation for select UDP > ports, i.e. 443? That may cause issues if DNS-over-HTTP/3 becomes a > thing, but at least for now it would exclude DNS. > > > > > I'll get some metrics on it. Thanks again. > > > > > > -- > > > > "Well," Brahm=C4=81 said, "even after ten thousand explanations, a fool= is no > > wiser, but an intelligent person requires only two thousand five > hundred." > > > > - The Mah=C4=81bh=C4=81rata > > Matt Joras > --=20 "Well," Brahm=C4=81 said, "even after ten thousand explanations, a fool is = no wiser, but an intelligent person requires only two thousand five hundred." - The Mah=C4=81bh=C4=81rata