Re: [ippm] Question about rfc8972 STAMP TLV

Tianran Zhou <zhoutianran@huawei.com> Tue, 24 October 2023 00:17 UTC

Return-Path: <zhoutianran@huawei.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 A3E30C16F41F for <ippm@ietfa.amsl.com>; Mon, 23 Oct 2023 17:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.193
X-Spam-Level:
X-Spam-Status: No, score=-4.193 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dx0OwU-ZGbT for <ippm@ietfa.amsl.com>; Mon, 23 Oct 2023 17:17:15 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C6F6C152573 for <ippm@ietf.org>; Mon, 23 Oct 2023 17:17:14 -0700 (PDT)
Received: from lhrpeml100003.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4SDswb4s0wz6JBC8 for <ippm@ietf.org>; Tue, 24 Oct 2023 08:13:35 +0800 (CST)
Received: from kwepemi100021.china.huawei.com (7.221.188.223) by lhrpeml100003.china.huawei.com (7.191.160.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Tue, 24 Oct 2023 01:17:12 +0100
Received: from kwepemi500022.china.huawei.com (7.221.188.64) by kwepemi100021.china.huawei.com (7.221.188.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Tue, 24 Oct 2023 08:17:10 +0800
Received: from kwepemi500022.china.huawei.com ([7.221.188.64]) by kwepemi500022.china.huawei.com ([7.221.188.64]) with mapi id 15.01.2507.031; Tue, 24 Oct 2023 08:17:10 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Greg Mirsky <gregimirsky@gmail.com>, Henrik Nydell <hnydell@accedian.com>
CC: IETF IPPM WG <ippm@ietf.org>
Thread-Topic: [ippm] Question about rfc8972 STAMP TLV
Thread-Index: AdoFh+p7lDfc3ZRlS3CB1ZrfjLWe9///jf8AgAClEYD//yYBMA==
Date: Tue, 24 Oct 2023 00:17:10 +0000
Message-ID: <2b83a1d743e843f7aa0b671215c6a9fc@huawei.com>
References: <d24f64235d5d4436ae51a05c7d5c0b18@huawei.com> <CALhTbpq37wt32ibxdcbm+_DuA9kjKffBuY8CfZk4m_cFaqjvVg@mail.gmail.com> <CA+RyBmVka=3GP=zVzKNyFngTZa+b5nwY7zuWMoDF1hxmitMyhQ@mail.gmail.com>
In-Reply-To: <CA+RyBmVka=3GP=zVzKNyFngTZa+b5nwY7zuWMoDF1hxmitMyhQ@mail.gmail.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.40.118]
Content-Type: multipart/alternative; boundary="_000_2b83a1d743e843f7aa0b671215c6a9fchuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/xR6FefAgn2t2q9D3I50P8MMSfbc>
Subject: Re: [ippm] Question about rfc8972 STAMP TLV
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
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 Oct 2023 00:17:19 -0000

Hi Henrik and Greg,

Thanks very much for your clarification. Very helpful.
My concern was “all the elements that identify the STAMP test session”, should *the STAMP session* been exactly identified?
If your interpretation that wildcard is available, I am all good with it.
Yes, in this case, security should be considered anyway.

Thanks,
Tianran

From: Greg Mirsky [mailto:gregimirsky@gmail.com]
Sent: Tuesday, October 24, 2023 3:10 AM
To: Henrik Nydell <hnydell@accedian.com>
Cc: Tianran Zhou <zhoutianran@huawei.com>; IETF IPPM WG <ippm@ietf.org>
Subject: Re: [ippm] Question about rfc8972 STAMP TLV

Hi Tianran,
I agree with Henrik (and thank him for the reference to the IPR).
My interpretation is that "all the elements that identify the STAMP test session" could be a wildcards (all or some). If that is the case, then, I imagine, an implementation that has all elements as a wildcard would behave as you expect. Although, as Henrik has pointed out, there seems to be valid security concerns with that model. However, if these concerns are mitigated using ACLs, then I might not see such approach much different from providing more specific configuration via STAMP Session-Reflector configuration to begin with. WDYT?

Regards,
Greg

On Mon, Oct 23, 2023 at 2:19 AM Henrik Nydell <hnydell@accedian.com<mailto:hnydell@accedian.com>> wrote:
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 packet.

There is however IPR in this area that may need to be considered
https://patents.justia.com/patent/20160330092


On Mon, Oct 23, 2023 at 10:19 AM Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org<mailto:40huawei.com@dmarc.ietf.org>> 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
ippm@ietf.org<mailto:ippm@ietf.org>
https://www.ietf.org/mailman/listinfo/ippm


--

Henrik Nydell
Sr Product Manager
1.866.685.8181
hnydell@accedian.com<mailto:hnydell@accedian.com>

[https://i.xink.io/Images/Get/N63832/a263.png]
Accedian is now part of Cisco. Read more here<https://blogs.cisco.com/news/cisco-announces-intent-to-acquire-accedian>.

[https://i.xink.io/Images/Get/N63832/f97.png]<https://www.facebook.com/accedian/> [https://i.xink.io/Images/Get/N63832/t99.png] <https://twitter.com/Accedian>  [https://i.xink.io/Images/Get/N63832/l54.png] <https://ca.linkedin.com/company/accedian>
<http://www.accedian.com>
accedian.com<http://accedian.com>


Avis de confidentialité

Les 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

This e-mail message and any attachment hereto contain confidential information 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.