Ticking Away the Moments

(Errata Notice:  When I read the entries on Steve's blog, my eyes interpreted shanna as "Shanna;" and I incorrectly assumed that someone else at Juniper had posted an entry in Steve's blog.  I've corrected the entry below.  My apologies to Steve and my thanks to Chris Radkowski for pointing out my error.)

So, I've been in a discussion with Steve Hanna over on the Juniper NAC blog about the state of TNC NAC standards within the IETF (Steve's initial post that spurred my comment is here; his response post is here).  Network World's Tim Greene also had a newsletter item on the same topic.  Setting aside that Tim's view is necessarily more pessimistic than Steve's, there is no doubt in my mind that progress on the standards front is a good thing for all NAC vendors.  A rising tide that lifts all boats.  The strong-armed quarterback that completes the West Coast Offense.  The Turn card that completes the flush.  You get the idea.

Steve's initial post was around IETF's acceptance of the TNC client-server protocol definitions.  My follow-on question involved the progress, if any, of standards adoption for the enforcement pieces.  Steve's response was both helpful and encouraging, and I look forward to reading additional details as they come.  I'm not looking to minimize the importance of standardizing client-server communication within a NAC framework. However, we continue to impatiently tap our fingers waiting for a similar level of progress on the enforcement front.  The reasons for this are (a) it's "easier," at least politically, since there is broad agreement as to where enforcement should be done; and (b) enforcement puts the C in NAC, since there can be no control without enforcement.  As is obvious, NAC without the C just becomes NA.  Not an acronym (abbreviation, actually, but that's a whole other rant) that any of us wants.

Now, to be sure, every NAC vendor in the space claims "some" kind of enforcement capability, including Mirage.  And it remains more likely than not that at least some of these enforcement mechanisms remain relevant post standards adoption, for unmanaged assets if nothing else.  After all, whether you're talking about NAP, TNC, NEA or some kind of hybrid, the enforcement elements look pretty much the same, which is to say based around a RADIUS authentication handshake, which holds a two-fold assumption that the asset is (a)managed by the organization and (b) capable of running some kind of host-based software (VPN client, 802.1x supplicant).

Still, for that class of managed assets running host-based software, I don't believe there is significant disagreement that RADIUS extensions are the way to go.  RFC 3580 was great, in that it defined a standard way of providing VLAN assignment and port-based filters to connecting users according to the policy defined on the RADIUS server.  The missing piece is the ability to change those attributes post entry outside the context of an authentication handshake.  This is important not only for post-admission security but also for remediation, since remediation by definition changes the status of the endpoint.  By extending the traditional RADIUS Packet of Disconnect to be a more generic Change of Authorization, RFC 3576 fills this gap, seamlessly, across switching platforms, and for all connection methodologies (wired, wireless, VPN).

So, what's the holdup?  I honestly have no idea.  As Steve points out, RFC 3576 is 5 years old now.  5 years.  5.  Five.  Why hasn't the unknown-pantone-blend switching company (Are they gray?  Blue?  Green?  Pick one!) just gone ahead and implemented it?  It would sell more of their switches.  It would keep them a relevant player in the NAC arena irrespective of whatever else happens (see above).  And it's just the right answer.  My hope is that Juniper (now that they're in the switching business), along with maybe Enterasys, will provide the competitive push that is clearly necessary.  Hope is good.  Hope springs eternal.  Time, I suppose will tell us whether Hope fell down and sprained her ankle.  Let's just please make the time something less than another 5 years.