The implicit blacklist is insufficient. #223

Closed
ydahhrk opened this Issue Sep 6, 2016 · 5 comments

Projects

None yet

3 participants

@ydahhrk
Member
ydahhrk commented Sep 6, 2016

This applies to both Jool 3.4 and the upcoming 3.5, though the code was already fixed in 3.5's test branch.

As stated in --blacklist, SIIT Jool has an additional implicit blacklist that prevents translation of certain IPv4 addresses regardless of the EAMT and pool6.

Rather bafflingly, that list does not currently include recognizable directed broadcast. If pool6 has 64:ff9b::/96 and Jool is connected to 192.0.2.0/24, 192.0.2.255 is happily translated into 64:ff9b::192.0.2.255 and vice versa.

Also, much like the explicit blacklist, the implicit blacklist does not currently apply to the EAMT. Among other (predictable) consequences of this, it's causing the translator itself to lose contact with IPv4 if its IPv4 address is included in the EAMT. For example, if the EAMT contains EAM [0.0.0.0/0, 2001:db8::/96] and the SIIT machine has address 192.0.2.24, then an incoming packet towards 192.0.2.24 will be translated into 2001:db8::192.0.2.24 and likely end up dropped.

Thanks to Eduardo Montoya for reporting this.

@ydahhrk ydahhrk added a commit that referenced this issue Sep 6, 2016
@ydahhrk ydahhrk Improve the implicit blacklist
- Stop translating broacast.
- Apply implicit blacklist to both the EAMT and pool6.

Fixes issue #223.

Also includes a cgcc review.
80e531a
@toreanderson
Contributor

Just an observation here: I've seen folks that are working with IPTables and DNAT add secondary IP addresses to local interfaces on the DNAT boxes in order to attract traffic to those addreses without requiring routes to be added on the upstream router, i.e., something like:

ip address add 192.0.2.2/24 dev eth0 # primary
ip address add 192.0.2.3/32 dev eth0 label eth0:1 # for DNAT44 purposes
iptables -t nat -I PREROUTING -d 192.0.2.3 -j DNAT --to 10.1.2.3

This would be roughly equivalent to:

ip address add 192.0.2.2/24 dev eth0 # primary
ip address add 192.0.2.3/32 dev eth0 label eth0:1 # for SIIT-DC purposes
jool_siit --eamt --add 192.0.2.3 fd01:2345::6789

If you implicitly blacklist all local IPv4 addresses, then it might be that this use case no longer works. To be perfectly honest, though, I don't know if it works right now either, since I'm not using such a config myself.

That said, it might be possible to accomplish the same thing without assigning 192.0.2.3/32 to a local interface, e.g., using ip neigh add proxy functionality. If so I guess it's fine to blacklist local IPv4 addresses and instead document how it could be done instead.

@edmont
edmont commented Sep 7, 2016

Just tested both the broadcast issue and the EAMT blacklist and everything works well now. Great job!

@ydahhrk
Member
ydahhrk commented Sep 7, 2016

I've seen folks that are working with IPTables and DNAT add secondary IP addresses to local interfaces on the DNAT boxes in order to attract traffic to those addreses without requiring routes to be added on the upstream router

Good catch!

It's interesting to note that you used the word "secondary". It also seems reasonable to expect all such addresses to be /32. Perhaps it would be cleaner if only primary addresses were blacklisted. Or we could make exceptions out of /32s.

I'm interested to see if NAT44 also handles these addresses differently; I'll take a look at the iptables code.

(Also reminder to myself: If /32s end up being supposed to be translated anyway, be careful not to blacklist the "broadcast".)

@ydahhrk
Member
ydahhrk commented Sep 7, 2016

Just tested both the broadcast issue and the EAMT blacklist and everything works well now.

Thanks!

@ydahhrk
Member
ydahhrk commented Sep 7, 2016 edited

Never mind. Your own example clearly shows that DNAT couldn't care less whether the --to address belongs to itself or not. I suppose it can afford that because it lets the user specify --dport, which makes it less intrusive. But we can't do that, because having to look at ports (in layer 4 headers) would force SIIT Jool to defragment.

So the solution of iptables is unsuitable here.

By the way:

Creating an iproute2 NAT mapping has the side effect of causing the kernel to answer ARP requests for the NAT IP.

(http://linux-ip.net/html/nat-stateless.html. I guess they got tired of adding /32 addresses?)

My current tendency is to let the SIIT translate host addresses that belong to /32s. These are (AFAIK) generally more specific and useless than secondary address and so they would more likely be intended for translation.

Though it still feels like an ugly hack. I suppose enclosing Jool is a namespace (or the device driver model) would be cleaner; the node would consume its own packets first, Jool would translate second. But that's also a lot of documentation excess.

I'll roll the code tomorrow.

@ydahhrk ydahhrk added a commit that referenced this issue Sep 9, 2016
@ydahhrk ydahhrk Apply the latest #223 development to the 3.5 code.
The implicit blacklist prevents SIIT Jool from translating its own
node's addresses. This commits makes addresses that belong to /32
"networks" an exception.

This is because some people prefer to add these addresses to
attract to-be-translated traffic, as opposed to add explicit routes
in all neighbors.
5885c40
@ydahhrk ydahhrk added this to the 3.4.5 milestone Sep 14, 2016
@ydahhrk ydahhrk added a commit that closed this issue Sep 19, 2016
@ydahhrk ydahhrk Allow translation of the node's /32 addresses.
The implicit blacklist prevents SIIT Jool from translating its own
node's addresses. This commits makes addresses that belong to /32
"networks" an exception.

This is because some people prefer to add these addresses to
attract to-be-translated traffic, as opposed to add explicit routes
in all neighbors.

Fixes #223 further.
b81dee0
@ydahhrk ydahhrk closed this in b81dee0 Sep 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment