netdev - Traffic shaping with netkey

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>] [day] [month] [year] [list]

Date:	Wed, 15 Feb 2012 05:40:14 -0500
From:	"John A. Sullivan III" <jsullivan@...nsourcedevel.com>
To:	netdev@...r.kernel.org
Subject: Traffic shaping with netkey

Hello, all.  I'm finally making some progress on our 95 percentile
traffic shaping project.  The last major area of exploration has been
handling all kinds of VPN traffic - netkey, KLIPS, OpenVPN.  netkey has
proven the most challenging with its double pass through the same
interface.  After several days playing in the lab, I'd like to share my
observations to see if they are as they should be or if I mangled my
testing!

The challenge has been classifying the netkey traffic.  Ingress has
proven easier than egress surprisingly.  I redirected all ingress to an
ifb interface.  I needed to create a separate, relatively unlimited HFSC
service curve for the ESP traffic, but then was able to use a tc filter
to properly classify the decrypted packets.  I find I can also use
CONNMARK to classify the decrypted packets on ingress.

Egress has been a challenge.  Perhaps it is extra complicated because I
needed to redirect all egress traffic to an ifb interface, too, so that
traffic coming off the tun and ipsec interfaces would land in the same
queues as the netkey traffic.  The only was I could do this for egress
was to use the iptables CLASSIFY target. That seemed to properly
classify the netkey traffic before it was encrypted.  tc filters did not
seem to catch the packet before it was encrypted; perhaps this is
because the filters are operating on the ifb interface and the packet
has been encrypted/encapsulated before handing it off to ifb.

Most surprisingly, I found I could not use CONNMARK for egress netkey
traffic.  I could see that SYN packet triggered the rule to mark the
connection and I see tons of packets hitting the restore mark rule but
all the traffic is going to the default HFSC queue rather than being
properly classified.

Is this to be expected, viz., that CLASSIFY works on ifb redirected
netkey egress traffic but tc filters and CONNMARK do not? Thanks - John

--
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