port bound SAs

port bound SAs

[Paul Moore]

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

Re: port bound SAs

[David Miller]

From: "Paul Moore" <paul.moore@centrify.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?

Re: port bound SAs

[Patrick McHardy]

David Miller wrote:
> From: "Paul Moore" <paul.moore@centrify.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?

RE: port bound SAs

[Paul Moore]

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@trash.net] 
Sent: Tuesday, January 27, 2009 2:27 AM
To: David Miller
Cc: Paul Moore; netdev@vger.kernel.org
Subject: Re: port bound SAs

David Miller wrote:
> From: "Paul Moore" <paul.moore@centrify.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?

Re: port bound SAs

[Patrick McHardy]

Paul Moore wrote:
> 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

Assuming you're also using setkey, try adding "unique" to your policies.

RE: port bound SAs

[Paul Moore]

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

Paul Moore wrote:
> 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

Assuming you're also using setkey, try adding "unique" to your policies.

Re: port bound SAs

[Patrick McHardy]

Paul Moore wrote:
> 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

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.

RE: port bound SAs

[Paul Moore]

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

Paul Moore wrote:
> 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

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.

Re: port bound SAs

[David Miller]

From: "Paul Moore" <paul.moore@centrify.com>
Date: Tue, 27 Jan 2009 09:13:46 -0800

> the pfkey / xfrm interface throws them away
> 
> i fixed racoon to send the port numbers and they were ignored

Did you actually try "ip xfrm" as Patrick suggested?

Where exactly are the ports "thrown away" for both pfkey and xfrm
cases?

RE: port bound SAs

[Paul Moore]

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>
Date: Tue, 27 Jan 2009 09:13:46 -0800

> the pfkey / xfrm interface throws them away
> 
> i fixed racoon to send the port numbers and they were ignored

Did you actually try "ip xfrm" as Patrick suggested?

Where exactly are the ports "thrown away" for both pfkey and xfrm
cases?

Re: port bound SAs

[Patrick McHardy]

Paul Moore wrote:
> the pfkey / xfrm interface throws them away

I misparsed that statement, I thought you meant both. Yes, you
seem to be right, pfkey ignores them.

> i fixed racoon to send the port numbers and they were ignored

I believe thats intentional, RFC2367 specifies to ignore port
numbers except for larval states.

RE: port bound SAs

[Paul Moore]

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

Paul Moore wrote:
> the pfkey / xfrm interface throws them away

I misparsed that statement, I thought you meant both. Yes, you
seem to be right, pfkey ignores them.

> i fixed racoon to send the port numbers and they were ignored

I believe thats intentional, RFC2367 specifies to ignore port
numbers except for larval states.

Re: port bound SAs

[Patrick McHardy]

Paul Moore wrote:
>>> 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)

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.

RE: port bound SAs

[Paul Moore]

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

Paul Moore wrote:
>>> 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)

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.

Re: port bound SAs

[Patrick McHardy]

Paul Moore wrote:
> OK I misunderstood. Sorry
>
> You are saying that the port number should be dropped by the pfkey /
> xfrm interface - OK
>   

Yes. I think thats also why it includes the unique" option.

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

Yes, if the selectors would actually differ, it would be wrong.

RE: port bound SAs

[Paul Moore]

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

Re: port bound SAs

[Patrick McHardy]

Paul Moore wrote:
> 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?

No, so far everything seems fine. The SAs don't have a port selector,
no reqid is specified => Linux is allowed to reuse them.

RE: port bound SAs

[Paul Moore]

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

Paul Moore wrote:
> 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?

No, so far everything seems fine. The SAs don't have a port selector,
no reqid is specified => Linux is allowed to reuse them.

Re: port bound SAs

[Patrick McHardy]

Paul Moore wrote:
> So how do I get an SA with a port set on it

You don't, using pfkey. Use reqid or ip xfrm.

RE: port bound SAs

[Paul Moore]

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

Paul Moore wrote:
> So how do I get an SA with a port set on it

You don't, using pfkey. Use reqid or ip xfrm.

Re: port bound SAs

[Herbert Xu]

Paul Moore <paul.moore@centrify.com> wrote:
> aha - so with racoon (which uses pfkey) I cannot make this work

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

xfrm selector generating IKE

[Paul Moore]

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

Paul Moore <paul.moore@centrify.com> wrote:
> aha - so with racoon (which uses pfkey) I cannot make this work

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

Re: xfrm selector generating IKE

[Herbert Xu]

On Mon, Feb 23, 2009 at 05:31:29PM -0800, Paul Moore wrote:
> 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

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

RE: xfrm selector generating IKE

[Paul Moore]

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

On Mon, Feb 23, 2009 at 05:31:29PM -0800, Paul Moore wrote:
> 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

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

Re: xfrm selector generating IKE

[Herbert Xu]

On Tue, Feb 24, 2009 at 09:23:39AM -0800, Paul Moore wrote:
> 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

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

RE: xfrm selector generating IKE

[Paul Moore]

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 connection (both have the
same reqid) but the remote system (windows) thinks that that SA is for
inbound traffic from 21 (which it is) and so discards the packets

c) set both port src 21 rules to 1 and both dest 21 rules to 2
this fails like (a) 



BTW all works fine after I change af_key.c to accept port numbers from
sadb_address and copy to SA selector - dont need any reqids

Re: xfrm selector generating IKE

[Herbert Xu]

On Tue, Feb 24, 2009 at 06:07:06PM -0800, Paul Moore wrote:
> 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 

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

RE: xfrm selector generating IKE

[Paul Moore]

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

On Tue, Feb 24, 2009 at 06:07:06PM -0800, Paul Moore wrote:
> 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 

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

Re: xfrm selector generating IKE

[Herbert Xu]

On Tue, Feb 24, 2009 at 06:30:41PM -0800, Paul Moore wrote:
> 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

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

RE: port bound SAs

[Paul Moore]

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

Paul Moore wrote:
> So how do I get an SA with a port set on it

You don't, using pfkey. Use reqid or ip xfrm.

RE: port bound SAs

[Paul Moore]

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