Re: a couple of comments on xfrm
From: Brian Buesker
Date: Wed Mar 24 2004 - 13:10:47 EST
One other topic that was discussed on the ipsec-tools-devel mailing list
was how support for specifying the priority for an SPD entry should be
added to the PF_KEY interface. Such a priority is already supported in
the XFRM interface, and it can be used to insert a policy into the SPD
at locations other than the end.
The two possible approaches that have been suggested are:
1. Use the sadb_x_policy_reserved2 field of struct sadb_x_policy to
indicate the priority.
2. Use the SADB_X_SPDSETIDX message to do this by defining a new message
format that includes the priority (and optionally an interface index as
well since this is also supported by the XFRM interface).
Are there opinions on which approach is preferrable? Is there a reason
why the reserved2 field should not be used? Also, is SADB_X_SPDSETIDX
intended to insert a policy or change the location of an existing one?
Currently messages of this type just use pfkey_spdadd, so it seems that
this message type could be used as an alternate way of inserting SPD
entries when the priority and interface index are desired.
Aidas Kasparas wrote:
John Williams Floroiu wrote:
here are a few comments I have on xfrm:
1. when a SPD entry is added (see "pfkey_spdadd"),
xp->selector.family isn't set accordingly. therefore when making a
netlink XFRM_MSG_DELPOLICY or XFRM_MSG_GETPOLICY call this
information is completely missing because (unlike "xfrm_policy")
"xfrm_userpolicy_info" has no "family" member. as a result the
selector sent to the kernel must have "family" set to 0, otherwise
the match will fail.
the mega patch that fixes this would look like:
--- net/key/af_key.c.orig 2004-03-23 15:39:14.000000000 +0100
+++ net/key/af_key.c 2004-03-23 18:56:43.000000000 +0100
@@ -1863,6 +1863,7 @@
err = -EINVAL;
+ xp->selector.family = xp->family;
xp->selector.prefixlen_s = sa->sadb_address_prefixlen;
xp->selector.sport = ((struct sockaddr_in *)(sa+1))->sin_port;
At ipsec-tools-devel list poeple find a need for patch like this. Yet
it would be very helpfull, if designer of this code could clarify:
1) why two family fields (one in policy, another in selector) are needed;
2) how they differs;
3) how they supposed to be filled.
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html