On Fri, Nov 04, 2022 at 06:18:35PM +0100, Sriram Yagnaraman wrote:
> Changes since v2:
> - Abandoned the sctp no_random_port patch from the series
>
> SCTP conntrack currently assumes that the SCTP endpoints will
> probe secondary paths using HEARTBEAT before sending traffic.
>
> But, according to RFC 9260, SCTP endpoints can send any traffic
> on any of the confirmed paths after SCTP association is up.
> SCTP endpoints that sends INIT will confirm all peer addresses
> that upper layer configures, and the SCTP endpoint that receives
> COOKIE_ECHO will only confirm the address it sent the INIT_ACK to.
>
> So, we can have a situation where the INIT sender can start to
> use secondary paths without the need to send HEARTBEAT. This patch
> allows DATA/SACK packets to create new connection tracking entry.
>
> A new state has been added to indicate that a DATA/SACK chunk has
> been seen in the original direction - SCTP_CONNTRACK_DATA_SENT.
> State transitions mostly follows the HEARTBEAT_SENT, except on
> receiving HEARTBEAT/HEARTBEAT_ACK/DATA/SACK in the reply direction.
>
> State transitions in original direction:
> - DATA_SENT behaves similar to HEARTBEAT_SENT for all chunks,
> except that it remains in DATA_SENT on receving HEARTBEAT,
> HEARTBEAT_ACK/DATA/SACK chunks
> State transitions in reply direction:
> - DATA_SENT behaves similar to HEARTBEAT_SENT for all chunks,
> except that it moves to HEARTBEAT_ACKED on receiving
> HEARTBEAT/HEARTBEAT_ACK/DATA/SACK chunks
>
> Note: This patch still doesn't solve the problem when the SCTP
> endpoint decides to use primary paths for association establishment
> but uses a secondary path for association shutdown. We still have
> to depend on timeout for connections to expire in such a case.
Applied, thanks
One request of mine: Would you send a patch to extend
Documentation/networking/nf_conntrack-sysctl.rst
to document sctp timeouts?
Thanks.
