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

From: Brian E Carpenter <[email-masked]>
Date: Sat, 2 Mar 2019 14:08:23 +1300

A few small updates and fixes to references. Please comment;
the authors are wondering about next steps for this draft.

    Brian + Bing

-------- Forwarded Message --------
Subject: I-D Action: draft-carpenter-limited-domains-06.txt
Date: Fri, 01 Mar 2019 17:04:37 -0800
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Limited Domains and Internet Protocols
        Authors         : Brian Carpenter
                          Bing Liu
	Filename        : draft-carpenter-limited-domains-06.txt
	Pages           : 24
	Date            : 2019-03-01

Abstract:
   There is a noticeable trend towards network requirements, behaviours
   and semantics that are specific to a limited region of the Internet
   and a particular set of requirements.  Policies, default parameters,
   the options supported, the style of network management and security
   requirements may vary.  This document reviews examples of such
   limited domains, also known as controlled environments, and emerging
   solutions, and develops a related taxonomy.  It then briefly
   discusses the standardization of protocols for limited domains.
   Finally, it shows the needs for a precise definition of limited
   domain membership and for mechanisms to allow nodes to join a domain
   securely and to find other members, including boundary nodes.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-carpenter-limited-domains/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-carpenter-limited-domains-06
https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-carpenter-limited-domains-06

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Tom Herbert <[email-masked]>
Date: Fri, 1 Mar 2019 17:46:10 -0800

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.

Thanks,
Tom

On Fri, Mar 1, 2019 at 5:08 PM Brian E Carpenter
<[email-masked]> wrote:
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 2 Mar 2019 16:18:29 +1300

> 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.

    Brian

---

From: Tom Herbert <[email-masked]>
Date: Sat, 2 Mar 2019 09:35:31 -0800

> 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.

Tom

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 3 Mar 2019 08:50:53 +1300

> 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.

    Brian

    Brian

---

From: Tom Herbert <[email-masked]>
Date: Sat, 2 Mar 2019 12:35:44 -0800

> 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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 4 Mar 2019 08:56:34 +1300

> 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.)
 
> 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