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

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 10 October 2022 19:53 UTC

Return-Path: <brian.e.carpenter@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 287E9C152710; Mon, 10 Oct 2022 12:53:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Level:
X-Spam-Status: No, score=-7.106 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, NICE_REPLY_A=-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_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 DCPzoBg4eao2; Mon, 10 Oct 2022 12:53:31 -0700 (PDT)
Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 1AB67C152707; Mon, 10 Oct 2022 12:53:00 -0700 (PDT)
Received: by mail-pf1-x433.google.com with SMTP id i3so11609765pfk.9; Mon, 10 Oct 2022 12:53:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=n7b/SFW+hHKHaV5BWXVmif+yWIHGpnrSdT1nw+78qWQ=; b=glQFcu6nMK8vUqRaFgL37xH+Ud25F/2+c9fkPvyjI39UngjthofXX8NZnFdOd56A3h Odrq5KThn2CyJjtxAlrotB/AvZNefdTkoZc+4QIVb3zHfqJY1RH8ODeuMDFw4tBAeTZs BTTHTBnFq97qI3uMZYIBFx3XmPgWKFrqGPD18GBcWXkiaudzn14GE5fXA6mzxRiz/KeX RfsV+rn68aZIx6vHxEU5dcT1hOQUze74Q6EdzdimEx3ZgP6XPICYCL7hANnkNFFkJPFX y7q5IxiqsBu5E3tt+9RGdeYiOAR28aBiRcleTPokLyWnoJMC71W0RZUTvKq0dp545jwc mv7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=n7b/SFW+hHKHaV5BWXVmif+yWIHGpnrSdT1nw+78qWQ=; b=L07J0B9UXWFC1KyUgtceNNkLpvucWOxMUzA7ndqTV+wPV/mDRile/Mq3VyEfORH9gf YqG5MhPMKApQLO/PsQBju0QhzcLGmAcd41Pp3usS2SP9zVXfhPNwz0VdZjlQYAXp8Lgr M7e60jsKmLfoXkQFO0lGWS1EwCW/0B4ISuwKZgSYDe1kI/k6WXVlcBiKKBHSPC0EFPak QiLkdRbQKTXljep3AdEC/Z3pqmEujcuJNQu5DLNITgNIyRyp1d7KlfWKn7VRndnqxWQL c2cmJPCtmhmrOVwORrNkTaVa9LOgYvJNzESBVVDGOgzMeg5osUUapAAxq7rBqxWCUkEa RElg==
X-Gm-Message-State: ACrzQf0cbN5M6UVGLCS+S7XmhcDcx4cqe9R16zYLK3zvDSKCqlZzsKSK EX8g/nwlvjVVbx2lpqzaVAk=
X-Google-Smtp-Source: AMsMyM6cspDTV77Imr5Wuy0og84v3vixDBpQr1HLnguaxZ5pO1Svf2u52GanBzx3041tw81TDEsrOg==
X-Received: by 2002:a63:2a81:0:b0:43c:5fa6:1546 with SMTP id q123-20020a632a81000000b0043c5fa61546mr18044174pgq.43.1665431579196; Mon, 10 Oct 2022 12:52:59 -0700 (PDT)
Received: from ?IPV6:2406:e003:1124:9301:80b2:5c79:2266:e431? ([2406:e003:1124:9301:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id y10-20020a17090a154a00b0020d48bc6661sm1838378pja.31.2022.10.10.12.52.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Oct 2022 12:52:58 -0700 (PDT)
Message-ID: <e096bd13-983b-5801-95b2-a3d0210a9633@gmail.com>
Date: Tue, 11 Oct 2022 08:52:52 +1300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Dirk Steinberg <dirk@lapishills.com>, David Farmer <farmer=40umn.edu@dmarc.ietf.org>
Cc: Joel Halpern <jmh.direct@joelhalpern.com>, SPRING WG List <spring@ietf.org>, 6man <ipv6@ietf.org>
References: <CAFU7BARixwPZTrNQOuEw3WP-FqUsVwTj7btMTahcMbXm_NqWGw@mail.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> <CAOj+MMFGRjevpYLGxwiRs1GP-yN8eAxE6a7JKxuhbsYrJgUyLA@mail.gmail.com> <0d911d38-b939-692a-9b8b-24ff752672bc@joelhalpern.com> <CAOj+MMEnYR-ORvtUg+mrq=TW=QXrKYRXoJx=eaFhv2rc+rb+WQ@mail.gmail.com> <CAN-Dau1iOPn5kiu1nxNmp7U+ziCqN1m+isadBwQTZfz1WTFgiQ@mail.gmail.com> <CAOj+MMHWGVDKO5NAzP=hcb3swoO-i+PKz+dkb7j-AZ5CY=DYWQ@mail.gmail.com> <CAN-Dau0-r1xJ5_iR+ec8PRMXuVijkkhoi5EYRW72FtB1CkB28A@mail.gmail.com> <CAFqxzqYGcZL-szk5oVT9kFn0SBn4EyGqs0H8NTbeLNh8nMNJqw@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <CAFqxzqYGcZL-szk5oVT9kFn0SBn4EyGqs0H8NTbeLNh8nMNJqw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/bYl-ab53a8dzQ1TyLHqTf4cIpVw>
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 19:53:32 -0000

Dirk,

I'm not picking on your message particularly, because the comment below
could be made on many of the messages on this thread:

On 11-Oct-22 04:51, Dirk Steinberg wrote:
> Well, an IPv6 packet with an SRH first of all is a legal IPv6 packet.
> 
> Dropping of IP packets which are not malformed by transit domains
> based on arbitrary local policies is a very bad thing IMHO.

The operators who do so, which are in fact rarely transit providers,
but either ISPs or enterprise operators, or even domestic users who
don't know that their CPE is doing it, don't care about Internet
transparency or about some interpretations of the end-to-end principle.
They care about their interpretation of security and anti-penetration.
The reality is, and has been for most of the last 25 years or longer,
that some packets are systematically dropped for this reason. Anyone
who thinks this is untrue should perhaps start with RFC7872, RFC9098,
RFC9288 and draft-elkins-v6ops-eh-deepdive-fw.

Also, the concept of "limited domains" that some people love to hate
isn't a proposal, it's an observation of running code.

Regards
    Brian

> 
> If many operators adopt such practices based on their very own local
> policies we will end up with a network which is NOT the Internet anymore,
> but rather some unreliable internetwork where it becomes unpredictable
> if packets can be sent end-to-end or not.
> 
> This is NOT my understanding of the Internet.
> 
> I strongly object to transit domains dropping packets based on
> arbitrary local policies regarding arbitrary extension headers.
> 
> The presence of an SRH for example has NO security or other
> negative implication for any transit domain. Note that the keyword
> here is TRANSIT. If the IPv6 DA is within that operators domain
> things are different, but then the operator will want to filter at his
> domain ingress based on the IPv6 destination address being from
> his (protected) address space. Such filtering is justified.
> 
> Cheers
> Dirk
> 
> On Mon, Oct 10, 2022 at 6:32 PM David Farmer <farmer=40umn.edu@dmarc.ietf.org <mailto:40umn.edu@dmarc.ietf.org>> wrote:
> 
>     Well, I'd agree it is contrary to several RFCs, but illegal is way too strong of a word and implies somehow that RFCs gained the force of law that I'm not aware they have.
> 
>     Furthermore, declaring the dropping of packets as evil is additional unnecessary hyperbole.
> 
>     Finally, if we are going to go after people for committing immoral acts against packets, dropping them because of SRH headers is fairly low on my list.
> 
>     Thanks
> 
>     On Mon, Oct 10, 2022 at 10:05 AM Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>> wrote:
> 
>         David,
> 
>         No, that is not what I am saying. I am saying that the concept of limited domains is very loosely defined in rfc8799 and using it as a base to drop packets which contain SRH is not right.
> 
>         For example are my enterprise sites interconnected with SD-WAN a limited domain - surely is for me even if I use vanilla IPv6 Interconnect to talk between them.
> 
>         And let's not worry about such sites' security ... This is a completely different topic. Let's agree that dropping IPv6 packets somewhere in transit only because they contain specific extension header is illegal.
> 
>         Thx,
>         R.
> 
> 
> 
> 
>         On Mon, Oct 10, 2022 at 4:56 PM David Farmer <farmer@umn.edu <mailto:farmer@umn.edu>> wrote:
> 
>             If you are saying the concept of Limited Domains does not apply to SRH since it isn't an IETF consensus document, then I believe that calls the consensus for SRH into serious question. Furthermore, if the SRH consensus is questionable, the idea that operators might filter it shouldn't be surprising.
> 
>             Thanks
> 
>             On Mon, Oct 10, 2022 at 9:24 AM Robert Raszuk <robert@raszuk.net <mailto:robert@raszuk.net>> wrote:
> 
>                 Joel,
> 
>                 Am I wrong understanding that definition of "limited domain" was never approved by any formal IETF process ?
> 
>                 If so do you really think we should be bounded on something which has been defined outside of IETF ?
> 
>                 Cheers,
>                 Robert
> 
>                 On Mon, Oct 10, 2022 at 4:03 PM Joel Halpern <jmh.direct@joelhalpern.com <mailto:jmh.direct@joelhalpern.com>> wrote:
> 
>                     SRH was explicitly defined for use in limited domains.   That is why I think dropping it is acceptable.  Certainly not required, but permitted.  The closest equivalent is NSH, which is also defined for limited domains.  In my personal opinion (not speaking for the SFC working group) I think it would be legitimate for a domain, particularly one that is using NSH, to drop packets where the IP carried protocol is NSH.  (I would prefer that they block only packets to their domain with carried protocol of NSH, but that is up to the operator.)
> 
>                     You have said that you consider the limited domain requirement to be wrong and irrelevant.  Whether you agree with it or not, it is in the RFC.  Operators may reasonably act on that.
> 
>                     Yours,
> 
>                     Joel
> 
>                     On 10/10/2022 9:59 AM, Robert Raszuk wrote:
>>                     >  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 <mailto: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
>>
>                 --------------------------------------------------------------------
>                 IETF IPv6 working group mailing list
>                 ipv6@ietf.org <mailto:ipv6@ietf.org>
>                 Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>                 --------------------------------------------------------------------
> 
> 
> 
>             -- 
>             ===============================================
>             David Farmer Email:farmer@umn.edu <mailto:Email%3Afarmer@umn.edu>
>             Networking & Telecommunication Services
>             Office of Information Technology
>             University of Minnesota
>             2218 University Ave SE        Phone: 612-626-0815
>             Minneapolis, MN 55414-3029   Cell: 612-812-9952
>             ===============================================
> 
> 
> 
>     -- 
>     ===============================================
>     David Farmer Email:farmer@umn.edu <mailto:Email%3Afarmer@umn.edu>
>     Networking & Telecommunication Services
>     Office of Information Technology
>     University of Minnesota
>     2218 University Ave SE        Phone: 612-626-0815
>     Minneapolis, MN 55414-3029   Cell: 612-812-9952
>     ===============================================
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     ipv6@ietf.org <mailto:ipv6@ietf.org>
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
>     --------------------------------------------------------------------
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------