Edge has an ICE issue with username in BIND response

Duplicate Issue #7718344 • See Issue #7718294

Details

Author
Erik L.
Created
May 27, 2016
Privacy
This issue is public.
Duplicates
See progress on Bug #7718294
Reports
Reported by 1 person

Sign in to watch or report this issue.

Steps to reproduce

Seems Edge has a bug regarding ICE replies. Official RFCs require the USERNAME attribute MUST NOT be present. But Edge is sending USERNAME attribute in replies and does appear to reject our ICE responses from ORTC Lib that do not contain USERNAME attribute.

According to: https://tools.ietf.org/html/rfc5245#section-7.1.2.3

… A connectivity check
from R to L utilizes the username LFRAG:RFRAG and a password of
LPASS. The responses utilize the same usernames and passwords as the
requests (note that the USERNAME attribute is not present in the
response).
And: https://tools.ietf.org/html/rfc5389#section-10.1.2

If these checks pass, the agent continues to process the request or
indication. Any response generated by a server MUST include the
MESSAGE-INTEGRITY attribute, computed using the password utilized to
authenticate the request. The response MUST NOT contain the USERNAME
attribute.
But edge does not appear to like our STUN response packets (as the ICE transport does not go into the “connected” state on the Edge side) and sends us USERNAME in ICE BIND responses. This seems to follow the MSDN articles on the topic where I noticed that MS has STUN BIND reply behavior defined wrongly.

https://msdn.microsoft.com/en-us/library/dd921399(v=office.12).aspx

The USERNAME attribute MUST have the same value as the USERNAME attribute in the corresponding STUN binding request message. The MESSAGE-INTEGRITY attribute MUST have the message integrity value that is computed by using the password of the local candidate in the matching candidate pair.
and https://msdn.microsoft.com/en-us/library/dd926073(v=office.12).aspx

If a STUN binding response message is received without a USERNAME attribute, it MUST be discarded. The USERNAME attribute MUST be used to find the matching transport address pair for which the STUN binding response message is received.

NOTE: We understand that your implementation is partially conformant when considering Google’s ICE implementation, but Google support both methods in their WebRTC lib, Edge does not and is also not conformant with the STUN spec.

Attachments

0 attachments

    Comments and activity

    • Microsoft Edge Team

      Changed Status to “Duplicate”

    • Hello,

      Thanks for reporting the issue to us.  It seems you opened two bugs for the same topic.  We are resolving this one, and will track the issue with the other bug you opened (i.e. 7718294). 

      All the Best, MS Edge Team

    You need to sign in to your Microsoft account to add a comment.

    Sign in