8.8.8.8 hijack and ripe atlas
It appears there are some public measurements like #1002630, and i'm curious if someone is able to look at the latency and TTL numbers of the transport side and observe the localized hijacking of 8.8.8.8. The dataset is somewhat huge and i'm not a json master so trying to discern if there is evidence in there is something i'm looking at. - Jared
Gesendet: Mittwoch, 19. März 2014 um 14:14 Uhr Von: "Jared Mauch" <jared@puck.nether.net> An: "RIPE Atlas People" <ripe-atlas@ripe.net> Betreff: [atlas] 8.8.8.8 hijack and ripe atlas
It appears there are some public measurements like #1002630, and i'm curious if someone is able to look at the latency and TTL numbers of the transport side and observe the localized hijacking of 8.8.8.8.
The dataset is somewhat huge and i'm not a json master so trying to discern if there is evidence in there is something i'm looking at.
- Jared
Could you please elaborate on what you are trying to do? I did not fully understand you (and I'm only a layman). Is this related to http://www.itnews.com.au/News/375278,google-dns-servers-suffer-brief-traffic... Regards, Stephan
On Mar 19, 2014, at 1:14 PM, Stephan Müller <stephanr.mueller@gmx.de> wrote:
Gesendet: Mittwoch, 19. März 2014 um 14:14 Uhr Von: "Jared Mauch" <jared@puck.nether.net> An: "RIPE Atlas People" <ripe-atlas@ripe.net> Betreff: [atlas] 8.8.8.8 hijack and ripe atlas
It appears there are some public measurements like #1002630, and i'm curious if someone is able to look at the latency and TTL numbers of the transport side and observe the localized hijacking of 8.8.8.8.
The dataset is somewhat huge and i'm not a json master so trying to discern if there is evidence in there is something i'm looking at.
- Jared
Could you please elaborate on what you are trying to do? I did not fully understand you (and I'm only a layman). Is this related to http://www.itnews.com.au/News/375278,google-dns-servers-suffer-brief-traffic...
What i'm trying to determine is if there is an outlier of the mean RTT and/or TTL from probes within a region to 8.8.8.8 which would represent a localized hijacking could be detected. eg: If the RTT is typically 20ms and drops to 8ms, perhaps that is something worthy of investigating. Same for TTL, if the IP_TTL is typically 54 due to taking 10 hops to reach Google, and now becomes 58, that would be a localized "hijacking" or unauthorized use of the IP space. - Jared
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 19/03/14 14:14, Jared Mauch wrote:
It appears there are some public measurements like #1002630, and i'm curious if someone is able to look at the latency and TTL numbers of the transport side and observe the localized hijacking of 8.8.8.8.
The dataset is somewhat huge and i'm not a json master so trying to discern if there is evidence in there is something i'm looking at.
This may works to get the data into an easier to digest form (requires the perl JSON module installed): curl "https://atlas.ripe.net/api/v1/measurement/1002630/result/?start=1340323200&stop=1395273599&format=txt" | perl -MJSON -nle'$d=decode_json($_); print "$d->{timestamp} $d->{prb_id} $d->{min} $d->{ttl}"' | tee results.txt I looked into the results a little bit and didn't find clues for a localized hijacking of 8.8.8.8 for the probes I looked at (out of the 10 total in that measurement). The fact that 8.8.8.8 is anycast may make it hard to distinguish between changes due to anycast flapping or localized hijacks. hth, Emile -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMqo38ACgkQj05ACITZaqq8rgD6A50rqO5rTCzlTBPj+fNET7bR 7U2wO54lXbAFND+ciKsA/1dS+yKqysVa2j5I0WTLXAoiSWK3cBGDYB4nkeNKP0AZ =iDv1 -----END PGP SIGNATURE-----
On Mar 20, 2014, at 4:14 AM, Emile Aben <emile.aben@ripe.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 19/03/14 14:14, Jared Mauch wrote:
It appears there are some public measurements like #1002630, and i'm curious if someone is able to look at the latency and TTL numbers of the transport side and observe the localized hijacking of 8.8.8.8.
The dataset is somewhat huge and i'm not a json master so trying to discern if there is evidence in there is something i'm looking at.
This may works to get the data into an easier to digest form (requires the perl JSON module installed):
curl "https://atlas.ripe.net/api/v1/measurement/1002630/result/?start=1340323200&stop=1395273599&format=txt" | perl -MJSON -nle'$d=decode_json($_); print "$d->{timestamp} $d->{prb_id} $d->{min} $d->{ttl}"' | tee results.txt
I looked into the results a little bit and didn't find clues for a localized hijacking of 8.8.8.8 for the probes I looked at (out of the 10 total in that measurement). The fact that 8.8.8.8 is anycast may make it hard to distinguish between changes due to anycast flapping or localized hijacks.
Do the allocated probes stay fixed or rotate over time? (I’m new here, so hope the question isn’t too dumb). - Jared
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 20/03/14 09:47, Jared Mauch wrote:
On Mar 20, 2014, at 4:14 AM, Emile Aben <emile.aben@ripe.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 19/03/14 14:14, Jared Mauch wrote:
It appears there are some public measurements like #1002630, and i'm curious if someone is able to look at the latency and TTL numbers of the transport side and observe the localized hijacking of 8.8.8.8.
The dataset is somewhat huge and i'm not a json master so trying to discern if there is evidence in there is something i'm looking at.
This may works to get the data into an easier to digest form (requires the perl JSON module installed):
| perl -MJSON -nle'$d=decode_json($_); print "$d->{timestamp}
$d->{prb_id} $d->{min} $d->{ttl}"' | tee results.txt
I looked into the results a little bit and didn't find clues for a localized hijacking of 8.8.8.8 for the probes I looked at (out of the 10 total in that measurement). The fact that 8.8.8.8 is anycast may make it hard to distinguish between changes due to anycast flapping or localized hijacks.
Do the allocated probes stay fixed or rotate over time? (I’m new here, so hope the question isn’t too dumb).
Fixed, so you can look at the same probe over longer periods of time.
- Jared
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlMqrVkACgkQj05ACITZaqoq2wD+N0p5J96zlGYXYWtGA6gilc36 +uMMYC2YZs1+IdVMTz4A/3atwBaqzvUv2R7yXFHZDVnCw9Iacug616OJ96AKCaA1 =rKuO -----END PGP SIGNATURE-----
On Mar 20, 2014, at 4:56 AM, Emile Aben <emile.aben@ripe.net> wrote:
Fixed, so you can look at the same probe over longer periods of time.
Might be interesting to have an option to allow this to have entropy/reallocation after a single test to eventually collect data from all probes. Would be valuable for monitoring these ‘anycast’ type resources. - Jared
participants (3)
-
"Stephan Müller" -
Emile Aben -
Jared Mauch