[redhat-lspp] Labeled IPsec localhost problems

[Joy Latten]

On Tue, 2007-01-30 at 17:43 -0500, Paul Moore wrote:
> As discussed in the LSPP conference call this week, it appears that when using 
> IPsec over localhost (I suspect you will see this behavior whenever the IPsec 
> selector for two SAs are the same) only a single SA is used, i.e. the 
> directionality of the SA is not preserved.  During the call I mentioned that 
> I was slightly concerned about this being a problem but at the time the only 
> thing I could think of was the AH/ESP sequence number.

yes, I was looking into this and then got kind of caught up in the code
because I was also thinking about your concern of SA pair not being
unidirectional.

> 
> While thinking about it a bit more today I believe there is another, more 
> serious concern; I'm hoping the labeled IPsec experts here could help 
> validate or disprove this ...
> 
> When using labeled IPsec the packet's are said to be implicitly labeled based 
> on the label assigned to the SA when it is created.  In practice, the SAs are 
> assigned labels based on the security context of the socket which triggers 
> the SPD rule requiring the use of IPsec (this glosses over some things, I 
> know, but I believe it captures the basic concept).  Since SAs are intended 
> to be unidirectional, for each bidirectional communication channel two SAs 
> are created.  In the traditional client-server model this means that for any 
> given communication channel between the two domain the client->server SA will 
> be labeled with label "A" and the server->client SA will be labeled with 
> label "B".  Normally this works fine, however, when the two SAs have the same 
> IPsec selector then the kernel gets confused and picks the same SA for each 
> direction.  The network traffic then gets labeled incorrectly in one of the 
> two directions.

Hmmm... I did not see this happening but I only played with it a little
so far. I did tcpdump and noticed that my ESP headers alway contained
the same spi. If it were randomly selecting an SA for outbound traffic,
I would have saw different spis... but like I said I only played with it
for awhile.

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.

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

Sigh... my head hurts and just thinking of this made me realize I think
we have a bug in policy for labeled ipsec. Darn!! Will write it up in
separate email since a separate issue. 

Joy