[redhat-lspp] Labeled IPsec localhost problems

Paul Moore paul.moore at hp.com
Tue Jan 30 22:43:14 UTC 2007


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.

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.

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.

Anyone?

-- 
paul moore
linux security @ hp




More information about the redhat-lspp mailing list