lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 25 Sep 2012 07:17:07 +0200 From: Eric Dumazet <eric.dumazet@...il.com> To: Stephen Hemminger <shemminger@...tta.com> Cc: Chris Wright <chrisw@...hat.com>, David Miller <davem@...emloft.net>, netdev@...r.kernel.org Subject: Re: [RFC] gre: conform to RFC6040 ECN progogation On Mon, 2012-09-24 at 15:30 -0700, Stephen Hemminger wrote: > Logging is a bad idea in this case since the tunnel might be from a remote > host/protocol and the log would be filled with crap. > > The tunnels in general do need to have rx_dropped counter, but it looks > like that isn't being done right either. > I never suggested to log _all_ messages. Stephen, I personally was hit by some provider playing with TOS bits so wrong I had to patch linux to fix a minor problem. [1] I would like to know why my tunnels are going to fail, and what should I do to get a fallback. Ie reverting your patches. RFC 6040 states : In these cases, particularly the more dangerous ones, the decapsulator SHOULD log the event and MAY also raise an alarm. Just because the highlighted combinations are currently unused, does not mean that all the other combinations are always valid. Some are only valid if they have arrived from a particular type of legacy ingress, and dangerous otherwise. Therefore, an implementation MAY allow an operator to configure logging and alarms for such additional header combinations known to be dangerous or CU for the particular configuration of tunnel endpoints deployed at run-time. Alarms SHOULD be rate-limited so that the anomalous combinations will not amplify into a flood of alarm messages. It MUST be possible to suppress alarms or logging, e.g., if it becomes apparent that a combination that previously was not used has started to be used for legitimate purposes such as a new standards action. [1] commit 7a269ffad72f3604b8982fa09c387670e0d2ee14 Author: Eric Dumazet <eric.dumazet@...il.com> Date: Thu Sep 22 20:02:19 2011 +0000 tcp: ECN blackhole should not force quickack mode While playing with a new ADSL box at home, I discovered that ECN blackhole can trigger suboptimal quickack mode on linux : We send one ACK for each incoming data frame, without any delay and eventual piggyback. This is because TCP_ECN_check_ce() considers that if no ECT is seen on a segment, this is because this segment was a retransmit. Refine this heuristic and apply it only if we seen ECT in a previous segment, to detect ECN blackhole at IP level. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists