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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 2 Feb 2007 10:30:28 -0500
From:	Paul Moore <paul.moore@...com>
To:	James Morris <jmorris@...ei.org>,
	Joy Latten <latten@...tin.ibm.com>
Cc:	netdev@...r.kernel.org, vyekkirala@...stedcs.com,
	herbert@...dor.apana.org.au, davem@...emloft.net
Subject: Re: when having to acquire an SA, ipsec drops the packet

On Thursday, February 1 2007 6:44 pm, James Morris wrote:
> On Thu, 1 Feb 2007, Joy Latten wrote:
> > 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.

I agree that having an MLS box spend some extra time when starting the IKE 
daemon is probably not the end of the world.  However, I'm a little concerned 
that it may not be possible to determine a "good" set of SAs to negotiate 
with only the SPD as a reference.

For example, the current SELinux MLS policy has 16 sensitivity levels and 1024 
categories.  Ignoring the TE portion of the SELinux context for the sake of 
clarity you can easily see the large number of unique combinations, with each 
combination requiring a new SA.  Granted, in the majority of these cases only 
a quick mode IKE negotiation would be required, which is much less expensive 
then having to do a full phase-1 negotiation, but due to the large numbers of 
SAs involved I believe it would still be quite a task.  It also should be 
said that this procedure would need to be done for each SPD rule.

I haven't thought about this too much yet, but I suspect proactively creating 
SAs is not going to be a practical solution.

-- 
paul moore
linux security @ hp
-
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