Security

1. Security David D. Clark July, 2012

2. Aspects of security • Attacks on the network • Routing, supply chain • Attacks on communication • Confidentiality and integrity addressed with encryption. • Availability?? The central objective of networks. • What else? (Traffic analysis…) • Attacks on the host • Infiltration (can lead to most anything) • So either prevent infiltration or limit its consequences. • Denial of service • A special case of availability. • Information assurance. • Sign the information, not the connection. • National security

3. Attacks on the network itself • Today, routing is most obvious example. • Get back to DNS later… • Regions issuing rogue routing assertions. • E.g. Pakistan and false routes to Youtube. • Seems like a technical problem with a technical solution. • All routing assertions should be signed. • NOT a technical problem—no root of trust. • International tiff…

4. Some attacks on communication • Deep packet inspection • Should we call this an “attack”? • Re-writing of parts of content. • Changing embedded URLs in web pages. • Byzantine packet handling. • Re-routing, adding and dropping. • Man in the middle attacks. • DNS corruption (pharming) • No architectural support today to mitigate this. • Design is redundant, but not in face of malice.

5. A simple approach • Deal with confidentiality and integrity (spying and changing) by using end-to-end encryption. • Raises a number of subsidiary issues, but a good place to start. • The classic taxonomy misses a major issue. • Talking to actors you don’t trust. • The norm today—email, web sites, etc. • Encrypted communication with an actor you don’t trust is like meeting a stranger in a dark alley. • No witnesses. • What does that leave? • Availability. What else? • If “all” a network does is deliver packets, then availability is the crux of the requirement. • Why do we lack a theory of availability?

6. Availability • First, as much as possible, make attacks on network and communication into failures of availability. • Limit the range of attacks and responses. • Think: what is excluded…? • Mechanism: wrap an end-to-end confirmation of identity around a connection. • Cleanly makes many attacks on/by the network into an availability problem. • Second, develop a theory of availability. • At a high level: • All critical resources must be supported in a rich, heterogeneous, diverse form. • It must be possible to detect and distinguish (to some degree) failures. • The point of detection must be able to invoke different resources. • In general, only the end-points can detect failures.

7. End-to-end checks • To turn misdirection attacks into “availability problems”, need a means to confirm with whom you are communicating. • An issue of identity and shared information. • What notion(s) of identity will be suitable? (See below.) • “You” means the end-nodes, but not just the human. If the end-node can be trusted, software can help. • Corrupted end-nodes are a central issue here. • Can a trusted helper node help? • To detect Byzantine attacks, fault detection must be integrated into the carriage of data. • Security and management are entangled.

8. Security mechanisms • Security mechanisms do not ensure correct successful operation. • DNSSEC • SSL/TLS • IPsec • SBGP and its kin • Self-signed identifiers (public key hashes, etc) • They only give a clean indication of failure. • What we wanted was success. • Successful operation depends on the ability to select and use trustworthy components.

9. Traffic analysis • Recording addresses, not content. • Who talks to whom? • Incredibly powerful tool for intelligence gathering. • Hardly need “wiretap”, which is the term for getting the content. • Encryption does not help. • This is “security” vs. “national security”. • Counter-measure: encapsulate to hide address.

10. Example of encapsulation • Onion routing (TOR). • See www.torproject.org. • Pick a sequence of presumably trustworthy TOR nodes from around the globe. • In turn, encrypt your packet (addresses and all) using the public key of each node. • Each node peels off its layer of encryption (like peeling an onion—get it?) and forwards it. • Who uses TOR today? • Bad guys. Dissidents. Spies.

11. Protecting the end-node • Node security • Classic end-nodes will always be insecure, but we can build fixed-function nodes that are pretty good. • Can we build secure virtual machines? • What parts do we have to work with? • Applications define the range of patterns of communication that can be utilized, and what can be seen/modified in the communication. • Elements in the network can examine what is revealed. • End-node controls the initiation of connections and what is sent. • Encryption blunts the power of examination/modification. • Network controls topology and completion of connections. • A tussle over availability. • Can enforce communication patterns.

12. The design challenge • What trusted components, combined with application modes that exploit them, can protect untrustworthy end-nodes from attack (in particular infiltration, sabotage and exfiltration)? • The network can enforce the needed patterns of communication. • For example, OpenFlow. • Network elements can examine what the application chooses to reveal. • Trusted and untrusted… • Application design patterns and building blocks should be part of the future network.

13. Prevent infiltration • Require identity as part of session initiation. • Use agent to validate incoming service requests. • “Firewall of the future” • Allow end-node (or trusted helper) to open ports dynamically. • Eliminate well-known ports. • Make port scans less effective. • Inspect incoming data for “bad stuff”. • Represents a loss of privacy, so use selectively. • Host-centric actions. • Virtual machines for risky actions. • Outsource risky apps to different machine.

14. Prevent exfiltration • If a machine is penetrated, limit the bad consequences. • Could be use as zombie, deletion or corruption of data, or theft. • (This uncertainty is a major policy issue today.) • Theft is a major problem today. • The problem with controlling theft: • How can an external agent tell if the transfer is legitimate?

15. Case studies • Three stories: • Foreign hackers penetrate a system and send information back to their country. • We try to block it. • Foreign citizens download public information from a U.S. web site. • Their country tries to block it. • Users download pirated material from foreign site. • The user’s country tries to block it. • What is the difference? • We relabeled the actors. • In one case, had to penetrate the sender to implement the pattern. • In one case, the sender’s regime tries to block, in others the receiver’s regime tries to block.

16. The design challenge, part two • How can we design applications and patterns of communication that can distinguish between these three stories, even if the sending machine has been penetrated?

17. Distinguish the stories • In the first story: • Require that data being sent get an export permit (from a trusted machine), that the user must concur, and that we get a strong identity of the receiver before issuing the permit. • In the second story: • Put the data into an open publish-subscribe or peer-to-peer distribution system. • Another example of the theory of availability. • But protect the privacy of the requester… • But how to tell the second and third apart… • Balance the interests… • Don’t forget other stories, such as unwelcome sending. • These solutions involve application design.

18. Certain attacks can be degraded • For attacks that are economically motivated, it may be possible to render them no longer cost-effective. • Hint: • Attacks against business--high value. • Attacks against home computer--low value. • Requires collective action. • Users cannot do this on their own.

19. Information assurance • Today we validate information by validating the source. • Make a secure connection. • Most servers today do not support this... • Once you have information (e.g. a web page), no way to confirm it is legitimate. • If information is signed, then it can be authenticated independent of how it is distributed. • But how do we know to trust the signature?

20. Remaining topics • DDoS • National security • I ignore these due lack of time…

21. Summary • Good security is a balance among competing considerations. • It is not a problem that we can or should try to solve (totally) “in the network”. • Many problems arise (and must be handled) in the applications. • Encouraging the design of secure applications is central to a more secure future.

22. Aspects of security • Attacks on the network • Routing, supply chain • Attacks on communication • Confidentiality and integrity addressed with encryption. • Availability?? The central objective of networks. • What else? • Attacks on the host • Infiltration (can lead to most anything) • So either prevent infiltration or limit its consequences. • Denial of service • A special case of availability. • Information assurance. • Sign the information, not the connection. • National security

23. Who is responsible? • Attacks on the network. • The network. • Attacks on communication. • Confidentiality and integrity can be delegated to end-nodes. • But remember communication among untrusting parties. • Availability is a shared responsibility. • Mechanisms lead to clean failures, end-nodes (applications) must recover. • Attacks on hosts. • Many parties have a role: end-node, trusted components, network, application designer, user. • DDoS. • A contested space. • Information assurance • Sign the content, but how to trust the signature? • National security.

24. Issues to consider • Security • Availability and resilience • Better management • Economic viability • Meet society’s needs • Support for tomorrow’s computing • Exploit tomorrow’s networking • Support tomorrow’s applications • Fit for purpose (it works…)