Re: Fwd: [Nea] Re: use of a design team to develop requirements

["Mike Fratto" <mfratto at gmail.com>]

>   That statement is already assuming a host of requirements and
> functionality.  My intent was to describe the *administrators*
> requirements for controlling network access, independent of the
> capabilities of the end hosts.

Ok, I am not going to act as charter police, but what you are
describing is a matter local policy and a matter of deployed
infrastructure regarding both assessment and enforcement. Maybe I am
wrong about that, but I don't think so. ha-ha  :)

>   My $0.02 for a problem statement is that administrators want to know:
>
> 1) who is on their network (users/machines)
> 2) that those users/machines engage in behavior that is mutually agreed
> to by the users and network administrators.

I think your problem statement is too specific and really is kind of
obvious. Organizations are assessing, piloting, and deploying network
access control solutions today and in the next year or so. That is
happening regardless of what happens in this, or any, group. But I
think the problem statement that NAC address (from talking to those
very same organizations) more generally comes down to the following:

Network owners want to control access to network resources based on a
one or more factors such as (this is NOT an exhaustive list), MAC
address, IP address, location, time of day, host configuration,
assessment of installed applicaitons, assessment of running
applications, determination of whether the host is known or unknown,
and operating system patch levels and network owners want
interoperable products that will grant host assessment, remeidation,
and enforcement. In short, network owners want the tools that will
allow them to enforce a policy they deem appropriate for thier
network. That is the problem NAC attempts to solve (for better or
worse, that is also debateable)

Making the resonable asusmption that NAC is being deployed, the
problem with the NAC market today is that there are three competing
frameworks, Cisco Network Admission Contron, Microsoft Network Access
Protection, and the Trusted Computing Group Trusted Network Connect.
Cisco and Microsoft have announced interoperabilty plans, but neither
interperate with TNC. That means there is a very real possibility that
the market will continue to be fractured and that means interoperation
will be  impossible and that hurts organizations deploying NAC. If
your chosen products don't conform with a specific framework, then
you're SoL. For example, if a host attempts to access the network, but
their host software can't be assessed because it does not interoperate
with the assessment tool, that is a problem. That is a very differnet
problem than a host denying an assessment transmitted through an
agreed upon protocol.

So the problem really comes down to getting the different frameworks
to interoperate and also to allow other products to interoperate
regarding host assessment. That leads me back to my short bullet list
which addresses what the protocols should support.

mike

_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea