IETF Logo Mail Archive

Re: [spring] 6MAN WGLC: draft-ietf-6man-sids

Robert Raszuk <robert@raszuk.net> Mon, 10 October 2022 13:59 UTC

Return-Path: <robert@raszuk.net>
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 F1E4EC1522B1 for <spring@ietfa.amsl.com>; Mon, 10 Oct 2022 06:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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_SCC_BODY_TEXT_LINE=-0.01, 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=raszuk.net
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 xW71DPeBLWtt for <spring@ietfa.amsl.com>; Mon, 10 Oct 2022 06:59:46 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 1A2C9C14CE20 for <spring@ietf.org>; Mon, 10 Oct 2022 06:59:46 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id n35-20020a05600c502300b003b4924c6868so7207375wmr.1 for <spring@ietf.org>; Mon, 10 Oct 2022 06:59:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=CaMX3If03AfSbdVQVig7kAGE1GD5TpjWuWwSX9W0sfc=; b=ZiwqdOWu4HeHYctdj9lEwso+eJHRmu8DrNHWRyw7IvK9x35ax8mEMMJp+scBJTnj7a shd0AcrSYndfszQZNzS9tJbOO6zXipZrmu7IKJNIv+zzvPS5SgdqFK/Jfloo7XRCn/Zm fZxXeNnbCsnMyGdO8szTadeIlwTmmEEHcjrxvSG5CKYd+YKEYqXbUc9vomiduKhfpzAx aL/nyycEuGgnt8BfYF62LIarBU4hbmQVdkXfTQuNDN91W4Fzs9LZrzjQTWAyRxdhjG26 83dQC4b+mpeIAjwkJGxMpE2d8LzJqcGwks8biqdxg5nnvSAfR3RzGSo39838V8cCvdOq tlBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=CaMX3If03AfSbdVQVig7kAGE1GD5TpjWuWwSX9W0sfc=; b=y3abBmRvWQ4aLK18aB9zVJYgLEgXM4+Ox5OfgexPT8jUCBghAhKza2k0wiX61oBr3l xj2zHv9/70mYydUwzhBxDSL3p6BJAdQ9DtnPcGirKNPLqjBxdoi73L+b02+xQRYGVV6L O00fE9TWB/6qYcTMJR1O6XIXrunFHMCKmz7OdlO78k8nUa+fv81RhQSJkPPEiXOKJ3hD eZ32SC8d1ie9uoHUD5j42HU5mo1PwzP1knuckw4WzBvcVlU6H6ekE4ojeQZLD6Iwp/5Q MHmO+/cpzeeCecws43PnTHaAiYX3AmXO4OaVeXTKcA7Z2JMz80t9JlngWcCz8sVwCidX 41IA==
X-Gm-Message-State: ACrzQf24/mxczc0o+bs9cVmiMVl3HvZBw9Sd8y6d3FI5e5qbu2uA/UcH nwLF/2KcN7X3yIDojiCLfmPMNE7OQ3hN7S9Q5YNmFKqZGntM5A==
X-Google-Smtp-Source: AMsMyM5aGoebOVQ8zg0twMBmhSv2XNx3hTyUiFjW8HbxSbJT5AWzDLhFzL6AVCH4uwAnr9a66eep1clm1nq9mUM9b5c=
X-Received: by 2002:a05:600c:2255:b0:3c4:6c57:3d19 with SMTP id a21-20020a05600c225500b003c46c573d19mr8542591wmm.92.1665410384442; Mon, 10 Oct 2022 06:59:44 -0700 (PDT)
MIME-Version: 1.0
References: <CAFU7BARixwPZTrNQOuEw3WP-FqUsVwTj7btMTahcMbXm_NqWGw@mail.gmail.com> <CAB75xn4Zme4KOjPuY1_-4jCKTk1jshbq8X645zXhYQLiKB+N9g@mail.gmail.com> <54A38015-95AD-41F0-8E9D-76B3E62AA55B@gmail.com> <bdd7bf12-f712-3fe5-2698-9272c16ddded@joelhalpern.com> <58E77509-A1A1-4CE8-9EE4-22BEEEA8B62E@gmail.com> <98a941e4-0fff-ced1-d4ca-4406368eac31@joelhalpern.com> <4DC495DF-AD6B-4D60-80C4-B836DD365A0C@gmail.com> <CAOj+MMEx7+jWN1yC=81dMwo5GmqbhyHqOZr9W2_qzN9BNjs+Zw@mail.gmail.com> <ab55e9c0-60b9-2986-07f1-38c28852009e@joelhalpern.com> <CAOj+MMEn6Dz-Rz0PRRvR8VXT8idAQm+rLuouWJoNz-dA+kRkJQ@mail.gmail.com> <1fe2d387-8ecc-5240-092c-84a5978af5e4@gmail.com> <CAOj+MME6Nb3MLQCiGQ5S06Cwj6d3Z+aoSpxwFdtoFaV-yPPuJQ@mail.gmail.com> <e65772a1-bc86-c59c-e99f-7cabf92f28a4@joelhalpern.com> <183BB8B9-A338-4136-8546-7C7858B4D4E4@cisco.com> <35484ed3-509a-39ba-6a16-8f2bf807f4f2@joelhalpern.com> <BAAD744A-2AD2-4498-90EC-9C9A184E0A8A@cisco.com> <CAOj+MMGjTa+zwRHnRWWu-+bRZd83vo4xz22XuRK+7TJ5A81DQQ@mail.gmail.com> <a10a6d8c-ef59-398b-1b53-dc3e688c16b0@joelhalpern.com>
In-Reply-To: <a10a6d8c-ef59-398b-1b53-dc3e688c16b0@joelhalpern.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Mon, 10 Oct 2022 15:59:32 +0200
Message-ID: <CAOj+MMFGRjevpYLGxwiRs1GP-yN8eAxE6a7JKxuhbsYrJgUyLA@mail.gmail.com>
To: Joel Halpern <jmh.direct@joelhalpern.com>
Cc: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, 6man <ipv6@ietf.org>, SPRING WG List <spring@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005ecb6a05eaae9229"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/vtFyjsENgjkzRWWJs1lA53S-2GQ>
Subject: Re: [spring] 6MAN WGLC: draft-ietf-6man-sids
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: Mon, 10 Oct 2022 13:59:50 -0000

>  it seems acceptable to block all packets with SRH

And such statements you are making are exactly my point.

Just curious - Is there any other extension header type subject to being a
good enough reason to drop packets at any transit node in IPv6 ?

Thx,
R.

On Mon, Oct 10, 2022 at 3:53 PM Joel Halpern <jmh.direct@joelhalpern.com>
wrote:

> Protection from leaking inwards is required by the RFCs as far as I know.
>
> Note that there are multiple ways to apply such protection.  It is
> sufficient for the domain only to block packets addressed to its own SID
> prefixes.  If the domain is using SRv6 without compression or reduction, it
> seems acceptable to block all packets with SRH.  After all, they should not
> be occurring.  But we do not tell operators how to perform the filtering.
> It is up to them what they do.
>
> Yours,
>
> Joel
>
>

v2.23.0 | Report a Bug | By Email