Hi - Functionally, how would nea be different from using netconf or snmp to retrieve a system's configuration data? Describing it as a way to retrieve vendor-specific strings from a system makes it sound like a profile of netconf. Randy > From: "Ted Hardie" <hardie@xxxxxxxxxxxx> > To: <ietf@xxxxxxxx> > Cc: <nea@xxxxxxxx> > Sent: Sunday, October 08, 2006 11:45 PM > Subject: WG Review: Network Endpoint Assessment (nea) > > I have a very basic fear that this working group is getting chartered > with a bunch of aims added by people who will not take on the > task of doing the work. After private discussion with folks > involved, my sense is that the very core of this work is a perceived > need to be able to pass opaque strings between a host and the network > prior to the host attaching. Those opaque strings are, essentially, > the vendor-specific strings currently associated with posture assessment. > The standard protocol carrying these strings would connect on the network > side to a system that has plug-ins which understand the vendor-specific > strings. > > With a charter that clarified that this was intended to assist the end > systems with vulnerabilities prior to attachment because the > network they are attaching to might be filled with danger, I > think this work would get done reasonably quickly. (As a control > mechanism to protect the network, I agree with the point made > clearly by others that this is not appropriate). > > I am less sure of the task of standardizing attributes. > > I am not sure that the number of attributes which can be standardized > will ever be high enough to be truly useful, and I am pretty sure > that all of these will be already covered by vendor-specific attributes. > Since there must be an assessor in place on the client for those few > standardized attributes to be assessed and that assessor will likely already > have these covered by vendor-specific attributes, in other words, > we seem to be standardizing redundancy. On the network attachment > side, it is possible, of course, that an offer of remediation could be made > based on just the standard attributes, but it seems far more likely that > it would be a two step process (assess standard attributes, then pass > vendor-specific attributes to vendor plug-in). Again, if the vendor's > attributes cover the standard attributes, then this is largely redundant > and may add measurable latency; it seems far more likely that > step one would simply be skipped if there were a vendor-specific string > and an available plug-in. Since there has to be an assessor, the first > seems very likely to me. If you don't have a vendor's plug-in, then > I suppose there is some chance that you will trust and act based on the standard > attributes, but the chance of getting the right remediation seems > pretty slight in those circumstances. Especially when many vulnerabilities > are a combination of conditions, (Browser version Foo on OS patch level Bar) > that you could remediate by upgrading either one, checking for and > acting on the attributes which could be standardized seems of very, very > limited utility. > > Ted Hardie > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf