class: big, middle # ECE 7420 / ENGI 9823: Security .title[ .lecture[Lecture 18:] .title[Network security] ] --- # Progress ### ~~Introduction~~ ### ~~Software security~~ ### ~~Host security~~ ### Network security ### Web security --- # Today ### Networking layers ### Networking assumptions ### Networking attackers --- # Recall <img src="../layers/more-realistic.png" align="left" width="450"/> --- <a href="https://xkcd.com/2166"> <img src="https://imgs.xkcd.com/comics/stack.png" alt="XKCD: Stack" width="350" align="right"/> </a> # Recall <img src="../layers/more-realistic.png" align="left" width="450"/> --- # X.200 OSI layers ([link](https://www.itu.int/rec/T-REC-X.200-199407-I/en)) -- | # | Name | Description | |---|------|-------------| | 7 | Application | What we're actually building systems to do -- | 6 | Presentation | Encoding, compression, encryption/decryption -- | 5 | Session | Continuous exchanges of **data** between nodes -- | 4 | Transport | **Segments** or **datagrams** between nodes -- | 3 | Network | **Packets** with addressing and routing -- | 2 | Data link | **Frames** between connected nodes -- | 1 | Physical | **Symbols** over analog link --- # Common layers / encapsulations | # | Name | Example | |---|------|-------------| | 7 | Application | HTTP, DNS, NFS, SSH... | 6 | Presentation | TLS, SSH... | 5 | Session | SOCKS, SMB... | 4 | Transport | TCP, UDP, SCTP... | 3 | Network | IP | 2 | Data link | Ethernet MAC | 1 | Physical | Ethernet PHY --- # OSI model in practice ### OK, that's kind of a nice idea, but... -- * rigorous standardized layers most important for lower layers ??? Standardization matters a lot at some layers of the stack. However, **which thing goes in which layer** is a bit more fluid at the top of the stack than at the bottom. -- * fairly narrow-minded (e.g., encryption goes **there**) ??? Let's not be dogmatic about where the crypto should go, or which layer is supposed to **provide "trust"**. We need to think **systemically** about these things! -- * can be a crutch to avoid thinking about layering for yourself ??? Starting a section of a technical report with, "the OSI model for networking states that..." is like starting a speech with, "**Webster's dictionary defines 'trust' to be [...]**." It's a terrible way to engage both your own mind and your reader's: instead of **thinking about the problem** first, it **appeals to a common formulation** and then **slots your problem into that formulation**. -- #### Still: useful to think about encapsulation, abstraction layers, TCBs ??? **Demo:** show Wireshark example --- # TCBs in networking ### Q: What is the TCB in networking? -- ### A: It's complicated! It depends on: ??? Different networking models embody different assumptions about trust. -- * how you trust middleboxes ??? We'll talk more about middleboxes as we get further into the course, but for now, we should recognize that different networking arrangements place different levels of trust in the switches, routers, caches and TLS interception boxes that exist between you and a remote host. -- * how you trust the other host ??? When we talk about "trusting" a remote host, we should (as always!) think carefully about what exactly we mean. We can trust a host to have our best interests at heart (unlikely?), we can trust a host to deliver something they said they would (more likely), we can trust a follow a protocol correctly even if they're malicious, etc. -- * how you trust other users --- # Assumptions -- ### Original internetworking model ??? Systems tend to embody the assumptions of their designers. This observation has been expressed in different ways, including [Conway's Law](http://www.melconway.com/Home/pdf/committees.pdf): teams tend to design software whose structure mirrors that of their organization. Teams in hierarchical organizations think in terms of hierarchy, teams in flat organizations think in terms of interconnection webs, etc. Similarly, things like network protocols embody their designer's assumptions about "how things ought to work". -- ### Trust ??? Early internetworking was done by a handful of sysadmins at a handful of institutions (mostly universities), most of whom knew each other and all of whom had control over the systems attached to their networks. How would this affect the internetwork they designed? -- * physical security -- * low-numbered ports -- * raw sockets --- # Trusted networking .floatright[ * application data * remote hosts * local OS * internetworking middleboxes * network links * physical media ] ### Suppose we chose to trust everything: -- How could you attack an application, e.g., online banking? -- ### What _must_ we trust? Could we eliminate trust in any or even **all** of these layers? ??? ### Eliminating trust Answer: no. We can't eliminate trust in _all_ layers, as you ultimately must choose to trust something or someone in order to get anything done. In the online banking case, you've chosen to trust the bank (backed by a regulator, backed by a government)... if you don't like trusting banks, try putting your trust in a global cabal of cryptocurrency developers! --- # How little can we trust? ##### (a slightly depressing question!) -- ### Cryptography: Kirckhoffs's principle (one of six) > It should not require secrecy, and it should not be a problem if it falls into enemy hands -- ### Networking: the _Dolev-Yao_ attacker --- # The Dolev-Yao attacker&ast; .footnote[ &ast; Dolev and Yao, "On the Security of Public Key Protocols", _IEEE Transactions on Information Theory_ 29(2), 1983. DOI: <a href="https://doi.org/10.1109/TIT.1983.1056650">10.1109/TIT.1983.1056650</a> ] ### Communications should assume an attacker can: ??? Like with Kirckhoffs's principles, assuming a very strong attacker will help us defend against both strong and weak attackers. Assuming a weak attacker will lead to designing vulnerable systems that can't stand up against strong attackers. -- 1. observe all messages (**passive eavesdropper**), -- 2. send messages impersonating users (**active** attacker) and -- 3. intercept messages and drop or replace them (**middleperson**). --- # Dolev-Yao in practice #### What would these assumptions mean for the TCB? -- .footnote[ &ast; Saltzer, Reed and Clark, "End-to-end arguments in system design", _ACM Transactions on Computer Systems (TOCS)_ 2(4), 1984. DOI: <a href="https://doi.org/10.1145/357401.357402">10.1145/357401.357402</a>. ] This is an example of an _end-to-end_ argument&ast;: what matters is the end-to-end communication, the middle is just detail. -- (spidey-sense?) ??? Do your spidey-senses tingle when I say that something is "just detail"? They should! That is **an assumption that we should test**. -- #### How can we put these assumptions into practice? -- Trust no one! -- Or... -- Be explicit about trust and communication -- : **security protocols** --- # Summary ### Networking layers ### Networking assumptions ### Networking attackers --- class: big, middle The End.