Skip to content
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

Closed
tuexen opened this issue Feb 19, 2021 · 4 comments
Closed

Strange sentence #27

tuexen opened this issue Feb 19, 2021 · 4 comments

Comments

@tuexen
Copy link
Contributor

tuexen commented Feb 19, 2021

DATA chunks that are received before DTLS handshake will be silently discarded.

Needs to be changed.

@gloinul
Copy link
Owner

gloinul commented Feb 19, 2021

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.

@tuexen
Copy link
Contributor Author

tuexen commented Feb 19, 2021

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.

@gloinul
Copy link
Owner

gloinul commented Feb 22, 2021

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.

@gloinul
Copy link
Owner

gloinul commented Feb 22, 2021

Closing this issue after having created #35 and #37 to address two remaining aspects of the changes done in the PR #36.

@gloinul gloinul closed this as completed Feb 22, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants