login
Search
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 --
From: "Paul Moore" <paul.moore@centrify.com> 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? --
i did exactly that (in the original message) and it makes this test case work but as I point out a) it should not be necessary b) i get more SAs than I need c) i can no longer say that a SA is optional (this is an error in the pfkey/xfrm/racoon interface to combine two orthogonal concepts) d) I am not convinced that I have resolved all cases. Needs more testing -----Original Message----- From: Patrick McHardy [mailto:kaber@trash.net] Sent: Tuesday, January 27, 2009 9:01 AM To: Paul Moore Cc: David Miller; netdev@vger.kernel.org Subject: Re: port bound SAs Assuming you're also using setkey, try adding "unique" to your policies. --
IIRC I tested port selectors in SA a few years ago using "ip xfrm" and they worked fine. The xfrm interface doesn't ignore them (copy_from_user_state()), I think the pfkey interface also doesn't. Please try configuring them manually using "ip xfrm state", I'm pretty sure the bug is actually in racoon. --
the pfkey / xfrm interface throws them away i fixed racoon to send the port numbers and they were ignored -----Original Message----- From: Patrick McHardy [mailto:kaber@trash.net] Sent: Tuesday, January 27, 2009 9:12 AM To: Paul Moore Cc: David Miller; netdev@vger.kernel.org Subject: Re: port bound SAs testing IIRC I tested port selectors in SA a few years ago using "ip xfrm" and they worked fine. The xfrm interface doesn't ignore them (copy_from_user_state()), I think the pfkey interface also doesn't. Please try configuring them manually using "ip xfrm state", I'm pretty sure the bug is actually in racoon. --
From: "Paul Moore" <paul.moore@centrify.com> Did you actually try "ip xfrm" as Patrick suggested? Where exactly are the ports "thrown away" for both pfkey and xfrm cases? --
I dont know what ip xfrm means - excuse my ignorance please I will try it -----Original Message----- From: David Miller [mailto:davem@davemloft.net] Sent: Tuesday, January 27, 2009 9:21 AM To: Paul Moore Cc: kaber@trash.net; netdev@vger.kernel.org Subject: Re: port bound SAs From: "Paul Moore" <paul.moore@centrify.com> Did you actually try "ip xfrm" as Patrick suggested? Where exactly are the ports "thrown away" for both pfkey and xfrm cases? --
I misparsed that statement, I thought you meant both. Yes, you I believe thats intentional, RFC2367 specifies to ignore port numbers except for larval states. --
>>I believe thats intentional, RFC2367 specifies to ignore port numbers except for larval states. the ietf ipsec list thinks thats not the case. The consensus there is that the port owns the SA (and thats what Windows, and solaris actually do) -----Original Message----- From: Patrick McHardy [mailto:kaber@trash.net] Sent: Tuesday, January 27, 2009 9:22 AM To: Paul Moore Cc: David Miller; netdev@vger.kernel.org Subject: Re: port bound SAs I misparsed that statement, I thought you meant both. Yes, you I believe thats intentional, RFC2367 specifies to ignore port numbers except for larval states. --
What does "think thats not the case" mean? Its clearly stated in
2.3.3. Address Extension:
...
The
zeroing of ports (e.g. sin_port and sin6_port) MUST be done for all
messages except for originating SADB_ACQUIRE messages, which SHOULD
fill them in with ports from the relevant TCP or UDP session which
generates the ACQUIRE message.
--
OK I misunderstood. Sorry You are saying that the port number should be dropped by the pfkey / xfrm interface - OK This is actually what happens. (BTW this is fortunate - in a few cases racoon accidentally passes down 500) I meant that the consensus was that the wire behavior is wrong. -----Original Message----- From: Patrick McHardy [mailto:kaber@trash.net] Sent: Tuesday, January 27, 2009 9:29 AM To: Paul Moore Cc: David Miller; netdev@vger.kernel.org Subject: Re: port bound SAs What does "think thats not the case" mean? Its clearly stated in 2.3.3. Address Extension: ... The zeroing of ports (e.g. sin_port and sin6_port) MUST be done for all messages except for originating SADB_ACQUIRE messages, which SHOULD fill them in with ports from the relevant TCP or UDP session which generates the ACQUIRE message. --
So where did we get to on this? My main question is - do you agree this is incorrect behavior of the overall system (racoon, pfkey, xfrm, ip) without trying to say which bit is to blame? I have done more investigation of code and looked at what other platforms do but that is redundant unless there is agreement that there is a problem --
No, so far everything seems fine. The SAs don't have a port selector, no reqid is specified => Linux is allowed to reuse them. --
So how do I get an SA with a port set on it -----Original Message----- From: Patrick McHardy [mailto:kaber@trash.net] Sent: Wednesday, January 28, 2009 10:03 AM To: Paul Moore Cc: David Miller; netdev@vger.kernel.org Subject: Re: port bound SAs No, so far everything seems fine. The SAs don't have a port selector, no reqid is specified => Linux is allowed to reuse them. --
aha - so with racoon (which uses pfkey) I cannot make this work This kind of seems broken - doesnt it? racoon is a very common IKE daemon So what IKE daemon should I be using on linux? FYI On solaris they do 2367 it differently (I know this because I am in the middle of porting racoon to solaris) the ACQUIRE message to user land has port selectors in it (linux does not, and racoon accidentaly barfs if they are there) the ADD and UPDATE messages from user land contain selectors and the kernel expects them (racoon leaves them set randomly, fortunately Linux pfkey throws them away) This is why solaris does the right thing in terms of wire behavior. Its selector code know about ports (using its own IKE daemon) The simple solution is to stop the pfkey interface throwing the port numbers away and then I can change racoon to send them (which I had to do for solaris port) -----Original Message----- From: Patrick McHardy [mailto:kaber@trash.net] Sent: Wednesday, January 28, 2009 10:12 AM To: Paul Moore Cc: David Miller; netdev@vger.kernel.org Subject: Re: port bound SAs You don't, using pfkey. Use reqid or ip xfrm. --
Either fix racoon to use xfrm or go with a properly maintained key manager like one of the *swans. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --
Do you know which version of *swan generates xfrm selectors when it does an SA ADD or UPDATE. I downloaded openswan 2.6.19 and it does not -----Original Message----- From: Herbert Xu [mailto:herbert@gondor.apana.org.au] Sent: Thursday, January 29, 2009 10:31 PM To: Paul Moore Cc: kaber@trash.net; davem@davemloft.net; netdev@vger.kernel.org Subject: Re: port bound SAs Either fix racoon to use xfrm or go with a properly maintained key manager like one of the *swans. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --
The selector logic doesn't work very well with nested tunnels which is why I didn't use it for the original Openswan port. We rely on the policy selector instead to do the job. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --
are you sure that works. the xfrm code in the kernel does not look at the policy selector when checking port numbers to see if it should reuse an existing SA. It only looks at the selector on the SA - this is why racoon has a problem. The policy selector has the correct portness in it but the SA does not. I have not tested it but I suspect openswan has the same issue since it passes in an empty SA selector -----Original Message----- From: Herbert Xu [mailto:herbert@gondor.apana.org.au] Sent: Monday, February 23, 2009 6:09 PM To: Paul Moore Cc: kaber@trash.net; davem@davemloft.net; netdev@vger.kernel.org Subject: Re: xfrm selector generating IKE The selector logic doesn't work very well with nested tunnels which is why I didn't use it for the original Openswan port. We rely on the policy selector instead to do the job. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --
Yes I'm sure it works :) It uses the reqid field to tie policies to the SAs. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --
You seem to be saying that that if I explicitly set the policy reqids that it should work. I had experimented with that a lot The problem is that I cannot find a good combination of reqids I want to say - "for this subnet all ftp auth (port 21) traffic is encrypted" I am testing between RedHat 5 and Windows So I have 4 rules (all specifying esp transport mode) // for outbound connections subnet -> subnet[21] out subnet[21] -> subnet in // for inbound connections subnet[21] -> subnet out subnet -> subnet[21] in So how to set the reqids - what would you suggest I set? a) just say unique and let the kernel allocate a new reqid each time (or explicitly put different reqid on each rule) you would think that this would work but it does not outbound connection works inbound connection does not - see below for why it fails even when the inbound connection is the first thing you do I can fix this behavior by reordering the SPD If I move the last 'in' to be before the first 'in' then inbound connection works There is no logical reason why I should have to reorder the rules like that and it doesn't feel very deterministic to me. why does it fail, because __xfrm_policy_check does xfrm_sk_policy_lookup. This matches the flow to a policy, since the SAs making up the flow do not have selectors then ports are ignored in the lookup. So the lookup matches the first one with matching dir and addresses. In the initial ordering of rules it returns #2 but the SPI it is checking against was built using #4 - xfrm_state_ok rejects it -> SOL If I reorder the rules then its OK. However the inverse case must also exist, where it needs to find other inbound policy. I just cant find the test case yet b) set both in rules to 1 (say) and both out rules to 2 (say) inbound connection works because both inbound rules have same reqid and so we avoid (a) case outbound connection after inbound connection done fails because it tries to reuse the outbound SA setup by the inbound ...
It's very simple, you want each equivalent class of SAs (i.e., SAs where any one can replace the other) to be assigned a unique reqid. The Openswan algorithm simply assigns an ID to each policy (or connection as it stores them internally), and then uses that ID as the reqid. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --
could u suggest a numbering for my 4 rules - as I said , no combination I have tried works // for outbound connections subnet -> subnet[21] out subnet[21] -> subnet in // for inbound connections subnet[21] -> subnet out subnet -> subnet[21] in -----Original Message----- From: Herbert Xu [mailto:herbert@gondor.apana.org.au] Sent: Tuesday, February 24, 2009 6:28 PM To: Paul Moore Cc: kaber@trash.net; davem@davemloft.net; netdev@vger.kernel.org Subject: Re: xfrm selector generating IKE It's very simple, you want each equivalent class of SAs (i.e., SAs where any one can replace the other) to be assigned a unique reqid. The Openswan algorithm simply assigns an ID to each policy (or connection as it stores them internally), and then uses that ID as the reqid. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --
If you want them to each use distinct SAs, then 1/2/3/4 or any four distinct reqid's will do. The point is that you should set the reqid on the policy yourself instead of having the kernel pick one for you at random. Then you know what to assign to your SAs when you create those. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --
thx - terse but helpful comments Q. I need port bound SAs that are optional. The kernel code seems to allow this but ip xfrm does not allow them to be specified (nor does pfkey) Is it simply an error in ip xfrm to ban them or does the kernel not support them -----Original Message----- From: Patrick McHardy [mailto:kaber@trash.net] Sent: Wednesday, January 28, 2009 10:12 AM To: Paul Moore Cc: David Miller; netdev@vger.kernel.org Subject: Re: port bound SAs You don't, using pfkey. Use reqid or ip xfrm. --
my inspection of the code shows that the port numbers in the SA do not get propagated into the right places in transport mode linux is never aware of the port numbers racoon systematically zeros them out during SA setup, but even if i correct the racoon code to put the port number in it still fails becuase the port numbers get ignored by the kernel -----Original Message----- From: David Miller [mailto:davem@davemloft.net] Sent: Monday, January 26, 2009 10:21 PM To: Paul Moore Cc: netdev@vger.kernel.org Subject: Re: port bound SAs From: "Paul Moore" <paul.moore@centrify.com> 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? --
