Date: Fri, 22 Apr 2022 17:24:04 -0700 From: Gleb Smirnoff <glebius@freebsd.org> To: Michael Tuexen <michael.tuexen@macmic.franken.de> Cc: Florian Smeets <flo@smeets.xyz>, Michael Butler <imb@protected-networks.net>, freebsd-current@freebsd.org, melifaro@freebsd.org Subject: Re: IPv6 TCP: first two SYN packets to local v6 unicast addresses ignored Message-ID: <YmNHJIR3%2B207YHMq@FreeBSD.org> In-Reply-To: <B9EFD82D-9050-4271-873B-3A02B8C14C37@macmic.franken.de> References: <131c363a-7b7d-a106-5b8a-6838e7a66567@smeets.xyz> <E0584477-0F2E-454D-871C-368F14A9AF1D@freebsd.org> <9679642b-5de6-28be-a64b-07375c3efeba@smeets.xyz> <b12a74b2-cd7d-2066-ff60-b14c08d70d6f@protected-networks.net> <YlpSs8p/3Gh1JDI5@FreeBSD.org> <7cd2e76a-c6d1-e8d7-b9fb-b8797f1ca731@smeets.xyz> <YmM8fknVX/wmUDiD@FreeBSD.org> <B9EFD82D-9050-4271-873B-3A02B8C14C37@macmic.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Michael,
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>
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>
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?
The IPv6 has a special feature of calling (ifp->if_output)(origifp, ...
I don't fully understand it, but Alexander does.
What I can observe is that it works differently for the original packet,
its first retransmit and second retransmit. Still unclear to me why.
Here is how to observe it:
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]); }'
And you will see this:
1 45625 ip6_output:entry ro fffff800122c19a0 ifp 0
1 22539 ip6_output_send:entry ifp fffff800027cb800 origifp fffff800020db000
0 45625 ip6_output:entry ro fffff800122c19a0 ifp fffff800027cb800
0 22539 ip6_output_send:entry ifp fffff800027cb800 origifp fffff800020db000
0 45625 ip6_output:entry ro fffff800122c19a0 ifp fffff800027cb800
0 22539 ip6_output_send:entry ifp fffff800027cb800 origifp fffff800027cb800
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 :)
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.
M> I also have an additional question:
M> Why is this check protected by an (ia != NULL) condition? It does not make
M> any use of ia?
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.
For a machine acting as a router better behavior is not to drop anything routed
through unless explicitly told so by a filtering policy.
--
Gleb Smirnoff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YmNHJIR3%2B207YHMq>