Vidya, Thanks for your response. I think we may be getting closer to understanding each other's perspectives. That's a good thing. Let me respond to your comments inline below. I hope you won't mind if I clip a bit since this thread is starting to get long. Vidya Narayanan wrote: > A. Any network is exposed to threats from lying endpoints, compromised > endpoints and unknown vulnerabilities even on NEA-compliant endpoints. > > B. A network needs to be protected against such generic threats (as > listed in A). Agreed. There are plenty of other threats but that's enough for now. > I am rather confused by this attempt to make NEA fit into some kind of a > network protection mechanism. I keep hearing that NEA is *one* of a > suite of protocols that may be used for protecting networks. Let's dig a > bit deeper into what a network may employ as protection mechanisms in > order to protect against all kinds of general threats. > > i) Access control mechanisms such as authentication and authorization > (to ensure only valid endpoints are allowed on the network) > ii) Ingress address filtering to prevent packets with topologically > incorrect IP addresses from being injected into the network > iii) VPNs to provide remote access to clients > iv) Firewalls to provide advanced filtering mechanisms > v) IDS/IPS to detect and prevent intrusions > vi) Application level filtering where applicable (e.g., detecting and > discarding email spam) > > A combination of the above (or the like) needs to be used to address the > general threats mentioned above (in B, for e.g.). Given that, what does > NEA bring to the network that isn't already provided by such mechanisms > that need to be employed anyway? It is not like we can stop using some > of these mechanisms if NEA is present, since the threats that NEA may > protect against (from the network perspective) are a small subset of the > general threats that a network operator must consider. And, when the > general threats are addressed, any subset of those threats are also > addressed. NEA is another network security tool. Like the others, it has some special advantages but does not remove the need for the others. What does NEA provide that isn't provided by the others? NEA can 1) identify unhealthy endpoints (vulnerable or infected) 2) quarantine unhealthy endpoints before they can infect others or become infected (optionally) 3) repair unhealthy endpoints (optionally) Yes, NEA cannot provide all these functions itself. NEA provides a framework for passing messages about endpoint health. Other security products use that framework to collect, send, and validate specific posture attributes and then to send remediation instructions and/or quarantine unhealthy endpoints. > The effectiveness of NEA is tied to the type of endpoint (i.e., > truthful, compliant endpoints with known vulnerabilities). A network, > OTOH, needs mechanisms that protect against all kinds of endpoints. I > fail to understand why a particular category of endpoints that NEA > addresses is not viewed as a subset of the general category of "all > endpoints". With the aid of technology for detecting lying endpoints, NEA can also handle that class of endpoints. But I agree that NEA will probably never apply to every endpoint on the network. For endpoints that support NEA, the network operator can provide better security. For endpoints that don't support NEA, it will be status quo. > Steve Hanna wrote: > > In the context of an overall security program and when > > combined with other security technologies, NEA can help > > protect networks. > > Let me list the ways. > > > > First, NEA can help improve the security of cooperating, > > truthful endpoints. > > How is this network protection? As you state above, it is about > improving the security of co-operating, truthful *endpoints*. Network security is improved because fewer cooperating, truthful endpoints turn into uncooperative, infected endpoints that then flood the network with attacks. > > Second, NEA can be used with technology for detecting lying > > endpoints. This prevents compromised systems from lying to > > gain access to the network, thus providing a huge improvement > > in network security. > > Once again, given that a network operator must really protect against > many generic threats, what kind of improvement is NEA bringing to the > security of the network? See my comments above. > > Third, endpoints that don't initially participate in NEA > > protocols can be quarantined for further examination with an > > external vulnerability scanner or a dynamically downloaded > > NEA client. Again, this is not part of the proposed NEA WG > > charter but it is another example of ways that NEA can be > > used with other security technologies to improve network security. > > I'm confused by the above - what is the role of NEA here? I'm pointing out that endpoints that don't initially participate in NEA protocols can be quarantined and directed to a web page where they can run a dynamically downloaded NEA client. So this expands the set of endpoints that can be handled by NEA. > I continue to remain puzzled on the above points! I was previously confused by your perspective but I think I now see where you're coming from. I think you want to provide a network that's as secure as possible without having any involvement in how endpoints are configured. That's one valid perspective but it's not the only valid one. Many enterprises want to know about the configuration of endpoints connected to their networks. They may or may not restrict network access for endpoints that don't comply with their policies. Some ISPs want to provide endpoint security services for their customers and therefore want to know about endpoint configuration. Do you now see the value of NEA for these network operators? And maybe you see how NEA can help them make their networks more secure? Thanks, Steve _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf