Date: Sat, 23 Apr 2022 03:57:42 +0200 From: tuexen@freebsd.org To: Gleb Smirnoff <glebius@FreeBSD.org> 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: <43CF838A-0C48-4ABC-8A5F-FBC0C39B21AA@freebsd.org> In-Reply-To: <YmNHJIR3%2B207YHMq@FreeBSD.org> 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> <YmNHJIR3%2B207YHMq@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
> On 23. Apr 2022, at 02:24, Gleb Smirnoff <glebius@FreeBSD.org> wrote:
>
> 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.
I consider this also strange. The three packets are identical.
So I would expect, that all of these are handled the same way.
>
> 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.
Understood. I was confused, since all other code protected by (ia != NULL) actually
depends on ia not being the NULL pointer.
Best regards
Michael
>
> 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
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?43CF838A-0C48-4ABC-8A5F-FBC0C39B21AA>