Subject: [Ice] STUN attribute 0xC057 - What is this?

From: Ross Finlayson <[email-masked]>
Date: Thu, 9 Jun 2016 18:15:18 -0700

(Apologies in advance for the slightly off-topic question)

I’ve found that my STUN server (in my WebRTC server implementation) often receives STUN Binding Requests that contain an unknown attribute type 0xC057.  This attribute is always 4-bytes long, with each of the four bytes being zero.

This unknown attribute is sent by Chrome (and Opera) browsers, but apparently never by Firefox.

According to RFC 5389 (and IANA), STUN attribute 0xC057 is unassigned, but is in the 'Designated Expert’ Comprehension-Optional range.

Does anyone know what this is?

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

---

From: Adam Roach <[email-masked]>
Date: Thu, 9 Jun 2016 21:10:27 -0500

> Does anyone know what this is?

Yep, it's part of the webrtc.org code:

https://chromium.googlesource.com/external/webrtc/+/6ab3db249b075e0e820a263d54804f521e7bc24b/webrtc/p2p/base/stun.h#611

It appears to have been introduced here:

https://codereview.webrtc.org/1815473002

And it seems to be described, at least at a high level, here:

https://tools.ietf.org/html/draft-thatcher-ice-network-cost-00

Maybe Peter will explain his draft further? I would suggest that the 
IANA section, at least, is incorrect.

/a

---

From: Taylor Brandstetter <[email-masked]>
Date: Fri, 10 Jun 2016 10:19:14 -0700

Not off-topic at all, actually. We're using 0xC057 for an experimental
"network cost" attribute, which is described in this draft:
https://tools.ietf.org/html/draft-thatcher-ice-network-cost-00

This is used in order to communicate an endpoint's preference for different
networks (if the endpoint is using multiple network interfaces), so that
the controlling ICE endpoint can select the preferred one based on certain
criteria. We can't just use the ICE candidate priority, because the "type
preference" part of the priority (local, stun, relay) takes precedence over
the "local preference". There are other reasons as well, which are
discussed in the draft.

On Thu, Jun 9, 2016 at 6:15 PM, Ross Finlayson <[email-masked]>
wrote:

> I’ve found that my STUN server (in my WebRTC server implementation) often
> receives STUN Binding Requests that contain an unknown attribute type
> 0xC057.  This attribute is always 4-bytes long, with each of the four bytes
> being zero.
>
> According to RFC 5389 (and IANA), STUN attribute 0xC057 is unassigned, but
> is in the 'Designated Expert’ Comprehension-Optional range.
>
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 27 Jun 2016 12:34:52 -0700

On Thu, Jun 9, 2016 at 7:10 PM, Adam Roach <[email-masked]> wrote:

>> According to RFC 5389 (and IANA), STUN attribute 0xC057 is unassigned,
>> but is in the 'Designated Expert’ Comprehension-Optional range.
>>

​

> ​
Yes, that's what it is.  ​
​  It's our implementation of the draft whereby an ICE endpoint can
indicate how much it thinks a network interface will cost to use (wifi vs
cell, for example).​

> Maybe Peter will explain his draft further? I would suggest that the IANA
> section, at least, is incorrect.
>
>
​I don't know what to say other than read the draft.  It's quite short.  I
will hopefully be presenting about it at IETF 96.

You are correct that I should update the IANA section of the draft to
indicate we'll need to register a STUN attribute (instead of the temporary
0xC057).