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

[Keith Moore <moore at cs.utk.edu>]

> >   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  :)

Why in the world should IETF standardize a protocol that enables
networks to impose whatever policies they wish on hosts, given that we
already understand how this could be harmful to the Internet and
counter to IETF's organizational goals?

> 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. 

Perhaps, but that doesn't justify IETF's endorsement of such practices.

> 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.

Interoperability is not always a good thing.  Making it easier for
networks to impose draconinan and intrustive policies on hosts that
they do not own is not consistent with IETF goals.  NEA either needs to
be fixed so that it balances risk between host, user, and network, or
it needs to be taken out of IETF.

Keith


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