Issues of Security and Privacy in Networking in the CBA

1. Issues of Security and Privacyin Networking in the CBA Karen Sollins Laboratory for Computer Science July 17, 2002

2. Assumptions • Ubiquitous networking within facility - universal access • Connectivity to the Internet - MIT doesn’t run firewalls - how to set limits on access • Curious students - want to see inside everything • Uses • Research - both networking research and support for wide variety of other research- adaptability • Infrastructure of facility - utilities of building, computing services, others?? - stability, trustworthiness, privacy

3. Kinds of things we know how to do • Network encryption at the link level, network (IP level), even transport (TCP, etc.) level • Authentication (e.g. using key exchange or other mechanisms) • Key or certification management (PGP, etc.) • Firewalls: blocking traffic based on filtering at the transport layer

4. What to notice about these • Tend to be rather static • Tend to take offline setup with human intervention • Not human friendly • Elements that may provide similar high level functionality may do it very differently, without concern to substitute-ability

5. Is there a different way to think about these issues? YES! • Layering: protocols designed to provide some model of connectivity among different “end-points” • Modularity: separation of realization of functions, often used to design, implement, improve or replace independently • Abstraction: hiding details of implementation behind a more formal definition of functionality and interface

6. Layering • Solve parts of problem at different layers - allow them to complement each other • Example: providing privacy • Link level encryption: allows for co-design with link level coding, might be more efficient • Network level: can assume link level encryption, but needs to build privacy across composed links • Transport level needs to guarantee privacy from network level end-point through operating system to transport end-point • Application level may need to allow for human friendly access, interpretation, management, etc.

7. Modularity • Provides separation of units of functionality • Allows for improvement. Upgrade, substitution of elements without impact on others • Example: encryption algorithms. If found to have flaws or compromised, could be replaced without replacing whole layer implementation

8. Abstraction • Defining model at some point that masks models from which it is created • Allows for new bases of assumptions about behaviors. • Example: in privacy example, allows for assumption by transport layer that network layer provides IP address to IP address privacy, rather than elements strung together

9. Conclusion Abstraction is what is really necessary • For human policy and decision-making, without necessarily intervention in low level details • For authentication, authorization, confidentiality, extensibility and stability