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

[Adam Roach <[e-mail]>]

On 10/24/18 2:53 PM, Eric Rescorla wrote:
>
>
> On Wed, Oct 24, 2018 at 12:50 PM Roman Shpount <[e-mail] 
> <mailto:[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]
>     <mailto:[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....
>

The rationale here is that this approach -- matching the proto to the 
default candidate -- allows for compatibility with clients that do not 
do ICE. JSEP and WebRTC took an explicit decision to require ICE, and to 
fail with clients that do not implement it. As a consequence, there's a 
lot of simplifications of handling the proto field in WebRTC that are 
broadly inapplicable outside of that ecosystem.

/a