Bug #15924
openSCTP states not purged causing subsequent SCTP INIT to be blocked
0%
Description
The current code transitions the state to CLOSING upon receiving an ABORT.
The firewall state should instead transition to CLOSED immediately upon receiving a correctly formatted ABORT chunk.
Updated by Oliver Thomas 5 days ago
The issue is in SCTP state handling added in FreeBSD D42393 - https://reviews-dev.freebsd.org/D42393
The SCTP ABORT mechanism is not handled correctly by the state handling in src/sys/netpfil/pf/pf.c - function pf_test_state_sctp
In the current code, when an ABORT chunk is received on an association, the state moves to 'CLOSING'.
However, the RFC (RFC4960 section 3.3.7) is clear on the expected behaviour on receipt of an ABORT:
“under any circumstances, an endpoint that receives an ABORT MUST NOT respond to that ABORT by sending an ABORT of its own.”
Basically, an ABORT kills an association immediately with no acknowledgement allowed.
This is in contrast to the SHUTDOWN which should be replied to with SHUTDOWN_COMPLETE.
In terms of firewall states, this means that the state should move to CLOSED immediately upon receipt of a correctly formatted ABORT chunk.
For example, in src/sys/netpfil/pf/pf.c - function pf_test_state_sctp, the following conditional statement should not include the ABORT:
if (pd->sctp_flags & (PFDESC_SCTP_SHUTDOWN | PFDESC_SCTP_ABORT |
PFDESC_SCTP_SHUTDOWN_COMPLETE)) {
And the following conditional statement should include PFDESC_SCTP_ABORT:
if (pd->sctp_flags & (PFDESC_SCTP_SHUTDOWN_COMPLETE)) {
Updated by Kristof Provost about 20 hours ago
- Status changed from New to In Progress
- Assignee set to Kristof Provost
Thanks. That makes sense. I've pushed that into FreeBSD and it'll turn up in our tree on the next upstream merge. That may or may not be this week, but will be before the next release in any event.