These days with the prevalance of HTTPS, another option is to inspect the TLS client hello packet. To work well with load balancers etc, clients typically indicate the server name that they're trying to connect to (SNI - https://en.wikipedia.org/wiki/Server_Name_Indication). That information is not encrypted. So you have both the dst IP and hostname in the initial packet.

Zero-rating at ISPs via SNI inspection is pretty common practice

Makes me wonder if one could bypass the zero-rating scheme with a custom TLS tunnel that sends SNI headers for Facebook.com to your own server.

You probably can. But it would require a custom app that doesn't use the same cname for DNS resolution, SNI and then inside follow-up requests in the Host header. A web-browser would e.g. just use the same values for all of those, and then you either get charged or would end up at facebook.com.

It's also a preferred hardware inspection as its dead easy to rip the header than to seek mid-message to do message entropy/fingerprinting.

It's indeed pretty simple for TLS over TCP, since the whole ClientHello is part of the first packet and relatively easy parse or seek for. With QUIC it becomes a major pain, since it's not obvious anymore for middleboxes which QUIC packet is the first in a connection, and since Crypto data can be fragmented and reordered (Chrome is doing that by purpose even inside single packets). Therefore hardware inspection would require a pretty full-featured QUIC protocol parser and understanding.

It's easier to just block QUIC. (And UDP in general, might as well)

Interesting, thanks for the insight.

I don't understand, what's the domain of.. WhatsApp? Not to mention you are just as likely to hit some Round-Robin configuration.

This is a very good question.

I would also assume that Whatsapp might change the servers used with updates of the app. How would Delta deal with that? Just wait for the complaints to come in?

WhatsApp (now, since it moved into FB's infra) connects to g.whatsapp.net, which is a CNAME to chat.cdn.whatsapp.net, which in turn is an A record to a VIP on Facebook's edge network. The A record you're returned can change — it's intended to be one that's closest to you (as determined by your DNS resolver's location and probably EDNS Client Subnet) but traffic engineering policies might cause different responses over time.

Since on a flight it's likely everyone will use the same resolver on the ground somewhere in Delta's infrastructure a simple mechanism to resolve the IP periodically and update a whitelist (or to cache one VIP location and always return that) might work. Alternatively, as other commenters have suggested, it'd be better to identify traffic with SNI or other profiling.

Updates to the app almost certainly won't change the address it connects to.

> Updates to the app almost certainly won't change the address it connects to.

Well, they have before. There's four generations of hostnames that were used before g. But g seems likely to work for quite a while.