ietf
[Top] [All Lists]

Re: Internet Architecture Document

2014-10-14 14:52:12
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

On 15/10/2014 08:21, Phillip Hallam-Baker wrote:
On Tue, Oct 14, 2014 at 2:41 PM, Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
On 15/10/2014 06:33, Phillip Hallam-Baker wrote:
We have an Internet Architecture Board. But we don't have an
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

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.


<Prev in Thread] Current Thread [Next in Thread>