John Williams Floroiu wrote:
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.
John,
if you have policy which "require" traffic to be protected using some ipsec means, then that traffic will not be allowed to reach application if it was not protected using these ipsec means. I just did the following experiment:
1) from Box-B started ping to Box-A; got responce every 1 sec. 2) on Box-A setkey -c <<EOP spdadd Box-B Box-A icmp -P in ipsec esp/transport//require; EOP
[You need to have 2 boxes, as pinging the same host from itself was not stoped (don't know why)]
As soon as this command was executed, I stoped to receive ping responces on Box-B. When I flushed SPD - ping responces resumed.
So, your app just needs to set policies right and believe that all the info it gets was protected.
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
-- Aidas Kasparas IT administrator GM Consult Group, UAB - : 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
