netdev - Re: when having to acquire an SA, ipsec drops the packet

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 1 Feb 2007 18:44:48 -0500 (EST)
From:	James Morris <jmorris@...ei.org>
To:	Joy Latten <latten@...tin.ibm.com>
cc:	netdev@...r.kernel.org, paul.moore@...com,
	vyekkirala@...stedCS.com, herbert@...dor.apana.org.au,
	davem@...emloft.net
Subject: Re: when having to acquire an SA, ipsec drops the packet

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?

It may not be the end of the world if an MLS box has to negotiate a 
whole bunch of SAs when it boots up.

- James
-- 
James Morris
<jmorris@...ei.org>
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html