2017-01-17 19:13 GMT+01:00 Xin Long <lucien.xin@xxxxxxxxx>: > On Tue, Jan 17, 2017 at 9:11 PM, Julian Cordes <julian.cordes@xxxxxxxxx> wrote: >> 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. 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? -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
