sctplab / pr-sctp-improved Goto Github PK

An INIT-Chunk with an cropped FORWARD-TSN-supported parameter (2 bytes instead of 4 bytes) is accepted by the FreeBSD-Kernel and results in sending an INIT-ACK-Chunk instead of an expected ABORT-Chunk.

See the folloing test-case for more details:

• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/error-cases/init-with-forward-tsn-too-short.pkt

When an endpoints wants to use the user message interleaving and activates it by calling:

+0.0 setsockopt(3, IPPROTO_SCTP, SCTP_FRAGMENT_INTERLEAVE, [2], 4) = 0
+0.0 setsockopt(3, IPPROTO_SCTP, SCTP_INTERLEAVING_SUPPORTED, {assoc_value=1}, 8) = 0

after receiving an INIT-Chunk like:

INIT[flgs=0, tag=1, a_rwnd=1500, os=16, is=16, tsn=1, FORWARD_TSN_SUPPORTED[], SUPPORTED_EXTENSIONS[types=[FORWARD_TSN, I_DATA]]]

and completing the handshake, it uses the I-DATA-Chunk, which should be acceptable, because of section 2.2.1. of sctp-ndata internet draft:

A sender MUST NOT send an I-DATA chunk unless both peers have
indicated its support of the I-DATA chunk type within the Supported
Extensions Parameter as defined in [RFC5061]. If I-DATA support has
been negotiated on an association, I-DATA chunks MUST be used for all
user messages and DATA-chunk MUST NOT be used. If I-DATA support has
not been negotiated on an association, DATA chunks MUST be used for
all user messages and I-DATA chunks MUST NOT be used.

If one outstanding user message is abandoned it uses the I-FORWARD-TSN-Chunk that the other endpoint does not support. It should use the FORWARD-TSN-Chunk i assume. See the following test-case for more details:

• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/i-forward-tsn/handshake-with-i-forward-tsn/handshake-with-i-forward-tsn-9.pkt
• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/i-forward-tsn/handshake-with-i-forward-tsn/handshake-with-i-forward-tsn-14.pkt

When an invalid FORWARD-TSN-Chunk where the physical length is 8 bytes but the length in the tlv-header is set to 12 bytes (too long) no ABORT-Chunk is sent.

See the following test-case for more details:

• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/error-cases/forward-tsn-tlv-too-long.pkt

When an INIT-Chunk is injected with an FORWARD-TSN-Supported parameter but an invalid tlv-length (too short) the invalid and inconsistent INIT-Chunk is processed and an INIT-ACK-Chunk is sent instead of an expected ABORT-Chunk.

See the following test cases for more details:

• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/error-cases/init-with-forward-tsn-tlv-too-short.pkt

In the following test cases the sender should ideally bundle the outstanding DATA and FORWARD-TSN-Chunk into one packet, because the DATA-Chunk does not exceed the MTU and could be bundled with an FORWARD-TSN-Chunk:

• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/sender-side-implementation/ttl-policy/sender-side-implementation-4.pkt
• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/sender-side-implementation/ttl-policy/sender-side-implementation-7_1.pkt
• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/sender-side-implementation/limited-retransmission/sender-side-implementation-4.pkt

When both endpoints have listed NR-SACK-Chunks at the supported extensions in the INIT and INIT-ACK-Chunks incoming SACK-Chunks are accepted by the FreeBSD-Kernel-Implementation. At the internet draft "Load Sharing for the Stream Control Transmission Protocol (SCTP)" i was not be able to find any information on how to handle those situations (see https://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-multipath-12#page-6). There is although one paragraph stating:

Once both endpoints indicate during association establishment that
they support the NR-SACK extension, each endpoint SHOULD acknowledge
received DATA chunks with NR-SACK chunks, and not SACK chunks. That
is, throughout an SCTP association, both endpoints SHOULD send either
SACK chunks or NR-SACK chunks, never a mixture of the two.

See the following test cases fore more details:

• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/nr-sack/handshake-with-nr-sack/handshake-with-nr-sack-7.pkt
• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/nr-sack/handshake-with-nr-sack/handshake-with-nr-sack-8.pkt

When two not fragmented user messages are sent and the cwnd only allows one outstanding I_DATA-Chunk the second user message should be discarded if it has already been abandoned by a PR-SCTP-Policy (for example the ttl has expired).

The current FreeBSD-Implementation still tries to deliver the already abandoned second user message after the first user message has been abandoned by sending a I_FORWARD-TSN for the first user message and then sending a I_DATA-Chunk for the already abandoned second user message.

See the following test case for more details:

• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/i-forward-tsn/sender-side-implementation/ttl-policy/sender-side-implementation-6.pkt

When an INIT_ACK-Chunk like

INIT_ACK[flgs=0, tag=2, a_rwnd=1500, os=16, is=16, tsn=1, STATE_COOKIE[len=4, val=...], FORWARD_TSN_SUPPORTED[]]

is injected and PR-SCTP-Support is disabled at FreeBSD, it is not listed at the unrecognized parameters at the COOKIE_ECHO-Chunk. See the following test-cases for more details:

• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/handshake-with-forward-tsn/handshake-with-forward-tsn-3.pkt
• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/i-forward-tsn/handshake-with-i-forward-tsn/handshake-with-i-forward-tsn-3.pkt

When an INIT-Chunk like

INIT[flgs=0, tag=1, a_rwnd=1500, os=1, is=1, tsn=0, FORWARD_TSN_SUPPORTED[], SUPPORTED_EXTENSIONS[types=[FORWARD_TSN, I_FORWARD_TSN]]]

in injected and later after the handshake is completed the following I-FORWARD-TSN-Chunk is injected:

I_FORWARD_TSN[cum_tsn=1, ids=[]]

the FreeBSD-Implementation sends an SACK-Chunk instead of an ERROR-Chunk.

In section 2.3.1. of the internet draft "Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol" it says:

Support for the I-FORWARD-TSN chunk is negotiated during the SCTP
association setup via the Supported Extensions Parameter as defined
in [RFC5061]. Only if both end points support the I-DATA chunk and
the I-FORWARD-TSN chunk, the partial reliability extension can be
used in combination with user message interleaving.

See the following test-case for more details:

• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/i-forward-tsn/handshake-with-i-forward-tsn/handshake-with-i-forward-tsn-5.pkt

FreeBSD does not seem to react to any FORWARD-TSN-Chunks received before any DATA chunks. Only after one DATA-Chunk was processed, there seems to be a reaction to incoming FORWARD-TSN-Chunks. See the following failing (more specific: they are hanging, because the kernel does not send a SACK-Chunk) packetdrill tests for details:

• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/packetdrill-tests/receiver-side-implementation/receiver-side-implementation-1.pkt
• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/packetdrill-tests/receiver-side-implementation/receiver-side-implementation-3.pkt
• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/packetdrill-tests/receiver-side-implementation/receiver-side-implementation-5.pkt
• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/packetdrill-tests/receiver-side-implementation/receiver-side-implementation-6.pkt

In the test-case https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/sender-side-implementation/ttl-policy/sender-side-implementation-7_1.pkt the FORWARD-TSN-Chunk in line 84 is not transmitted like expected at the relative time +2.0 seconds after the first retransmission.

Currently the test-case also fails, because the FORWARD-TSN-Chunk is not bundled with the still outstanding DATA-Chunk in line 81. This Issue is therefore related to #5.

This is the same problem like #5 but for I-DATA and I-FORWARD-TSN-Chunks.

See the following test case for more details:

• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/i-forward-tsn/sender-side-implementation/ttl-policy/sender-side-implementation-4.pkt

When there are multiple outstanding DATA-Chunks of one fragmented ordered user message the current FreeBSD-Kernel reports each outstanding DATA-Chunk sid/ssn value in an sent FORWARD-TSN Chunk if the fragmented ordered user message is abandoned.

Ideally it should only report the sid/ssn value once in the FORWARD-TSN Chunk, because if there are multiple fragmented DATA-Chunks outstanding the FORWARD-TSN Chunk gets filled with duplicate sid/ssn values.

See the following test cases for more details:

• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/sender-side-implementation/ttl-policy/sender-side-implementation-1.pkt
• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/sender-side-implementation/limited-retransmission/sender-side-implementation-1.pkt
• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/i-forward-tsn/sender-side-implementation/ttl-policy/sender-side-implementation-1.pkt

In the following test-case three unordered user messages with two fragments are outstanding and only the DATA-Chunk with E-Flag set has arrived the IUT. Then the third user message is completed with a DATA-Chunk and the first and second user message is abandoned by sending two bundled FORWARD-TSN-Chunks.

After that the sctp_recvmsg call fails and does not deliver the third message to the userland application. See the following test case for more details:

• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/receiver-side-implementation/packet-loss/unordered/unordered-packet-loss-13.pkt

In the following test-cases sctp_recvmsg fails under FreeBSD if two (or more) user messages arrived the implementation out of order. When some fragments of an outstanding user message are missing, the following user messages are not delivered to the userland application.

For example if tsn=2,3,4 of two user messages (first message got tsn=1, 2 second user message got tsn=3, 4) are received and tsn=1 are missing the kernel does not deliver the complete second user message (tsn=3,4).

See the following test-cases for more details:

• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/receiver-side-implementation/packet-loss/unordered/unordered-packet-loss-6.pkt
• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/receiver-side-implementation/packet-loss/unordered/unordered-packet-loss-7.pkt
• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/receiver-side-implementation/packet-loss/unordered/unordered-packet-loss-11.pkt
• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/receiver-side-implementation/packet-loss/unordered/unordered-packet-loss-14.pkt

When an association uses NR-SACK-Chunks and support for PR-SCTP is enabled when sending three user messages where the first and third have a ttl of 500ms and the second user message must be delivered, the FreeBSD-Implemention does not use the information of an incoming NR-SACK-Chunk where in the nr_gap-Block the second user message is acknowledged non regenable.

It should ideally send an FORWARD-TSN with cum_tsn=3. See the following test cases for more details:

• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/nr-sack/with-forward-tsn/with-forward-tsn-2.pkt
• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/nr-sack/with-forward-tsn/with-forward-tsn-3.pkt

In the following test-case after calling close the FreeBSD-Kernel sends an ABORT-Chunk instead of an expected SHUTDOWN-Chunk:

• https://github.com/nplab/PR_SCTP_Testsuite/blob/master/i-forward-tsn/receiver-side-implementation/receiver-side-implementation-11.pkt

In the following test-case https://github.com/nplab/PR_SCTP_Testsuite/blob/master/nr-sack/with-forward-tsn/with-forward-tsn-5.pkt after calling close no SHUTDOWN-Chunk is sent by the IUT. 300 seconds after calling close an ABORT-Chunk is sent by IUT which is not expected.