Re: Limited Domains:

Toerless Eckert <tte@cs.fau.de> Wed, 14 April 2021 22:01 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 3091A3A21A0; Wed, 14 Apr 2021 15:01:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.869
X-Spam-Level:
X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 XlozEKXvN75p; Wed, 14 Apr 2021 15:01:49 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0029D3A2191; Wed, 14 Apr 2021 15:01:48 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 3D95254804B; Thu, 15 Apr 2021 00:01:41 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 379DF4400B2; Thu, 15 Apr 2021 00:01:41 +0200 (CEST)
Date: Thu, 15 Apr 2021 00:01:41 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, "draft-filsfils-6man-structured-flow-label@ietf.org" <draft-filsfils-6man-structured-flow-label@ietf.org>, "6man@ietf.org" <6man@ietf.org>
Subject: Re: Limited Domains:
Message-ID: <20210414220141.GA34032@faui48f.informatik.uni-erlangen.de>
References: <4077E736-0092-44C6-80D1-E094F468C00C@gmail.com> <12878114-5c26-86f9-89c3-bcfa10141684@gmail.com> <CALx6S35NBfVJmjqVwhNV3nui2avUOXn6ySMG3cxx2AvGkwr_Ow@mail.gmail.com> <08A6C3D2-A81C-413A-81B3-EFAAA9DBCCE5@cisco.com> <5b68beb6-a6f9-828b-5cca-9c5ec2bfbea7@foobar.org> <126B0A5E-B421-4B1F-AAEB-ABD48FFA4289@cisco.com> <CALx6S35yxqAqWJVhav-=+TB2ZyYttAFfsLNs6Btt+QUx__aQ1w@mail.gmail.com> <9b22cfe4-22eb-3977-2d25-79eb61370291@gmail.com> <17DC585D-3378-42BF-8CD0-67676BF0CFD3@gmail.com> <fa412769-893d-8bd8-ebfe-abfb741412a0@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <fa412769-893d-8bd8-ebfe-abfb741412a0@gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/f99_Zdx3zTAas62WsFadLLolg4M>
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: Wed, 14 Apr 2021 22:01:53 -0000

> On 14-Apr-21 22:36, Stewart Bryant wrote:
> > As far as I can see the only safe limited domain protocol is one specifically designed for use in limited domains.

Which IMHO does not exclude the option to design such a protocol for
limited domain in a way that it also supports "non-limited domains".

> On Thu, Apr 15, 2021 at 08:33:58AM +1200, Brian E Carpenter wrote:
> Absolutely. And also, there needs to be a secure and objective definition of the membership and boundary of the domain. That's why we wrote RFC8799.

And especially the permissible/desirable in/out between the limited domain
and other networks, because limited domain >= isolated domain. That
particular issue is what makes semantic overloading problematic as
any enterprise operator can attest to who has gone through an M&A
of multiple 10 net domains, or who had to start multi-homing without
PI addresses just to name two common cases.

Cheers
    Toerless

>    Brian
> 
> > Any other approach leads to confusion, mistakes, security threats, complexity and cost.
> > 
> > Thus declaring that an ???ordinary??? IPv6 packet can simultaneously have both global and limited scope has the potential for creating significant issues for those wishing to use basic IPv6 in a limited domain.
> > 
> > We have an example of an IETF limited domain protocol: MPLS. This has a very simple lightweight data plane security model: it is a different protocol from IP and if it is presented with an IP packet at its edge, it simple wraps it in MPLS and sends it safely on its way across the network for export Into some other network. Operators have a lot of experience with this protocol and we know that the model that MPLS is not IP results in complete confidence that the network will not confuse the two.
> > 
> > Equally we know of cases where IP is vulnerable to attack because it is so difficult to exclude packets. This was at the heart of the reason that source routing, was deprecated some years ago.
> > 
> > Now I am not for a moment suggesting that the limited domain applications that the flow-label authors have in mind should be done in MPLS, but I am suggesting that if they want a limited domain protocol with properties different from IPv6, and there is no obvious way to unambiguously indicate the new functionality in basic IPv6, they ought to design a protocol with the properties that they require that is not IPv6.
> > 
> > I am reminded in this discussion of the a time when another SDO wanted to make a ???small??? incompatible change to MPLS and argued that as this was only deployed in a limited domain that was safe.The IETF position was that incompatible and unrecognisable modification to one of our network protocols was a bad thing. A protracted high profile argument ensued and in the end  the IETF view won the day.
> > 
> > This protracted discussion on flow labels seems to be in a similar mould, and I would argue that we should not accept a change to the forwarding actions on an IPv6 packet unless it is possible for the forwarder to know precisely and unambiguously  which action it is to take on the packet is is currently parsing.
> > 
> > - Stewart
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

-- 
---
tte@cs.fau.de