Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)

Sander Steffann <sander@steffann.nl> Fri, 06 December 2019 15:12 UTC

Return-Path: <sander@steffann.nl>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE731200B1; Fri, 6 Dec 2019 07:12:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8myZsDccP_LQ; Fri, 6 Dec 2019 07:12:55 -0800 (PST)
Received: from mail.sintact.nl (mail.sintact.nl [83.247.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6163F1200C5; Fri, 6 Dec 2019 07:12:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 092334B; Fri, 6 Dec 2019 16:12:53 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:in-reply-to:date:date:subject:subject :mime-version:content-type:content-type:message-id:from:from :received:received; s=mail; t=1575645170; bh=fswxa8gHjX9eqShi2gx vrkkiPBoLr8q2MNVXFI2d3N8=; b=fzlZLr1kt8XMfYc6PSGKdI0vMLXFhBr6ART rHNy1rXvzzVjhFHGh9bQcIUgSY2PnlVBz8ZcDUbZwpGcMYRsjVqNBBDtxqvQeACt v5H10kJxoiK4I0jxUnzt+mXQck/qCPpU3abfwGbuTFsnz4jKJpK5YTtex6oReweX mdDwlch8=
X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl
Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id CgEVR7KmDF8v; Fri, 6 Dec 2019 16:12:50 +0100 (CET)
Received: from [IPv6:2a02:a213:a300:ce80:6075:199d:31e0:cdef] (unknown [IPv6:2a02:a213:a300:ce80:6075:199d:31e0:cdef]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id EB31749; Fri, 6 Dec 2019 16:12:49 +0100 (CET)
X-Clacks-Overhead: GNU Terry Pratchett
From: Sander Steffann <sander@steffann.nl>
Message-Id: <E3C0E460-9329-40B1-ACF6-B9D8F6E2B3DF@steffann.nl>
Content-Type: multipart/signed; boundary="Apple-Mail=_11F47E7E-ECB8-4145-8638-321712A3F9E5"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\))
Subject: Re: We don't seem to be following our processes (Re: Network Programming - Penultimate Segment Popping)
Date: Fri, 06 Dec 2019 16:12:48 +0100
In-Reply-To: <C7BCB0CF-1CA3-4CA8-9E71-13A013955938@employees.org>
Cc: Enno Rey <erey@ernw.de>, rtg-ads <rtg-ads@ietf.org>, Fernando Gont <fgont@si6networks.com>, SPRING WG <spring@ietf.org>, 6man <6man@ietf.org>, "int-ads@ietf.org" <int-ads@ietf.org>
To: Ole Troan <otroan@employees.org>
References: <BN7PR05MB56998A05469327E759B5B671AE5D0@BN7PR05MB5699.namprd05.prod.outlook.com> <3AD3BD11-8C34-41FE-B88F-49A9F2561D78@cisco.com> <BN7PR05MB569946D6AA5C6B78AFC05F6BAE5C0@BN7PR05MB5699.namprd05.prod.outlook.com> <8DEDE597-B7B0-48F5-959E-69757315C2AC@employees.org> <BN7PR05MB56996FFC117F512EEA04AFC8AE5C0@BN7PR05MB5699.namprd05.prod.outlook.com> <4FAB68A3-C533-471D-94D0-3F6EB1F32FC1@employees.org> <1e36a492-5931-02de-cf85-63339522b13a@si6networks.com> <F6DD2C7C-DBBF-4B48-B890-3C86005FB9CF@employees.org> <bb3be82d-8ea7-6c29-ad0a-61b491ee997d@si6networks.com> <8A9BC46E-A018-41C0-BE47-4BABC30EFE79@employees.org> <20191205222740.GA9637@ernw.de> <C7BCB0CF-1CA3-4CA8-9E71-13A013955938@employees.org>
X-Mailer: Apple Mail (2.3594.4.19)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/1tEoJBRPlbXTqh7GWW4CqDI7Fkg>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2019 15:12:58 -0000

Hi Ole,

> If I own and manage three routers, R1 -- R2 -- R3.
> You are saying that if R1 sends a packet to R3, it is not allowed to off-load some functions to R2?
> Going to be difficult to do stuff like service chaining then.

This bit I don't mind that much, but what about:

R1 -- R2 -- [open internet] -- R3
or
R1 -- [open internet] -- R2 -- R3
or even
R1 -- [open internet] -- R2 -- [open internet] -- R3

And what if you're an ISP and R1 is your customer's device? It is in your routing domain but not in your administrative domain. What then?

> When putting in the restrictions in RFC8200, which makes a lot of sense on the open Internet, it was always clear that there could and would be exceptions to this. Those are the ones we are discussing now.

This has never been clear to me. Quite the opposite actually…
There was a reason the text discussing this was tightened while RFC8200 was still a draft.

> Conflating the two use cases and claiming that the arguments for why it's a bad idea on the open Internet also applies to a limited domain, only serves to polarise the debate.

The problem is in the definition (and viability) of a domain.

> My suspicion is that the header insertion argument is a straw-man.

Not to me. I care about my packets not being mangled by a third party (my ISP). If there is a way that they can mangle the packet and restore it to its original 100% of the time before a box outside the ISP network is able to see it (for debugging or whatever) then I don't mind. I care about observable behaviour, and whether my ISP uses MPLS, SR or something else isn't my problem. But the moment the packet leaves their network it'd better be exactly as I sent it. And the way the domain is defined, as well as the operator experience with limited domains, points to potential leaks.

Cheers,
Sander