On Wed, Jan 18, 2017 at 4:03 AM, Julian Cordes <julian.cordes@xxxxxxxxx> wrote: > 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? 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. -- 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
