 I will start with providing a short overview of three slides on what is IPsec, but then I will spend some time to show how it is used in practice. Then we look at the standards that exist, and then say the main stuff starts. First, we will discuss the two modes that IPsec is supporting transport mode and tunnel mode. Then we look at the two main protocols that IPsec has AH, authentication header, and ESP, encapsulating security payload. We will have a short look at IPsec and virtual private networks, and then we look at the third IPsec protocol, this IPsec key management protocol, and then I summarize stuff. So that's the plan for today. The break will be somewhere in here, I assume. So let's start with the overview. What is IPsec doing? Well, it is providing you with three security services. The first one is data authentication. So you can be sure that the data is indeed coming from the person machine that you expected from. The second source is data confidentiality. So if you send something, you can be sure that no one who can tap the wire would be able to decrypt the content, and it offers data integrity. So if someone captures an encrypted packet, would change something or recent it later that would be detected. It also has the key management protocol to take, for example, or to manage the keys that you need for authentication as well as confidentiality encryption. Why would you need such protocol? Who has an idea? Can't you just simply give keys away or if you have an X509 public key infrastructure, can't you simply use it? The key issue is, and that's also what we will see next week if you look at HTTPS. The key issue is that if you use public key encryption, it's a factor of thousand probably less efficient than symmetric keys. So CPU overhead is quite high. So therefore, you usually see with all security protocols that people start with public keys to create a secure channel. After they have created that secure channel, they use that to create or exchange a symmetric key, and after that, they use a symmetric key. That's say also the purpose of this key management protocol. At the end, you have symmetric keys that you can use. You also have some other things that at a certain moment you have to change it, et cetera. But we'll come to that later. IPsec is an option in IP version 4. It originally got included in IP version 6, but I think now it's optional again. I have to look it up. Anyway, what is happening is in both protocols nearly identical. So what I do for the lecture, I only focus on IP version 4. I already said that IPsec has multiple protocols. You have the AH protocol, authentication header protocol, or the encapsulating security payload, and you have the third one, the Internet Key Exchange protocol. Usually, you start with the Internet Key Exchange protocol to create your symmetric keys. After you have that, you do everything else with either AH or ESPs. As we will see later, ESP is by far the most popular one. Why? Well, if you look at the kind of services that it is providing ESP and AH, you will see that ESP has confidentiality, whereas AH doesn't have this. So if you want to send data encrypted over the Internet, you have to use ESP. You can't do it with AH. Originally, AH was able to do authentication whereas ESP was not able to do authentication but later, and in that scenario, you would have to use both. But later, they added to ESP the option to also have authentication. So basically, you can do everything with ESP whereas AH is a bit simpler but you can't do encryption. What else can you do except authentication and encryption? You can do access control, which basically means that if you have a virtual private network, you can limit access to your virtual private network to only those people that can talk IPsec with you. Replay protection, so if someone captures a packet, the firewall should be open say between nine and five, and you capture that packet and you replay it in the evening, then it will be detected as a duplication and thrown away. Integrity means that it will detect if you modify some bits, and finally, you have non-repudiation. Who knows what non-repudiation is? You can't say how what you are saying. If someone received a message from you and you later say, but it wasn't me, it was someone else, like spoofing or whatever, that can't be the case. The fact that someone has a message from you is you can mathematically prove it must indeed have been from you. It cannot have been generated by someone else. But this is an option depending which algorithm you use. So this is IPsec protocols. Now let's look at ways how you can use IPsec. You can use it in multiple ways. You can have your machine install IPsec on your machine and just connect to the Internet and send from your machine IPsec packets. What you can also do is that you have a local area network and you say, well, I don't want to reinstall on every machine IPsec. So a lot of work and blah, blah, blah. So what I'll do is I have my local area network. Access is very limited. Internally, I just use plain IP version 4. But everything that goes from this branch of, say, the bank to that branch of the bank, so this is, say, Rabobank in Enschede and this is Rabobank in Utrecht, everything that goes from Enschede to Utrecht, is sent over the Internet via IPsec gateways that include an IPsec header there, do something with the payload, send it over the Internet so people on the Internet cannot decrypt it, cannot modify it or whatever. It goes here and this security gateway is then stripping off the IPsec stuff and just creates a plain old IP version 4 packet out of it. So this is, say, a kind of virtual private network that you can do, which you can also, what I said, directly run on your machine IPsec. It is basically included on most operating systems. I'm not sure if you have a Raspberry Pi, if it is on the Raspbian, but if you are Linux, Windows, OSX, it's there. OK. The first thing I want to do is look at, say, how IPsec is used in practice. I use some old slides, but, say, the ideas are still the same. But before I do that, probably I ask a question to you. Assume you want to communicate securely over the Internet. What protocols could you use for that? TLS. Sorry. Yes. 100% correct next week. Yeah. What more? SSL or? It's not that, but it is a previous version of TLS. Yeah. What else? Yeah. What's the relation between HTTPS and TLS? Any clue? You know the answer, I guess. So it is really simple. HTTPS is just, say, the name. And you use internally TLS as, say, the protocol for that. But I'll come to that next week. But it is basically the same. Other protocols for secure communication? Yeah. SSH, of course, also next week. What is most popular? HTTPS is, say, very popular. Yeah. In the past, people assumed that IPsec would be, say, the dominant security protocol. And that is what we will see at the end of this lecture if you look at conclusions. IPsec is not easy to implement. And it turned out that if you do security point to point at a higher layer, transport layer, that that's much easier. So all websites use HTTPS or TLS. If you log in into another machine, you usually do it via SSH. So IPsec usage is not so high as people expected, it's, say, 10 years ago. So let's give some numbers. These are relative old numbers. I would have liked to update them, but they stopped collecting data on the internet, too. The internet, too, is the same as the surfnet, but then in the US. And there were some volunteers collecting data. So what you see is that in 2010, more than 2% was SSH, HTTPS. So this was roughly the same. IPsec ESP was, say, only 10%. IPsec AH is virtually nothing. So here you see terabytes versus gigabytes and the key exchange protocol, which you only use at the beginning, is also very small. If you compare that to, say, a couple of years earlier, you see that SSH already was high, but HTTPS has been going up. And I think HTTPS, whether I can easily check it, is by far the most used security protocol now. So IPsec is used, but not, say, as much as SSH and HTTPS. So network layer security is being used, but not as much as transport layer security. Here are some figures, and you see that this is SSH. This is logarithmic, so you see something, is it logarithmic? No, it's not logarithmic. It's linear, so at least you see a kind of logarithmic. So this is HTTPS. This was more straight. This is more zoop. Also, IPsec is, in that sense, still doing relatively well. That's ESP, but if you look at AH, it is not much. And that's IKEA. So what is it that you should remember? In practice, transport layer security is more used than network layer security, but still IPsec is used and is important. Standardization of IPsec, what can we say about that? Well, if you look at standardization, you can make a simple figure which puts together the various pieces that are being standardized. So there is a document. By the way, it is standardized in the Internet Engineering Task Force. I'll come to that a little bit later. They have an architecture that describes how the entire thing works. And then they split into two kind of protocols, the ESP protocol or the AH protocol. So you have a separate RFC that describes ESP and a separate that describes AH. In the ESP protocol, you can use encryption. So ESP protocol specification points to several encryption algorithms. And you can also use authentication algorithms, whereas the AH protocol can only do authentication. So the AH protocol points to various authentication algorithms, but not here. So if you implement something, you have to start with reading this, then this, then you have to take some of these. The encryption algorithms are not just, say, the AES standard or a triple dash or whatever, but it is also how you use it in the specific context of IPsec. So these are specific IPsec documents. Then you have a domain of interpretation, DOI, not Document Object Identifier. The domain of interpretation basically gives numbers to all kind of things so that if you send something, then you can identify which encryption algorithm you use by using the abbreviations specified here. And finally, of key management. This is all doable, but if you then look at the different RFCs, internet drafts, then just for IPsec, this is, say, a subset of what exists. And I'm not going through it. I just want to impress you by the high number. Don't ask me about details about all of them. Maybe I know some, but not all. But you see here lots of stuff that is related to IPsec. But if you go to the internet engineering task force, they are not just doing IPsec, but they have lots of, say, security working groups. You have, say, the IP, I'm looking to give some examples. You have, there must be something here, I think, or at least it's not sure. You have, say, TLS. You have secure shell. You have secure mail. You have Kerberos. You have, well, SNMP, something I've been doing a lot. So there are many groups that all have many RFCs. So what is the conclusion? Security standards, security activities. There's a lot of it, and we are just scratching the surface of the iceberg in this lecture. We'll still get into enough detail to confuse you. OK, let me now look at, say, how things are running. So I said earlier we have two modes, transport mode and tunnel mode. And if you look at the packets that go over the wire, you can immediately see what is what. Assume this is the original IP, version four packets. You have an IP header and your payload. Payload usually starts with the TCP or UDP header. If you use transport mode, you add, after the IP header, but before the payload, so before the transport header, you add an IPsec header. Whereas if you use tunnel mode, you keep the old IP header that you have from here. You don't change it. You don't change the payload. So this part, the last part, white part here, is exactly the same as the original IP packet part. You, again, add an IPsec header, but you include a new IP header. So this is a bit bigger than this, of course. Um, question. If you receive a packet, how do you know if the packet is a normal IP version four packet, an IPsec packet in transport mode, or an IPsec packet in tunnel mode? How do you decode that? What you see in many protocol headers is that there's one specific field which tells what comes next. And so if you have plain old IP, it says, there's a field which says, next header is TCP or UDP, yeah? If you have IPsec in transport mode, then the IP header does not say anymore that UDP or TCP is coming. No, it is saying that IPsec is coming. And in IPsec, you have also a next header field, which is now saying, hey, UDP or TCP is next. And so here you have exactly the same. The new IP header points to the IPsec header. In the IPsec header, you point to the old IP header, and in the old IP header, you point to the TCP or UDP payload. Um, general question regarding networking. So this trick that you have here, a header field which tells what comes next, would you be able to have 10 IP packets in each other? Well, basically what you can easily do is have indeed, say, an IP header which points to another IP header, which points to another IP header, which points to another IP header, which points to another IP header, and at the end you somehow point to TCP UDP content. So that is perfectly possible. It doesn't make a lot of sense, but maybe from a, say, a security point of view, it would be nice to experiment with that. See what happens with, say, firewalls. I don't know. Okay, so the key to distinguish them is that the header fields, they all have a next field, which tells if UDP, TCP, IPsec, or in this case IP, what comes next. Okay, how is transport mode usually used? Transport mode is, say, usually used in a scenario where you have your computer, which is directly generating IPsec packets and you send it over the internet. If you look at tunnel mode, you have a tunnel mode, this new header and this old header, that's typically used if you have security gateways in between. So I gave you the example of the bank earlier with a branch in yesterday and one in Amsterdam. And the bank has security gateways, so they will usually use tunnel mode. Why can't you use transport mode in the case of these banks? So in the case that you have security gateways, can't you use simply here the IPsecAH, sorry, IPsec transport? Yes, so what you have, you have here an IP header which says which source and IP address you're using and here you have the old IP header which also tells which source and IP address you're using. If you look at the old IP header, what source and destination address are there? Well, easy from this source and this destination. But if you look at the new IP header, what is the IP address from the source? Is it this system or is it this system? It's the gateway, yes. And what is the destination IP address? Of course, the other gateway. So these are systems that have different, sorry, this and this are different systems, they have different IP addresses. So you can't put here the same, say, source IP address of this one, et cetera. Yes, so the security gateway here is configured such that it knows this security gateway. It doesn't need to know which systems are here. So if you have a bank with thousands of computers in Amsterdam and thousands in Amsterdam, you don't have to configure all these thousand computers. You just tell the security gateway in Amsterdam about the details of the one in Amsterdam and visa first, good question. Yes. The first thing that you say is that this machine should know the IP addresses. So the machines in Amsterdam should know the IP addresses of the machines in Amsterdam. That is correct. Your second statement, that means that they should have public IP addresses is incorrect because you can have, within a bank, you can have a private IP address space. And so if you start with 192 points, blah, blah, blah, or 10 points, these are private, say, addresses that will never be routed over the internet. It may be included internally, but it can't be and say the outmost IP header which is used for routing here. So you may have here private addresses. What you do need to make sure is that address space here and address space there is somehow coupled. So probably you have a DHCP server only in Amsterdam or you have two DHCP servers, but they're configured in such a way that they don't give away twice the same IP address. You should have a DHCP server that can be in the security gateway. It can also be a separate machine, but that DHCP server, if it is here or here, should know about also here. There's a question over there. Yeah, yeah. So your question is what about access control? Take, again, the example of the bank. Amsterdam, everything that is sent from Amsterdam via this security gateway arriving here will be accepted here, but everything that this security gateway receives which doesn't come from the trusted or the security gateway is just rejected. You throw away everything. So only from here data may get in in Amsterdam. So the question is now what happens if you spoof the, say, the addresses? Well, if you set up the IPsec, well, I call it connection, although it's not a real connection. They use the term association. If you set up an IPsec association, you can spoof in the first message, say, the source. It goes to here. This one sends it back to the spoofed one, but that's not you. It's someone else. So before you can do anything, know about keys, et cetera, yeah, you never receive the response. Probably you can do something in specific scenarios where you have, say, a man in the middle that also sees the response, but then still at a certain moment you have to tell here what is my public key and that should match with your private key. The other one, the man in the middle, will know the public key, but doesn't know your private key. So it's unable to decrypt stuff. So men in the middle attacks with spoofed IP addresses will not work. I'm not saying that there are not any security holes still in the system. Question there? Sorry, IPsec itself can basically do the access control. Although you have a couple of things which run, say, usually still on top of that point-to-point tunneling protocol, you can run it on top of it or some other things. But basically you can already do it with pure IPsec. So you don't need, well, alternatives are open VPN and this kind of stuff, you don't need that. You can see it as a competitor. Okay, let's now look at the functionality. Oh, yeah, sorry. Of course, a combination is also possible. That you have somewhere a laptop that wants to connect to the bank in Amsterdam, but the laptop is equipped with IPsec, knows everything about it and can directly send also tunnel mode packets. So earlier I showed you that such system can send transport mode packets, but you can also send tunnel mode, no problem. Yeah, let's look at functionality and compare. Yeah, no, let's dive into IPsec AH and then compare AH versus ESP for transport mode and tunnel mode. So remember, we have here lots of choices. We have the choice transport mode or tunnel mode. Usually tunnel mode is more powerful than transport mode, but why wouldn't, are there any disadvantages of using tunnel mode? So if I go back here, this is tunnel mode. Are there also disadvantages of tunnel mode compared to transport mode? Yeah, yeah, performance is a problem. It has to do extra processing indeed, but that's not the main problem. Source IP is visible, that's also not a problem because always the outmost source IP at the west should be visible, whatever you do. I think I heard the right answer. So can you say it again? Yeah, so you have say an extra IP header. So this is longer than the original, say IP version four or the transport mode packet. Why is that a problem that it is a little bit longer? Sorry? Fragments, yes. So what happens? If you send data over the internet and assume you do file transfer, then if you have huge files, you break the packets up into smaller pieces. What is the average piece that you sent over the internet? 1500 bytes, yes. Why 1500 bytes? Who knows why 1500 bytes is say the, that we can't do amplification. That's not the right answer. So let's go there. Yes, internet is not able to have bigger things. It's a completely different kind of lecture why internet is having the 1500 bytes maximum, but it's just, internet is everywhere and so it dominates how big the packets are. So if you send a huge file, you split it into many packets that have roughly 1500 bytes. You don't want to split it into many packets that have just 1000 bytes because then you have to send more packets. So you try to be as close as possible to 1500 to make the number of packets you have to transmit as small as possible and thereby make transfer as fast as possible. But if you come too close to the 1500 and you don't have just tunnel mode but you also have all kinds of other options, then it might be that you just go a few bytes over the 1500 say border. And then the packet will be split into multiple and you get fragments and these fragments, they take more time. They have to be reassembled. It's the receiving part. They sometimes have problems to pass firewalls and so you try to avoid that. So there may be cases where you have optimized things. Things go extremely fast. In transport mode, it's just fitting into 1500 bytes and then you add a new header and it doesn't fit in 1500 bytes. It has to be fragmented and you see performance going down. Question there? Yes, so the payload field should then be, should have been a little bit smaller but the problem is that if you from the application are sending something, you not always know exactly what fields will be added in front of it. So you make a guess and the guess may be wrong but I agree with you. You should try the application layer not to stretch it to the maximum because then things in between happen, you don't know and you run into performance problems. Yeah, question there? Yeah, there are techniques to allow you to more precisely predict how big you can be but not always say ICMP packets get responses and sometimes they are filtered. And roll off. Yeah. If the entire world would move now to exactly the same implementation of IP version six and we all agree on using just one thing then we wouldn't have any legacy problems. But if, Roland Vereisweig who gave the third lecture I spend a lot of time on making DNS say working and if you are a bank and just 1% of your customers or say one tenth of a percent of your customers are no longer able to reach you, you have a severe problem. If you are booking.com and you lose one out of 1000 customers that's a lot of money, you don't want that. So, okay, so what is AH and ESP doing? Well, no, first what I said we have transport mode tunnel mode, so you have two options and then you have the option to choose between AH and ESPs. ESP is encrypting the IP payload. If used in transport mode, if it is used in tunnel mode it encrypts the entire inner IP packet. What is the difference? Here it encrypts the TCP UDP payload and here it also encrypts the inner IP header. If you don't want to make details regarding the IP structure of your bank and answer day visible to the rest of the world, please encrypt the inner IP packet because then they don't know anything about the number of machines that you have. If you use transport mode, then yeah, you would be able to see that stuff. AH is not using encryption but it is using authentication. It uses the IP payload, so the TCP UDP plus selected portion of the IP header for authentication. So not all the IP header, I'll come to that later. And if you use the tunnel mode, it again authenticates the entire inner IP packet plus including TCP UDP payload plus selected portion of the outer header. I'll come to that later what I said. ESP with authentication encrypts payload and uses IP payload but not IP header for authentication. So here you see a small difference. Portions of the IP header here are authenticated in AH but not in ESP. So here you have less of the packet that is protected by say your hash. So if people try to modify things, it would still here be possible. I can then argue that if you do that, that would not lead to severe security problems but there are still then cases where things might go wrong. So that gets too complex now. I think I spent more than 45 minutes so it's really time for the break. Yeah, before the break that this header is included before say the IP header and before the payload or probably another IP header. If you look at the AH header, it's not very big. So you have these are four bytes each. The first byte tells the next header. That was the field that told you if the next thing that comes afterward is a UDP packet, a TCP or say UDP content, TCP content, another IP header or whatever. Yeah, payload length. The payload length is, I'm looking here, is the length of the entire thing I believe but I have to look that up. So I don't know, reserved. Then you have the security parameter index SPI. That's an important field. The security parameter index is basically just a 32 bit number. Which may seem random but it should be unique between this source and that IP. And it basically is a number that is used by the sending and receiving entity to look in the database. What are the encryption algorithms that we use for this association? What are the authentication algorithms that we use? What keys currently belong to that? So it's a pointer into a database that tells you everything that you need for encryption, decryption, authentication. Further, it's just a 32 bit number. Then you have a sequence number. I'll come a little bit later to that AFT authentication data. The authentication data is say in hash over the content so that if someone modifies something, it doesn't match with this hash anymore and you will detect that something is wrong. This value of the security parameter index is unique for the direction from A to B. The opposite direction from B to A. You don't use the same number but you just have another number. So this number is unique for a security association but security associations are one way. So if you capture data, the SPI field in one direction is different from the other direction. That's also part of the exercise. Here we see a sequence number and the sequence number is used for replay detection. But can you think of other ways to detect if a packet is being replayed? Assume you have to design a protocol from scratch. Would there be an alternative to sequence numbers? Yes? Yeah, so you can also include the current date and time. Do you happen to know if there are secure protocols that use date and time? Okay, I don't know. You may be right. The thing that I know is for example SNMP. So SNMP version three, which does security, is using say current time. Not precisely, it has boot time and time up. Why is, yeah, in what case should you use, say sequence numbers? In what case should you use time? It's very easy in fact. In the case that... Yeah, but you shouldn't confuse the sequence numbers that IPsec is using from the sequence numbers that TCP is using. They look similar. They may probably even have the same values, but TCP is doing the retransmission. IPsec will never do retransmission. Basically, it's very simple. If you send lots of data, then if you send the current time, you always have then to have a certain period in which you still accept, say packets. Then you can have lots of packets. If you just send one packet every five minutes, then it is not very useful to use sequence numbers because the sequence numbers are used in conjunction with the window. And if you use, for example, SNMP, and you query a router every five minutes, how many packets did you receive? And that is a single query. Then you increase the sequence number every five minutes with one, which you have a window of, say, 64. So you have 64 times five minutes that you're vulnerable. So what should you remember? There are multiple ways how you can do in protocols, replay protection, depending on how much you send. In some cases, it's better to use something in which you use actual time. And in some cases, it's easier to use sequence number. If you look at IPsec, it's using sequence number and a window. The window is usually 64 packets. And yeah, you basically check if something that you receive falls into the window. If it is older than the current window, then you throw it away. It must have been something that has been replayed. If it is, say, the next or close to the next, then you advance it, yeah? Yes, question? You start a sender. You start with, say, one, two, three, four, five, six, yeah? And here you have something like, OK, I accept the first 64 sequence number. So everything that is between one and 64, you accept it. Once the sending client is, say, 1,000, then the receiving site also says, well, I've just seen 1,000. So everything from 1,000 to 964 is 936. Everything, until that I accept. But if it is older, I'm not accepting. And if it's newer, I will slowly advance. So you just start and you keep in sync while the sender slowly moves up. The receiver also moves up. Question there? No, you don't have to remember that. Because before you start this internet key exchange protocol and you create there the SPI, how this index in the database, et cetera. And at that moment, you agree on a new sequence number. Or you could say, I start with one. So it's for the lifetime of the security association. And if you break the IPsec association and you restart something three days later, there's nothing that you have to remember. Why do you need a window? Why not just have, OK, this number has been sent. So that is what I should receive now. And you have just a window of one. Yeah, you say if packets are missing. But that is what TCP is already doing. And so you shouldn't redo TCP. So that's not how you use it. Yes, packets may be out of sequence. That is quite common. Yeah, but that depends on how much things can be out of order. And what you often see is that you have load balancing mechanisms. So you send something and assume that you don't have. You have a five-geek connection outside to the external world. But you don't implement it as one five-geek interface. It's hard to buy. But you have five one-geek interfaces. So you do load balancing over these. So the router, something comes in. And you say, OK, let's now go here. And next time I go there, next time I go there. And things might go out of order. Many routers do try to avoid it. So they try to remember, oh, this comes between this source and destination. I always have to use this one to not have the out-of-order too much. Yeah, that's what they try. But still you see out-of-sequence quite often. So you have to accept something. 64 seems a reasonable value. OK, AH is calculating a hash over your data. That's called the integrity check. Secure hash is usually used. MD5 is still possible. So this is what you must support. There are some options that you can also support. What is interesting is to know over which fields this integrity check value is calculated. And if you read the text, it says it's calculated over the IP data, so TCP, UDP content, as well as the IP header fields that do not change in transit. So repeat the sentence. The integrity check value is calculated over the IP data in most of the IP header. But which IP header fields should be included in the calculation of the hash? So which fields do not change and which you should not? So IP version number, can that change? No, IP version number is version 4 or 6 and will always remain the same. So you include this. IP source and destination address. Can they change if you send something from A to B? No, they can only change if there's a man in the middle who's modifying things and that's what you don't want. So that's being protected. So someone who gets your packet, changes the source address into something else, that will be detected. Time to live field. Is that something that is, can that change if you send a packet from A to B? No, no? Yes, so some people say yes, some people say no. Who says no? It's only one now. And who says yes? What made you change your mind? I think you said first no. OK. Yeah, time to live is, say, every router that sees the packet is changing the time to live field. It's lowering it one. Why is it doing so? You say it has something to do with if the packet is really lost. Yeah, it can't stay in the internet forever. So if you have a routing mistake and you would have a circle and it would be rerouted again and again and again, then it would be lowered in every router and at a certain moment it reaches zero, then you throw it away. The fact that you can play with time to live is also from a security point if you're quite interesting because you can then go every time one step further. And so even in networks where you can't see too much, you can play with it. By the way, what we also do, there's also from a security point of view, quite nice. The first lecture, Jair told you about, say, DDoS attacks. And so what you often see with DDoS attacks is that they come from many source IP addresses. And depending on the kind of attack, these may be spoofed addresses or not. And so there are cases where you see many different IP addresses, UDP, DDoS attacks. But if you then look at the time to live field, you see they're all the same. So they come from exactly the same distance. Then you know that these packets are spoofed and that they're sent from one system. So you can use this to analyze, say, certain attacks. IP header lengths, is IP header lengths, is that changed over time? No, no, that is not changed, so you can include that. IP total packet length, will that change? No, OK. IP header checksum, yes. Why is that changing? Well, you change, for example, the time to live field. So type of surface field, is that something that can change? No, and yes. Who says no? I'm watching you if you change now to yes. I'm not sure. And there are people who say yes, when can it change? Well, the type of surface field is often used for differentiated surfaces. And differentiated surfaces tells if something should be sent very fast or with lower priority. But people could not agree on the exact coding. So if they go from one network to the other, then they agree, OK, this is something that has high priority. But the coding in my network for that is slightly different. So I change it. So that's one of the things how this can change. The actual surface type can also change. But if you don't support specific things, then you have to lower it. Throwing it away is not the good option. So yes, people, differentiated surfaces was, say, the promise, say, 10, 15 years back. Because people believe that we need for streaming or real-time applications, we needed a different surface. It's still being used. So voice over IP, for example, uses another type of surface field than FTP. But there are many networks that don't really support it. I'm not even sure if surfnet supports it. They just overprovision and have something like command. But I think type of surface is also used heavily by companies like ZIGO. ZIGO, I'm not sure. But companies that do video broadcast. So the video has its own type of surface field. OK, let's dive into the fields. This is the original IP version for packet. This is the new IPsec AH in transport mode. The yellow stuff is the stuff that is protected by this authentication data. So the secure hash or MD5 algorithm. Initially, you filled this with 0, so you don't count this. And so all these fields, if someone tries to modify just a single bit of it, you will detect it. So this is all protected. If you use AH in tunnel mode, you get something quite similar. In tunnel mode, you have here the new IP header. Whereas this is the original IP header. So this was the original IP packet. The header of this original packet is moved to this part. So the IP addresses that you have here are the same as that you have here. Whereas here, you can have the IP addresses of the gateway, et cetera. But what you see is that IPsec in AH tunnel mode is also protecting the outer IP addresses. So these addresses might be different from this. So the fact that this is also protected seems nice, isn't it? Or are there also problems if you protect that? So assume you're now a designer of the IPsec protocol. And you have to say, should we include this in the hash, or shouldn't we include this in the hash? Who would vote, yes, let's include it? People did it. Who says, no, I rather not include it? Why would you rather not include it? Yes, exactly. Who has network address translator at home? Who knows that you don't have a network address translator at home? And who has no idea? OK, I guess that people who have no idea that they do have a network address translator. On the campus, you don't. So you have Justin say, you are lucky. You could have put yours. No, but if you. But if I have it at home, I have Zigo. I have one IP address from Zigo. I have 10 Macs at home, all having local addresses. So I have network address translation. If I run my machines with IPsec and I want to communicate to the university or whatever, I have to pass my network address translator. I cannot use IPsec at all. So this is a question that, if I had more time today, I would have asked, yes, no, depends. Because people love the depends answer. But the answer is simply no. Why not? Well, this stuff is being changed by your network address translator. You can't avoid it. But this is protected. So IPsec will say, oh, someone modified the packet. Let's throw it away. So IPsec AH over net is not working. Not use AH. And then you say, ha, come on. But you could build another AH protocol, of course. But the answer is, and I use this as a bridge to say, IPsec ESP. And I will stop, say, in 15 minutes anyway. So don't be afraid. IPsec ESP has better chances to pass network address translator. But we'll come to that. So ESP. What is ESP doing? ESP is doing everything AH is doing, but also doing encryption. So it also includes an IPsec header. And the header looks like this. But it also includes here the payload. Because what you see is the header has a few bytes immediately after the IP header. And the authentication data is at the end. It again has the security parameter index, SPI, which was this pointer into your database with what keys and algorithms you are using. It again has the sequence number. Since you will have to analyze this for today's lecture, I'll tell you that there may also be cases where you have here the initialization factor of your algorithms. So if you use AES, which many people do, then here you have something which is an initialization factor for your AES algorithm. But if you use something else as AES, you may not need to have such an initialization factor. So this is protected. This is payload data. So that is the TCP UDP data. Then there is padding. Why do we need padding? Yeah, you have many, say, encryption occurrences that work on fixed-side blocks. And so your data may not be exactly the same. And so you have to pad it to make it in the multiple of these fixed-size blocks. So that can be anything between 0 and 255 bytes. Remember now, if you run this, you have your size such that it just fits in 1,500. You add this header, but oh, shit, also the padding. Now it doesn't fit anymore. And this can be a lot. OK, in the exercise, you have to play a little bit with this. So what are the, say, things you have to support? You must support desk CBC, which is, say, outdated, I would say. Triple desk would be the minimum. And for authentication, MD5 and secure hash the same as MD5. It's optional, and I'm not sure if they recently changed it. But triple desk, which would be much better, but, say, AES is the one that most people would choose, I guess. But there's still a couple of things that you must support. And probably this is a security problem, because you can downgrade to this and then you break this. So I think I skip this because I want to look at the discussion we just had. You have something that you encrypt. Yellow is for encryption and something that you authenticate. So this is where you create the hash over. So the hash is over this part. So this is in transport mode. So you don't include in the hash the source and destination appear to us. Nice. Remember the network address translators. So I can change this. Nice. And if you look at encryption, you encrypt, say, the TCP payload, but not, say, of course, the header, then you can't route it anymore. So OK. So this looks nice for network address translators. This is the initialization factor I mentioned earlier, which is not encrypted, because otherwise you have a problem with starting to decrypt. And you can also use ESP and tunnel mode. In tunnel mode, we again see here the new IP header. And this is the old IP header. This old IP header comes from this original packet. So the source and destination IP addresses are in here. Whereas these might be the same, but can also be different, say, IP addresses. So if you use a gateway, these are different. But if it is a single machine that is connected to the internet that doesn't need any gateway you have here, source IP address and IP address here the same. OK. Would this run over a network address translator? Who says yes? Who says no? Who says maybe? Why maybe? Over there? Yeah. Where's the port number? Yeah. So where is the port number? It's in the yellow stuff. Yeah. It's encrypted. Yeah. No? IP header. Yeah. But this is just saying with tunnel mode that if you decrypt it, the first thing you will find is a new IP header. In the IP header, it says somewhere, hey, the first thing that you find is, say, a UDP content. In the UDP header, it says, oh, but it's this port number. So it's somewhere, say, here. Do all network address translators look at the port numbers? You have four different types of network address translators in the past I presented them. Some are looking at ports. Some are not looking at ports. So sometimes it goes through. Sometimes not. But sometimes you do both. So you always do the, say, changing the IP addresses. Assume that you have multiple machines behind your net on your own local area network. And the entire family is doing something on the internet. So they all generate, or they all go to Facebook, yeah? And although they might then violate new European law in that respect, but OK, there's something else. They all go to Facebook. They have browsers that generate a source port number, such that if something comes back, that machine knows where to go through. But the network address translator is then often changing the port numbers such that you get unique port numbers to the outside world. Because it seems that to the outside world that, say, this is, say, the same and the source ports, you want them to be different. But it depends on the type of network address translator. What you see happening is that you have, where did I say that? You have an RFC that discusses IPsec net compatibility requirements. And what often happens is that there is an extra. So here you have a next field. And instead of directly going to ESP, you can include, say, a UDP. And from UDP, you go then back to ESP. And so you have then in between here something, which does include a publicly visible port number that can be manipulated by the network address translator and then things work. So you can get it working, but it is not easy. Yeah? Yeah? Yeah, but. The other side needs to know whether you're using it or not. Yeah. But if you start using IPsec, I'm looking if I can misuse this for, yeah, I misuse this bridge for the last part. Before you start, you run, say, IPsec key management. And there you agree on all this kind of stuff. And so there's kind of negotiation phase. If you both support the same options, then it will work. If someone is not supporting specific options, it's not working. But talking about options, key management, OK, six minutes. That's more than enough because it's very complex. You can do things manually, usually not a good idea. Or you can do it automatically. And for that, you use the internet key exchange protocol. The internet key exchange protocol, however, is not a single RFC that just describes implement this. No, it's a combination of internet security association key management protocol. I say KMP Oakley, S-K-E-M-E. I can't not really, say, pronounce that. And these are parts that something has been developed by Microsoft. There's something there. And so if you want to implement IPsec, the internet key exchange protocol, you have to look at many different documents to find pieces and glue them together. And to make things worse, you have even two versions of IKE, version one and version two. Assume that you used the automated approach with IKE. Then you basically have in this initial phase where you built up your security associations, you have two phases. First, you create a special channel which you will then later use to negotiate your symmetric keys. And then you create a child's security associations over which you really send the data. If you have sent a lot of data, you may close this and create a new one just to make sure that if someone breaks in between all this stuff, then it gets secured. This is what you keep alive. OK, so you have two phases. Still understandable. Let's look now at phase one. Phase one, you have two modes, the main mode, which has six packets in the aggressive mode, which can just do with three packets. Then you have options, pre-shared keys, digital signatures, public key encryption, revised public key encryption, whatever you want. There you go to mode two. And you have, again, a quick mode and, oh, no, sorry. You have only one mode, that's a quick mode, and you have three messages, but, again, many options. So if you are already lost, then you have understood the message. So there are too many options, which is a severe problem for the, say, interoperability of IPsec. To make things worse, they're not just a lot of options. They're not, say, safe default options that if you just negotiate at a certain moment, you will come back to that. It can be that you start with something, this is what I can support, this is what you can support, you start negotiating, and then at a certain moment. Although there would be a theoretic thing that you both support, you don't find it. Another thing is it looked complex. And if it is complex, you can deduce it, and you can create lots of stuff. And there's a lot of computation behind, and so your IPsec system gets overloaded. It's not just something which is difficult to implement, which takes a lot of time to, say, compute, but also something which is difficult to implement. And so the more complex the software is, the bigger the chance that our security problems with it. So IKE is something which might have many security problems in it, because it's so complex, and you have so many things. And what I already said, if you wanna implement it, you have to look at many RFCs, which, blah, blah, blah. So people started to work on IKE version two, which should improve this situation, should already, from the start, look at transferring stuff through network address translators. Okay, that's everything I wanted to say about IKE. So let's summarize. What do we have? We have discussed two kind of data exchange protocols, AH and ESPs. We also have shown that there are two modes, both for AH and ESP, transport and tunnel mode. In addition, we have a separate key management protocol, which had quite some options, difficult to implement. As a result, usage is below expectation, and there are various problems. Some people, there's somewhere a quote, I think. IPsec is too complex to be secured. It's an old quote already, but I somehow like it. You have network address translators. If you suddenly are in a network where you get a new IP address, so for example, if you are in a mobile network, then you might get the DHCP a whole time, maybe very short, and you get something new, and then, oh, it's not working. Why not? Performance, you may have this fragmentation stuff. Key management is time consuming, and you need also time for encryption and decryption. This sounds a bit negative, but I decided a while back to create, just to check how IPsec implementations are nowadays, so at home I tried. Can I create a VPN with IPsec, and it basically worked immediately, so it's not perfect, but it is working. Questions? Yeah, I took the stuff that is on my OSX server. I just clicked on a few things, so it is ESP, it has all the stuff to transfer network address, translators, et cetera. That was really easy, except that it doesn't, cannot handle all the, say, key value, sorry, yeah, the key values, so you have to enter a key, and with certain characters it has problems, and it seems that on iOS it has also such kind of things, so you should be careful there. That, in fact, is based on open source, and I forgot the term, but it is basically what you find in any Linux environment. Any other questions?