Re: [ippm] Adam Roach's Discuss on draft-ietf-ippm-twamp-yang-11: (with DISCUSS and COMMENT)

Mahesh Jethanandani <mjethanandani@gmail.com> Sun, 01 July 2018 20:55 UTC

Return-Path: <mjethanandani@gmail.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1819130E1E; Sun, 1 Jul 2018 13:55:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YZWy1K77UGnA; Sun, 1 Jul 2018 13:55:24 -0700 (PDT)
Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD3F6130DC9; Sun, 1 Jul 2018 13:55:24 -0700 (PDT)
Received: by mail-pf0-x22d.google.com with SMTP id z24-v6so6501937pfe.7; Sun, 01 Jul 2018 13:55:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/IHm4m5jz41yB71kp78Pr/dTCZQc8XBD5qg6IiZ7NEY=; b=Z7HIM6FQLTUp/e9xjmb2RjvogaW+rXrmDuPHc6AsL5Oi1AoEju7TmvwvHwn/dTe6A3 umnQkptLHRnSO3rq+w9kGOH98wmjLwFVSUljwA2xpHnB00XQb7TWxWOIXE66guUDpd8F xGA1SZJeVhhSTfeZ6PxxVZFXPF7jRUbJ8U8GeTSD4FXs6nbmXR5k0qRmXKFCFlU/dZyg DathmVkQ753XbDWFv67E29WFVRb0pSXzclCwxbuLwM52MhY0xlZUWUGfBrx0ieS/aeXy WgF3BAu10r7E4A8UTvWuJ7IITVQ8atcrj8kCxM+jYqBY0A77NZkOgGog+hTe53y7nKG9 yjZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/IHm4m5jz41yB71kp78Pr/dTCZQc8XBD5qg6IiZ7NEY=; b=HCvIpzlCwshrVGOz9Zw51aCfeofEX+T2/IjpNh5fPaehAX1uRjPO4vDvIqXaBvCkCJ kOQcKYPQ1pQLaR56fY0vUFKEjMFs9cj7ed5D4skxzG31ZZbIIa1lKPIZqresPioqPvku cCuFCLRaPUuDDqq6HvpmjvQKW3dRPWRx7TKbK8e6EwYWTyCANj6jj4Rp1tIzgRklPFlW 9nTjbU02FakH7rNJ8Z8qyhfT1YtlxFRqjldK5xRH+91UUZu9O+6XAjPDThDzR7o8Pw8i zSdg3HaQggyAERinbawgLpPpbvNbWQ+C1gB/BkYEr4TRPyP7Y3GO1NDKbaUKhqPSOhB/ A0mQ==
X-Gm-Message-State: APt69E25CN9tdb715zzkqW60Y7MJByH6DWyXdlzHUrWNBXYdS57SJWvH kTbfWv/1yP446lHCigpeNzg=
X-Google-Smtp-Source: ADUXVKJiQX+BFwQNmQRzcxDamGddJUgXqzzggymaNltCGJMFHP9A4+h/koX9Ocl2YCRi7yTWOJWzHA==
X-Received: by 2002:a65:5686:: with SMTP id v6-v6mr19558967pgs.141.1530478524028; Sun, 01 Jul 2018 13:55:24 -0700 (PDT)
Received: from ?IPv6:2607:fb90:9c56:8b26:ac44:e224:db38:dff6? ([2607:fb90:9c56:8b26:ac44:e224:db38:dff6]) by smtp.gmail.com with ESMTPSA id z10-v6sm21612346pfh.83.2018.07.01.13.55.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 01 Jul 2018 13:55:22 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
X-Mailer: iPhone Mail (14G60)
In-Reply-To: <20180701185831.GD22125@kduck.kaduk.org>
Date: Sun, 01 Jul 2018 13:55:21 -0700
Cc: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>, ippm-chairs@ietf.org, Adam Roach <adam@nostrum.com>, Nalini Elkins <nalini.elkins@insidethestack.com>, ippm@ietf.org, draft-ietf-ippm-twamp-yang@ietf.org, The IESG <iesg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <39B43C72-59B3-4625-BA4D-4C6C565F9749@gmail.com>
References: <152955610162.28620.13249468338471662781.idtracker@ietfa.amsl.com> <063FD288-AF03-43B0-A519-5BFE418D3DC0@gmail.com> <CAKKJt-enitr0uC37-x3dJR13o4Ju-3b3SSjyR_qo=rGi1v=Dyg@mail.gmail.com> <5C8A4F3E-3FE0-4EBB-8A60-C974769DBB0C@gmail.com> <20180701185831.GD22125@kduck.kaduk.org>
To: Benjamin Kaduk <kaduk@mit.edu>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/27k2PaY4U43lj0Iv-iEskPRuTME>
Subject: Re: [ippm] Adam Roach's Discuss on draft-ietf-ippm-twamp-yang-11: (with DISCUSS and COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
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: Sun, 01 Jul 2018 20:55:27 -0000

Hi Ben,

Sent from my iPhone
> On Jul 1, 2018, at 11:58 AM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> (Also not the Adam interpreter)
> 
>> On Fri, Jun 29, 2018 at 12:19:53PM -0700, Mahesh Jethanandani wrote:
>> Hi Spencer,
>> 
>>> On Jun 29, 2018, at 8:08 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
>>> 
>>> Hi, Manesh, 
>>> 
>>> On Fri, Jun 22, 2018 at 2:14 PM Mahesh Jethanandani <mjethanandani@gmail.com <mailto:mjethanandani@gmail.com>> wrote:
>>> Hi Adam,
>>> 
>>>> On Jun 20, 2018, at 9:41 PM, Adam Roach <adam@nostrum.com <mailto:adam@nostrum.com>> wrote:
>>>> 
>>>> Adam Roach has entered the following ballot position for
>>>> draft-ietf-ippm-twamp-yang-11: 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 <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/ <https://datatracker.ietf.org/doc/draft-ietf-ippm-twamp-yang/>
>>>> 
>>>> 
>>>> 
>>>> ----------------------------------------------------------------------
>>>> DISCUSS:
>>>> ----------------------------------------------------------------------
>>>> 
>>>> Thanks for the work and thought that everyone involved in this document spent. I
>>>> find the model well described and easy to understand.
>>>> 
>>>> I agree with Ben's comments about including more information about the privacy
>>>> and security properties of specific entities in the module. See
>>>> https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines> for specific
>>>> guidance.
>>>> 
>>>> Since this conflicts with normative language in RFC 6087 §3.4 (and 6087bis
>>>> §3.7), it is a blocking defect that needs to be remedied prior to publication.
>>> 
>>> I have added more nodes in the Security Considerations section.
>>> 
>>> I'm not the Adam Interpreter, but I'm seeing considerable new discussion about the MTI security for NETCONF and RESTCONF, and about what happens if writable nodes are modified by an attacker. Thank you for that. 
>>> 
>>> Adam said in his Discuss that he was agreeing with Ben's comments on this topic, and Ben's comments included this question: 
>>> 
>>> Are there no nodes that are privacy (or otherwise) sensitive when just readable?
>>> 
>>> I didn't see any new text about this. Are there privacy-sensitive read-only nodes?
>> 
>> I took another look at nodes that are marked read-only in the YANG module. These nodes include session state, sent and receive packet count, last sequence number received or transmitted, start time, repeat count, tcp/ip address and port numbers etc. Nothing jumped out as particularly privacy sensitive.
> 
> In some scenarios knowing the current sequence number is useful to an
> attacker, e.g., in TCP for sending off-path RST.  I don't remember enough
> of how TWAMP works to say offhand whether an analogous disruption is
> possible in some (unauthenticated?) cases.

That is correct. But we do not store the sequence number, so they would have to snoop the traffic to get the sequence number which they can, whether they have the IP address/port number from the twamp module or not. 

> 
>> One field that did catch my attention was the ‘token’ field, which is defined as "This parameter holds the 64 octets containing the concatenation of a 16-octet Challenge, a 16-octet AES Session-key used for encryption, and a 32-octet HMAC-SHA1 Session-key used for authentication; see also the last paragraph of Section 6 in RFC 4656.”
>> 
>> I am not a security expert, and do not know if being able to read this or other read-only information is sufficient in itself to launch an attack or disrupt an existing or new session. Maybe somebody from SEC-DIR can comment on it. If it is, I would be happy to add some text around it. 
> 
> I note that secdir is not on the recipients list, so if you want to get
> specific feedback, someone will need to explicitly seek it out.
> 
> I also note that the cryptographic constructions used for TWAMP are quite
> diverged from current best practices and appear to be fragile at best.  So
> someone doing such an analysis might have to go through a fair amount of
> effort to reach a conclusion (part of why I did not attempt such analysis
> myself).  It might be safest to assume that being able to read the token
> field gives an attacker the ability to disrupt a test session.

Ok. I will write something up for the 'token' attribute. 

> 
> -Benjamin