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

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Oct 2018 12:23:34 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-bfcpbis-rfc4583bis-26: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4457

DETAIL
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.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

S 5.3.
>      The SDP Offer/Answer procedures for the 'confid' attribute are
>      defined in Section 10.
>   
>   5.3.  SDP 'userid' Attribute
>   
>      This section defines the SDP userid' media-level attribute.  The

Are there any security considerations around this attribute?

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?

S 7.1.
>      deliver a BFCP message and times out, the endpoint that attempted to
>      send the message (i.e., the one that detected the TCP timeout) MUST
>      send an offer in order to re-establish the TCP connection.
>   
>      Endpoints that use the offer/answer mechanism to negotiate TCP
>      connections MUST support the 'setup' and 'connection' attributes.

You probably need a reference here.

S 10.1.
>   
>      o  MUST associate an SDP 'floorid' attribute (Section 5.4) with the
>         'm' line; and
>   
>      o  MUST associate an SDP 'label' attribute ([RFC4574]) with the 'm'
>         line of each BFCP-controlled media stream.

We managed to mostly purge "associate" from BUNDLE. Can we do it here
too?

S 10.2.
>      o  MUST insert a corresponding 'm' line in the answer, with an
>         identical 'm' line proto value [RFC3264]; and
>   
>      o  MUST associate a 'bfcpver' attribute with the 'm' line.  The
>         answerer only indicates support of BFCP versions also supported by
>         the offerer; and

Is this an odd way of saying you must subset what the offer contained?

---

From: Roman Shpount <[email-masked]>
Date: Wed, 24 Oct 2018 15:50:10 -0400

Hi Eric,

Since I have helped with ICE related sections of this draft, I can provide
answers to some of your comments:

> do what WebRTC does and when you do ICE, always do DTLS even if it's
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".

> 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?

Regards,
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Oct 2018 12:53:32 -0700

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

> 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....

> transports are considered reliable. Do you think it should be explicitly

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

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Wed, 24 Oct 2018 16:12:13 -0400

> two proto versions here, rather than just UDP/TLS/BFCP. We didn't find it
ICE SDP draft still requires a re-INVITE after nomination process is
completed where c= and m= line are updated to reflect the nominated
candidate. If nominated candidate an ICE-TCP candidate, then proto in m=
line would be 'TCP/DTLS/BFCP' to reflect this. In cases when non ICE-TCP
candidate is used, the proto in m= line will be 'UDP/TLS/BFCP'. Also, all
subsequent offer/answer exchanges, which do not initiate ICE restart are
supposed to use the proto value of nominated candidate in the m= line. So,
the only reason for existence of 'TCP/DTLS/BFCP' proto is to differentiate
if UDP or TCP candidate is used after the nomination.

How did you solve this issue in JSEP? I was pretty sure
that 'TCP/RTP/DTLS/SAVP' and 'TCP/DTLS/SCTP' were used there for this
purpose, but I could have missed one of the updates.

Regards,
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Oct 2018 13:44:45 -0700

On Wed, Oct 24, 2018 at 1:12 PM Roman Shpount <[email-masked]> wrote:

>> 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....
>>
>>

I don't believe any WebRTC stack does this, and to the best of my
knowledge, JSEP does not require it.

Moreover, that's not how I read the ICE-SDP draft, at least as far as
ICE-bis goes.
https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-21#section-3.3.4

"

 However, If the support for 'ice2' ice-option is in use, the
   nominated candidate is noted and sent in the subsequent offer/answer
   exchange as the default candidate and no updated offer is needed to
   fix the default candidate.
"

> purpose, but I could have missed one of the updates.

For DTLS-SRTP, JSEP requires that you generate UDP/TLS/RTP/SAVPF regardless
of the ICE candidates. Similarly, for datachannels, you must generate
UDP.DTLS/SCTP.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 24 Oct 2018 16:55:48 -0400

Hi Eric,

On Wed, Oct 24, 2018 at 4:45 PM Eric Rescorla <[email-masked]> wrote:

> Updated offer is still present when ice2 is not used.

When ice2 is used, nominated candidate still ends us as default candidate
in the subsequent offer/answer exchanges, which means ICE-TCP candidate
ends up in the m= line.

> For DTLS-SRTP, JSEP requires that you generate UDP/TLS/RTP/SAVPF
> regardless of the ICE candidates. Similarly, for datachannels, you must
> generate UDP.DTLS/SCTP.
>

I think this only covers the initial offer, but not the subsequent
exchanges.

Regards,
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Oct 2018 19:04:49 -0700

> in the subsequent offer/answer exchanges, which means ICE-TCP candidate

For the same reasons as JSEP is going to reference ICE-bis, you should do
so here, and just punt this problem.

> I think this only covers the initial offer, but not the subsequent

Well, sort of: https://github.com/rtcweb-wg/jsep/issues/854

-Ekr

---

From: Adam Roach <[email-masked]>
Date: Thu, 25 Oct 2018 01:48:41 -0500

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

---

From: Roman Shpount <[email-masked]>
Date: Thu, 25 Oct 2018 14:08:36 -0400

> so here, and just punt this problem.

We did punt the problem. We have defined proto values for all possible
protocol variations. How these proto values are going to be used with ICE
is up to ICE or ICE-bis RFCs. In the worst case  'TCP/DTLS/SCTP' ends up
being just a place holder which is never used. Since RTP and datachannel
both have proto value for the same purpose, this should not be that big of
an issue.

> Well, sort of: https://github.com/rtcweb-wg/jsep/issues/854

I will address this in the github. Thank you for providing the reference.

Regards,
_____________
Roman Shpount