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

Robert Raszuk <robert@raszuk.net> Sun, 09 October 2022 14:49 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 B4D34C14CE2C for <spring@ietfa.amsl.com>; Sun, 9 Oct 2022 07:49:16 -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, 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=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 2N3pDlW-1mLn for <spring@ietfa.amsl.com>; Sun, 9 Oct 2022 07:49:12 -0700 (PDT)
Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 59D6CC14CF0E for <spring@ietf.org>; Sun, 9 Oct 2022 07:49:12 -0700 (PDT)
Received: by mail-wr1-x42f.google.com with SMTP id a3so13728937wrt.0 for <spring@ietf.org>; Sun, 09 Oct 2022 07:49:12 -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=6NibM/2TFwe5gexv2wi50IDFimSO0d04MvVWoCd8YTk=; b=K9vDRZxqKujLoe2AsGwWClIZMCbBlU0grOnNK3U2NOe9+GIW2BR7FYMl7gAnZMFj0W YfHUqY3v96K1owF46pjylqlut3/KkfqYeKwfIrNN8odpkaYf0CbB17GPjWAHtUueifr5 GjdvgRvnaDmALJQ04GpMd/yxINwGm4qqI4ZdqnTi33rBKye4P9jYQYmwqCGPptYtXnpB RymGn0dv5gKseNsQ/2O5+aWH2EK4nFTvXKmYrrEcSDcF9oHKgoeJzJJbDqF9fP5dcCZf GGnB4mCThxlyX2sKzpcDYVsML+GXyco5A25qCluFZex9sfT3hwCtPhrzvpv8tVuFjrPj FI7A==
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=6NibM/2TFwe5gexv2wi50IDFimSO0d04MvVWoCd8YTk=; b=wPl0ZnvxC06rqQELiMbSpXYrHoSuURGvSDl5Q0MyHEzH9HZTzAKKNWzVKwsHKCxm9H MO4woGw3EPGHHQn1fhU6Hosucs7GZqsN9yQX6hUPPrkRbKbMPfkVm6qIyawmZYRDCSx5 eAecjNalAWIw3P6ZumxJAYYfFp+2NUQ+pYNDFPaQkr+VVYo43YgoLZuEfdD79tSqd8M/ Svp+e5hylvMPMoXqi/rECMvv8a0HKYUCXhb0jL029rWYmbbByC6Wgaya4lYQa8vcN/qc /uv9PX5BgqdE+uK49iNdiK4Pdqpdd8lBUyplSQORukiDQhNRvZEdKf5n7XuJ8XrP3uzp dRYg==
X-Gm-Message-State: ACrzQf0ekjkdVCGzoS2tm2mk5GM9DfJkdXmrAVyjHolVxob0LnbsqHk/ RGvaa5mf0Xe62/0IomzBzRvipJJSEvaAdXwL4n8g3g==
X-Google-Smtp-Source: AMsMyM7kgZNkdCXoeHHELTq39ZZgGdThT7tAgPrzoI9ChkR47hus9jMUOZeosPjOCsuWVBgoGrZSX1H3WYybX9OWiXQ=
X-Received: by 2002:a5d:47a1:0:b0:22e:7507:a1ab with SMTP id 1-20020a5d47a1000000b0022e7507a1abmr8909948wrb.230.1665326949691; Sun, 09 Oct 2022 07:49:09 -0700 (PDT)
MIME-Version: 1.0
References: <CAFU7BARixwPZTrNQOuEw3WP-FqUsVwTj7btMTahcMbXm_NqWGw@mail.gmail.com> <CAB75xn4+N31=ggO03AAQJANv7RgHaC1eNGXRUQ9B20rLK+nJyg@mail.gmail.com> <E77D8982-11E9-45F9-81BF-3CA1E1F6B745@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>
In-Reply-To: <e65772a1-bc86-c59c-e99f-7cabf92f28a4@joelhalpern.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sun, 09 Oct 2022 16:49:48 +0200
Message-ID: <CAOj+MMF-dWpdLwQjc611Uv6s_0jaexvvRNmiMbkqxwjAfqwHbw@mail.gmail.com>
To: Joel Halpern <jmh@joelhalpern.com>
Cc: 6man <ipv6@ietf.org>, SPRING WG List <spring@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000045885405ea9b25d6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/PytYB811F0ppuPl2NeG429std7I>
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: Sun, 09 Oct 2022 14:49:16 -0000

Joel,

> it turns SRH into a powerful attack vector

Really ?

How is this possible if IPv6 destination address of the packet does not
belong to the block of locally allocated range used as ASN's infra subnet ?
I am talking about a pure IPv6 transit case.

Isn't this the case that SRH should be examined by the node listed in the
destination address of the packet ?

And of course it is common and very good practice to filter any external
attempt to reach my own address blocks use for management and node
configuration. But this is way more granular then to say kill all packets
entering my network which have SRH.

Thx,
R.

On Sun, Oct 9, 2022 at 4:37 PM Joel Halpern <jmh@joelhalpern.com> wrote:

> We require, per the RFC, blocking SRH outside of the limited domain for
> many reasons.
>
> One example is that it turns SRH into a powerful attack vector, given that
> source address spoofing means there is little way to tell whether an
> unencapsulated packet actually came from another piece of the same domain.
>
> So yes, I think making this restriction clear in this RFC is important and
> useful.
>
> Yours,
>
> Joel
> On 10/8/2022 5:07 PM, Robert Raszuk wrote:
>
> Hi Brian,
>
> Completely agree.
>
> One thing is not to guarantee anything in respect to forwarding IPv6
> packets with SRH (or any other extension header) and the other thing is to
> on purpose recommending killing it at interdomain boundary as some sort of
> evil.
>
> Cheers,
> R.
>
>
>
> On Sat, Oct 8, 2022 at 9:51 PM Brian E Carpenter <
> brian.e.carpenter@gmail.com> wrote:
>
>> Robert,
>>
>> > If there is any spec which mandates that someone will drop my IPv6
>> packets only because they contain SRH in the IPv6 header I consider this an
>> evil and unjustified action.
>>
>> The Internet is more or less opaque to most extension headers, especially
>> to recently defined ones, so I don't hold out much hope for SRH outside SR
>> domains.
>>
>> https://www.rfc-editor.org/rfc/rfc9098.html
>> https://datatracker.ietf.org/doc/html/draft-elkins-v6ops-eh-deepdive-fw
>>
>> Regards
>>     Brian Carpenter
>>
>> On 09-Oct-22 07:52, Robert Raszuk wrote:
>> > Hi Joel,
>> >
>> > I was hoping this is apparent so let me restate that I do not buy into
>> "limited domain" business for SRv6.
>> >
>> > I have N sites connected over v6 Internet. I want to send IPv6 packets
>> between my "distributed globally limited domain" without yet one more encap.
>> >
>> > If there is any spec which mandates that someone will drop my IPv6
>> packets only because they contain SRH in the IPv6 header I consider this an
>> evil and unjustified action.
>> >
>> > Kind regards,
>> > Robert
>> >
>> > On Sat, Oct 8, 2022 at 7:40 PM Joel Halpern <jmh@joelhalpern.com
>> <mailto:jmh@joelhalpern.com>> wrote:
>> >
>> >     Robert, I am having trouble understanding your email.
>> >
>> >     1) A Domain would only filter the allocated SIDs plus what it
>> chooses to use for SRv6.
>> >
>> >     2) Whatever it a domain filters should be irrelevant to any other
>> domain, since by definition SRv6 is for use only within a limited domain.
>> So as far as I can see there is no way a domain can apply incorrect
>> filtering.
>> >
>> >     Yours,
>> >
>> >     Joel
>> >
>> >     On 10/8/2022 3:16 AM, Robert Raszuk wrote:
>> >>     Hi Suresh,
>> >>
>> >>         NEW:
>> >>         In case the deployments do not use this allocated prefix
>> additional care needs to be exercised at network ingress and egress points
>> so that SRv6 packets do not leak out of SR domains and they do not
>> accidentally enter SR unaware domains.
>> >>
>> >>
>> >>     IMO this is too broad. I would say that such ingress filtering
>> could/should happen only if dst or locator is within locally
>> configured/allocated prefixes. Otherwise it is pure IPv6 transit and I see
>> no harm not to allow it.
>> >>
>> >>         Similarly as stated in Section 5.1 of RFC8754 packets entering
>> an SR domain from the outside need to be configured to filter out the
>> selected prefix if it is different from the prefix allocated here.
>> >>
>> >>
>> >>     Again the way I read it this kills pure IPv6 transit for SRv6
>> packets. Why ?
>> >>
>> >>     (Well I know the answer to "why" from our endless discussions
>> about SRv6 itself and network programming however I still see no need to
>> mandate in any spec to treat SRv6 packets as unwanted/forbidden for pure
>> IPv6 transit.)
>> >>
>> >>     Thx,
>> >>     R.
>> >
>> >
>> > --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > ipv6@ietf.org
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>>
>