| To: | Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: IPsec xfrm resolution |
| From: | Patrick McHardy <kaber@xxxxxxxxx> |
| Date: | Sat, 19 Feb 2005 21:26:02 +0100 |
| Cc: | Maillist netdev <netdev@xxxxxxxxxxx> |
| In-reply-to: | <4217993D.4070107@xxxxxxxxx> |
| References: | <20050210202810.GA1609@xxxxxxxxxxxxxxxxxxx> <42144C3F.2060501@xxxxxxxxx> <20050217091137.GA9476@xxxxxxxxxxxxxxxxxxx> <42152841.5000707@xxxxxxxxx> <20050218100854.GA19427@xxxxxxxxxxxxxxxxxxx> <4216D6B4.5070901@xxxxxxxxx> <20050219092314.GA8153@xxxxxxxxxxxxxxxxxxx> <42173125.3040505@xxxxxxxxx> <20050219183202.GA10773@xxxxxxxxxxxxxxxxxxx> <421789AF.4020705@xxxxxxxxx> <20050219190333.GA22166@xxxxxxxxxxxxxxxxxxx> <4217993D.4070107@xxxxxxxxx> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
| User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.5) Gecko/20050106 Debian/1.7.5-1 |
Patrick McHardy wrote: I've checked KAME, it also skips IPSEC_LEVEL_USE SAs if they aren't present. IPCOMP in tunnel mode is a special case. It wants to express more than just "optional". It means to say "use SA if present and some things wrt. size apply, otherwise use a similar SA with proto=IPIP". One of both has to be used, and this is what "optional" can't express. The current method is to use the IPIP SA automatically created with the IPCOMP SA when the compressed size exceeds the uncompressed size, but it doesn't handle a missing SA. This suggests weneed to special-case tunnel mode IPCOMP in xfrm_tmpl_resolve() and either ignore "optional" for IPIP tunnel mode SAs or create them on demand. How about this patch ? It ignores "optional" for missing tunnel mode SAs, symetric to input. Regards Patrick ===== net/xfrm/xfrm_policy.c 1.66 vs edited =====
--- 1.66/net/xfrm/xfrm_policy.c 2005-02-16 00:16:04 +01:00
+++ edited/net/xfrm/xfrm_policy.c 2005-02-19 21:12:38 +01:00
@@ -656,7 +656,7 @@
xfrm_state_put(x);
}
- if (!tmpl->optional)
+ if (!tmpl->optional || tmpl->mode)
goto fail;
}
return nx;
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: IPsec xfrm resolution, Patrick McHardy |
|---|---|
| Next by Date: | Re: Intel and TOE in the news, Andi Kleen |
| Previous by Thread: | Re: IPsec xfrm resolution, Patrick McHardy |
| Next by Thread: | Re: IPsec xfrm resolution, Herbert Xu |
| Indexes: | [Date] [Thread] [Top] [All Lists] |