Protect against ping periods that are out of range #488
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
slackpad
reviewed
Oct 20, 2017
coordinate/client.go
Outdated
| @@ -205,6 +207,11 @@ func (c *Client) Update(node string, other *Coordinate, rtt time.Duration) (*Coo | |||
| return nil, err | |||
| } | |||
|
|
|||
| durSec := rtt.Seconds() | |||
There was a problem hiding this comment.
You can do this as a time.Duration (I'd put the constant right here, too):
const maxRTT = 10 * time.Second
if rtt < 0 || rtt > maxRTT {
return nil, fmt.Errorf("RTT %s out of range 0 to %s", rtt, maxRTT)
}
There was a problem hiding this comment.
I'd also rail it way lower since 10 seconds is already several times around the Earth, so this should keep the coordinates better behaved in the face of weirdness (and it's not useful to model anything slower).
coordinate/client_test.go
Outdated
| } | ||
|
|
||
| dist_old := client.DistanceTo(other) | ||
| // Update with a valid ping period, should have an affect on estimated rtt |
coordinate/client_test.go
Outdated
| t.Fatal(err) | ||
| } | ||
|
|
||
| // Make sure the Euclidean part of our coordinate is what we expect. |
There was a problem hiding this comment.
This upper part doesn't seem necessary since we test the coordinate client elsewhere. I'd just try to update with a negative and a too large value and make sure you get the expected error back.
|
Related to #487. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I could reliably reproduce both extreme negative adjustment values and negative rtt estimates by feeding it time.maxvalue as the rtt value, which is a valid return values from the
time.Submethod.This patch makes it so that we reject any updates that contain rtt durations that are not in a range from 1 to 32400 seconds (9 hours). Another option is to force updates > 9 hrs to be = 9hrs, but rejecting it seemed better to avoid corrupted data feeding into the algorithm.
The 32000 was something I found from some experimentation with Vivaldi starting with two sets of coordinates at the origin and trying to get them to drift to the point where adjustment becomes this large negative value. 9 hours also seems like a conservative but large enough upper bound on the previously unbounded rtt value.