[clue] Benjamin Kaduk's Discuss on draft-ietf-clue-signaling-14: (with DISCUSS and COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Mon, 19 November 2018 23:56 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: clue@ietf.org
Delivered-To: clue@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C12124C04; Mon, 19 Nov 2018 15:56:22 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-clue-signaling@ietf.org, "Daniel C. Burnett" <danielcburnett@gmail.com>, Roni Even <roni.even@mail01.huawei.com>, clue-chairs@ietf.org, roni.even@mail01.huawei.com, clue@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.88.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154267178201.26570.2400616201103578148.idtracker@ietfa.amsl.com>
Date: Mon, 19 Nov 2018 15:56:22 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/clue/e1zW7FBQntsBBmjdw7I2vtke9TQ>
Subject: [clue] Benjamin Kaduk's Discuss on draft-ietf-clue-signaling-14: (with DISCUSS and COMMENT)
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.29
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Nov 2018 23:56:22 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-clue-signaling-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 11.2 of the IANA considerations lists an actual OID value to use for the "sip.clue" media feature tag, but the IANA last call review indicates that the decimal value for sip.clue will be assigned at registration, so it is incorrect to claim that it will be 1.3.6.1.8.4.29. Squatting on the next available codepoint like this is quite risky and I really want to discourage this practice. We had a lot of trouble in TLS recently with *three* different extensions attempting to use the same codepoint, which was not fun to resolve. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please consider using the RFC 8174 version of the BCP 14 boilerplate. Section 3 The "sip.clue" media feature tag SIP [RFC3840] indicates support for CLUE in SIP [RFC3261] calls. nit: I think there's a missing word or three here; maybe "for SIP"? Section 4.3 The restrictions on CLUE-controlled media always apply to "m=" lines in an SDP offer or answer, even if negotiation of the data channel in [...] I'm not entirely sure I understand what "the restrictions" are, here. Unless this is supposed to just be the general requirements for how they are (not) sent? Section 4.4.1.1 Each <encID> (in encodingIDList) in a CLUE ADVERTISEMENT message SHOULD represent an Encoding defined in SDP; the specific Encoding referenced is a CLUE-controlled "m=" line in the most recent SDP sent ^^^^^^^^^^^^^^^ by the sender of the ADVERTISEMENT message with a label value corresponding to the text content of the <encID>. Is this "most recent SDP Offer/Answer"? (Similarly in the following paragraph.) I'm also not sure why these are SHOULD- instead of MUST-level requirements, modulo the non-atomicity mentioned in the final paragraph of the section. Section 4.5.1 [I will leave it to Adam to check that the "initial offer" terminology is being used in the consensus manner, since I haven't been tracking what manner that is.] Section 4.5.2.2 (Also in 4.4.1.1) Am I reading this correctly that with the initial offer, we are talking about negotiating media lines with labels that correspond to CLUE Encoding names that have not yet been present in any CLUE messages (that is, we're doing it "blind")? Section 4.5.4.2 group then the call is now CLUE-enabled; negotiation of the data channel and subsequently the CLUE protocol begin. nit: begins Section 4.5.4.4 o The CLUE protocol enters an unrecoverable error state as defined in Section 6. of [I-D.ietf-clue-protocol], either the 'MP- TERMINATED' state for the Media Provider or 'MC-TERMINATED' for the Media Consumer. The MP-TERMINATED and MC-TERMINATED states do not seem to exist in the -17 of the protocol document. (I'm assuming this is essentially editorial in nature and doesn't need to be part of the DISCUSS section.) Section 5.1 The primary implication of this is that a device may receive an SDP with a CLUE Encoding for which it does not yet have Capture [...] presumably this is "SDP Offer/Answer" as well? A device with the CLUE Participant state machine in the ACTIVE state MAY choose not to move from ESTABLISHED to ADV (Media Provider state machine) or from ESTABLISHED to WAIT FOR CONF RESPONSE (Media Consumer state machine) based on the SDP state. [...] Is this "choose not to move", "choose to not move", or "chose whether or not to move"? Section 5.2 : an implementation MUST NOT send a specific CLUE Capture Encoding unless its most recent SDP exchange contains an active media channel for that Encoding AND the far end has sent a CLUE CONFIGURE message specifying a valid Capture for that Encoding. nit: "far end" is perhaps a bit informal; "peer" or "MC" might be alternatives. I guess technically this also doesn't require that he CONFIGURE parsed correctly and was accepted, which is arguably a bug. Section 8 With the successful initial SDP Offer/Answer exchange complete Alice and Bob are also free to negotiate the CLUE data channel. This is illustrated as CLUE DATA CHANNEL ESTABLISHED. Once the data channel is established CLUE protocol negotiation begins. In this case Bob chose to be the DTLS client (sending a=active in his SDP answer) and hence is the CLUE Channel Initiator and sends a CLUE OPTIONS message describing his version support. On receiving that message Alice sends her corresponding CLUE OPTIONS RESPONSE. My understanding was that the DTLS connection was a prerequisite for setting up the CLUE data channel (so I would have been less confused if the note about DTLS client was in the first paragraph). There are some instances of "CLUE channel" in this section that might be better as "CLUE data channel". Is it normal for the mid of the CLUE data channel to be changing around in the various SDP snippets shown in these examples? Section 12 This attack can be prevented by ensuring that the media recipient intends to receive the media packets. As such all CLUE-capable devices MUST support key negotiation and receiver intent assurance via DTLS-SRTP [RFC5763] on CLUE-controlled RTP "m=" lines. All CLUE- controlled RTP "m" lines must be secured and implemented using mechanisms such as SRTP [RFC3711]. CLUE implementations MAY choose not to require the use of SRTP to secure legacy (non-CLUE-controlled) media for backwards compatibility with older SIP clients that are incapable of supporting it. Should these normative requirements be placed somewhere in the main body of this (or some other) document in addition to their necessity being described in the security considerations here? Section 14.2 Should-ietf-rtcweb-data-channel be a normative reference? (It seems like it should be so at least in draft-ietf-clue-datachannel, which is not on this week's telechat.) I think that RFC 3840 should be normative here, though, since you have to use it to enable CLUE. There's probably others, though I'd be inclined to consider at least the core SIP and SDP specs as "basic specifications" (per https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/) that do not need to be normative.
- [clue] Benjamin Kaduk's Discuss on draft-ietf-clu… Benjamin Kaduk