Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)

"Alan DeKok" <aland@deployingradius.com> Fri, 27 October 2006 12:50 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdRA2-0004eM-FH; Fri, 27 Oct 2006 08:50:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPJ3-0000Kl-Bz; Tue, 24 Oct 2006 12:39:13 -0400
Received: from newgiles.striker.ottawa.on.ca ([205.150.200.131] helo=mail.nitros9.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcPIy-00006C-V3; Tue, 24 Oct 2006 12:39:13 -0400
Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 9D7B616E1C; Tue, 24 Oct 2006 12:28:33 -0400 (EDT)
From: Alan DeKok <aland@deployingradius.com>
To: Keith Moore <moore@cs.utk.edu>
In-Reply-To: Your message of "Tue, 24 Oct 2006 08:25:45 EDT." <453E0649.2000503@cs.utk.edu>
Date: Tue, 24 Oct 2006 12:28:33 -0400
Message-Id: <20061024162833.9D7B616E1C@mail.nitros9.org>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
X-Mailman-Approved-At: Fri, 27 Oct 2006 08:50:03 -0400
Cc: nea@ietf.org, iesg@ietf.org, ietf@ietf.org
Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

Keith Moore <moore@cs.utk.edu> 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 mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf