Buzz roundtable: Policy-based networking, 09/27/99

Policy-based networking

Network World Fusion, 09/27/99

Let's move on to policy-based networking. This is ability to set corporate policies for network and application access and for bandwidth privileges, to determine who or what applications get priority. There have been lots of issues raised as to whether implementing all these policies is worth the trouble, especially in the LAN where bandwidth is relatively cheap, or if it's even feasible in a multivendor network. So what's your take on policy-based networking? Is this an idea users should be trying to pursue?

Kobielus: What policy-based networking needs is very strong meta-directory capabilities across different environments. You need to have a master meta-directory that incorporates the NOS directory, the e-mail directory and all the other directories in use in an organization.

In terms of bringing the network transport QOS environment into it, you need to have connections into your backbone. Let's say you're using Cisco routers, you need to have a directory that encompasses all those router objects and links. And that directory needs to be part of the meta-directory environment. Whatever policy tools you have then need to tie in to those low-level physical internetworking objects. They also need to tie into the directories that control access to your corporate applications and databases and whatnot.

That's quite an effort, integrating all those systems. But policy-based networking is a laudable goal. It's another way of talking about permissions management and application security. But in terms of a general purpose policy networking infrastructure, it depends first and foremost on meta-directories and secondly it depends on public key infrastructure technologies. Neither of which – metadirectories or PKI –is widely deployed in enterprises yet. So these are big things to bite off and chew.

Nolle: Before you get to the implementation issues, you've got to address the value issue.That's where the major problem associated with policy based networking is. The problem is that if we make a directory or a policy networking environment relatively confined, then the benefit of the environment is so small that the expense of linking this with the equipment to bring about the changes that the directory is supposed to bring about really aren't justified.

On the other hand, if we expand the scope of policy based networking, for example into the QOS space, to open up the value proposition, we expose ourselves to a lot of complexity in terms of maintaining the policies. And we also expose ourselves to a lot of complexity with regard to the multivendor interpretation of directory contents. It seems to me like we're caught here in policy management. We can either dumb it down to the point where we can understand it, and then it's useless; or we can kind of ramp it up to the point where it's useful in which case we can't understand it. In neither case is the user very likely to do anything with it.

Bradner: The IETF has actually been working on policy based management and the policy schema in the quality of service and security areas for a while now and is certainly having trouble figuring out what exactly that means.

Kobielus: In policy based networking, one of the big hitches is the whole issue of certificates and how broad those certificates should be. Should you stick with standard x.509 certificates that simply identify a user or entity, or should you somehow also store attribute certificates that define various levels of access control, applying to particular users and entities. There are many people, including myself, who would argue that the best place to put dynamic information, such as access controls, is right in the directory where they're available to multiple applications. You don't want to have to revoke and reissue certificates if you can help it. When you're dealing with something as volatile as user permissions and privilege levels, that's an area where you would want to stick with just a basic identity certificate, put the permissions information in the directory and make that permissions information available generally to all applications.

Nolle: If we were to let the users listen to the last description here, which I agree with completely at a technical level, the interpretation of the average user is going to be that the cure of policy management is a lot worse than the disease is. I don't believe that a certificate gives any significantly better assurance of identity today, without the availability of smartcards, than passwords over a secure link.

Kearns: Let's not get caught up in the benefits or drawbacks of certificates. All we really need to specify here is an authentication method of some sort.

Bradner: I would agree.

Kearns: We've been talking about policy management in the security arena and the licensing arena for many years. It's not something new. It's just a new term that somebody invented when they tried to throw QOS in, which still really isn't defined very well. What we're talking about is extending the policy management and I have a feeling that, give it a year or two and we'll be down to calling it rules-based management where we apply rules to everybody's access to everything.

More of the roundtable