[redhat-lspp] Labeled IPsec localhost problems

[Joy Latten]

On Tue, 2007-01-30 at 23:14 -0500, Paul Moore wrote:
> 
> The fact that you only saw one SPI being used indicates that only one SA was 
> being used.  I didn't mean to imply that the SA to use is being picked at 
> random, rather, the SA is being picked according to the regular IPsec 
> selector rules.  The problem is that multiple SAs exist with the same 
> selector which means that one SA is effectively hiding, or masking, a second 
> SA.
> 
> > I am currently revisiting the xfrm code and will answer shortly.
> > I will also run a loopback stress test tonight with your patch and
> > periodically check packets to see what is happening.
> >
> > By the way, I ran one last night with labeled ipsec over ipv6 with
> > your patch and happy to report the stress test completed a 15 hour
> > run successfully. So at least no regression on that front.
> 
> Great, thank you for testing this.  Out of curiosity, how many times during 
> the test did the phase-2 SAs get re-keyed, i.e. what was the SA lifetime?

ISAKMP SA lifetime is 30 minutes and IPSEC SA is 15 minutes. And test
ran for 15 hours sending streams of udp and tcp packets. I also had
both esp and ah configured to be used. 

> > > I know TCS did some work to at least partially (maybe fully?) integrate
> > > the label into the IPsec selector so this may not be an issue, but I know
> > > Joy/IBM mentioned seeing the same behavior during her labeled IPsec tests
> > > so I suspect this is in fact a problem.  Unfortunately I don't have
> > > anything setup to quickly test this so I thought I would send it out to
> > > list in hopes that someone else had already thought of this problem and
> > > (hopefully) solved it.
> >
> > Venkat can perhaps answer this best. I know he addressed this
> > previously. But yes, the label has been somewhat integrated into our
> > selection. On inbound we are guaranteed correct labeled SA because of
> > the spi.
> 
> ... Assuming that the SPI/SA has been used correctly by the sender, see my 
> comments above.
> 
> > On outbound we lookup policy by a selector match and a polmatch 
> > on flow's sid and policy's sid. This helps us to get the correct
> > policy.
> > policy->bundles contain xfrms used or associated with this policy.
> > My knowledge gets fuzzy here and I'll have to examine code for better
> > explanation or terminology, but we examine this list of xfrms to find
> > the one we want. We do this by a xfrm_selector_match() and permission
> > check betweem flow's sid and xfrm's sid. The result is the dst entry for
> > sending.
> > This is why I don't think we will be randomly picking between loopback
> > SAs, when sending out. But I will examine some more until I feel sure.
> > What I have not examined yet, is how the policy->bundle gets created. In
> > other words, for loopback, how do we ensure the SA meant for outbound
> > traffic gets associated with the outbound policy.
> 
> That is exactly the problem I am concerned about too ... using the standard 
> IPsec selectors of src,dst,proto,port I'm not sure there is a way to 
> differentiate connections between two localhost addresses in all cases; for 
> example, what happens if you want to label ICMP traffic across localhost?
> 
Ok, I am going to talk myself through this, I apologize ahead of time
if it is too much info and I will skip over stuff since xfrm process is
kind of a lot to me. :-)

This is not exclusive to loopback. What if I have a traffic stream
10.1.1.1->10.1.2.3 and I have specified a separate ipsec policy for each
upper layer protocol, udp, tcp, and icmp. This gives me 3 pairs of
policy entries (6 entries altogether) with exact same info except for
the upper-layer protocol. Well, in regular ipsec, this will result in a 
single pair of SAs, that will be used for icmp, udp, and tcp traffic.
This single pair of SAs will be associated with all 3 pairs of policy. 

Now with labeled ipsec, the only difference is the security context.
The security context is the "selector" that differentiates xfrms.
So, instead of a single pair of xfrms, we could possibly have many.
And the code takes care of this. To find correct xfrm, we do a 
xfrm_selector_match() and if successful, then do a
security_xfrm_state_pol_flow_match(), which checks to see if (flow->sid
== xfrm->id) then avc_has_perm(check for association:sendto) permission.
This ensures we get correct xfrm for the flow. Otherwise return error
and continue to step thru xfrm list until you find another one whose
selector matches and try again. If there is none and we have a policy,
then call racoon.

Now with loopback the concern is we will have two exact SAs per
security context. I am thinking that if they are exact, what does
it matter which one gets used. We just want to make sure we use SA
that has the correct security context and this will get done
via security_xfrm_state_pol_flow_match() per what I said in above
paragraph. Venkat or anyone, please correct me if I am off on this
or missing something. Regardless of which SA of the pair
gets used, the SPI will ensure we pull up corresponding SA for inbound. 

Now because of the policy->bundle feature, I think one of the SAs
of the pair will always end up being used for outbound and the other
for inbound processing. Again, unless I am missing something, I
think it won't matter which of the 2 gets associated with inbound or
outbound policy->bundle since they are exact.

Switching back to regular labeled ipsec, I have noticed in a
client->server model, "ssh" for example, 4 pairs of
SAs get created per security context. A pair for server and a pair for
client. I have noticed, when sending, the client security context is
used. Upon receiving, the server needs to have recvfrom permission to
use client SA. Correct SA will always get pulled up because of spi.

Switching to loopback, this should work ok too. (i tried it and it did) 
  
As for sequence numbers, their use is optional and we can
specify/document that when using loopback, we recommend you do not use
them since loopback has guaranteed delivery. Because yes, packets can
get dropped when using sequence numbers and window size. 

Ok, if I missed something, please let me know.

And last but not least, I started a labeled ipsec over loopback stress
test last night. So far it has been running for 15 hours.
isakmp lifetime is 30 minutes 
ipsec sa lifetime is 15 minutes
esp used over tcp and udp.
 
I have noticed only one thing that I am concerned about.
I have not yet figured out what it means. Although pfkey ADD fails, I
believe the new SA has been entered because when I dump the databases, I
notice the new spis in the SAs.The old ones are gone...

My log file has the following. I think it occurs for each rekeying.

Jan 31 15:12:46 tim-hv4 racoon: INFO: IPsec-SA expired: ESP/Transport
127.0.0.1[0]->127.0.0.1[0] spi=29906937(0x1c857f9)
Jan 31 15:12:47 tim-hv4 racoon: INFO: IPsec-SA expired: ESP/Transport
127.0.0.1[0]->127.0.0.1[0] spi=200715915(0xbf6ae8b)
Jan 31 15:12:47 tim-hv4 racoon: INFO: initiate new phase 2 negotiation:
127.0.0.1[0]<=>127.0.0.1[0]
Jan 31 15:12:47 tim-hv4 racoon: INFO: respond new phase 2 negotiation:
127.0.0.1[0]<=>127.0.0.1[0]
Jan 31 15:12:49 tim-hv4 racoon: INFO: IPsec-SA established:
ESP/Transport 127.0.0.1[0]->127.0.0.1[0] spi=211935989(0xca1e2f5)
Jan 31 15:12:49 tim-hv4 racoon: ERROR: pfkey ADD failed: File exists
Jan 31 15:12:49 tim-hv4 racoon: INFO: IPsec-SA established:
ESP/Transport 127.0.0.1[0]->127.0.0.1[0] spi=251963520(0xf04a880)
Jan 31 15:12:49 tim-hv4 racoon: ERROR: pfkey ADD failed: File exists


Regards,
Joy