Re: [v6ops] network topology hiding

Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org> Wed, 15 December 2010 21:13 UTC

Return-Path: <ipng@69706e6720323030352d30312d31340a.nosense.org>
X-Original-To: v6ops@core3.amsl.com
Delivered-To: v6ops@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2B228C0DC for <v6ops@core3.amsl.com>; Wed, 15 Dec 2010 13:13:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxBW34jYy16H for <v6ops@core3.amsl.com>; Wed, 15 Dec 2010 13:13:57 -0800 (PST)
Received: from smtp1.adam.net.au (smtp1.adam.net.au [202.136.110.253]) by core3.amsl.com (Postfix) with ESMTP id 70F6428B23E for <v6ops@ietf.org>; Wed, 15 Dec 2010 13:13:57 -0800 (PST)
Received: from 219-90-153-253.ip.adam.com.au ([219.90.153.253] helo=opy.nosense.org) by smtp1.adam.net.au with esmtp (Exim 4.63) (envelope-from <ipng@69706e6720323030352d30312d31340a.nosense.org>) id 1PSyhF-0003OL-Kw; Thu, 16 Dec 2010 07:45:37 +1030
Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id DBA4A3B31E; Thu, 16 Dec 2010 07:45:36 +1030 (CST)
Date: Thu, 16 Dec 2010 07:45:36 +1030
From: Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>
To: "t.petch" <ietfc@btconnect.com>
Message-ID: <20101216074536.6f10447e@opy.nosense.org>
In-Reply-To: <00ff01cb9c3b$a51c7420$4001a8c0@gateway.2wire.net>
References: <AANLkTik248vSqAb79=oEWmzNwZ4xOP7ZSp01b6A4bXZ4@mail.gmail.com> <00ff01cb9c3b$a51c7420$4001a8c0@gateway.2wire.net>
X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; x86_64-unknown-linux-gnu)
X-Location: Lower Mitcham, South Australia, 5062
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: v6ops@ietf.org
Subject: Re: [v6ops] network topology hiding
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Dec 2010 21:13:58 -0000

On Wed, 15 Dec 2010 10:37:04 +0100
"t.petch" <ietfc@btconnect.com> wrote:

> ----- Original Message ----- 
> From: "Toru Kuboshiki" <toru.kuboshiki@wata-lab.meijo-u.ac.jp>
> To: <v6ops@ietf.org>
> Sent: Wednesday, December 15, 2010 8:46 AM
> 
> > Hello, everybody.
> > My name is Toru Kuboshiki, the student of Meijo University in JAPAN.
> > This is the first time I post on this mailing list.
> > 
> > I am studying how we can familiarize IPv6.
> > I think that one of reasons, why IPv6 does not become popular, is that
> > IP addresses in the local network are seen from the outside. In IPv4,
> > NAT conceals a whole network and this gives the network manager
> > security. 
> 
> <more emotion than engineeering>
> 
> Put forward this point of view on some lists, the main IETF one for 
> example, and, judging by past experience, you will get a firestorm of 
> protest that NAT adds no security.  I think that the truth is closer to
> that than you say, that NAT adds a little security, but not much.  I have
> worked with a number of managers who are convinced that it adds 
> a lot, and I think that that is a dangerous position to take.
> 

NAT topology hiding is functionally equivalent to camouflage. It
provides a minimal defence in depth mechanism, however anything that
uses it also a big gun, can run fast, can kick hard, or bite savagely
to resort to when the camouflage fails. People who seem to vehemently
defend topology hiding seem to be coming from a position that there is
no need for any other prevention or response mechanisms, which is quite
false.


> At the same time, you will see a lot of support for the view that NAT
> destroys end-to-end communication, which I personally think untrue
> in almost all cases.

I don't think you fully understand what "end-to-end" is referring to.

The nature of the Internet is supposed to be, and was originally 
peer-to-peer. A peer-to-peer network architecture means that if a
node has an network address, it has an equal ability to directly send or
receive packets to any other node that also has an address and is
attached to the same network. What the end-nodes, and more
specifically, what the applications put in those packets was irrelevant
to the newtork. The roles of "client" or "server" are only supposed
to be relevant to application architecture and roles. A node attached
to a peer-to-peer architecture network should be able to concurrently
run client or server components of applications without any network
imposed limitations - it was exclusively an end-nodes choice as to what
application role it wanted to play, not the network's. Also,
because the network doesn't care about what applications
it was being used for, the network doesn't need to be upgraded
before new applications can be deployed.

NAT has broken the peer-to-peer nature of the Internet. The
consequences have been that some end-nodes can't directly send traffic
to other end-nodes, so they have relay the communications via another
intermediary node that is visible to both the end-nodes. This
intermediary node then becomes another possible failure point, an
possible traffic interception point and a potential performance
bottleneck point. Applications that are forced to use an intermediary
become less reliable, less naturally secure and less scalable. Yet
there is no other choice if the end-nodes cannot directly send packets
towards each other. That is the limitation that NAT has imposed on
end-nodes. NAT exists because there aren't enough IPv4 addresses to
give all end-nodes unique addresses, and therefore not all remote-end
nodes that local end-nodes might want to send packets to are uniquely
identifiable and therefore reachable. Giving every end-node a network
unique Internet address (i.e. an IPv6 one), will give them back their
ability to exclusively choose what role they want to play in the
application architecture.

>  The protocols used by the vast mass of Internet
> users overcame NAT years ago, and there are just a few protocols,
> unknown to almost everybody in the world at large, which have not,
> but for most people, that is irrelevant.

NAT boxes "overcame" those limitations be incurring the hidden costs of
forcing public intermediary servers to exist, and application
developers to have develop client-server applications where a
peer-to-peer application architecture would have been far more
reliable, secure and scalable. The costs of dealing with a network
layer problem, namely lack of IPv4 addresses, has been shifted onto the
application developers and ultimately the end-users of those
applications. People have accepted them because there is no other
choice an an IPv4/NAT scenario - but with the deployment of IPv6
without NAT those costs can disappear. So we'll have more reliable, more
naturally secure and more scalable applications at less cost.

> 
> So, roll on NAT! we won't need it to in IPv6 as an address proxy, 
> and it won't add security, but I still expect it to happen.
> 

Returning to the original question, for the comparative advantage of
network camouflage, verses the other costs NAT incurs, I'm willing to
go without it.

Regards,
Mark.