Packet Analysis Academic Research
Hi,
I'm researching how DPI and SPI can be used to block short form content to improve mental health.
I closest explanation I've found is: https://www.cloudflare.com/learning/security/what-is-next-generation-firewall-ngfw/
Any insight or resources will be extremely helpful, thanks!
14 Replies
Willing to pay for a consulting session!
I'm researching the feasibility of detecting whether a device is loading short form video content, with the intent of blocking it
So not exacly block to websites, that's what DNS is for, but more for different type of content served from the same CDN
yes that's what DPI is about
headers aren't encrypted though
are you talking about http headers or packet headers?
I swear I saw that you can see packet headers
and the data part is encrypted
So here's the deal: loading short form content (Youtube shorts) triggers periodic packet spikes because of the data amount, the periodicity of this packet spike in theory can be linked with user scrolling an app
Do you see any flaws in this approach
does that even count as DPI
another think I looked into is that youtube server all their videos using QUIC, for a long video it does buffered loading from the same ip, for youtube shorts it's a different ip every time
good idea
so tldr, is this idea crazy
You're going to detect a massive amount of content as YouTube with these heuristics unfortunately. QUIC is just HTTP/3 which a good portion of the web uses, and when buffering people will load from the same IP because of request affinity
Really the only ways to do DPI are:
1. If the user consents, to install a certificate on their device and then do request interception (this is what Cloudflare WARP does)
2. Do wide-ranging blocks like the GFW as Leo mentioned above.
what about reverse DNS lookups to narrow down the packet source
then it would just be either youtube long or short videos I have to distinguish
This won't work either, as YouTube is using the Google IPs (ex.
whois 142.250.176.206 returns Google) so you'd end up blocking any Google IPs
You also can't detect video or regular content because that's all done after the initial handshake, within encryption.I'll show you some data I got one sec
aaah can't find it
but I can though detect udp packets
Not sure how? UDP is still HTTP/3, so heavily encrypted + it's not just video using UDP
Literally the only thing you can detect from the packet header is source IP (the client), destination IP (a random Google IP, not YouTube specific), and the length which means nothing.
If it was possible to detect traffic through TLS encryption that would be a massive security flaw and would be patched nearly instantly since the entire web uses TLS and relies on it to secure things like banking, medical info, etc.
I'm relying on frequency analysis. I tought it falls under DPI, my bad
This graph shows only YouTube videos though, have you tried graphing other content?
That's just graphing the number of packets, which will increase due to regular web traffic that uses HTTP/3
this is accumulated of my entire network interface filtered for UDP
what else would trigger udp, downloads?
UDP is used for HTTP/3, and a large number of sites use HTTP/3 for regular content (HTML, images, css, etc)
And downloads, yeah
Doeesnt look like downloads trigger UDP, HTTP/3 does though, you're right. Tested on facebook maily
UDP is just a connection protocol so there's going to be a lot of things that use it that aren't videos:
- games uses UDP for multiplayer
- WebRTC, i.e. Zoom/Teams/Google Meet use UDP
- web browsing (HTTP/3)
- voice-over-IP, i.e. some phone calls
So detecting based on UDP packet count is going to be almost certainly too imprecise.
my hope was that the video bandwidth generates enough UDP traffic to overshadow other communications.
The hard part is knowing which UDP packet came from which provider
apparently content served over youtube shorts resolved to the network provider