Re: [Int-area] Fwd: I-D Action: draft-carpenter-limited-domains-06.txt

Brian E Carpenter <brian.e.carpenter@gmail.com> Sun, 03 March 2019 19:56 UTC

Return-Path: <brian.e.carpenter@gmail.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 024AE130DEF for <int-area@ietfa.amsl.com>; Sun, 3 Mar 2019 11:56:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GB7yFX3ZFv3p for <int-area@ietfa.amsl.com>; Sun, 3 Mar 2019 11:56:40 -0800 (PST)
Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 E47DC130DE9 for <int-area@ietf.org>; Sun, 3 Mar 2019 11:56:39 -0800 (PST)
Received: by mail-pg1-x535.google.com with SMTP id j3so1462830pgm.11 for <int-area@ietf.org>; Sun, 03 Mar 2019 11:56:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1SQCb4fz4C4krW1qYSpX0LqhO873UES3j5G8LaAqClM=; b=tymwCA7hEgQNNhUJzTc6iwvk/87UeK9/dDf+ucN9TEsVuUd5x22tfv/2UX067pAG8f Bqc0hPLG2PCutOYJZgJm2nd1Smg2A8ZD9pY4xK9U1it/qt0XdsqZMNoxh383Xk8haXOW tewVIy5lg3XaiZAhGR6btQuEE6lZqJvk8ZX3rRVU2NTMNjUXmGJTdvWK9cqgIpjYF4yX a6L18XeRN4+gIRpe05GMM7qE058xhT2VwMtEmfwDatGrfuwqqDQVxhh/VZsqNaU1jLDl 8w1WRtME7ba0G6bl6typhs1B95s/y2FF9ixcFtY/RalABIFFUsQTEUWgA4d4eudtnRfS ZX5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1SQCb4fz4C4krW1qYSpX0LqhO873UES3j5G8LaAqClM=; b=l66uyxaBXGvXl1bZ7pcvPn30JH+PFY8qhSM2yt9X2x+rhFjUY4882Oi3UJKRQAYk+4 dxiZkmihSoavTb/GUX22hjmh8xUVR8rm/U+Me792I7SOnxch/etkk5Mpu932oco8f5e4 3U6Laf0jcgio9y0tncPv6hQE04lwjg9ikjJcwzTwBhzIcFcl4DBYexzSKnFcQnFK9JXm 0xj3au+vcSHlYtQZeFPRFvegwFe5+Q2PgBPCtdK/fM87DbK5xlEtF7RQ3R8ry5oLp6/k vLH5P+kBRVIa3vL1c6BFoRoqMmRFuKEMcDPC/F3Q4bnVWQWuvs2ETfHy3bKzU0ihhfpj bnKg==
X-Gm-Message-State: APjAAAUDKhTU9mfYqO5JFERihjX9fJtNF9fkxVmSakwBOKAh2fijI1Lc /S7aeIwyIBlVbkt3xisJreqp7q3o
X-Google-Smtp-Source: APXvYqwpC5XJ/kt4+azl8hDXzGE3YdmNrWcrh333wbRg/OyiPZC2YGipN9xhthDk59ryMf9gOZ0fYA==
X-Received: by 2002:a17:902:241:: with SMTP id 59mr16396074plc.72.1551642998746; Sun, 03 Mar 2019 11:56:38 -0800 (PST)
Received: from [192.168.178.30] ([118.148.79.176]) by smtp.gmail.com with ESMTPSA id d6sm6400344pfg.47.2019.03.03.11.56.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Mar 2019 11:56:38 -0800 (PST)
To: Tom Herbert <tom@herbertland.com>
Cc: int-area <int-area@ietf.org>
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> <CALx6S364Hn8Xf=QuDq3uyJ==bAunt1bkV6K4TOwL_sdvoTz1Ng@mail.gmail.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <458413f3-7d1e-98e9-1b38-5a1ed32b78c4@gmail.com>
Date: Mon, 04 Mar 2019 08:56:34 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <CALx6S364Hn8Xf=QuDq3uyJ==bAunt1bkV6K4TOwL_sdvoTz1Ng@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/b0sgX-GmeRss3ws4YyU8bB_UkM8>
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: Sun, 03 Mar 2019 19:56:42 -0000

On 03-Mar-19 09:35, Tom Herbert wrote:
> 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.

I think we already distinguish between a protocol that runs over the
open Internet and a local protocol that runs over IP, with a limited
scope for interoperability. And we distinguish between a standardised
protocol and a private (possibly undocumented) protocol. What we're
arguing is that "standardised and interoperable" can be a very useful
property of a local protocol, and such a protocol can be very useful
even though it's *not* designed to run across the open Internet.

We'll try to make this argument clearer in the next version. (I'm
also wondering whether the taxonomy section isn't a distraction
that would be better as an Appendix.)
 
> 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).

I think it's some of both. As the IPv6 saga has shown, getting new
stuff to become universally deployed is very, very difficult. In fact,
that was already true 25 years ago. But the argument we're making is 
also that for some scenarios and applications, explicit design for
local use is a good thing. That's not about ossification.

Analogy: taxis, Ubers and Lyfts are great for travel around town,
but they are a really bad solution for crossing the ocean, so it's
OK that they aren't interoperable with airplanes. You could tunnel them
between airports in a cargo plane but that would be bad engineering.

    Brian