On Fri, 2007-03-30 at 10:40 -0400, Paul Moore wrote: > On Thursday, March 29 2007 8:16:31 pm Joy Latten wrote: > > On Thu, 2007-03-29 at 10:56 -0400, Paul Moore wrote: > > > Basically I'm trying to have each SPD rule, i.e. each "spdadd" command to > > > setkey, from my previous email (copied again below) result in a new SA. > > > For example I would like a connection from A,B[5300],UDP to use a > > > different SA then a connection from A,B[5300],TCP. I know this is > > > possible using different IPsec implementations and would be *very* > > > surprised to find this is not the case for the current Linux kernel. > > > Looking again at the setkey man page, I wonder if swapping "require" for > > > "unique" would accomplish this? > > > > Paul, I am not very familiar with "unique" so let me know if > > it works for you. > > Okay, I'll try and play with it a bit more but right now I'm still in a bit > of > a wrestling match with the proper way to configure labeled IPsec (as well as > IPsec in general) on Linux. I'm a bit tainted from using other > implementations and I'm finding some differences which have been tripping me > up ... > > > But in general, I think the upper layer protocol specified in the > > policy is not necessarily used to create the SA. From what I can tell by > > looking at the code, the upper layer protocol specified in policy is > > used as one of the selectors to determine if the policy and flow > > matches. A udp flow should not use a policy with tcp specified. > > However, from what I could determine, the upper layer protocol is not > > used in negotiating an SA. > > > > What I am not able to figure out is where in the code do we fill in > > the selector fields for the xfrm_state. We do use the selectors to > > find the SA to create the bundle. I was curious to see what we > > put for protocol in the selector for SAs. But I am unable to find in > > code where xfrm_selector structure is filled for SAs! I saw in > > __xfrm4_init_tempsel() and in __xfrm4_find_acq() where we fill in > > selector for larval SAs. But these get deleted once we add real SA. > > Could not find where we fill in selectors for real SA! It has > > to get filled in or nothing would work. My guess is that selector's > > protocol for SAs is always set to ANY. > > If it is always set to ANY that would explain the behavior, but that would > also be pretty scary for potential users who want to protect UDP and TCP > traffic separately as the setkey man page seems to indicate this is possible. > > Once I get things settled with the configuration I'll recheck to see what SAs > are actually used. > > If you arrive at a conclusion before then please let me know.
I took a look at the setkey manpage and noticed that although you can specify upper layer protocol in ipsec policy, when entering an SA manually there aren't any parameters for specifying upper layer protocol. I also took a look at the racoon code and could not find anywhere that upper layer protocol is passed on as an attribute when negotiating SA. I am thinking the implementation of ipsec-tools perhaps does not support this. I looked at pfkey api code in kernel and also could not find where selector or protocol is passed in ACQUIRE message to userspace. However, I looked at xfrm_user api and it looks like it may support this. It passes the entire selector structure into the ACQUIRE message to userspace. I could also easily find where it copies entire selector structure to new SA. Of course, I do not know all that may be in the selector at that time though. Upper layer protocol may or may not be there. I am not very familiar with openswan, but it is possible that it may support this behaviour if using xfrm_user api. If using kernel's pfkey api, then I don't see how it can. Of course I could have missed or misunderstood something. Regards, Joy -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
