[redhat-lspp] Labeled IPsec localhost problems

[Paul Moore]

On Tuesday 30 January 2007 9:06 pm, Joy Latten wrote:
> On Tue, 2007-01-30 at 17:43 -0500, Paul Moore wrote:
> > 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.

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?

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

-- 
paul moore
linux security @ hp