Re: [ippm] Roman Danyliw's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS and COMMENT)

Greg Mirsky <gregimirsky@gmail.com> Tue, 24 September 2019 22:29 UTC

Return-Path: <gregimirsky@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 03DD3120845; Tue, 24 Sep 2019 15:29:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.596
X-Spam-Level:
X-Spam-Status: No, score=-0.596 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, HTML_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 eaWocT_6Ja1U; Tue, 24 Sep 2019 15:29:13 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 CA6C01200F7; Tue, 24 Sep 2019 15:29:12 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id n14so3522553ljj.10; Tue, 24 Sep 2019 15:29:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PjxLqp9ClWAPn0XmRwb6WoLUmnNnVPySHihbfgyJRoA=; b=K+oXx0bq/gJqlWjpjWOsWsbHBcT3YTEpo5MRjMXx2B2Dv/kPjjlDFE7HSNuEVkBONO 7ggTBUQfFWwSVlV2Wxaa6Sba1bVNy4FIY0bWu03958Php8E6TnmCek8vX9LbSfgqH6/g DLxgeXTF4rhqifBr5ClGAt87+PFfoN2wi2Qjkj08L6Fc0ZKw/Lfy+VU90Xl+PM83ilPJ SRCjDabsMmYj+Vmt/FfOBJSRpFDS/VlWMWLRtvQK5F+rkc2A+dOQGpvDklbibWbJWLEC 9f9tQ0tGq7zx6CMSSiUc7amKoqyt52sJjvB9DfvKJFYoKEBw0QlDCXLiXvhv2CRT36Fm IQgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PjxLqp9ClWAPn0XmRwb6WoLUmnNnVPySHihbfgyJRoA=; b=jkloTIW6b/kpg+MIHi/sJUckYBq0nijOZonDjt01wiAB85HWcMiADKdojO3pVjbfQM 4Qax1X6F47Dptp7y8IC3AwjbnE+Tx5ZbjuABKloEeDeM3uic/gt7pkdHEO1EaBjGDd2Y aqeRkvqpDX94Jgd+4A8ADsnrFX6hcLhzlNRfUl1GGlI7/V+0DbkANFBmabAElWrUTMqq clIyhiYV1/ovcjdsp2RKoxIC3vVFyNuSXTzXLx1BtEOWjeWRYsnZd3cfDuFRjt43yrW6 fp+0duumXjTNfFvS0EfeFdklCVzZv/hFH+qsUE+kllmSpjtDKf2lmdR/uSoRxAwk5KiT XWYQ==
X-Gm-Message-State: APjAAAWR2IC8LirBJqthJqhHHXarg3zWHCIvPEmoXtEPUTAOcb14P0I+ ClYsUezGpxtdTs3Igeev83RK+AKexP2lYwwohS4=
X-Google-Smtp-Source: APXvYqzctD9NgxpqmJm4y6n+P3NQ+E4B1tmairCW+Db+RvmL1IaDoT2aNxbb0hD9yjka4tMYrnlDFTsJbk4TcTg3Th0=
X-Received: by 2002:a2e:7d19:: with SMTP id y25mr3568331ljc.177.1569364150368; Tue, 24 Sep 2019 15:29:10 -0700 (PDT)
MIME-Version: 1.0
References: <156764791626.22774.7572696173575309052.idtracker@ietfa.amsl.com>
In-Reply-To: <156764791626.22774.7572696173575309052.idtracker@ietfa.amsl.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Tue, 24 Sep 2019 15:28:59 -0700
Message-ID: <CA+RyBmUm9UHbK9W0FT6GVgafN+of5thCNpZ4pGY=EFf9e8K9Rw@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-ippm-stamp@ietf.org, Tal Mizrahi <tal.mizrahi.phd@gmail.com>, IPPM Chairs <ippm-chairs@ietf.org>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/mixed; boundary="000000000000b5365605935410fa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/_XCK2EamoOR9vtxCmESebkEByaY>
Subject: Re: [ippm] Roman Danyliw's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS and COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 24 Sep 2019 22:29:21 -0000

Hi Roman,
thank you for your review of the STAMP draft and my apologies for the
delayed response.
Through discussions with Barry and Magnus, we've updated -07 version and
just published the new one
<https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-08>. Please
find my answers to your questions, proposed updates in-line below and
tagged GIM>>.
Attached, please find the new working version and the diff between versions
-07 and -09 (the new working version).

Kind regards,
Greg

On Wed, Sep 4, 2019 at 6:45 PM Roman Danyliw via Datatracker <
noreply@ietf.org> wrote:

> Roman Danyliw has entered the following ballot position for
> draft-ietf-ippm-stamp-07: 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-ippm-stamp/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> (1) Section 4.3.  The text does not explicitly state the data on which the
> HMAC
> is computed (i.e., bytes 1 to the end of the last MBZ field of the
> message?)
>
GIM>> Yes, the intention is to cover the whole STAMP packet as presented in
the draft for Session-Sender and Session-Reflector. Would adding the
following sentence make it clear:
In the Authenticated mode, HMAC covers the first six blocks (96 octets).

>
> (2) Section 6.  Per “In general, all the security considerations related to
> TWAMP-Test, discussed in [RFC5357] apply to STAMP.”, what exact guidance is
> relevant here:
>
> -- Section 6 (Security Considerations) of RFC5357 says follow the guidance
> of
> RFC4656 and guidance on the OWAMP Server-Greeting messages, only the former
> seems relevant
>
> -- Section 6 (Security Considerations) of RFC4656 has:
>
> Section 6.1 which discusses authenticated and encrypted mode of OWAMP; but
> STAMP has no encrypted mode.  The claims about authenticate mode seem to be
> similar to OWAMP, but that’s not explicitly said
>
> Section 6.2 discusses DoS, seems to have some related guidance but also
> discusses TCP handshakes
>
> Section 6.3 discusses covert channels, this seems relevant
>
> Section 6.4 seems to discuss key management that section 4.3 of this draft
> seems to suggest is out of scope
>
> Section 6.5 seems to provide guidance on resource provisioning but uses the
> KeyID primitive that doesn’t appear present in this draft
>
> [please review the other sections too ...]
>
GIM>> Much appreciate your thorough analysis. Indeed, much of discussion in
RFC 4656 was centered on the security of the control plane, OWAMP-Control,
and is not relevant in case of STAMP. Thus the first sentence in the
Security Considerations section has been replaced with the new paragraph as
below:
OLD TEXT:
   In general, all the security considerations related to TWAMP-Test,
   discussed in [RFC5357] apply to STAMP.
NEW TEXT:
   [RFC5357] does not identify security considerations specific to
   TWAMP-Test but refers to security considerations identified for OWAMP
   in [RFC4656].  Since both OWAMP and TWAMP include control plane and
   data plane components, only security considerations related to OWAMP-
   Test, discussed in Sections 6.2, 6.3 [RFC4656] apply to STAMP.

>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I support Barry Leiba’s DISCUSS.
>
GIM>> The new section, Operational Considerations, has been added in -08
version to address Barry's DISCUSS.

>
> I also support Magnus Westerlund’s DISCUSS.  See #4.
>
> (2) Section 4.1.1.  The sequence number is defined in terms of a “new
> session”.
>  However, I couldn’t find the precise definition of a “session” – how is
> new
> one initiated?  terminated?
>
GIM>> Per discussion with Magnus, defined session as follows:
   In this document, a measurement session also referred to as
   STAMP session, is the bi-directional packet flow between one specific
   Session-Sender and one particular Session-Reflector for a time
   duration.

>
> (3) Section 4.2.1.  Per Session-Sender TTL, this field is defined, the
> guidance
> on generating its value is clear, but its use is not explained.
>
GIM>> The operations on the Sender TTL in STAMP are the same as defined in
RFC 5357. There's no specific performance metric associated with the value
in the Sender TTL field. Some implementations may use it to monitor the
stability of the path from the Session-Sender to the Session-Reflector. I'd
imagine that there could be other ways to use it.

>
> (4) Section 4.3.  Related question to Magnus Westerlund’s DISCUSS, what is
> the
> planned approach for crypto agility?
>
> (5) Section 4.3.  Per, “HMAC uses its own key, and the definition of the
> mechanism to distribute the HMAC key is outside the scope of this
> specification.”
>
> -- What is being suggested by “uses its own key”?
>
GIM>> The intention was to differentiate from the procedure described in
Section 4.2 Integrity Protection (HMAC) in RFC 4656 how HMAC Session-key is
communicated using the control plane and then HMAC key can be derived based
on HMAC Session-key. Would you suggest changed wording?

>
> -- Is it expected that each Session-Sender/Reflector pair would have a
> unique
> key?
>
GIM>> Ultimately, yes. Each pair of Session-Sender and Session-Reflector
may be using a unique key.

>
> -- Recommend being clearer on what’s out of scope, perhaps something on the
> order of: s/… the definition of the mechanism to distribute the HMAC key is
> outside the scope of this specification./


> … key management and the mechanisms to distribute the HMAC key is outside
> the
> scope of this specification.”
>
GIM>> Thank you for the suggested text. Applied in the new working version:
   HMAC uses its own key; key management and
   the mechanisms to distribute the HMAC key is outside the scope of
   this specification.

>
> (5) Section 4.3.  Thanks for responded to Russ Housley’s SECDIR review and
> proposing the new Section 4.3 and 4.4.  It provides helpful clarity.
>
> (6) Editorial Nits
> -- Section 3.  I didn’t understand the title of ‘Softwarization of
> Performance
> Management’.  The text of the section seems to simply describe the
> elements of
> Figure 1 and suggests a few ways to configure the these elements.
>
GIM>> Re-named the section to "Operation and Management of Performance
Measurement Based on STAMP". Is the new title closer to the content of the
section?

>
> -- Section 4.  Typo.  s/MUST use received/MUST received/
>
GIM>> Thank you for catching it. Applied in the working version:
   An implementation
   of STAMP Session-Reflector by default MUST receive STAMP test packets
   on UDP port 862.
>
>
> -- Section 6.  Editorial.  s/Load of STAMP test packets/The load of the
> STAMP
> test packets/
>
GIM>> Thank you. Applied.