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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 24 Oct 2018 17:18:44 -0700

Benjamin Kaduk 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:
----------------------------------------------------------------------

I will go ahead and say that we should discuss the "UDP/TLS/BFCP" naming.
In particular, while I see the previous discussion that there may be
existing deployments out there, why can we not give it the same treatment
as "mstrm", and make the official name "UDP/DTLS/BFCP" while documenting
that you should accept the old name?

We also had a very long discussion about the usage of the term "initial
offer" in the context of draft-ietf-mmusic-sdp-bundle-negotiation; I do not
propose to rehash that discussion, but want to ask whether we should stick
to the established precedent with regard to the use of the term (which,
IIUC, would involve a change to this document).

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

Section 4

      m=<media> <port> <proto> <fmt> ...

   The media field MUST have a value of "application".

This is "For BFCP streams, the media field MUST have a value of
application", right?  I might just swap the "This section describes [...]"
paragraph to be after the exerpt from RFC4566 to avoid confusion.

   The fmt (format) list is not applicable to BFCP.  The fmt list of 'm'
   lines in the case of any proto field value related to BFCP MUST
   contain a single "*" character.  If the the fmt list contains any
   other value it is ignored.

The fmt list is ignored, or the whole m= line (and section)?

Section 5.1

The interpretation of the "c-s" value is not mentioned prior to the table
in which it appears, which kind of leaves the reader hanging.  (But I guess
that is still a style matter, so I should have no say on it.)

Table 1 could probably benefit from some discussion of how it is applied,
since (e.g.) an offer could include both c-only and c-s, and if the answere
includes s-only, the offerer needs to know which role it is performing.
It seems like this would be "the offerer proceeds through the following
table, and if the offer and answer included the values present in the
current line of the table, that line is a match and determines what role
the offerer will use".
(This would be a DISCUSS but I am not convinced that there is a way to
actually do the wrong thing as an implementation.)

   Endpoints compliant with [RFC4583] might not include the 'floorctrl'
   attribute in offers and answerer.  If the 'floorctrl' attribute is
   not present the offerer will act as floor control client, and the
   answerer will act as floor control server.

I assume this is going to be backwards compatible, but it might be worth
explicitly saying so.

Section 5.4, 5.5

I'd go with "decimal integer representation" for consistency with the
preceding sections.

Section 7

      Note: When using Interactive Connectivity Establishment (ICE)
      [RFC8445], TCP/DTLS/BFCP, and UDP/TLS/BFCP, the straight-forward
      procedures for connection management as UDP/BFCP described above
      apply.  [...]

nit: this sentence as written applies only when all three of ICE,
TCP/DTLS/BFCP, and UDP/TLS/BFCP apply (which is nonsensical).  I assume the
intended grouping is: (1) ICE is used, and (2) either TCP/DTLS/BFCP or
UDP/TLS/BFCP is used.

Section 8

   When TLS is used with TCP, once the underlying connection is
   established, the answerer always acts as the TLS server.  If the TCP
   connection is lost, the active endpoint is responsible for re-
   establishing the TCP connection.  Unless a new TLS session is
   negotiated, subsequent SDP offers and answers will not impact the
   previously negotiated TLS roles.

IMPORTANT: "TLS session" is a term of art, and is in fact nonsensical here.
I think that you mean "TLS connection" or maybe "TLS handshake".

Section 10

   If the 'm' line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP' or
   'UDP/TLS/BFCP', the offerer and answerer follow the generic
   procedures defined in [RFC8122].

Why is 8122 the reference even for the DLTS values (as opposed to
mmusic-dtls-sdp)?

Section 10.2

So the answerer can indicate multiple BFCP versions in the bfcpver
attribute and is not using that attribute to indicate the selected BFCP
version in use?

A ref to RFC 4145 for the 'active' endpoint might be helpful.

Section 10.3

The "Note" is indented as if it is part of the list, but it should not be
part of the list.

Section 10.4

   When an offerer sends an updated offer, in order to modify a

My knowledge of SDP is rusty (and was sparse to begin with), but can't the
answerer also send a mid-session offer to start renegotiation of various
parameters?  That is, it is not just the offerer that can send an offer
during an existing session.

Section 12

It's probably worth noting explicitly that the non-(D)TLS proto values
offer neither integrity protection nor confidentiality protection to the
BFCP stream.

An attacker able to view the SDP exchanges can determine which media flows
contain which content, which could exacerbate existing metadata leakage
channels in some circumstances.

As Ekr notes in his comment, the potential for privacy considerations
relating to the various identifiers transmitted in the session description
should be discussed.  If the various integer IDs are just local to the
physical premises (even better if they're periodically randomized!), the
impact is going to be fairly limited, but should still be covered.

Section 14

   2.  Authentication (Section 8):
       In last paragraph, made clear that a TCP connection was
       described.

I'm rather confused at what this is attempting to describe.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Oct 2018 21:36:13 -0500

> On Oct 24, 2018, at 7:18 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

[...]

> IIUC, would involve a change to this document).

IIRC* subsequent discussion in MMUSIC decided that the important thing was to be clear on how you use the term.

* It’s entirely possible I do not. i think that was during the power failure, and I may have been distracted :-)

[...]

---

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

> * It’s entirely possible I do not. i think that was during the power failure, and I may have been distracted :-)

That matches my memory.

/a

---

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

That would cause unrecoverable errors when a new client sends an offer 
to a legacy client. That's a pretty bad backwards-compatibility story. I 
get why the current value is ugly, but I don't think making new clients 
fail to talk to old ones is a fair price for aesthetic adjustments.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Oct 2018 07:15:00 +0000

Hi,

In Montreal/MMUSIC we discussed getting rid of the "initial offer" terminology all together, and replace it with something else (different terminology and section structure).

However, since then we have not really been able to incorporate a new approach yet, so we have more or less kept the existing terminology/structure, and added clarification text what "initial offer" means. We did that also in 4583bis. Section 10 says:

   "Within this document, 'initial offer' refers to the first offer,
   within an SDP session (e.g. a SIP dialog when the Session Initiation
   Protocol (SIP) [RFC3261] is used to carry SDP), in which the offerer
   indicates that it wants to negotiate the establishment of a BFCP
   stream."

Regards,

Christer

On 25/10/2018, 9.50, "Adam Roach" <[email-masked]> wrote:

    That matches my memory.
    
    /a

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 25 Oct 2018 06:20:03 -0500

> fail to talk to old ones is a fair price for aesthetic adjustments.

I'm not 100% sure I understand the "unrecoverable" nature -- would this
cause the entire m= section to be ignored, or the negotiation to fail
completely?

-Benjamin

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 25 Oct 2018 11:30:49 +0000

Hi,

    >cause the entire m= section to be ignored, or the negotiation to fail
    
    It would at least cause the m= section to be rejected.

    Whether the whole session negotiation will fail depends on whether the answerer wants to continue the session without BFCP or not.

Regards,

Christer