Re: [RFC PATCH] netfilter: conntrack: simplify sctp state machine

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Thu, Jan 05, 2023 at 12:11:44PM +0000, Sriram Yagnaraman wrote:
> > -----Original Message-----
> > From: Pablo Neira Ayuso <pablo@netfilter.org>
> > Sent: Thursday, 5 January 2023 12:54
> > To: Sriram Yagnaraman <sriram.yagnaraman@est.tech>
> > Cc: netfilter-devel@vger.kernel.org; Florian Westphal <fw@strlen.de>;
> > Marcelo Ricardo Leitner <mleitner@redhat.com>; Long Xin
> > <lxin@redhat.com>; Claudio Porfiri <claudio.porfiri@ericsson.com>
> > Subject: Re: [RFC PATCH] netfilter: conntrack: simplify sctp state machine
> > 
> > On Thu, Jan 05, 2023 at 11:41:13AM +0000, Sriram Yagnaraman wrote:
> > > > -----Original Message-----
> > > > From: Pablo Neira Ayuso <pablo@netfilter.org>
> > > > Sent: Wednesday, 4 January 2023 16:02
> > > > To: Sriram Yagnaraman <sriram.yagnaraman@est.tech>
> > > > Cc: netfilter-devel@vger.kernel.org; Florian Westphal
> > > > <fw@strlen.de>; Marcelo Ricardo Leitner <mleitner@redhat.com>; Long
> > > > Xin <lxin@redhat.com>
> > > > Subject: Re: [RFC PATCH] netfilter: conntrack: simplify sctp state
> > > > machine
> > > >
> > > > On Wed, Jan 04, 2023 at 12:31:43PM +0100, Sriram Yagnaraman wrote:
> > > > > All the paths in an SCTP connection are kept alive either by
> > > > > actual DATA/SACK running through the connection or by HEARTBEAT.
> > > > > This patch proposes a simple state machine with only two states
> > > > > OPEN_WAIT and ESTABLISHED (similar to UDP). The reason for this
> > > > > change is a full stateful approach to SCTP is difficult when the
> > > > > association is multihomed since the endpoints could use different
> > > > > paths in the network during the lifetime of an association.
> > > >
> > > > Do you mean the router/firewall might not see all packets for
> > > > association is multihomed?
> > > >
> > > > Could you please provide an example?
> > >
> > > Let's say the primary and alternate/secondary paths between the SCTP
> > > endpoints traverse different middle boxes. If an SCTP endpoint detects
> > > network failure on the primary path, it will switch to using the
> > > secondary path and all subsequent packets will not be seen by the
> > > middlebox on the primary path, including SHUTDOWN sequences if they
> > > happen at that time.
> > 
> > OK, then on the primary middle box the SCTP flow will just timeout?
> > (because no more packets are seen).
> 
> Yes, they will timeout unless the primary path comes up before the
> SHUTDOWN sequence. And the default timeout for an ESTABLISHED SCTP
> connection is 5 days, which is a "long" time to clean-up this entry.

Does the middle box have a chance to see any packet that provides a
hint to shorten this timeout? no HEARTBEAT packets are seen in this
case on the former primary path?

What I am missing are a more detailed list of issues with the existing
approach. Your patch description says "SCTP tracking with multihoming
is difficult", probably a list of scenarios would help to understand
the motivation to simplify the state machine.

Thanks.