Re: [spring] [WARNING: SUSPICIOUS SENDER] Request comments/feedback on https://datatracker.ietf.org/doc/draft-zzhang-spring-microtap-segment/01/

Eduard Metz <etmetz@gmail.com> Fri, 01 March 2024 11:42 UTC

Return-Path: <etmetz@gmail.com>
X-Original-To: spring@ietfa.amsl.com
Delivered-To: spring@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9B2C14CE25; Fri, 1 Mar 2024 03:42:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 l-t2S5qHWs2p; Fri, 1 Mar 2024 03:42:40 -0800 (PST)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 DCC73C151062; Fri, 1 Mar 2024 03:42:40 -0800 (PST)
Received: by mail-lf1-x12f.google.com with SMTP id 2adb3069b0e04-5131d0c3517so1887963e87.1; Fri, 01 Mar 2024 03:42:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709293359; x=1709898159; 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=t/PMoDxU8i+93+Euki2ij8OKSsztHbKL6wN8iIer6rw=; b=SLHPwcgYdPGZJXFSkRlBdHYxPIvS+w1syorDs/hijWHZu5eWI2bd1JW3bjFgbgys8A 73QJM6KAvi5Abc8qvxEX8enizQogEDuOkDcEeSmJraVPZS3ZZEuRVt4rsI2vjm26L+S0 HMmXjvcWzYV1H+BR2IsOKZfZk1lvNRw3fj2jVuGQzFJqJPE+mFVlNrxYvTMFsJ/LABLo p8ozR2oBavx9lUXx3vJ66JogwGHdxl95LHmdlzLsrNH0qOTUpdODRxGZ4q4a2M0UPJSQ y8eezNsFVbJgMHXij0Q0G8umhaBiFi6RFMuB6vldlUNPOqShUU0hTrr4j6vxUpPmLd/2 tgwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709293359; x=1709898159; 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=t/PMoDxU8i+93+Euki2ij8OKSsztHbKL6wN8iIer6rw=; b=UjSpxNC3+h1AuVr1dL6A/ccFv7PS9TPriGXUdxVqPVQ4DCMOJ3V8w1N5MU5d9lSkxl Dco4RcmkH8GEeByx+Debftrdsp6CkE47evbREFCBMqkIoIKUGpaaKx/KqWEMPRlM7v8B 4cguxjU+y/CB8J7NGi7GMgnYozlnTxQKJm9x+qC0Np2WE9ZNZw+PufA4Us72EiDgFO1T Eby0OcGR/i6PW6vKIQHof6hCrryIXUED0WbYJrWksHSiyhTY1etbkFor+tRhZHo/ghHN o1PZXFDQ0gGNIJtJTB5z29oDGJVFrrJ1VMC2u3ppE1lPvxy8YU14iAy2TBvrPpnCDffT tU6A==
X-Forwarded-Encrypted: i=1; AJvYcCUPAbGMUprlUbZqK8UJgWlXDG9rn/PM9Eg8HrxBR1ujpZENdtHCF3gtxHceB5db4q7jwpLGcxGhwULY4YqJejUjl1OCKpTwkK0GHXuPwH6Odl2p2M6lDirTUxvPabrObJ6Fhkm1YxKMyJ2DfggN8Q==
X-Gm-Message-State: AOJu0Yzkf/yhiOtDQOMVOeTRgTRZvfk6N87BKXqOcbDPzlx5drWMeO3K dAiPWx7pxUWqJeli2HQSGve9BH7hOSuy6mOcbtIjf8qaAPA/bnF5T3yl8VLdLJ5OwjmkKqtOk3Z 83Zr2Ze0gQ1LTSUT81awS63NUZOZTtGMqoM8=
X-Google-Smtp-Source: AGHT+IEtwWqcwecT/lAeG3UJL00hTg0eUAvIiPJLbTAkQthiRekI84mhW3A92GNDJugfUeqhGCcJyU0QCYVkvHMu+Fc=
X-Received: by 2002:a19:740c:0:b0:513:346a:5a16 with SMTP id v12-20020a19740c000000b00513346a5a16mr350184lfe.9.1709293358574; Fri, 01 Mar 2024 03:42:38 -0800 (PST)
MIME-Version: 1.0
References: <CAKsJ_vjpjKC=9wDboxVK0UZFE=_SnogrwWKso-AaQ0eezq4WBw@mail.gmail.com> <3187342B-DA67-4857-A4E6-926CF54861D2@gmail.com>
In-Reply-To: <3187342B-DA67-4857-A4E6-926CF54861D2@gmail.com>
From: Eduard Metz <etmetz@gmail.com>
Date: Fri, 01 Mar 2024 12:42:26 +0100
Message-ID: <CAG=3OHdWa_iVxJtB_VpdWDHdPqa3KgYsBstBnff1qxyHP-m=mw@mail.gmail.com>
To: Jeff Tantsura <jefftant.ietf@gmail.com>
Cc: Ryan Hoffman <ryan.hoffman=40telus.com@dmarc.ietf.org>, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, spring@ietf.org, draft-zzhang-spring-microtap-segment@ietf.org
Content-Type: multipart/alternative; boundary="00000000000074729e061297df13"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/b_HaCG11vrVw8osAlcHV_2sRzQw>
Subject: Re: [spring] [WARNING: SUSPICIOUS SENDER] Request comments/feedback on https://datatracker.ietf.org/doc/draft-zzhang-spring-microtap-segment/01/
X-BeenThere: spring@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:spring-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spring/>
List-Post: <mailto:spring@ietf.org>
List-Help: <mailto:spring-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:spring-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Mar 2024 11:42:41 -0000

I think this is a relevant use-case / feature.

Few comments after first read:
- For SRv6 the procedure may be slightly different, ie steer traffic via
MicroTAP capable node or have MicroTAP as integrated capability of
"default" forwarding (of capable nodes) and indicate the parameter - this
is the approach in the current draft if I understand correctly.
- Section 2.3 describes that if a MicroTAP SID becomes the active on the a
node not supporting the MicroTAP capability, the packet would be dropped. I
wondered if this is correct? Wouldnt the packet be forwarded to the
"monitor" node? This breaks the communication effectively, but not a drop
at the node not supported MicroTAP.
- In general, or least for intercept, one would be interested in both
directions of a traffic stream (e.g to / from a specific IP). To
address this, the MicroTAP SID would need to inserted on all relevant
ingresses. And the monitor may receive packets from different MicroTAP
capable nodes. This may have implications for the use of IOM header (e.g.
to avoid duplicate sequence ids)

cheers,
  Eduard


On Wed, Feb 28, 2024 at 4:52 AM Jeff Tantsura <jefftant.ietf@gmail.com>
wrote:

> Seems like a very useful feature indeed.
>
> Cheers,
> Jeff
>
> On Feb 27, 2024, at 07:15, Ryan Hoffman <ryan.hoffman=
> 40telus.com@dmarc.ietf.org> wrote:
>
> 
> TELUS intends to deploy this microTap segment feature once available in
> vendor NOS after thorough testing in our lab.  We'd expedite TELUS testing
> and deployment when available from vendors, as this is a much needed
> feature in our network.
>
> Thanks,
> Ryan Hoffman
>
> On Wed, Apr 5, 2023 at 3:28 PM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
> wrote:
>
>> Hi,
>>
>> The authors of this draft would like to get your feedback on this draft.
>>
>>    This document specifies a microTap segment that can be used to
>>    instruct a transit node to make a copy of a segment-routed packet and
>>    deliver it to a specified node for the purpose of network monitoring,
>>    trouble shooting, or lawful intercept.
>>
>> Due to the limit of Spring WG session time we have not been able to
>> present it but we submitted slides before:
>> https://datatracker.ietf.org/meeting/115/materials/slides-115-spring-slides-115-spring-microtap-segment-00
>> .
>>
>> Thanks.
>> Jeffrey
>>
>> Juniper Business Use Only
>>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>