Issues of Security and Privacyin Networking in the CBA
Karen Sollins
Laboratory for Computer Science
July 17, 2002
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
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
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
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
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.
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
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
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