Network Measurement Tool Detects Reset Packets

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.'"

Comments

Ignoring reset packets?

[Ojuicer]

First the Chinese firewall, and now ISPs closer to home.
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?

[Applekid]

IANANG (I Am Not A Network Guru) but, what harm could happen if, say, all reset packets were just ignored and dropped by the network stack? All the hubbub about figuring out if your ISP is sabotaging you seems less useful than just blocking the shanangans and moving on with your life.

Re:RST blocking?

[cduffy]

Without RST packets, how are you supposed to know if the remote host is legitimately closing the connection?

Re:RST blocking?

[Zocalo]

Assuming that you have a device capable of doing so, which I doubt many SoHo router/firewalls are, then there are not too many issues with dropping RST packets, and none of the them are show stoppers. It'll take a little longer before your web browser or whatever can determine that the remote site is genuinely down or otherwise refusing connections but that's about it from the "end-user" point of view. If you have a Linux proxy box however, then IPTables is perfectly capable of doing this for you, and can even do so in a sensible way - ie. just for BitTorrent traffic, just to pick a protocol at random.

Re:RST blocking?

[Anonymous Coward]

Opportunistic IPSec runs into the problem that you need a pre-shared secret ("PSK") or a public key infrastructure ("PKI"), otherwise malicious persons will simply do man-in-the-middle attacks on the key exchange, so they can do deep inspection of the encrypted traffic anyway (they just have to add decryption to the inspection process).

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 ... etc. Scalability is awkward, and key distribution becomes a point of failure, since you don't just "build in" a small number of top level certs.

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.

The evolvong nature of "open"

[utnapistim]

This just highlights the evolving nature of open ... protocols? (it's more than the software).
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 ... not for long.

Re: Network Measurement Tool Detect Reset Packets

[CogDissident]

Well yeah, but having a tool where you can have joe-average download it, press a button, and get all upset at Comcast has much more value.

Re:tcpdump?

[morgan_greywolf]

Well, probably. I know you can do this with Wireshark, and wireshark and tcpdump both use libpcap.

Re:Grammar?

[Vectronic]

From The Site:

Please let us know if you're interested in coordinating on ports to other platforms, such as Linux, BSD, and Mac, or embedded hardware (e.g. WRT54G router).

Special thanks to John Bartas for all of his diligent and continuing work on this software for NNSquad. So, I would assume that its just the one guy working on it (at the moment) which would explain why its Windows Only, its probably his chosen platform.

Re:The race is on

[Vectronic]

Yeah, and when that fails just cut the internet off... "just doing some routine maintenance"

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

[redelm]

Not that [ISP] managment have ever been known for great intelligence, but throttling connections via RESET is just plain dumb. The client will just retry and extra data transferred.

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.

Re:Not directly relevent,

[Jabrwock]

A good friend of mine works for Shaw Cable... 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. I got one of those calls, and the guy I spoke with couldn't tell me what "grey zone" I'd wandered into, or why my unlimited account... wasn't. I asked him what I should cap my d/l rate to, so I wouldn't get these calls, and he said there wasn't a limit "per se". So I asked him why he was calling me with a vague request to stop using so much of a service he couldn't define for me. No answer.

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...