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

Joel Halpern <jmh@joelhalpern.com> Mon, 10 October 2022 15:35 UTC

Return-Path: <jmh@joelhalpern.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 9C1A0C14CF0B; Mon, 10 Oct 2022 08:35:50 -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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 KjiA1saQ5rlb; Mon, 10 Oct 2022 08:35:46 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 B53A3C14F693; Mon, 10 Oct 2022 08:35:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4MmNKZ3rFDz1p7Fg; Mon, 10 Oct 2022 08:35:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1665416146; bh=co+K2kmJqeqGeJgxIPIpF40pZUOYVFZBnUao8nNuAzo=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=DoNLMSGFclXrMa7uH/SUDNICkh3t9EpFFWNp2ig9OHmPFNUwfDlPrBi45UbQCceYl xparHYBKg2wGZenNW+Cs7hhOboV7zeVChoumpkNhkEVaqVfD7LwMTudv0jKNlGYh9R 9IaOk0KoSmXd3782pGp5NVyL5N/nPXfYguc7qHuI=
X-Quarantine-ID: <nw-4XoV8pTiq>
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [192.168.23.73] (unknown [50.233.136.230]) (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 mailb2.tigertech.net (Postfix) with ESMTPSA id 4MmNKY6lzgz1nsML; Mon, 10 Oct 2022 08:35:45 -0700 (PDT)
Message-ID: <8181802b-0319-4609-2679-8ced5993bdac@joelhalpern.com>
Date: Mon, 10 Oct 2022 11:35:45 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1
Content-Language: en-US
To: Ole Troan <otroan@employees.org>
Cc: 6man <ipv6@ietf.org>, SPRING WG List <spring@ietf.org>
References: <35484ed3-509a-39ba-6a16-8f2bf807f4f2@joelhalpern.com> <95BA9A88-CCC3-4E4B-9283-5BF38EDC79D0@employees.org>
From: Joel Halpern <jmh@joelhalpern.com>
In-Reply-To: <95BA9A88-CCC3-4E4B-9283-5BF38EDC79D0@employees.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/QRrV9mBd0nLEjYod_NP29TDhUto>
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 15:35:50 -0000

There appear to be two separate issues, only one of which affects this 
document.

The issue that affects this document is that the SRH document explicitly 
requires that domains using SRH filter it at ingress and egress edges.  
That is what is relevant for the document at hand.  And while some folks 
have envisioned use cases that violate that, the RFC is clear that it is 
prohibited.  (My reading is that this also applies to SRv6 in general, 
even when compressed SIDs with no SRH are used.)

The question of whether, in doing enforcing that requirement a domain 
may filter more packets that should not be received is about how the 
operator chooses to enforce the requirement.  We are not specifying how 
the operator does the enforcement.

The question of what transit domains are permitted to do is one that 
reasonable people appear to be able to differ on.  But it is not a 
relevant question for this draft.

Yours,

Joel

On 10/10/2022 10:31 AM, Ole Troan wrote:
> Joel,
>
>> On 10 Oct 2022, at 15:36, Joel Halpern <jmh@joelhalpern.com> wrote:
>>
>> Eric, you seem to be objecting to something I did not say.  I have not asked, and do not expect, for the document to mandate or even suggest that arbitrary domains should drop packets with SRH.  I will note that given that SRH is explicitly for limited domains, an operator who chooses to drop such packets is well within his rights.  And I am told there are such operators.  But that is not what I asked for this document.
> No, that would violate rfc8200.
>
> O.