Subject: Internet Architecture Document

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Oct 2014 13:33:13 -0400

We have an Internet Architecture Board. But we don't have an
architecture document. By which I mean a document that is kept up to
date with the Internet architecture as realized.

The end-to-end paper is not an architecture document. It predates DNS
for a start. And one of the problems of making sense of where
middleboxes and PKI and Software Defined Networking 'fit in' is that
there is no reference model to provide a delta to.

Two of the reasons there is no IETF model are the OSI model. This is
just good enough to be a substitute for an IETF model while
simultaneously demonstrating the futility of modelling.

There is however a very simple modification to the OSI model that
suddenly makes sense. The OSI model defines the layers in the
architecture. What matters in a standards context is not what happens
inside the layer, it is how that layer interfaces to other layers.

So rather than looking at the 'Applications Layer', instead look at
the Applications interface to the Transport layer beneath. And instead
of the Transport layer, consider the interface between Transport and
Network.

Modelling the Internet in this fashion allows us to broaden the
definition of the Internet. At the Network layer the Internet is the
set of devices that speak IP protocol. But at the Application layer,
the Internet is the set of devices that use the Internet class of the
DNS to resolve names.

Each interface is characterized by the identifier used to mediate the
transition to the layer beneath. So there really should be a layer
between Applications and Transport because Applications use the DNS
name identifier and Transport runs on IP addresses and port numbers.
We might as well call the layer Presentation.

Right now that Presentation layer is encoded into BSD sockets which in
turn are hardcoded to the hosts.txt era Internet architecture.

A VPN is a filter on the Network interface. It sits above the Network
layer and below the Transport Layer. Software Defined Networking is a
filter on the Data Link Layer.

TLS is a bit more than a filter because it involves DNS and PKI
operations that are bundled into the sockets layer. It is really a
presentation layer.

Looking at the Internet as it has evolved, it fits the 'interfaces'
model really well. Building a formal model using the interfaces
approach would be fairly straightforward.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Oct 2014 07:41:30 +1300

On 15/10/2014 06:33, Phillip Hallam-Baker wrote:
> architecture document. 

I believe the reason for that is stated fairly clearly in
http://tools.ietf.org/html/rfc1958#section-1 and
http://tools.ietf.org/html/rfc1958#section-2

   Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 14 Oct 2014 15:21:05 -0400

> http://tools.ietf.org/html/rfc1958#section-2

Well first that document was written in 1996. A lot has changed since.
And lets read what you wrote:

"2.1 Many members of the Internet community would argue that there is
   no architecture, but only a tradition, which was not written down for
   the first 25 years (or at least not by the IAB).  However, in very
   general terms, the community believes that the goal is connectivity,
   the tool is the Internet Protocol, and the intelligence is end to end
   rather than hidden in the network."

Do we really believe that is true? If so there would have been no
complaints about NAT boxen and the like 'spoiling' the Internet
architecture. We would be completely happy with the free for all that
has happened since.

I don't think that is the case that nobody has complained. And right
now we are having a long discussion in DPRIVE over whether DNSCurve is
the answer or not and the major complaint being made against DNSCurve
is that it just doesn't fit the Internet architecture.

Oh and one of the reasons DNSCurve does not fit the architecture is
precisely because it attempts to remove recursive resolvers from the
DNS architecture making it an end-to-end protocol!

What you are doing there is essentially choosing one of the interfaces
that I described and asserting that is the Internet Architecture.
Which might work fine if you only work at the Network layer. It does
not work at all well for those of us who work above that layer. And
especially not for folk working in the constrained device world where
you want to work out how a device that is not capable of supporting IP
fits into the Internet architecture model.

There are two types of problems caused by middleboxen. The first is
the 'problems' resulting from their intended purpose. A firewall will
stop inbound connections to random hosts inside the corporate network.
That may violate some people's ideology but it is what the box was
intended to do and people should get over the fact people want that.

The second set of problems are second order effects caused by the
implementation and these are much harder to deal with because they are
essentially random. The middleboxes that decide to truncate all
messages on port 53 to 500 bytes in length for example.

So right now there are two types of middleboxes, those that perform
their intended function without causing second order issues (type 1)
and those that cause second order problems (Type 2). I can describe
the difference subjectively but I can't give an objective definition
of what a well-formed middlebox is because I don't have objective
definitions of what the interfaces should look like. And without that
I can't eliminate Type-2 middleboxes.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Oct 2014 08:51:39 +1300

Phill,

Excuse top posting as I'm about to head to the airport.

Yes, and I was one of the first to rant about middleboxes
(RFC 2775 and 3234). But ranting is very different from being
able to describe a systems architecture, and I think RFC 1958
was correct to argue that constant change is the only certainty.
I suspect that's why no IAB since 1996 has really tackled
this question.

Regards
   Brian

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 15 Oct 2014 07:55:10 +0900

> Well first that document was written in 1996. A lot has changed since.

Wrong. W.r.t. the end to end architecture, nothing has changed.

> the answer or not

It is not.

> DNS architecture making it an end-to-end protocol!

That you insist that something is end to end means that you
think nothing has changed.

Moreover, DNS can not be end to end, because domain structure
is not consistent with network topology.

According to the end to end argument:

	The function in question can completely and correctly be
	implemented only with the knowledge and help of the
	application standing at the end points of the
	communication system.

that communicating end systems must depend on intermediate
name servers governing domains of the end systems and that
the end systems can not "help" the name servers by providing
their "knowledge" means that DNS is not end to end, which has
nothing to do with security mechanisms nor recursive resolvers.

					Masataka Ohta

---

From: Joe Touch <[email-masked]>
Date: Fri, 24 Oct 2014 14:41:10 -0700

> We have an Internet Architecture Board. But we don't have an

That is a question better asked of the IAB.

...
> inside the layer, it is how that layer interfaces to other layers.

http://www.isi.edu/rna

> of the Transport layer, consider the interface between Transport and

If you admit that layer interfaces are what matter, then you also need
to accept that layer names are no longer meaningful. The distinctions
that defined the layers according to OSI need not be relevant.

> the Internet is the set of devices that use the Internet class of the

According to RNA, each layer interface requires a way to map names
within one layer to names in another. This is why ARP, BGP, DNS, and
even Google are related.

> We might as well call the layer Presentation.

App layer identifiers are (IMO) service names and DNS strings.

Transport layer identifiers are port numbers and IP addresses; Internet
transport does not exist independent of the Network layer because of the
integration of the IP pseudoheader in TCP endpoint identifiers (again,
if we're using OSI layer names).

> turn are hardcoded to the hosts.txt era Internet architecture.

Not since mDNS/Bonjour.

> A VPN is a filter on the Network interface.

A VPN is a partial overlay.

> It sits above the Network
> layer and below the Transport Layer.

It sits where it sits. Some sit on L2 (L2TP). Some sit on L3 (IPsec).
Some sit at the app layer (SSH).

> Software Defined Networking is a

SDN is the current flavor of an application layer network management
protocol; IMO, nothing more, nothing less, and certainly nothing
interesting.

> operations that are bundled into the sockets layer. It is really a

Like TCP, TLS bundles names from a number of layers together.

> approach would be fairly straightforward.

http://www.isi.edu/rna

FWIW, I'm developing this as a revision of USC's primary computer
networks course for this spring. If anyone is interested in getting some
early info and providing feedback, please contact me directly off-list.

Joe