Re: [tsvwg] L4S & VPN anti-replay interaction: Explanation

["Black, David" <[e-mail]>]

Dave,

Thanks - I have one clarification on the third item in your message:

> 3) Exposing different diffserv codepoints in a single flow ...

For clarity, that's not part of the scenario here.  Each transport flow would use a single DSCP, which differs for L4S vs. Classic flows so that a Diffserv classifier can direct L4S and Classic traffic to different IPsec SAs.  FWIW, Transport protocols such as TCP have a history of not working well with multiple DSCPs in the same flow - see RFC 7657 for details (https://datatracker.ietf.org/doc/rfc7657/).

In contrast to the ECN field, a VPN sender for an IPsec tunnel-mode VPN is allowed to change the DSCP as part of tunnel encapsulation - an example described in earlier list discussion always clears the outer DSCP to zero.

Thanks, --David

-----Original Message-----
From: Dave Taht <[e-mail]> 
Sent: Tuesday, May 11, 2021 11:48 AM
To: Black, David
Cc: [e-mail]
Subject: Re: [tsvwg] L4S & VPN anti-replay interaction: Explanation


[EXTERNAL EMAIL] 

Dear David:

This was an extremely clear discussion of what can go wrong with
reordering in a vpn tunnel.
I, like many other linux devs, have switched to wireguard and not
looked back, as we made site-site vpns like ipsec and that work
beautifully with fq_codel also on that bottleneck link, and userspace
vpns like openvpn have severe bufferbloat problems whether run

I've long meant to get on top of openvpn to have it manage its
internal queues better.

In reading your description I ultimately have 3 points to make.

1) I was reminded of how hard it was to diagnose and fix a similar but
different crypto/reordering interaction problem over wifi we
encountered in early versions of the "ending the anomaly" codebase,
which I'd written up, as amusingly as possible, over here:

http://blog.cerowrt.org/post/crypto_fq_bug/

I am curious what other tools, besides tsde as used there, exist to
detect persistent re-ordering issues, as a plugin to wireshark, or so
on?

2)

I don't know a lot about userspace p2p vpns nowadays, but after a
difficult encounter with
one corp that shall remain nameless's universal per employee vpn tech,
I plan to go take a hard look at

http://www.infradead.org/openconnect/ to see what they do as to
encapsulating dscp and ecn markings. Not having sources to many other
ostensibly secure vpn technologies kind of bothers me... I guess I
should go look hard at ssh also.

3)

Exposing different diffserv codepoints in a single flow to a wifi
stack will end up dropping
it into different wifi AC classes, which have dramatically different
media access properties.
The maximum number of packets that can fit into each of the 4 classes
each is 64k or 42 packets on 802.11n, I think it is 96 or higher (and
4Mbytes) on 802.11ac, and I'm about to go review the now final ax spec
to see if they were paying attention to how vpns might behave over it.