 We said that if we want to communicate across the Internet or a network using IP-based protocols, the protocols themselves don't have built-in security mechanisms. There's usually add-ons, some extensions that add the encryption and authentication. So we started to go through that when you want to securely communicate in the Internet, there's different options. There's not just one way to do it. So we started to go through using some example stack. Let's encrypt inside the application. So you write some application that talks to another instance of that application, say a client-to-server, inside that application you implement some encryption, so application-level security. It's good because it's end-to-end or host-to-host encryption in that we encrypt at the start point and encrypt finally at the end point, protecting the data all the way between hosts. Then we saw an alternative, slightly different transport level, where we, as the application, think of it from the application developer, if you're creating your new application, whether it's a mobile application, one for a desktop, doesn't matter, but an application that communicates across the Internet to a server instance. So you're writing the software for the client and server with application-level security, you implement the security mechanisms inside your application. Someone downloads your application, the application includes the encryption and other security mechanisms. With transport-level security, when you develop your app, you don't implement the security mechanisms. You just use an API, say a function call inside your code, to call the operating system-provided security mechanisms. And the common one is TLS or SSL, again, same protocol. And your application calls that security mechanism, which will then encrypt your data and send it using TCP across the Internet. Normally, an application calls an API, a function call that you can think send data. So when you write your application, an Internet application, it calls a function, send data using TCP, and then the operating system sends the data across the network. You, as the programmer, don't have to deal with TCP. It's done by the OS. If you're using transport-level security, what you do is you call a function, which is send data using TLS, for example, using encryption. And then the operating system takes the data that you want to send, does the encryption, does all the security operations, and then sends it using TCP. So from the application development process, it's much simpler. You don't need to implement the security. The OS does it for you. But of course, you depend upon the operating system. No, TLS is just for TCP. And that's one of the limitations here, that TLS is widely supported. There are many operating systems support it, but it's built for TCP data only. If your application is using UDP, then TLS cannot be used. There are some other protocols that work with UDP, but they're just not very common. So not all operating systems support those other ones. So if you want your application to work on any system, it's much less likely if you want to use UDP. So in practice, usually, if you want to use transport-level security, it only applies if your application uses TCP, which is most applications, but not all. So there's some trade-offs there. There's no best solution. Both of them provide end-to-end or host-to-host encryption in that encrypt at the source host, decrypt at the destination. That's good. Let's look at some alternatives. Moving down, encrypt at the network layer. So your application just generates normal data, sends via TCP or UDP, which creates an IP datagram, and there's an extension of the Internet protocol called IPsec, security for IP. And that does the encryption. So that takes the IP datagram, and there's different ways to do it, but you think it encrypts the datagram, or at least encrypts the data inside that IP datagram. So you take the IP datagram, it has a header and data, IPsec can encrypt that data, and it's sent across the Internet. Again, just using normal IP because the header is the same, and it's delivered to the destination host, B, and the IPsec here decrypts the data and sends it up via the transport layer to the application, so the application receives the decrypted data. So there's a third option, network level security. Still, in this case or in this example, it's host-to-host encryption. That's a good thing. If I encrypt it at host A, the data stays encrypted all the way across the Internet until it gets to host B. An advantage of using this is that it works for any transport layer. Whether we're using UDP or TCP, the application just uses them normally, sends to IP, and then that encrypts the data. It doesn't matter if it's UDP, TCP, or something else, even. So this applies for any transport protocol. Any application can use it. So again, as the application developer, you don't need to worry about the encryption. You just, again, rely on the operating system features, in this case, within IP. But again, you are relying on the operating system. The operating system must support IPsec. So if you've got an OS that doesn't support it, then you cannot use this form of encryption. It's not as widely used as TLS. So it's not as widely deployed in practice for different reasons. So you'll see that it's not so common to be used like this, especially for end-to-end encryption. It requires some configuration. So one reason it may be not widely used in practice is because it requires some configuration on the computer. So the person who runs this computer, they install the application, but they must set up IPsec. And it's not trivial to set it up. So it usually requires some configuration changes on the operating system to set it up correctly. Whereas with TLS, there's nothing really to do from the setting up of the operating system perspective to get it to work. So that's one of the reasons why it's not so common. But it's an option. So encrypt our IP datagram contents. So the computer is configured to apply the security mechanisms. And IPsec is the main one. There are some other alternatives, but that's the main one at the network level. Good thing. It supports all applications, transport protocols. So you just install your normal application, your web browser, your email client, instant messaging, anything that you install that's using IP to send data. If you set up IPsec at both endpoints, everything's encrypted across the internet. So that's the advantage here. It doesn't matter what application or transport protocol you use. It's host to host. Or we'll see, at least in that example picture, it was host to host encryption, a good thing. But in the next few slides, we'll see that there's some alternatives where it's not host to host. The problem, it requires support and often some user configuration in the operating system. So it's not something that the user is transparent to the user. So the user must do something, usually set up some parameters in the operating system to get it to work correctly. The next few slides will show a variation of using IPsec, which are a bit more common. And we'll see some advantages of them and used in what we'll call tunneling mode. So staying at the network level security is another way that IPsec can be used. Here, let's say I have my laptop. Remember host A was my laptop, my wireless access point, some router on our LAN. Then there's the internet. And then there's a router at the destination network. So here's some server that I want to connect to. And there's a router that's connected to that. One way to configure using IPsec is to run IPsec between hosts and routers. So in this case, my computer, my laptop, is configured to use IPsec, which means that when my applications generate some data, and I can set it up so that any application that creates data that wants to send across the internet, IPsec will encrypt it. But I can set it up so that IPsec will encrypt it. And what we'll do is use tunneling such that it sends the original packet all encrypted to some intermediate destination, this other router here, which will then decrypt and send on to the destination host. So let's see how that works. So again, I want to communicate it from A to B. And I've tried to draw the IP packet that would be created in the normal case. Assume no encryption. Then what happens is my application creates some data, maybe TCP is being used, and eventually an IP datagram is created. I've drawn it here as AB data. Maybe I'll just show what that means. Here's our pictures. In this case, so this is our same one, what do I mean by this AB data? I mean that's an IP datagram, the original one. So what's an IP datagram? The IP header and some data. So that's created in the normal case. And the IP header, remember, contains a number of fields including a source address and a destination address. And if host A is sending to host B, the source address when this is created will be A and the destination will be B, the IP address of A and B. So there's our IP datagram. And instead of me drawing it like this all the time, I've just summarized it as in that picture up there. So A sending to B, source address is A, destination is B, the data is what's inside, whatever the application created. That's the normal IP datagram. That's created. But then what IPsec does is it can take that entire datagram, encrypt it, and put it inside another one. So we take this, so that's created, and it's supposed to be sent across the internet to B. But IPsec takes all of that, and we can think we take it and encrypt the contents. So we take our original IP datagram, draw it again, and you'll see that this is our source address is A. So the same datagram, but encrypt it. That is take the entire contents and encrypt that. So it just becomes a random set of bits, but then put that inside another IP datagram. So really attach a header. This is done at computer A. So the first IP datagram is the normal IP datagram created. But then IPsec goes to work. It takes this, encrypts it, and then attaches a new IP header, where the new IP header has a source address of A. It's coming from A and a destination address in this example of router Y, which is if you scroll up, you can see this router here. Because we've set up our computer. So this assumes we've set IPsec on the computer to do the encryption and send the data to router Y. We'll see what Y does when it receives it. So this packet is this AB data. And this second one I've drawn here is summarized here. So the encrypted original packet in red and this new header, which is the source of A, destination of Y. That happens at computer A. Remember, our aim is to get data from A to B. In this case, the IP address here, the source is A, destination is Y. So computer A has an IP address. So whatever the IP address is, the original packet, the source address is the computer that creates it. The destination is who we want to send it to, A and B. We take that, encrypt everything, including the header. Now, if we encrypt the header, there's no way to send that across the internet, because the routers need the header to be able to know where to send it. So what we do is we encrypt all of that and attach a new header where the source is still A. It's coming from A. But let's send it to Y, this router. We send that. And now we send it who to, where we send it to the next device to reach the destination Y. We send it to our access point. So this is, say, my laptop up to the access point. That's normal. The access point gets it, sends it to the next, the local router inside SIT. And then we use the normal internet routing features of, this router X has a datagram. Header says, source A, destination Y. So it uses its routing table to say, OK, I need to get this to Y. So I send it to the next router, which is some next router on the internet, which gets it. OK, destination Y, they keep sending until it reaches computer Y, router Y in this case. So between A and Y, all the intermediate devices, they just look at the header and look, well, who's the destination? Who do I send it to to reach this destination? And the result is that this one eventually reaches Y, router Y. Router Y receives it. And router Y is running IPsec as well. And it's configured. OK, it's received an IP datagram, destination Y. What it does is it recognizes this is an IPsec datagram. It removes the outer header. It decrypts this data. It was encrypted before. It decrypts, because that's the receiving endpoint. And we see what we have left. After we decrypt, we have this original packet left. We decrypt the red part. We get this back. And router Y is configured. OK, we have a datagram. We've just used IPsec. I've received a datagram and decrypted. And actually, the destination is not me. It's B. So what router Y does now is realizes, OK, I need to send this further. I need to send this unencrypted datagram onto B. So router Y now sends it to B. And B receives this datagram. And that's shown here, this AB data. So this is one way that we use IPsec. We don't have to use it on the endpoints. We can use it on the routers as well. And we'll see the advantages in a moment. So the result, A encrypted the datagram before it sent it, sent the encrypted datagram to Y, router Y. When Y receives it, it decrypts and sends the original datagram onto the final destination B. And you see, all right, the red line shows us where the data is sent encrypted. So if anyone intercepts on the wireless LAN in this access point on this internet here, if someone intercepts, they see the encrypted form of the data. They cannot see the original data. So we still have our protection across this portion of the path. But we don't have any encryption between router Y and host B. The data is sent unencrypted. So this is not protected. So there's a disadvantage. But often it may be safe because if host B is inside some physical LAN, so inside some company LAN, and the router is the router for that LAN, then we may trust these links inside the organization. It's common that within an organization, we trust that no one can get access, like get access to the building and intercept on the links. Or it's much harder to do so. So we send the data unencrypted to B. What's the advantage? Why do this versus what was the previous one? Why do this one instead of this end to end or host to host encryption is better because we encrypt all the way. But the advantage of doing the decryption and encryption on the router is that we don't need to have this host B configured to use IPsec. It's just a normal host. It doesn't use any security mechanisms. Now imagine this destination LAN has not just host B, but thousands of computers inside. So this is the router for some organization. And there are thousands of computers in there. Rather than every computer have to be configured to use IPsec for end to end encryption, it's the router that does it on their behalf. So the router provides the security across the public internet portion of the network. But internal on the organization, we don't use any encryption because we trust internal networks, but not external networks. We could, and with all of these examples I go through, we can use multiple levels of encryption and also encryption across different portions. So we could apply some encryption here. But the advantage of doing everything on the router is that we don't have to set up these computers to use IPsec. As I said before, IPsec involves some configuration on the computer. You need to have the software set up and you need to have some configuration parameters set. So if we've got thousands of computers inside some organization, then instead of having to configure every single one and make sure every operating system supports IPsec, just do it all on the router. So at least from if this is internal to the organization, at least the external communications are protected using encryption. So this is a trade-off again, using network-level security but not end to end, but using a router as one of the endpoints. And an example where this is commonly used, again, here's our internal organization, let's go to that picture, an example configuration is that here's our, the separation is that this is our internal network inside some organization. And we trust that. So we don't need encryption across the links inside the organization because it's very hard for someone to intercept on those links, assuming we're only protecting against outsiders. And the rest from this organization is external, the public internet. And maybe this is one of the users that's working at home. So one of the employees and they need to access the internal network to do some things working at home. And between the router Y and the rest is the public internet. And the organization cannot trust the communications across the public internet. So what they do is that the home user has their computer configured to use IPsec. The router that connects into the internal network is configured to use IPsec. And they're set up such that they encrypt the data between the home user and the router. Effectively giving this home user secure access to the internal network, to the organization's network. And they can be set up such that they can do things. There's some other extension so they can do things as if they're sitting on this network, as if they're internal to the network. Because by encrypting all across the internet, no one can intercept. And this is the concept used in a virtual private network. So this concept of, well, we have a private communications across a public internet by using encryption across this portion, the public form of the network. And it essentially allows this host A to communicate on this internal network as if they were actually had their computer on the internal network. So that's a common setup of a virtual private network to allow an external user to access an internal network, to connect into your work from home, for example. Any questions on this example of IPsec? Here's another one. We don't have to run IPsec between hosts and hosts. We don't have to be host to router. We can even be router to router. Here's, all right, so in this example, let's draw it again. As an example, this is RungSit. And this portion is our campus. Whereas this part is the public internet. So although it's not to scale, so this is a server at RungSit and our router that connects the RungSit campus to the internet. And then here we are on our campus, our Wi-Fi, our router that connects us to the internet. We don't trust the internet. It's a public network. When we send our data across it, assume someone could intercept. So if we want secure communications between computers between our two campuses, we can use IPsec in this manner. Run it on the routers that connect our internal network, so internal here to the external internet. And from this router at RungSit, from the internal RungSit campus to the external internet, run IPsec on them. So again, host A sends something to host B. There's no encryption used here. We send it across the wireless LAN. We trust the internal network as an example. We hope that no one will be able to intercept across this portion of the network. We send it internally to our local router. And then that is set up to encrypt the data there. So the original IP datagram from A to B is the data. That datagram goes to the access point. It goes to router X. And then the IPsec at router X is set up to take that datagram, encrypt it, and add a new header saying from X to Y. And it's sent across the internet destination Y. So from the routers and the internet perspective, they see a datagram. It needs to get to Y. So it's sent across the internet. It gets to router Y. IPsec receives it, decrypts, or removes the outer header, decrypts, and we get the original datagram back. And it sends it on to B. And B receives exactly what A created. So in this case, we have encryption across the public network, not internal. The advantage, even more so than before, none of the hosts need to be set up to use any encryption. You just use your normal applications, your normal operating system set up. All the hosts internal on each of the campuses just use their normal applications to communicate. But everything sent across the public internet between the campuses is encrypted. So this is another example of a virtual private network. So communications between host A and B are private from the perspective of the public internet. So it's shifting the security to a device, in this case, a router that has the advantage of it can encrypt everything for all hosts, no matter how they're set up. What's the disadvantage here? What's the problem? For example, comparing the three IPsec cases, this one versus this one. Let's compare these two first. What's the disadvantage of router to router versus the previous case? Okay, so we have no encryption here. So there's our first problem. We must trust this portion of the network. If we cannot trust it, then we have a problem because someone could intercept our data. But if we can trust it and we'll come back to why we may trust it in some cases in a moment, but if we can trust this portion of the network, then this seems okay. Maybe what's another problem? Performance problem? What's the problem of doing this? A potential problem? If the connection fail or be more specific, if what fails? If, okay. The encryption, everything depends upon this router. Let's say we have not just host A, but we have hundreds of hosts in here, all sending outside. Then everything goes to router X, and that does the encryption. So we depend on this router to do the encryption. Now, all right, if this router fails, then of course we cannot encrypt and send out. But maybe more practical, there may be performance limitations here. Encryption takes time. So now this router must not just receive packets and send, but receive packets, encrypt, and then send. And encryption is actually a processor intensive operation. So we need a faster router to handle the data being sent out. So there's some performance implications there. So this is using the concept called tunneling. And we're not trying to explain tunneling too much, but this idea of we see we're putting the original IP datagram inside another IP datagram. And that's common in tunneling. So we had our original one, header was saying from A to B, we take all of that IP datagram and put that as the data inside another IP datagram. So we have a second header. And this is the concept used in tunneling. We've seen example, I've shown examples using IPsec. There are other technologies that will do this creation of a virtual private network from one point to another. So IPsec can be used in this tunneling mode. Other common ones, you may see a PPTP, L2TP, some tunneling protocols that are used to essentially provide virtual private networks. This concept of connecting host to router or even router to router and encrypting at those points. And the advantage is that the support for those protocols and the configuration that's set up is done only on those end points. So we only need to set up two routers to support this as opposed to set up thousands of hosts. So for the network maintenance, it's much easier. Of course, it does not provide end-to-end encryption. That's our disadvantage. We must trust some portion of the network. How do we trust this portion of the network? Why could we trust this? The wireless LAN is a questionable part. You know that you can very easily intercept across a wireless LAN. It's very easy. And in fact, for a wired LAN, I said the other day that maybe if I was malicious, I could plug a device into there and tap into the wired link. But that requires me as the malicious user to get physical access to this point, to this building. So let's say we have a security guard that watches everyone who comes in. It's much harder to get physical access to the building. But with wireless LAN, with this wireless access point, to intercept, you don't have to be inside the building. You could be outside maybe in the car park because the wireless signal travels across a, is not just restricted to the building. So you could be out on the street and still intercept packets being sent across the wireless LAN. That's why wireless LAN security is a problem. So in practice, we can set up wired LANs which are reasonably secure because you need physical access to the building to tap into it. But wireless LAN is much harder. So if we want to trust this internal network, we need to deal with the wireless LAN. And I think most of you know that you can do encryption across just the wireless link. You can set up your wireless LAN to encrypt the frames just being sent across that portion of the path. An example of, this is an example of link level security. Encrypt at one endpoint of the link, decrypt at the other endpoint. So it's not for the entire path. But it's very useful when some of our links are using wireless technologies or less secure technologies. So with Wi-Fi or 802.11 in the past, there was something called WEP as the encryption protocol, but had some flaws. And the common one today is referred to as WPA, Wi-Fi Protected Access. And there are some variations to it, some different versions and different options with it. But in general, Wi-Fi Protected Access takes our, so our application generates data, IP datagram is created. Normally we send a wireless LAN frame across our wireless link from laptop to access point. Think of WPA encrypts that before it's sent. We encrypt and send such that if someone intercepts by listening in out in the street, all they see is the encrypted frame. They don't see the contents. The access point when it receives it decrypts. So that's another form of encryption. So an example of link level security just encrypt across the links. Both of them need to be set up to do the encryption, to use WPA in this case. And there are different ways to do it, but the simplest way is that I set up my laptop to, as the user, I enter in some secret. And that secret key is also set up on the access point. Okay, so this is convenient if you're using, say, home networks. You know, or you operate the access point. You also operate your laptop, so you can set up and set up, choose the secret key on the access point, choose the secret key or enter it in on the laptop or tablet, and they will encrypt using that secret key. So that works fine. It becomes a little bit harder to set up this key management aspect of it when you have multiple access points and many different users. Because if I set a secret on my access point, how do I get every other student to know that secret without maybe writing it down on a web page? How do I conveniently distribute this secret to you? So that's a problem with securing wireless links, getting, setting up both endpoints to use the same secret. But there are ways to do that in enterprise networks, in large networks. Yeah, so the same issue with the public Wi-Fi. There's an access point that's provided by TOT somewhere in I, down in the other building. And they allow anyone to use it. But again, we have this problem. If you want to use encryption across that, both endpoints need to know some secret. And typically in most simple access points, there's no way for them to do that rather than manually share that secret. So how does the operator of the access point get that secret to every user that wants to use it? Not easy. All right, maybe print it out on a piece of paper if you go into McDonald's and they want to give you free secure Wi-Fi, they can print out a piece of paper, the secret for today and you use it. But that's very inconvenient. So setting up the wireless link to use encryption has an issue with convenience. There are ways that you can use another server that will help with the setup. For example, use HTTPS to connect from some special application to some internal server that will then set up the secret for the wireless encryption. But that gets more complex. But for now, just understand that we can use link-level encryption across, in this example, Wi-Fi, but other technologies also have link-level encryption. How to set that up is something will not go into it. But it's interesting. So many wireless technologies, especially have encryption capabilities. Bluetooth, different wireless networks, mobile phones have GSM, uses encryption for voice calls, sometimes secure, sometimes not. But there are many different link-level encryption techniques. Again, what's the advantage? All data sent across the link, it doesn't matter what application you're using, HTTP, SMTP, email, TCP, UDP, doesn't matter if you're even using IP, maybe you're using other network protocols. It's all encrypted. So that's the advantage. The problem, it only applies to that link. And it usually requires configuration of the endpoints. So setting up this shared secret key on those both endpoints. In reality, we use a combination. Okay, so although I don't have a picture, we could use, in this case, WPA across the wireless LAN, trust the wired LAN, and IPsec across the public internet. So we can start to combine the different technologies and approaches. We can use just skipping back. You'll see that sometimes, although it may not be necessary, there may be wireless LAN encryption and also transport layer encryption. So it's not just one solution that's used on its own. You can use a combination, multiple levels of security. And I think that brings us to the end of this aspect of internet security. Any questions on, so we've gone through application, transport, network and different variations of network level security and just quickly one on link level security, just as an example. Any questions on those four? Could we use IPsec compared to the, how fast or how delayed would you be? Okay, so we said that there's issue of performance. So if there was no IPsec, we have a router receives a packet and just sends it. And if there's IPsec, a router receives a packet, encrypts it and then send it. So what's the performance degradation here? Well, it's a time to decrypt and at the receiver to decrypt. How long does it take to encrypt? Did you do in, you've used OpenSSL, in OpenSSL you can do a speed test. If you just run OpenSSL speed, it will give you some typical results of how long it takes to encrypt data of a particular size. So using AES, how many bytes per second you can encrypt. And I don't remember the numbers, but you can see that it's in the order of, I don't know, maybe tens, hundreds of microseconds per packet, maybe milliseconds, it differs depending upon the CPU. But you can measure that and you can work out how much impact it would have on your applications. But it adds something that's noticeable if there's thousands of packets going through this router per second. But I don't remember the exact numbers of how long it takes. Next week we will finish with just a quick example of secure email. And there may be one or two new slides or some discussion of aspects of, some aspects of privacy, like how people track based upon IP address and cookies. But not much new. Hopefully we'll finish on Tuesday and leave Thursday for some final review and preparation for the exam the following week.