netdev - Re: [PATCH net-next v15 4/7] sch_cake: Add NAT awareness to packet classifier

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87bmd6xeur.fsf@toke.dk>
Date:   Wed, 23 May 2018 23:05:16 +0200
From:   Toke Høiland-Jørgensen <toke@...e.dk>
To:     David Miller <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, cake@...ts.bufferbloat.net,
        netfilter-devel@...r.kernel.org
Subject: Re: [PATCH net-next v15 4/7] sch_cake: Add NAT awareness to packet classifier

David Miller <davem@...emloft.net> writes:

> From: Toke Høiland-Jørgensen <toke@...e.dk>
> Date: Wed, 23 May 2018 22:38:30 +0200
>
>> How would this work?
>
> On egress the core networking flow dissector records what you need
> somewhere in SKB or wherever.  You later retrieve it at egress time
> after NAT has occurred.

Ah, right, that could work. Is there any particular field in sk_buff
we should stomp on for this purpose, or would you prefer a new one?
Looking through it, the only obvious one that comes to mind is, well,
skb->_nfct :)

If we wanted to avoid bloating sk_buff, we could add a union with that,
fill it in the flow dissector, and just let conntrack overwrite it if
active; then detect which is which in Cake, and read the data we need
from _nfct if conntrack is active, and from what the flow dissector
stored otherwise.

Is that too many hoops to jump through to avoid adding an extra field?

-Toke