[bfcpbis] SDP directorate review of draft-ietf-bfcpbis-sdp-ws-uri-05

[🔓Dan Wing <[e-mail]>]

My review of draft-ietf-bfcpbis-sdp-ws-uri-05 as part of the SDP directorate review.


Overall review feedback:

1. How does draft-ietf-bfcpbis-sdp-ws-uri interact and work with ICE, and IPv6/IPv4 address preference in the OS?
2. The active/passive text has me nervous, especially considering that draft-ietf-bfcpbis-bfcp-websocket-10 says:
"   BFCP WebSocket clients cannot receive incoming WebSocket connections
   initiated by any other peer.  This means that a BFCP WebSocket client
   MUST actively initiate a connection towards a BFCP WebSocket server."
Is the active/passive stuff really necessary, or can it be simplified for the common use case where the BFCP server is a server, on the Internet, and thus doesn't need ICE and thus the clients always initiate connection to it, and the clients only validate its certificate and the clients do not include their certificate in TLS ClientHello.  (see comments below, too, about client certificate).


Specific review feedback:


Section 1, "Introduction":
   While it is possible to generate self-signed certificates with
   Internet Providers (IPs) as CNAME, in most cases it is not viable for
   certificates signed by well known authorities. 

I can't make sense of that sentence standalone, or within its paragraph.  Is it trying to say IP address (rather than Internet Provider), and is it trying to say self-signed certificates are not viable?  I encourage the authors to review that entire paragraph for consistency, as it is an important paragraph justifying the entire SDP work, but this sentence needs special attention and re-writing.  This sentence needs to be fixed in the document.


Section 3.2 and 3.3, "ws-uri SDP Attribute" and "wss-uri SDP Attribute", these comments apply to both sections:

   When the 'ws-uri' attribute is present in the media section of the
   SDP, the IP address in 'c= ' line SHALL be ignored and the full URI
   SHALL be used instead to open the WebSocket connection.

Later in section 4.2, an example shows using port 9 (discard port).  Do you want to consider making that a requirement, so we never have issues of disagreeing ports?

The document needs to clarify if IPv6 or IPv4 are attempted simultaneously, if all A and AAAA records are used per some order or only first, if a Happy Eyeballs-like algorithm is needed, or something else.  Document needs to discuss DNS failure.  I wonder how devices like cellular phones supporting this SDP would acquire a DNS name, but I guess we could declare that out of scope of this I-D, and it is something else's problem.

   The port
   provided in the 'm= ' line SHALL be ignored too, as the 'a=ws-uri'
   SHALL provide port number when needed.

Please clarify in the document if the default web socket ports (80 and 443) are used, or if some other default port algorithm is used.


Section 3.3, "wss-uri SDP Attribute", does not discuss if the certificates presented in TLS handshake need to match, or what happens if they don't match, or if the certificate needs to be chased up the certificate validation trust chain.  This more appropriately belongs in the new section that I suggest below for the 'active' connection.


Section 4.2, "Generating the Initial Offer"

   If the offerer assigns the SDP "setup" attribute
   with a value of "passive", the offerer MUST be prepared to receive an
   incoming TCP connection on the IP and port tuple advertised in the
   "c=" line and audio/video ports of the BFCP media stream before it
   receives the SDP answer.

The sentence above conflicts with ignoring the 'c=' line in Sections 3.2 and 3.3, and using the port number of the URI in a=ws-uri or a=wss-uri.  The document needs to resolve this conflict.

 
Section 4.3, Generating the Answer

Should DNS be queried before, or after, generating the answer?  Or is that a quality of implementation issue?

The section needs a paragraph saying the offer and answer have to align with "ws" or "wss".  That is, if the offer was for (un-)encrypted WebSockets, the answer has to be, too.


   ... If the answerer assigns an SDP "setup" attribute with a value of
   "active", the answerer MUST initiate the WebSocket connection
   handshake by acting as client on the negotiated media stream, towards
   the IP address and port of the offerer using the procedures described
   in [RFC6455].

Does it also send a GET, like what is described in 4.4??  In any event, my point is that 4.4 and 4.3 do not align on the exact procedure for the "active" side.  It should.  And the "active" procedure (IPv6/IPv4, DNS error, ICE) should be more carefully detailed -- probably in its own separate section so there is no risk of accidental different procedures or interpretation.


Overall, it seems only the server's certificate is validated, and -- unlike DTLS-SRTP -- the client's certificate is never sent?  Is that correct?   This is the typical web model of security, but is not the typical peer-to-peer model of security.  This seems useful to point out in Security Considerations.

-d