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). 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)?
