Keith Moore <moore@xxxxxxxxxx> wrote:
> That seems overbroad, in particular because a laptop that connects to
> multiple networks cannot in general be expected to adhere to conflicting
> policies of the networks to which it connects.
Exactly. That's why there are provisions for non-conforming
systems. Network access can be denied entirely, or limited to the
public (and unprotected) network. However, 99% of systems don't move
networks, so those systems don't have a problem conforming to the
local requirements.
> As far as I can tell, this is the crux of the problem with NEA - that in
> general it's simply unreasonable for a network to demand that every host
> that connect to it conform to arbitrary policies for configuration of
> those hosts.
I'm not sure how to take this. It's unreasonable... OK, why? Is it
unreasonable for me to require that I know which machines are on my
network, or to deny access to machines I don't own? Given the
remediation options outlined above, what part of controlling network
access for unknown machines is unreasonable?
> The other problem I have with this charter is one that I have with many
> charters these days - it presupposes a particular design or architecture
> before the working group has actually met, when this should be an
> engineering decision taken by the consensus of the working group AFTER
> analysis of the problem space.
I think it presupposes a particular problem, not an architecture.
The problem is:
a) knowing who is on my network
b) controlling who is on my network
c) controlling the behavior of the hosts on my network.
If any of those problems are unreasonable to solve, then I would be
*very* confused.
The proposed NEA architecture derives directly from that problem
statement. The *only* assumptions I see are:
a) It's a good idea to know who's on my network
b) It's a good idea for me to control who is on my network
c) It's a good idea for me to control the behavior of hosts
on my network
d) all of the above is possible to implement
e) Step (d) should be standardized
Alan DeKok.
--
http://deployingradius.com - The web site of the book
http://deployingradius.com/blog/ - The blog
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf