Subject: [Nea] REQ (-03) my comments

From: "Sanchez, Mauricio (ProCurve)" <[email-masked]>
Date: Mon, 23 Jul 2007 05:07:05 -0000

My comments of draft -03 of NEA requirements document:

Meta-comments
* NIT:  From the last version I reviewed (-01), I see most of the
document has moved away from using capitalization of nomenclature.
Section 5 is a notable exception.  However, there are still instances of
capitalization and even then the same keyword isn't capitalized
uniformly throughout the document.  For example, reference model is
capitalized in some sections, but not others.  I still personally
dislike capitalization of nomenclature.
* Why are remediation attributes defined as a class of attributes, yet
there is no intention of the WG to define any standard set?   The fact
that remediation attributes are described in various places of the
document somewhat sets the stage as if we are going to define some
standard set.

Abstract
* NIT: There's too many things in parenthesis.  IMO, should be used more
sparingly.  Something clear could be:

"This document defines the problem statement, scope and protocol
interface requirements between the components of the NEA (Network
Endpoint Assessment) reference model.  NEA provides owners of networks,
such as an enterprise offering remote access, a mechanism to  evaluate
the posture of a system.  This may take place during the  request for
network access and/or subsequently at any time while connected to the
network.  The learned posture information can then  be applied to a
variety of compliance oriented decisions.  The posture information is
useful for detecting systems that  are lacking or have out of date
security protective mechanisms, such as Anti-Virus  and host firewall
applications."

Section 1 - Introduction
* First sentence "...can leverage existing standards-based technologies"
Would be nice if document had references to some of the standards-based
technologies the NEA team had in mind when saying the statement.
* Second paragraph, first sentence: "...indicate appropriate remediation
actions to be taken"  Since the WG is not defining any remediation
attributes, how can this claim be made?  
* Second paragraph "Such a mechanism could offer a useful tool..."  What
mechanism is this sentence referring to? The previous sentence is about
the fact that the endpoint may still be vulnerable to threats that exist
on the network.
* Third paragraph "NEA typically involves the use of special client
software..." I don't see any reason why this claim needs to be made.
This is a requirements document, not one about NEA implementation -
there are none in existence. 
* NIT: Fourth paragraph, first sentence ("In many cases, the admission
decision...") The first paragraph talks about "access decisions" while
this paragraph talks about "admission decisions".  Is there a difference
between both. I don't believe so.  Document needs to be scrubbed to use
a common set of terms.

Section 3.1 scope
* NIT:  Second paragraph, bulleted-list:  First and second bullet should
have periods instead of commas.

Section 3.2 scope 
* Why make assertion of "special software".  I don't see it as special.
It's just additional software functionality required in the endpoint.
* NIT: second paragraph, first sentence:  Word "Network" should not be
capitalized.

Section 4 (Problem statement)
* NIT:  Paragraph 3: "out of scope" is usually not hyphenated. Consider
removing hyphens. 
* Paragraph 3 ("The decision of how to handle...") I question why the
document suggests any method (e.g. authentication) to deal with
non-compliant or non-participating endpoints.   We should point out the
problem, but not try to solve it here in this section. 
* Paragraph 6 ("NEA technology...") Why not add a reference to 802.1X?

Section 5 (Reference model)
* Why in the discussion of the reference model is there already
discussion about protocol design ("PA is likely a thin message wrapper
around a set of attributes...").  We've yet to evaluate any protocol,
why bias the reader now?
* NIT: second paragraph, second sentence ("PB is primarily is"):
Spurious "is" in sentence.  Need to delete. 
* NIT:  second paragraph, third sentence ("The vertical lines in the
model represent APIs...") I always like to spell out completely the
first usage of any acronym.  The acronym "API" is used here for the
first time and isn't spelled out completely.  

Section 5.1
* NIT: I spoke too early about the reduction in use of capitalization.
Section 5 has it everywhere.  Consider reducing usage.

Section 5.1.1 (NEA Client)
* "An NEA Client is not responsible for reporting on posture of entities
that might exist on the endpoint or over the network that are outside
the scope/visibility of the NEA Client."   I don't understand this
statement.  What is it trying to say?

Section 5.1.1.1 (Posture Collector)
* Last paragraph ("The above list describe the model's view of the
possible responsibilities...") - Why was this disclaimer added.  I don't
see it as being useful.  Moreover, the subsequent sections on other NEA
components don't include the same disclaimer. Consider removing. 

Section 5.2.1 (Posture Attribute Protocol)
* Second sentence ("The PA protocol is a message oriented lightweight
wrapper..."): Again, I don't see why we need to start specifying the
protocol in a requirements document.  Consider removing all such
discussion.

Seciton 5.2.3 (Posture Transport Protocol)
* Last sentence ("The PT protocol provides reliable message delivery,
mutual authentication and cryptographic protection..." "...as specified
by local policy.")  How is this statement to be interpreted, in
particular the "...as specified by local policy."  Would we always want
mutual authentication and reliable message delivery?  

Section 6.1
* NIT: Would help readability if Figure 2 was all on the same page.
When printing out the document, the figure is across two pages. 
* NIT: Second sentence ("Endpoints that have been...") Extremely wordy
sentence.  Took a couple passes to understand. Consider:

"Endpoints that have been recently assessed and for which the NEA Client
or Server has maintained state or proof that the endpoint is compliant
need not have their posture evaluated again. Therefore, this use case
does not apply."

Section 6.1.2.3 (Impact on requirements
* NIT: Inconsistent usage of periods for bulleted items. Consider
removal of period of bullet with one to be uniform across all bulleted
items in section.

Section 7 (Requirements)
* Second paragraph: Why is there the huge security loophole to allow
implementers to arbitrarily choose whether to implement security
measures we specify to be part of the protocol.  Seems counter-intuitive
to the desire to have secure protocols by default.

Section 7.1 (Common Protocol Requirements)
* C-2:  What is "normal" network access?  What if an endpoint is only
given "limited" network access, which presumably is not "normal"?  Does
this requirement not apply?
* C-5:  Add references to EAP, PANA, IKE standards in references
section.
* C-7, C-8, C-9:  All these requirements refer to a qualitative "large"
for scalability needs.  Just how large is "large"?  Tens? Hundreds?
Thousands? Millions large?
* C-10: For which assessments modes will we require that proposed
protocols have the ability to exchange just a little information?

Section 7.2 
* PA-8: Isn't there already an IETF spec'ed encoding standard that most
protocols refer to? If so, maybe add reference here explicitly.

Section 7.3
* PB-4: What's the rationale behind having put this as a MAY instead of
SHOULD or even MUST?

Section 7.4
* First paragraph: I believe this is the first reference to RADIUS.
Consider adding reference to RADIUS RFC in reference section and using
here.
* PT-1; NIT: Missing period.
* PT-4:  Why no authentication as a requirement to integrity and
confidentiality.

Section 8.1.1
* NIT: Add reference to Trusted Computing Group to reference section and
add here.  

Section 9.1 (Implementer Considerations)
* Second paragraph ("The opt-in mechanism...") Why would the opt-in
mechanism not also be available on a per-network access basis?  

Cheers,
MS
-------------------------------------------- 
Mauricio Sanchez, CISSP 
Chief Security Architect 

ProCurve Networking by HP 
Hewlett Packard 
8000 Foothills Boulevard, ms 5541
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