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-next>] [day] [month] [year] [list]
Date:	Mon, 26 Jan 2009 11:21:33 -0800
From:	"Paul Moore" <paul.moore@...trify.com>
To:	<netdev@...r.kernel.org>
Subject: port bound SAs

A few weeks ago I posted a question to the IETF IPsec group on this
topic 

I have 2 SPDs declared saying (transport mode)
10.0.0.0/24 port 23 esp
10.0.0.0/24 port 80 esp

I then initiate a connection from that Linux machine to another system
that has the same logical rules
port 23 fires up and I get an SA pair. The question is - does that SA
pair belong to port 23 or not
If I now connect using port 80 from the same Linux box to the same peer
it tries to use the SA already set up for port 23
The remote system (windows in my test case) drops the packets because it
believes that the SA is for port 23 traffic only

The small amount of feedback I got was that the SA should belong to port
23 and that Linux seems to be doing the wrong thing

I can change the problem a bit by adding require to the SPD entry. There
are several things wrong with that though

a) it should not be necessary
b) I get a lot of SAs
c) I can no longer say that the SPD is optional (that's a separate
topic, the overloading of 2 orthogonal concepts onto a single value)
d) I am still worried that it does not work correctly in all cases

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ