Subject: [rtcweb] 5G standards advocating WebRTC protocol violations?

From: Harald Alvestrand <[email-masked]>
Date: Wed, 3 Nov 2021 12:37:23 +0100

It's come to my attention that there's apparently some 5G spec that says 
"Use WebRTC datachannel, but don't bother with this ICE stuff".

The exact quote is below.

Now I don't mind saying "don't use TURN/STUN servers" - that's a 
configuration option on the WEBRTC API, and anyone can choose to not do 
that - but I do mind leaving out ICE. An ICE-supporting implementation 
won't interwork properly with an implementation that doesn't support ICE.

Is it possible for the IETF to say "please don't make incompatible 
changes to our protocols without asking us"? (that's the version where I 
try not to use expletives).

Or is it possible that this is all a misunderstanding, and the 5G folks 
actually meant to require peer-to-peer ICE, but just wrote it wrongly?

Or did I misunderstand what the WG's intent was, and should just suck it 
up and interoperate with non-ICE-supporting endpoints?

Harald

--------- Spec reference quote ----------

1. Spec
NG.129 - 5G Data Channel White Paper  (CR1001)

8.2.1Data channel APIs
The data channel application consists of the device side logic and the 
server side logic.
Both should use standardized APIs that need to be agreed by the industry.
W3C WebRTC1.0 data channel API specification is suggested as the 
preferred IMS data channel API. RTCPeerConnection ,
RTCDataChannel object, the  callbacks need to be supported .
Only data channel API related definitions  are used and IMS data channel 
API is not allowed to use WebRTC media.
ICE/STUN/TURN are also not required.

# Reference
3GPP TS 26.114 IMS_Multimedia Telephony Media handling and interaction
GSMA NG.114 IMS Profile for Voice, Video and Messaging over 5GS
GSMA NG.129_5G DATA CHANNEL

---

From: Ted Hardie <[email-masked]>
Date: Wed, 3 Nov 2021 13:10:12 +0000

Hi Harald,

It is definitely possible for us to send liaison statements via the
appropriate channel, but I am missing some context.  Can you provide a
citation to the document from which the excerpt comes?  (It appears to be
labeled a white paper, so the first step may be to confirm that its
description and the underlying specs say the same thing.)

regards,

Ted Hardie

On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand <[email-masked]>
wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 9 Nov 2021 13:38:26 -0700

We might want to say if you don’t want to do any of the ICE nightmare, ICE Lite is the best way to not do it and still have interoperability.  Do we know someone working on this at 5G that can help provide more guidance ?

> On Nov 3, 2021, at 7:10 AM, Ted Hardie <[email-masked]> wrote:
> 
> Hi Harald,
> 
> It is definitely possible for us to send liaison statements via the appropriate channel, but I am missing some context.  Can you provide a citation to the document from which the excerpt comes?  (It appears to be labeled a white paper, so the first step may be to confirm that its description and the underlying specs say the same thing.)
> 
> regards,
> 
> Ted Hardie
> 
> On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand <[email-masked] <mailto:[email-masked]>> wrote:
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 9 Nov 2021 15:49:01 -0500

I would advise against ICE-lite. One of the things that ICE provides is
consent to send media. ICE-lite does not have this. Getting consent is
important to avoid using endpoints for DDOS attacks, so it is a matter of
security.

If they want to simplify things, they can use host candidates only, which
will make the ICE state machine trivial.
_____________
Roman Shpount

On Tue, Nov 9, 2021 at 3:38 PM Cullen Jennings <[email-masked]> wrote:

>
> We might want to say if you don’t want to do any of the ICE nightmare, ICE
> Lite is the best way to not do it and still have interoperability.  Do we
> know someone working on this at 5G that can help provide more guidance ?
>
>
>

---

From: Bo Burman <[email-masked]>
Date: Tue, 9 Nov 2021 22:45:07 +0000

Hi Ted, Harald,

I have some insight into that GSMA work that might help the discussion.

The intent was never to create or even suggest incompatible changes to WebRTC protocols. Quite the opposite, the intent was to reuse WebRTC protocols, which I believe is clear from other parts of that White Paper. The suggested reuse of WebRTC data channel protocol stack is for 3GPP IMS-native multimedia telephony, not intended to change the core of WebRTC. It should be OK to use a data channel outside of WebRTC context – for example, like CLUE telepresence makes use of it. Also, 3GPP previously defined WebRTC access to IMS through the use of a gateway where ICE is used on the WebRTC side, but that is separate from the GSMA case.

The GSMA White Paper is mainly educational for that community, in this case exploring possibilities with using WebRTC data channel media as part of 5G phone calls. If GSMA members find this interesting enough, normative work and specifications will follow but nothing is started yet.

I believe the sentence Harald highlights below should be interpreted from the perspective that ICE/STUN/TURN functionality is strictly not needed in a telco operator’s network, since connectivity is solved by other means in that context. That particular sentence is likely not considering what requirements, e.g. use of ICE, that may come from reuse of existing WebRTC protocol stacks. This aspect must however be kept in mind as the work continues.

I hope that helps.

Cheers,

Bo

From: rtcweb <[email-masked]> On Behalf Of Ted Hardie
Sent: den 3 november 2021 14:10
To: Harald Alvestrand <[email-masked]>
Cc: RTCWeb IETF <[email-masked]>
Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol violations?

Hi Harald,

regards,

Ted Hardie

On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand <[email-masked] <mailto:[email-masked]> > wrote:

Harald

--------- Spec reference quote ----------

1. Spec

8.2.1Data channel APIs

# Reference

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 10 Nov 2021 09:39:58 +0100

Thanks Bo!

The specific problem I have is that a customer has requested that Chrome 
be modified to be able to operate without ICE, where the owner of the 
equipment in question is pointing to this particular sentence as 
justification for its request.

If the sentence had said "Use of STUN and TURN servers are not required, 
and ICE-Lite can be used", that would have been no problem.

Harald

On 11/9/21 11:45 PM, Bo Burman wrote:
> The intent was never to create or even suggest incompatible changes to 
> WebRTC protocols. Quite the opposite, the intent was to reuse WebRTC 
> protocols, which I believe is clear from other parts of that White 
> Paper. The suggested reuse of WebRTC data channel protocol stack is 
> for 3GPP IMS-native multimedia telephony, not intended to change the 
> core of WebRTC. It should be OK to use a data channel outside of 
> WebRTC context – for example, like CLUE telepresence makes use of it. 
> Also, 3GPP previously defined WebRTC access to IMS through the use of 
> a gateway where ICE is used on the WebRTC side, but that is separate 
> from the GSMA case.
>
> The GSMA White Paper is mainly educational for that community, in this 
> case exploring possibilities with using WebRTC data channel media as 
> part of 5G phone calls. If GSMA members find this interesting enough, 
> normative work and specifications will follow but nothing is started yet.
>
> I believe the sentence Harald highlights below should be interpreted 
> from the perspective that ICE/STUN/TURN functionality is strictly not 
> needed in a telco operator’s network, since connectivity is solved by 
> other means in that context. That particular sentence is likely not 
> considering what requirements, e.g. use of ICE, that may come from 
> reuse of existing WebRTC protocol stacks. This aspect must however be 
> kept in mind as the work continues.
>
> I hope that helps.
>
> Cheers,
>
> Bo
>
> *From:* rtcweb <[email-masked]> *On Behalf Of *Ted Hardie
> *Sent:* den 3 november 2021 14:10
> *To:* Harald Alvestrand <[email-masked]>
> *Cc:* RTCWeb IETF <[email-masked]>
> *Subject:* Re: [rtcweb] 5G standards advocating WebRTC protocol 
> violations?
>
> Hi Harald,
>
> citation to the document from which the excerpt comes?  (It appears to 
> be labeled a white paper, so the first step may be to confirm that its 
> On Wed, Nov 3, 2021 at 11:37 AM Harald Alvestrand 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Ted Hardie <[email-masked]>
Date: Wed, 10 Nov 2021 10:09:43 +0000

Hi Harald, Bo,

Thanks to you both for the clarifications.  It seems to me, in light of
this, that the working group probably does not need to draft a liaison
statement and that this can be worked out simply using the explanatory
email that Bo provided.  If that is not the case, I'd appreciate a clearer
statement of what would be required.

thanks,

Ted Hardie

On Wed, Nov 10, 2021 at 8:39 AM Harald Alvestrand <[email-masked]>
wrote:

> protocols, which I believe is clear from other parts of that White Paper.
> The suggested reuse of WebRTC data channel protocol stack is for 3GPP
> IMS-native multimedia telephony, not intended to change the core of WebRTC.
> It should be OK to use a data channel outside of WebRTC context – for
> example, like CLUE telepresence makes use of it. Also, 3GPP previously
> defined WebRTC access to IMS through the use of a gateway where ICE is used
> on the WebRTC side, but that is separate from the GSMA case.
>
>
>
> case exploring possibilities with using WebRTC data channel media as part
> of 5G phone calls. If GSMA members find this interesting enough, normative
> work and specifications will follow but nothing is started yet.
>
>
>
> I believe the sentence Harald highlights below should be interpreted from
> the perspective that ICE/STUN/TURN functionality is strictly not needed in
> a telco operator’s network, since connectivity is solved by other means in
> that context. That particular sentence is likely not considering what
> requirements, e.g. use of ICE, that may come from reuse of existing WebRTC
> protocol stacks. This aspect must however be kept in mind as the work
> continues.
>
>
>
> I hope that helps.
>
>
>
> Cheers,
>
> Bo
>
>
>
> *From:* rtcweb <[email-masked]> <[email-masked]> *On
> Behalf Of *Ted Hardie
> *To:* Harald Alvestrand <[email-masked]> <[email-masked]>
> *Cc:* RTCWeb IETF <[email-masked]> <[email-masked]>

---

From: westhawk <[email-masked]>
Date: Wed, 10 Nov 2021 11:17:10 +0100

This is (perhaps) a subclass on an interesting situation, where the 5g network spins up a new bearer channel with an interface which is effectively a VPN to the far end.
This obviates ICE, also they probably don’t want Chrome to be able to talk to the far end :-)

Tim (who spent too long in Telcoland) 

> On 10 Nov 2021, at 11:09, Ted Hardie <[email-masked]> wrote:
> 
> Hi Harald, Bo,
> 
> Thanks to you both for the clarifications.  It seems to me, in light of this, that the working group probably does not need to draft a liaison statement and that this can be worked out simply using the explanatory email that Bo provided.  If that is not the case, I'd appreciate a clearer statement of what would be required.
> 
> thanks,
> 
> Ted Hardie
> 
> On Wed, Nov 10, 2021 at 8:39 AM Harald Alvestrand <[email-masked] <mailto:[email-masked]>> wrote:
> Thanks Bo!
> 
> The specific problem I have is that a customer has requested that Chrome be modified to be able to operate without ICE, where the owner of the equipment in question is pointing to this particular sentence as justification for its request.
> 
> If the sentence had said "Use of STUN and TURN servers are not required, and ICE-Lite can be used", that would have been no problem.
> 
> Harald
> 
>> From: rtcweb <[email-masked]> <mailto:[email-masked]> On Behalf Of Ted Hardie
>> To: Harald Alvestrand <[email-masked]> <mailto:[email-masked]>
>> Cc: RTCWeb IETF <[email-masked]> <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>_______________________________________________
> rtcweb mailing list
> [email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 10 Nov 2021 07:32:06 -0700

I  agree we need the consent checks that ICE provided but I think ICE Lite still provided the checks that provide the consent to receive packets property. 

> On Nov 9, 2021, at 1:49 PM, Roman Shpount <[email-masked]> wrote:
> 
> I would advise against ICE-lite. One of the things that ICE provides is consent to send media. ICE-lite does not have this. Getting consent is important to avoid using endpoints for DDOS attacks, so it is a matter of security.
> 
> If they want to simplify things, they can use host candidates only, which will make the ICE state machine trivial.
> _____________
> Roman Shpount
> 
> 
> On Tue, Nov 9, 2021 at 3:38 PM Cullen Jennings <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Nov 3, 2021, at 7:10 AM, Ted Hardie <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi Harald,
>>

---

From: Bo Burman <[email-masked]>
Date: Wed, 10 Nov 2021 14:36:56 +0000

It seems to me that Tim is making a fair description of reality in this case.

While I have no insight into the customer request to Google, I’d like to emphasize that since it refers to the GSMA text, the context of that request must reasonably be IMS-native telephony with added data channel(s). In IMS-native telephony context there’s today no support for ICE or ICE Lite, which is then likely the reason for the request. Use of Chrome as a browser application would hardly make sense to me in the context of IMS-native telephony (without any gateway), so I agree with Tim on that aspect.

Thanks,

Bo

From: rtcweb <[email-masked]> On Behalf Of westhawk
Sent: den 10 november 2021 11:17
To: Harald Alvestrand <[email-masked]>
Cc: RTCWeb IETF <[email-masked]>
Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol violations?

On 10 Nov 2021, at 11:09, Ted Hardie <[email-masked] <mailto:[email-masked]> > wrote:

Hi Harald, Bo,

thanks,

Ted Hardie

On Wed, Nov 10, 2021 at 8:39 AM Harald Alvestrand <[email-masked] <mailto:[email-masked]> > wrote:

Thanks Bo!

Harald

Hi Ted, Harald,

I hope that helps.

Cheers,

Bo

From: rtcweb  <mailto:[email-masked]> <[email-masked]> On Behalf Of Ted Hardie
Sent: den 3 november 2021 14:10
To: Harald Alvestrand  <mailto:[email-masked]> <[email-masked]>
Cc: RTCWeb IETF  <mailto:[email-masked]> <[email-masked]>
Subject: Re: [rtcweb] 5G standards advocating WebRTC protocol violations?

Hi Harald,

regards,

Ted Hardie

Harald

--------- Spec reference quote ----------

1. Spec

8.2.1Data channel APIs

# Reference

---

From: Roman Shpount <[email-masked]>
Date: Wed, 10 Nov 2021 13:16:46 -0500

When two ICE-Lite clients are connected, there are no consent checks. With
one ICE-Lite client, there are consent checks in one direction only. In
either case, an endpoint can be used to generate traffic for DDOS. In the
case of WebRTC, there is an additional initial consent present in the form
of a DTLS handshake, but only ICE provides continuous consent to send media.

At this point, any system, which sends a large amount of data without
consent to receive it, should be considered a DDOS risk. I am not sure how
telecom networks would be any different unless they use some other
mechanism for the same purpose.
_____________
Roman Shpount

On Wed, Nov 10, 2021 at 9:32 AM Cullen Jennings <[email-masked]> wrote:

> I  agree we need the consent checks that ICE provided but I think ICE Lite
> still provided the checks that provide the consent to receive packets
> property.
>
>> We might want to say if you don’t want to do any of the ICE nightmare,
>> ICE Lite is the best way to not do it and still have interoperability.  Do
>> we know someone working on this at 5G that can help provide more guidance ?
>>
>>
>>