From nobody Sat Apr 23 01:57:42 2022 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F3CD31A86760 for ; Sat, 23 Apr 2022 01:57:53 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KlZDJ6H6tz3sw9; Sat, 23 Apr 2022 01:57:52 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:3c04:dbac:3dcb:cb4d]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id AED97721E2808; Sat, 23 Apr 2022 03:57:42 +0200 (CEST) Content-Type: text/plain; charset=us-ascii List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored From: tuexen@freebsd.org In-Reply-To: Date: Sat, 23 Apr 2022 03:57:42 +0200 Cc: Florian Smeets , Michael Butler , freebsd-current@freebsd.org, melifaro@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <43CF838A-0C48-4ABC-8A5F-FBC0C39B21AA@freebsd.org> References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> <7cd2e76a-c6d1-e8d7-b9fb-b8797f1ca731@smeets.xyz> To: Gleb Smirnoff X-Mailer: Apple Mail (2.3696.80.82.1.1) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4KlZDJ6H6tz3sw9 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=softfail (mx1.freebsd.org: 2001:638:a02:a001:20e:cff:fe4a:feaa is neither permitted nor denied by domain of tuexen@freebsd.org) smtp.mailfrom=tuexen@freebsd.org X-Spamd-Result: default: False [-1.99 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[tuexen]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-0.59)[-0.588]; R_SPF_SOFTFAIL(0.00)[~all]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FROM_NO_DN(0.00)[]; NEURAL_HAM_MEDIUM(-0.81)[-0.806]; MLMMJ_DEST(0.00)[freebsd-current]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:680, ipnet:2001:638::/32, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N > On 23. Apr 2022, at 02:24, Gleb Smirnoff wrote: >=20 > Michael, >=20 > On Sat, Apr 23, 2022 at 01:54:25AM +0200, Michael Tuexen wrote: > M> > here is a patch that should help with the IPv6 problem. I'm not > M> > yet committing it, it might be not final. > M>=20 > M> when I was looking at the code, I was also wondering if it would = make > M> more sense to check for M_LOOP. > M>=20 > M> However, isn't the rcvif wrong for the first two received packets? = I > M> would expect it always to be the loopback interface. Is that = expectation > M> wrong? >=20 > The IPv6 has a special feature of calling (ifp->if_output)(origifp, = ... >=20 > I don't fully understand it, but Alexander does. >=20 > What I can observe is that it works differently for the original = packet, > its first retransmit and second retransmit. Still unclear to me why. I consider this also strange. The three packets are identical. So I would expect, that all of these are handled the same way. >=20 > Here is how to observe it: >=20 > dtrace > -n 'fbt::ip6_output:entry > { printf("ro %p ifp %p\n", args[2], args[2]->ro_nh ? = args[2]->ro_nh->nh_ifp : 0); }' > -n 'fbt::ip6_output_send:entry { printf("ifp %p origifp %p\n", = args[1], args[2]); }' >=20 > And you will see this: >=20 > 1 45625 ip6_output:entry ro fffff800122c19a0 ifp 0 > 1 22539 ip6_output_send:entry ifp fffff800027cb800 = origifp fffff800020db000 >=20 > 0 45625 ip6_output:entry ro fffff800122c19a0 ifp = fffff800027cb800 > 0 22539 ip6_output_send:entry ifp fffff800027cb800 = origifp fffff800020db000 >=20 > 0 45625 ip6_output:entry ro fffff800122c19a0 ifp = fffff800027cb800 > 0 22539 ip6_output_send:entry ifp fffff800027cb800 = origifp fffff800027cb800 >=20 > So, on packet three (second retransmit) the origifp is equal to ifp = (is lo0) and now > packet passes validation. However, the more I read it, the more it = seems to me that > actually packet three is incorrect and first two are correct :) >=20 > To cope with this self inflicted damage of (ifp->if_output)(origifp, = IPV6 introduced > M_LOOP and uses it internally. Looks like a quick solution for IPv6 is = to use it. > However, I will commit it only once we got understanding why the hell = a second retransmit > is different. >=20 > M> I also have an additional question: > M> Why is this check protected by an (ia !=3D NULL) condition? It does = not make > M> any use of ia? >=20 > It is a host protection feature, so checks only packets that are = destined to us. > This allows to do basic antispoof checks for a host not equipped with = any firewall. Understood. I was confused, since all other code protected by (ia !=3D = NULL) actually depends on ia not being the NULL pointer. Best regards Michael >=20 > For a machine acting as a router better behavior is not to drop = anything routed > through unless explicitly told so by a filtering policy. >=20 > --=20 > Gleb Smirnoff