Re: [bfcpbis] Eric Rescorla's Discuss on draft-ietf-bfcpbis-rfc4583bis-26: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

On Wed, Oct 24, 2018 at 12:50 PM Roman Shpount <[e-mail]> wrote:

> Hi Eric,
>
> Since I have helped with ICE related sections of this draft, I can provide
> answers to some of your comments:
>
> On Wed, Oct 24, 2018 at 3:23 PM Eric Rescorla <[e-mail]> wrote:
>
>> S 9.
>> >      transport is used for the default candidate, then the 'm' line
>> proto
>> >      value MUST be 'UDP/TLS/BFCP'.  If TCP transport is used for the
>> >      default candidate, the 'm' line proto value MUST be
>> 'TCP/DTLS/BFCP'.
>> >
>> >         Note: Usage of ICE with protocols other than UDP/TLS/BFCP and
>> >         TCP/DTLS/BFCP is outside of scope for this specification.
>>
>> this is very different from any other use of ICE, and I'm not sure
>> it's interoperable, unless you require that only TCP or only UDP
>> candidates be offered (which you do not seem to). The reason is that
>> with ICE you can flip between different candidates as part of the
>> negotiation. So what happens if I initially get a UDP candidate and
>> then via aggressive nomination settle on TCP (or vice versa). DTLS and
>> TLS aren't really interoperable in that way. It would be far better to
>> do what WebRTC does and when you do ICE, always do DTLS even if it's
>> over TCP.
>>
>>
> When ICE is used, DTLS is always used exactly for the reasons you
> mention.  End points only allowed to use 'UDP/TLS/BFCP', which is DTLS over
> UDP, or 'TCP/DTLS/BFCP', which is DTLS over TCP. DTLS over UDP is only
> named  'UDP/TLS/BFCP' instead of  'UDP/DTLS/BFCP' for legacy interop
> reasons, since some implementations apparently already added support for
> this.  Please note that naming of BFCP over DTLS over UDP  as
> 'UDP/TLS/BFCP'  is similar to naming RTP over DTLS over UDP as
> "UDP/RTP/TLS/SAVP".
>

Ah, I missed this. But then I do wonder whether it's really useful to have
two proto versions here, rather than just UDP/TLS/BFCP. We didn't find it
helpful in JSEP....



>
>> S 5.5.
>> >      'bfcpver' attribute in offers and answers.  The attribute value, if
>> >      present, MUST be in accordance with the definition of the Version
>> >      field in [I-D.ietf-bfcpbis-rfc4582bis].  If the attribute is not
>> >      present, endpoints MUST assume a default value in accordance with
>> >      [I-D.ietf-bfcpbis-rfc4582bis]: when used over a reliable transport
>> >      the default attribute value is "1", and when used over an
>> unreliable
>>
>> Just for clarity: UDP over TURN-TCP is an unreliable transport, right?
>>
>>
> UDP/BFCP, UDP/TLS/BFCP, and TCP/DTLS/BFCP are all unreliable transports,
> even if TURN-TCP or TURN-TLS is used. Only TCP/BFCP and TCP/TLS/BFCP
> transports are considered reliable. Do you think it should be explicitly
> spelled out?
>

It shouldn't have to be, but people seem to get confused.

-Ekr


> Regards,
> _____________
> Roman Shpount
>
>
>