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

["Ram Mohan R (rmohanr)" <[e-mail]>]

Sorry for getting back late on this. We have addressed the comments given
by Dan. Please find the diffs.
I will publish this in a few days if I don¹t receive any further feedback.

Regards,
Ram

-----Original Message-----
From: bfcpbis <[e-mail]> on behalf of "Dan Wing (dwing)"
<[e-mail]>
Date: Sunday, 7 August 2016 at 12:01 AM
To: "[e-mail]"
<[e-mail]>, "[e-mail]"
<[e-mail]>
Cc: "[e-mail]" <[e-mail]>,
"[e-mail]" <[e-mail]>
Subject: [bfcpbis] SDP directorate review of
draft-ietf-bfcpbis-sdp-ws-uri-05

>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
>
>_______________________________________________
>bfcpbis mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/bfcpbis