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

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Mon, 15 August 2016 14:45 UTC

Return-Path: <eckelcu@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 001C312DAB0 for <bfcpbis@ietfa.amsl.com>; Mon, 15 Aug 2016 07:45:37 -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 miuy3jTTLpW5 for <bfcpbis@ietfa.amsl.com>; Mon, 15 Aug 2016 07:45:35 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B83112DAA6 for <bfcpbis@ietf.org>; Mon, 15 Aug 2016 07:45:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7760; q=dns/txt; s=iport; t=1471272335; x=1472481935; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NS+cQPdOWouLVl1ct5dvjZXhns03DsHuzEDUkTbc0v0=; b=Wn2LHD48eGusLO03t0ZNoCL77HPQfGHAM2ZLUZWuEj74V1H0cFqHxAbb ElK1N4HNrsPy5FpTZ1deOFRHjVZLq9/6TC5Sn54l2maJxzbcIMT2Ja7W/ k3VzNo7Cw+BPfznoYi2fFWlTzpTN0P8IOal4UwxDzbFZE4DWGZjFLM/as o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CkCQBU1LFX/4MNJK1eg0VWfAe5NIF9J?= =?us-ascii?q?IUvSgIcgTAUJBQCAQEBAQEBAV4nhF8BBQEBIRE3AwsQAgEIGgImAgICJQsVEAI?= =?us-ascii?q?EAQ0FG4gWDq1EkCYBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBhyEIgk2EKhaDA?= =?us-ascii?q?SuCLwWGDogNiyMBiRuCeIMCgWuEW4h9kC4BHjaDem6FYSsZfwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.28,525,1464652800"; d="scan'208";a="310162180"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Aug 2016 14:45:34 +0000
Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u7FEjYGA031493 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Aug 2016 14:45:34 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 15 Aug 2016 09:45:32 -0500
Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1210.000; Mon, 15 Aug 2016 09:45:32 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: "Dan Wing (dwing)" <dwing@cisco.com>, "draft-ietf-bfcpbis-sdp-ws-uri@tools.ietf.org" <draft-ietf-bfcpbis-sdp-ws-uri@tools.ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Thread-Topic: [bfcpbis] SDP directorate review of draft-ietf-bfcpbis-sdp-ws-uri-05
Thread-Index: AQHR8BDbaopj/7lGikmxon5CA9e4VqBKBbkA
Date: Mon, 15 Aug 2016 14:45:32 +0000
Message-ID: <802ACBC2-2761-4159-8A79-0F1F618DA1FB@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:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.15.1.160411
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.20.182.35]
Content-Type: text/plain; charset="utf-8"
Content-ID: <166CE68AC56113488C1BC584C22C414A@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bfcpbis/lsPA4kvd2niRevpDnC31YTM9b8U>
Cc: "mmusic-chairs@tools.ietf.org" <mmusic-chairs@tools.ietf.org>, "bfcpbis-chairs@tools.ietf.org" <bfcpbis-chairs@tools.ietf.org>
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, 15 Aug 2016 14:45:38 -0000

Dan,

As working group chair, thank you for your expert review of this draft. The draft authors are considering your comments and will respond with proposed solutions for the points you have raised.

Cheers,
Charles




On 8/6/16, 11:31 AM, "bfcpbis on behalf of Dan Wing (dwing)" <bfcpbis-bounces@ietf.org on behalf of dwing@cisco.com> wrote:

>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