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

From: Brian E Carpenter <[email-masked]>
Date: Wed, 12 Sep 2018 15:30:30 +1200

New version, with a first draft of a taxonomy added.

Discussion welcome.

   Brian + Bing

-------- Forwarded Message --------
Subject: I-D Action: draft-carpenter-limited-domains-03.txt
Date: Tue, 11 Sep 2018 20:18:56 -0700
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-03.txt
	Pages           : 19
	Date            : 2018-09-11

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 and emerging solutions, and develops a related
   taxonomy.  It shows the needs for a precise definition of a limited
   domain boundary and for a corresponding protocol to allow nodes to
   discover where such a boundary exists.

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-03
https://datatracker.ietf.org/doc/html/draft-carpenter-limited-domains-03

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

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: Alexandre Petrescu <[email-masked]>
Date: Wed, 12 Sep 2018 16:51:44 +0200

I read the draft.  I find it describes well a state of matters in 
networking along a Limited Domain paradigm.

Maybe some call IP-enabled Limited Domains 'walled gardens'.

> 4.  Examples of Limited Domain Solutions
> 
>    This section lists various examples of specific limited domain
>    solutions that have been proposed or defined.  It intentionally does
>    not include Layer 2 technology solutions, which by definition apply
>    to limited domains.

But there are so many new layer 2 technology solutions that could well 
apply to be Limited Domains.  I was just shown HDMI datagrams over 
Ethernet without IP headers, to cite an example outside the typical 
Bluetooth or USB network.

I think this is a tendency that will continue: more application-specific 
layer 2 technologies will be developped to manage more Limited Domains, 
which will all need to be connected to the Internet in one way or another.

At first, the connection to the Internet will be with a Gateway, and 
only then IP will blend in.  But it's always a two-step operation. 
Never people start make new application-specific Limited Domains 
networks with IP.

Alex

Le 12/09/2018 à 05:30, Brian E Carpenter a écrit :
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 12 Sep 2018 09:10:56 -0700

Hi Brian,

Thanks for the draft!

I am still concerned about the implications and perceptions this draft
might entail. Particularly, I wonder whether this will fracture the
Internet (even more) and encourage (even more) protocol ossification
by allowing developers and protocol designers to take short cuts that
skimp on interoperability and use proprietary solutions instead of
investing in open ones (with the vendor lock-in that goes with that).

Consider this from the draft:

"This section suggests that protocols or protocol extensions should,
when appropriate, be standardised to interoperate only within a
Limited Domain Boundary.  Such protocols are not required to operate
across the Internet as a whole."

I'm not sure what "not required to operate across the Internet as a
whole" means. Specifically, what does it mean for a protocol to not
have to "operate" on the whole Internet. I think there are three
possible meanings here: 1) using the protocol across the whole
Internet isn't useful because it depends on localized information 2)
using the protocol on the Internet isn't feasible because there is a
lack of global support for it in the Internet 3) using the protocol on
the whole Internet isn't correct and leads to bad behaviors. Example
of #1 is segment routing, example of #2 is IPv6 extension headers, and
example of #3 is extension header insertion. Of the three
possibilities, an incorrect protocol is the most problematic. As a
litmus test, consider that a Limited Domain implies a security
perimeter exists around the domain that would contain the Limited
Domain protocol. We know that such perimeters can and will break down
at some point so that some day a limited domain protocol will leak
into the Internet. That cannot lead to incorrect behavior, this cannot
break the Internet! I submit that if a protocol cannot operate
*correctly* in the Internet, or would break correct operation of other
protocols on the Internet, then it is _not_ an Internet protocol.

The part about "interoperate only within a Limited Domain Boundary" is
also interesting. I worry vendors make take a lot of license with
this. For instance, I have heard one suggestion that mobile operators
might "give" each hardware vendor there own slice. So a Limited Domain
is defined to contain only one vendor's equipment. Interoperability
within a single implementation is rarely an issue! While I don't think
it's our business to prevent things like this (network operators can
do what they want within their domain), neither do I think we should
be encouraging or facilitating it. IETF is fundamentally about
standardizing open, interoperable Internet protocols. I guess the
consequences of this is that if someone defines a protocol that only
operates in a limited domain, then the limited domain itself needs to
be clearly defined in normative language.

Tom

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 12 Sep 2018 12:16:51 -0400

Alex and Brian,

Any time you have a limited domain layer 2 network (such as a campus
Ethernet, or more application-specific networks like Alex was mentioning),
one thing that commonly occurs is that people want to use tunnels to
interconnect such networks either over the Internet, or alternatively over
an enterprise's managed L3 network from a WAN service provider if they want
to be able to maintain SLA parameters. In that  case, tunneling
technologies such as pseudowires, L2TPv3, or GRE are commonly used. I think
that this is a different case than the gateways mentioned by Alex, since in
some cases there may be no IP involved except as an outer tunnel wrapper,
or MPLS may be the outer wrapper, in which case there's no IP at all.

Brian, you started to touch on this in your draft with mentions of
interconnections between limited domains, but you might want to add more
detail for the reader.

Cheers,
Andy

On Wed, Sep 12, 2018 at 10:51 AM, Alexandre Petrescu <
[email-masked]> wrote:

> apply to be Limited Domains.  I was just shown HDMI datagrams over Ethernet
> without IP headers, to cite an example outside the typical Bluetooth or USB
> network.
>
> At first, the connection to the Internet will be with a Gateway, and only
> then IP will blend in.  But it's always a two-step operation. Never people
> start make new application-specific Limited Domains networks with IP.
>
> Alex
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Sep 2018 08:40:55 +1200

Andy, and Alex,

Yes. I think we need to say more about this aspect. It's clear that
a technology boundary is a kind of "natural" domain boundary,
but on the other hand we've been overcoming such boundaries for
many years (anybody remember Ethernets bridged together over FDDI?).
And of course VLANs create limited domains at layer 2. However,
implicitly we're talking about limited domains at layer 3. Maybe we
need to be explicit about that (but see Tom Herbert's message, which
I'll reply to next).

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Sep 2018 08:53:12 +1200

Tom,

> investing in open ones (with the vendor lock-in that goes with that).

Of course that's a concern. My personal opinion is since it's going to
happen anyway (in fact, has been happening for many years in reality),
we are better off to bite the bullet and face reality. If the IoT is
anything real, it means we're going to make the Internet 100 times bigger
and that seems inconceivable without limited domains at the edges.

> have to "operate" on the whole Internet.

Yes, this area needs more work. Our idea was to do that next, after
getting the taxonomy into shape. Your comments below are very insightful
and help a lot. Just one specific comment below at this point.

> I think there are three

I'd go a bit further - I think we need to standardize the mechanisms
for identifying and defining the boundary, so that what happens inside
can be effectively contained. That helps everybody.

Thanks
    Brian

> .

---

From: Tom Herbert <[email-masked]>
Date: Wed, 12 Sep 2018 16:14:01 -0700

> and that seems inconceivable without limited domains at the edges.
Yes, but it's not yet clear that a formal concept of Limited Domains
is required to scale the Internet, or at least is required as an
entity that defines or drives requirements in protocols.

Consider the world of mobile. Every mobile provider runs their network
as a Limited Domain already in order to manage the mobile devices in
their network. But everyone runs their domain differently. For
example, some have firewalls, some have proxies, some provide no
security. At the end of the day, a device can't assume that all
networks provide anything but connectivity. Knowing that a device is
connected to some standard "Limited Domain" that might imply a set of
available services isn't much consolation. Instead of talking about
network devices be non-conformant to the protocols, we'll be talking
about whether networks conform to the definition of a limited domain.

Note also, that some other SDOs already define standards for limited
domains. 3GPP in particular, specifies both the network architecture
and protocols for a mobile network (e.g. 5G specification). While it
one sense it's good to have a common model and architecture for mobile
networks, I believe that is at the expense of having a very complex
protocol that is extremely hard to change.

IMO, IETF's strength and advantage is that it focuses on standardizing
protocols without standardizing network architecture. This provides
all the necessary freedom for to build networks as appropriate and
encourage innovation on many fronts. For the most part this model
seems to haved worked well. The same TCP/IP protocol suite that works
over the Internet also works in the largest data center down to the
smallest home network. Sure, to make things work, use of protocols and
configurations need to be adapted for different use, but we haven't
yet had to radically change the protocol because it needs to run in a
new environment (I suppose one might consider NAT as a radical change,
but that is supposed to be obsoleted by IPv6 anyway :-) ).

Tom

---

From: Amelia Andersdotter <[email-masked]>
Date: Thu, 13 Sep 2018 02:39:12 +0200

Dear all,

Thanks Brian for going through all this work, and Tom and Alexandre for
providing interesting feedback.

In section 3, it may be more interesting to divide Examples of Limited
Domain Requirements into networks containing human end-users and
networks that don't contain human end-users (such as industrial systems,
sensor networks, IoT, etc, merging the home network and small office
network use-cases). It would make the taxonomy a more useful tool for
assessing the limited domain requirements, and is better adjusted to how
demands for (or requirements/expectations on) these limited domains
arise in the real world. That could serve as a basis for elaboration of
section 7.

More broadly, I share Tom's concerns that this justifies using the IETF
as a platform for standardising intRAnets, rather than an intERnet. But

> can be effectively contained. That helps everybody.

This makes sense, and could perhaps even help constructively with some
issues (such as privacy/security issues discussed in SUIT) that arise
when specific limitations on node privacy or security as described
RFC6973 or RFC8280 aren't relevant, because no human is technically
impacted.

best regards,

Amelia

-- 
Amelia Andersdotter
Technical Consultant, Digital Programme

ARTICLE19
www.article19.org

PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55

---

From: Tom Herbert <[email-masked]>
Date: Wed, 12 Sep 2018 18:50:20 -0700

> arise in the real world. That could serve as a basis for elaboration of
Hi Amelia,

I'm curious why you think discriminating networks containing end-users
and those that don't would be helpful here. Until the rise of the
machines happens, isn't it true that all communication networks exist
to serve humans in some fashion? For instance, if someone deploys
radiation sensors in a nuclear power planet and connects them as IoT
to their network, doesn't that make the workers in the power plant
effectively end-users of those devices? Or to put a darker spin on it,
if such devices are breached then couldn't bring harm to people just
as easily as if a normal "end-user device" is compromised?

Tom

---

From: Amelia Andersdotter <[email-masked]>
Date: Thu, 13 Sep 2018 04:18:11 +0200

> as easily as if a normal "end-user device" is compromised?

I had hoped the following comment would clarify:

"[Standardize mechanisms for identifying and defining boundaries] makes sense, and could perhaps even help constructively with some issues (such as privacy/security issues discussed in SUIT) that arise when specific limitations on node privacy or security as described RFC6973 or RFC8280 aren't relevant[.]"

If these limited domains are already practically (albeit implicitly) assumed -- and I think the draft makes a good case that they are -- then the idea of having a mechanism for classifying them seems to me helpful in assessing uses and effects of features in those domain-limited protocols. 

best regards,

Amelia

ARTICLE19
www.article19.org

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Sep 2018 14:42:37 +1200

Just picking on one part of Tom's excellent note:

On 2018-09-13 11:14, Tom Herbert wrote:
...
> seems to haved worked well.

Well, I think we have counter-examples. PMTUD failure for one. Opaqueness
of the Internet to new IPv6 extension headers for another. The strong
desire from some operators to deploy locally-significant extensions
in a standardized way for another. And we've developed solutions
already, dating back at least to SOCKS. So haven't we been implicitly
pretending that this elephant wasn't in the room?

    Brian

---

From: Tom Herbert <[email-masked]>
Date: Wed, 12 Sep 2018 20:18:45 -0700

On Wed, Sep 12, 2018 at 7:42 PM, Brian E Carpenter
<[email-masked]> wrote:
> in a standardized way for another.

Okay, some operators want such things. However, the specifics of what
they're requesting are pertinent as to whether these should be
undertaken in IETF. In particular, each request should be evaluated
against the "necessary and sufficient" test. It might be good to
discuss in some detail a few specific locally-significant extensions
in the draft, particularly those that fall into the category of "not
correct" when used on the Internet.

I will give one example. The draft mentions extension header insertion
(I-D.voyer-6man-extension-header-insertion). Some operators want it as
unabashedly indicated by the first line of the abstract in that draft:
"The network operator and vendor community has clearly indicated that
IPv6 header insertion is useful and required.". There was quite a bit
of discussion of this draft on 6man list. I believe the (current)
consensus is that it's neither necessary nor sufficient protocol. It's
not necessary because IP/IP encapsulation can be used to achieve the
same effect. It's not sufficient because it makes several requirements
on the network that are outside the specification of the protocol.

Tom

> And we've developed solutions