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