[arin-ppml] CGN multiplier was: RE: Input on an article by Geoff Huston (potentially/myopically off-topic addendum)

[Tom Vest]

On Sep 15, 2011, at 12:19 PM, Chris Engel wrote:

>> In places where consumers have choice, perhaps nothing is particularly
>> wrong with that. However, there are a great many places where the
>> consumers choice is limited to whatever service they can get from monopoly.........
> 
> Owen,
> 
> You'll have no disagreement from me that lack of consumer choice is a bad thing. However, I don't believe the appropriate answer to that is to restrict choice even further by trying to dictate to carriers (or even end user networks) what sort of protocols they must run. A better answer would be to foster more competition in the market place. Barriers to entry aside, I certainly know that I have significantly greater choice of carriers and types of services then I did a decade ago.  If consumers aren't particularly happy with their current service but feel they just have to live with it because they have no better options, then there is a very significant opportunity for someone to come in and capture that market segment.
> 
> 
>> If you can spell out that functionality, I'll be happy to show you how to do
>> that in IPv6. It may require a certain amount of rethinking your methodology,
>> but, I have yet to encounter an application where you could not achieve just
>> as good a result without NAT using better methods available in IPv6.
> 
> Sure, I'll give you a number of examples that are important to me (i.e. We actually use NAT to perform these functions today in our Enterprise)....
> 
> 1) I want to be able to easily and quickly switch around the hardware that provides a particular service without changing anything about the external advertisement of that service on the network level and I don't want to have to worry about doing any renumbering or re-architecting on my internal infrastructure when I do so. I even want to be able to take 1 device that provided 2 services (say SMTP & HTTP) and split them into 2 separate devices without changing the advertisement of those services.
> 
>                   - DNS won't work for that as it has propagation and caching issues that are beyond my control. Even if I set a really short TTL, some external resolvers will just ignore it and cache it for multiple days. On top of that, I may not always know well in advance when I need to switch hardware and if I keep a short TTL for everything, all the time, I'm significantly increasing the number of DNS requests I need to resolve. 
> 
>                  - The externally IP's need to be static, since we have multiple partners/clients that have setup firewall rules on their own firewalls to allow their users to interact with our services. I can't go around coordinating with 50 different outside entities to change their firewall rules, every time I change a piece of hardware. These outside entities generally want to define their FW rules as narrowly as possible ( good security practice) therefore opening up their FW's to my entire potential address range would be a no go.
> 
>                  - I don't want to have to manage more IP's then absolutely necessary on each individual end device. Not only does that become a management overhead nightmare......but I don't want any complications when I move provision of an external service from a device on one part of my internal network to another part.
> 
> 2) I want access to my internal devices to fail closed where possible. We have alot of devices on our corporate network that aren't going to be as well hardened as devices that we EXPECT to be hosting external traffic. Those devices MAY occasionally need to establish OUTGOING connections to areas of the public internet but they'll never need to accept INCOMING ones. While all these devices are behind statefull firewalls that SHOULD have access rules blocking unintended access. Those firewalls are configured and maintained by human beings...and human beings are capable of mistakes. A common mistake with firewalls (that goes unnoticed) is to define a rule that opens access too broadly. With many to one NAT, even if admin inadvertently defined a FW rule too broadly, an INCOMING packet to one of those devices will fail since there will be no entry in the FW's state table to tell it where to route that packet (i.e. fail closed). I want something that provides an equivalent level of protection.
> 
> 3) Privacy. I want to retard the ability of external entities to track and profile my users. At the same time, I want to preserve the ability of INTERNAL admins to easily track and recognize the activities of said users. With many to one NAT this is fairly straightforward. An external entity see's 1 IP address for all our users/devices. So at least on the network level when it see's that IP somewhere else, it can't tell which user/device on my network it belongs. Yet, at the same time, one of our admins needs to track what a user/device was doing, they can pretty easily parse our FW logs for the internal IP assigned to that device. In fact our address scheme pretty much allows us to recognize what sort of device an internal IP is without even bothering to look it up.

Out of curiosity, do you rely on IP transit for reachability to any part of the rest of the Internet?

If so, how do you feel about the identifiability of your own network-operating entity to third parties, i.e., those with whom you do not have a direct/bilateral contractual agreement?  

An finally, would you be comfortable knowing that any transitive traffic exchanges that you voluntarily participate in would always/constantly and unavoidably necessitate exposing you and your customers to intentional and/or unintentional adverse impacts, including some that are not and will never become (more) predictable over time, and some that were/are initiated by remote third parties that are not and will never be identifiable at any future point in time... and others still that would be and remain unknowable in both of these ways? 

All it would take for these question to go from academic-rhetorical to urgent-operational would be a marginally liquid market for ASNs plus anything less than 100% complete, 100% accurate, and 100% instantaneous participation in a public registry of the kind that we currently have.

TV 

> 4) Renumbering/multi-homing. If we DO need to change carriers or add additional ones....I don't want to have to worry about doing anything with the address assignments to all our internal devices. With NAT, I will just need to worry about the external address scheme at the boundaries...don't need to worry about doing anything inside the boundaries.
> 
> Those are a few of the things we currently find NAT useful for. What are your suggestions? Note, I HAVE considered other alternatives to address some of the above....but pretty much all of them fall short of the same sort of utility NAT currently provides us...or have undesirable side effects. Currently, NAT doesn't break anything for us that we wouldn't want broken in the first place. So not much of a downside from a practical perspective there. If that changes dramatically in the future, I'd certainly reevaluate.
> 
> 
> 
> 
> 
> Christopher Engel 
> 
>