Subject: RE: On supporting NAT, was: Re: MBONE access?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 4 Mar 2004 05:42:30 -0800

> Sounds like a conspiracy... ISPs charging orders of magnitude 
> more than 
> cost for additional addresses "forcing" people to use NAT.

Its called a monopoly.

There are good reasons why ISPs are encouraging their customers
to use NAT, they provide a weak firewall capability and that
in turn significantly reduces exposure to being hacked which
in turn reduces the cost of chasing zombie machines.

The next generation of cable modems my ISP will be installing will
have a NAT box built in.

> > The NAT war has been over for years, NAT won. The problem is that
> > the IETF still has not come to terms with that fact.
> 
> I don't think anyone has won here, there are just casualties all over 
> the place: more work for the IETF and vendors, less functionality for 
> the users.

Less functionality is a deliberate, concious choice on the part of
the IETF. Fixing the problem is utterly trivial.

Think of all the machines in my network as a single machine with a
single IP address. The requests to open and close ports to the outside
world are simply RPC requests (without the RPC syntax).

> That should be perfectly doable, in 
> essence we'd be redefining the protocol and port numbers to 
> be part of 
> the address. However, this means these must now also be put 
> in the DNS 
> and in most other places where IP addresses show up. So this 
> adds up to 
> a HUGE amount of new work.

No, the machines do not need to be individually addressable.

> Guess what: we already did pretty much the same thing with IPv6. The 
> logical conclusion here is that we can save a lot of time and 
> effort by 
> simply adding IPv6 to the mix, as it is just a hair shy of 
> being ready 
> for full deployment, while all this stuff to make NAT 
> actually work is all over the place.

Simply repeating the claim that IPv6 is the solution to every
issue does not make it so, or advance the deployment of IPv6.
The problem is the intrinsic asymmetry between the value of
an IPv4 and an IPv6 address. An IPv4 address will be visible 
to the world, an IPv6 address will only be visible to other
IPv6 addresses.

The main reason IPv6 is nowhere is the refusal to deal with NAT
except by ideological reactions like the above. NAT is the
way to deploy IPv6. 

The consumer's internal network can then be a NAT'd IPv4 net
and the external network can be IPv6.

> > In the case of H323 the problem is not just NAT, it is the derranged
> > protocol which uses a block of 3000 odd TCP/IP ports to receive
> > messages on. there is no way that this is consistent with good
> > firewall management
> 
> So now you are complaining because after you install a firewall, it 
> turns out the thing does its job? 

No, I am complaining about a protocol that is not firewall friendly.

> The whole idea that decent security 
> can be had by allowing packets with certain port numbers in 
> them in and 
> not others is fatally flawed, 

Your view is not held by the computer security industry. Sure firewalls
are not infallible. But that does not mean that they do not provide a 
valuable service.

One reason everything is migrating to Web Services is that the 
Web Services stack is designed to support a new generation of
firewalls and expose exactly the right data at the perimeter.

> What we need is "corporate zone alarm" like functionality, where 
> firewalls get to see which applications (and users) are trying to 
> communicate with the outside world, rather than guess based 
> on the port 
> number in the packet. This would allow some very nice 
> features such as 
> blocking vulnerable versions of applications but allowing patched 
> versions of the same application.

That is not a bad idea. In essence it would mean extending requests 
to open incomming AND outgoing ports to the perimeter defense.

"Hey Mr firewall, this is Internet Explorer version 9.2, please
allow me to connect up to port 80 on 23.43.2.2"

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 4 Mar 2004 18:52:43 +0100

> in turn reduces the cost of chasing zombie machines.

Hm, but apparently many ISPs don't care about their customer boxes 
being turned into zombies as they let them persist in their undead 
state for long periods of time. ISPs would probably love it if there 
were no NAT (or proxies, NAT is no more than a simple way to implement 
generic proxying), that way they could extort their customers even 
more.

> the IETF. Fixing the problem is utterly trivial.

A pointer or two to support the former would be nice. An explanation of 
the latter too, as I'm unfamiliar with this trivial fix.

Or are you referring to the issue that some client/server type 
interactions are broken when the client is behind NAT? This should 
probably be fixable in most cases (I wouldn't call updating huge 
installed bases trivial though), but that still leaves the applications 
and protocols that don't conform to the client/server model, such as 
VoIP.

> world are simply RPC requests (without the RPC syntax).

What if two boxes want to have the same port open? Believe me, you are 
just making the port number part of the address. Internal address 
allocation (your RPC w/o RPC mechanism) is only one of the issues that 
needs attention in this case.

>> effort by simply adding IPv6 to the mix, as it is just a hair shy of
>> being ready for full deployment, while all this stuff to make NAT

> issue does not make it so, or advance the deployment of IPv6.

It's annoying when people complain about a problem when the solution is 
right there in their face.

> to the world, an IPv6 address will only be visible to other

In this case, you only need to be visible to the streaming server... 
Use your IPv4 address for other stuff if you like.

> except by ideological reactions like the above. NAT is the

I don't follow.

>> The whole idea that decent security can be had by allowing packets 
>> with certain port numbers in them in and not others is fatally 
>> flawed,

> Your view is not held by the computer security industry.

The idea that "security" is a substance with an independent existance 
which underpins a "security industry" is also fatally flawed. (And one 
of the main reasons why I chose to avoid becoming a part of said 
industry.) Security is a property of all aspects of life and must be 
managed as such.

>> on the port number in the packet.

> allow me to connect up to port 80 on 23.43.2.2"

Right! When the firewall considers IE 9.2 safe it may allow it to 
communicate freely, but at a later time, when a vulnerability is found 
and (hopefully) a new version is installed, IE 9.2 isn't allowed to 
connect to the rest of the world anymore, or only to trusted 
destinations. This mechanism would also be great to catch trojans and 
other unauthorized software trying to communicate over the net.