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

🔓Dan Wing <dwing@cisco.com> Sat, 06 August 2016 18:32 UTC

Return-Path: <dwing@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 4051C12B05C for <bfcpbis@ietfa.amsl.com>; Sat, 6 Aug 2016 11:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.768
X-Spam-Level:
X-Spam-Status: No, score=-15.768 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, 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 DHiWvo7AsX0p for <bfcpbis@ietfa.amsl.com>; Sat, 6 Aug 2016 11:32:10 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E793C12B054 for <bfcpbis@ietf.org>; Sat, 6 Aug 2016 11:32:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5239; q=dns/txt; s=iport; t=1470508329; x=1471717929; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=RJ4LHy0ljKTJUhWoeCCXncqkHOfUdTZUuWfdiR96IIM=; b=Qqhbf8HshPWigCmkLy7e9WsnjRrW/CNTE+pL7HPSP1BcyabxUTrkYNC0 DMsT1X4jrvkqonRuEqXIv2s1xO+ZAUuF8+splLsE+j27BQr/Db8JBy0Vc 28HDM38fpqE2dhj+bqKHzxTNU7dTqxmCh4dtjCH+CIaZ3kYXPWULS+SAg M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C7EgCBLKZX/4wNJK1dg0W6YYF9hh2BL?= =?us-ascii?q?BQmEgEBAQEBAQFdJ4UfP4E/iEPBHwEBAQcBAQEBAQEBIIYqgXiGf4NCgi8Fhgy?= =?us-ascii?q?IDHWKLIkZgnOCfoFrhFuDD4VukCwlAS6EGhyFaSuBGAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.28,479,1464652800"; d="scan'208";a="132701721"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Aug 2016 18:32:08 +0000
Received: from [10.24.108.237] ([10.24.108.237]) (authenticated bits=0) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u76IW79Q020230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Aug 2016 18:32:08 GMT
From: =?utf-8?Q?=F0=9F=94=93Dan_Wing?= <dwing@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sat, 6 Aug 2016 11:31:50 -0700
Message-Id: <47B42250-B5FF-4D58-BA7B-4CCDB218F37C@cisco.com>
To: draft-ietf-bfcpbis-sdp-ws-uri@tools.ietf.org, bfcpbis@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
X-Authenticated-User: dwing
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/fobMAtc2dmLakNmVxLPJo1um5qk>
Cc: mmusic-chairs@tools.ietf.org, bfcpbis-chairs@tools.ietf.org
Subject: [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: Sat, 06 Aug 2016 18:32:11 -0000

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