You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The solution should document how to perform SCTP Restart in a safe way. Based on what is written in Section 6.3 of RFC 4895 we believe a safe method for restarting is possible.
The restarting node need to have stored the SCTP-AUTH key that was in use prior to the restart. Then perform the INIT to initiate the restart per RFC 9260. Then use SCTP-AUTH with the old key in the Cookie-Echo message. That way proving to the peer that this is the same node. After that a new DTLS handshake can/must be done to re-authenticate the nodes on DTLS level, and then user messages can be sent using the new established DTLS connection and its derived SCTP-AUTH key.
The text was updated successfully, but these errors were encountered:
The solution should document how to perform SCTP Restart in a safe way. Based on what is written in Section 6.3 of RFC 4895 we believe a safe method for restarting is possible.
The restarting node need to have stored the SCTP-AUTH key that was in use prior to the restart. Then perform the INIT to initiate the restart per RFC 9260. Then use SCTP-AUTH with the old key in the Cookie-Echo message. That way proving to the peer that this is the same node. After that a new DTLS handshake can/must be done to re-authenticate the nodes on DTLS level, and then user messages can be sent using the new established DTLS connection and its derived SCTP-AUTH key.
The text was updated successfully, but these errors were encountered: