Re: There are no NAT boxes on the Internet and never have been.

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 28 January 2015 15:02 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6649F1A00ED for <ietf@ietfa.amsl.com>; Wed, 28 Jan 2015 07:02:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.977
X-Spam-Level:
X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
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 1M8syCDE-oPY for <ietf@ietfa.amsl.com>; Wed, 28 Jan 2015 07:02:40 -0800 (PST)
Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 677331A00C5 for <ietf@ietf.org>; Wed, 28 Jan 2015 07:02:39 -0800 (PST)
Received: by mail-la0-f53.google.com with SMTP id gq15so19493193lab.12 for <ietf@ietf.org>; Wed, 28 Jan 2015 07:02:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=WkZ0o9JZ1tY3nM819B27hp2X90SKfY24bbhB8POeF7E=; b=Ov0Syzrd5Dw/aIeYRLK4w5e9WAwMCNH7O+O7B+hFqknwCgP+V/dWqd8ENfv9cTxVhY mYwuDcJDG6765wdk+wJiP78USGt5ly28GWzqxoW/xNYft9efcAIeGT0S26IVfFm8bYcY 9rQv622HXOs1qt+Tjcgrx8oD/kVx6eIeulS9Dfn7LIFWg9dQbbSxwtgfzpCBq94h/qK0 5S/7ZuM3IEFi75QelIcgW9/g2OMEqQP6sTKu6tUNwv00sxc/fhfEQWB6QtsguuFsw2rP Yw/41Bqv4nHpxQ63dQ4ZkvsfKV9mLVIW69YhhMFtZhRIYDTnN5POjp5ID1+UwiTu1V0M oq4w==
MIME-Version: 1.0
X-Received: by 10.152.7.180 with SMTP id k20mr8707176laa.4.1422457357833; Wed, 28 Jan 2015 07:02:37 -0800 (PST)
Sender: hallam@gmail.com
Received: by 10.112.147.193 with HTTP; Wed, 28 Jan 2015 07:02:37 -0800 (PST)
In-Reply-To: <20150127202437.GA6264@besserwisser.org>
References: <CAMm+LwgUAZtLShdX+S7ZtfhFZrF5QxBCkwVvBZtL=UCN-Xt1WQ@mail.gmail.com> <20150127202437.GA6264@besserwisser.org>
Date: Wed, 28 Jan 2015 10:02:37 -0500
X-Google-Sender-Auth: r1R5tA3fRCATYnD55264-PZqEVs
Message-ID: <CAMm+LwhBc64U3==HwJH526wBpP_iPk=63SZCtu5omN3vkkC_Lw@mail.gmail.com>
Subject: Re: There are no NAT boxes on the Internet and never have been.
From: Phillip Hallam-Baker <phill@hallambaker.com>
To: Måns Nilsson <mansaxel@besserwisser.org>
Content-Type: multipart/alternative; boundary="001a11c217d2859be7050db7a93c"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/xYV8hKQakBWApu6KyCjxyV9USaA>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Jan 2015 15:02:44 -0000

On Tue, Jan 27, 2015 at 3:24 PM, Måns Nilsson <mansaxel@besserwisser.org>
wrote:

> Subject: There are no NAT boxes on the Internet and never have been. Date:
> Tue, Jan 27, 2015 at 12:40:19PM -0500 Quoting Phillip Hallam-Baker (
> phill@hallambaker.com):
> > Since my paper was rejected, I did not attend the middlebox workshop.
>
> <snip>
>
> > It does not hold for an inter-network because the definition of an
> > Internetwork is that there is no central control point. Which in turn
> means
> > that we can't implement certain security functions in the Internet
> (though
> > there are some functions such as traffic analysis defense that can only
> be
> > implemented there).
>
> Your definition of The Inter-Network does not look to me as "no central
> control point" but more in the direction of "The network where there
> are no middleboxes" which is IMNSHO less satisfactory. Not to mention
> an exercise in circulus in probando in the light of the present
> discussion.
>

The Inter-network is the network of networks. Einar Stefferud used to give
a very good talk explaining the difference between an Inter-network and a
network.

Running IP end to end does not necessarily mean running Internet end to
end. The point is that the INTERNET Engineering Task Force is recognized as
the authoritative body for setting standards for the inter-network but the
decision maker at the network level is the owner of each network.

A random IETF participant with an opinion and a keyboard does not get to
tell me how to run my damn network. He is not even entitled to an opinion
on the matter.

I am certainly not arguing for reducing the scope of the IETF to the areas
where it is authoritative. But I think people from the routing layer need
to understand that what we do at the applications layer are better
understood as suggestions rather than making laws and our approach as being
persuasion rather than command.


I do, however, agree that for the IP-network overseer there exists a
> right to manage traffic by regulating it but  that right should be as
> delegated as possible and flexible if at all possible.
>

Why is delegation a good thing? Why is flexibility a good thing?

What I want as a network user is for my applications to work with as little
hassle as possible. And for that I find consistency and a single control
point much easier than having to work out which of the multiple veto points
is stopping something from happening.

Yesterday I had to remove and reinstall Apache on the linux box because it
would not start thinking it didn't have the right permissions. The
permissions in question being split between O/S permissions and application
level permissions and the software gives no information saying which is
blocking.

Windows is even worse for this. Trying to get apps to run under IIS
requires three separate sets of permissions to be set and they don't even
tell you about one of them. It is a hidden O/S feature that you have to
discover by poking about on programming forums.


The problem with middleboxes is that they distribute control across a
network and make the transport of packets non-deterministic. Middleboxes
will make arbitrary and often bran dead modifications to packets in an
attempt to achieve control.

There are two aspects of an access control infrastructure, the policy
decision point and the policy enforcement point. In the current middlebox
model every middlebox does both and that makes network management hard. In
a default-deny network, no packet transits without express authority. So
middleboxen need to perform policy enforcement. But the only way to make
such a configuration practical is to coordinate policy distribution.