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

[Alan DeKok <aland at deployingradius.com>]

Mike Fratto wrote:

> Alan, this needs to be generalized to something like "products must
> have configurable actions based on posture assessment"

  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.  Once those requirements are quantified,
we can then move on to describing the requirements that the end hosts
have to meet in order to satisfy the larger objectives.

  According to the charter, this is part of what the requirements
document is supposed to cover.  Since there were concerns raised about
the openness of the process, I would like to see a public discussion here.

  If there is no public discussion about the requirements, then the WG
members are saying they have no opinion about the requirements, and that
 we should just rubber-stamp whatever document is produced by the
requirements team.

> For example, I think it is critical:
> 
> 1) that a set of basic attributes such as MAC, IP, and NEA client
> time, be defined that MUST be exchanged between a NEA client and NEA
> server

  To what end?  I'm not being facetious here.  The charter indicates
that the requirements document should include a problem statement.  We
should discuss that before talking about attributes and solutions.

  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.

  The invasive "scan your machine" system that Keith is rightly worried
about is a poor proxy for statement (2).  i.e. It's hard to put content
scanners everywhere in the network, to prevent bad behavior, so the next
best thing is to ensure that all the machines have patchlevel X, because
we know it's not vulnerable to an attack which as a side effect produces
bad behavior.

  To put it another way, it doesn't matter much if a machine is
vulnerable to an attack, so long as that attack is never executed.

  Many of the claimed NEA benefits about controlling network access can
be achieved by leveraging information that's already in the network, but
which isn't being looked at or used.  Many more of the NEA benefits
about protecting the network can be achieved by running IDS machines, or
by traffic filtering on the switch/router.  And other NEA benefits about
controlling the remote machine can be obtained by running the vulnerable
OS's in a VMware image, on a host OS that is much less vulnerable.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog

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