Re: Fwd: [Nea] Re: use of a design team to develop requirements
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Mike Fratto wrote:

> If the protocol can be designed that prevents open ended queries while
> still allowing queries,

  What kind of queries?  Do you have examples?

  And I still don't see why *any* queries are required.  Look at the
target deployments specified by the charter, the enterprise admin "owns"
the machines.  So there is *always* a way for that admin to inform the
machines off-line what information is required.  This can be done when
the machines are first configured, or as part of a remediation update.

  i.e. remediation updates inform the machines of updates to local site
policy.  Updates to virus scanners, etc. are just subsets of updates to
the local site policy.  The updates will also include statements sycg as
"install new software program X, and when you reconnect, tell me what it
says."

  Requiring queries in the NEA protocol looks to me like the intended
deployment scenarios are *outside* of the scenarios described in the
charter.

> Any protocol could be used for nefarious purposes. I don't think that
> there is need for alarm that the work of the NEA will be abused any
> more than any other protocol.

   Most network access protocols (PPP, DHCP, RADIUS, etc.) do NOT
support queries.  If the NEA protocol supports queries, it *will* be
abused more than protocols that do not support queries.

  That conclusion is inescapable: The more functionality exists in a
protocol, the more potential for abuse.  We should therefore be careful
to put only required functionality into NEA, and nothing more.

  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




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.