Tech for blocking particular YouTube video - Wired.com question
froztbyte at froztbyte.net
Tue Oct 23 22:20:32 UTC 2012
On 23 Oct 2012, at 11:52 PM, Ryan Singel <ryan at ryansingel.net> wrote:
> A colleague is working on a story that a particular country not to be named
> implemented technology to block a particular infamous riot-inducing video
> for a certain section of its populace.
> The questions are: 1) how hard is this to do at scale, 2) does it require
> DPI equipment and 3) is there a way to prove, from an end node, that it's
Challenge number one, push all your HTTP through one specific place. Not that hard. Choke all your traffic via a single routed path, WCCP or whatever it off from there. Just need equipment that can handle it. I'm going to make a slight assumption here on the level of traffic required, since it's likely not /that/ much in those warring regions. But if you need more traffic, you may exceed device limits, and then you might run into interesting state sharing issues on async routing (if the traffic out goes over one router (thus one cache), and back via another router/cache combo). If you have enough budget, it's doable.
On question 2) I'd guess only if people were tunnelling HTTPS in normal HTTP. You could block HTTPS at port level, which would make YouTube (in normal operation) only be available over HTTP. You'd need tunnelling of whatever sort to get around this.
3) …possibly. I would hazard to say it'd depend on how they're going about blocking in.
To get back to 1: the moment you choke all the traffic through WCCP, you can hand it off to application servers that you maintain, and on those app servers you can then do whatever you like. This is how lots of semi-transparent/transparent caching is implemented.
If you need more info, feel free to mail me directly.
More information about the NANOG