Re: [atlas] All-Probe Traceroute + detect RFC1918 addresses
Philip Homburg writes: > As far as I know, this a well known Juniper bug where their routers > forward errors ICMPs without checking whether the source address is > link local. Thinking about this... Is there any reason except formalities why you shouldn't forward those packets? The won't generate a reply and can't generate an ICMP error, so their source address will never be used as a destination. Agreed, it would be better if they had a global source. But they don't. Maybe because there was none configured on the router/host the error message originates from? In any case, the source address is what it is and you can either forward the packet or drop it. Dropping it means the information is lost. Maybe breaking PMTU or whatever. I believe it's better to ignore the formalities here and forward those packets. It's certainly harmless. At least as harmless as forwarding any other ICMP error messages. Bjørn
Re: [atlas] All-Probe Traceroute + detect RFC1918 addresses
On 2021/09/15 19:06 , Gert Doering wrote: On Wed, Sep 15, 2021 at 06:58:50PM +0200, Philip Homburg wrote: My router at home gets a lot of error icmps with link local source, from quite a few hops away... *wake up* IPv4 "link local" (169.254.*) or IPv6 LLA (fe80::)? IPv6 link local The latter would make me very curious what sort of intermediate devices are forwarding these (which is strictly forbidden). As far as I know, this a well known Juniper bug where their routers forward errors ICMPs without checking whether the source address is link local. I don't know what happens to other packets with link local source. Philip
Re: [atlas] All-Probe Traceroute + detect RFC1918 addresses
On 9/15/21 11:32 AM, Jeroen Massar via ripe-atlas wrote: Hi Folks, Has anybody ever run a all-probe traceroute and then to detect any RFC1918 addresses in there? (though many probes will have locally some RFC1918) Since probes are running measurements to many targets already, the full dataset will uncover a lot without having to run more measurements. A quick query: https://gist.github.com/sdstrowes/e9d4a3c7c03dd1aafa3198333cc39ffa Out of ~106M IPv4 traceroutes, this finds ~6M that contain 10.0.0.0/8 in an ICMP response more than 4 hops from the origin. That's not the smartest approach, but it's a good ballpark of what's in the data. It'd be reasonably easy to take that and whittle it down to a set of probes and/or probe ASNs that see this. With more work it'd be possible to identify ASNs on the forward path as a strong hint (asymmetric routing to one side) of where these pass through. S. We got CAIDAs spoofer project, but that primarily afaik checks that by doing connections, not by checking ICMP returns. I just saw towards 213.244.71.2 : 11 Bundle-Ether42.br03.mrs01.pccwbtn.net (63.223.38.78) 29.068 ms 29.301 ms 29.129 ms 12 Bundle-Ether41.br03.mrs01.pccwbtn.net (63.223.38.74) 31.462 ms 31.410 ms 31.459 ms 13 10.74.42.10 (10.74.42.10) 77.574 ms 63.222.97.82 (63.222.97.82) 73.651 ms 63.222.97.90 (63.222.97.90) 73.514 ms 14 10.74.42.129 (10.74.42.129) 82.789 ms * 10.74.19.29 (10.74.19.29) 78.695 ms 15 * * 10.74.25.22 (10.74.25.22) 78.914 ms 16 * * 10.74.25.22 (10.74.25.22) 78.875 ms 17 * * * Which means the whole path till that IP was not doing any kind of RPF thus spoofing anything else would be possible too. At least one could kick PCCW in this case... but likely there are others. And as we are in 2021... a hall of shame might be appropriate... Of course, one should also do that for IPv6; though I expect outside the stray ULA address (thank you apple; though they are fixing that ULA issue with homepods apparently) very little of it, though "meten is weten" (measuring is knowing). Greets, Jeroen
Re: [atlas] All-Probe Traceroute + detect RFC1918 addresses
Hi, On Wed, Sep 15, 2021 at 06:58:50PM +0200, Philip Homburg wrote: > My router at home gets a lot of error icmps with link local source, from > quite a few hops away... *wake up* IPv4 "link local" (169.254.*) or IPv6 LLA (fe80::)? The latter would make me very curious what sort of intermediate devices are forwarding these (which is strictly forbidden). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 signature.asc Description: PGP signature
Re: [atlas] All-Probe Traceroute + detect RFC1918 addresses
On 2021/09/15 17:32 , Jeroen Massar via ripe-atlas wrote: Has anybody ever run a all-probe traceroute and then to detect any RFC1918 addresses in there? (though many probes will have locally some RFC1918) Atlas performs quite a few traceroutes on all probes. For example, https://atlas.ripe.net/measurements/5017/ which is a unicast destination. So anything close to the probes should show up. Of course, one should also do that for IPv6; though I expect outside the stray ULA address (thank you apple; though they are fixing that ULA issue with homepods apparently) very little of it, though "meten is weten" (measuring is knowing). My router at home gets a lot of error icmps with link local source, from quite a few hops away...
[atlas] All-Probe Traceroute + detect RFC1918 addresses
Hi Folks, Has anybody ever run a all-probe traceroute and then to detect any RFC1918 addresses in there? (though many probes will have locally some RFC1918) We got CAIDAs spoofer project, but that primarily afaik checks that by doing connections, not by checking ICMP returns. I just saw towards 213.244.71.2 : 11 Bundle-Ether42.br03.mrs01.pccwbtn.net (63.223.38.78) 29.068 ms 29.301 ms 29.129 ms 12 Bundle-Ether41.br03.mrs01.pccwbtn.net (63.223.38.74) 31.462 ms 31.410 ms 31.459 ms 13 10.74.42.10 (10.74.42.10) 77.574 ms 63.222.97.82 (63.222.97.82) 73.651 ms 63.222.97.90 (63.222.97.90) 73.514 ms 14 10.74.42.129 (10.74.42.129) 82.789 ms * 10.74.19.29 (10.74.19.29) 78.695 ms 15 * * 10.74.25.22 (10.74.25.22) 78.914 ms 16 * * 10.74.25.22 (10.74.25.22) 78.875 ms 17 * * * Which means the whole path till that IP was not doing any kind of RPF thus spoofing anything else would be possible too. At least one could kick PCCW in this case... but likely there are others. And as we are in 2021... a hall of shame might be appropriate... Of course, one should also do that for IPv6; though I expect outside the stray ULA address (thank you apple; though they are fixing that ULA issue with homepods apparently) very little of it, though "meten is weten" (measuring is knowing). Greets, Jeroen
