Sean Convery

Since so many other bloggers are having fun sticking their necks on the line with New Year’s predictions, how can I resist? There’s something about appearing sage–while knowing you can’t get called on your mistakes for 12 months–that is fundamentally appealing. Here are my predictions for 2007. Some of them are somewhat difficult to measure so I’m hoping to get some help from my readers this time next year on how I did. I’d love to see your own predictions as well in the comments to this post.

1. NAC as a term will grow out of favor as NAC teeters on the brink of Gartner’s “Trough of Disillusionment.” This one seems quite likely given that we have already seen a bit of NAC backlash. I can see this going a couple ways. First, rather than the NAC term completely going away I can see it surviving with qualifiers such as “Identity-based NAC.” Another option is that the term itself is completely replaced with something either more generic, or more specific such as network identity management or role-based access control.
2. One of today’s NAC vendors will go under. I don’t see how the market can sustain so many players, especially given that some have seen many rounds of funding and have already retooled their products once to chase the NAC wave. I won’t list all the NAC vendors here but there are easily 15 or more.
3. So that I’m not all doom and gloom, one of today’s NAC vendors will get acquired by a larger firm. Whether the NAC term survives or not, the functionality of NAC–in its broadest definition–is useful to organizations. There are plenty of players who need that functionality in their product portfolio. My guess is a networking player will do the buying. I won’t get into whether the acquisition will be from a position of strength or as a result of the NAC vendor running out of cash, but it is fair to say that both appear feasible.
4. An open-source 802.1X supplicant will emerge as a viable alternative to commercial and OS-native supplicants. So that I don’t give myself any wiggle room here, this doesn’t mean that one is available to download, but rather that organizations are deploying it at scale. I think the market can’t help but make this happen since the OS supplicants are lacking and the commercial supplicants are simply too expensive. Think of the market forces that created Firefox when Internet Explorer wasn’t getting the job done; I think we’ll see something similar here.
5. 2007 is the year wired 802.1X turns the corner from rare occurrence to early-adopter chic. While it won’t be mainstream by any means (that label will belong to wireless 802.1X) it will see substantially more deployment than in 2006.

Technorati Tags: 802.1X, NAC, Supplicant

Back in June I wrote about a new draft in the IETF RADEXT working group concerning access control lists (ACLs). The draft specified a way to generically format and transmit IP ACLs using RADIUS. The draft is now in its sixth revision and left the working group headed towards a proposed standard in the IETF. If approved, we will finally have a common technique for passing ACLs to a network enforcement device from a AAA server. The approach taken in this draft is to reuse the filter format defined within Diameter (scroll down to page 44 to see the format). To date, enforcement vendors have either relied on proprietary techniques for formatting these ACLs or have simply not supported them. It is very common today to see no support for the specific ACL but a more general support for the RADIUS Filter-Id attribute (attribute 11, page 35). The Filter-Id attribute is nice but it only allows the AAA server to point to a pre-existing filter on the enforcement device, not to create one on the AAA server.

The key, if approved, will be getting the enforcement vendors to support the new standard. Since HP authored the draft It seems quite likely that HP will support the capability. If Cisco and Juniper follow suit it would be great news for customers struggling with network level authorizations throughout a heterogeneous network. My guess is customer pressure will be instrumental in getting the big guys on board. Pairing this functionality with network-wide authentication and some basic NAC checks and you’ve suddenly got a heterogeneous solution which hangs together quite nicely. Heck, toss in RFC 3576 support and you’ll really be onto something.

Technorati Tags: 802.1X, NAC, RADIUS

Apologies for the TCP humor.

An interesting article at Network World points to an analyst report from TheInfoPro about NAC. The report, due out next month, shows that “of 126 network professionals, 37% say it is very likely or extremely likely they will decide to develop or implement a NAC policy initiative in the next 12 months, down 17% from earlier this year.” Reasons cited include a lack of standards, high cost, and the lack of a universal endpoint agent.

I always had a sense that NAC–as narrowly defined under the endpoint health banner–might find the “trough of disillusionment” (as Gartner describes it) earlier than expected. With so much hype, so little standards, and so many vendors piling on with solutions it seems almost inevitable. Much of my talks with customers, at conferences, and in posts on this blog have encouraged caution in approaching this problem space so quickly–and so narrowly focused on endpoint health.

Making user identity decisions at the time of network access is a much more proven technology since it has been used to augment the security of dial-up, VPN, and wireless networks at scale. Adding wired access to the authentication solution makes it possible to make access decisions for all forms of network access in a consistent way. Sure wired 802.1X is encountering its own growing pains, but vendors have responded by enabling simpler alternate mechanisms–such as web authentication–to bootstrap wired deployments until 802.1X is truly plug-and-play. It will be interesting to see how this plays out over time.

Technorati Tags: NAC