> -----Original Message----- > From: Keith Moore [mailto:[email protected]] > Sent: Wednesday, October 27, 2010 1:39 PM > To: Chris Engel > Cc: Fred Baker; NAT66 > Subject: crippling apps ; dns as a generic referral mechanism (not) > > > > > I actually wouldn't have any objection to some mechanism built into > > NAT that allowed for a requesting host/application to be > informed of > > the Public Address it would be assigned by the NAT device. My only > > caveat would be that the Administrator SHOULD be able to > disable such > > functionality on a given interface if they choose. It could > be enabled > > by default, but there should be an option to turn it off if you > > explicitly choose to do so. > > Why are you trying to cripple apps? > > If you don't want certain apps to function across your > network border, disable their traffic at the firewall. > You're trying way too hard to make NATs do a firewall's job. >
Enterprise Admins spend a great deal of time keeping unauthorized apps from running. Many such apps are problematic to use in an Enterprise environment, even when they aren't intended to be malicious and have legitimate functions outside such environments. What I'm trying to accomplish is insure that the people responsible for deploying and maintaining such a hypothetical mechanism on thier OWN boundary are able to excersize some degree of control over how it functions. There may well be legitimate reasons for an engineer to NOT want a host/application to be aware of it's external IP. In the case given we would be talking about an OPTION that was disabled by default and had to be explicitly enabled in order to disallow such functionality. There could even be strong language reccomending against doing so and listing the consequences of such. In that case, the only people who would be breaking apps, would be doing so on purpose. Where is the problem with allowing the people who own and are responsible for deploying and administering a solution some granularity of control over how it works? > > Note that I understand the reluctance for applications to > rely overly > > on DNS. For practical purposes with propagation and caching issues, > > TTL's are often not respected. > > True, but there's a lot more to it than that. > > Here's a quick example: Say you want to write an app that > needs to do referrals. Say further that the app needs to be > port-agile because of the potential for NAPTs in the signal > path. Let's say further that the app uses ICE or some other > heuristic to find its external/global transport address. > Where in DNS is the app going to store that transport > address? (Don't say that the application vendor should > provide zones and servers for that purpose - that's basically > tantamount to saying that every app needs to have its own > referral servers in the public network. Also don't say that > the app should be able to use the host's DNS zones, because > admins are highly unlikely to allow that.) How is it going > to reliably store/update that transport address given that > some ISPs intercept port 53? How does the app get > credentials to allow it to write RRs to that zone? And how > much does that really help the referral problem? Sure it > provides some insulation against the transport address > changing - assuming the app notices the change it can update > the transport address in DNS. But there is the TTL problem, > as you point out. DNS is fundamentally designed for storing > data that doesn't change often, and where the changes are > managed events. And even if you can use small TTLs and get > all of the parties involved to respect those TTLs, that > doesn't fix TCP connections that break when the transport > address changes. > > And that's just one example. > > Keith > > > _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
