Slashdot Mirror
Distributed Network for Reverse-Tracerouting
I got the head's up from some folks concerning Traceloop.com. It's an interesting idea - you can see what route your traffic takes on the /return/ path. By utilizing a large group of distributed test
points anyone registered with the service can run traceroutes in both directions provided there is a client near the destination ISP. So, they are looking for more people to sign up for the network - but also to have people use it. I'd like to see this used vis a vis DoS attacks and such - but this approach is a whole new way of doing this.
How many hops away from slashdot am I?
C:\>tracert slashdot.org
Tracing route to slashdot.org [127.0.0.1]
over a maximum of 30 hops:
1 <10 ms <10 ms <10 ms slashdot.org [127.0.0.1]
Trace complete.
Hrm, that looks pretty good. So why do the pages take so long to load?
--Shoeboy
Now I know I'm not some kind of network guru, but isn't there the possibility that this could be used to launch DDoS attacks? Any kind of distributed system has got to have the ability to launch such attacks, and open services like this must surely be more vulnerable to abuse than machines that have to be cracked.
Hopefully the encryption system they are using will withstand such attempts. At least they've thought about it, because this kind of thing would probably be a target for malicious script kiddies.
However it would be good to be able to reverse traceroute incoming packets. It's also nice to be able to worry less about allowing UDP and ICMP through your firewall, and hopefully this will be taken up by enough concerned sysadmins to make it a viable concept. As recent attempts have shown, tracking down the originator of DDoS attacks is pretty hard, and this might save us the threat of yet more Government "protection" for the net.
--Anticipation of a New Lover's Arrival, The
Are your statements business critical? There is more to life, and the internet, than money.
Alright, first, ICMP is a necessity. It is the Internet Control Messaging Protocol, and is used to troubleshoot network issues. It does _not_ use much bandwidth, and I seriously doubt it consumes 15-17%, though I do not have stats to back that up. Regardless, even if it does take that much bandwidth, or even 25%, it is a necessary part of the internet. I work at an ISP, doing routing configuration and troubleshooting most of the time, and without free reign to use ICMP however I want (which includes flood pings and extended pings), I could not do my job. This tool could be used to save a lot of time on the internet, actually.. here's a situation I see every day.. some customer has a problem reaching blah.com.. when he runs a traceroute, it goes all the way through my network, and then dies in another isp's network which I have no visibility to. I have to send email or call the other ISP and wait at their whim for them to address the problem, which happens slowly, if not at all most of the time. If Traceloop were inplemented across the board, a lot of time could be saved by Noc employees across the globe, which would mean quicker resolution of internet problems, which would lead to greater stability and speed on the network, which I am sure would help your precious business.
You business people need to realize that you don't own the internet. You pay for a very small amount of bandwidth on the internet, which you can do what you choose with, but you didn't build the internet, you don't maintain the internet and you have no right whatsoever to tell anyone else what to do with their bandwidth.
The only thing I can figure is you're either an idiot or a troll.. if the former is true, please go read Internet Architechtures by Halabi (cisco press book)... it is very useful. If the latter is the case, the fuck right off.
//Phizzy
"Most European technology just isn't worth our stealing," -- Former CIA chief James Woolsey, referring to Echelon
Sorry there, but if you take the time to read the FAQ you'll see that they express the same concerns about the possibility of this network being used as a launching point for DDoS. I don't see how this makes me a troll.
--Anticipation of a New Lover's Arrival, The
The UK academic network charge institutions (2p/MB on average), some of which pass the cost on to individuals, for transatlantic traffic.
Having a way to do reverse traceroutes would be invaluable for identifing the offending traffic more effectively.
Currently we can look at traceroutes for evidence of the JANET US gateways, and the ping time (anything that does through the US gateways >70ms) all of which isn't ideal...
Yes, it does.
They make the clients and run the central servers which tie the whole thing together. This is not a fully distributed Network like gnutella (thank god). So there is nothing wrong with them trying to make some money from it.
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
I'd like to see this used vis a vis DoS attacks and such
A serious DOS wil use spoofed source addresses, rendering this use useless.
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
While the distributed concept of this approaches something that might be called cool, there is already a remote tool installed at many NAPs which provides similar functionality in terms of reverse traceroutes and considerably more (BGP, etc). It's called looking glass, it's open source (perl) and doesn't carry around the broken subscriber model that this traceloop crap has.
Check out http://nitrous.digex.net for more info. An invaluable tool for routing engineers.
During a Denial of Service attack, certain peers can be overwhelmed, while others are passing little or no traffic. This tool will let you bounce tranceroutes off of other starting points so that you can correctly verify your transit and peering operation. There is a lot of value in this tool. I can see larger ISPs paying a subscription to gain access to this type of service to help them develop their own Quality of Service with peering providers.
Hopefully they add support for IPv6 and the 6bone, as for now we're restricted to using web pages with traceroute CGI's. For more information on BGP routing, take a look at http://www.landfield.com/rfcs/rfc1771.html. Have a nice day!
-Pat
Quite often the return route differs. In fact, in many cases, subsequent traceroutes won't even be the same. Packets will take whatever route any given router sends it by. If packets always followed the same route, there wouldn't be any such thing as out of order packets.
Just because a packet travelling from point A to point B passing through router C, because point A thought C was the best place to send the packet, does not mean that B will think the same thing. B may send the packet to a different router, or any of the many routers in between might make such a decision.
Of course, it doesn't really make any difference as long as the packet gets there. When this becomes significant is when you get horrible latency or speed issues when connecting to a specific site but nobody else has the same problem. The site may have plenty of bandwidth, but a router somewhere in between is sending your data to you through a clogged hole somewhere.
-Restil
Play with my webcams and lights here
The source for tltrace is freely available. The link hasn't been published on the site (yet), but it is tltrace-0.91b-1.src.tar.gz.
We will endeavour to make this clearer on the web site in the future. Go ahead and grab it if you like.