RE: NATs as firewalls
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: NATs as firewalls



> From: michael.dillon at bt.com [mailto:michael.dillon at bt.com] 

> IPv6 is also a technology refresh, i.e. it forces vendors to 
> reimplement their boxes. It forces people to buy new systems. 
> If the only thing that they get is a new protocol with wider 
> addresses, then they will see this as a generally negative 
> experience and wonder why people with more money couldn't 
> just buy IPv4 addresses from those with less. Let them eat NAT!

Quite, the bigger address space does not necessarily drive adoption in the way we would wish. Population pressure in Europe continued to bid up the value of land there even after the discovery of the New World. 

Even though there was no shortage of space in the New World (if you were prepared to push aside the indigenous population) it was three centuries before the infrastructure there made the land equally attractive.

> But, if there are clear guidelines for IPv6 gateways that 
> focus on enabling functionality then people will see a value 
> in upgrading. An explicit firewall service is a value. No NAT 
> thus enabling more peer-to-peer applications is a value. 
> There could be more to it as well.

You conflate an implementation with a requirement.

Enabling peer-to-peer applications, in particular video conferencing is the value. ANY means of enabling the benefit works.

The chief challenge however is how to open up the network to inbound TCP requests without creating a security melt-down. Eliminating NAT does not by itself eliminate the network issue. Once you start to look at ways of managing the network security issue the question of addresses becomes moot.


> For instance, if we accept the model that the majority of 
> Internet hosts will communicate with the core via stateful 
> gateways, then there is the possibility of a standard way for 
> an application to communicate with its local stateful gateway 
> iFrom ietf-bounces at ietf.org Mon Mar 05 12:16:49 2007
Return-path: <ietf-bounces at ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1HOGn0-00027d-7K; Mon, 05 Mar 2007 12:15:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1HOGmy-00027T-VH
	for ietf at ietf.org; Mon, 05 Mar 2007 12:15:56 -0500
Received: from colibri.verisign.com ([65.205.251.74])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HOGmx-0006Ge-JV
	for ietf at ietf.org; Mon, 05 Mar 2007 12:15:56 -0500
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com
	[65.205.251.33])
	by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id l25HFlxf013353;
	Mon, 5 Mar 2007 09:15:47 -0800
Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by
	MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft
	SMTPSVC(6.0.3790.1830); Mon, 5 Mar 2007 09:15:47 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 5 Mar 2007 09:15:47 -0800
Message-ID: <198A730C2044DE4A96749D13E167AD3701147B1F at MOU1WNEXMB04.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: NATs as firewalls
Thread-Index: AcdekBmA8PBYw9UlRvKoVf0viHjAtQAcDOOAAA80hcAFrom: "Hallam-Baker, Phillip" <pbaker at verisign.com>
To: <michael.dillon at bt.com>, <ietf at ietf.org>
X-OriginalArrivalTime: 05 Mar 2007 17:15:47.0834 (UTC)
	FILETIME=[EAB525A0:01C75F49]
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc:
Subject: RE: NATs as firewalls
X-BeenThere: ietf at ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf at ietf.org>
List-Help: <mailto:ietf-request at ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:ietf-request at ietf.org?subject=subscribe>
Errors-To: ietf-bounces at ietf.org


> From: michael.dillon at bt.com [mailto:michael.dillon at bt.com] 

> IPv6 is also a technology refresh, i.e. it forces vendors to 
> reimplement their boxes. It forces people to buy new systems. 
> If the only thing that they get is a new protocol with wider 
> addresses, then they will see this as a generally negative 
> experience and wonder why people with more money couldn't 
> just buy IPv4 addresses from those with less. Let them eat NAT!

Quite, the bigger address space does not necessarily drive adoption in the way we would wish. Population pressure in Europe continued to bid up the value of land there even after the discovery of the New World. 

Even though there was no shortage of space in the New World (if you were prepared to push aside the indigenous population) it was three centuries before the infrastructure there made the land equally attractive.

> But, if there are clear guidelines for IPv6 gateways that 
> focus on enabling functionality then people will see a value 
> in upgrading. An explicit firewall service is a value. No NAT 
> thus enabling more peer-to-peer applications is a value. 
> There could be more to it as well.

You conflate an implementation with a requirement.

Enabling peer-to-peer applications, in particular video conferencing is the value. ANY means of enabling the benefit works.

The chief challenge however is how to open up the network to inbound TCP requests without creating a security melt-down. Eliminating NAT does not by itself eliminate the network issue. Once you start to look at ways of managing the network security issue the question of addresses becomes moot.


> For instance, if we accept the model that the majority of 
> Internet hosts will communicate with the core via stateful 
> gateways, then there is the possibility of a standard way for 
> an application to communicate with its local stateful gateway 
> in order to change the state, rather than implementing things 
> like STUN (Simple Traversal of UDP through NAT).
> That too, would be a value for the buyer of a standard 
> Internet gateway.

This is the model that I prefer. It allows me to meet a set of security objectives that is considerably more restrictive than anything on the market today yet also make use of video conferencing and other peer to peer configurations practical.

One of the keys here is to step back from administering hosts and instead look at ways to configure the network.

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.