On Thu, Jan 05, 2023 at 12:11:44PM +0000, Sriram Yagnaraman wrote: > > -----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. 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.
