Re: [ippm] Question about rfc8972 STAMP TLV

Greg Mirsky <gregimirsky@gmail.com> Tue, 24 October 2023 00:56 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 EC045C170614 for <ippm@ietfa.amsl.com>; Mon, 23 Oct 2023 17:56: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 poZmVWhmgP_P for <ippm@ietfa.amsl.com>; Mon, 23 Oct 2023 17:56:06 -0700 (PDT)
Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 A4C5FC170619 for <ippm@ietf.org>; Mon, 23 Oct 2023 17:56:06 -0700 (PDT)
Received: by mail-yb1-xb2e.google.com with SMTP id 3f1490d57ef6-d9fe0a598d8so1351527276.2 for <ippm@ietf.org>; Mon, 23 Oct 2023 17:56:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1698108965; x=1698713765; 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=OG1IG4hlxbI+JO8Z3XdCn60+U1d1ve3kgodAgNIwzAo=; b=njk5GXlsRvL4h3qnGsR9co7PFObooviYtkrCvKLA3lL/UD3JvrKfjX6cMzSfLEe8sn fLH7BnWUcgdgcBpYa0W1Pj4g864xiI8rIqi4SaghChc2GAaguITjgmJ/6PsJ/S+U5bDj j4QFgy5iY0+80DnKNK95bZMDLkFpZlbBEsP0+vKQTfI8615qopvWLgiMKHYk+kEixOFx vf+N69nQ2tCeZ6TClZFbfgB1Q1cGmDVRlNLEOajs8NwD6+0LM/7EflcGuagj2lkdNdUc sYOC9XDDHQpMAuTQvVkJ5xKr46iOM/afVXBMx2CbIvifoYccHOSo216QQMDpNBu71+5L xvrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698108965; x=1698713765; 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=OG1IG4hlxbI+JO8Z3XdCn60+U1d1ve3kgodAgNIwzAo=; b=CAx+n4/HgOzs+lXtm010BWZ/3WdJeThfTDsuy5VosZMM/lz0OeUrw44qLPXxycjncx hr8P4pWtGcCWtM/s7G1IUZYhFZuqnfTDaF/gi9cducnP2cSRwXjV8CmSYsLPJSGqcHV3 H3uz86AaagVe6rOblHPyEEfDOCV2Y052NfDBlaaY9yDd/i6wjsTtgFpx8Qy896PtqAA5 HYglbSUEi3gj8DTznfKULfyNqt8bjnOECenvK7sdGHUJqUo+2mn0xCQaO4Zh9hpx5THi cQDCt3cKOJR/hlPy2tCrAY9p80Aw6ZaTmg2r9K7KHLOc2gjkFpY+VDX9LukGglHdVMi6 mv8w==
X-Gm-Message-State: AOJu0YxD0uB94wfgsdqACnQvxmUojvkI+TaNaDbsSx4bh07wyHBPrhij 8mmjKalH0LsRXShkSE1J22hXTPULvANHWUIud5k=
X-Google-Smtp-Source: AGHT+IEGJBL/pB+JviBJrP2VM+NYccttyrZ85bS1YRNN7QB4FgDEjrTIKU4idNoZwrTpm6Gye4yCrf5KpIQdnXIhW6o=
X-Received: by 2002:a25:b85:0:b0:d9a:ba4b:44ab with SMTP id 127-20020a250b85000000b00d9aba4b44abmr9822944ybl.61.1698108965317; Mon, 23 Oct 2023 17:56:05 -0700 (PDT)
MIME-Version: 1.0
References: <d24f64235d5d4436ae51a05c7d5c0b18@huawei.com> <CALhTbpq37wt32ibxdcbm+_DuA9kjKffBuY8CfZk4m_cFaqjvVg@mail.gmail.com> <CA+RyBmVka=3GP=zVzKNyFngTZa+b5nwY7zuWMoDF1hxmitMyhQ@mail.gmail.com> <2b83a1d743e843f7aa0b671215c6a9fc@huawei.com>
In-Reply-To: <2b83a1d743e843f7aa0b671215c6a9fc@huawei.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Mon, 23 Oct 2023 17:55:54 -0700
Message-ID: <CA+RyBmXwuDhBVAU8XNBenqFQA=S-8-FK0acDEXSLwkbHgDr4Qw@mail.gmail.com>
To: Tianran Zhou <zhoutianran@huawei.com>
Cc: Henrik Nydell <hnydell@accedian.com>, IETF IPPM WG <ippm@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000aaf39706086bcd37"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/0l6uxuYPA6Lbyno1PFIUKDMeZ44>
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:56:11 -0000

Hi Tianran,
thank you for clarifying the question. I think that for a Session-Reflctor,
wildcards must be allowed for all elements that characterize the
Session-Sender, e.g., source IP address, source UDP port number. I don't
expect that the Session-Reflector will implicitly have STAMP enabled on all
of node's IP addresses and all UDP ports. WDYT?

Regards,
Greg

On Mon, Oct 23, 2023 at 5:17 PM Tianran Zhou <zhoutianran@huawei.com> wrote:

> 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>
> 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.
>
>