> -----Original Message-----
> From: Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx>
> Sent: Thursday, 5 January 2023 12:54
> To: Sriram Yagnaraman <sriram.yagnaraman@xxxxxxxx>
> Cc: netfilter-devel@xxxxxxxxxxxxxxx; Florian Westphal <fw@xxxxxxxxx>;
> Marcelo Ricardo Leitner <mleitner@xxxxxxxxxx>; Long Xin
> <lxin@xxxxxxxxxx>; Claudio Porfiri <claudio.porfiri@xxxxxxxxxxxx>
> 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@xxxxxxxxxxxxx>
> > > Sent: Wednesday, 4 January 2023 16:02
> > > To: Sriram Yagnaraman <sriram.yagnaraman@xxxxxxxx>
> > > Cc: netfilter-devel@xxxxxxxxxxxxxxx; Florian Westphal
> > > <fw@xxxxxxxxx>; Marcelo Ricardo Leitner <mleitner@xxxxxxxxxx>; Long
> > > Xin <lxin@xxxxxxxxxx>
> > > 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.
>
> Or the scenario you describe is this? Assuming a middle box that is an
> alternate/secondary path, then such middle box (which did not see any other
> packets before for this connection) starts seeing packets for this flow, so
> packets are dropped by the secondary middle box (which now became the
> primary path after the network failure)?
With d7ee35190427 ("netfilter: nf_ct_sctp: minimal multihoming support") and bff3d0534804 ("netfilter: conntrack: add sctp DATA_SENT state ") there is some multihoming support, so secondary middleboxes should have an entry already. SCTP endpoints can send packets to secondary transport addresses according to the RFC, and they do path monitoring of secondary paths using HEARTBEAT when needed.
