I know that sctp does prevents SYN/Flooding (Denial of service) by the use of state cookies every echoed cookie is stored at a session-browser buffer level. But what does the state cookie actually contains?!
RFC-4960, chapter 5.1.3 describes it in details:
5.1.3. Generating State Cookie
When sending an INIT ACK as a response to an INIT chunk, the sender of INIT ACK creates a State Cookie and sends it in the State Cookie
parameter of the INIT ACK. Inside this State Cookie, the sender
should include a MAC (see [RFC2104] for an example), a timestamp on
when the State Cookie is created, and the lifespan of the State
Cookie, along with all the information necessary for it to establish
the association.The following steps SHOULD be taken to generate the State Cookie:
Create an association TCB using information from both the received INIT and the outgoing INIT ACK chunk,
In the TCB, set the creation time to the current time of day, and the lifespan to the protocol parameter 'Valid.Cookie.Life' (see Section 15),
From the TCB, identify and collect the minimal subset of information needed to re-create the TCB, and generate a MAC using this subset of information and a secret key (see [RFC2104] for an example of generating a MAC), and
Generate the State Cookie by combining this subset of information and the resultant MAC.
After sending the INIT ACK with the State Cookie parameter, the
sender SHOULD delete the TCB and any other local resource related to
the new association, so as to prevent resource attacks.The hashing method used to generate the MAC is strictly a private
matter for the receiver of the INIT chunk. The use of a MAC is
mandatory to prevent denial-of-service attacks. The secret key
SHOULD be random ([RFC4086] provides some information on randomness
guidelines); it SHOULD be changed reasonably frequently, and the
timestamp in the State Cookie MAY be used to determine which key
should be used to verify the MAC.An implementation SHOULD make the cookie as small as possible to
ensure interoperability.