-
Notifications
You must be signed in to change notification settings - Fork 79
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
Fix handling of retransmitted cookie-echo #130
Conversation
Codecov Report
@@ Coverage Diff @@
## master #130 +/- ##
==========================================
+ Coverage 78.71% 78.82% +0.10%
==========================================
Files 43 43
Lines 2795 2800 +5
==========================================
+ Hits 2200 2207 +7
+ Misses 457 455 -2
Partials 138 138
Continue to review full report at Codecov.
|
0357fc7
to
892b525
Compare
892b525
to
9119023
Compare
@Sean-Der This is a fix for a fundamental error in handling delayed cookie-echo received in the "established" state (which would happen over lossy connection). If you could review this at your earliest convenience, that would really be appreciated. |
This is related to #62 in which we removed the use of immediate ack (I) bit. This test became unstable as we no longer use immediate ack. Relates to pion/webrtc#1270
ae7ec58
to
ae15c0e
Compare
Commit message from GitHub web UI uses CR+LF which is currently not supported by our commit message lint script. pion/.goassets#6
|
ae15c0e
to
e9599dc
Compare
return nil | ||
} | ||
case established: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Current implementation seems returning cookie-ack whenever cookie-echo is received after established.
https://tools.ietf.org/html/rfc4960#section-5.2.4 seems to specify several conditions/actions and cookie-echo should be silently discarded in some case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@at-wat Yes, good finding. The current implementation does not follow the RFC for building a cookie. It is currently a random value that prevents us from validating the echoed cookie as specified in the RFC.
I am hoping to address this issue in #74 sometime soon, encoding TCB information into the cookie, then validate as the spec says. (no effect in WebRTC usage however, if we provide Listen/Dial semantics, yes it is desired.)
This pull-request tries to address missing state transitions from COOKIE-ECHOED to ESTABLISHED because the peer in the ESTABLISHED state does not send COOKIE-ACK, a different issue. We are seeing the connection stalled in the real world because of this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am hoping to address this issue in #74 sometime soon, encoding TCB information into the cookie, then validate as the spec says.
Great!
Maybe it's better to notify the current status of the implementation in README. If users try to use the library as a full sctp implementation, simplified implementation may cause some security problems. (as it's over DTLS in WebRTC, we don't have to care.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @at-wat You just made me realize we at least needed to check if the echoed cookie was identical to the original one. Thanks!
Let me add these lines in the "established" case.
if !bytes.Equal(a.myCookie.cookie, c.cookie) {
return nil
}
When the cookie does not match, it will silently be discarded.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@at-wat a quick question. Use used 'break' inside the switch statement. Golang does not require break but is that something you'd recommend for readability or any other reasons? (just out of my curiosity...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have strong reason, but I just feel it's more clear to tell that it's not fallthrough
. (I mainly used C/C++ before starting Go)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@at-wat I have just added the cookie comparison to the established case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hear you. I write C/C++ too. ;) but I am trying to think in Go. I removed it in the last commit, hope you wouldn't mind...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's 100% fine to me!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Relates to pion/webrtc#1270
Description
Please see this comment(pion/webrtc#1270 (comment)) for details.
What's in this PR