• United States
by Joel Snyder, Network World Test Alliance

NAC competition: Juniper’s Infranet

Apr 03, 20064 mins
AuthenticationIdentity Management SolutionsNetwork Security

Focuses on firewall, access control, with less emphasis on endpoint security.

Although it is possible to map the basic components in the Juniper Infranet to TCG’s Trusted Network Connect architecture, the reality is that Juniper is trying to accomplish very different things, focusing on firewall and access control, with less emphasis on endpoint security.

Juniper breaks from other vendor’s NAC architectures in the amount of control that it gives the network manager when building a NAC infrastructure. Juniper’s strategy is very dependent on both authentication and on detailed access control using its firewalls. The result is that when someone enters a network under Juniper’s NAC control, every connection goes through a stateful packet-filtering firewall, can be encrypted and is explicitly tied to an access-control policy based on a user’s identity.

For example, when a system enters a network under Microsoft Network Access Protection with , the main concern is whether the user has the appropriate level of endpoint security. If so, the user is given unlimited access to the network. With Juniper’s Infranet, the endpoint-security assessment of the user is optional, but the identity-based access-control policy is not.

This philosophical difference has one benefit: It makes it easier to decide whether the Juniper approach is right for you, and whether this level of authentication, security and access control is what you’re looking for – or whether you mostly care about endpoint-security assessments.

On the client end, Juniper uses its Enterprise Infranet Agent as the focal point for client management. The Infranet Agent links to third-party TCG Integrity Measurement Collectors using its own JEDI API. Juniper also provides endpoint-security assessment tools – a feature of its called Host Checker – for checking endpoint status, such as open ports or running processes.

Because the user is assumed by Infranet’s architecture to already have connected to the network, the Infranet Agent doesn’t participate in Layer 2 authentication schemes, such as . Instead, the Infranet Agent’s role is to provide user authentication to the Policy Enforcement Point deeper in the network and the endpoint-security assessment information back to the Policy Decision Point, dubbed Infranet Controllers.

Juniper’s firewall and SSL VPN products, called Infranet Enforcers, act as the Policy Enforcement Points and are typically located deep within the network.

The Infranet Agent also manages encryption between the end system and the Infranet Enforcer Policy Enforcement Point. By applying encryption between the client and the Infranet Enforcer, Juniper offers strong binding between the end station, its authentication and the applied policy. This security starts only at the Policy Enforcement Point; any misbehavior by the client before it reaches the Infranet Enforcer is uncontrolled in the Juniper Infranet model.

Juniper’s Infranet Controllers, akin to the TCG’s Policy Decision Points, are based closely on Juniper’s SSL VPN product line, as both use the same policy engine.

Unlike other NAC architectures, Juniper’s Policy Decision Points don’t have a clear link between the Integrity Measurement Verifiers, which evaluate endpoint-security information from the Juniper Host Checker (acting as the Integrity Measurement Collector in the TCG scheme) and give a policy decision back to the Infranet Controller.

Instead, the Infranet architecture waves away the question of how Integrity Measurement Collectors can pass information to the Integrity Measurement Verifiers within the Policy Decision Point by pointing off to the JEDI specification. In reality, the JEDI specifications are mute on how this link will work. This is a weak point in the Infranet architecture, because management of desktop and roaming user policy has to be handled once in whatever enterprise console is used to control the third-party security tool and then a second time within the Infranet Controller environment.

Choosing a NAC architecture depends on your goals and your integration strategy. If you’re an all-Cisco shop with modern hardware, you can hitch your horse to Cisco’s architecture, which is as complete as anyone’s.

For those interested in standards-based solutions, TCG’s TNC is the only real option despite some risk. Microsoft’s approach is most appropriate in smaller networks where you want to control the PCs you already own and are most concerned about viruses rather than authentication and access control.

Next: A NAC primer >