netfilter buglog - Jan 2024 - [Bug 1730] New: nft does not handle IPv6 addresses with embedded IPv4 addresses

https://bugzilla.netfilter.org/show_bug.cgi?id=1730

            Bug ID: 1730
           Summary: nft does not handle IPv6 addresses with embedded IPv4
                    addresses
           Product: nftables
           Version: 1.0.x
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: antonio.ojea.garcia at gmail.com

Originally reported by Lars Ekman in Kubernetes
https://github.com/kubernetes/kubernetes/issues/122611 , all credit to him

The rfc5952 seems to accept "embedded ipv4" addresses, and iptables
accept
them, however, nft does not

This works

ip6tables -A INPUT -s fd00::10.0.0.1/128 -j DROP

This does not

nft -v
nftables v1.0.9 (Old Doc Yak #3)
nft add table ip6 test6
nft 'add chain ip6 test6 test6 { type filter hook prerouting priority 0;
}'
nft insert rule ip6 test6 test6 ip6 saddr fd00::10.0.0.1 log
Error: syntax error, unexpected log
insert rule ip6 test6 test6 ip6 saddr fd00::10.0.0.1 log

Comment in
https://github.com/kubernetes/kubernetes/issues/122611#issuecomment-1879569171
seems to indicate the problem is in the flex/bison parsers

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240106/26a03710/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1730

Antonio Ojea <antonio.ojea.garcia at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P5                          |P1
           Severity|enhancement                 |major

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240106/ea02fde0/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1730

Eric Fahlgren <evil.function at proton.me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |evil.function at proton.me

--- Comment #1 from Eric Fahlgren <evil.function at proton.me> ---
Playing with this, I found that IPv4-mapped unicast addresses work as expected.
 This particular address format is somehow getting past the parser, so it must
be seeing some special casing somewhere.

(I'm also running v1.0.9.)

$ nft insert rule ip6 test6 test6 ip6 saddr ::ffff:10.0.0.1 log

$ nft list table ip6 test6
table ip6 test6 {
        chain test6 {
                type filter hook prerouting priority filter; policy accept;
                ip6 saddr ::ffff:10.0.0.1 log
        }
}

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240106/7cb1f675/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1730

--- Comment #2 from Antonio Ojea <antonio.ojea.garcia at gmail.com> ---
::ffff:10.0.0.1 is a IPv4-Mapped IPv6 Address
https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.5.2

That is well defined, try with fd00::10.0.0.1/128 

It seems that Section 5 in rfc5952 leaves the representation using mixed
notation open so theoretically it should be possible
https://datatracker.ietf.org/doc/html/rfc5952#section-5

This is an edge case, but for compatibility reasons, I think that all the
representations that work with iptables user space tools should be allowed to
work with the nftables one, so migration and portability is simpler for end
users and consumers

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240106/b9eecf32/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1730

--- Comment #3 from Eric Fahlgren <evil.function at proton.me> ---
Yes, I duplicated your results, but was puzzled that the IPv4-mapped address
was able to pass through the parser, which I would not expect if the same flex
rule is used for all address tokens.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240107/e7abbf73/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1730

--- Comment #4 from Pablo Neira Ayuso <pablo at netfilter.org> ---
Cursory look at inet_pton()

static const char *                                                             
inet_ntop6 (const u_char *src, char *dst, socklen_t size)                       
{                                                                               
        /*                                                                      
         * Note that int32_t and int16_t need only be "at least" large
enough
         * to contain a value of the specified size.  On some systems, like     
         * Crays, there is no such thing as an integer variable with 16 bits.   
         * Keep this in mind if you think this function should have been coded  
         * to use pointer overlays.  All the world's not a VAX.
         */                                                                     
        char tmp[sizeof
"ffff:ffff:ffff:ffff:ffff:ffff:255.255.255.255"], *tp;

shows that the intention is to support for embedded IPv4 notation as an IPv6
suffix.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240108/94b60e78/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1730

--- Comment #5 from Pablo Neira Ayuso <pablo at netfilter.org> ---
(In reply to Eric Fahlgren from comment #3)
> Yes, I duplicated your results, but was puzzled that the IPv4-mapped
address
> was able to pass through the parser, which I would not expect if the same
> flex rule is used for all address tokens.
Because it only supports for RFC-compliant IPv4-Mapped IPv6 addresses.

See:

commit fd513de78bc0133f6ba61087be168e2a8d067107
Author: Pablo Neira Ayuso <pablo at netfilter.org>
Date:   Mon Oct 9 01:40:36 2017 +0200

    scanner: IPv4-Mapped IPv6 addresses support

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240108/b835d0c7/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1730

--- Comment #6 from Antonio Ojea <antonio.ojea.garcia at gmail.com> ---
Then, should we close as Worked as Intended Pablo?

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240407/fe5d1dc1/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1730

--- Comment #7 from Pablo Neira Ayuso <pablo at netfilter.org> ---
(In reply to Antonio Ojea from comment #6)
> Then, should we close as Worked as Intended Pablo?
I can take a look and extend it to support this, it is a userspace patch.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20240407/1b7391a5/attachment.html>