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

"Ram Mohan R (rmohanr)" <> Mon, 17 October 2016 06:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02101129430 for <>; Sun, 16 Oct 2016 23:06:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.941
X-Spam-Status: No, score=-14.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BNr7EWQNuExm for <>; Sun, 16 Oct 2016 23:06:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AE39E129409 for <>; Sun, 16 Oct 2016 23:06:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=173950; q=dns/txt; s=iport; t=1476684404; x=1477894004; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=7qX0kv+5EnNl7QLhNHOaFL5qXh2LW8Z/5i1I0SrLKhg=; b=QnUL9jRvHIRQPuDyFnVU5rmuq5C0YrBz3RlurEALzhsH9aSQ0oLo7rBO tpxtbeXUXm0sD9czla6eQWYpCOR+OmtgU9k1RgeYRI+GD75aX1Z5Q+nNS /V8mMkTee9a1wRH7AaZrmKvPNelwVAwgMuqKwxB+D/sCgyKP4h7wvDfFC 8=;
X-Files: Diff_ draft-ietf-bfcpbis-sdp-ws-uri-05.txt - draft-ietf-bfcpbis-sdp-ws-uri-06.txt.html, draft-ietf-bfcpbis-sdp-ws-uri-06.txt : 94586, 27071
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.31,356,1473120000"; d="txt'?html'217?scan'217,208,217";a="334680798"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Oct 2016 06:06:40 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u9H66emh030223 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <>; Mon, 17 Oct 2016 06:06:40 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Oct 2016 02:06:39 -0400
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Mon, 17 Oct 2016 02:06:39 -0400
From: "Ram Mohan R (rmohanr)" <>
To: "" <>
Thread-Topic: [bfcpbis] SDP directorate review of draft-ietf-bfcpbis-sdp-ws-uri-05
Thread-Index: AQHR8BDbPcDzYcbgwUaX+wLu3Fbs6aCtOFsA
Date: Mon, 17 Oct 2016 06:06:39 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/mixed; boundary="_003_D42A67F36C347rmohanrciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [bfcpbis] SDP directorate review of draft-ietf-bfcpbis-sdp-ws-uri-05
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: BFCPBIS working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Oct 2016 06:06:49 -0000

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.


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

>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.
>bfcpbis mailing list