![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
On Dec 18, 2006, at 12:29 PM, Alan DeKok wrote:
I have assumed that the network could require information to allow access. The user could also refuse to provided certain information. The result on the network side might be to allow only access to a remediation network. The result on the user side might be to only allow the user to connect to a particular web site. The point is that policy exists at both places.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.
The value of queries to at least some people is the reason for the wg.
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
_______________________________________________ Nea mailing list Nea at ietf.org https://www1.ietf.org/mailman/listinfo/nea