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]

Message-Id: <1170708727.2603.366.camel@faith.austin.ibm.com>
Date:	Mon, 05 Feb 2007 14:52:06 -0600
From:	Joy Latten <latten@...tin.ibm.com>
To:	James Morris <jmorris@...ei.org>
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, 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html