No suggested text because it requires a much more serious analysis. May be adding that the rate-limit counter SHOULD be per-connection, in the spirit of RFC 6528?
It appears the section does not specify that the counter for ACK throttling SHOULD be per-connection. In Linux, it is apparently global, which allowed its use as a side channel enabling nasty attacks (CVE-2016-5696 and the paper "Off-Path TCP Exploits: Global Rate Limit Considered Dangerous" )
注記:
当該セクションはACK throttlingのためのカウンタは接続ごとにされるべき (SHOULD) であることを規定していないようである。Linuxでは、どうやらグローバルになっていて、悪意のある攻撃を可能にするサイドチャネル攻撃を許してしまう。 (CVE-2016-5696と論文"Off-Path TCP Exploits: Global Rate Limit Considered Dangerous" より)
リンク先など (スコア:5, 参考になる)
とりあえず CVE-2016-5696 [mitre.org] についての幾つかのディストリビューションへのリンク
Debian [debian.org] ほとんど全部?
Ubuntu [canonical.com] デフォルトのパッケージだとほぼ全部?
RHEL/CentOS [redhat.com] 6/7, MRG 2
SUSE [suse.com] 12, 11 SP3 and SP4
Register のリンク先ではワークアラウンドとして tcp_challenge_ack_limit に大きい値を設定するというのが紹介されています。999999999 の箇所は Akamai blog [akamai.com] では 1073741823になっています。大きければ良さそう。(デフォルトは 100?)
Re:リンク先など (スコア:4, 参考になる)
RFCの方を見るとErrata Existsとあるので検索したら出てきました。
https://www.rfc-editor.org/errata_search.php?rfc=5961 [rfc-editor.org]
RFC 5961での記述漏れが脆弱な実装を許してしまったようですね。こんなの実装すればすぐ気づけるように思えますが、人間は間違えるものですしね。
Re: (スコア:0)
DNS関係見てたときに思ったことだけど、どっちの方向にブレるかは、文化というか各OSでのRFCに対する考え方次第に感じるなあ。
なので私はBINDは自宅で使わない。