Re: [ippm] Question about rfc8972 STAMP TLV

Greg Mirsky <gregimirsky@gmail.com> Mon, 23 October 2023 19:10 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 552A3C16F3F3 for <ippm@ietfa.amsl.com>; Mon, 23 Oct 2023 12:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 5FJH9v6KN0BB for <ippm@ietfa.amsl.com>; Mon, 23 Oct 2023 12:10:06 -0700 (PDT)
Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 172B7C151094 for <ippm@ietf.org>; Mon, 23 Oct 2023 12:10:06 -0700 (PDT)
Received: by mail-yb1-xb2a.google.com with SMTP id 3f1490d57ef6-d865854ef96so3397257276.2 for <ippm@ietf.org>; Mon, 23 Oct 2023 12:10:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698088205; x=1698693005; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Q1Jm3BJnpuTowOuvT+xkmeRVx01MaXUnZ6/j+4Jwf70=; b=DotsY6smQ2cu5hUu1vCP5LE9UNgBzkEIQpRqdMb1PIBwu600Dtzy7vDpRjlYpRSWhM 7xPVaLHwOfjWUZeMwCndPrVSASI2YF1TOKFyG0RYo/jCeQsCTwVz+uS+fUzU6DY+qB25 pyo7BsAzplUbpy713ncPv0wyQZ3XYZ8LcOuI5fWGs+DaW2k8s04h4O4hO5gIVI3goTwY N1DLQ9QoMTdJCeh5WneO2pXXjwrD6WktDtbmWYetH5Kypt+wq456oUAO6Skrn20fQoYl LdERnzszcMBctTeBTWneOdVxsZW4tQwg4XbVALeaa4Ytheu0dW/pf5NpLHfIGnazSYKY fGXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698088205; x=1698693005; 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=Q1Jm3BJnpuTowOuvT+xkmeRVx01MaXUnZ6/j+4Jwf70=; b=bM/rluv0xyEZTk9S8yXz01ViIgSDesZxh1ku+5eXKnb8efLrQr7BkMyQ2siGpbncKT XxLcyRNDJqIQCNbTWImM2x3r53hlWjcobocDGaD/nO/7tGNlXmCjWM+v4weK6xeCL7rX 1ukWN16+4zUT67PrdQO2XBbqT1OgjcD9PfTsbT2sqlDVdYtmdEEqSR7H7fJLTrGq2z0c 95/mjWze6bDbaCFYTg858rTDn8f1H8YVdiJdQMwmRLm3840VmrGJcvJOe0hFBdkm9CmS 1gSNbQFpHA2XasizuLX+mTfnW5cHWac+cxxtFwDVRfLiO/0LaNvi9Kvd8j2vbI6qu51c 4c6g==
X-Gm-Message-State: AOJu0YwRiz75vbwpNv9CbbnxYr8Ig/c7W9EleL2w9BjNpUEty0Ez0saP BEkYdMAUtsvfFlqPfTmTC9LpQmkDxdMegpJTeoHjS3Tk
X-Google-Smtp-Source: AGHT+IFe4qhSNJClcynFZx7U7kPbAUM52tohfu/OcA60uRFxONJm+gl1q3C6Ilw85Lpw4wCboVIxkhlh8aUYJolyxzI=
X-Received: by 2002:a05:6902:72f:b0:d9a:fedc:cbf4 with SMTP id l15-20020a056902072f00b00d9afedccbf4mr12900927ybt.21.1698088205101; Mon, 23 Oct 2023 12:10:05 -0700 (PDT)
MIME-Version: 1.0
References: <d24f64235d5d4436ae51a05c7d5c0b18@huawei.com> <CALhTbpq37wt32ibxdcbm+_DuA9kjKffBuY8CfZk4m_cFaqjvVg@mail.gmail.com>
In-Reply-To: <CALhTbpq37wt32ibxdcbm+_DuA9kjKffBuY8CfZk4m_cFaqjvVg@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 23 Oct 2023 12:09:53 -0700
Message-ID: <CA+RyBmVka=3GP=zVzKNyFngTZa+b5nwY7zuWMoDF1hxmitMyhQ@mail.gmail.com>
To: Henrik Nydell <hnydell@accedian.com>
Cc: Tianran Zhou <zhoutianran=40huawei.com@dmarc.ietf.org>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000432eb2060866f879"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/36CDf5Bq5WhUG4Vdxs_GWzFW0o8>
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: Mon, 23 Oct 2023 19:10:10 -0000

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> 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> 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
>> https://www.ietf.org/mailman/listinfo/ippm
>>
>
>
> --
>
> *Henrik Nydell*
> *Sr Product Manager*
> 1.866.685.8181
> hnydell@accedian.com
>
>
> Accedian is now part of Cisco. Read more here
> <https://blogs.cisco.com/news/cisco-announces-intent-to-acquire-accedian>.
>
> <https://www.facebook.com/accedian/>  <https://twitter.com/Accedian>
> <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.
>