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:
Code: Select all
# 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:
- Unspecified address (RFC6092 REC-3; RFC5156 sec 2.1)
- Loopback address (RFC6092 REC-3; RFC5156 sec 2.1)
- Deprecated site-local address (RFC6092 REC-3; RFC3879)
- IPv4-Mapped address (RFC6092 REC-3; RFC5156 sec 2.2)
- IPv4-compatibile address (RFC6092 REC-3; RFC5156 sec 2.3)
- Blackhole (RFC6666 sec 4)
- Documentation-only range (see below, probably shouldn't be separately listed)
- ORCHID (see below, probably shouldn't be separately listed)
- 6bone v2 (RFC6092 REC-3; RFC5156 sec 2.9)
- Dropping all listed above when src matches
- Dropping all listed above when dst matches
- 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:
Code: Select all
/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.
Code: Select all
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:
Code: Select all
/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
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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.