Jeroen Massar <jeroen@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