From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.zx2c4.com (lists.zx2c4.com [165.227.139.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 0B218C072A2 for ; Sun, 19 Nov 2023 13:45:25 +0000 (UTC) Received: by lists.zx2c4.com (ZX2C4 Mail Server) with ESMTP id 38e78a34; Sun, 19 Nov 2023 13:34:49 +0000 (UTC) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [2001:660:3301:8000::1:2]) by lists.zx2c4.com (ZX2C4 Mail Server) with ESMTPS id 25f6ec89 (TLSv1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256:NO) for ; Sat, 18 Nov 2023 12:22:21 +0000 (UTC) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 3AICM9Br003886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 18 Nov 2023 13:22:11 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/82085) with ESMTP id 3AICM9KV005678; Sat, 18 Nov 2023 13:22:09 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A36CB4449A; Sat, 18 Nov 2023 13:22:07 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=irif.fr; h= content-type:content-type:mime-version:user-agent:references :in-reply-to:subject:subject:from:from:message-id:date:date :received:received; s=dkim-irif; t=1700310126; x=1701174127; bh= nYcVXKVlv1ETZgy7miHoyMFRG25VY0yG0blwZ8Ol3IU=; b=Uvc/O79JqT/8n/aL HuTLwjQqf9POidqiOvU7YUW1AkzmyzchM4k84N+wxWkN9f/cQ0HX/5KLAB44Esn9 fxb/QGXdNvCnWkgi1o5zB5vZ1JJ+TXiNSqXgUfxH65An4LtPQv84BkEJjGWaDICo Zjzi4x1MwEvqt3DonTbmieao+JpVchfz8KSNlHG1ogHMtDgLSKRERZ/vGrOHqhBO 7cvJ1AIwAWQU5JyX9Lr7nmfJaP5d6u06QIiW+gk6mzytgeiRe9EFBd3d39LYvH2u FPjuk5t6+x/blMCDzTwmBD8MZxGz/RVdoMALtt9jqouWntbCBbsO3KmKGaw80ClD bKUxLw== X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id wcIyYWvOr0to; Sat, 18 Nov 2023 13:22:06 +0100 (CET) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0B12E44499; Sat, 18 Nov 2023 13:22:03 +0100 (CET) Date: Sat, 18 Nov 2023 13:22:03 +0100 Message-ID: <871qcn8d5g.wl-jch@irif.fr> From: Juliusz Chroboczek To: "Erin Shepherd" Cc: Daniel =?ISO-8859-1?Q?Gr=F6ber?= , "Alexander Zubkov" , babel-users@alioth-lists.debian.net, "Kyle Rose" , bird-users@network.cz, wireguard@lists.zx2c4.com Subject: Re: [Babel-users] [RFC] Replace WireGuard AllowedIPs with IP route attribute In-Reply-To: <918e1d5b-9f11-4f9c-bf9a-94cb0d41ce2b@app.fastmail.com> References: <20230819140218.5algu2nfmfostngh@House.clients.dxld.at> <4b-64e11f80-13-5e880900@8744214> <20230819212357.lkshcpslkgbeaq4e@House.clients.dxld.at> <20230828160705.a5uxv5l2zknna7yj@House.clients.dxld.at> <87v8czqd3w.wl-jch@irif.fr> <20230828221312.fw5pvnt4x7p2c52k@House.clients.dxld.at> <804a0c0a-78df-7f4c-1d0d-213e8bdb4120@nic.cz> <20231118021901.47kzvwn4pup4vkmg@House.clients.dxld.at> <918e1d5b-9f11-4f9c-bf9a-94cb0d41ce2b@app.fastmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/29.1 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Sat, 18 Nov 2023 13:22:11 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Sat, 18 Nov 2023 13:22:09 +0100 (CET) X-Miltered: at korolev with ID 6558AC71.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 6558AC71.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 6558AC71.000 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 6558AC71.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 6558AC71.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 6558AC71.000 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham X-Mailman-Approved-At: Sun, 19 Nov 2023 13:34:33 +0000 X-BeenThere: wireguard@lists.zx2c4.com X-Mailman-Version: 2.1.30rc1 Precedence: list List-Id: Development discussion of WireGuard List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: wireguard-bounces@lists.zx2c4.com Sender: "WireGuard" > Is tying source address filtering to the routing table the right thing to do > here? It seems to me that it would cause issues similar to those we see more > generally with Unicast Reverse Path Filtering Issues are caused by the kernel performing filtering that the routing protocol is not aware of: it causes the routing daemon's routing table to no longer match the effective forwarding table (the kernel's routing table). That's the reason why uRPF breaks most routing protocols, that's the reason why we have trouble making Wireguard work with Babel, and also the reason behind https://github.com/jech/babeld/issues/111. Contrariwise, we can teach Babel to explicitly take into account the kernel features that we're interested in using. Thus, Babel could be aware of the restrictions placed on a wireguard interface, and collaborate with Wireguard so that the routing table and the forwarding table remain congruent. I haven't looked at the issue in detail, but I believe that would be an interesting (short-term) research project, one that I would be glad to collaborate with (but not necessarily lead, at least not right now). For the specific case of source address filtering, Babel already has an (implemented) extension to deal with source addresses, and I encourage you to consider whether it can be used to deal with the issue at hand. Please see https://arxiv.org/pdf/1403.0445.pdf and RFC 9079. -- Juliusz