Tawnee Kendall and I sat down and recorded this video on Interop 2008. Check it out!

In a comment on my last post, Grant Hartline wrote:

I’m happy to see the movement towards unification of standards and appreciate all of the effort you’ve put into NAC standards adoption, both within the TCG and the IETF. However, one TNC standard that is conspicuous in its absence is IF-PEP. Is there an IETF working group that may pull in IF-PEP for the purposes of triggering enforcement actions? Alternatively, or at least in the meantime, do you see any movement within what we’ll call “the industry” on adoption of RFC 3576 within Ethernet switches?

Let me answer some of Grant’s questions here. First, bit of background. IF-PEP is the TNC’s standard way for a Policy Decision Point (PDP) to send instructions to a Policy Enforcement Point (PEP). Those instructions might be “put this user on a quarantine VLAN”, for example. The TNC standard for IF-PEP is currently IF-PEP for RADIUS 1.1.

To answer Grant’s first question, there is in fact an IETF WG that works on this protocol. It’s the RADEXT (RADIUS Extensions) Working Group. If you look at IF-PEP for RADIUS, you’ll see that it cites a bunch of IETF RFCs. In fact, most of the TCG spec is just “use IETF RFC 3580 in this way” and things like that. So the IETF is already on board with IF-PEP for RADIUS. That’s one reason why TNC is so compatible with existing networking gear. RADIUS has been around for more than ten years. All enterprise grade switches and wireless access points support it, also many VPN gateways and things like that. There was no reason for TNC to reinvent the wheel. Reusing the existing IETF protocols provided maximum compatibility.

Grant’s second question is whether there’s any movement on adoption of RFC 3576 in Ethernet switches. For those who aren’t totally up on their RFC numbers, RFC 3576 describes how a PDP can send real-time updates to previous enforcement instructions to a PEP. For example, “please move that user out of the quarantine VLAN onto the production VLAN”.

RFC 3576 is about five years old and it has not been widely implemented by switch vendors to date. This is a shame because it makes it hard for a PDP to move users around as conditions change (change in user privileges or endpoint health, change in policy, etc.). The usual ways to handle this are to use another way to send the updates (SNMP or CLI), have the PDP ask the endpoint to request reauthentication from the switch, or configure the switches with a short reauthentication timeout. None of these are ideal. The first is proprietary and unreliable. The second depends on the endpoint to behave nicely. And the third is inefficient. Implementing RFC 3576 (also known as CoA for Change of Authorization) is clearly the way to go.

I have heard that a lot of switch vendors are moving now to implement RFC 3576. I want to provide a more complete answer for Grant so I’m going to do some research on this. I’ll submit another blog posting in a week or so with more information. If anyone has info on this topic, please post it as a comment. Links to data sheets would be ideal.

Thanks!

Are you interested in Network Access Control (NAC)? Want to learn more about it? Well, you’ve come to the right place. This blog is all about NAC - all NAC, all the time.

I’ll cover everything related to NAC: technology, products, standards, news, reviews, and so on. Anything that’s new and interesting in the NAC world is fair game. But I also want to go beyond news and look at the deeper issues behind NAC. Are standards important? What benefits do NAC systems really provide? Are they worth the effort?

I’ll try to take a vendor-neutral perspective. That’s my role in the industry. I’m the NAC standards guy. But I’m not going to sugarcoat things. I’ll give you my honest opinion. That’s what blogs are all about.