[atlas] All-Probe Traceroute + detect RFC1918 addresses

Jeroen Massar <jeroen at massar.ch> writes:

> If you can't verify the source, which with LL you cannot as they are
> on every interface around the world, it is spoofable.

Yes.

> Do you really want to receive a fe80::/10 at your recursive DNS
> service as a request (which could be valid, locally).

If you allow fe80::/10 at your recursive DNS service then you will make
sure this prefix cannot be spoofed.  This is a policy for the next-hop
router seen from the DNS server (if there is any - I'm not sure why I'd
allow fe80::/10 on any link with a router).  But the point is that this
policy does not need to affect any other router on the Internet. And I
would most certainly not depend on the configuration of other routers
outside my control for anything security related.

Not that different from the RPF you will do in your own network to
protect agaist spoofing the other prefixes allowed at your recursive DNS
service.  It's nice if people do RPF elsewhere too, but not something
I'd depend on for my DNS service.

I still do not see any problems letting the DNS server receive "illegal"
ICMP errors though.

> fe80::/10 should never have a TTL other than 1... it is link-local.

Maybe so.  But that's not enforced anywhere.

Many common IP applications can use LL addresses with the appropriate
zone identifier, but will not change the header to adapt to any LL
restrictions.  And the same goes for applications implemented in the
kernel. if you ping ff02::1 on a link with some hosts, then you'll
probably see a number of replies from LL sources with ttl=64.

> The whole point of the thread is to find networks that allow
> non-routed addresses, the standard BCP38 trick. Detecting RFC1918 in
> traceroutes might just be a cheap-ish way to identify these kind of
> networks (especially when outbound NAT happens, thus spoofing gets
> killed).

Yes, I see the value in that test and it does sound like a reasonable
approach.

It was just the notion that there should be any problem forwarding ICMP
errors with "illegal" source addresses that caught my attention.  I
don't think there is, regardless of the reason the address is defined as
illegal.

As long as the Juniper bug is limited to ICMP errors, then I am willing
to accept it as a standard-stretching feature.  And if they document the
bug, then it is a feature by definition :-)


Bjørn