Re: [secdir] secdir review of draft-ietf-ippm-model-based-metrics-10

Matt Mathis <> Mon, 20 March 2017 20:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 462AE12951D for <>; Mon, 20 Mar 2017 13:15:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.666
X-Spam-Status: No, score=-0.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, LONGWORDS=2.035, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uKZnPld3KXmX for <>; Mon, 20 Mar 2017 13:15:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E90061294CF for <>; Mon, 20 Mar 2017 13:15:02 -0700 (PDT)
Received: by with SMTP id v198so97557878ywc.2 for <>; Mon, 20 Mar 2017 13:15:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CpbU4CgOO1cw44ITtgx5ZqB2plHsqJf0aJc1HveIUM4=; b=l2q9ed52+bBoPNqmEWw1cGNDKVfwSXJGcq5Zl5UCRZ7Bf8K9ilHy3b7ytZpFYS3ejK Vikk7iK0MgLi+YcNdLkpnJ6tjtXitEFp910+MIKeym8fDwRT9jKdDa9JbfuGbtIkjac4 djZqND3RIOQveonwKvlNQIL7fyJvjomT12eE29LbD0f/x6XnXOVWXVLQ0Ol7hAV3j5qR rdyi/irCz2WHTW0TXlxtN8E1nVJXsyIjtVJNnByz29ZZ7MUVdNg5QOXkJwAYopRziXe1 Ra+9a/ga6jOE+SbBqLxJGAmjKwcAQDk5L79myNDdpi1Js3jEcIhDFi8KGmnwxJXTxDOr v26Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CpbU4CgOO1cw44ITtgx5ZqB2plHsqJf0aJc1HveIUM4=; b=HLyiPx9M/nz5U7Igt+q1wDBFwjt6cOmLbFLFFQjpJ0z/Xy2/UtFTn5IhBpqU5zP6Oe xEmFFYFds97aYjeZgtGB20nheIoT4AdHoo6ejCnenV9ktCTIkh5OxEJI3Vg+guu7Ah81 u9yiLZCk5UCedPGhR+RL/uRtpspxSHqHi6GHAjeipKRb3Soz8TMhLW/1MiL1jpFQayHN c+Iwt2L3i+sHBNj87WeLLG+jfJAEAFMSgSf6VysOpwF1JQo6+LDxfzsXQXtZbkDuaFiP lwCQPbSrYKcG9cLey2G1u2qn+ZEZe00hbMrJpyK5fVW+5L6pttlkRjAhuh6SSCpkurrU 4vCA==
X-Gm-Message-State: AFeK/H3qpBdUQXf+4RhnNxNm3b7t8kdzrCYqi4JCb/8ozKTEoR2/qsxRgW29/7msHIgrFH3H8Wkremibe1/MYm8k
X-Received: by with SMTP id h68mr16529449ywe.173.1490040901950; Mon, 20 Mar 2017 13:15:01 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 20 Mar 2017 13:14:41 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Matt Mathis <>
Date: Mon, 20 Mar 2017 13:14:41 -0700
Message-ID: <>
To: David Mandelberg <>
Content-Type: multipart/alternative; boundary=94eb2c07cef4aa1249054b2f2ed2
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-ippm-model-based-metrics-10
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Mar 2017 20:15:05 -0000

(Dropping iesg from the follow up chatter).

I am adding a paragraph to the security section:
      <t>Note that in situ measurements sometimes require sending
      synthetic measurement traffic between arbitrary locations in the
      network, and as such are potentially attractive platforms for
      launching DDOS attacks.  All active measurement tools and
      protocols must be deigned to minimize the opportunities for
      these misuses.</t>

Thanks for the feedback!

The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.

On Sun, Mar 12, 2017 at 2:14 PM, David Mandelberg <>

> Hi,
> 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.
> This experimental draft "provides a framework for designing suites of IP
> diagnostic tests" to measure a network path's bulk transport capacity.
> As mentioned in the security considerations, actual attempts at
> measurement might be subject to manipulation by an attacker. As I
> understand it, the framework in this document neither attempts to
> prevent such attacks, nor makes them any more likely.
> The only other relevant potential security issue I could think of is
> whether measurement system(s) using this framework could be co-opted by
> an attacker to cause a denial of service to a specific network path. I
> think this would depend entirely on the implementation of a system
> designed using the framework in this document, and is therefore pretty
> far removed from this document itself. An attack like this also might
> not be possible because of some part of the framework that I missed. So
> I'll trust the authors' and/or working group's judgment on what to do
> with this comment.
> I think this draft is somewhere between (inclusive) Ready and Ready With
> Issues, depending on how far off-base my point about denial of service
> is. I'm leaning towards Ready.
> --
> David Eric Mandelberg / dseomn