On supporting NAT, was: Re: MBONE access?
On 4-mrt-04, at 2:44, Hallam-Baker, Phillip wrote: In case you had not noticed there are now tens of millions of NAT devices in use. End users are not going to pay $10 per month for an extra IP address when they can connect unlimited numbers of devices to the net using a $40 NAT box. Sounds like a conspiracy... ISPs charging orders of magnitude more than cost for additional addresses forcing people to use NAT. 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. The Internet was designed to be a network of networks. The core architecture is NOT end-to-end, that is a political shiboleth that has been imposed later. Suppose for the sake of argument that the above is a valid position, and that we would actually want to make NAT work. What we need to do then is extend it such that it becomes possible to address hosts behind a NAT from the public internet. 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. 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. 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? 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, as it just makes for an arms race between firewall vendors that inspect deeper and deeper into packes and firewall bypass utilities that tunnel the real protocol through more and more layers of accepted protocols. 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.
RE: On supporting NAT, was: Re: MBONE access?
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
Re: On supporting NAT, was: Re: MBONE access?
On 4-mrt-04, at 14:42, Hallam-Baker, Phillip wrote: 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. 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. 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. 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. 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). 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. 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. It's annoying when people complain about a problem when the solution is right there in their face. 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. In this case, you only need to be visible to the streaming server... Use your IPv4 address for other stuff if you like. 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. 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. 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. 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 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.
RE: On supporting NAT, was: Re: MBONE access?
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. VoIP is still a client-server model when you get down to the individual communications. For that matter so is UDP. In any communication you have to have a listener waiting for attention and a party that initiates the message transfer. This happens even when you look at CSP type mechanisms where there is a symmetric rendezvous. What if two boxes want to have the same port open? Same thing that happens when two processes on the same box ask for the same port. The latecomer loses. Either that or the port is assigned on a different IP address, these could be pooled at the ISP level. That is not a problem if you know about this restriction when you design the protocol that is NAT listener friendly. You could even build into the protocol a feature that would allow a response of the type, 'the port requested is already in use by machine at address 10.2.1.1, he is accepting requests to share via protocol X on port Y' 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. Needs attention is not the same as 'impossible'. It is very clear that the negative effects of NAT can be largely eliminated if there is goodwill and an intention to succeed. It is equally clear that the whole issue of NAT has been addressed here with a complete determination to fail. It's annoying when people complain about a problem when the solution is right there in their face. A 'solution' that requires action by parties completely out of my control does not qualify as such in my opinion. At present I don't expect much in the way of NAT deployment before 2015, and that is building in expectation of a major shakeup in the management structure in 2010. If things go on as at present I don't expect IPv6 deployed before 2025. 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. I don't follow. NAT performs address translation. it is in effect an Ipv4 to IPv4 translator. Make that transparent and you can make Ipv4 to IPv6 and IPv6 to Ipv4 transparent in the same way. 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. Which is why the empirical observation that firewalls significantly reduce the number of successful penetration incidents is important. The theoretical strength of a firewall against the NSA is irrelevant when 99% of the attacks are from script kiddies. Filtering out the 99% of script kiddies allows more time to focus on the remainder. 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. Yes, and sign the messages under a key protected by the trustworthy computing base. That is where Palladium gives real value. Phill
