>> 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.
I get that. What I don't get is that the granularity for such control should
be on a per-NAT basis, rather than on a per-application basis. For every app
that should not be aware of its external IP address, there's an app that should
be aware of its external IP address.
And furthermore, if you want to keep an app from being aware of its external IP
address, the only reliable way to do that is to block that app from
communicating with any external host. If you just tell the NAT to disable that
functionality, there's at least some chance the app can still use ICE on some
other external server. So you're not buying yourself any security benefit by
disabling the functionality in the NAT. All you're doing is making apps more
complex and harder for people like yourself to control.
Again, you're trying way too hard to make the NAT do the firewall's job.
> 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.
Typing the word OPTION in all caps doesn't keep it from doing harm. What app
writers need is a predictable environment, not one that changes at the whim of
a network administrator. I'm not saying that apps should be able to do
everything that they want, I'm saying that IETF shouldn't endorse a mechanism
that can't be made to work fairly consistently from one network to the next.
There's a world of difference between creating a practical necessity for an app
to try using the NAT's ICE mechanism, and if that fails, to try using an
external server to do the same thing; from creating a uniform way for apps to
ask for an external address and having the app be told "it's a violation of
policy for you to send a referral to an external peer". And the only way to
make the latter kind of mechanism viable is to do it on a per-app basis.
In general, apps have no way in the current network architecture to distinguish
explicitly chosen network policy, from network failures and the inability of
access control mechanisms to be applied with sufficient granularity. Apps are
often expected "to do the right thing" (even by network administrators) in the
face of NATs, firewalls, etc. that block traffic on a very coarse-grained
basis, and "the right thing" for the app to do is not (in general) to just fall
over and play dead when the network, NAT, firewall, etc. doesn't permit the
first thing that the app tries to do (especially when the app generally has no
idea why the first thing it tried to do didn't work).
So what I see is that you need two things:
1. Control over access to network resources on a per-app basis.
2. A mechanism that allows an app to know whether what it is trying to do would
violate network policy. Then it at least becomes possible for well-behaved
apps to know when they're crossing a line and to issue useful error messages to
users ("this operation is prohibited by your network administrator, whose
address is [email protected]").
Both of these are in the firewall space. Neither one is in the NAT space?
> 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?
The problem is that you keep trying to get IETF to endorse brain-damaged
mechanisms. It's not that you don't have legitimate concerns, it's that you
keep insisting that IETF recommend that people use the wrong tools for the job.
Keith
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
