Topic: I had a short conversation with a person who works at an ISP provider (Read 2413 times)

Packet level filtering will not ultimately work in stopping Bitcoin I think, although it could well be tried and may even be a catalyst for dramatic changes in society.

Attack 1: filter Bitcoin protocol
Response: encrypt, e.g. using vpns, secure tunnels, ssl connections

Attack 2: restrict use of encrypted connections to "trusted" sites (not easy to do fully, and a devastating attack on internet freedom, crippling a lot of activity).

Response: perhaps move to a steganographic approach. Hide bitcoin data in plain sight (even in html pages?).

Attack 3: revert internet to a limited "walled garden": customers allowed only incoming connections, can only access government mandated hosts.
This is a dial back to something worse than mid-90s internet which is nearly unthinkable right now. Note that even China allows a lot more than this.
Response:
Meshnets? Revolution?

Bingo!  Since we are talking about a financial system which we hope people can feel confident relying on to store and utilize value it some quantity it is more critical to consider a wider range of attack surfaces than would be the case with other applications.

There is also the fact that any nation's monetary system is a hugely important facet of the state's function.  So, an alternate system which could challenge the official system could be a significant threat justifying a significant response.  Problems here would be triggered more my a weakening of the official system than by a strengthening of alternate solutions, and and economic or currency crisis would be accompanied by a lot of extra-normal policies.  A clamp-down on freedoms of access to the global internet would probably be a lesser of the multitude of complaints.

The use of packet filters and protocol recognition and disruption is common to control people's behaviors within organizations.  It seems (to me) not much of a stretch to project that it could happen at the direction of a nation-state level when a compelling need arises.  There will be a golden period of time when it is quite effective since it will spur a lot of interest in developing work-arounds.  For this reason it is good policy to wait until a crisis situation for any real use so that people are lulled into a belief that since it has not happened yet it never will.  Or more typical; "What is packet filtering?"

Probably. Once the company you work in is large enough, it's fine to have very specialized employees that only know their specific tasks and not much more. A radio/communications engineer at Boeing doesn't have to know how the thing flies, just how the crew can talk with others. A sales rep at an ISP doesn't have to know what ports are and how they work. Of course, you run into the situation where such employees have vague and incorrect ideas about how these things work and then suddenly gain undue credibility because of the company they work at.

He/she might be the one that makes the tea/coffee.

This seems quite hard to believe. There are so many Web based services that don't use port 80. Mail clients, flash streaming, messengers, HTTPS, login for most web control panels. That's what I use at least, so that's at least 5 - 10 ports for me, and I'd say that's pretty average web use.


If they do this, then they are going to have to have enough phone staff to handle several calls from every single client of theirs over the next few days. After the initial surge of calls, so long as people keep writing software which utilizes the web, they're going to have a constant stream of phone calls from angry customer because the favourite new IM doesn't work, or they can't skype their grandma in Scotland.

Is there any evidence of any other ISPs doing this ever? I'd be intrigued to find to find out how they handle it.


Who is "this person"? Some random drunk you met in a pub? Your best friend who you can confirm works for an ISP?

I'm really surprised that everyone that has responded so far seems to have just accepted this is true. I suppose even if it's not true, it's still helpful/useful to consider how resilient Bitcoin would be if someone did actually choose to do it.

Only port 80? So no https, no FTP, no email... WTF? He was joking I guess.

Seems pretty unlikely, no?  I've talked to employees at Boeing who have no idea how a plane flies.  Maybe that's what's going on here?

Is this a very small ISP?

Amusing we've been blocked here in UK from visiting Pirate Bay.
Obviously our government hasn't heard about TOR.

Did this person work in The Department of Redundancy Department?   

Seriously, the previous response had good suggestions.

The ISP has to know that the technical minded can get around the block s for most or all protocols. This was interesting to hear about.

That's the worst traffic control policy I've ever heard of, many ISP's, like the one I use, use this, http://www.sandvine.com/ , it is able to shape traffic by protocol no matter what port you are using, I have to use a VPN to bypass traffic shaping.

I use Google since 8.8.8.8 and 4.4.4.4 are easy to remember.  I ran Bernstein's old jdbdns for a while but eventually it had to many problems that I didn't fell like dealing with.  In the future if I have nothing better to do I may run one in the cloud and access it through a tunnel or something like that.  Of course I had to deal with BIND as well for work reason.  At least to the degree that I had to make it work and make a token effort to keep it secure...again...and again...and again...

Point is, from an ISP's point of view the though of losing a tiny fraction of customers, and especially highly technical ones who are more prone to cause problems, is simply not a huge concern.  Also, it is unlikely that we geeks are going to rally a army of grandmothers to our cause on the basis of being denied use of an obscure system which very few people understand.  This is especially true if it can be painted as a tool for miscreants, and like it or not a lot of this technology can be.  With some amount of legitimacy even.  Failure to appreciate this unpleasant reality will lead to a failure to construct the proper defenses against potential threats.

Now you are going beyond the premise of the OP though.   

More likely,  a restricted environment would/should force everything to go through a proxy they run anyway. 

I always resolve my own queries with dnsmasq. If I use my ISPs ones, they redirect to a page pumped with adverts if a page doesn't exist. No thanks!

Most people use either the resolves configured by the ISP, or one of the compliment providers of such service.  Rules to pass port 53 could easily be constructed.

If they allowed only port 80 and block all the rest, DNS queries wouldn't resolve.

If you want to run bitcoind as root.  I like to run nothing as root.  Linux dudes can use ipchains to avoid this and BSD guys have similar methods as well.

Of course this does nothing to guard against DPI.  It would be pretty straightforward to differentiate between http and other traffic.

As for port 443, it seems to me that it would be fairly triffling to employ a whitelist of netmasks which would leave 99.9% of customers unaffected.  And those who are can go piss up a rope since they are more trouble to an ISP than they are worth.  Or at least to an ISP who was incorporated under Western law and thus legally obligated to maximize shareholder profits.

+1;

You can set ports on any torrent client to 80. Just can't browse with the machine that is setup like that. BTW most ISP do something call Deep Packet Inspection under the guise of ITMP (Internet Traffic Management Protocols) and while they can't see the whole packet they can even uncover generally what you are d/ling (especially if it is not encrypted).

I doubt they would block post 443 used for https, so a common way to get around a censor is to tunnel over port 443 to an uncensored VPN. The following article explains some of the arms race between the censors and those getting around the censorship. http://www.bestvpn.com/blog/5919/how-to-hide-openvpn-traffic-an-introduction/

bitcoin protocol uses TCP on port 8333, although it can be reassigned to any port, including port 80.