Re: IPsec xfrm resolution

Re: IPsec xfrm resolution

[Patrick McHardy]

Herbert Xu wrote:

>On Thu, Feb 17, 2005 at 08:48:15AM +0100, Patrick McHardy wrote:
>
>>sorry for the delay, I haven't made much progress yet. The old patch was
>>crap, I started over again. So far I've been mostly looking into a better
>>wake-up mechanism for SADB changes than the brute-force approach currently
>>taken with km_waitq. All incomplete bundles are waiting on exactly one
>>SA at a time. Keying daemons need to specify the sequence number for SAs
>>installed in response to an acquire request, finding everything waiting
>>on this SA is easy. But it could also be added manually by the user, in
>>which case the larval state SA continues to exist. I'm not sure if we need
>>to cover this case. A different problem is finding everything waiting on a
>>SA when SAs turn invalid to send back an ICMP error without waiting for a
>>timeout. Adding a wait list to larval state SAs would be ok (if useful),
>>but adding a list to every state would be a big mess. So it seems we can't
>>do much better than km_waitq. SPD changes are fortunately pretty easy,
>>when policies are inserted we do nothing, packets should always use the
>>policy that was active for them at the time of the first lookup. When the
>>policy that was selected is removed we simply drop the packets.
>>I appreciate any comments you might have, I'll try to come up with some code
>>in the next days.
>>
>
>Thanks for the update.  I think there's another aspect of the problem
>that we can tackle first.
>
>To me there are two parts to the puzzle.  We've got packets whose flow
>resolves to an incomplete bundle and we've got sockets whose dst is an
>incomplete bundle.
>
>Whatever solution we come up with needs to resolve both problems.
>
>First of all the sockets shouldn't wait for the larval states to
>materialise.  The reason is that the information they need from
>the bundle (such as the MTU) is either already available or
>can be provided through a best-effort guess such that the socket
>can handle a change later on when the larval state is filled in.
>
>To do this we need to be able to generate xfrm_dst bundles with
>larval states.  This shouldn't be difficult.
>
Yes, this part is simple. There's one thing I think we need to do
slightly different from what you describe. The current behaviour is
to resolve one SA at a time, we should keep it this way because we
may need an early SA in the bundle for a different policy to resolve
a follow-up SA for nested tunnels with different peers where the
second peer is only reachable through a tunnel to the first peer.
I'm not sure if this actually works, but it also saves traffic when
resolving a SA fails. So in addition to larval state SAs we also add
XFRM_STATE_VOID SAs initialized to the parameters contained in the
template to the bundle.

I'm not sure yet how to deal with optional SAs. We shouldn't add
incomplete optional tunnel mode SAs to the bundle because then we
can't determine the output device, but if we don't nothing will
trigger resolving of optional SAs following a non-optional SA that
needs to be resolved.

>If we apply the same strategy to the packets (by giving them bundles
>with larval states in them) then we can defer the waiting from the
>route loop-up stage to the dst output stage.  There the packet can
>be placed on a queue similar to arp_queue.
>
>At this point we can come back and revisit the problem that you've
>pointed out.  I haven't thought about it very much so this might
>sound silly: We could either key the packets by the larval SA so that
>when that larval SA is updated through UPDATESA or GETSPI/UPDATESA
>we process the packets.  Or we could key the packets by its flow so
>that the creation of any SA matching that flow causes them to be
>processed.
>
I thought about adding the queue to the xfrm_dst and adding a dummy
xfrm_state with a selector that matches only the current flow. This
allows us to cache incomplete bundles, more easily find all packets
affected by SADB changes and only resolve the bundle once for the
entire queue. The downside is that we could potentially get a lot of
bundles.

Finding all queues affected by ADDSA/UPDATESA is not easy. A SA
installed in response to an acquire request doesn't need to match
the one requested, so theoretically states waiting on different
larval states SAs might be able to use it. I don't think we have
much choice other than looking at all incomplete bundles (or
one per flow) on SADB changes.

>Feel free to move the discussion to netdev so that others can voice
>their thoughts.
>
Thanks for your input.

Regards
Patrick

Re: IPsec xfrm resolution

[Herbert Xu]

On Fri, Feb 18, 2005 at 12:26:57AM +0100, Patrick McHardy wrote:
>
> Yes, this part is simple. There's one thing I think we need to do
> slightly different from what you describe. The current behaviour is
> to resolve one SA at a time, we should keep it this way because we
> may need an early SA in the bundle for a different policy to resolve
> a follow-up SA for nested tunnels with different peers where the
> second peer is only reachable through a tunnel to the first peer.

Agreed.  This doesn't stop us from creating the bundle object of course.
 
> I'm not sure yet how to deal with optional SAs. We shouldn't add
> incomplete optional tunnel mode SAs to the bundle because then we
> can't determine the output device, but if we don't nothing will
> trigger resolving of optional SAs following a non-optional SA that
> needs to be resolved.

I don't get it.  Can't you just add it into the bundle but ignore it
for dst->output and other calculations until it's either realised or
removed?

> I thought about adding the queue to the xfrm_dst and adding a dummy
> xfrm_state with a selector that matches only the current flow. This

The inner flow is probably not the best key for this.  How about
keying it using the outer remote address on the template? The SAs
have a bydst hash which makes this easy to look up.

So we would attach each packet to a queue shared by all SAs to a
specific (outer) remote address.
 
> Finding all queues affected by ADDSA/UPDATESA is not easy. A SA
> installed in response to an acquire request doesn't need to match
> the one requested, so theoretically states waiting on different
> larval states SAs might be able to use it. I don't think we have
> much choice other than looking at all incomplete bundles (or
> one per flow) on SADB changes.

If you key it on the remote address then you only have to look up
those.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: IPsec xfrm resolution

[Patrick McHardy]

Herbert Xu wrote:

>On Fri, Feb 18, 2005 at 12:26:57AM +0100, Patrick McHardy wrote:
>  
>
>>I'm not sure yet how to deal with optional SAs. We shouldn't add
>>incomplete optional tunnel mode SAs to the bundle because then we
>>can't determine the output device, but if we don't nothing will
>>trigger resolving of optional SAs following a non-optional SA that
>>needs to be resolved.
>>    
>>
>
>I don't get it.  Can't you just add it into the bundle but ignore it
>for dst->output and other calculations until it's either realised or
>removed?
>  
>
An optional tunnel mode SA might change peer/dev/rt_gateway/rt_type if
successfully resolved. This introduces a couple of problems:

- MTU estimatation impossible
- netfilter LOCAL_OUT hook sees incorrect output device
- strict source routing check done with incorrect rt_gateway

Simply ignoring these SAs if they are not available when the bundle is
created looks like the easiest solution to me.

>>I thought about adding the queue to the xfrm_dst and adding a dummy
>>xfrm_state with a selector that matches only the current flow. This
>>    
>>
>
>The inner flow is probably not the best key for this.  How about
>keying it using the outer remote address on the template? The SAs
>have a bydst hash which makes this easy to look up.
>
>So we would attach each packet to a queue shared by all SAs to a
>specific (outer) remote address.
>  
>
That sounds reasonable. The selector initialized to the inner flow is
meant for cacheing the incomplete bundle at the policy. We can have
multiple SAs with equal family/reqid/saddr/daddr/mode/proto differing
only be SPI and selector. If we use a selector selecting more than the
inner flow we could create a conflict with an already existing cached
bundle.

Regards
Patrick

Re: IPsec xfrm resolution

[Herbert Xu]

On Sat, Feb 19, 2005 at 07:03:32AM +0100, Patrick McHardy wrote:
>
> An optional tunnel mode SA might change peer/dev/rt_gateway/rt_type if
> successfully resolved. This introduces a couple of problems:
> 
> - MTU estimatation impossible

This is OK for two reasons:

1) The application must be able to react to MTU changes anyway.
2) The most common use for optional SAs is IPCOMP which has zero overhead.

Actually, 2) gives us the real reason why we must include optional SAs.
Even though we can skip the compression of a tunnel mode IPCOMP SA, we
must perform the IPIP encapsulation.

> - netfilter LOCAL_OUT hook sees incorrect output device
> - strict source routing check done with incorrect rt_gateway

Once you take the above into account these turn out to be non-issues.
If the optional SA is transport mode, then the route is identical with
or without it.  If it's tunnel mode, then we must perform the IPIP
encapsulation regardless.

> That sounds reasonable. The selector initialized to the inner flow is
> meant for cacheing the incomplete bundle at the policy. We can have
> multiple SAs with equal family/reqid/saddr/daddr/mode/proto differing
> only be SPI and selector. If we use a selector selecting more than the
> inner flow we could create a conflict with an already existing cached
> bundle.

Agreed.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: IPsec xfrm resolution

[Patrick McHardy]

Herbert Xu wrote:

>On Sat, Feb 19, 2005 at 07:03:32AM +0100, Patrick McHardy wrote:
>  
>
>>- netfilter LOCAL_OUT hook sees incorrect output device
>>- strict source routing check done with incorrect rt_gateway
>>    
>>
>
>Once you take the above into account these turn out to be non-issues.
>If the optional SA is transport mode, then the route is identical with
>or without it.  If it's tunnel mode, then we must perform the IPIP
>encapsulation regardless.
>
This is not what happens currently. If an optional IPCOMP SA is missing
it is skipped entirely. It is also legal to configure an optional
ah/esp tunnel, although we don't accept such packets if the SA isn't
present.

Regards
Patrick

Re: IPsec xfrm resolution

[Herbert Xu]

On Sat, Feb 19, 2005 at 01:29:25PM +0100, Patrick McHardy wrote:
>
> This is not what happens currently. If an optional IPCOMP SA is missing
> it is skipped entirely. It is also legal to configure an optional
> ah/esp tunnel, although we don't accept such packets if the SA isn't
> present.

That's a bug.  How can you forward packets properly if the tunnel mode
SA is missing?

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: IPsec xfrm resolution

[Patrick McHardy]

Herbert Xu wrote:

>On Sat, Feb 19, 2005 at 01:29:25PM +0100, Patrick McHardy wrote:
>  
>
>>This is not what happens currently. If an optional IPCOMP SA is missing
>>it is skipped entirely. It is also legal to configure an optional
>>ah/esp tunnel, although we don't accept such packets if the SA isn't
>>present.
>>    
>>
>
>That's a bug.  How can you forward packets properly if the tunnel mode
>SA is missing?
>
Using normal routing. What meaning would "optional" have otherwise ?
If the encapsulation has to be done, the user shouldn't mark the SA
as optional in my opinion.

Regards
Patrick

Re: IPsec xfrm resolution

[Herbert Xu]

On Sat, Feb 19, 2005 at 07:47:11PM +0100, Patrick McHardy wrote:
>
> >That's a bug.  How can you forward packets properly if the tunnel mode
> >SA is missing?
>
> Using normal routing. What meaning would "optional" have otherwise ?
> If the encapsulation has to be done, the user shouldn't mark the SA
> as optional in my opinion.

In that case you can't mark IPCOMP SAs as optional in this scenario
which is the most common application of optional:

IPCOMP(tunnel) -- ESP(transport)
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: IPsec xfrm resolution

[Patrick McHardy]

Herbert Xu wrote:

>On Sat, Feb 19, 2005 at 07:47:11PM +0100, Patrick McHardy wrote:
>  
>
>>>That's a bug.  How can you forward packets properly if the tunnel mode
>>>SA is missing?
>>>      
>>>
>>Using normal routing. What meaning would "optional" have otherwise ?
>>If the encapsulation has to be done, the user shouldn't mark the SA
>>as optional in my opinion.
>>    
>>
>
>In that case you can't mark IPCOMP SAs as optional in this scenario
>which is the most common application of optional:
>
>IPCOMP(tunnel) -- ESP(transport)
>  
>
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 we
need to special-case tunnel mode IPCOMP in xfrm_tmpl_resolve() and either
ignore "optional" for IPIP tunnel mode SAs or create them on demand.

Regards
Patrick

Re: IPsec xfrm resolution

[Patrick McHardy]

[-- Attachment #1: Type: text/plain, Size: 859 bytes --]

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 we
> need 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


[-- Attachment #2: x1 --]
[-- Type: text/plain, Size: 314 bytes --]

===== 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;

Re: IPsec xfrm resolution

[Herbert Xu]

On Sat, Feb 19, 2005 at 09:26:02PM +0100, Patrick McHardy wrote:
> 
> How about this patch ? It ignores "optional" for missing tunnel mode 
> SAs, symetric
> to input.

Actually, I've been convinced by your earlier argument :)

I now think that IPCOMP users like racoon/openswan should simply
not set the optional flag on the sending policy.  It only needs
to be set on the receiving side.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: IPsec xfrm resolution

[David S. Miller]

On Sat, 19 Feb 2005 20:23:14 +1100
Herbert Xu <herbert@gondor.apana.org.au> wrote:

> 1) The application must be able to react to MTU changes anyway.

This would seem to be the case, but keep in mind that if
we're going through all this trouble to improve this
quality of implementation issue, we should really get this
right.

On a more practical side, let's use an example to drive home
a point.  Say you're using DNS-sec or something like that for
all outgoing connections, and you're using non-blocking sockets
for all of your stuff.

Every time I use TCP to talk to a unique host, we're going to
mis-estimate the MTU, get an entire send queue full of too-large
packets, then have to resegment the entire thing once the SA is
resolved.  We'll eat a retransmit every such connection as well.
And actually, we'll have to resend about 4 frames (depends upon
what the initial send cwnd is set to, it's usually 4 for ethernet
size MTUs).

Anyways, in truth I'm being very picky :-)  Is there any prototype
or beginnings of these ideas anywhere?

Re: IPsec xfrm resolution

[Herbert Xu]

On Thu, Mar 17, 2005 at 08:32:31PM -0800, David S. Miller wrote:
> On Sat, 19 Feb 2005 20:23:14 +1100
> Herbert Xu <herbert@gondor.apana.org.au> wrote:
> 
> > 1) The application must be able to react to MTU changes anyway.
> 
> This would seem to be the case, but keep in mind that if
> we're going through all this trouble to improve this
> quality of implementation issue, we should really get this
> right.

Don't worry, further down in that thread we agreed that optional
SAs will simply not be added so the MTU estimate will be correct
unless it's changed by PMTU later on.
 
> Anyways, in truth I'm being very picky :-)  Is there any prototype
> or beginnings of these ideas anywhere?

Not yet.  However, once the MTU stuff is out of the way I would like
to work on this.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: IPsec xfrm resolution

[Patrick McHardy]

David S. Miller wrote:

> Anyways, in truth I'm being very picky :-)  Is there any prototype
> or beginnings of these ideas anywhere?

Not yet, I've put it on hold after clashing with Herbert's MTU work.
I'll have a few free days this week where I will continue to work
on this.

Regards
Patrick

Re: IPsec xfrm resolution

[Herbert Xu]

On Sun, Mar 20, 2005 at 04:51:23PM +0100, Patrick McHardy wrote:
>
> Not yet, I've put it on hold after clashing with Herbert's MTU work.
> I'll have a few free days this week where I will continue to work
> on this.

I've completed the first stage of the MTU work so please feel free to
send patches through.

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: IPsec xfrm resolution

[Patrick McHardy]

Herbert Xu wrote:
> On Sun, Mar 20, 2005 at 04:51:23PM +0100, Patrick McHardy wrote:
> 
>>Not yet, I've put it on hold after clashing with Herbert's MTU work.
>>I'll have a few free days this week where I will continue to work
>>on this.
> 
> I've completed the first stage of the MTU work so please feel free to
> send patches through.

I'll send something this weekend.

Regards
Patrick