[Nea] Comments on NEA Problem statement

["Sanchez, Mauricio (PNB Roseville)" <mauricio.sanchez at hp.com>]

Finally had some time to look through the problem statement.  It's a
good start.  Look forwarding to working with the team to get this one
going...


Substantive comment #1: 
------------------------

We may want to reconsider the problem statement of NEA [section 3].
While I do agree there's a general endpoint integrity/posture problem
and solution, I don't agree that it is NEA's goal to solve this.  I see
the problem that NEA is trying to solve as one of interoperability, not
of functionality.  Customer's already have a functional solution for the
endpoint integrity/posture problem.  There is actually more than one
solution - I can think of three: Trusted Computing Group's Trusted
Network Connect, Cisco's Network Admission Control, and Microsoft's
Network Access Protection.  The problem with these solutions is that
they are not at all interoperable. This is where I see NEA providing
value by making some strides towards interoperability.

We have to be careful on pinning down the scope of NEA.  The document
tends to mix together the desire to make existing architectures more
interoperable through common protocols, but also takes the stance that
NEA *will* support a number of diverse goals [section 4] that may or may
not already be supported in existing architectures (i.e.).  My opinion
is the NEA should focus on assisting interoperability of what has
already been defined in existing architectures and leave the rest for a
different effort (or at least as a future goal and not an immediate
one). 

Moreover, the document spends a substantial amount of time creating new
nomenclature and describing a new generalized architecture, even though
it states up front [section 1] that it is not the intention of NEA to
create a new framework.  It seems that sections 2 through 6 have just
done that and do not reference in any implicit or explicit manner
existing architectures/efforts.  My suggestion on these sections would
be that they be more inclusive of existing architectures and discuss
from the perspective that we have existing solutions to the endpoint
integrity/posture problem, but they are currently incompatible and
non-interoperable due to differing use of protocols and protocol
bindings. 

What I see to be the real aim of NEA only shows up until section 7
(scope of standardization).  This section is good and could be improved
by describing how existing architectures would benefit from having these
interfaces standardized.  

Speaking of interfaces... It is probably a misnomer to call NEA a
standardization of various interfaces.  I see the work being more one of
standardization of protocol and/or protocol bindings. The term interface
may be construed as meaning API's , which should not be the intention. 

Substantive comment #2: 
-----------------------
Role of trusted computing technology is not highlighted in any form.
Although it shouldn't be mentioned as a normative reference, it should
be brought in a way that has it as an informative reference.

NITS of current draft
---------------------
-Some of terminology not intuitive. 
* NEA describes in its most basic form a client-server architecture. The
NEA server is called out appropriately as a server.  Why not do the same
for the NEA agent by calling it the NEA client, instead?
* It didn't strike me that 'NEA agent plug-ins' and 'NEA posture
servers' are peers.  
* Perhaps following nomencalture changes? 
	
	Old			New
	NEA agent		NEA client
	NEA agent broker	NEA client broker
	NEA agent plug-in	NEA posture collector
	NEA posture server    NEA posture validator
	All other remain same 
-The fact that there may be multiple NEA plug-ins should be called out
uniformly across the document.  Section 2 does state that there may be
multiple plug-ins, but Figure 1 and other sections of the document are
not clear on this fact. 
-Can there be multiple NEA agent brokers, access requestors, access
authorities, or server brokers?
-802.1X is spelled with a capital 'X'.  

Section 1
-Fourth paragraph: Document never mentions by name the several existing
architectures in existence. I can think of three - TCG's Trusted Network
Connect (TNC), Cisco's Network Admissions Control (NAC), and Microsoft's
Network Access Protection (NAP).  Document should go on describe each
architecture's relationship to generalized NEA architecture. 

Figure 1
-Figure should show a plurality of NEA plug-ins and posture servers. 
-'NEA Plug-in' label should be 'NEA Agent Plug-in' for correctness. 

Section 2
Some definitions unclear.  Details below:
*	NEA server : Is it just processing the posture information
collected by the NEA agent?  If so, the definition should call this out
since it's not clear what "...assesses the posture of endpoint" actually
entails. 
*	Network enforcer: Probably would be better to say that the
network enforcer "enforces" the authorization decision than "implement"
*	Network access authority: Missing period at end of definition. 

Section 5
This section should be written from the perspective of what current
architectures support. Have to find the common use cases, which then
serve to guide what the scope of NEA should be. 

Section 5.1
Paragraph 2: Section 4 does not call out that NEA will explicitly
support single or multiple hosts per switch.  Again, considering whether
support for this goal should be included should be predicated on what
existing architectures support. 

Section 5.4
Third paragraph: It is unclear whether NEA intends to support multiple
network enforcers along a given network path.  This paragraph points out
the possibility, but doesn't state whether this is a supported use case.
If it is a supported use case, it should be highlighted in section 4.
Again, considering whether support for this goal should be included
should be predicated on what existing architectures support. 

Section 6.1
This section needs additional elaboration.  Just how does NEA relate to
EAP and AAA architectures?  References would be nice.

Section 6.2
Seems to duplicate a lot of the terminology already defined in section
2.  

Section 6.2.2
Possibly think of changing 'implements' to 'enforces'

Section 6.2.3
"...(which may or may not be co-located on a single server)."   Why is
this fact important to mention here?  If they are not, then it raises
the question of whether additional protocol needs are raised.   Again,
perhaps tying back to existing architectures would drive whether this
statement needs to be made.

Section 6.2.3.1
a. Missing period at end of paragraph.
b. Who is makes the posture assessment?  Where does the assessment
decision come from?  (I assume it's the NEA server broker and if so,
probably should be explicitly stated). 

Section 6.2.3.2
What happens to the server broker's assessment result?

Section 6.3.5.
This seems like a catch-all section. Consider removing. It doesn't add
clarity to the problem statement nor work scope to say that there may be
"other" interfaces without a clear reason why they need to be mentioned
in the first place.  Again, perhaps tying back to existing architectures
and showing some examples of "other" interfaces would drive whether this
statement needs to be made. 

Section 6.4
What are your thoughts on what will go into this section?

Section 7
-IMHO, this section would be much better if we described the protocol
usage for each of the (three) existing architectures. This would give
insight into just how big or small the job at hand is for NEA. 
-On IF-PA, last sentence: Are there any examples of common attributes
that would benefit from standardization?
-On IF-PB: Doesn't EAPoUDP draft specify an EAP transport for L3
gateways already?  -Would seem to me that there is some work, perhaps
not finished. 
-Can you provide a reference to the PANA WG work item mentioned? 
-What non-standardized protocols have been designed?  References?
-Last paragraph: What remaining interfaces were identified?  I only see
four and all four are accounted four.

Cheers,
MS

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

916.785.1910 Tel
916.785.1815 Fax
mauricio.sanchez at hp.com
--------------------------------------------   


_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea