Bug 278088 - ipfw missing options for some useful IPv6 features for RFC 4890
Summary: ipfw missing options for some useful IPv6 features for RFC 4890
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 15.0-CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ipfw (Nobody)
URL: https://datatracker.ietf.org/doc/html...
Keywords:
Depends on:
Blocks:
 
Reported: 2024-04-01 06:29 UTC by Joshua Kinard
Modified: 2024-04-02 03:07 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joshua Kinard 2024-04-01 06:29:02 UTC
I was reading through RFC 4890 "Recommendations for Filtering ICMPv6 Messages in Firewalls", and it looks like some of the recommendations cannot be implemented using FreeBSD's ipfw(8).  Specifically, there isn't an option for IPv6's "hop limit".  I at first thought "ipttl" was a synonym for it, and the rule parser doesn't error out if using it with an IPv6-only rule (e.g., 'ip6' 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 = 1 to avoid
>   ICMPv6 Time Exceeded messages being generated for these packets.
>
>   Address Configuration and Router Selection messages (must be received
>   with hop limit = 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 certain ICMPv6 Type 3 codes, as referenced down in Appendix B using Linux's ip6tables 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.