CenturyLink to Service SMB Segment With Managed WiFi Network [telecom]

Network Neutrality is no problem for Centurylink: the company will allow its "SMB" "customers" to "prioritize" and "throttle" traffic before it gets to the ILEC's wires.

- - - - - - - - - - - - -

Regional wireline operator and incumbent local exchange carrier ("ILEC") CenturyLink Inc. CTL is opting for managed WiFi services to cater to the demands of small and mid-sized business (SMB) and to lure more customers in this segment from cable TV operators and Competitive local exchange carriers ("CLEC").

Based on Meraki technology of Cisco Systems Inc., the managed WiFi platform will offer real-time monitoring and analytics in order to enable enterprises to better connect with customers. Business customers will be able to view their networks through Meraki's dashboard. They can also prioritize and throttle priority and nonpriority applications. Moreover, enterprises can use client- and location-based analytics to better serve their client who are connected to the network.

formatting link

We've been using Meraki wireless for nearly as long as the company has been around (disclaimer: Meraki was a CSAIL spinoff and gave us a very steep discount on our initial deployment). I have found that their application identification is informative, but unfortunately the product lacks integration with IP differentiated services on the wired side, so I decided not to try to use it for traffic prioritization.

The product uses a combination of shallow and deep packet inspection and DNS snooping to identify applications, rather than just protocols. I suspect that it also has lists of certain providers' network blocks as well. If I look at my top-20 "applications" over the past 24 hours, it tells me that they are:

1) SSH, 2) "Miscellaneous secure web", 3) "Apple file sharing" (local backups), 4) Dropbox, 5) YouTube, 6) apple.com, 7) "UDP", 8) "Non-web TCP", 9) "Miscellaneous web", 10) iTunes, 11) Facebook, 12) Google HTTPS, 13) "Encrypted TCP (SSL)", 14) "Software updates", 15) Google, 16) Spotify, 17) "CDNs" (Content Distribution Networks), 18) iCloud (Apple cloud backups), 19) Gmail, 20) "Miscellaneous video"

"Applications" 1, 2, 3, 7, 8, and 9 are easy to identify by shallow inspection [TCP/22, TCP/443, TCP/548, UDP/(not 53 or 5353), TCP/(not

80 or 443), TCP/80]. The rest require some form of payload inspection (either DNS snooping or actually looking for protocol handshakes inside TCP connections). Streaming video can be semi-reliably identified on the basis of interarrival times.

If I dig more deeply into the list, I can see which news sites my users frequent, where they shop (I'm going to assume for business-related purchases here), and what cloud and peer-to-peer applications they use. As an operator of a university network, this level of packet inspection doesn't bother me much (after all, I'm already snooping on every packet that enters or leaves the network anyway). As a residential customer, I'd be a bit more uncomfortable. (And I know that my home ISP is almost certainly collecting similar data on me to sell to advertisers without my consent.)

This sort of traffic analysis is now fairly routine and easy to do. It is one of the justifications for DNScrypt, a proposed protocol for clients to communicate with (non-ISP) resolvers without exposing the content of queries, although it's not clear how much that buys you given that for most applications, a DNS lookup is almost immediately followed by an HTTP(S) connection which reveals the same information.

-GAWollman