| 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: Wed, 23 May 2018 22:31:53 +0300
From: Jonathan Morton <chromatix99@...il.com>
To: David Miller <davem@...emloft.net>
Cc: toke@...e.dk, cake@...ts.bufferbloat.net, netdev@...r.kernel.org,
netfilter-devel@...r.kernel.org
Subject: Re: [Cake] [PATCH net-next v15 4/7] sch_cake: Add NAT awareness to
packet classifier
> On 23 May, 2018, at 9:44 pm, David Miller <davem@...emloft.net> wrote:
>
> I'd much rather you do something NAT method agnostic, like save
> or compute the necessary information on ingress and then later
> use it on egress.
We were under the impression that conntrack was the cleanest and most correct way to convey this information between qdiscs. Frankly it's difficult to see how else we could do it without major complications.
Remember that it takes two different qdiscs to implement ingress and egress on the same physical interface, and there's no obvious logical link between them - especially since the ingress one has to be attached to an ifb, not to the actual interface, because there's no native support for ingress qdiscs.
What's more, there's no information (besides conntrack) at ingress about the "inside" address of NATted traffic. There might be some residual information for egress traffic, but communicating that to the ingress side feels very much like we need to reimplement something very like conntrack.
If not supporting "alternative" NAT mechanisms that don't register their data in conntrack is the penalty, it's one I personally can live with.
- Jonathan Morton
Powered by blists - more mailing lists