Open
Bug 1319681
Opened 9 years ago
Updated 3 years ago
Implement the "dtls-id" SDP attribute from the dtls-sdp draft
Categories
(Core :: WebRTC: Networking, defect, P3)
Core
WebRTC: Networking
Tracking
()
NEW
| Tracking | Status | |
|---|---|---|
| firefox53 | --- | affected |
People
(Reporter: drno, Unassigned)
References
()
Details
(Keywords: cisco-spark)
Apparently it is not very obvious from any of the specs, but according to a very few references (see below) DTLS uses ICE as a "virtual transport" rather than a typical 5 tuple (as referenced in a few places).
Which means that a DTLS handshake can happen over multiple, different ICE candidate pairs as long as they belong to the same ICE component. This should probably work as transportlayerdtls.cpp does not care about 5 tuples.
But it looks like the change of ufrag/pwd, which is the equivalent of an ICE restart, constitutes a new virtual transport. Which makes sense since the new ufrag/pwd (plus new candidates from the remote side) means you no longer have any idea if you are still talking to the same entity as before, or if the remote side is now a different ICE endpoint (it should be the same, but there is no way to transfer that trust over the ICE restart).
Luckily the issue raise by some people on the mailing list that this causes problems if you re-use existing port numbers during an ICE restart does not affect us.
As it looks like this has not been written down in any of the new specs (at least I have not been able to find anything) I'm for discussion on this, but currently I think it makes sense to require a DTLS restart after an ICE restart.
https://tools.ietf.org/html/rfc5763#section-6.7.1
https://www.ietf.org/mail-archive/web/rtcweb/current/msg14257.html
https://groups.google.com/forum/#!msg/discuss-webrtc/i67xq-FWtoM/kzHIINH5WpcJ
| Reporter | ||
Comment 1•9 years ago
|
||
Martin, Byron, Ekr: what are your thoughts on the question above?
Flags: needinfo?(martin.thomson)
Flags: needinfo?(ekr)
Flags: needinfo?(docfaraday)
Comment 2•9 years ago
|
||
The correct behavior is documented in:
https://tools.ietf.org/id/draft-ietf-mmusic-dtls-sdp-15.txt
In general, you don't need to change if ufrag/pwd changes but fingerprint does not.
Flags: needinfo?(ekr)
Comment 3•9 years ago
|
||
That draft used to say:
"In the case of an ICE restart, the DTLS handshake procedure is repeated, and a new DTLS association is created."
Now it says:
"an ICE restart does not by default require a new DTLS association to be established."
Is this subject for further changes, or can we feel confident that a new DTLS handshake is definitely not going to be needed on ICE restarts?
Updated•9 years ago
|
Rank: 15
| Reporter | ||
Comment 4•9 years ago
|
||
For future reference section 6 "ICE Considerations" of the DTLS SDP draft specifies that in fact we only need to renegotiate DTLS if the cert fingerprint or the "dtls-id" attribute changes: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-15#section-6
So an regular ICE restart does not require DTLS to be restarted.
I think we actually at some point want to implement the "dtls-id" SDP attribute defined in this draft. Especially if people start re-using certificates at some point in the future.
Rank: 15 → 25
Flags: needinfo?(martin.thomson)
Flags: needinfo?(docfaraday)
Priority: P1 → P2
Summary: ICE restart is not restarting DTLS → Implement the "dtls-id" SDP attribute from the dtls-sdp draft
Comment 5•8 years ago
|
||
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•