Community discussions

MikroTik App
 
User avatar
kiler129
Member
Member
Topic Author
Posts: 352
Joined: Tue Mar 31, 2015 4:32 pm
Location: IL, USA
Contact:

Improving default IPv6 firewall to follow RFCs

Sun Jan 16, 2022 7:06 am

Hello!

Recently I had a bit of time for a larger maintenance windows and some spare time with a cup of strong coffee. I decided to attack IPv6. During my endeavor I carefully examined the IPv6 firewall in ROS in attempt to really understand where particular things are coming from. I was able to trace most of them while also discovering possible shortcomings.

ROS default IPv6 firewall and where it came from
Ignoring all the usual stuff which are described pretty well (like accepting DHCPv6 or IKE) the IPv6 filter in ROS 7.2rc1 can be summarized as:
# added rule numbers for reference
/ipv6 firewall 
  [1]  address-list add list=bad_ipv6 address=::/128 comment="defconf: unspecified address"
  [2]  address-list add list=bad_ipv6 address=::1 comment="defconf: lo"
  [3]  address-list add list=bad_ipv6 address=fec0::/10 comment="defconf: site-local"
  [4]  address-list add list=bad_ipv6 address=::ffff:0:0/96 comment="defconf: ipv4-mapped"
  [5]  address-list add list=bad_ipv6 address=::/96 comment="defconf: ipv4 compat"
  [6]  address-list add list=bad_ipv6 address=100::/64 comment="defconf: discard only "
  [7]  address-list add list=bad_ipv6 address=2001:db8::/32 comment="defconf: documentation"
  [8]  address-list add list=bad_ipv6 address=2001:10::/28 comment="defconf: ORCHID"
  [9]  address-list add list=bad_ipv6 address=3ffe::/16 comment="defconf: 6bone"

  [10] filter add chain=forward action=drop src-address-list=bad_ipv6 comment="defconf: drop packets with bad src ipv6"
  [11] filter add chain=forward action=drop dst-address-list=bad_ipv6 comment="defconf: drop packets with bad dst ipv6"
  [12] filter add chain=forward action=drop protocol=icmpv6 hop-limit=equal:1 comment="defconf: rfc4890 drop hop-limit=1"

I went ahead and traced RFCs which lead to MT including of these rules:
  1. Unspecified address (RFC6092 REC-3; RFC5156 sec 2.1)
  2. Loopback address (RFC6092 REC-3; RFC5156 sec 2.1)
  3. Deprecated site-local address (RFC6092 REC-3; RFC3879)
  4. IPv4-Mapped address (RFC6092 REC-3; RFC5156 sec 2.2)
  5. IPv4-compatibile address (RFC6092 REC-3; RFC5156 sec 2.3)
  6. Blackhole (RFC6666 sec 4)
  7. Documentation-only range (see below, probably shouldn't be separately listed)
  8. ORCHID (see below, probably shouldn't be separately listed)
  9. 6bone v2 (RFC6092 REC-3; RFC5156 sec 2.9)
  10. Dropping all listed above when src matches
  11. Dropping all listed above when dst matches
  12. Drop invalid ICMP
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Issues with the default IPv6 firewall
Let me preface my questions/concerns with the fact that I'm by no means IPv6 expert and I gather the info by digging through RFCs - I will be more than happy for someone to correct me ;)

#1: 6bone v2 is blocked while v1 is not
One of the entries in MTs firewall ([9]) claims to block deprecated 6bone range - 3ffe::/16. However, according to RFC5156 sec 2.9 both v1 and v2 are deprecated, while 3ffe::/16 only covers the newer v2. The firewall probably should also block 5f00::/8.

#2: 2001::/23 range should use whitelist instead of a blacklist
According to IANA that range is special in a sense that everything in it is not routable unless defined. MT took a different approach and routes everything in that range while blocking documentation-only range (2001:db8::/32) and ORCHIDv1 (2001::10::/28). IANA includes a handy table for all ranges which should be routable within that range: https://www.iana.org/assignments/iana-i ... stry.xhtml
Seeing this I believe that the original ROS list (bad_ipv6) should not contain entries [7] and [8] and the firewall for this range should look look more like below:
/ipv6/firewall/address-list
    add list=rfc2928-exception address=2001::/32       comment="TEREDO (RFC4380; RFC8190)"
    add list=rfc2928-exception address=2001:1::1/128   comment="Port Control Protocol Anycast (RFC7723)"
    add list=rfc2928-exception address=2001:1::2/128   comment="Traversal Using Relays around NAT Anycast (RFC8155)"
    add list=rfc2928-exception address=2001:2::/48     comment="Benchmarking (RFC5180)"
    add list=rfc2928-exception address=2001:3::/32     comment="AMT (RFC7450)"
    add list=rfc2928-exception address=2001:4:112::/48 comment="AS112-v6 (RFC7535)"
    add list=rfc2928-exception address=2001:20::/28    comment="ORCHIDv2 (RFC7343)"

/ipv6/firewall/filter
    add chain=forward  src-address=2001::/23 src-address-list=!rfc2928-exception action=drop comment="RFC2928 src non-routable drop"
    add chain=forward  dst-address=2001::/23 dst-address-list=!rfc2928-exception action=drop comment="RFC2928 dst non-routable drop"

#3: IPv6-encapsulated IPv4 loopback address shouldn't be routable
In short the bad_ipv6 should contain an an entry for ::127.0.0.0/104 to comply with RFC6092 REC-3.

#4: Disable IPv6 multicast
This may not be fully appropriate for enterprise networks, but for a default (i.e. probably more home-y use) the bad_ipv6 list should contain two additional entires, as suggested by RFC6092 REC-1. Additionally, I think not at least limiting these can lead to amplification attacks.
    add list=bad_ipv6 address=ff00::/8        comment="Disable IPv6 multicast source (RFC6092 REC-1)"
    add list=bad_ipv6 address=::224.0.0.0/100 comment="Disable IPv6-encapsulated IPv4 multicast source (RFC6092 REC-1)"

#5: UDP traceroute and amplification attacks
As with every UDP protocol spoofing in IPv6 traceroute is a problem. MTs simply allows UDP traceroute to happen on input. I believe a better approach will be to at least limit the scope to realistic values:
/ipv6/firewall/filter
    add chain=input protocol=udp port=33434-33534 dst-limit=5,10,src-address/30s

#6: Entries I found in v6?
ROS v6 used to contain two additional addresses on the bad_ipv6 list:
  • ::/104
  • ::255.0.0.0/104
I wasn't able to find these ranges in any RFCs and I'm not sure why they were included in v6 but they're removed in v7. Maybe someone has any idea here?

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Running IPv6 in production
In my test bed I see ~40% of the traffic from regular home users going over IPv6. This isn't insignificant amount and I will like to roll-out IPv6 throughout all the networks. Can anyone here running IPv6 in the real world chime in here about the firewall configuration? I think after the improvements it should be sufficient.
 
User avatar
kiler129
Member
Member
Topic Author
Posts: 352
Joined: Tue Mar 31, 2015 4:32 pm
Location: IL, USA
Contact:

Re: Improving default IPv6 firewall to follow RFCs

Mon Jan 24, 2022 8:23 pm

<Hopeful bump> :)
 
pe1chl
Forum Guru
Forum Guru
Posts: 10195
Joined: Mon Jun 08, 2015 12:09 pm

Re: Improving default IPv6 firewall to follow RFCs

Mon Jan 24, 2022 9:17 pm

You can disable that entire section of the firewall without any adverse effects.
You will normally find the hit count of that rule frozen at zero.

Interesting that they added this to the IPv6 default firewall, while there is no comparable address list and rule for IPv4 (where it can be written as well).
 
User avatar
kiler129
Member
Member
Topic Author
Posts: 352
Joined: Tue Mar 31, 2015 4:32 pm
Location: IL, USA
Contact:

Re: Improving default IPv6 firewall to follow RFCs

Wed Jan 26, 2022 1:39 am

True, it can be removed without much of the adverse effect (probably? ;)) but being complain with the current RFCs is IMHO good. Because of how broken IPv6 is in the IoT world I had to disable it for my personal networks on the IoT VLAN. After like ~2 weeks I've got 0.05% of the traffic matching bogon & multicast rules - it's truly a minuscule amount but it's there so we get some stray packets still which in the future may end up being used as an attack vector.

As for IPv4 I think situation here is more complex due to attempts to squeeze out as many public v4s as possible. They even want to route 0. prefix now ;)
 
pe1chl
Forum Guru
Forum Guru
Posts: 10195
Joined: Mon Jun 08, 2015 12:09 pm

Re: Improving default IPv6 firewall to follow RFCs

Wed Jan 26, 2022 11:14 am

This thing has nothing to do with RFCs except that the ranges they block are defined in some RFC.
The idea of this filter is to block addresses that are not supposed to be sending traffic to you. It is like blocking 192.168.0.0/16 from internet, which would
also be "a good idea" but usually the ISP already does that. Similar for these ranges.
 
User avatar
Kentzo
Long time Member
Long time Member
Posts: 516
Joined: Mon Jan 27, 2014 3:35 pm
Location: California

Re: Improving default IPv6 firewall to follow RFCs

Wed Jan 26, 2022 5:53 pm

I have recently reached to mikrotik regarding incorrectly blocking ::/128 source in one special ICMPv6 case and they addressed the error within two days.

Try https://help.mikrotik.com/servicedesk/servicedesk
 
User avatar
Kentzo
Long time Member
Long time Member
Posts: 516
Joined: Mon Jan 27, 2014 3:35 pm
Location: California

Re: Improving default IPv6 firewall to follow RFCs

Wed Jan 26, 2022 7:55 pm

#3: IPv6-encapsulated IPv4 loopback address shouldn't be routable
In short the bad_ipv6 should contain an an entry for ::127.0.0.0/104 to comply with RFC6092 REC-3.

...

#6: Entries I found in v6?
ROS v6 used to contain two additional addresses on the bad_ipv6 list:
::/104
::255.0.0.0/104
I wasn't able to find these ranges in any RFCs and I'm not sure why they were included in v6 but they're removed in v7. Maybe someone has any idea here?

...

add list=bad_ipv6 address=::224.0.0.0/100 comment="Disable IPv6-encapsulated IPv4 multicast source (RFC6092 REC-1)"

These are handled by the following rules:
[4] address-list add list=bad_ipv6 address=::ffff:0:0/96 comment="defconf: ipv4-mapped"
[5] address-list add list=bad_ipv6 address=::/96 comment="defconf: ipv4 compat"

Who is online

Users browsing this forum: FurfangosFrigyes, Renfrew and 85 guests