Issue with handling too long FORWARD-TSN-SUPPORTED parameter in INIT chunk
An INIT-chunk with a FORWARD-TSN-SUPPORTED parameter having a length of 8 bytes is accepted by the linux kernel.
According to the definition in https://tools.ietf.org/html/rfc3758#page-5
the length of this parameter has to be 4 bytes long, so the implementation should ideally react with an ABORT.
Testscript available at:
https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/error-cases/init-with-forward-tsn-too-long.pkt
Xin Long
maintainerQuoted 8 lines · Julian Cordes
An INIT-chunk with a FORWARD-TSN-SUPPORTED parameter having a length of 8 bytes is accepted by the linux kernel.
According to the definition in https://tools.ietf.org/html/rfc3758#page-5
the length of this parameter has to be 4 bytes long, so the implementation should ideally react with an ABORT.Testscript available at:
https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/error-cases/init-with-forward-tsn-too-long.pkt
To react with an ABORT seems not RFC demands, no clear description for that actually.
In sctp_verify_param(), sctp does send the necessary ABORT for the other abnormal params that RFC demands.
2017-01-17 19:13 GMT+01:00 Xin Long <[email protected]>:
Quoted 7 lines · Julian Cordes
Quoted 6 lines
An INIT-chunk with a FORWARD-TSN-SUPPORTED parameter having a length of 8 bytes is accepted by the linux kernel.
According to the definition in https://tools.ietf.org/html/rfc3758#page-5
the length of this parameter has to be 4 bytes long, so the implementation should ideally react with an ABORT.
Quoted 7 lines
Quoted 2 lines
Testscript available at:
https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/error-cases/init-with-forward-tsn-too-long.pktTo react with an ABORT seems not RFC demands, no clear description for that actually.
Insctp_verify_param(), sctp does send the necessary ABORT for the other abnormal params that RFC demands.
You are right,
these situations are not specified clearly in the RFC. I have talked about this with Michael Tüxen before, he has suggested that the implementation should either silently discard the INIT-Chunk or send an ABORT-Chunk. The linux implementation accepts at the moment this invalid INIT-Chunk and replies with an INIT-ACK-Chunk. I am not sure if this is wanted behaviour?
Xin Long
maintainerQuoted 16 lines · Julian Cordes
2017-01-17 19:13 GMT+01:00 Xin Long <[email protected]>:
Quoted 7 lines · Julian Cordes
Quoted 6 lines
An INIT-chunk with a FORWARD-TSN-SUPPORTED parameter having a length of 8 bytes is accepted by the linux kernel.
According to the definition in https://tools.ietf.org/html/rfc3758#page-5
the length of this parameter has to be 4 bytes long, so the implementation should ideally react with an ABORT.Quoted 7 lines
Quoted 2 lines
Testscript available at:
https://github.com/nplab/PR_SCTP_Testsuite/blob/master/forward-tsn/error-cases/init-with-forward-tsn-too-long.pktTo react with an ABORT seems not RFC demands, no clear description for that actually.
Insctp_verify_param(), sctp does send the necessary ABORT for the other abnormal params that RFC demands.
Quoted 7 lines
You are right,
these situations are not specified clearly in the RFC. I have talked about this with Michael Tüxen before, he has suggested that the implementation should either silently discard the INIT-Chunk or send an ABORT-Chunk. The linux implementation accepts at the moment this invalid INIT-Chunk and replies with an INIT-ACK-Chunk. I am not sure if this is wanted behaviour?
It maybe just forget to check it, will think about it, and I need to check if other params' processing also has the similar issue.
Thanks.