Message ID | 1229680846.13159.115.camel@martin |
---|---|
State | RFC, archived |
Delegated to: | David Miller |
Headers | show |
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 --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; }