[ippm] Benjamin Kaduk's No Objection on draft-ietf-ippm-twamp-yang-11: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Mon, 18 June 2018 16:18 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: ippm@ietf.org
Delivered-To: ippm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62430130E04; Mon, 18 Jun 2018 09:18:14 -0700 (PDT)
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-ippm-twamp-yang@ietf.org, Nalini Elkins <nalini.elkins@insidethestack.com>, ippm-chairs@ietf.org, nalini.elkins@insidethestack.com, ippm@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.81.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152933869439.3647.15290297683322606646.idtracker@ietfa.amsl.com>
Date: Mon, 18 Jun 2018 09:18:14 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/ScSX_8w3ODmBK8IZ7Vg-TGEIfuA>
Subject: [ippm] Benjamin Kaduk's No Objection on draft-ietf-ippm-twamp-yang-11: (with COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.26
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2018 16:18:24 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-ippm-twamp-yang-11: No Objection 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-ippm-twamp-yang/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Perhaps I am confused and/or misreading things, but the descriptions of the control-client and session-reflector include discussion of 'sid' session identifiers as if they were always used, but the mode bitmap includes a separate bit for negotiation of 'individual-session-control' for session identifier usage. Is there some conflict between this mandatory/negotiable distinction, or are they actually talking about different things? Comments below in document order, but please pay special note to the (potential) need for global uniqueness of key-ids, the PBKDF2 iteration count, and the list of sensitive nodes to call out in the security considerations. Section 3.1 o Authentication and encryption attributes such as KeyID, Token and the Client Initialization Vector (Client-IV); see also the last paragraph of Section 6 in OWAMP [RFC4656] and Randomness Requirements for Security [RFC4086]. I'm confused about what the RFC4656 reference is intended to call out -- the reliance on AES to be resistant to chosen plaintext, or the randomly generated challenge from the server, or the existential forgeries? o Information pertaining to the test packet stream, such as the test starting time, which performance metric is to be used Registry for Performance Metrics [I-D.ietf-ippm-metric-registry], or whether the test should be repeated. Is there something missing before or around "Registry for Performance Metrics"? The current text is hard to read. Section 3.4 Each Session-Reflector is associated with zero or more TWAMP-Test sessions. For each test session, the REFWAIT timeout parameter which determines whether to discontinue the session if no packets have been received (TWAMP [RFC5357], Section 4.2) can be configured. nit: I think this would be easier to read if "which determines...received" was offset by commas or parentheses. Read-only access to other data model parameters, such as the Sender IP address is foreseen. Each test session can be uniquely identified by the 4-tuple mentioned in Section 3.2. Nit: comma after "Sender IP address". Section 4.1 [...] Specifically, mode-preference-chain lists the mode and its corresponding priority, expressed as a 16-bit unsigned integer, where zero is the highest priority and subsequent integers increase by one. I thought I remembered some discussion about this text being unclear and removing "and subsequent integers increase by one" being proposed. But I don't see that discussion in an obvious place, so maybe it was on a different document. Note that the list of preferred Modes may set bit position combinations when necessary, such as when referring to the extended [...] Maybe "may set multiple bits independently" would be more clear? But it seems that some bit combinations don't make any sense, like unauthenticated+authenticated -- is there need for more expository text here? [...] The secret-key is the shared secret, a sequence of octets of arbitrary length whose interpretation is unspecified. The key-id and secret-key encoding SHOULD follow Section 9.4 of YANG [RFC7950]. [...] Section 9.4 of YANG is for (printable) strings, but the secret-key is binary -- should this get a Section 9.8 reference as well? I'm also not sure that leaving it as "arbitrary length" is great -- if we're using it to derive 16-byte AES keys and 32-byte HMAC-SHA1 keys, we could at least say "SHOULD contain at least 128 bits of entropy". Section 4.2 [...] The Server, being prepared to conduct sessions with more than one Control-Client, uses KeyIDs to choose the appropriate secret-key; a Control-Client would typically have different secret keys for different Servers. key-id tells the Server which shared-secret the Control-Client wishes to use for authentication or encryption. Does this imply a global uniqueness requirement for key-ids? If so, that should be called out more clearly. Section 4.3 | name | | ctrl-connection-name {ro} | | fill-mode | | number-of-packets | | state {ro} | | sent-packets {ro} | | rcv-packets {ro} | | last-sent-seq {ro} | | last-rcv-seq {ro} | +---------------------------+ nit: should the "{ro}" on "state" be right-aligned with the others? Is there any privacy concern about exposing the parent-connection 4-tuple? Section 5.2 In the 'count' leaf, a default value of 10 (corresponding to an iteration count of 2^10 == 1024 for PBKDF2) is described. This seems quite low for a PBKDF2 iteration count, by modern standards. In "normal" cryptographic protocols we would generally be using a default closer to 32768 == 2^15 (which I see is the default *max* count value, and there is additional discussion of the issue in the leaf description for that leaf). Perhaps one could make an argument that this is just for test setups and the keys and data exchanged are "not very valuable", but there is always risk of key sharing across protocols, and my preference is to present the strong defaults and give users the option to reduce where appropriate. What are the authors' thoughts here? Section 7 There are probably more nodes that can get called out as particularly vulnerable, such as the count and max-count nodes that can cause a long time to be spent on PBKDF2 iterations, the dscp markings, the mode bitmask, etc. Appendix A The <secret-key> elements appear to be using base64-encoded values. Where is it specified that such encoding is used for the binary values? (I assume this is just my ignorance of a generic standard, so please enlighten me!) Am I reading it right that the <count>30</count> means 2^30 (one billion) PBKDF2 iterations? Has this actually been run in practice? It seems like it would be painfully slow.
- Re: [ippm] Benjamin Kaduk's No Objection on draft… Benjamin Kaduk
- Re: [ippm] Benjamin Kaduk's No Objection on draft… t.petch
- Re: [ippm] Benjamin Kaduk's No Objection on draft… Mahesh Jethanandani
- Re: [ippm] Benjamin Kaduk's No Objection on draft… Benjamin Kaduk
- Re: [ippm] Benjamin Kaduk's No Objection on draft… MORTON, ALFRED C (AL)
- [ippm] Benjamin Kaduk's No Objection on draft-iet… Benjamin Kaduk
- Re: [ippm] Benjamin Kaduk's No Objection on draft… Benjamin Kaduk
- Re: [ippm] Benjamin Kaduk's No Objection on draft… Mahesh Jethanandani