whether it's a good idea to encourage sites to use address selection as
a means of policy enforcement is a separate question. IMHO this is not
sound architecture. but that's a separate question from the API.
I'm not convinced it's sound either, but I can't figure out a more
straightforward way of implementing the types of policies I hear customers
ask for.
what policies are those? what kinds of filtering can be implemented with address selection that cannot be implemented without it?
I meant the application can't statically determine what a site's policy
will be; that doesn't mean the API can't determine it via some sort of
configuration.
the more I think about it the clearer it becomes that specifying application policy at the network level is like trying to make fine furniture with a chainsaw - it's the wrong tool for the job. so the API that the app uses to deal with the network is not the right place to inform the app about policy.
I don't think the app needs to be aware of policy if it's hidden behind the
API -- presumably the policy will be configured and implemented in the OS or
some system library. As long as the app can specify what behavior it needs
and the policy is able to find a valid address, the app can stay oblivious.
that's true only as long as the same policy applies to every host that is participating in the app. any app that crosses policy domains has the potential for conflicts between those policies. in one part of the network the policy is to favor globals; in another the policy is to favor locals. there's no good reason to support this kind of inconsistency and complexity. what we need are a set of rules for assigning addresses to hosts and for use of addresses by hosts and apps that works the same everywhere. that doesn't stop networks from having policies, but it does mean that there are correct and incorrect ways to implement those policies.
the app writer knows what his app needs from the network. if the network doesn't provide what the app needs, the app is likely to fail. maybe it won't fail every single time it is used, but it won't be reliable.
Even if the API were to return what the app asks for (e.g. a global
address), there are still a large number of cases where that address still
won't work because of firewalls or other necessary evils.
it is not at all clear that firewalls as we currently know them are necessary, though I do accept that they're going to continue to exist for awhile. as long as packet filters exist the best we can hope for is to get them to return appropriate ICMP messages.
On a slightly different note, there may be many servers or p2p apps with
only local addresses available because that is the administrator's intent.
the rules have to accommodate the fact that not everyone is connected to the public internet and not everyone has public addresses. apps have to use local addresses if global addresses are not available. of course this limits the app to whatever addresses are reachable. but the same is true for global addresses, since as you point out, those addresses can still be filtered.
on the other hand, if your net has a global prefix, trying to limit a host or an app to a local prefix is not a very good way to implement policy. it's the wrong tool for the job.
Having these apps fail because no global address is available doesn't make
sense, even if it does print a friendly error on the screen. This case is
only marginally different than one where a global address is available but
the administrator doesn't want it used for local communication.
no, that's just wrong. it's one thing to say that an app isn't expected to communicate if the network isn't wiling to route packets between its hosts. it's quite another to say that it's appropriate for network admins to restrict which addresses an app or host can use in order to keep the network from routing packets between certain hosts. it's crude and imprecise, it imposes unnecessary complexity on hosts and apps, and it's unreliable. it's much easier to reliably implement a policy if reachability is the same for every address that is available to a host than if reachability varies from one prefix to another. it's also much easier to monitor network traffic for policy violations if this is the case.
"Needs a global address" is an inherently flawed expectation; "needs an
address which can reach a given address" is not.
there are apps that need global addresses in order to function properly. there are other apps which need addresses that are reachable by an arbitrary number of hosts which might be participating in the application now or at sometime in the future (though they don't need to be global). other apps only need pairwise reachability.
"Function properly" and "reachable by an arbitrary number of hosts" are both
flawed in the presence of firewalls anyhow.
ARRRRRRRRRRGH!
no, they're not flawed. it may be that what the app needs and how the admin has configured a firewall are mutually inconsistent. that doesn't inherently mean there's something wrong with the app.
it's perfectly reasonable for some apps to operate that way. it might be that the admin simply doesn't want that app to operate. it might be that the admin has misconfigured the firewall. it might be that present-day firewalls are too crude to allow the admin to implement the policy that he wants and still have the app operate.
but folks need to stop blaming apps for failing when they impose unreasonable conditions on their operation.
It is well within an
administrator's right to block such applications from leaving the local
network, and in that case a local address becomes superior to a global one
due to stability.
you're confusing two different things here. one is policy, and the other is use of local addresses for stability. if the app can reasonably make use of local addresses, telling the app "hey, you can use this more stable local address in place of this global one" is a useful thing to do. then the app can optimize if it's able to do so. but this doesn't work equally well for all apps. some apps need for every host to use the same address and for all of those addresses to be reachable by all participating hosts. those apps probably don't want to use local addresses unless they're the only ones available. this is something for the app to decide, not something for an admin to try to dictate with policy.
it's not reasonable to expect admins to know how every app operates and what they need in terms of addresses.
it is reasonable to let admins control which hosts or users or principals an app can talk to, but prefix assignment is not the right mechanism for the job.
I never suggested that; I gave a simple case of two mutually exclusive
local policies which are both perfectly reasonable, but would cause apps
to needlessly fail if they make unfounded static assumptions.
it's not "perfectly reasonable" for local policies to expect apps to vary how they choose addresses from one site to the next.
That's the whole point of providing an API -- the app just specifies its
requirements and which available address is returned (if any) will
implicitly vary between sites.
having an API is useful - to a point. different kinds of apps prefer different kinds of addresses. some apps prefer privacy addresses; others need addresses that have a long-term association with the host. some apps prefer local addresses even when a global is available, others have the opposite preference. some apps prefer an ephemeral address (like an address that changes when the host moves) for the sake of efficiency, others prefer one that will stay the same even if the host moves even though this is less efficient. it's good to have an API that lets the host and app negotiate these things.
what's not a good idea is to expect this API to be a means for implementing policy. the fact that the address selection is hidden by an API does not keep it from breaking apps.
There is no consistent view of the network independent of location.
Not all addresses can reach all other addresses, and that is something
we all need to live with.
true. but if for whatever reason the network cannot or is prohibited
from routing traffic between two points, it needs to be clear that it's
not the app's job to do so. expecting the app to be aware of network
topology, local policy, or whatever is not reasonable.
Right. But I argue it's reasonable to allow an administrator to configure
hosts with local policies, which the apps transparently inherit.
that's like arguing that it's reasonable to allow the administrator to unplug the machines from the mains and still expect the apps to work. sure enough, you can implement a policy of sorts by doing that - but it's a very crude mechanism. we can't stop admins from doing things like this, but that doesn't mean we should tell them that it's a good way to implement policy. (and an API won't help much)
An "obvious" security scheme for corporate networks is to block all packets
with local addresses at the firewall (as specified in the I-D)
which I-D is this? I've been ill for several months and not able to keep up.
but that's a REALLY, REALLY Bad Idea - one which needs to be thoroughly discredited.
and then
block access to server farms from non-local addresses (in case there's a
leak or misconfiguration at the firewall, and to simplify configuration and
auditing). Since the servers inside that farm will only have local
addresses themselves, it is logical to require any hosts contacting them use
local addresses as well. I welcome any suggestions on how to accomplish the
same goals without increasing overall complexity.
the method you're proposing is pretty complex already - it just puts the complexity in the hosts and apps (not only in having to implement the policy but in being expected to work around the resulting dysfunctionality)
if you must put policy in addresses, don't put it in the "local" vs. "global" bits - put it in the least significant bits of the subnet. that lets you write simple filtering rules at the routers without expecting apps to be contortionists.
here's the thing - it's rarely the case that an admin really wants to isolate a network or even a significant set of hosts. what the admin typically wants (if he'll take the time to think about it) is to let some apps traverse boundaries and other apps not traverse those boundaries. also, it's less and less often the case that the boundaries that an admin wants to enforce conveniently coincide with routers. of course admins try to arrange their networks that way, but there are constantly good reasons to make exceptions. meanwhile app writers are standing on their heads trying to make their apps work in the presence of arbitrary constraints imposed by network admins -- even when the network admins weren't trying to break those apps.
what this means to me is that we need to provide better tools for network admins to specify policy to apps and to enforce that policy in depth. but that's not the same thing as saying that we need to give network admins more tools for limiting which addresses a host or app can use.
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
