netdev - xfrm transport mode policy and forward packets

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

Date:	Thu, 22 Oct 2009 15:07:28 +0300
From:	Timo Teräs <timo.teras@....fi>
To:	netdev@...r.kernel.org, Herbert Xu <herbert@...dor.apana.org.au>
Subject: xfrm transport mode policy and forward packets

Hi,

I'm using on my dmvpn environment security policies like:

src 0.0.0.0/0 dst 0.0.0.0/0 proto gre 
	dir in priority 2147483648 ptype main 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport

src 0.0.0.0/0 dst 0.0.0.0/0 proto gre 
	dir out priority 2147483648 ptype main 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 0 mode transport

To make sure the locally generated/received GRE traffic is IPsec protected.
Now when some other non-local gre traffic is being forwarded by this router,
that seems to match these SPs too. Basically no one behind this router box
can use GRE (or PPTP).

I originally had the 'fwd' policy too, but removing it did not help as-is.
I needed to add destination specific 'out' policies with higher priority.

Apparently, the forward path does two xfrm lookups: first one with from 'fwd'
policies to check if the received packet is not against policy, and a second
'out' lookup to see if it needs to get transformed.

My initial thought was if transport mode policies ought to be ignored, but
if the forwarded packet is NATted we might actually want to xfrm it in
transport mode.

There is 'ifindex' field in xfrm_selector, but that seems to be the output
interface. So it would not solve my problem: both local and forwarded gre
packets are output on the same interface.

I'm now slightly curious why 'in' was sort of split to 'in' and 'fwd', but
'out' was not split similarly, so we'd have more control over policies
depending if the traffic is local or forwarded?

My ideas so far have been:
a) rename 'fwd' to 'infwd' and split 'out' to 'out' and 'outfwd' ?
   (sounds kinda intrusive)
b) iptables target that would be able to disable xfrm

Any other ideas?
What would be the proper fix for this problem?

Thanks,
  Timo
--
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