Subject: [Nea] REQ: section 9 comments

From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
Date: Mon, 26 Feb 2007 02:28:00 -0000

Section 9 comments:

1. Section 9.2, second paragraph,  "If deployer wishes to support Endpoint
Assessment without a NEA client..." sentence.  Two comments on this.  

First comment is that up until this point the document has never mentioned
the possibility that NEA can be deployed without a client.  Are clientless
NEA deployments within scope of NEA WG?  If so, then the reference model,
use cases, and requirement section need elaboration with respects to
clientless deployments.  

Second comment is that if NEA is going to make the claim that clientless
deployments can improve privacy, there should be additional discussion as to
how exactly privacy is improved.  It's just too tantalizing of a claim to
leave in a vague state. 

NITS
a. Section 9.1, fourth paragraph, last sentence has an awkward structure.
There's a "that a that which" that needs cleaning up. 
b. Section 9.2, fourth paragraph, second sentence.  The word "Attribute"
should be plural form ("Attributes").
c. Section 9.2, fifth paragraph, second sentence.  Change "...to the policy
being provision" to "...to the policy being provisioned".

Cheers,
MS

--------------------------------------------
Mauricio Sanchez, CISSP
Network Security Architect
ProCurve Networking Business
Hewlett Packard
8000 Foothills Boulevard, ms 5557
Roseville CA, 95747-5557

916.785.1910 Tel
916.785.1815 Fax
[email-masked]
--------------------------------------------   

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: "Paul Sangster" <[email-masked]>
Date: Mon, 26 Feb 2007 20:21:11 -0800

Changing subjects in hopes of a thread emerging... 

> -----Original Message-----
> From: Sanchez, Mauricio (ProCurve) [mailto:[email-masked]] 
> Sent: Sunday, February 25, 2007 6:28 PM
> To: [email-masked]
> Subject: [Nea] REQ: section 9 comments
> 
> Section 9 comments:
> 
> 1. Section 9.2, second paragraph,  "If deployer wishes to 
> support Endpoint Assessment without a NEA client..." 
> sentence.  Two comments on this.  
> 
> First comment is that up until this point the document has 
> never mentioned the possibility that NEA can be deployed 
> without a client.  Are clientless NEA deployments within 
> scope of NEA WG?  If so, then the reference model, use cases, 
> and requirement section need elaboration with respects to 
> clientless deployments. 

Thanks for asking this.  We had planned to raise this at the WG meeting
and on the alias soon.  What do folks think about this?  The design team
discussed it at length and decided we should ask the WG.

The downside of including clientless is that the NEA Client components
wouldn't be running on the Endpoint which is confusing and would require
us to do a lot of rewording (likely remaining confusing.)  The upside is
this has better privacy properties and reflects real world situations
where no NEA Client is running on the Endpoint.  However some of these
common cases may not be in scope for NEA (visitor who Owns her laptop
and does not wish to consent to an invasive assessment when joining a
network ...)
 
> 
> Second comment is that if NEA is going to make the claim that 
> clientless deployments can improve privacy, there should be 
> additional discussion as to how exactly privacy is improved.  
> It's just too tantalizing of a claim to leave in a vague state.

Ok.  Based on what the WG thinks we should do here we'll address your
comments (likely in -03.)
 
> c. Section 9.2, fifth paragraph, second sentence.  Change 
> "...to the policy being provision" to "...to the policy being 
> provisioned".

Thanks

---

From: Alan DeKok <[email-masked]>
Date: Tue, 27 Feb 2007 10:45:52 +0100

> discussed it at length and decided we should ask the WG.

  Clientless endpoints were discussed at length on this list from
October to January.  Little of that discussion made it into the draft.

http://www1.ietf.org/mail-archive/web/nea/current/msg00519.html
http://www1.ietf.org/mail-archive/web/nea/current/msg00485.html
http://www1.ietf.org/mail-archive/web/nea/current/msg00446.html

  In addition, the concept of "clientless endpoints" MUST also include
endpoints which might be running NEA client software, but which choose
to not participate in NEA on the current network.  The idea that some
clients might not participate in NEA doesn't appear to be addressed in
the draft.  (A quick scan for "choose" or "choice" or "participate" or
"quarantine" yields nothing relevant.)  In my mind, this is a major flaw
not only with the draft, but with the assumptions that underly it.

  We have to assume that for the first while that ALMOST ALL endpoints
will not be running NEA software.  If NEA chooses to ignore that problem
completely (as the current draft does), then it's utility will be minimal.

  As noted in the messages pointed to above, there is a significant
amount of endpoint assessment that can be done by using information
already available in existing protocols.  The NEA operational model MUST
address clientless enpoints, it MUST address what decisions can be made
about those endpoints, and it MUST address what happens to endpoints
that choose to not participate in NEA.

> us to do a lot of rewording (likely remaining confusing.)

  I don't understand what the difficulty is.

 a) clientless endpoints get policy X
 b) participating endpoints get policy Y.

  i.e. Clients have a set of attributes indicating current posture.
That set MAY be empty.

>  The upside is

  If the NEA documents are silent on those issues, then the design is
ignoring clientless endpoints, which makes NEA nearly useless.

 The requirements document would be made stronger if the authors
reviewed the discussions from last fall, and integrated conclusions and
scenarios from then into the draft.  I've given as much feedback as I
can, but I'm reluctant to re-type all of those messages again, and tie
them into specific areas of the draft.

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