Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-06.txt
Tom Herbert <tom@herbertland.com> Sat, 02 March 2019 20:35 UTC
Return-Path: <tom@herbertland.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF19130E74 for <int-area@ietfa.amsl.com>; Sat, 2 Mar 2019 12:35:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 MCpgr4vqR3Og for <int-area@ietfa.amsl.com>; Sat, 2 Mar 2019 12:35:56 -0800 (PST)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C9BF130E7F for <int-area@ietf.org>; Sat, 2 Mar 2019 12:35:56 -0800 (PST)
Received: by mail-qt1-x830.google.com with SMTP id u7so1254188qtg.9 for <int-area@ietf.org>; Sat, 02 Mar 2019 12:35:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Da5zVW4GP/Nd1vfCLeIEjiPJ6YA/YTGNLSL5ZzxNVfk=; b=DJln3iuCIKQiRk6ykF5EyAbydGloPhv7yHxQndwI27RudI4MyabfFK9iT9YvotvAcE MYIDSDT1IMfb+0eAipH/1hMvKBMkfl3YeyR8grVolwrWXz+jgF1c6jElXDrc5dYPxTXr zUS6j53orambXvGGQrBuQymfdSo0qBKM3VemWG42lGecGRoZ7Edw+IvY+3F/bQEwvcG7 NZ/oMWHQjmQ5PMjAFiqSwD+bX+BDs+euySTb1ziY/50Q462NDhz3SyvpHqSj+oXTfJg+ h38o0mRBceolRYNOCd1ofiKqYp4U7xzmWYvU3hXPgQNGXRErRJfE1t73K2o8dTX12VKA G7sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Da5zVW4GP/Nd1vfCLeIEjiPJ6YA/YTGNLSL5ZzxNVfk=; b=JJVrs58S2xSEjNZgN7KN6WoPY0O2PduPy/hlXOhKNlSCJ93a5njaOit4gnvVa6TgUC 3CIrKJhJh1qtfUm6RV/Ll1f8oIcdHH9GPL4e4D/KnOQQa5In/Kqjh15UMeLU5tKJs03D M7VQMtAe5HDBgBKiUSelYUTwM86EGBbH4p/nEJ2wKvKfAgSrAydYrutvLMe4Wy0WhDDW 44R6IPn2aHHWbDul6RXMWiodcOnERvOwxfG1Sgshwz9bzXa+iWJy5+c7byfFfURbr7vs q4yYL2QlijhRkbuyrPA14UmHJL5ik2dgS9uJ7i6h/tZCq+X8Sdm7NkM+gUJkadPcF6Z7 iHHw==
X-Gm-Message-State: APjAAAXMTE+I4Qhs5b49S5BlHetn/YbzgnbXcpuFsSh6D/58XKVFS0Iy OsXlSn9umh7CVEUaBip69OcHH92ENdkddHdib2Bv2YFRYBc=
X-Google-Smtp-Source: APXvYqwRwPwitRgsCLoliC2G85/XBqE9qEndv5dA3dK225kkL7gbZrQBryM+ZCH5SCECyEi74enMvvtXdfjpTxqd+Mc=
X-Received: by 2002:a0c:9681:: with SMTP id a1mr9109412qvd.72.1551558954805; Sat, 02 Mar 2019 12:35:54 -0800 (PST)
MIME-Version: 1.0
References: <155148867733.6203.17876831273429823351@ietfa.amsl.com> <45a7996f-3d80-cf32-43ca-c02244ea2d39@gmail.com> <CALx6S34zqSV2gxkOHU=hcNrDy=ptAba3iMx4_JKAMoHZQMKsxg@mail.gmail.com> <31f83f21-f884-1f4a-f92f-5b40927bac4b@gmail.com> <CALx6S377x12FLVX75Ud0gya8apirs+3KZvenXA9e==JG1L+zNw@mail.gmail.com> <3b7778c4-e9c3-0fa2-b8ff-17cd0984e4e6@gmail.com>
In-Reply-To: <3b7778c4-e9c3-0fa2-b8ff-17cd0984e4e6@gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Sat, 02 Mar 2019 12:35:44 -0800
Message-ID: <CALx6S364Hn8Xf=QuDq3uyJ==bAunt1bkV6K4TOwL_sdvoTz1Ng@mail.gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: int-area <int-area@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/5jm8HwBAec2_sdPI5bWpahceBt8>
Subject: Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-06.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Mar 2019 20:35:59 -0000
On Sat, Mar 2, 2019 at 11:50 AM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote: > > On 03-Mar-19 06:35, Tom Herbert wrote: > > On Fri, Mar 1, 2019 at 7:18 PM Brian E Carpenter > > <brian.e.carpenter@gmail.com> wrote: > >> > >> On 02-Mar-19 14:46, Tom Herbert wrote: > >>> Hi Brain, > >>> > >>> One comment... > >>> > >>> >From the draft: > >>> > >>> "5. Firewall and Service Tickets (FAST). Such tickets would > >>> accompany a packet to claim the right to traverse a network or request > >>> a specific network service [I-D.herbert-fast]. They would only be > >>> valid within a particular domain." > >>> > >>> While it's true that Firewall and Service and Tickets (in HBH > >>> extension headers) are only valid in a particular domain, that really > >>> means that they are only interpretable in the origin domain that > >>> created the ticket. It's essential in the design that FAST tickets can > >>> be exposed outside of their origin domain (e.g. used over the > >>> Internet) and reflected back into the origin domain by peer hosts. > >>> FAST tickets contain their own security (they are encrypted and signed > >>> by agent in the origin network) so there should never be any reason > >>> for a firewall to arbitrarily filter or limit packets with FAST > >>> tickets attached. This technique could probably be applied to some of > >>> the other use cases mentioned. > >> > >> Yes, that's an interesting model: effectively a domain split into various > >> parts without needing a traditional VPN. > >> > >> Of course, there remains the bogeyman of making the Internet transparent > >> to some new unknown option or extension header. I'm pessimistic about that. > >> So far we have had poor success. > > > > Maybe, although I wouldn't phrase it exactly that way. Protocol > > ossification of the Internet and the abandonment of the End-to-End > > model has made evolution of the Internet harder, but I don't believe > > it is yet proven impossible. This goes back to my primary concern that > > if the concept of limited domains is standardized, some people will > > use it as rationalization to justify non-conformant implementation and > > proprietary, non-interoperable solutions as somehow being compatible > > with Internet architecture and ideals. > > I certainly acknowledge that risk; but (having lived with this problem > in some form or other since RFC2101) I really think we can't duck it any > longer. > > Also, we really have standardized limited domains already, in numerous > places - segment routing and detnet being recent examples. I think > ultimately what we're arguing in the draft is: let's do it properly. Hi Brian, Yes, limited domains in the form of administrative domains and security domains have existed for quite some time (since NAT, RFC1918, firewalls first came into being). Every service provider and datacenter operator have implemented a domain. But those distinguished domains by the operation and use of the protocol, not in the definition of a protocol or its interoperability which seems to be proposed in the draft.. The draft states: "This documents analyses and discusses some of the consequences of this trend, and how it impacts the idea of universal interoperability in the Internet" I don't see much discussion in the draft on the impact of interoperability. This is critical. Interoperability is a core principle in the Internet. If, for instance, a protocol is specified to only work and be interoperable in a limited domain then would it still be called an Internet protocol? (to me, it seems like an oxymoron to call something an Internet protocol that doesn't even work on the Internet). It would good for the draft to elaborate on this. Also, I think there should be some mention here about ossification of the Internet. Will standardizing limited domains mitigate the ossification problem or perpetuate it (AFAICT, right now it seems more likely to be the latter). Tom > > Brian > > Brian > >
- [Int-area] Fwd: I-D Action: draft-carpenter-limit… Brian E Carpenter
- Re: [Int-area] Fwd: I-D Action: draft-carpenter-l… Tom Herbert
- Re: [Int-area] Fwd: I-D Action: draft-carpenter-l… Brian E Carpenter
- Re: [Int-area] Fwd: I-D Action: draft-carpenter-l… Tom Herbert
- Re: [Int-area] Fwd: I-D Action: draft-carpenter-l… Brian E Carpenter
- Re: [Int-area] Fwd: I-D Action: draft-carpenter-l… Tom Herbert
- Re: [Int-area] Fwd: I-D Action: draft-carpenter-l… Brian E Carpenter