On 26 Oct 2015 00:44, "David Woodhouse" <[email protected]> wrote: > > On Mon, 2015-10-26 at 00:15 +0100, Steffan Karger wrote: > > On Mon, Oct 26, 2015 at 12:09 AM, Steffan Karger <[email protected]> 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.
Well, I will admit that is the case for the large majority of OpenVPN use cases, in particular the road warriors. But there are also use cases, such as connecting otherwise isolated networks, where this *is* a concern. > 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". Heh, that did make me smile :) > 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. I am actually very interested in this part too, but lack the experience to make any statements here. *waiting for Gert and/or Arne to chime in* -Steffan
