diff mbox

xfrm: Accept ESP packets regardless of UDP encapsulation mode

Message ID 1229680846.13159.115.camel@martin
State RFC, archived
Delegated to: David Miller
Headers show

Commit Message

Martin Willi Dec. 19, 2008, 10 a.m. UTC 
> I'm going to revert the change from net-next-2.6 from now

Yes, I'm fine with that.

> 3) Martin can apply the change locally to do testing until we
>    work this stuff out.

I'll do some testing with a modified patch that accepts encapsulated
packets on a non-encapsulating SA, but not vice-versa. This should solve
that specific issue without introducing that (and hopefully no other)
regression.

Comments

Herbert Xu Dec. 19, 2008, 10:19 a.m. UTC | #1 
On Fri, Dec 19, 2008 at 11:00:45AM +0100, Martin Willi wrote:
>
> I'll do some testing with a modified patch that accepts encapsulated
> packets on a non-encapsulating SA, but not vice-versa. This should solve
> that specific issue without introducing that (and hopefully no other)
> regression.

Yes this patch looks safe to me from ESP's point of view.

However, I still don't think this makes sense as ESP will no longer
react to an address change (since it may have no x->encap) should a
routing change cause NAT to occur.

Moreover, the fact that we need this patch in the first place
means that the two sides may be sending different encapsulations
to each other which should raise a big red flag since any stateful
firewall in the middle is going to break this completely.

Thanks,
diff mbox

Patch

diff --git a/net/xfrm/xfrm_input.c b/net/xfrm/xfrm_input.c
index 7527940..ffc32f5 100644
--- a/net/xfrm/xfrm_input.c
+++ b/net/xfrm/xfrm_input.c
@@ -166,7 +166,7 @@  int xfrm_input(struct sk_buff *skb, int nexthdr, __be32 spi, int encap_type)
 			goto drop_unlock;
 		}
 
-		if ((x->encap ? x->encap->encap_type : 0) != encap_type) {
+		if (x->encap && x->encap->encap_type != encap_type) {
 			XFRM_INC_STATS(LINUX_MIB_XFRMINSTATEMISMATCH);
 			goto drop_unlock;
 		}