Wherefore art thou TCG IF-MAP?

This all started, as many things do, with an article by Hoff wherein this idea was posed.

I’m really interested in how many vendors outside of the NAC space are including IF-MAP in their roadmaps. While IF-MAP has potential in convential non-virtualized infrastructure, I see a tremendous need for it in our move to Infrastructure 2.0 with virtualization and Cloud Computing.

Integrating, for example, IF-MAP with VM-Introspection capabilities (in VMsafe, XenAccess, etc.) would be fantastic as you could tie the control planes of the hypervisors, management infrastructure, and provisioning/governance engines with that of security and compliance in near-time.

So, of course, a response was crafted by NACMeister Alan Shimel who thoughtfully sets Hoff straight on the state of TCG/TNC adoption by NAC vendors, explaining it this way.

I think very few vendors are actually supporting and have implemented it. In fact it is not just non-NAC vendors, it is NAC vendors as well. Other than Juniper, I am not aware of another NAC vendor who actually supports MAP yet. Not because we don’t want to, it is just not important enough. Customers have not demanded it. So no one has the cycles to spend on it.

And predictably Steve Hanna fired back with this explanation of the TNC adoption curve.

I have found that standards adoption follows the classic innovation adoption lifecycle. Innovators are the vendors and customers that have the vision and foresight to see where things must go. They are the first to create and adopt new technology. Next come Early Adopters, Early Majority, Late Majority, and Laggards. It takes at least a year for each stage: six months to turn prototypes into products and six months for the next generation of adopters to catch on. That’s the timescale we’ve seen for the other TNC standards. So I expect to see Innovator vendors shipping products that implement IF-MAP in the next few months and Innovator customers deploying those products in the months after that.  Then will come Early Adopters and so on.

So clearly I couldn’t let this topic slide by untarnished by my view from the NAC trenches.

In principle I don’t disagree with anybody here. I mean as a card-carrying member of the group who would enjoy the most benefit from adoption of TCG/TNC – NAC software developers – what’s not to like? A standard. Everybody being able to interoperate. Not having to design one-off protocols to allow your own products to interoperate. Reverend Hanna, you are preaching to the choir – say Amen!

But Alan’s point about customers not demanding it is the nasty thing floating in the TCG/TNC NAC adoption koolaid punch bowl. However I think the reason for this lack of demand is more problematic than “it simply hasn’t hit the customer’s radar”. Given that TNC’s raison d’être is to allow different vendors’ products to interoperate such that a customer could integrate new stuff into an existing environment or do a “best of breed” grab bag for a complete NAC solution; and given that implementing a real, working NAC solution is, shall we say, non-trivial; I don’t see customers clamoring for this feature any time soon. I mean, it is challenging enough to get a single vendor’s NAC solution working in your environment even with copious amounts of support from that vendor. It makes me queasy to even think about trying to make multiple competing NAC vendors’ stuff play nice. Much less actually work. Cage match maybe, NAC solution not so much.

So I’m thinking that Hoff’s ideas may actually help TCG/TNC adoption get traction quicker than the NAC purveyors it was intended to corral into a single herd. Because at the end of the day, I don’t really think customers give a rodent’s patoot whether or not your NAC product implements an industry standard. They just want NAC with the least amount of pain and suffering. If and when we can make TCG/TNC the agent of that blessed relief, then it will be.

So say we all.