[Cerowrt-devel] cerowrt 3.6.9-5

[Cerowrt-devel] cerowrt 3.6.9-5

[Dave Taht]

Under absolutely no circumstances install this on your default gateway.

http://snapon.lab.bufferbloat.net/~cero2/cerowrt/3.6/3.6.9-5/

* IPtables moved forward to 1.4.16.3 (thx swalker)
* IPv6 instruction traps eliminated (Thx robert bradley) * wow! big difference!
* Enabled (the old, non signed) opkg (thx murphy)

I would, however, now that opkg works again, like people to take a
look at their favorite packages, and see what broke. (and what's
missing!)

I'm pretty sure samba's default config is wrong... there's a new
dhcpv6 client daemon totally untested... I haven't folded in the upnp
fixes.... didn't try mesh networking....

Probably one of the biggest things that concerns me is vpn behavior
under fq_codel, and in the three bin classification scheme the
simple_qos.sh script uses. (openvpn is installed by default,
strongswan as an option)

And:

Given how successful that script has been at actually using
classification I've been toying with the idea of boiling the core
ideas of simple_qos, into pure C in the the nfq_codel version of
fq_codel, so that htb would not be required to do it (in other words,
it would "just work" in variable rate scenarios)

Partial syntax idea:

tc qdisc add dev whatever root nfq_codel bgweight 20 # Background
traffic would get 5% of the sent packets

Regrettably I can't come up with a mental way to express a "capped
weight" for priority traffic...

That said, merely having a background class may well be good enough,
as fq_codel does such a great job already in taking light traffic that
should be high priority and making it so.

I go back, however, to worrying about encapsulated traffic (such as
vpn) that might need to ignore classification in order to preserve the
stream boundries....



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] cerowrt 3.6.9-5

[Michael Richardson]

>>>>> "Dave" == Dave Taht <dave.taht@gmail.com> writes:
    Dave> I go back, however, to worrying about encapsulated traffic (such as
    Dave> vpn) that might need to ignore classification in order to
    Dave> preserve the 
    Dave> stream boundries....

What do you mean here?

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 

Re: [Cerowrt-devel] cerowrt 3.6.9-5

[Dave Taht]

On Mon, Dec 10, 2012 at 1:00 AM, Michael Richardson <mcr@sandelman.ca> wrote:
>
>>>>>> "Dave" == Dave Taht <dave.taht@gmail.com> writes:
>     Dave> I go back, however, to worrying about encapsulated traffic (such as
>     Dave> vpn) that might need to ignore classification in order to
>     Dave> preserve the
>     Dave> stream boundries....
>
> What do you mean here?

I worry about encapsulating protocols copying the inner TOS/Diffserv
bits to the outer IP header. Using a shaper that is aware of these
bits would end up delivering packets that depend on a sequential
encrypted stream out of order.

I went looking into it a bit and it looks not to be a problem with
openvpn, gre, and ike, as the protocols are not defined to do that.
6in4 is OK as it's pretty stateless... I think the other ipv6
encapsulating protocols should be fine too.

(what actually happens in the real world has to be looked at, though)

My head explodes when trying to understand AH and ipsec (strongswan),
however, and I'd rather set up one and look at packets than try to
understand the code. ENOTIME... and that leaves ipip etherip and
encap, and l2tp left to look at.

I'm also growing interested in protocols we could no longer use in the
NAT era, but can in the ipv6 era (even with npt66), like sctp, and
hip.... (100+ others elided), and also ones that are heavily used
outside of conventional networking, like dccp.

Then there's various forms of multicast...

As happy as I am with fq_codel and it's upcoming successors, I keep
looking for things that will break if we flipped a switch tomorrow and
converted linux over to it!

For example, it would make sense to FQ packets entering the
ipsec/openvpn portions of the stack somehow, and it is suboptimal to
penalize vpn streams over all others.

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] cerowrt 3.6.9-5

[Michael Richardson]

[-- Attachment #1: Type: text/plain, Size: 3876 bytes --]


>>>>> "Dave" == Dave Taht <dave.taht@gmail.com> writes:
    Dave> I worry about encapsulating protocols copying the inner TOS/Diffserv
    Dave> bits to the outer IP header. Using a shaper that is aware of these
    Dave> bits would end up delivering packets that depend on a sequential
    Dave> encrypted stream out of order.

1) RFC4301 is quite specific about this... it permits a window of up to
   64 (even 128) out of order packets.   It's not a problem.

    Dave> My head explodes when trying to understand AH and ipsec (strongswan),
    Dave> however, and I'd rather set up one and look at packets than try to
    Dave> understand the code. ENOTIME... and that leaves ipip etherip and
    Dave> encap, and l2tp left to look at.

2) Strongswan, unless it added in it's IKEv2 implementation, could
negotiate how to set/copy ECN bits.  However, that was never in openswan
historically (from which strongswan forked)

L2TP generally is no longer used without IPsec.
The ECN bits are "fresh" on new packets.... the issue is propogating
them into the inner packet on decap.  I don't know if the Netkey kernel
IPsec code is compliant to RFC3168 or not, but it's a decap concern, not
an encap shaping concern.

RFC4306:
2.24.  Explicit Congestion Notification (ECN)

   When IPsec tunnels behave as originally specified in [RFC2401], ECN
   usage is not appropriate for the outer IP headers because tunnel
   decapsulation processing discards ECN congestion indications to the
   detriment of the network.  ECN support for IPsec tunnels for IKEv1-
   based IPsec requires multiple operating modes and negotiation (see
   [RFC3168]).  IKEv2 simplifies this situation by requiring that ECN be
   usable in the outer IP headers of all tunnel-mode IPsec SAs created
   by IKEv2.  Specifically, tunnel encapsulators and decapsulators for
   all tunnel-mode SAs created by IKEv2 MUST support the ECN full-
   functionality option for tunnels specified in [RFC3168] and MUST
   implement the tunnel encapsulation and decapsulation processing
   specified in [RFC4301] to prevent discarding of ECN congestion
   indications.

RFC4301:
5.1.2.  Header Construction for Tunnel Mode

...
    o IPsec describes how to handle ECN or DS and provides the ability
      to control propagation of changes in these fields between
      unprotected and protected domains.  In general, propagation from a
      protected to an unprotected domain is a covert channel and thus
      controls are provided to manage the bandwidth of this channel.
      Propagation of ECN values in the other direction are controlled so
      that only legitimate ECN changes (indicating occurrence of
      congestion between the tunnel endpoints) are propagated.  By
      default, DS propagation from an unprotected domain to a protected
      domain is not permitted.  However, if the sender and receiver do
      not share the same DS code space, and the receiver has no way of
      learning how to map between the two spaces, then it may be
      appropriate to deviate from the default.  Specifically, an IPsec
      implementation MAY be configurable in terms of how it processes
      the outer DS field for tunnel mode for received packets.  It may
      be configured to either discard the outer DS value (the default)
      OR to overwrite the inner DS field with the outer DS field.  If
      offered, the discard vs. overwrite behavior MAY be configured on a
      per-SA basis.  This configuration option allows a local
      administrator to decide whether the vulnerabilities created by
      copying these bits outweigh the benefits of copying.  See
      [RFC2983] for further information on when each of these behaviors
      may be useful, and also for the possible need for diffserv traffic
      conditioning prior or subsequent to IPsec processing (including
      tunnel decapsulation).


[-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --]