On Mon, 2015-10-26 at 00:15 +0100, Steffan Karger wrote: > On Mon, Oct 26, 2015 at 12:09 AM, Steffan Karger <stef...@karger.me> wrote: > > For > > covert channels, it means 23 possible values per 1500-byte packet, or > > ~5 bits for BF, and 12 possible values (~4 bits) for AES-CBC. That is > > still less than the 8 bits QoS/ToS. > > Grmbl, at the moment I hit send I realize I messed up bytes and bits > in this back-of-the-envelope calculation. For 1500-bytes packets, > there are 187 possible lengths (~8 bits) for BF-CBC, and 93 possible > lengths (~7 bits) for AES-CBC. So just barely less than QoS/ToS, but > --passtos would still double the bandwidth.
To be honest, you'd lost me a little before that anyway. The design goals of a VPN deployment typically *don't* include blocking that kind of covert channel anyway — and if it did, then we should all pack up and go home, because we've failed. It's not so much "I'll just disable the brakes", but more "there's this burned-out wreck by the side of the road and three of its wheels are missing; they probably won't notice if I take the fourth". I'm actually *more* interested in the potential for incompatibilities if we start setting the TOS bits — as we saw with stupid firewalls dropping packets when ECN was in use. That sounds like a much more reasonable argument for not doing --passtos by default, although even that is somewhat diminished these days — I think most such firewalls have been fixed now. -- dwmw2
smime.p7s
Description: S/MIME cryptographic signature
