netdev - RE: port bound SAs

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: <BB7E16A14DE689469A181EC770AFBF4D02A77515@exch-one.centrify.com>
Date:	Tue, 27 Jan 2009 08:46:02 -0800
From:	"Paul Moore" <paul.moore@...trify.com>
To:	"Patrick McHardy" <kaber@...sh.net>,
	"David Miller" <davem@...emloft.net>
Cc:	<netdev@...r.kernel.org>
Subject: RE: port bound SAs

racoon

if I look at the xfrm/pfkey code in the kernel it ignores any ports sent
down by the IKE daemon in transport mode. I actually changed the racoon
code to include the ports and it makes no difference

-----Original Message-----
From: Patrick McHardy [mailto:kaber@...sh.net] 
Sent: Tuesday, January 27, 2009 2:27 AM
To: David Miller
Cc: Paul Moore; netdev@...r.kernel.org
Subject: Re: port bound SAs

David Miller wrote:
> From: "Paul Moore" <paul.moore@...trify.com>
> Date: Mon, 26 Jan 2009 11:21:33 -0800
> 
>> 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
> 
> Why does the Linux system do this?  The route lookup should, as it's
> final IPSEC route lookup action, do an xfrm policy lookup which should
> do a selector match and thus not match the port 23 rule.
> 
> I can't find the code which would allow the sequence of events
> you describe, can you?

I'm guessing that its just the policy that has the port selector set
and the keying daemon does not set it for the installed SAs. So unless
the policies specify seperate SPIs or reqids the SAs will be shared.

Paul, which keying daemon are you using?
--
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