public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH] IPSec protocol application order
@ 2003-02-19 23:03 Tom Lendacky
  2003-02-20  1:32 ` David S. Miller
  0 siblings, 1 reply; 12+ messages in thread
From: Tom Lendacky @ 2003-02-19 23:03 UTC (permalink / raw)
  To: David S. Miller; +Cc: kuznet, linux-kernel


> 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



^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [PATCH] IPSec protocol application order
@ 2003-02-20 14:40 Tom Lendacky
  0 siblings, 0 replies; 12+ messages in thread
From: Tom Lendacky @ 2003-02-20 14:40 UTC (permalink / raw)
  To: David S. Miller; +Cc: cw, kuznet, linux-kernel


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




^ permalink raw reply	[flat|nested] 12+ messages in thread
* Re: [PATCH] IPSec protocol application order
@ 2003-02-19 21:48 Tom Lendacky
  2003-02-19 21:39 ` David S. Miller
  0 siblings, 1 reply; 12+ messages in thread
From: Tom Lendacky @ 2003-02-19 21:48 UTC (permalink / raw)
  To: David S. Miller; +Cc: Alexey N. Kuznetsov, linux-kernel


>> 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




^ permalink raw reply	[flat|nested] 12+ messages in thread
* [PATCH] IPSec protocol application order
@ 2003-02-19 20:42 Tom Lendacky
  2003-02-19 21:29 ` Jeff Garzik
  2003-02-19 22:05 ` David S. Miller
  0 siblings, 2 replies; 12+ messages in thread
From: Tom Lendacky @ 2003-02-19 20:42 UTC (permalink / raw)
  To: linux-kernel; +Cc: davem, kuznet, toml

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);
 	}


^ permalink raw reply	[flat|nested] 12+ messages in thread
end of thread, other threads:[~2003-02-20 14:31 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-02-19 23:03 [PATCH] IPSec protocol application order Tom Lendacky
2003-02-20  1:32 ` David S. Miller
2003-02-20  0:57   ` Chris Wedgwood
2003-02-20  6:51     ` David S. Miller
  -- strict thread matches above, loose matches on Subject: below --
2003-02-20 14:40 Tom Lendacky
2003-02-19 21:48 Tom Lendacky
2003-02-19 21:39 ` David S. Miller
2003-02-19 22:07   ` YOSHIFUJI Hideaki / 吉藤英明
2003-02-19 20:42 Tom Lendacky
2003-02-19 21:29 ` Jeff Garzik
2003-02-19 21:20   ` David S. Miller
2003-02-19 22:05 ` David S. Miller

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox