search

NICMx / Jool

SIIT and NAT64 for Linux
GNU General Public License v2.0
326 stars 66 forks source link

IPv4 multicast should probably be implicitly blacklisted #168

Closed toreanderson closed 9 years ago

toreanderson commented 9 years ago

I've noticed that Jool will happily by default translate traffic destined for multicast addresses. Here's an example showing a VRRP packet being translated:

09:01:38.217668 IP 87.238.62.197 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 254, authtype none, intvl 1s, length 24
09:01:38.217756 IP6 2a02:c0::46:42:57ee:3ec5 > 2a02:c0::46:42:e000:12: ip-proto-112 24

RFC 6052 is silent on the subject of multicast, while RFC 6145 says:

The IP/ICMP header translation specified in this document is consistent with requirements of multicast IP/ICMP headers. However, IPv4 multicast addresses [RFC5771] cannot be mapped to IPv6 multicast addresses [RFC3307] based on the unicast mapping rule [RFC6052].

The last sentence there makes me think that IPv4 multicast (224.0.0.0/4) should probably be implicitly blacklisted. At the very least, IPv4 multicast addresses which the local node has subscribed to should be - there's some application running on the Jool node that's interested in those packets; Jool shouldn't steal them.

ydahhrk commented 9 years ago

Yet another argument in favor of #140. Once traffic intended to be translated has to be manually routed towards Jool, it will naturally stop seeing link-local traffic.

As a workaround, 224.0.0.0/24 /4 can be manually blacklisted; correct?

toreanderson commented 9 years ago

As a workaround, 224.0.0.0/24 can be manually blacklisted; correct?

Correct. So this is just a suggestion, it doesn't cause me any operational problems in any way.

mcr commented 9 years ago

Tore Anderson notifications@github.com wrote:

The last sentence there makes me think that IPv4 multicast (224.0.0.0/4) should probably be implicitly blacklisted. At the very least, IPv4 multicast addresses which the local node has subscribed to should be - there's some application running on the Jool node that's interested in those packets; Jool shouldn't steal them.

I can't see a good reason to translate class D addresses (multicast). Probably should blacklist 127/8, 0/8 and some other invalid things. I don't know what to do with 240/16 (class E).

ydahhrk commented 9 years ago

Probably should blacklist 127/8, 0/8 and some other invalid things.

Don't worry; those are already blacklisted. This is the relevant code.

I don't know what to do with 240/16 (class E).

Well, since they are experimental, I don't think we should completely ban the user from doing whatever with them.

They can always be manually blacklisted if use cases or security implications arise.

jm493 commented 9 years ago

The code blacklists 224.0.0.0/4 https://github.com/NICMx/NAT64/blob/master/mod/common/blacklist.c

But this documentation doesn't mention that range can't be used: https://www.jool.mx/usr-flags-blacklist.html

ydahhrk commented 9 years ago

Fixed; thank you!