Youtube QUIC not recognized by NBAR

[GIdenJoe]

Hi all,

This is another finding I made when I was a bit bored and hoping some Meraki employee will pick this up.

So I have an MX at home and in my case video streams is "business relevant" especially for the kids. 🙂 So it's a traffic category I want the MX to recognize and give the AF31 marking and high bandwidth allocation from the internet connection.

The MX is in NBAR mode, so it recognizes 1400+ applications so it should recognize most.
However in the case if Youtube I run into an issue.

It appears that Youtube streams some video's inside TCP and other streams in UDP/QUIC depending on the selected quality setting.  And it seems that the MX is unable to classify the QUIC traffic for proper marking.

The screenshot above first shows the setting in the Traffic shaping page.

Then the initial DNS request and start of TCP based streaming.
Then some further TCP based streaming.
Further down the packet capture the next video segments are in QUIC and show the MX did not apply the AF31 marking onto the packets.

I believe the ads on Youtube were TCP based and the main video was later on moved over to QUIC.

EDIT: I also found a reference online that shows how Google implements the streaming:
http://web.cs.wpi.edu/~claypool/papers/yt-crawler/final.pdf

[PhilipDAth]

Good analysis!

The interesting thing to find out is if the latest NBAR engine knows about this or not.  If it did know about it Meraki would just need to update the engine in use in the MX.

If not I suspect Meraki would be the wrong people to talk to.  You would need to talk to the NBAR team at Cisco.  I have no idea how you would contact them.  Once the NBAR people have updated the signatures then Meraki would need to update the NBAR engine they are using.

[RomanMD]

This QUIC topic is pain in the ***.

The other day I came across this while peoples were reporting they can't watch youtube videos... and of course they were right, because we're not allowing UDP/80 or UDP/443... but what's more strange is that it mostly happens in Chrome because it is supported by Chrome (and can be disabled), but it does not happen in other browsers (at least per my checks).

Now coming back to NBAR. While I agree that the topic might be for the Cisco NBAR team - I would say - I am not buying a NBAR product, I buy a Meraki product that is advertised to support 1400+ NBAR applications and if it does not work as intended/advertised, it is solely Meraki's problem. How will they deal with Cisco NBAR team is again their problem.

[GIdenJoe]

I feel you guys.

I had someone who blocked streaming media in his firewall but wanted YouTube to go through and had to whitelist a bunch of googlemedia domains and allowing UDP ports.

@RomanMDthe captures were done on my pc and I exclusively use Firefox, so yes QUIC is also used on other browsers.  If you read the article that was linked  you'll see it has to do with the chosen quality.

@PhilipDAthcorrect I could have posted this on the Cisco community but I can't be sure which version of NBAR is used on the latest MX beta software.  Also I'm hoping some engineer will see this and just forward it to Cisco.

I haven't had a chance to test this on a non-NBAR network so I'm not sure if the classic Meraki TA will catch this or not.

[RomanMD]

@GIdenJoe I can assure you this is browser dependent. As you can see this is an experimental feature in Chrome. Maybe Firefox have implemented it too.. who knows...

In my very extensive testing on MacOS, I can see this happening in Chrome, but I can't see it happening in Safari regardless of the quality you choose. Nor did the QUIC fallback mechanism work while the UDP ports are blocked.

So I would avoid using QUIC at this moment, if possible.