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 ?
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).