All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Ulrich Weber <uweber@astaro.de>
Cc: vpn-failover@lists.balabit.hu, netdev@oss.sgi.com,
	ipsec-tools-devel@lists.sourceforge.net
Subject: Re: [Vpn-failover] [RFC] IPSEC failover - Netlink part
Date: Thu, 04 Nov 2004 19:15:54 +0100	[thread overview]
Message-ID: <418A71DA.2090607@trash.net> (raw)
In-Reply-To: <418A3630.1040900@astaro.de>

Ulrich Weber wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> I take the opportunity to post my code as well. At the moment I'm 
> working at
> the same as Krisztian. My solutions however is for openswan, which uses
> netlink instead of pfkey.
>
> Please find attached the appropriate netlink modifications to
> include/linux/xfrm.h and net/xfrm/xfrm_users.c
>
> In theses patches, a new netlink group (XFRMGRP_REPLAY) is added to 
> notify
> about seq number changes. Each notify message contains a xfrm_usersa_id
> struct with the replay struct attached as rt attribute. In addition, 
> these
> replay struct is also attached at ipsec sa dumps.
>
> Any comments are welcome :)


Some minor bugs, see below.

Regards
Patrick

>------------------------------------------------------------------------
>
>--- linux.org/include/linux/xfrm.h.	2004-10-11 04:57:07.000000000 +0200
>+++ linux/include/linux/xfrm.h	2004-10-18 17:00:43.000000000 +0200
>@@ -140,6 +140,9 @@
> 	XFRM_MSG_FLUSHPOLICY,
> #define XFRM_MSG_FLUSHPOLICY XFRM_MSG_FLUSHPOLICY
> 
>+	XFRM_MSG_UPDSEQ,
>+#define XFRM_MSG_UPDSEQ XFRM_MSG_UPDSEQ
>+
> 	XFRM_MSG_MAX
> };
> 
>@@ -171,6 +174,7 @@
> 	XFRMA_ALG_COMP,		/* struct xfrm_algo */
> 	XFRMA_ENCAP,		/* struct xfrm_algo + struct xfrm_encap_tmpl */
> 	XFRMA_TMPL,		/* 1 or more struct xfrm_user_tmpl */
>+	XFRMA_REPLAY,		/* struct xfrm_replay_state */ 
> 	__XFRMA_MAX
> 
> #define XFRMA_MAX (__XFRMA_MAX - 1)
>@@ -258,5 +258,6 @@
>
> #define XFRMGRP_ACQUIRE                1
> #define XFRMGRP_EXPIRE         2
>+#define XFRMGRP_REPLAY         3
>
> #endif /* _LINUX_XFRM_H */
>  
>
>------------------------------------------------------------------------
>
>--- linux.org/net/xfrm/xfrm_user.c	2004-10-18 23:54:32.000000000 +0200
>+++ linux/net/xfrm/xfrm_user.c	2004-10-21 16:27:59.000000000 +0200
>@@ -240,6 +240,12 @@
> 	if ((err = attach_encap_tmpl(&x->encap, xfrma[XFRMA_ENCAP-1])))
> 		goto error;
> 
>+        if(xfrma[XFRMA_REPLAY-1]) {
>+                struct xfrm_replay_state *replay;
>+                replay = RTA_DATA(xfrma[XFRMA_REPLAY - 1]);
>+                x->replay = *replay;
>+        }
>+
> 	err = -ENOENT;
> 	x->type = xfrm_get_type(x->id.proto, x->props.family);
> 	if (x->type == NULL)
>@@ -368,6 +375,8 @@
> 	if (x->encap)
> 		RTA_PUT(skb, XFRMA_ENCAP, sizeof(*x->encap), x->encap);
> 
>+	RTA_PUT(skb, XFRMA_REPLAY, sizeof(x->replay), &x->replay);
>+
> 	nlh->nlmsg_len = skb->tail - b;
> out:
> 	sp->this_idx++;
>@@ -852,6 +861,27 @@
> 	return 0;
> }
> 
>+static int xfrm_update_seq(struct sk_buff *skb, struct nlmsghdr *nlh, void **xfrma)
>+{
>+        struct xfrm_state *x;
>+        struct xfrm_usersa_id *p = NLMSG_DATA(nlh);
>  
>
>+	struct xfrm_replay_state *replay;
>+ 
>+	x = xfrm_state_lookup(&p->daddr, p->spi, p->proto, p->family);
>+        if (x == NULL) {
>+		printk(KERN_INFO "Found no xfrm state for sa seq update\n");
>+                return -ESRCH;
>+		}
>+
>+	if(xfrma[XFRMA_REPLAY-1]) {
>+		replay = RTA_DATA(xfrma[XFRMA_REPLAY - 1]);
>+		x->replay = *replay;
>  
>
>+		}
>+	else return -EINVAL;
>  
>
^^ leaks xfrm_state reference

>+		
>+	return 0;
>  
>
^^ same here

>+} 
>+
> static const int xfrm_msg_min[(XFRM_MSG_MAX + 1 - XFRM_MSG_BASE)] = {
> 	NLMSG_LENGTH(sizeof(struct xfrm_usersa_info)),	/* NEW SA */
> 	NLMSG_LENGTH(sizeof(struct xfrm_usersa_id)),	/* DEL SA */
>@@ -867,6 +897,7 @@
> 	NLMSG_LENGTH(sizeof(struct xfrm_user_polexpire)), /* POLEXPIRE */
> 	NLMSG_LENGTH(sizeof(struct xfrm_usersa_flush)),	/* FLUSH SA */
> 	NLMSG_LENGTH(0),				/* FLUSH POLICY */
>+	NLMSG_LENGTH(sizeof(struct xfrm_usersa_id)),/* UPD SEQ */
>  
>
^^ what about struct xfrm_replay_state ?

  reply	other threads:[~2004-11-04 18:15 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-29 10:23 [RFC] IPSEC failover and replay detection sequence numbers KOVACS Krisztian
2004-10-29 12:58 ` jamal
2004-10-29 13:24   ` KOVACS Krisztian
2004-10-29 15:01     ` jamal
2004-10-29 16:15       ` KOVACS Krisztian
2004-11-07 17:42   ` Michael Richardson
2004-11-04 14:01 ` [Vpn-failover] [RFC] IPSEC failover - Netlink part Ulrich Weber
2004-11-04 18:15   ` Patrick McHardy [this message]
2004-11-08 10:31     ` Ulrich Weber
2004-11-08 16:10       ` Patrick McHardy
2004-11-09  8:55         ` Ulrich Weber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=418A71DA.2090607@trash.net \
    --to=kaber@trash.net \
    --cc=ipsec-tools-devel@lists.sourceforge.net \
    --cc=netdev@oss.sgi.com \
    --cc=uweber@astaro.de \
    --cc=vpn-failover@lists.balabit.hu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.