On Thu, 2007-02-01 at 18:44 -0500, James Morris wrote:
> On Thu, 1 Feb 2007, Joy Latten wrote:
>
> > IPsec returns EAGAIN when it needs to acquire an SA.
> > There have been a thread or two about this...
> > Has there been any info or progress in how best to fix this?
> >
> > James Morris presented some work/ideas,
> > http://vger.kernel.org/jmorris_ipsec_sa_resolution_netconf2006.pdf
>
> The status of this is that I started refactoring some core IPv6 code (to
> bring it in line with the IPv4 code, e.g. create an ip6_route_connect() to
> match ip_route_connect(), and manage the packet queuing from there) and
> ran into some IPv6 bugs, and fixed those, but then ran out of time on the
> IPsec stuff. AFAIK, no other progress has been made.
>
> Generally, the problem is only seen when using the BSD userland, which
> does not proactively maintain SAs. Openswan does, and general IPsec users
> running it never see the problem, so it's not clear how high the priority
> is for fixing this really is in the general case. It's quite a lot of
> surgery on core networking to fix a problem which doesn't occur with the
> Linux tools, which seemingly most people use when they're not using
> proprietary and/or userland IPsec stacks.
>
> Non-kernel options include moving to Openswan (which I would hope is
> getting labeled networking support at some stage in any case), or have the
> BSD code proactively maintain SAs.
>
> Also, applications using TCP, and UDP applications with their own session
> management, will resend packets while the SA is being negotiated, which
> I've observed as typically completing before the first resend. I think
> one of the practical problems with this is that the apps are not expecting
> an EAGAIN and thus decide to crash.
>
> A quick & dirty solution, which is what I think the BSD kernels do, is to
> still drop the packet but just not return an error to the app. The app
> then just sees a slight delay on the initial connection, as if a DNS
> lookup took a bit longer than usual.
>
> > When using labeled xfrms (xfrms that contain a security context), there
> > is potential for a greater amount of SAs to be created than when using
> > regular xfrms. An SA may be created every time a different security
> > context is encountered in a particular traffic stream. This could be
> > many if each networking app has its own security context, making current
> > behavior problematic.
>
> Do you have any examples of how many SAs would need to be created on a
> typical system?
>
No, but I have to admit, just playing around with it gives me a scary
idea. We have s0-s15 levels, each with c0-c1023 categories. Then I have
noticed, each mapped selinux user is a different context... thus just an
ssh session by a sysadm and a regular user (who is mapped to an selinux
user) can cause 8 SAs to be generated, whereas with regular ipsec, we
only need one... :-(
Regards,
Joy
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
