The Forward-TSN-supported parameter is not listed at the unrecognized parameters

[TheAomx]

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

[stewrtrs]

why would it be unrecognized? The O/S knows what it is, its just been disabled. As long as its not responded saying “I do PR-SCTP” I don’t see an issue R

…

On Dec 12, 2016, at 10:32 AM, TheAomx ***@***.***> wrote: When an INIT-Chunk like this: 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/handshake-with-forward-tsn/handshake-with-forward-tsn-3.pkt — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

-------- Randall Stewart [email protected] 803-317-4952

[TheAomx]

Section 3.3.2. of RFC 3758:

When a receiver of an INIT-ACK detects a Forward-TSN-Supported
parameter and it does not support the Forward-TSN chunk type, the
receiver MUST follow the rules defined in Section 3.3.3 of RFC 2960
[2].

The Linux Implementation does follow this rule if the extension has only been disabled with sysctl...

[tuexen]

Hi Randy,

I reacted exactly as you.

But we/someone wrote in RFC3758:

Note that if the endpoint chooses NOT to include the parameter, then
at no time during the life of the association can it send or process
a FORWARD TSN.  It MUST instead act as if it does NOT support the
FORWARD TSN chunk, returning an ERROR to the peer upon receipt of any
FORWARD TSN.

in addition to

When a receiver of an INIT detects a Forward-TSN-Supported parameter
and does not support the Forward-TSN chunk type, the receiver MUST
follow the rules defined in Section 3.3.3 of RFC 2960 [2].

This text is not as I would expect, but it is pretty clear... What do you think?

[stewrtrs]

Interesting :) I guess we need to fix it then :D R

…

On Dec 12, 2016, at 10:45 AM, Michael Tüxen ***@***.***> wrote: Hi Randy, I reacted exactly as you. But we/someone wrote in RFC3758: Note that if the endpoint chooses NOT to include the parameter, then at no time during the life of the association can it send or process a FORWARD TSN. It MUST instead act as if it does NOT support the FORWARD TSN chunk, returning an ERROR to the peer upon receipt of any FORWARD TSN. in addition to When a receiver of an INIT detects a Forward-TSN-Supported parameter and does not support the Forward-TSN chunk type, the receiver MUST follow the rules defined in Section 3.3.3 of RFC 2960 [2]. This text is not as I would expect, but it is pretty clear... What do you think? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

-------- Randall Stewart [email protected] 803-317-4952