hello,
well, if you put it like this, then you are right ;-)
however we faced the following issue: there are protocols where the peers authenticate each other using some challenge-response mechanisms (for instance) in the first place, then they set an IPsec tunnel between each other. the application will now receive signalling which is no longer protected at the application layer, however one needs a mean to check that the packet has been received through a secure channel. we were happy with the FreeSWAN's approach because we could check the input interface and make sure it was ipsec*. now the only way to do it is to check if the traffic matches any of the policies.
in the event that somebody else has set policies on behalf of applications, each individual application might not know exactly all the parameters (in terms of selectors) of those policies, so it has to check whether any of the policies "covers" its traffic.
regards, John.
Aidas Kasparas wrote:
John Williams Floroiu wrote:
2. "xfrm_policy_bysel" compares selectors using memcmp. however, if a policy rule from say 10.0.0.0/8 to 20.0.0.0/8 (protocol, etc.) has been established, I guess traffic from 10.1.1.1/32 to 20.2.2.2/32 (same protocol, etc.) must match it. I believe some functions similar to __xfrm4_selector_match/__xfrm6_selector_match would be required here.
John,
Take a note where xfrm_policy_bysel() is used. Quick grep over source gave:
pfkey_spddelete()@net/key/af_key.c
xfrm_get_policy()@net/xfrm/xfrm_user.c
In first place user has requested to remove policy specified by policy description via PF_KEY interface. In second place - user has requested to get information about policy (and optionally remove it) from policy list via xfrm interface.
In both of these cases policy should be matched exactly and therefore present code is corect. This function is not used and is not intended to be used to find out if some traffic matches selector.
- : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
