[secdir] secdir review of draft-ietf-ice-trickle-16

David Mandelberg <david+work@mandelberg.org> Wed, 21 February 2018 22:09 UTC

Return-Path: <david+work@mandelberg.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5AE4B124C27 for <secdir@ietfa.amsl.com>; Wed, 21 Feb 2018 14:09:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id qKzoU1eev4jV for <secdir@ietfa.amsl.com>; Wed, 21 Feb 2018 14:09:13 -0800 (PST)
Received: from smtp.rcn.com (smtp.rcn.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D14AA12DB6B for <secdir@ietf.org>; Wed, 21 Feb 2018 14:09:11 -0800 (PST)
X_CMAE_Category: , ,
X-CNFS-Analysis: v=2.2 cv=fpieXxwf c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=Op4juWPpsa0A:10 a=bmmO2AaSJ7QA:10 a=BTUBnpS-AAAA:8 a=iiazv-oawmH03g7Men8A:9 a=QEXdDO2ut3YA:10 a=pblkFgjdBCuYZ9-HdJ6i:22
X-CM-Score: 0
X-Scanned-by: Cloudmark Authority Engine
X-Authed-Username: ZHNlb21uQHJjbi5jb20=
Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=david+work@mandelberg.org; spf=neutral; sender-id=neutral
Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=david+work@mandelberg.org; sender-id=neutral
Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN)
Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: is neither permitted nor denied by domain of mandelberg.org)
Received: from [] ([] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from <david+work@mandelberg.org>) (ecelerity r(Core: with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id DE/9C-48647-50EED8A5; Wed, 21 Feb 2018 17:09:09 -0500
Received: from [] (DD-WRT []) by uriel.mandelberg.org (Postfix) with ESMTPSA id 34D7A1C6099; Wed, 21 Feb 2018 17:09:06 -0500 (EST)
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ice-trickle.all@ietf.org
From: David Mandelberg <david+work@mandelberg.org>
Organization: David Mandelberg, LLC
Message-ID: <02c7b2a3-6e15-7a1c-7781-19cd3c8656ab@mandelberg.org>
Date: Wed, 21 Feb 2018 17:09:04 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/CM3JGkM1N8cUigejpXZ4nufhs7U>
X-Mailman-Approved-At: Mon, 26 Feb 2018 06:32:11 -0800
Subject: [secdir] secdir review of draft-ietf-ice-trickle-16
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Feb 2018 22:31:34 -0000


I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The summary of the review is: ready with nits.

(nit) Section 2: What is a "ufrag pair"? Is it short for username 
fragment pair? I might have just missed it, but I don't see a definition 
in the referenced terminology.

(nit) Section 15: If I understand correctly, the signaling protocol also 
needs to guarantee that the end-of-candidates indication is not 
re-ordered with respect to any trickled candidates. Is that correct? Is 
it worth adding to the requirements?

Freelance cyber security consultant, software developer, and more