Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 01 Apr 2024 06:29:02 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 278088] ipfw missing options for some useful IPv6 features for RFC 4890
Message-ID:  <bug-278088-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D278088

            Bug ID: 278088
           Summary: ipfw missing options for some useful IPv6 features for
                    RFC 4890
           Product: Base System
           Version: 15.0-CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: freebsd@kumba.dev

I was reading through RFC 4890 "Recommendations for Filtering ICMPv6 Messag=
es
in Firewalls", and it looks like some of the recommendations cannot be
implemented using FreeBSD's ipfw(8).  Specifically, there isn't an option f=
or
IPv6's "hop limit".  I at first thought "ipttl" was a synonym for it, and t=
he
rule parser doesn't error out if using it with an IPv6-only rule (e.g., 'ip=
6'
or 'ipv6-icmp').  But further digging reveals that it is only applicable for
IPv4 (sys/netpfil/ipfw/ip_fw2.c in function ipfw_chk()):
>                        case O_IPID:
>                        case O_IPTTL:
>                                if (!is_ipv4)
>                                        break;

Support for this option would be necessary for things like this, from Pg 15:
>   Administrators may also wish to consider providing rules in firewall/
>   routers to catch illegal packets sent with hop limit =3D 1 to avoid
>   ICMPv6 Time Exceeded messages being generated for these packets.
>
>   Address Configuration and Router Selection messages (must be received
>   with hop limit =3D 255):
>
>   o  Router Solicitation (Type 133)
>   o  Router Advertisement (Type 134)
>   o  Neighbor Solicitation (Type 135)
>   o  Neighbor Advertisement (Type 136)
>   o  Redirect (Type 137)
>   o  Inverse Neighbor Discovery Solicitation (Type 141)
>   o  Inverse Neighbor Discovery Advertisement (Type 142)
If implemented, I proposed that the option be called one of "hoplimit" or
"ip6hoplimit"

In another case, there is no support for specifying ICMPv6 Codes (similar to
Bug #153161, which is for IPv4 ICMP).  This would be relevant to limit cert=
ain
ICMPv6 Type 3 codes, as referenced down in Appendix B using Linux's ip6tabl=
es
format (Pg 34):
>   # Allow outgoing time exceeded code 0 messages
>   for inner_prefix in $INNER_PREFIXES
>   do
>   ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
>            --icmpv6-type ttl-zero-during-transit -j ACCEPT
>   done
>
>   #@POLICY@
>   # Allow outgoing time exceeded code 1 messages
>   for inner_prefix in $INNER_PREFIXES
>   do
>   ip6tables -A icmpv6-filter -p icmpv6 -s $inner_prefix \
>            --icmpv6-type ttl-zero-during-reassembly -j ACCEPT
>   done
If implemented, the best name for the option should be "icmp6code" and/or
"icmp6codes", to align with icmp6type/icmp6types.

I also noticed that there isn't support in "tcpflags" for the CWR and ECE
flags, which are used for congestion control.

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-278088-227>