Re: [ippm] Question about rfc8972 STAMP TLV

Henrik Nydell <> Mon, 23 October 2023 09:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE640C1519B6 for <>; Mon, 23 Oct 2023 02:19:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZpWQOffeINlC for <>; Mon, 23 Oct 2023 02:19:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 00743C1705EB for <>; Mon, 23 Oct 2023 02:19:22 -0700 (PDT)
Received: by with SMTP id 98e67ed59e1d1-27d4b280e4eso2158067a91.1 for <>; Mon, 23 Oct 2023 02:19:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=corp1; t=1698052762; x=1698657562;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aI+tAEZioeaGk5Q5SRmDLO9TfokjAb8H6ZfA8NCyGLY=; b=fFx4vcfQ6YOTXQ3nufCHG29WvqGb3iUFf35cW0MQGvcz49Qc7YzwUHThLNzd14Z30m 78owrIHEvS423Y9Mqm2PTELOt11B4Bvz/tpVo0QUI0Hbs7l4Ny/nhIQbghIcpB0tA2DP r0bYmoupvoGyPw5m36ZTGgNbSrx6nLe0dfgZjldhulAG0ZXfvviedKx1hYVzglnWM1dH tqlYui8JI0ljqpcawUhL+iK1JxcBRERqAoyGwulxoLVx93BR5aWLHhYWhtGwCXOiumYI PbB58mq4fas/fWU9NK2HxiQanIZ1mzpEe5DpjGH/+MvrQeHnxAxff5XwzNgy9KcWurY3 a4mw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1698052762; x=1698657562; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=aI+tAEZioeaGk5Q5SRmDLO9TfokjAb8H6ZfA8NCyGLY=; b=Jd0vUHlc3FwRPr89Z6Af4VSFUUmi7sl8MPiDzlNDG/Mcv8g3fKK41SxnVyVfzUiwCw zRUivqltO7AIkYrRCu8U9+xYa8i3wcM6RJkxzo0BCZpumepGyK1xQgpIUGNlCIOZ3bil 5CJAfYIlOKu+1Z02b01ueVovna+jrgSj3gO467usI9/XdCo6JTQosGTOeLc9BtwwmXF2 by6BcxmFeNE7vHxgKDHNlQULDwwGEhcId0hiVJD9KiP72Y5qCBQboEsakx+8gVueMoMe FiHQt4Zk3llAYQOrEQrvSsPc1AQ5wCq8RauKE77fj6gphJ4oAkP5wlQxeq1oimCBUE0S ZuDQ==
X-Gm-Message-State: AOJu0YyyXn+fbwH8J86CszWJemiSBY8W0hqdWZzIwdwSXEmzJZ32cCc/ Lv231jcPqG5MzqF2WtGkeJiEAc0DOiMDK3CMcdL5u6YUx9G88g8vT10uCcLI+Y0dEcBKjyvJ38F bcDe/P7t0Iw==
X-Google-Smtp-Source: AGHT+IGob/nnDG7W2AWgqnjD5uhAhLEldxN1H1xSf/2BIxjIZ+c7Gcr2YLSHEgxAa8trqSK8YgUkBU51tFTZ3HDJHF8=
X-Received: by 2002:a17:90a:1943:b0:27d:63f1:2d24 with SMTP id 3-20020a17090a194300b0027d63f12d24mr12364623pjh.0.1698052762272; Mon, 23 Oct 2023 02:19:22 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Henrik Nydell <>
Date: Mon, 23 Oct 2023 11:19:06 +0200
Message-ID: <>
To: Tianran Zhou <>
Cc: IETF IPPM WG <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000b4b0e606085eb71f"
Archived-At: <>
Subject: Re: [ippm] Question about rfc8972 STAMP TLV
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Oct 2023 09:19:52 -0000

Hi Tianran,
I do not think that text limits you from creating a reflector with dynamic
session instances, as long as you can discard STAMP-test sessions that you
dont want to reflect, for example to or from a UDP port that is not
open/provisioned. The SSID is optional as described in section 3, so you
dont explicitly need to preprovision which SSIDs a session-reflector acts
on, as long as you copy/keep the incoming SSID if it exists. The main
reason for the clause you mention is for limiting risk of malicious use of
the reflector, since it basically is a UDP loopback, and in unauthenticated
mode there is no protection. An attacker may send a packet with IP source
address of STAMP-reflector A, to STAMP-reflector B, thus creating a looping

There is however IPR in this area that may need to be considered

On Mon, Oct 23, 2023 at 10:19 AM Tianran Zhou <zhoutianran=> wrote:

> Hi Greg and all the authors,
> I am considering a simple mode of STAMP.
> That means the reflector node only need a minimum configuration on the
> sessions.
> Specifically,  the reflector no need to configure any specific session
> info, just to reflect any session received blindly.
> I am not sure if this is allowed by RFC8972. Because I find the following
> text in section 3:
> “Before a test session commences, a Session-Reflector MUST be provisioned
> with all the elements that identify the STAMP Session. A STAMP
> Session-Reflector MUST discard non-matching STAMP test packets.”
> It sounds like my expected behavior is not allowed. Am I right?
> But I really find the simple mode of STAMP is useful.
> Best,
> Tianran
> _______________________________________________
> ippm mailing list


*Henrik Nydell*
*Sr Product Manager*

Accedian is now part of Cisco. Read more here

<>  <>
* <>*


Avis de confidentialité

 informations contenues dans le présent 
message et dans toute pièce qui 
lui est jointe sont confidentielles et 
peuvent être protégées par le 
secret professionnel. Ces informations sont 
à l’usage exclusif de son ou
 de ses destinataires. Si vous recevez ce 
message par erreur, veuillez 
s’il vous plait communiquer immédiatement 
avec l’expéditeur et en 
détruire tout exemplaire. De plus, il vous est 
strictement interdit de 
le divulguer, de le distribuer ou de le reproduire 
sans l’autorisation 
de l’expéditeur. Merci.

Confidentiality notice

 e-mail message and any attachment hereto contain confidential 
which may be privileged and which is intended for the 
exclusive use of its 
addressee(s). If you receive this message in error,
 please inform sender 
immediately and destroy any copy thereof. 
Furthermore, any disclosure, 
distribution or copying of this message 
and/or any attachment hereto 
without the consent of the sender is 
strictly prohibited. Thank you.