From: Brian B. <bbu...@qu...> - 2004-03-15 21:50:00
|
I came across the following problem. If you want to have a policy that will match any IPv4 and IPv6 address for a specific port, say 21, it is not possible to insert a single policy to do this nor is it possible to insert two different policies. For example, if you just do: spdadd ::0/0[any] ::0/0[21] tcp -P in ipsec esp/transport//require; spdadd ::0/0[21] ::0/0[any] tcp -P out ipsec esp/transport//require; Then these policies are only matched for IPv6 addresses, since xfrm_policy_lookup compares the family of the policy to the family of the flow. If instead you try to insert a policy for both IPv4 and IPv6, such as: spdadd ::0/0[any] ::0/0[5000] tcp -P in ipsec esp/transport//require; spdadd ::0/0[5000] ::0/0[any] tcp -P out ipsec esp/transport//require; spdadd 0.0.0.0/0[any] 0.0.0.0/0[21] tcp -P in ipsec esp/transport//require; spdadd 0.0.0.0/0[21] 0.0.0.0/0[any] tcp -P out ipsec esp/transport//require; Then you get an error saying the policy already exists, since xfrm_policy_insert just compares the selectors and the family for them doesn't get set by the PF_KEY code. I think the Netlink interface does set the family in the selector, so it would allow for both IPv4 and IPv6 policies to be inserted. Maybe PF_KEY should do this as well, by setting xp->selector.family = xp->family in pfkey_spdadd. Brian |
From: Michal L. <mi...@lo...> - 2004-03-19 17:25:30
Attachments:
kernel-spdadd-family-1.diff
|
On Mon, 15 Mar 2004, Brian Buesker wrote: > I came across the following problem. If you want to have a policy that > will match any IPv4 and IPv6 address for a specific port, say 21, it is > not possible to insert a single policy to do this nor is it possible to > insert two different policies. For example, if you just do: > > spdadd ::0/0[any] ::0/0[21] tcp -P in ipsec esp/transport//require; > spdadd ::0/0[21] ::0/0[any] tcp -P out ipsec esp/transport//require; > > Then these policies are only matched for IPv6 addresses, since > xfrm_policy_lookup compares the family of the policy to the family of > the flow. > > If instead you try to insert a policy for both IPv4 and IPv6, such as: > > spdadd ::0/0[any] ::0/0[5000] tcp -P in ipsec esp/transport//require; > spdadd ::0/0[5000] ::0/0[any] tcp -P out ipsec esp/transport//require; > > spdadd 0.0.0.0/0[any] 0.0.0.0/0[21] tcp -P in ipsec esp/transport//require; > spdadd 0.0.0.0/0[21] 0.0.0.0/0[any] tcp -P out ipsec esp/transport//require; > > Then you get an error saying the policy already exists, since > xfrm_policy_insert just compares the selectors and the family for them > doesn't get set by the PF_KEY code. I think the Netlink interface does > set the family in the selector, so it would allow for both IPv4 and > IPv6 policies to be inserted. Maybe PF_KEY should do this as well, by > setting xp->selector.family = xp->family in pfkey_spdadd. Something like the attached? Not tested, but looks reasonable... Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal |
From: <mr...@mr...> - 2004-03-19 17:41:37
|
Michal Ludvig <mi...@lo...> writes: > --- linux-2.6.3.patched/net/key/af_key.c 2004-03-05 14:22:22.000000000 +0= 100 > +++ linux-2.6.3/net/key/af_key.c 2004-03-19 18:06:59.000000000 +0100 > @@ -1863,6 +1863,7 @@ static int pfkey_spdadd(struct sock *sk, > err =3D -EINVAL; > goto out; > } > + xp->selector.family - xp->family; That statement does nothing, AFAICS. --=20 M=E5ns Rullg=E5rd mr...@mr... |
From: Michal L. <mi...@lo...> - 2004-03-19 17:42:42
|
On Fri, 19 Mar 2004, [iso-8859-1] M?ns Rullg?rd wrote: > Michal Ludvig <mi...@lo...> writes: > > > --- linux-2.6.3.patched/net/key/af_key.c 2004-03-05 14:22:22.000000000 +0100 > > +++ linux-2.6.3/net/key/af_key.c 2004-03-19 18:06:59.000000000 +0100 > > @@ -1863,6 +1863,7 @@ static int pfkey_spdadd(struct sock *sk, > > err = -EINVAL; > > goto out; > > } > > + xp->selector.family - xp->family; > > That statement does nothing, AFAICS. Oops, should have been: xp->selector.family = xp->family; Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal |
From: Brian B. <bbu...@qu...> - 2004-03-19 17:41:57
|
Yes, that patch is exactly what I was thinking and had already tried. It does fix the problem. Maybe this should be submitted to the linux-net mailing list. I'd do it myself, but I have to receive approval before doing so, and sometimes that takes a little while. Another nice addition to the PF_KEY interface for the SPD would be the ability to specify a priority. The Netlink API already allows one to do so. The priority just determines where in the SPD the entry is inserted (sorted from lowest to highest, with ties determined by order of insertion with the newest one last). I'd suggest using the sadb_x_policy_reserved2 field of struct sadb_x_policy and then setting xp->priority from it in pfkey_spdadd. Does anyone know if there is any reason this field cannot be used for the priority? If the kernel modification was made, then setkey could be extended to allow the priority to be specified, and support for the priority could be added to racoon and libipsec. I started doing this but got sidetracked with other tasks and I don't know exactly when I'll be able to come back to it. Thoughts on this suggestion? Brian Michal Ludvig wrote: >On Mon, 15 Mar 2004, Brian Buesker wrote: > > > >>I came across the following problem. If you want to have a policy that >>will match any IPv4 and IPv6 address for a specific port, say 21, it is >>not possible to insert a single policy to do this nor is it possible to >>insert two different policies. For example, if you just do: >> >>spdadd ::0/0[any] ::0/0[21] tcp -P in ipsec esp/transport//require; >>spdadd ::0/0[21] ::0/0[any] tcp -P out ipsec esp/transport//require; >> >>Then these policies are only matched for IPv6 addresses, since >>xfrm_policy_lookup compares the family of the policy to the family of >>the flow. >> >>If instead you try to insert a policy for both IPv4 and IPv6, such as: >> >>spdadd ::0/0[any] ::0/0[5000] tcp -P in ipsec esp/transport//require; >>spdadd ::0/0[5000] ::0/0[any] tcp -P out ipsec esp/transport//require; >> >>spdadd 0.0.0.0/0[any] 0.0.0.0/0[21] tcp -P in ipsec esp/transport//require; >>spdadd 0.0.0.0/0[21] 0.0.0.0/0[any] tcp -P out ipsec esp/transport//require; >> >>Then you get an error saying the policy already exists, since >>xfrm_policy_insert just compares the selectors and the family for them >>doesn't get set by the PF_KEY code. I think the Netlink interface does >>set the family in the selector, so it would allow for both IPv4 and >>IPv6 policies to be inserted. Maybe PF_KEY should do this as well, by >>setting xp->selector.family = xp->family in pfkey_spdadd. >> >> > >Something like the attached? Not tested, but looks reasonable... > >Michal Ludvig > > >------------------------------------------------------------------------ > >--- linux-2.6.3.patched/net/key/af_key.c 2004-03-05 14:22:22.000000000 +0100 >+++ linux-2.6.3/net/key/af_key.c 2004-03-19 18:06:59.000000000 +0100 >@@ -1863,6 +1863,7 @@ static int pfkey_spdadd(struct sock *sk, > err = -EINVAL; > goto out; > } >+ xp->selector.family - xp->family; > xp->selector.prefixlen_s = sa->sadb_address_prefixlen; > xp->selector.proto = pfkey_proto_to_xfrm(sa->sadb_address_proto); > xp->selector.sport = ((struct sockaddr_in *)(sa+1))->sin_port; > > |
From: Aidas K. <a.k...@gm...> - 2004-03-21 10:16:38
|
Hi, I think these two are separate problems and we would have better chances if we don't mix solutions for both of them to one patch sent to linux-net. Re: family. Does anybody know design reason why there are two "family" fields: in selector and in policy? Is there some docs HOW these two should be set? If not - I would propose to post this question to linux-net and only after that suggest solution. Re: priority - I understand the need for it, I understand that pf_key interface will need to be extended. The only questions I have are how does proposed method fit RFC-2367? What will happen if one of ipsec-tools or kernel will not support new method? Brian Buesker wrote: > Yes, that patch is exactly what I was thinking and had already tried. It > does fix the problem. Maybe this should be submitted to the linux-net > mailing list. I'd do it myself, but I have to receive approval before > doing so, and sometimes that takes a little while. > > Another nice addition to the PF_KEY interface for the SPD would be the > ability to specify a priority. The Netlink API already allows one to do > so. The priority just determines where in the SPD the entry is inserted > (sorted from lowest to highest, with ties determined by order of > insertion with the newest one last). I'd suggest using the > sadb_x_policy_reserved2 field of struct sadb_x_policy and then setting > xp->priority from it in pfkey_spdadd. Does anyone know if there is any > reason this field cannot be used for the priority? > > If the kernel modification was made, then setkey could be extended to > allow the priority to be specified, and support for the priority could > be added to racoon and libipsec. I started doing this but got > sidetracked with other tasks and I don't know exactly when I'll be able > to come back to it. Thoughts on this suggestion? > > Brian > > Michal Ludvig wrote: > >> On Mon, 15 Mar 2004, Brian Buesker wrote: >> >> >> >>> I came across the following problem. If you want to have a policy that >>> will match any IPv4 and IPv6 address for a specific port, say 21, it is >>> not possible to insert a single policy to do this nor is it possible to >>> insert two different policies. For example, if you just do: >>> >>> spdadd ::0/0[any] ::0/0[21] tcp -P in ipsec esp/transport//require; >>> spdadd ::0/0[21] ::0/0[any] tcp -P out ipsec esp/transport//require; >>> >>> Then these policies are only matched for IPv6 addresses, since >>> xfrm_policy_lookup compares the family of the policy to the family of >>> the flow. >>> >>> If instead you try to insert a policy for both IPv4 and IPv6, such as: >>> >>> spdadd ::0/0[any] ::0/0[5000] tcp -P in ipsec esp/transport//require; >>> spdadd ::0/0[5000] ::0/0[any] tcp -P out ipsec esp/transport//require; >>> >>> spdadd 0.0.0.0/0[any] 0.0.0.0/0[21] tcp -P in ipsec >>> esp/transport//require; >>> spdadd 0.0.0.0/0[21] 0.0.0.0/0[any] tcp -P out ipsec >>> esp/transport//require; >>> >>> Then you get an error saying the policy already exists, since >>> xfrm_policy_insert just compares the selectors and the family for them >>> doesn't get set by the PF_KEY code. I think the Netlink interface does >>> set the family in the selector, so it would allow for both IPv4 and >>> IPv6 policies to be inserted. Maybe PF_KEY should do this as well, by >>> setting xp->selector.family = xp->family in pfkey_spdadd. >>> >> >> >> Something like the attached? Not tested, but looks reasonable... >> >> Michal Ludvig >> >> >> ------------------------------------------------------------------------ >> >> --- linux-2.6.3.patched/net/key/af_key.c 2004-03-05 >> 14:22:22.000000000 +0100 >> +++ linux-2.6.3/net/key/af_key.c 2004-03-19 18:06:59.000000000 +0100 >> @@ -1863,6 +1863,7 @@ static int pfkey_spdadd(struct sock *sk, >> err = -EINVAL; >> goto out; >> } >> + xp->selector.family - xp->family; >> xp->selector.prefixlen_s = sa->sadb_address_prefixlen; >> xp->selector.proto = pfkey_proto_to_xfrm(sa->sadb_address_proto); >> xp->selector.sport = ((struct sockaddr_in *)(sa+1))->sin_port; >> >> > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Ipsec-tools-devel mailing list > Ips...@li... > https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel -- Aidas Kasparas IT administrator GM Consult Group, UAB |
From: Brian B. <bbu...@qu...> - 2004-03-22 16:27:24
|
Aidas Kasparas wrote: > Hi, > > I think these two are separate problems and we would have better > chances if we don't mix solutions for both of them to one patch sent > to linux-net. Agreed. > > Re: family. Does anybody know design reason why there are two > "family" fields: in selector and in policy? Is there some docs HOW > these two should be set? If not - I would propose to post this > question to linux-net and only after that suggest solution. I really don't know why there are two "family" fields. It seems that the family field inside struct xfrm_selector is only used when checking for duplicated policies, while the family field in struct xfrm_policy is used for lookup operations. It probably would be a good thing to ask on linux-net. > > Re: priority - I understand the need for it, I understand that > pf_key interface will need to be extended. The only questions I have > are how does proposed method fit RFC-2367? What will happen if one of > ipsec-tools or kernel will not support new method? IIRC, RFC 2367 doesn't specify PF_KEY for SPD policies. I think it only specifies the interface to the SADB. So I don't think we would be violating it. If we went with the approach to use the sadb_x_policy_reserved2 field then if ipsec-tools didn't support it but the kernel did, it would still get inserted at the end of the SPD list since the kernel would always receive policies with a priority of 0. If the kernel did not support it but ipsec-tools did, then the old behavior would again just occur since the kernel would just be defaulting the priority to 0 as it does right now. Brian > > Brian Buesker wrote: > >> Yes, that patch is exactly what I was thinking and had already tried. >> It does fix the problem. Maybe this should be submitted to the >> linux-net mailing list. I'd do it myself, but I have to receive >> approval before doing so, and sometimes that takes a little while. >> >> Another nice addition to the PF_KEY interface for the SPD would be >> the ability to specify a priority. The Netlink API already allows one >> to do so. The priority just determines where in the SPD the entry is >> inserted (sorted from lowest to highest, with ties determined by >> order of insertion with the newest one last). I'd suggest using the >> sadb_x_policy_reserved2 field of struct sadb_x_policy and then >> setting xp->priority from it in pfkey_spdadd. Does anyone know if >> there is any reason this field cannot be used for the priority? >> >> If the kernel modification was made, then setkey could be extended to >> allow the priority to be specified, and support for the priority >> could be added to racoon and libipsec. I started doing this but got >> sidetracked with other tasks and I don't know exactly when I'll be >> able to come back to it. Thoughts on this suggestion? >> >> Brian >> >> Michal Ludvig wrote: >> >>> On Mon, 15 Mar 2004, Brian Buesker wrote: >>> >>> >>> >>>> I came across the following problem. If you want to have a policy that >>>> will match any IPv4 and IPv6 address for a specific port, say 21, >>>> it is >>>> not possible to insert a single policy to do this nor is it >>>> possible to >>>> insert two different policies. For example, if you just do: >>>> >>>> spdadd ::0/0[any] ::0/0[21] tcp -P in ipsec esp/transport//require; >>>> spdadd ::0/0[21] ::0/0[any] tcp -P out ipsec esp/transport//require; >>>> >>>> Then these policies are only matched for IPv6 addresses, since >>>> xfrm_policy_lookup compares the family of the policy to the family of >>>> the flow. >>>> >>>> If instead you try to insert a policy for both IPv4 and IPv6, such as: >>>> >>>> spdadd ::0/0[any] ::0/0[5000] tcp -P in ipsec esp/transport//require; >>>> spdadd ::0/0[5000] ::0/0[any] tcp -P out ipsec esp/transport//require; >>>> >>>> spdadd 0.0.0.0/0[any] 0.0.0.0/0[21] tcp -P in ipsec >>>> esp/transport//require; >>>> spdadd 0.0.0.0/0[21] 0.0.0.0/0[any] tcp -P out ipsec >>>> esp/transport//require; >>>> >>>> Then you get an error saying the policy already exists, since >>>> xfrm_policy_insert just compares the selectors and the family for them >>>> doesn't get set by the PF_KEY code. I think the Netlink interface does >>>> set the family in the selector, so it would allow for both IPv4 and >>>> IPv6 policies to be inserted. Maybe PF_KEY should do this as well, by >>>> setting xp->selector.family = xp->family in pfkey_spdadd. >>>> >>> >>> >>> >>> Something like the attached? Not tested, but looks reasonable... >>> >>> Michal Ludvig >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> --- linux-2.6.3.patched/net/key/af_key.c 2004-03-05 >>> 14:22:22.000000000 +0100 >>> +++ linux-2.6.3/net/key/af_key.c 2004-03-19 18:06:59.000000000 +0100 >>> @@ -1863,6 +1863,7 @@ static int pfkey_spdadd(struct sock *sk, >>> err = -EINVAL; >>> goto out; >>> } >>> + xp->selector.family - xp->family; >>> xp->selector.prefixlen_s = sa->sadb_address_prefixlen; >>> xp->selector.proto = pfkey_proto_to_xfrm(sa->sadb_address_proto); >>> xp->selector.sport = ((struct sockaddr_in *)(sa+1))->sin_port; >>> >>> >> >> >> ------------------------------------------------------- >> This SF.Net email is sponsored by: IBM Linux Tutorials >> Free Linux tutorial presented by Daniel Robbins, President and CEO of >> GenToo technologies. Learn everything from fundamentals to system >> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click >> _______________________________________________ >> Ipsec-tools-devel mailing list >> Ips...@li... >> https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel > > |
From: Michal L. <mi...@lo...> - 2004-03-22 10:04:27
|
On Fri, 19 Mar 2004, Brian Buesker wrote: > Yes, that patch is exactly what I was thinking and had already tried. It > does fix the problem. Maybe this should be submitted to the linux-net > mailing list. I'd do it myself, but I have to receive approval before > doing so, and sometimes that takes a little while. Approval for what? I can submit it if you want. I'll also check if there is something similar needed for spd_delete. > Another nice addition to the PF_KEY interface for the SPD would be the > ability to specify a priority. The Netlink API already allows one to do > so. The priority just determines where in the SPD the entry is inserted > (sorted from lowest to highest, with ties determined by order of > insertion with the newest one last). I'd suggest using the > sadb_x_policy_reserved2 field of struct sadb_x_policy and then setting > xp->priority from it in pfkey_spdadd. Does anyone know if there is any > reason this field cannot be used for the priority? How about SADB_X_SPDSETIDX? Shouldn't it do something similar? Michal Ludvig -- * A mouse is a device used to point at the xterm you want to type in. * Personal homepage - http://www.logix.cz/michal |
From: Brian B. <bbu...@qu...> - 2004-03-22 16:39:47
|
Michal Ludvig wrote: >On Fri, 19 Mar 2004, Brian Buesker wrote: > > > >>Yes, that patch is exactly what I was thinking and had already tried. It >>does fix the problem. Maybe this should be submitted to the linux-net >>mailing list. I'd do it myself, but I have to receive approval before >>doing so, and sometimes that takes a little while. >> >> > >Approval for what? I can submit it if you want. I'll also check if there >is something similar needed for spd_delete. > > I have to get approval before I can submit any patches (unfortunate but true). I think pfkey_spddelete will also need the same change since it uses xfrm_policy_bysel which does a memcmp on the selectors. > > >>Another nice addition to the PF_KEY interface for the SPD would be the >>ability to specify a priority. The Netlink API already allows one to do >>so. The priority just determines where in the SPD the entry is inserted >>(sorted from lowest to highest, with ties determined by order of >>insertion with the newest one last). I'd suggest using the >>sadb_x_policy_reserved2 field of struct sadb_x_policy and then setting >>xp->priority from it in pfkey_spdadd. Does anyone know if there is any >>reason this field cannot be used for the priority? >> >> > >How about SADB_X_SPDSETIDX? Shouldn't it do something similar? > > Hmm, that's interesting. I hadn't seen that before. Right now it just uses pfkey_spdadd so it doesn't do anything different. It defintely could be made to do something different though. I guess it could even be extended to allow specifying an interface index as well (as the xfrm_user API supports). Maybe that would be the better way to go. There could be an additional header which holds the priority and interface index, and the kernel could fall back to using just the normal pfkey_spdadd if that header isn't present. Brian >Michal Ludvig > > |