RE: Where NAT disenfranchises the end-user ...

From: Jon Mansey [mailto:JMansey@interpacket.net]
Sent: Thursday, September 06, 2001 11:41 AM

Isnt part of the solution here for ppl to write NAT-aware
applications?

I got this idea from a bugtraq post about gnutella that is able to
detect and announce a different IP address than that of its actual
private host IP based on what its internet-facing public IP is.

Im sure there are a host of reasons why this is not a good idea from
a security POV, but its a start, no?

Im not disputing that a NATed connection should not be sold as "full
Internet connectivity", I agree, but in terms of making it look and
feel like one, I think we're close.

Two software development houses, playing nice with each other, is more rare
than two ISPs doing same. The bottom-line is that it comes right off the
bottom-line. You can't deny that it's extra work/cost and effects
time-to-market. Remember, in software development, it's the second 90% that
kills the project. Consider the straw that broke the camel's back. Then
consider that 80% of all software projects never make it to market. Then
consider that most developers are NOT network engineers. They expect the
network to *be there*, period.

Roeland Meyer wrote:

...
Then consider that most developers are NOT network engineers.
They expect the network to *be there*, period.

Or more completely, they expect the network to be transparent
so that every port at the destination IP address connects to
the same machine, and there is no operational restriction on
which end initiates the communication.

Tony

Or more completely, they expect the network to be
transparent so that every port at the destination IP
address connects to the same machine, and there
is no operational restriction on which end initiates
the communication.

which of course *is* possible for at least one machine per visible IP
address - even if additional IPs are masqed behind it.

Tony

Tony Hain writes:

Roeland Meyer wrote:

> ...
> Then consider that most developers are NOT network engineers.
> They expect the network to *be there*, period.

Or more completely, they expect the network to be transparent
so that every port at the destination IP address connects to
the same machine, and there is no operational restriction on
which end initiates the communication.

Nicely put. Of course, that model does not correspond to reality, nor
is it ever likely to. Traffic is always going to be controlled,
filtered, redirected, and translated at administrative boundaries.
Global, packet-level, end-to-end connectivity is dead, until somebody
comes up with a compelling argument for why a Windows PC in an
Internet cafe in Sofia, Bulgaria needs unfettered, packet-level access
to a Coke machine in a break room at Sun Microsystems in Palo Alto.
Like the battleship that radios a request for the lighthouse to move
out of its way, detractors of NAT seem to be waiting for the world to
modify itself to accomodate their end-to-end model.

Eric Hall <ehall@ehsco.com> has expressed the position succinctly:

The fact is that I can write an Internet-compliant application in
about two minutes that will break every NAT ever sold, simply because
they don't have a proxy for the protocol. NATs violate fundamental
Internet principles.

Many stupid things can be done in about two minutes. This particular
fundamentalist tenet has been at odds with reality since the first
firewall was installed, and will only become more so.

Jim Shankland

From: "Jim Shankland" <nanog@shankland.org>

Nicely put. Of course, that model does not correspond to reality, nor
is it ever likely to. Traffic is always going to be controlled,
filtered, redirected, and translated at administrative boundaries.
Global, packet-level, end-to-end connectivity is dead, until somebody
comes up with a compelling argument for why a Windows PC in an
Internet cafe in Sofia, Bulgaria needs unfettered, packet-level access
to a Coke machine in a break room at Sun Microsystems in Palo Alto.

Or why a team of gamers need to be able to coordinate n-way traffic between
them without each of them having listeners

Or why a protocol would need to embed addressing into the datastream

Not like any of that will ever happen.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric Hall <ehall@ehsco.com> has expressed the position succinctly:

> The fact is that I can write an Internet-compliant application in
> about two minutes that will break every NAT ever sold, simply because
> they don't have a proxy for the protocol. NATs violate fundamental
> Internet principles.

Many stupid things can be done in about two minutes. This particular
fundamentalist tenet has been at odds with reality since the first
firewall was installed, and will only become more so.

Jim Shankland

Oh yes, the firewall. That convenient device that network software
developers can assume will always pass port 80 and 443 traffic. So
everything uses port 80 and 443 in the future Internet, and we're all the
better for it.

Uh-huh.

Many streaming/multimedia apps try port 80 http if their typical range is
not open..

Brian "Sonic" Whalen
Success = Preparation + Opportunity

Brian Whalen wrote:

Many streaming/multimedia apps try port 80 http if their typical range is
not open..

A readily implemented awful hack doesn't make it less of an awful hack.