Testing Net Neutrality is Hard

In the Netherlands we have a law on net neutrality, and we’re trying to defend this in Europe as well. Our law has been in effect since 2012. About one year after that, ISOC-NL received reports that some providers were breaking net neutrality. This was discussed in the Internet Transparency WG of which I’m also a member. The group worked together with the university of Dhaka to create a mobile app to test net neutrality on mobile providers, Open Internet.

After a few weeks we received some reports that seemed to point at some blocking in mobile networks. More specifically traffic on VoIP ports did not seem to always arrive. VoIP stands for Voice over IP, and as the name says is used to transport voice communication traffic over data connections. This provides functionality like Skype, but then in an open way.

Since I had a subscription to one of those providers and was able to use Internet tethering, I thought I could easily test this. So I created a small Python script with the relevant parts shown below:

Client:

sent = socket.sendto(“This is the message”,
       (server.example.com,5060))
sent = socket.sendto(“This is the message”,
       (server.example.com,5061))

Server:

sock.bind(server.example.com,5060)
data, address = sock.recvfrom(4096)
sock2.bind(server.example.com,5061)
data, address = sock2.recvfrom(4096)

This gives the following result when testing on WiFi:

2013-08-01 received 20 bytes from ('151.216.75.176', 58818) on 5061
2013-08-01          This is the message.
2013-08-01 received 20 bytes from ('151.216.75.176', 52500) on 5060
2013-08-01          This is the message.

But if you then test on the mobile network you get this:

2013-07-23 received 20 bytes from ('92.69.197.167', 42312) on 5061
2013-07-23          This is the message.

Something seems to be missing there.

During OHM2013 I was fortunate enough to get into touch with KPN CIO Jaya Baloo and was able to debug the issue directly with some of the excellent engineers of the KPN CISO team. We performed some more extensive testing, and finally we pulled out the Wireshark and fired up a VoIP client to send actual VoIP traffic and see what happens.

INVITE sip:service@server.example.com:5060 SIP/2.0
Via: SIP/2.0/UDP 92.69.254.254:39431;branch=z9hG4bK-54411-94-0
From: sipp <sip:sipp@172.20.10.4:5060>;tag=54411SIPpTag0094
To: service <sip:service@server.example.com:5060>

VoIP is a hideously complex protocol, because it has to work everywhere. It also has to deal with NAT, for which it has several options. One of these is through an Application Layer Gateway (ALG). This ALG grabs VoIP traffic, and inserts a Via header to show how the return traffic should go. In the packet shown above you can see one of those headers. It turns out that some SIP servers don’t know about the Via header and get confused. They then fail to bring up a connection, which makes it look like a network issue.

As you have guessed, the KPN mobile network has NAT and an Application Layer Gateway. The NAT is there both because of address shortage, but also for customer protection (you pay for bits sent and received). The Gateway tries to insert the Via header to all VoIP traffic passing port 5060. If you send something that is not VoIP through that port, like the Python script above, the gateway gets confused and drops it. So you see, testing net neutrality really is not as easy as you would think.

The big question is then: what about net neutrality in this case? The network tries very hard to help their customers, improving VoIP traffic that would otherwise not work, and it does so equally to all VoIP traffic. It does block non-VoIP traffic on that port, but is that a violation of net neutrality?

(This article is based on talks that I have given at OHM2013 and TA3M. If you want to read more about legal issues surrounding net neutrality, I recommend The proof of the pudding is in the eating by prof. Nico van Eijk.)