* [Cerowrt-devel] cerowrt 3.6.9-5
@ 2012-12-09 7:28 Dave Taht
2012-12-10 0:00 ` Michael Richardson
0 siblings, 1 reply; 4+ messages in thread
From: Dave Taht @ 2012-12-09 7:28 UTC (permalink / raw)
To: cerowrt-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Cerowrt-devel] cerowrt 3.6.9-5
2012-12-09 7:28 [Cerowrt-devel] cerowrt 3.6.9-5 Dave Taht
@ 2012-12-10 0:00 ` Michael Richardson
2012-12-10 7:39 ` Dave Taht
0 siblings, 1 reply; 4+ messages in thread
From: Michael Richardson @ 2012-12-10 0:00 UTC (permalink / raw)
To: Dave Taht; +Cc: cerowrt-devel
>>>>> "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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Cerowrt-devel] cerowrt 3.6.9-5
2012-12-10 0:00 ` Michael Richardson
@ 2012-12-10 7:39 ` Dave Taht
2012-12-10 14:22 ` Michael Richardson
0 siblings, 1 reply; 4+ messages in thread
From: Dave Taht @ 2012-12-10 7:39 UTC (permalink / raw)
To: Michael Richardson; +Cc: cerowrt-devel
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Cerowrt-devel] cerowrt 3.6.9-5
2012-12-10 7:39 ` Dave Taht
@ 2012-12-10 14:22 ` Michael Richardson
0 siblings, 0 replies; 4+ messages in thread
From: Michael Richardson @ 2012-12-10 14:22 UTC (permalink / raw)
To: Dave Taht; +Cc: cerowrt-devel
[-- 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 --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-12-10 14:22 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-12-09 7:28 [Cerowrt-devel] cerowrt 3.6.9-5 Dave Taht
2012-12-10 0:00 ` Michael Richardson
2012-12-10 7:39 ` Dave Taht
2012-12-10 14:22 ` Michael Richardson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox