Unless I'm missing something, this is expected behavior.

A new DTLS association does require an ICE restart, so that you can disambiguate packets belonging to the old/new DTLS association. But the inverse is not true; you can restart ICE and continue to use the old DTLS association, which is what happens by default in Chrome (and Firefox, from my testing).

A new DTLS association will only be created if the answer from B changes the "a=fingerprint", or "a=tls-id" (which Chrome doesn't implement). Is that's what going on here? Is the issue that we don't implement a=tls-id?

Thanks for the response @deadbeef.

We are looking regarding the inverse.  Restarting ICE after IP changes, and using the same DTLS negotiation.  Our server is expected in this case to set up a new DTLS association after ice restarts, but chrome does not respond.  We also do not support a=tls-id server side, so I'm not sure that's 100% the issue.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

To clarify,

I think what we saw on Firefox was different.  I'm not sure I can share the pcap here, but Firefox, when no `a=tls-id` is present, allows for DTLS renegotiation to occur after ice restart. Chrome does not under the same circumstances.

I think the clear solution in our case is for both Chrome and our server to implement a=tls-id.  However, short of that, we can likely add a hack on our server to not force dtls renegotiation after ice restart, or alternatively Chrome could accept the DTLS renegotiation, and complete another handshake as Firefox does.

Hi we think firefox honers the ice-ufrag change and does the DTLS handshake on the other hand. 
https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24

Our server currently doesnt support tls-id and  doesnt change the a=fingerprint as its tied to the SSL certificate on the box. So they just change the ice-ufrag . I have seen from the above documents saying ice-ufrag and password change from the remote side also triggers DTLS in some cases .

> Our server is expected in this case to set up a new DTLS association after ice restarts, but chrome does not respond.

Meaning that the server sends a HelloRequest in order to trigger renegotiation? It looks like BoringSSL doesn't handle this, referring to renegotiation as an "extremely problematic protocol feature": https://github.com/google/boringssl/blob/master/PORTING.md

davidben@: Any comments on this? I assume the issue is mixing up packets belonging to the new/old association?

I believe we could handle this at the WebRTC level, by saying "if the first packet received on a new batch of ICE candidates is a ClientHello or HelloRequest, assume the answerer wants a new association." Then we can use the ICE layer to demux (delivering packets received on old ICE candidates to the old association, and packets received on new ICE candidates to the new association). We'll have to do something like this anyway, since even with "tls-id", you can receive a ClientHello before the answer.

But "tls-id" does seem like the proper solution, to resolve any ambiguities.

Uh-oh, renegotiation in DTLS is even more of a disaster than it is in TLS. :-(

I'm confused about the claim that it works in Firefox though. It looks like they also don't support renegotiation in DTLS.
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.27_release_notes
https://github.com/nss-dev/nss/commit/6e2c3ecdf00f3370af34ad7224ee66c0909329b8

And indeed that check is still in there:
https://github.com/nss-dev/nss/blob/master/lib/ssl/sslsock.c#L747-L751

So I expect whatever Firefox is doing, it's not a DTLS-level renegotiation.

(I don't know how ICE works or what renegotiation at that layer means, so I don't have anything more coherent to say than that. Though if it'd be helpful for me to understand it and you have time, deadbeef@, I'm happy to hop on a VC for a primer.)

Thanks for the comments @davidben . We checked once again it looks like the firefox clam was wrong .

Scenario 1: Turn off the wifi and turn it back on in 3 to 4 sec. We were seeing this two behavior on chrome and firefox 

Chrome : peerConnection state would do to disconnected --> Failed . Chome doesnt recover so we do a ice restart when the network comes back . We saw the IP remains the same but port and ice-ufrag changes 
Firefox : PeerConnection goes to disconnected but the connection established with the same IP and port 

Scenario 2: Wifi disconnect and connect back after 10 seconds 

Chrome : Behaves same as scenario 1
Firefox : Behaves same as Chrome doesnt connect back. 

Scenario 3: Related to IP change when connecting to a totally different network should be the same as scenario 2 (Needs more testing)
our server currently checks the ice-ufrag and password change also when deciding about the DTLS handshake. 

We couldnt figureout the best RFC to handle all ice-ufrag , setup role, tls and fingerprint scenario . Here is the two related RFC we found which suggested the ice-ufrag change should trigger DTLS on the server side 

https://tools.ietf.org/html/rfc5245#section-9.2.1.1
https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24 

So question here is should chrome change the ice-ufrag change if there is only Port change and IP remained the same . This could happen when you are connected to same lan and wifi network 

I remember last year this scenario was working when we tested in chrome . Not sure which version broke it 

And should chrome trigger DTLS when it also sees ice-ufrag and password change ?

The ice-ufrag will change whenever an ICE restart occurs, whether or not the IP remains the same.

But it doesn't trigger a new DTLS association. See comment #2. I notice the dtls-sdp-24 draft you linked contradicts this, but it was changed later. The current version (32) says:

   NOTE: A modification of the ufrag value is not treated as an
   indication that an endpoint wants to establish a new DTLS assocation.
   In order to indicate that a new DTLS association is to be
   established, one or more of the characteristics listed above have to
   be modified.

The issue seems to be out of TE-scope as it is related to createOffer() with iceRestart which is already being investigated by dev. Hence, adding label TE-NeedsTriageHelp for further investigation from dev team.

Thanks...!!

Since discussion has stalled, closing as "working as intended." Also filed https://bugs.chromium.org/p/webrtc/issues/detail?id=9297 to keep track of implementing a=tls-id.