> -----Original Message----- > From: Susmit Panjwani [mailto:susmit@xxxxxxxxx] > Sent: Saturday, October 07, 2006 5:04 PM > To: Harald Alvestrand > Cc: Narayanan, Vidya; nea@xxxxxxxx; iesg@xxxxxxxx; ietf@xxxxxxxx > Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > > Third, I > > simply can't see what the organization's > interests would be in > > > protecting a device that doesn't even belong to it. > > An organization might not be interested in protecting a > device that does not belong to it but would definitely be > interested in preventing the attacks originating from such > device (if compromised) when it joins the organization > network. It appears that the NEA charter is completely misleading to some people from what is stated in this email. As the NEA charter alludes to, NEA does nothing to protect against compromised devices. Also, as has been agreed, NEA is not a protection mechanism for the network - it is meant to be a protection mechanism for compliant, truthful and as yet uncompromised end hosts against known vulnerabilities. Any network, in its own best interests, must assume that it has lying and compromised endpoints connecting to it and that there are unknown vulnerabilities on any NEA-compliant devices connecting to it. Any kind of protection that addresses these general threats that the network may be exposed to at any time will simply obviate the need for NEA from the network perspective. A network operator that thinks the network is getting any protection by employing NEA is clearly ignoring the obvious real threats that the network is exposed to at any time. This is what I meant when I said that the charter is unclear and it must explicitly state that NEA is not meant as a protection mechanism of any sort for the network. Vidya > To cite a study that we performed at > UMD: we did a cost-benefit analysis based on the captured > attacks from within the organization, and it turns out that > the organization would benefit significantly if they > implement any trusted network access technology. > > I do realize that there would be issues in terms of user > privacy and interoperability(which this charter is trying to > tackle) but just wanted to mention that there would be > significant benefits if they can implement it. This is > especially true for university environment. As a matter of > fact I am aware of some universities/departments that were > planning to implement a home grown solution for this. > > Susmit > > -- > Susmit Panjwani > > PhD Candidate, > Center for Risk and Reliability, > University of Maryland > Cell: 240-460-9782 > > > On 10/7/06, Harald Alvestrand <harald@xxxxxxxxxxxxx> wrote: > > > > > > The reason we left it open is to allow the working group to spend > > > more > > > > time exploring the range of use cases in this area to better > > > > determine requirements and applicability. For example, > it may be > > > > useful to classify endpoints as network-managed versus > > > > user-managed versus 3rd-party managed. A user-managed > endpoint may > > > > want the choice to opt in or opt out, say. > > > > > > > > > > > > > Not only do I not see anything in the charter or milestones that > > > indicates that the WG is going to spend time exploring this, I > > > strongly believe this WG should not be spending any time > looking at > > > this. The trust models for the cases where the devices > are not owned > > > by the organization performing NEA are hugely different > and can take > > > up its own WG to actually find something that applies > there, if at > > > all. For one, this could be considered a violation of > privacy by the > > > user of the device. Secondly, the end user's perspective > of attacks > > > may be entirely different from the organization's perspective in > > > this case. Third, I simply can't see what the organization's > > > interests would be in protecting a device that doesn't > even belong > > > to it. Last but not the least, this requires the endpoint to be > > > running an NEA client (that is interoperable with the NEA > server of > > > the organization) - which in itself is often an > unrealistic requirement. > > Many universities require their students to buy their own > laptops, but > > prohibit certain types of activity from those laptops (like > spamming, > > DDOS-attacks and the like). They would love to have the > ability to run > > some kind of NEA procedure to ensure that laptops are reasonably > > virus-free and free from known vulnerabilities, and are important > > enough in their students' lives that they can probably enforce it > > without a complaint about "violation of privacy". > > > > Just pointing out that there's one use case with user-managed > > endpoints where NEA is not obviously a bad idea. > > > > Harald > > > > > > _______________________________________________ > > Nea mailing list > > Nea@xxxxxxxx > > https://www1.ietf.org/mailman/listinfo/nea > > > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf