-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strange sentence #27
Comments
Yes, that needs to be addressed. So in difference with RFC 6083, if one intended to use DTLS, no unprotected user messages should be sent. So what can arrive are either protected user messages or DTLS handshake messages on Stream 0. So stating that any data that has been sent will be ignored is not really protection against anything other than preventing misuse. But, it really ends up a question what the DTLS layer does with things that aren't DTLS records. |
How do you handle a starttls like setup used for example in RFC 3788? I think the point is that once an SCTP association is handled by an DTLS implementation, the DTLS implementation should terminate the SCTP association if it can't parse the record. |
I will review RFC 3788. From a layering perspective, I do agree that it is DTLS that needs to terminate the SCTP association. So maybe the way forward here is to state that once the DTLS over SCTP adapation layer interaction have gone both ways, we can mandate that all SCPT user messages will pass the DTLS layer, and thus it needs to be either DTLS messages (one stream 0) or protected user messages in DTLS records. If the DTLS stack receives anything else it can terminate the association. |
Needs to be changed.
The text was updated successfully, but these errors were encountered: