Edge has an ICE issue with username in BIND response

Won’t fix Issue #7718294

Details

Created
May 27, 2016
Privacy
This issue is public.
Reports
Reported by 2 people

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 Assigned To to “Frank L.”

      Changed Status to “Confirmed”

      Changed Assigned To from “Frank L.” to “Shijun S.”

    • Thank you so much for providing the feedback to us!

      You are correct that the Edge implementation currently is not fully consistent with RFC 5245.  Our media stack allows receiving replies either with or without the USERNAME attribute.  However, it includes the USERNAME attribute when sending response, 
      Hope you can work around the issue at this point based on this information, while we figure out how to address this properly in future product releases.  Please let us know if you have any further question in this area.

      All the Best, MS Edge Team

    • Microsoft Edge Team

      Changed Assigned To from “Shijun S.” to “Brad E.”

      Changed Status from “Confirmed” to “Won’t fix”

    • Hello,

       

      Thank
      you for your feedback on Edge. This item is not actionable in its current
      state.  If you could provide us with some more information we would be
      happy to look into this. Please provide:

       

      1.)
      Repro steps, including affected websites when you see resources going higher.

      2.)
      Fiddler / Network trace.

      3.)
      Output from a DXDiag report (for hardware details).

       

      Any
      of these items would make the item more useful for us to triage and direct to
      the appropriate teams for investigation.

       

      All
      the best,

      The
      MS Edge Team

    • Hi Brad,

      The original issue is about Edge generating ICE responses that contain the USERNAME attribute. Specific and complete documentation has been given, including multiple references to the corresponding RFCs.

      IMHO this issue can not just be closed (“WON’T FIX”) by requesting “affected websites” as if it was an amateur report. Exhaustive information, explaining how Edge violates the corresponding standard specification, has been provided. Most probably, this issue was discovered while testing Edge’s ORTC implementation in private environments, so asking for “affected websites” wont’t work nicely.

      Thanks a lot.

    • I can provide a test server URL for this issue, should MS be interested in fixing the bug.

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

    Sign in