From: Marcelo Ricardo Leitner <marcelo.leitner-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Michal Kubecek <mkubecek-AlSwsSmVLrQ@public.gmane.org>
Cc: Florian Westphal <fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org>,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
coreteam-Cap9r6Oaw4JrovVCs/uTlw@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Pablo Neira Ayuso <pablo-Cap9r6Oaw4JrovVCs/uTlw@public.gmane.org>,
Patrick McHardy <kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>,
Jozsef Kadlecsik
<kadlec-K40Dz/62t/MgiyqX0sVFJYdd74u8MsAO@public.gmane.org>,
"David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Subject: Re: [PATCH nf-next] netfilter: nf_ct_sctp: minimal multihoming support
Date: Thu, 16 Jul 2015 10:18:40 -0300 [thread overview]
Message-ID: <20150716131839.GA21634@localhost.localdomain> (raw)
In-Reply-To: <20150716120512.GA7200-OEaqT8BN2ewCVLCxKZUutA@public.gmane.org>
On Thu, Jul 16, 2015 at 02:05:12PM +0200, Michal Kubecek wrote:
> On Wed, Jul 15, 2015 at 05:35:08PM -0300, Marcelo Ricardo Leitner wrote:
> > Hi,
> >
> > On Tue, Jul 14, 2015 at 06:42:25PM +0200, Michal Kubecek wrote:
> > > On Tue, Jul 14, 2015 at 03:42:03PM +0200, Florian Westphal wrote:
> > > > Michal Kubecek <mkubecek-AlSwsSmVLrQ@public.gmane.org> wrote:
> > > > > + case SCTP_CID_HEARTBEAT:
> > > > > + pr_debug("SCTP_CID_HEARTBEAT");
> > > > > + i = 9;
> > > > > + break;
> > > > > + case SCTP_CID_HEARTBEAT_ACK:
> > > > > + pr_debug("SCTP_CID_HEARTBEAT_ACK");
> > > > > + i = 10;
> > > > > + break;
> > > > > default:
> > > > > /* Other chunks like DATA, SACK, HEARTBEAT and
> > > > > its ACK do not cause a change in state */
> > > > > @@ -329,6 +351,8 @@ static int sctp_packet(struct nf_conn *ct,
> > > > > !test_bit(SCTP_CID_COOKIE_ECHO, map) &&
> > > > > !test_bit(SCTP_CID_ABORT, map) &&
> > > > > !test_bit(SCTP_CID_SHUTDOWN_ACK, map) &&
> > > > > + !test_bit(SCTP_CID_HEARTBEAT, map) &&
> > > > > + !test_bit(SCTP_CID_HEARTBEAT_ACK, map) &&
> > > > > sh->vtag != ct->proto.sctp.vtag[dir]) {
> > > > > pr_debug("Verification tag check failed\n");
> > > > > goto out;
> > > > > @@ -357,6 +381,16 @@ static int sctp_packet(struct nf_conn *ct,
> > > > > /* Sec 8.5.1 (D) */
> > > > > if (sh->vtag != ct->proto.sctp.vtag[dir])
> > > > > goto out_unlock;
> > > > > + } else if (sch->type == SCTP_CID_HEARTBEAT ||
> > > > > + sch->type == SCTP_CID_HEARTBEAT_ACK) {
> > > > > + if (ct->proto.sctp.vtag[dir] == 0) {
> > > > > + pr_debug("Setting vtag %x for dir %d\n",
> > > > > + sh->vtag, dir);
> > > > > + ct->proto.sctp.vtag[dir] = sh->vtag;
> > > >
> > > > Could you please elaborate on the [dir] == 0 test?
> > > >
> > > > I see this might happen for SCTP_CID_HEARTBEAT_ACK, but why is this
> > > > needed for SCTP_CID_HEARTBEAT ?
> > > >
> > > > We found a conntrack entry so shouldn't the vtag[dir] already be > 0?
> > >
> > > Yes, you are right. This was originally intended to handle the case when
> > > a HEARTBEAT in the reply direction is seen before the HEARTBEAT-ACK but
> > > such HEARTBEAT would be dropped anyway in current version.
> >
> > And we have to keep the first vtag attempted because otherwise an
> > attacker could just probe for the right one until she gets a reply.
> >
> > IOW, if a different vtag is attempted, we should drop it as the packet
> > doesn't belong to that association/conntrack entry.
> >
> > As vtags are always != 0 in such case, that's a way to know if we
> > already have that information or not.
> >
> > > On the other hand, an alternative would be
> > >
> > > } else if (sch->type == SCTP_CID_HEARTBEAT_ACK &&
> > > ct->proto.sctp.vtag[dir] == 0) {
> > > pr_debug("Setting vtag %x for dir %d\n",
> > > sh->vtag, dir);
> > > ct->proto.sctp.vtag[dir] = sh->vtag;
> > > } else if ((sch->type == SCTP_CID_HEARTBEAT ||
> > > sch->type == SCTP_CID_HEARTBEAT_ACK) &&
> > > sh->vtag != ct->proto.sctp.vtag[dir]) {
> > > pr_debug("Verification tag check failed\n");
> > > goto out_unlock;
> > > }
> > >
> > > I'm not sure it looks better.
> >
> > Now it seems swapped, we should save the tag on HB and check on
> > HB_ACK only and would have to check against !dir entry. Like:
>
> I forgot to include the explanation of vtag setting/checking logic into
> the commit message. It is supposed to work like this:
>
> Normally, vtag is set from the INIT chunk for the reply direction and
> from the INIT-ACK chunk for the originating direction (i.e. each of
> these defines vtag value for the opposite direction). For secondary
Erf, indeed. I totally confused it and thought they would be equal on
both directions.
> conntracks, we can't rely on seeing INIT/INIT-ACK and even if we have
> seen them, we would need to connect two different conntracks. Therefore
> simplified logic is applied: vtag of first packet in each direction
> (HEARTBEAT in the originating and HEARTBEAT-ACK in reply direction) is
> saved and all following packets in that direction are compared with this
> saved value. While INIT and INIT-ACK define vtag for the opposite
> direction (that's where "!dir" comes from), vtags extracted from
> HEARTBEAT and HEARTBEAT-ACK are always for their direction. And we have
> to check vtags on packets with HEARTBEAT chunks as well because their
> vtags should match vtag of the first (set in sctp_new()).
Yes, that's pretty much it. Original code reads better here then.
Thanks,
Marcelo
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Michal Kubecek <mkubecek@suse.cz>
Cc: Florian Westphal <fw@strlen.de>,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
linux-api@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
Pablo Neira Ayuso <pablo@netfilter.org>,
Patrick McHardy <kaber@trash.net>,
Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH nf-next] netfilter: nf_ct_sctp: minimal multihoming support
Date: Thu, 16 Jul 2015 10:18:40 -0300 [thread overview]
Message-ID: <20150716131839.GA21634@localhost.localdomain> (raw)
In-Reply-To: <20150716120512.GA7200@unicorn.suse.cz>
On Thu, Jul 16, 2015 at 02:05:12PM +0200, Michal Kubecek wrote:
> On Wed, Jul 15, 2015 at 05:35:08PM -0300, Marcelo Ricardo Leitner wrote:
> > Hi,
> >
> > On Tue, Jul 14, 2015 at 06:42:25PM +0200, Michal Kubecek wrote:
> > > On Tue, Jul 14, 2015 at 03:42:03PM +0200, Florian Westphal wrote:
> > > > Michal Kubecek <mkubecek@suse.cz> wrote:
> > > > > + case SCTP_CID_HEARTBEAT:
> > > > > + pr_debug("SCTP_CID_HEARTBEAT");
> > > > > + i = 9;
> > > > > + break;
> > > > > + case SCTP_CID_HEARTBEAT_ACK:
> > > > > + pr_debug("SCTP_CID_HEARTBEAT_ACK");
> > > > > + i = 10;
> > > > > + break;
> > > > > default:
> > > > > /* Other chunks like DATA, SACK, HEARTBEAT and
> > > > > its ACK do not cause a change in state */
> > > > > @@ -329,6 +351,8 @@ static int sctp_packet(struct nf_conn *ct,
> > > > > !test_bit(SCTP_CID_COOKIE_ECHO, map) &&
> > > > > !test_bit(SCTP_CID_ABORT, map) &&
> > > > > !test_bit(SCTP_CID_SHUTDOWN_ACK, map) &&
> > > > > + !test_bit(SCTP_CID_HEARTBEAT, map) &&
> > > > > + !test_bit(SCTP_CID_HEARTBEAT_ACK, map) &&
> > > > > sh->vtag != ct->proto.sctp.vtag[dir]) {
> > > > > pr_debug("Verification tag check failed\n");
> > > > > goto out;
> > > > > @@ -357,6 +381,16 @@ static int sctp_packet(struct nf_conn *ct,
> > > > > /* Sec 8.5.1 (D) */
> > > > > if (sh->vtag != ct->proto.sctp.vtag[dir])
> > > > > goto out_unlock;
> > > > > + } else if (sch->type == SCTP_CID_HEARTBEAT ||
> > > > > + sch->type == SCTP_CID_HEARTBEAT_ACK) {
> > > > > + if (ct->proto.sctp.vtag[dir] == 0) {
> > > > > + pr_debug("Setting vtag %x for dir %d\n",
> > > > > + sh->vtag, dir);
> > > > > + ct->proto.sctp.vtag[dir] = sh->vtag;
> > > >
> > > > Could you please elaborate on the [dir] == 0 test?
> > > >
> > > > I see this might happen for SCTP_CID_HEARTBEAT_ACK, but why is this
> > > > needed for SCTP_CID_HEARTBEAT ?
> > > >
> > > > We found a conntrack entry so shouldn't the vtag[dir] already be > 0?
> > >
> > > Yes, you are right. This was originally intended to handle the case when
> > > a HEARTBEAT in the reply direction is seen before the HEARTBEAT-ACK but
> > > such HEARTBEAT would be dropped anyway in current version.
> >
> > And we have to keep the first vtag attempted because otherwise an
> > attacker could just probe for the right one until she gets a reply.
> >
> > IOW, if a different vtag is attempted, we should drop it as the packet
> > doesn't belong to that association/conntrack entry.
> >
> > As vtags are always != 0 in such case, that's a way to know if we
> > already have that information or not.
> >
> > > On the other hand, an alternative would be
> > >
> > > } else if (sch->type == SCTP_CID_HEARTBEAT_ACK &&
> > > ct->proto.sctp.vtag[dir] == 0) {
> > > pr_debug("Setting vtag %x for dir %d\n",
> > > sh->vtag, dir);
> > > ct->proto.sctp.vtag[dir] = sh->vtag;
> > > } else if ((sch->type == SCTP_CID_HEARTBEAT ||
> > > sch->type == SCTP_CID_HEARTBEAT_ACK) &&
> > > sh->vtag != ct->proto.sctp.vtag[dir]) {
> > > pr_debug("Verification tag check failed\n");
> > > goto out_unlock;
> > > }
> > >
> > > I'm not sure it looks better.
> >
> > Now it seems swapped, we should save the tag on HB and check on
> > HB_ACK only and would have to check against !dir entry. Like:
>
> I forgot to include the explanation of vtag setting/checking logic into
> the commit message. It is supposed to work like this:
>
> Normally, vtag is set from the INIT chunk for the reply direction and
> from the INIT-ACK chunk for the originating direction (i.e. each of
> these defines vtag value for the opposite direction). For secondary
Erf, indeed. I totally confused it and thought they would be equal on
both directions.
> conntracks, we can't rely on seeing INIT/INIT-ACK and even if we have
> seen them, we would need to connect two different conntracks. Therefore
> simplified logic is applied: vtag of first packet in each direction
> (HEARTBEAT in the originating and HEARTBEAT-ACK in reply direction) is
> saved and all following packets in that direction are compared with this
> saved value. While INIT and INIT-ACK define vtag for the opposite
> direction (that's where "!dir" comes from), vtags extracted from
> HEARTBEAT and HEARTBEAT-ACK are always for their direction. And we have
> to check vtags on packets with HEARTBEAT chunks as well because their
> vtags should match vtag of the first (set in sctp_new()).
Yes, that's pretty much it. Original code reads better here then.
Thanks,
Marcelo
next prev parent reply other threads:[~2015-07-16 13:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-14 12:23 [PATCH nf-next] netfilter: nf_ct_sctp: minimal multihoming support Michal Kubecek
2015-07-14 12:23 ` Michal Kubecek
[not found] ` <20150714122311.8DA8EA0C9A-OEaqT8BN2ewCVLCxKZUutA@public.gmane.org>
2015-07-14 13:42 ` Florian Westphal
2015-07-14 13:42 ` Florian Westphal
2015-07-14 16:42 ` Michal Kubecek
2015-07-15 20:35 ` Marcelo Ricardo Leitner
2015-07-16 12:05 ` Michal Kubecek
[not found] ` <20150716120512.GA7200-OEaqT8BN2ewCVLCxKZUutA@public.gmane.org>
2015-07-16 13:18 ` Marcelo Ricardo Leitner [this message]
2015-07-16 13:18 ` Marcelo Ricardo Leitner
2015-07-14 15:38 ` Pablo Neira Ayuso
2015-07-14 15:38 ` Pablo Neira Ayuso
2015-07-14 16:28 ` Michal Kubecek
[not found] ` <20150714162850.GA8478-OEaqT8BN2ewCVLCxKZUutA@public.gmane.org>
2015-07-15 16:45 ` Pablo Neira Ayuso
2015-07-15 16:45 ` Pablo Neira Ayuso
2015-07-16 13:50 ` Marcelo Ricardo Leitner
[not found] ` <20150716135059.GB14704-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2015-07-16 16:13 ` Michal Kubecek
2015-07-16 16:13 ` Michal Kubecek
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=20150716131839.GA21634@localhost.localdomain \
--to=marcelo.leitner-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=coreteam-Cap9r6Oaw4JrovVCs/uTlw@public.gmane.org \
--cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
--cc=fw-HFFVJYpyMKqzQB+pC5nmwQ@public.gmane.org \
--cc=kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org \
--cc=kadlec-K40Dz/62t/MgiyqX0sVFJYdd74u8MsAO@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mkubecek-AlSwsSmVLrQ@public.gmane.org \
--cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=netfilter-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=pablo-Cap9r6Oaw4JrovVCs/uTlw@public.gmane.org \
/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.