The IPSec RFC (2401) and IPComp RFC (3173) specify the order in which
the COMP, ESP and AH protocols must be applied when being applied in
transport mode. Specifically, COMP must be applied first, then ESP
and then AH. Also, transport mode protocols must be applied before
tunnel mode protocols.
Here is a patch that creates the xfrm_tmpl structures in the order
required by the RFCs. The patch requires that the application order
of new transformations/protocols be specified for transport mode
in order to have an xfrm_tmpl structure created. If this is not
desired, an additional transport mode loop can be placed ahead of the
COMP/ESP/AH transport mode loops that creates xfrm_tmpl structures
for protocols other than COMP/ESP/AH.
Tom
--- linux-2.5.62-orig/net/key/af_key.c 2003-02-17 16:56:09.000000000 -0600
+++ linux-2.5.62/net/key/af_key.c 2003-02-19 09:00:53.000000000 -0600
@@ -1562,12 +1562,58 @@
parse_ipsecrequests(struct xfrm_policy *xp, struct sadb_x_policy *pol)
{
int err;
- int len = pol->sadb_x_policy_len*8 - sizeof(struct sadb_x_policy);
- struct sadb_x_ipsecrequest *rq = (void*)(pol+1);
+ int len;
+ struct sadb_x_ipsecrequest *rq;
+ /* The order of template creation is important (RFC2401/RFC3173):
+ Transport templates first
+ COMP then
+ ESP then
+ AH then
+ Tunnel templates in any order */
+ len = pol->sadb_x_policy_len*8 - sizeof(struct sadb_x_policy);
+ rq = (void*)(pol+1);
while (len >= sizeof(struct sadb_x_ipsecrequest)) {
- if ((err = parse_ipsecrequest(xp, rq)) < 0)
- return err;
+ if (rq->sadb_x_ipsecrequest_mode == IPSEC_MODE_TRANSPORT &&
+ rq->sadb_x_ipsecrequest_proto == IPPROTO_COMP) {
+ if ((err = parse_ipsecrequest(xp, rq)) < 0)
+ return err;
+ }
+ len -= rq->sadb_x_ipsecrequest_len;
+ rq = (void*)((u8*)rq + rq->sadb_x_ipsecrequest_len);
+ }
+
+ len = pol->sadb_x_policy_len*8 - sizeof(struct sadb_x_policy);
+ rq = (void*)(pol+1);
+ while (len >= sizeof(struct sadb_x_ipsecrequest)) {
+ if (rq->sadb_x_ipsecrequest_mode == IPSEC_MODE_TRANSPORT &&
+ rq->sadb_x_ipsecrequest_proto == IPPROTO_ESP) {
+ if ((err = parse_ipsecrequest(xp, rq)) < 0)
+ return err;
+ }
+ len -= rq->sadb_x_ipsecrequest_len;
+ rq = (void*)((u8*)rq + rq->sadb_x_ipsecrequest_len);
+ }
+
+ len = pol->sadb_x_policy_len*8 - sizeof(struct sadb_x_policy);
+ rq = (void*)(pol+1);
+ while (len >= sizeof(struct sadb_x_ipsecrequest)) {
+ if (rq->sadb_x_ipsecrequest_mode == IPSEC_MODE_TRANSPORT &&
+ rq->sadb_x_ipsecrequest_proto == IPPROTO_AH) {
+ if ((err = parse_ipsecrequest(xp, rq)) < 0)
+ return err;
+ }
+ len -= rq->sadb_x_ipsecrequest_len;
+ rq = (void*)((u8*)rq + rq->sadb_x_ipsecrequest_len);
+ }
+
+ len = pol->sadb_x_policy_len*8 - sizeof(struct sadb_x_policy);
+ rq = (void*)(pol+1);
+ while (len >= sizeof(struct sadb_x_ipsecrequest)) {
+ if (rq->sadb_x_ipsecrequest_mode != IPSEC_MODE_TRANSPORT) {
+ if ((err = parse_ipsecrequest(xp, rq)) < 0)
+ return err;
+ }
len -= rq->sadb_x_ipsecrequest_len;
rq = (void*)((u8*)rq + rq->sadb_x_ipsecrequest_len);
}
On Wed, 2003-02-19 at 12:42, Tom Lendacky wrote:
> The IPSec RFC (2401) and IPComp RFC (3173) specify the order in which
> the COMP, ESP and AH protocols must be applied when being applied in
> transport mode. Specifically, COMP must be applied first, then ESP
> and then AH. Also, transport mode protocols must be applied before
> tunnel mode protocols.
Did you even read the email from Alexey yesterday that described
why none of this is a kernel issue and we merely do exactly what
the user application tells us to do when it uploads key configuration?
Just like you aparently ignored his email, I will ignore your patch.
On Wed, Feb 19, 2003 at 02:42:19PM -0600, Tom Lendacky wrote:
> The IPSec RFC (2401) and IPComp RFC (3173) specify the order in which
> the COMP, ESP and AH protocols must be applied when being applied in
> transport mode. Specifically, COMP must be applied first, then ESP
> and then AH. Also, transport mode protocols must be applied before
> tunnel mode protocols.
>
> Here is a patch that creates the xfrm_tmpl structures in the order
> required by the RFCs. The patch requires that the application order
> of new transformations/protocols be specified for transport mode
> in order to have an xfrm_tmpl structure created. If this is not
> desired, an additional transport mode loop can be placed ahead of the
> COMP/ESP/AH transport mode loops that creates xfrm_tmpl structures
> for protocols other than COMP/ESP/AH.
hmmm... do you really need to duplicate all that code, just to define
the order?
From: Jeff Garzik <[email protected]>
Date: Wed, 19 Feb 2003 16:29:50 -0500
hmmm... do you really need to duplicate all that code, just to define
the order?
It's not even a kernel issue as Alexey and myself said in other
emails, the kernel merely does what the user application asks it to do
>> The IPSec RFC (2401) and IPComp RFC (3173) specify the order in which
>> the COMP, ESP and AH protocols must be applied when being applied in
>> transport mode. Specifically, COMP must be applied first, then ESP
>> and then AH. Also, transport mode protocols must be applied before
>> tunnel mode protocols.
> Did you even read the email from Alexey yesterday that described
> why none of this is a kernel issue and we merely do exactly what
> the user application tells us to do when it uploads key configuration?
> Just like you aparently ignored his email, I will ignore your patch.
Yes, I read Alexey's email. He said that it is not a kernel or a setkey
issue. One of them is responsible for making sure the proper order is set
in order to insure RFC conformance and interoperability. You are saying
that it is up to the user application, which would be setkey. So if you
would prefer to not do this in the kernel you can ignore the patch, but
then the setkey application needs to be fixed.
Tom
From: "Tom Lendacky" <[email protected]>
Date: Wed, 19 Feb 2003 15:48:14 -0600
So if you would prefer to not do this in the kernel you can ignore
the patch, but then the setkey application needs to be fixed.
In one sense yes, but in another no.
setkey is for manual keying and debugging. Therefore, disallowing
experimenting with non-rfc-compliant orderings seems to lack purpose
to me.
In article <[email protected]> (at Wed, 19 Feb 2003 13:39:06 -0800 (PST)), "David S. Miller" <[email protected]> says:
> setkey is for manual keying and debugging. Therefore, disallowing
> experimenting with non-rfc-compliant orderings seems to lack purpose
> to me.
I'm for davem. Setkey is very flexible manual-keying tool and
we should not limit this flexibility.
--yoshfuji
> setkey is for manual keying and debugging. Therefore, disallowing
> experimenting with non-rfc-compliant orderings seems to lack purpose
> to me.
I apologize if I missed it, but is there another way to set policy in the
SPD besides the setkey command? I am under the assumption that setkey's
spdadd operation is what is to be used to define the policy on the system
so that racoon can perform dynamic keying.
Tom
On Wed, 2003-02-19 at 15:03, Tom Lendacky wrote:
> I apologize if I missed it, but is there another way to set policy in the
> SPD besides the setkey command? I am under the assumption that setkey's
> spdadd operation is what is to be used to define the policy on the system
> so that racoon can perform dynamic keying.
That's correct.
But there is still no issue.
The user can make his machine non-RFC compliant by giving a bogus
specification to setkey. Kernel and setkey are merely doing what
the user asks of them.
This is akin to the user writing a RAW socket application which makes
the kernel output non-RFC compliant TCP packets. Do you suggest that
the kernel or some other part of the system should verify the packets
sent through the RAW socket interface? That is exactly what you are
telling us that setkey should be doing.
On Wed, Feb 19, 2003 at 05:32:09PM -0800, David S. Miller wrote:
> ... Do you suggest that the kernel or some other part of the system
> should verify the packets sent through the RAW socket interface?
> That is exactly what you are telling us that setkey should be doing.
someone could patch setkey to warn if it's told to do something bogus,
with optional command line switch to silence this or whatever
--cw
From: Chris Wedgwood <[email protected]>
Date: Wed, 19 Feb 2003 16:57:29 -0800
someone could patch setkey to warn if it's told to do something bogus,
with optional command line switch to silence this or whatever
True. Whether this is wanted would be up to the KAME people
though. They are the maintainers of setkey and racoon.
I believe that good documentation will also be required then. If it is
being decided that the user must enter the ipsec protocols in the proper
order using the setkey spdadd operation, then the user will need to know
what order in which to specify the arguments to setkey. Given that the
spdadd operation:
spdadd src-ip dst-ip any -P out ipsec ah/transport//require
esp/transport//require;
would result in improper ordering of the AH and ESP headers and therefore
interoperability problems, while
spdadd src-ip dst-ip any -P out ipsec esp/transport//require
ah/transport//require;
results in the proper order.
No where have I been able to find any user level documentation that says
what order the ipsec protocols need to be specified on the spdadd
operation. Without good documentation I believe support centers, both a
customer's own and/or a distributor's, may be getting a lot of unnecessary
calls.
Tom