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 -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
