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

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

Return-Path: <rmohanr@cisco.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02101129430 for <bfcpbis@ietfa.amsl.com>; Sun, 16 Oct 2016 23:06:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.941
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNr7EWQNuExm for <bfcpbis@ietfa.amsl.com>; Sun, 16 Oct 2016 23:06:45 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE39E129409 for <bfcpbis@ietf.org>; Sun, 16 Oct 2016 23:06:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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-Anti-Spam-Result: =?us-ascii?q?A0A9AwD2aARY/5pdJa1aAhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8AQEBAQEdV3wHjS2XApQ4ggUDHQEKhCCBEEoCghYUJBQBAgE?= =?us-ascii?q?BAQEBAQFeHAuEYQEBAQQBAQEXARI6BxcEAgEIEQMBAhcKAQ0CJQsdCAIECgkOi?= =?us-ascii?q?EQOuiGHWAEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4PixKEDgsRAQYiCwkoC4UMBYY?= =?us-ascii?q?fgh2GAzuHUYM7AYM/gmiDBoMEg1KBbhc3hBmHeYEnjHuDfwEeNlKCQ4IqcgGGK?= =?us-ascii?q?g0XB4ECgQABAQE?=
X-IronPort-AV: E=Sophos;i="5.31,356,1473120000"; d="txt'?html'217?scan'217,208,217";a="334680798"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Oct 2016 06:06:40 +0000
Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u9H66emh030223 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <bfcpbis@ietf.org>; Mon, 17 Oct 2016 06:06:40 GMT
Received: from xch-rtp-017.cisco.com (64.101.220.157) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 17 Oct 2016 02:06:39 -0400
Received: from xch-rtp-017.cisco.com ([64.101.220.157]) by XCH-RTP-017.cisco.com ([64.101.220.157]) with mapi id 15.00.1210.000; Mon, 17 Oct 2016 02:06:39 -0400
From: "Ram Mohan R (rmohanr)" <rmohanr@cisco.com>
To: "bfcpbis@ietf.org" <bfcpbis@ietf.org>
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: <D42A67F3.6C347%rmohanr@cisco.com>
References: <47B42250-B5FF-4D58-BA7B-4CCDB218F37C@cisco.com>
In-Reply-To: <47B42250-B5FF-4D58-BA7B-4CCDB218F37C@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.8.160830
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.196.92.25]
Content-Type: multipart/mixed; boundary="_003_D42A67F36C347rmohanrciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/f_mYbNZmSstHBvWL0XHRe1RCPMM>
Subject: Re: [bfcpbis] SDP directorate review of draft-ietf-bfcpbis-sdp-ws-uri-05
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=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.

Regards,
Ram

-----Original Message-----
From: bfcpbis <bfcpbis-bounces@ietf.org> on behalf of "Dan Wing (dwing)"
<dwing@cisco.com>
Date: Sunday, 7 August 2016 at 12:01 AM
To: "draft-ietf-bfcpbis-sdp-ws-uri@tools.ietf.org"
<draft-ietf-bfcpbis-sdp-ws-uri@tools.ietf.org>rg>, "bfcpbis@ietf.org"
<bfcpbis@ietf.org>
Cc: "mmusic-chairs@tools.ietf.org" <mmusic-chairs@tools.ietf.org>rg>,
"bfcpbis-chairs@tools.ietf.org" <bfcpbis-chairs@tools.ietf.org>
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
>bfcpbis@ietf.org
>https://www.ietf.org/mailman/listinfo/bfcpbis