Network Measurement Tool Detects Reset Packets 118
kickassweb writes "If you think your ISP is sniffing packets, or worse yet, sending reset packets to stop torrents, there's now a beta Network Measurement Tool to detect them, courtesy of Lauren Weinstein of the Net Neutrality Squad. It's released under the LGPL, and runs under Win2K, XP, and Vista. Quoting: 'While the reset packet detection system included in this release is of interest, NNSquad views this package as more important in the long run as a development base for a broad range of network measurement functionalities and associated communications and analysis efforts.'"
Ignoring reset packets? (Score:2, Interesting)
Of course the ISPs shouldn't be allowed to spoof any packets, but what would be the consequence of ignoring all reset packets on a home network?
RST blocking? (Score:5, Interesting)
tcpdump? (Score:1, Interesting)
http://www.tcpdump.org/ [tcpdump.org]
The evolvong nature of "open" (Score:3, Interesting)
I believe new software will appear that works around the next attempt to block torrents, and new software to go arround the one after that
If there is a big-enough interest in code/protocol changes, and the code / protocol is open, you can't "put a stop" to it.
Well
Re:RST blocking? (Score:5, Interesting)
Re:RST blocking? (Score:5, Interesting)
Re: Network Measurement Tool Detect Reset Packets (Score:5, Interesting)
Re:tcpdump? (Score:3, Interesting)
Re:Grammar? (Score:4, Interesting)
Special thanks to John Bartas for all of his diligent and continuing work on this software for NNSquad.
Re:The race is on (Score:3, Interesting)
Im becomming suspicious of my ISP for that reason, aside from obvious traffic shaping (which I usually dont mind too much), they also just drop the internet entirely but leave the network intact, so any computers still think there is internet but it goes no further than the ISP, upon which I start fucking with their servers until I get internet back. (you know, 'boredom')
Throttling should not use RESET (Score:4, Interesting)
The correct (and difficult to detect) way of throttling is by delaying ACK packets a few ms. Then normal TCP congestion control does all the nice throttling for you.
The ethics of throttling are a different matter: one side says they've been promised unlimited, and the other wants to be fair to all customers.
Not directly relevent, (Score:1, Interesting)
He says it's just three guys (only one on at a time afaik) and when they see someone using to much bandwidth, they phone them up and tell them to settle down with the downloads.
Re:RST blocking? (Score:2, Interesting)
The net result of IPSec (or TLS) without strong authentication of both parties is that each packet consumes considerably more energy on the transmit and receive end systems, and any snooping middle system(s).
At best you get protection from trivial sniffing and injection attacks. That is not necessarily bad, but anyone actually doing deep inspection is already in a position to do more than trivial sniffing and injection.
PSK is difficult to scale to large numbers of counterparties, especially since you really want to do PSK out of band, and cope with compromised shared secrets. For small numbers of stable connections with known parties (as with a corporate VPN), PSK is a useful approach. For large numbers of connections with random parties, PSK scalability becomes really difficult, and is largely an unsolved problem (i.e., the "fix" is to use PKI).
PKI suffers from trust issues, namely who do you trust as an introducer. Usually that is done for you by the writer of a library (openssl, for example) or a tool (curl or wget, for example) or a browser, or an OS vendor, or some combination of these (either and-wise or inclusive or-wise). By default, everyone seems to trust Verisign among others. Alternatively, webs of trust are in use, and these suffer from the Kevin Bacon effect -- if you do not know Kevin Bacon, you have to trust someone when he or she claims to know Kevin Bacon, or one of Kevin Bacon's friends, or
Opportunistic IPSec originally anticipated using DNSSEC as a PKI database. This hasn't worked especially well for a variety of reasons; TLS's PKI system won in the marketplace and will be hard to dislodge, especially as it is increasingly integrated with authorization (and user authentication) systems like SASL.
Most crypto users seem not to turn on ephemeral key negotiation, for example, with Ephemeral Diffie-Hellman session key exchange. EDH is computationally expensive (and requires some handshaking) but without an ephemeral key exchange you are unlikely to have forward security. That means if a certificate is compromised, all sessions protected under that cert are compromised, including those sessions recorded "ages ago". Lots of X.509 certificates are in use now that are fairly weak already, and will be very weak within a couple of years. Some of these certificates supposedly protect information that will still be useful to attackers after those couple years are up...
Crypto is not a bad idea just because it doesn't protect one against determined traffic shapers; the general goal of TLS and IPSec is to make it much more attractive to use social engineering or other attacks on human beings, than to try to do cryptanalysis or other attacks on intercepted (or recorded) traffic. Unfortunately the two methods compose well; record traffic now, seduce/force a human being into giving you the key to decrypt it later. EDH/cycled-ADH with strong PKI certificates are the only well-known way to reduce that particular compositional problem.
Finally, the reality is that most P2P users *don't* want to be strongly identified, so authentication of counterparties is simply not a goal. In that case, crypto does very little except in the short term.
Re:Not directly relevent, (Score:3, Interesting)
I've since switched to Sasktel. While it's a lower max bandwidth, I don't have to share, and I don't get a phone call asking me to "tone it down" when I use my account for more than just email...