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)

defect

Tracking

()

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
Martin, Byron, Ekr: what are your thoughts on the question above?
Flags: needinfo?(martin.thomson)
Flags: needinfo?(ekr)
Flags: needinfo?(docfaraday)
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)
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?
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
See Also: → 1320903
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.