netdev - Re: Ingress tc filters with IPSec

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]

Date:	Sat, 30 May 2015 16:12:25 -0400 (EDT)
From:	"jsullivan@...nsourcedevel.com" <jsullivan@...nsourcedevel.com>
To:	netdev@...r.kernel.org
Subject: Re: Ingress tc filters with IPSec


> On May 30, 2015 at 2:24 AM "John A. Sullivan III"
> <jsullivan@...nsourcedevel.com> wrote:
>
>
> On Sat, 2015-05-30 at 01:52 -0400, John A. Sullivan III wrote:
> > Argh! yet another obstacle from my ignorance. We are attempting ingress
> > traffic shaping using IFB interfaces on traffic coming via GRE / IPSec.
> > Filters and hash tables are working fine with plain GRE including
> > stripping the header. We even got the ematch filter working so that the
> > ESP packets are the only packets not redirected to IFB.
> >
> > But, regardless of whether we redirect ESP packets to IFB, the filters
> > never see the decrypted packets. I thought the packets passed through
> > the interface twice - first encrypted and they decrypted. However,
> > tcpdump only shows the ESP packets on the interface.
> >
> > How do we apply filters to the packets after decryption? Thanks - John
>
> I see what changed. In the past, this seemed to work but we were using
> tunnel mode. We were trying to use transport mode in this application
> but that seems to prevent the decrypted packet contents from appearing
> again on the interface. Reverting to tunnel mode made the contents
> visible again and our filters are working as expected - John

Alas, this is still a problem since we are using VRRP and the tunnel end points
are the virtual IP addresses.  That makes StrongSWAN choke on selector matching
in tunnel mode so back to trying to make transport mode work.

I am guessing we do not see the second pass of the packet because it is only
encrypted and not encapsulated.  So my hunch is that we ned to pass the ESP
packet into the ifb qdisc but need to look elsewhere the packet for the filter
matching information.  We know that matching on the normal offsets does not work
so I am hoping the decrypted packet is decipherable by the filter matching logic
but just still has all the ESP transport header attached.

Normally, to extract the contents of my GRE tunnel, I would place them into a
separate hash table with the GRE header stripped off and then filter them into
TCP and UDP hast tables:

tc filter add dev ifb0 parent 11:0 protocol ip prio 2 u32 match ip protocol 47
0xff match u16 0x0800 0xffff at 22 link 11: offset at 0 mask 0f00 shift 6 plus 4
eat

So we match the GRE protocol and determine that GRE is carrying an IP packet.
 With the ESP transport header and IV (AES = 16B) interposed between the IP
header and the GRE header, I suppose the first part of this filter becomes:

tc filter add dev ifb0 parent 11:0 protocol ip prio 2 u32 match ip protocol 47
0xff match u16 0x0800 0xffff at 46

but what do I do with the second half to find the start of the TCP/UDP header?
Is it still offset at 0 because tc filter somehow knows where the interior IP
header starts or should it be offset at 48 to account for the GRE + ESP headers?
Or is there a better way to filter ingress traffic on GRE/IPSec tunnels? 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