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

Magnus Westerlund <magnus.westerlund@ericsson.com> Wed, 11 September 2019 07:53 UTC

Return-Path: <magnus.westerlund@ericsson.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 DC36E120810; Wed, 11 Sep 2019 00:53:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 ERisnMHH9bMI; Wed, 11 Sep 2019 00:53:22 -0700 (PDT)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40081.outbound.protection.outlook.com [40.107.4.81]) (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 D1546120143; Wed, 11 Sep 2019 00:53:21 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bI0pw3bnGZDIM4dH7NT3cNQ40G07DU9I+TR5LxQRFP0i0Tc6S2SP2294lus4wz0ooiB8fu8ysWBzt3+DH3Kx7WzN1lIWvIp+qZd2XtQQijD9OFOQckwiEYv75BVT6BozL/thBjxVXCG35IouUa4k0nRFjOuzo1Q32cNZsEuRLS9F2nnH1SHuUTn3Q9zMFfrcQtVsxhxYyRLtTB2Ig3wN+2GDusk5OLpOvLilTeNYaZR5vmG8Z01tcwGd0vaWMzUU9dykpNdcUTpCSbjH611w2LkQZmuLrU5RUyBaT2+Qh/Dmd+AF3isrv0e2Q8mQ9MsXxoDgQaX9mpshPqtuv+ZCyw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W1L51dgkAYGeWI2Nb29Wpkvr4cwGyekhzf4hYDefr2Y=; b=FYNUHJE52uxC9Ql21VtAU372qpot7WC7h3N4RVpPIV7DQd1Mm8QZuuKUJe3ILSM0+p9Oc/lxaWke0z12L8QJlIuPWwAsHj4L45eCOUfkIBcAXDWilhX+Lry7fRBZPkkIlg/b6otDQ1eymKkEFQO5XezapOo3KOyNtCruFnmG3STHdKM/WEfSJetTARRDmSUch0Q7J1srUygrmhuIDU982UbcGYv/8zVgsQPYgSeZSAD5iMWwYX3kWyVJUx1B9FgjPMRO6y9+pZDl3RrT1mg2f4psZ2boAXDBHiiCt2tfK490hJrjtWe0VpwJWjh3RhdO2rwULWjhnXXuAhmPMNisAw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=W1L51dgkAYGeWI2Nb29Wpkvr4cwGyekhzf4hYDefr2Y=; b=JUBRRaXoApI0wsieqK88hrN+MT2IgFFrVw/fDjirboxRRjJ0pvtBoFfopY6IMHm+sbk6+lKV8EutGP1aSxdiY81JhKReYLm7AVRB6rSQldUhEoW87zaactBRqJiNYtjeu72AOz0mWLhMXD387TYJ1os3PiecUvYuhgtFNpziLfA=
Received: from DB7PR07MB5736.eurprd07.prod.outlook.com (20.177.194.155) by DB7PR07MB5612.eurprd07.prod.outlook.com (20.178.45.206) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.10; Wed, 11 Sep 2019 07:53:19 +0000
Received: from DB7PR07MB5736.eurprd07.prod.outlook.com ([fe80::a935:4edd:29a2:9772]) by DB7PR07MB5736.eurprd07.prod.outlook.com ([fe80::a935:4edd:29a2:9772%6]) with mapi id 15.20.2263.015; Wed, 11 Sep 2019 07:53:19 +0000
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
To: "gregimirsky@gmail.com" <gregimirsky@gmail.com>
CC: "draft-ietf-ippm-stamp@ietf.org" <draft-ietf-ippm-stamp@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "tal.mizrahi.phd@gmail.com" <tal.mizrahi.phd@gmail.com>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>
Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-ippm-stamp-07: (with DISCUSS and COMMENT)
Thread-Index: AQHVaBAbqbmUyWu4qEOdjey0JDZTiacmG9IA
Date: Wed, 11 Sep 2019 07:53:19 +0000
Message-ID: <06fcd3bea80067202534aa70857194b2e4335d3f.camel@ericsson.com>
References: <156760524845.22816.16339950342338392164.idtracker@ietfa.amsl.com> <CA+RyBmUy-_ETfaPWoYivcWa0S3De4dcn9=Wb47M7x0vSfEsjYQ@mail.gmail.com>
In-Reply-To: <CA+RyBmUy-_ETfaPWoYivcWa0S3De4dcn9=Wb47M7x0vSfEsjYQ@mail.gmail.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com;
x-originating-ip: [158.174.130.76]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 3c096917-f44b-45dc-3610-08d7368d1c9a
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:DB7PR07MB5612;
x-ms-traffictypediagnostic: DB7PR07MB5612:
x-microsoft-antispam-prvs: <DB7PR07MB5612395C6651BF7EB8D3597295B10@DB7PR07MB5612.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0157DEB61B
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(346002)(366004)(376002)(396003)(51914003)(189003)(199004)(51444003)(229853002)(14454004)(30864003)(256004)(14444005)(186003)(54906003)(1361003)(316002)(71200400001)(71190400001)(91956017)(76116006)(446003)(11346002)(486006)(6246003)(44832011)(4326008)(5640700003)(53936002)(25786009)(2616005)(476003)(6512007)(6306002)(8936002)(81166006)(81156014)(1730700003)(8676002)(5660300002)(66446008)(64756008)(66556008)(66476007)(66616009)(66946007)(1411001)(99936001)(2501003)(305945005)(7736002)(2906002)(6116002)(3846002)(6916009)(76176011)(66066001)(102836004)(2351001)(26005)(6506007)(966005)(53546011)(99286004)(478600001)(86362001)(6436002)(36756003)(118296001)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB7PR07MB5612; H:DB7PR07MB5736.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: nt+Dol/ElHrynB8BHOKDrIN0VgtKLpPSvmI0H1dxGn28K9PI9mYInY1rwT4a6Dmkdryoyuqm98OvQ0f63KYnS8gwG/RW0X3XHMqhbCYR1CEJJJphhmKn4esY34LGzMayBG0yRXbxaMc7pCFJPUWNJ2SwBwSO089UhMB/peP7C0Qv2u3kaSTnR+UXKNejwJcBh27l3otJj442POuSjRwL0K95Is0ncpoTBLIxFor9Ww3brpeGz0oC+SKOr2VTX000KxfAvpxGk0tL5T2cutioAicHEMUfA794w36JNc55gwsA2pPVpbjfS8txKUHGHqXqa7bZCGPZPd269xQY9pQ9SX43Wx+dB5HoCcZXsLlAKefO/2WiII5xzz5Cmf39xYAXOOSwGVnwyVVhmgfp3UEakIZzf8AXPF3uObFXRMJG57w=
x-ms-exchange-transport-forked: True
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-tpnvwdBdulMxjGUGy6LC"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3c096917-f44b-45dc-3610-08d7368d1c9a
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Sep 2019 07:53:19.3442 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: +n+avjONqfL6cKb+4uKASUOF2uKT7NtmSkwa4gbJqwZLwP4XMF4kC62i1Bi1xO5k4+ewdbUh2F1u4TGlHE4J0B6bfWLYTZDx6NH8tp3iq6I=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR07MB5612
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/4qkYc7LgAD5C7d1F4LJZUwaceYU>
Subject: Re: [ippm] Magnus Westerlund'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: Wed, 11 Sep 2019 07:53:26 -0000

Hi Greg,

Thanks for the reply. See inline for my comments and response. 


On Tue, 2019-09-10 at 12:43 -0700, Greg Mirsky wrote:
> Hi Magnus,
> thank you for the review and thoughtful, pointed questions. Please
> find my answers in-line under GIM>> tag.
> 
> Regards,
> Greg
> 
> On Wed, Sep 4, 2019 at 3:54 PM Magnus Westerlund via Datatracker <
> noreply@ietf.org> wrote:
> > Magnus Westerlund 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:
> > -----------------------------------------------------------------
> > -----
> > 
> > Two very much discussing discusses. However, I would really like to
> > hear the
> > answer to these concerns before clearing.
> > 
> > 1. Section 4.3: Is the HMAC field size of 16 bytes hard coded? If
> > there ever
> > would exist a need to deploy another integrity solution, even if
> > the actual
> > algorithm used to construct the tag can be agreed by the
> > management, there
> > appear to exist a hard look in to use 16-byte tags. Have this issue
> > been
> > considered?
> 
> GIM>> Indeed, this specification defines the use of only one
> algorithm and only 16 bytes-long HMAC field. Your question prompted
> the discussion among authors and we believe that in a future
> specification it would be feasible to extend supporting a number of
> algorithms and different lengths of HMAC field both being defined
> through extension to STAMP YANG data model.

So if I understand this (taking a discussion with Mirja about keeping
things as simple as possible) the solution is to basically is when need
arises define a new STAMP version, and then use YANG to coordinate
which version is used for the measurement. If that is a correct re-
interpretation of your response then I am fine with it. 

> >         2. Section 6:
> >         The possible impact of the
> >    STAMP test packets on the network MUST be thoroughly analyzed,
> > and
> >    the use of STAMP for each case MUST be agreed by all users on
> > the
> >    network before starting the STAMP test session.
> > 
> >         I assume some potential issues are know, shouldn't they
> > really be
> >         listed here in the security consideration to further
> > motivate why the
> >         analysis needs to happen.
> 
> GIM>> This is in reference to using numbers from the User range as
> the destination port number. Would adding the reference to the case
> of using the port numbers from the User range address your concern?
> Or rather refer to Section 4, as it includes more discussion (see 
> below)? 

Okay, I don't really care where the discussion happens. But I don't
find any real discussion and listing of the concerns with using user or
dynamic ports for STAMP Sessions? With the formulation you use, I would
expect at least some list of potential concerns that needs to be
evaluated in the context of the particular usage of STAMP. 

> > 
> > -----------------------------------------------------------------
> > -----
> > COMMENT:
> > -----------------------------------------------------------------
> > -----
> > 
> >         1. Section 4:
> >         Before using numbers from the User Ports range, the
> > possible impact
> >    on the network MUST be carefully studied and agreed by all users
> > of
> >    the network.
> > 
> >         Is the above sentence missing to list an important
> > assumption? Is the
> >         assumption that by using the registred destination port an
> > operator
> >         that sees to much STAMP traffic can simply filter it out
> > and that way
> >         deal with the traffic, something which is not possible when
> > using an
> >         locally decided port? If that is the case, this assumption
> > should
> >         probably be noted.
> 
> GIM>> That is a very good point but our primary motivation for this
> cautionary note (or strong warning) was that by allowing STAMP to use
> port numbers from the User range, ports that may be already assigned
> to protocols, creates a DDOS attack vector. As for the filtering
> STAMP traffic out, I think that even if the destination port is one
> from the Dynamic range, for a relatively long test session it can be
> filtered out.

So if that is the only? concern then write it out. I would expect that
the higher layer management protocol that creates a measurement session
to actually ensure that the STAMP endpoint actually have the port
numbers they attempt to use. Isn't that a reasonable requirement to put
on the solution? 

My thinking with the filtering out concern was that in cases where one
runs STAMP measurement sessions, if the measurement interfer with
critical traffic an action for an on-path node that can actually
identify the STAMP traffic was to filer it out. And that may be
considered trivial when the well known port is used, but if a user or
dynamic port is used, then that requries a managment system to provide
the on-path node with the necessary information, i.e. 3/5 tuple for the
STAMP flows. 


> >         2. Section 3 and 4, and 4.1.1: What is a STAMP Session? Is
> > that a
> >         measurment session between one specific and sender and a
> > specific
> >         reflector for a time duration?  The defenition of the
> > session do matter
> >         if one intended to enable a single sender to use multiple
> > reflectors,
> >         and if that can be a single session or always multiple
> > indepdendent
> >         ones. Would appreciate a definition what a session is. If
> > it is
> >         possible to send STAMP traffic using a multicast or
> > broadcast address
> >         should be made explicit.
> 
> GIM>> Your interpretation is correct, STAMP session is implicitly
> defined as p2p. And that is what reflected in the STAMP YANG model.
> Would the following text make it clearer:
> NEW TEXT:
>    In this document, a measurement session also referred to as
>    STAMP session, is the session between one specific Session-Sender
> and
>    one particular Session-Reflector for a time duration.

Yes, please include that definition. Question would it be clearer to
replace ".. is the session betweeen .." with ".. is the bi-directional
packet flows between .."? 


> >         3.  Section 4.1.1.:
> >         Timestamp is eight octets long field.  STAMP node MUST
> > support
> >       Network Time Protocol (NTP) version 4 64-bit timestamp format
> >       [RFC5905], the format used in [RFC5357].  STAMP node MAY
> > support
> >       IEEE 1588v2 Precision Time Protocol truncated 64-bit
> > timestamp
> >       format [IEEE.1588.2008], the format used in [RFC8186].
> > 
> >         Is the clock source here something that may be relevant or
> > simply
> >         information the management functions should capture. I
> > think there is a
> >         similar issue to that of RTP faced when it comes to
> > understand what the
> >         timestamp actually represent and thus be used correctly.
> > RTP clock
> >         source specification is RFC 7273
> >         (https://datatracker.ietf.org/doc/rfc7273/)
> 
> GIM>> NTP and PTP encodings have a different interpretation of the
> Fraction field of the Timestamp field. In my experience, PTP format
> is native for the data plane, while NTP is more used at the control
> plane. Original extension to TWAMP has been described in RFC 8186.

I think you missunderstood. When I talk about clock source, I am
actually referring to identifying the particular clock that the node
use to derive the included timestamp from. 

And likely this is a moot point in this document where the clock source
information belongs in the management layer, e.g. in the YANG data
model. 


> >         4. Section 4.1:
> >            Because STAMP supports symmetrical test packets, STAMP
> > Session-Sender
> >    packet has a minimum size of 44 octets in unauthenticated mode,
> > see
> >    Figure 2, and 112 octets in the authenticated mode, see Figure
> > 4.
> > 
> >         The above text implies some potential for UDP payload size
> > variability
> >         for the STAMP packets. However, the actual definition
> > appear to have
> >         fixed sizes. Can you please clarify if I have missed
> > something that
> >         enables the STAMP packet to have variable size?
> 
> GIM>> I think that the text can be improved by characterizing the
> listed sizes as "base". The variable length of a test packet in STAMP
> is supported by using Extra Padding TLV defined in draft-ietf-ippm-
> stamp-option-tlv. Below is the proposed update:
> OLD TEXT:
>    Because STAMP supports symmetrical test packets, STAMP Session-
> Sender
>    packet has a minimum size of 44 octets in unauthenticated mode,
> see
>    Figure 2, and 112 octets in the authenticated mode, see Figure 4.
> NEW TEXT:
>    STAMP supports symmetrical test packets.  The base STAMP Session-
>    Sender packet has a minimum size of 44 octets in unauthenticated
>    mode, see Figure 2, and 112 octets in the authenticated mode, see
>    Figure 4.  The variable length of a test packet in STAMP is
> supported
>    by using Extra Padding TLV defined in
>    [I-D.ietf-ippm-stamp-option-tlv].
> 
> With the new reference, should I-D.ietf-ippm-stamp-option-tlv be
> moved to the Normative References list or may remain in the
> Informative list?

From my perspective, the fact that optional TLV may occur following the
base headers appears quite important. Here comes a question of
intention form the WG. Is it intended that one can have STAMP endpoints
that do not even support receiving packets larger than the base? 

In other words there will be two main versions already now, one that
supports some TLV and can at least handle the TLV skip forward and
ignore the content and one that will throw a fit over the TLVs? If that
is not the intention I think the fact that TLV's may occur should be
moved into this specification and have it as a normative reference.

I guess the answer is that you have backwards comaptibility reasons for
not allowing TLVs at all in some sessions, or? 

 
Cheers

Magnus Westerlund 


----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------