Subject: Re: [Nea] [NEA] Proposals for Attribute Categories & Attributes

From: "Paul Sangster" <[email-masked]>
Date: Mon, 22 Sep 2008 11:50:51 -0700

Brian,
 
Sorry for the delay but the editor team would like to get back to you on
the suggestion below.  We think you have an interesting idea of allowing
the NEA Server to obtain more detailed information about the NEA Client
(including vendor information and version).  We believe the best way to
do this consistent with RFC 5209 is to add a PA subtype (AKA component
type) for the NEA Client.  This will allow the NEA Server to obtain a
good amount of information about the NEA Client so could be factored
into a policy decision. We plan to add this in the next revision unless
the WG doesn't feel this is necessary) and believe this could cover your
QR and AG models (QR if parts of the NEA Client are built into the OS).
 
As for the probe (PR) and passive probe (PP) models, these involce
components outside the scope of the NEA WG charter and what is defined
in RFC 5209.  If/when our charter is expanded down the road we could
reconsider this decision.
 
Paul

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Brian Ford
	Sent: Friday, August 29, 2008 7:04 AM
	To: NEA
	Subject: Re: [Nea] [NEA] Proposals for Attribute Categories &
Attributes

	NEA Community,
	
	I suggest that an important Attribute Category would be
"Assessment Method".  This category would include information about how
the endpoint was assessed (method) and be able to be correlated to the
time of assessment .  
	
	When I think about posture attributes I believe that there are a
number of methods that a policy decision point (PDP) can expect the
attributes to have been collected.  
	
	#1 - The operating system on an endpoint reports its attributes.
I refer to this as Query-Response [QR] case.
	#2 - Some software added to the endpoint determines and reports
attributes.  I call this the Agent [AG] case.
	#3 - Some other device on the network interacts with an endpoint
and reports attributes. This is a Probe [PR] case.
	#4 - Some other device on the network does not interact with an
endpoint and reports its attributes. I refer to this as a Passive Probe
[PP].
	There might be other cases...
	
	I would suggest that these four (and perhaps other) collection
models might be attributes make up an category called Assessment Method.
	
	I think it would be valuable if the PDP could make a decision
knowing the answers for up to all four of these methods for a single
endpoint. For example a PC (Endpoint X) might have an agent installed
that provided data (#2) AND that same PC was probed when it was detected
on the network (#3).  Another example might be a network print server
(Endpoint Y) that reported attributes (#1) AND was subjected to a
passive probe (#4). 
	
	When data arrives at the PDP it could be visualized as a stream:
	
	[ENDPOINT X MAC ADDR], [TIME A], [ASSESSMENT METHOD AG], [DATA
SET 1],... [DATA SET N]
	[ENDPOINT Y MAC ADDR], [TIME A+1], [ASSESSMENT METHOD QR], [DATA
SET 1],... [DATA SET N]
	[ENDPOINT X MAC ADDR], [TIME A+2], [ASSESSMENT METHOD PR], [DATA
SET 1],... [DATA SET N]
	[ENDPOINT Y MAC ADDR], [TIME A+3], [ASSESSMENT METHOD PP], [DATA
SET 1],... [DATA SET N]
	
	The PDP could then build and (temporarily) maintain a data
structure about Endpoint X and Endpoint Y that has information available
about all the endpoints it knows about.  
	
	[ENDPOINT X MAC ADDR], [DATA GATHERED AT TIME A], DATA GATHERED
AT TIME A+2]  
	
	The PDP could then make decisions based on any data in that data
structure that meets it's "freshness" requirements (aging out old data)
or if no data meets those requirements it could call for (as an example)
an active probe [PR] or query the agent [AG].
	
	Note: Writing this data stream described above off to a storage
device also creates a potentially valuable data store.  Later processing
of this data could be used to create a sort of "batting average" that
would report on the accuracy of the different assessment methods and how
well the PDP rules are working.
	
	Liberty,
	
	Brian

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

---

From: Randy Turner <[email-masked]>
Date: Mon, 22 Sep 2008 13:31:31 -0700

Hi All,

I was re-reading the "NEA Requirements" RFC and I think some guidance  
and or clarification needs to be provided for virtualized  
environments.  The text in the requirements document (section 5.1.1 I  
believe) I think leaves too much open-ended.

We use the term "device" attributes everywhere, but this gets  
confusing in a virtualized environment about the meaning of "device".   
At a minimum, we may need a "terminology" section that rigorously  
defines what we mean by device, given that we've said in the  
requirements section that we're only talking about NEA clients  
operating within the context of a "execution domain", and that  
anything that attempts to aggregate execution domains is "outside the  
scope of this specification".  In the terminology section of the  
requirements doc we say "endpoint device", which, given the current  
language makes it more difficult to interpret in the context of  
virtualization. Maybe we should at least state that there is a one-to- 
many relationship between endpoints and devices.  It's not clear that  
we can necessarily get away with as little language about  
virtualization as we have now...the rate of deployment of virtualized  
systems is exploding and it seems like we should address it more  
clearly, at least with some type of guidance about how policy decision  
points might be able to "infer" that endpoints are residing on the  
same device.

If this is already addressed somewhere in the current doc set (beyond  
what I referenced above), I apologize in advance, but please let me  
know...I may have inadvertently missed it.

Thanks!
Randy