 All right, let's get started. I figured out how to present our point on my machine this time. So hopefully it will work. I just used bra lines. Okay. I actually went to the wrong classroom and then had to sprint here. But I ended up in WP carry. It was here, right? I ended up at six. Awesome. Obviously I'm not Adam. As much as you might all just not meant to be. I'm a young. I'm here. Today and Thursday. I made out and go to London. So this is the payback. So. Another confirmation. This is where Adam ended up. Since, since getting. Yeah. Paper. So let's start back up with. Also known as half open scanning. I've never really heard of it. I mean, it is also known as. And that makes sense. I've never heard of it. Have you seen a. Yeah. And all of these classes. Oh, you did. Perfect. Okay. Sorry. We are. You're at the same flooding attack. You did all this fingerprinting. Yeah. To be spoofing. To be hijacking. To be spoofing. To be spoofing. To be spoofing. To be spoofing. To be spoofing. To be hijacking. I see. Sin flooding. Okay. A different type of attack also. Has to do with sin. Packet. With. Sin flooding. And with a lot of other. Denial service and tax in general. The. Attacker takes advantage of this concept. That for many operations. Something that is very easy for the attacker might be just a little. And so the attacker. In this case. Open the connection. To a normal server. All the attack has to do is send a sin packet. Right. If the attackers are planning on actually connecting. To the. The system or doing. Anything with that. They don't have to. Actually keep any state. They just send one packet. Whereas the server. If it is. Trying to. Actually handle the action. It has to hold some states. And say, oh, I got this in packet. I'm going to respond. With an act. And I'll wait for the. All right. I'll respond to the sin act. And I'll wait for the. Sin packet. I'll wait for the. Sin packet. I'll wait for the. Sin packet. I'll respond to the sin act. And I'll wait for the act. Right. In order for. The server to be able to connect. That initial sin. With the. Act that finishes the handshake. He needs to hold some state. You say, okay. I've received this thing. I'm waiting for that for that. I received this. I went for that. I received this. I went for that. And as the attacker sends more and more sin packets. The defender runs out of. Resources to track. Right. This. Each sin packet might take a time to memory. To track. But in aggregate, they add up. Right. I have any of you try to. One from your machine. And seeing how, how many packets you can send them a second. Let me show you. This used to be all the rage back when. I was. Now base. There's not much that. My machine could do to overwhelm the server just by flooding it with, with. Back in the day before. Network cards would actually handle a lot of themselves. Before a lot of this stuff was. a server with a pink flood, right? Have you talked about ICMP in this class yet? So just another type of packet, a type of protocol, PC, UDP, their other one's ICMP is basically a... Just a protocol to... Off the top of my head, I don't remember what ICND stands for. Do you remember, Max? ICMP? Yeah, they're that connectivity management protocol, something like that. So it's basically to test connectivity, right? So if I ping Google.com, of course, who are here has done the ping? All right, perfect. So if I ping localhost, this ping's localhost, I respond. And of course, when you do ping, you send one a second. You can also ping flood. This floods my local machine with things and every dot is like 10 things and it's deleted when the response is received. So you can see just from that short time, they took me to say something, it was 690,000 packets were transmitted, right? That's a flood. I can also ping flood Google. This isn't very nice, but we're not nice people here. That was much slower, 477. If I remember correctly, the thing utility rate was based on how many packets I've responded to or something. But you can just flood packets. No one's stopping you from that. Except for eventually, if the network admins are paying attention, you will get a drop off the network. But that's okay. Anyways, the point is it's very easy to generate a lot of packets. In the same way of generating ICMP packets with ping, I could write a very quick program in Python just to generate insane amounts of SIM packets and seminal. If for every SIM packet, the server weighs just four bytes of memory, then in a billion packets, I can exhaust four gigs, which is quite a lot. And realistically, these early servers, when this attack was relevant, took more than four bytes to act at some stage for an additional SIM packet. So the basic idea is you send a SIM packet, the server sends a SIM act, and you just move on with your life. And the server is just waiting there with the messages on red and whatever. So this is what it made a problem. How do you fix this problem? There are a number of things proposed. One solution was filtering. So you say, OK, we're just going to sit on the network and say, as some sort of a monitoring process, running on the server, on the server, whatever. They say, OK, there's two names in packets from this host. But that's annoying as false positives. You're going to increase the limit of the people at use. They say, you don't actually accept arbitrary amounts of connection. You only support 100 half-open connections at a time, and then future connections are just rejected. So this is 1.5, the solution number 1.5, as we get two solution dues. What's the problem with that? So you need to take down a server and others. Yes. Then I will serve. So now you've taken down from taking down the server or life. Because it runs out to taking down the server because it's off the network fundamentally because it's not accepting connections. That's not much better. So you could also say, OK, well, then we're just going to have a really long queue. But it turns out, realistically, these sort of things, that no matter how long the queue is, the attacker will be able to exhaust it eventually. You could reduce the timeout, after which you will forget about that half-open connection. This has some problems. There are, again, false positive rates. There are legitimate issues that might cause a fine lack of the handshake to arrive well after that SIDAC was set. SIDAC and TTP is supposed to support that. So you don't want to do that. You could have a kind of round, what's it called, a loop instead of a queue, where if you get a new connection, you drop the oldest connection that's half-open that you haven't finished the handshake with at a server. You might get away with that, but then this has similar issues running in the attacker, plus a lot. You will still start dropping network connections. You might limit per source, but as you've seen, it's trivially easy to spoof source references. And the final kind of concept that is being adopted was syncopes. Syncopes are described in this document along with some other ideas. If you are really passionate about these attacks, you can read this document. Who wants to have a reading class? So you should tell Adam when he gets back. RFC 4987. Tell your friends. So let's talk about syncopes. This is the solution that's typically used. I actually never really verified myself with the solution that's used. That's just what everyone says. So you can take a look, but it seems like a good solution. The basic idea is that the sequence number has some amount of bits that you can use. And it used to be that the sequence numbers were nice and monosonicly increasing. And so they roll over. You see issues with that, and so forth, with predictable sequence numbers. But the basic idea is that you use that sequence number as a sort of cookie in your syn packet. And the cool thing here is that this doesn't require any changes to the protocol. The TTP protocol doesn't say the syn number has to be blocked. It can deal with pretty much any initial syn numbers. And so what you do for your first sequence number, sorry, for your sequence number of your first syn packet is come up with a scheme where the top five bits is your counter. It's a five-bit counter. The following three bits, some other stuff. And the important thing is the rest of it, it's a key hash, a keyed hash of your counter. That's the first five bits. And the idea is an enforce of the source and destination. So you have basically a unique identifier in your sequence number that is keyed. So it's not easily reducible, ideally. You still remember keyed hashes and what's called HMACs and stuff, similar sort of concept. And when you create your first sequence number, you set it to this. And suddenly, you don't have to hold any state because you encoded all your states in a sine way in the syn sequence number. So when you send back a syn act, you send your syn cookie, your sequence number along with it. When you receive the act, you can look at that sequence number and you can say, hey, did I generate this sequence number? And that's very, very easy to do. You basically just kind of, you look at all the information that makes up the sequence number. Let's go back. Sorry, sequence cookie is simply here. You look at the top like this. That's your T. Now you have your T. You have the source and destination added to that force. You make sure that the T is kind of makes sense for the time period where you received it. And then you can basically verify that the syn cookie that you received was one that you would have sent. And then you say, OK, connection established. And you don't have to worry about half open connections or anything. You just don't try that anymore. The ability to send this sort of not cryptographically secure secret, but like some sort of a secret that is then returned back to you makes it not necessary for you to store state. There's some drawbacks. The sequence number is a little less kind of normally predictable. I'm not actually quite sure why that's a drawback. Definitely not really a back hole in the modern internet. The maximum segment size, now you only have to read this for it. But that's also kind of OK. Eight possible values. Realistically, networks aren't sold in same variable that you need very granular control of that stuff. And then you can't send any data at your initial syn packet. Otherwise, what you get back from the server or your SNAC, otherwise, what you get back from the client will have a SYN that is a little bigger than this one. And that is basically a price you pay for this sort of denial of service protection. Any questions on sympathy? Oh, so let's do some board work. I just noticed these nice boards don't even. They'll go through an attack. And I'll try to get this in a place where it's kind of recorded for you guys. But then you probably can't see it. Hold on. Well, that's not better. Max, do you want to come hold this? Awesome. Maybe that table also moves low enough. Really? Who said that? Extra credit. Tell Adam. Max, thank you. Locations from Adam live. Maybe he's watching. What's the? OK. So let's say you're the server. This is a server. And this is your connection state for half open connections. Your server is your queue for half open connections. And an attacker starts at the use in packets. Right. S0, S1, S2. For every SIN packet, without the use of SIN cookies, you have to respond as a server with a SIN act. Right? S0, S1, and S2. And for every SIN act, you have to come up with a sequence number that you need to track. Because this server is going to, or sorry, the client, if it is not a malicious client, it's going to rely on those SIN values during TCP communication. Right? So you need to remember the next packet you send what your old sequence number was. So in fact, for every connection, every other connection that is successfully established, your server or your machine will track the sequence numbers in the kernel and continue to do so for the length of the connection. So whenever you receive this, and then, of course, wait for that final act, you need to store a sequence number here. Right? So this is your local sequence number for connection 0, local sequence number for connection 1, and so forth. Right? And do you understand how if you never receive this, how just getting more and more packets will end up, we're getting more and more SIN packets will end up overflowing this and basically running your system out of resources. Right? Cool. So there's nothing you can do about storing some resources once you've accepted a connection, once the connection is live. Right? But this is super easy for the attacker to do. It just takes one packet. There is no connection. So if you can avoid having to store the resources, it's better. So if you, instead of having this, you still have your queue but only for actually established connection. And in the meantime, you have a secret K that you can use to essentially sign, not securely, but pseudo-securely, sign a response in the SIN act and send it back. So when you receive a SIN instead of actually generating a sequence number and storing it here, you generate a sequence number in a predictable signed way and send it over. The kind of signed way, in this case, is taking the source and destination IP access, some number T that is also included in the sequence number and passing it in a keyed way that you can verify later. And you just wait for the attacker or the client, maybe they're not an attacker, maybe they're actually a good guy. In the case of the attacker, the attacker will just never send you an act and everything is fine. You don't care because you don't have a state that's being wasted. In the case of the actual client in the case of the actual client, the client will send you a SIN. You send back your SIN act with a sequence cookie that you don't have to store. And the client will send it back to you in their response. They'll have your sequence number. And then when the response happens, you process that. You validate that the act has a valid sequence number because you can validate it because only you can generate that hash secret. And then and only then do you add connection three to your queue or to your internal state. Does that make sense? Any other questions on this? Awesome. The cookie is the sequence number. Yeah. It doesn't require any modifications to the protocol. So now we can turn this back on. That was fast. All right. So moving on to other TCP attacks. Of course, the SIN flooding isn't the only attack that's happening to other things. As I mentioned, you still can't really get away with keeping state for actually open connections. There's no magic bullet there. You still have some amount of memory that is taken up by an open connection. Nice thing is that open connections are a little easier to track, easier to reason about. So you can deal with that. You talked about why open connections are needed to track that means half open connection with SIN scanning. You talked about how SIN scanning flies under the radar or some internal protection systems. So with the same attack, conceptually, as this SIN packet flooding, you can also check it before developing. You send a SIN packet to a specific port of a server. And then if that server is open, it'll send a SIN app. If it's closed, it'll send a reset. Using that, you can figure out which ports are open without having to do the full connection. One advantage of this is that a lot of intruder detection systems don't count, or now they probably do, but back on this with Java, didn't count that as a full open connection and wouldn't fly due to get away with your port scan without triggering in that scenario. So anyways, for those reasons, the fully open connections they're tracked a little more, and you can't really get away from having something out of memory usage there. Anyways, there's not much we can do about that. Even worse is a lot of systems, let's say, I have performance web servers, might spin off a thread or a process to deal with each incoming connection. So that's quite a lot of memory use. There can be an interesting attack where there are actually all sorts of attacks. But one other thing is when a server sends you some data over TCP, it needs to be ready to resend it in case that packet is lost. TCP is resilient like that. But that means it needs to keep it in memory. And so until you send the hack, the server has to keep that data in memory. That's another interesting attack. There's other ones dealing with fragmentation on the IP level. I think that's a little deeper than what you really need to be familiar with. But there are attacks generally how other ways to kind of exhaust resources of a server as you're attacking it. Not that I'm saying that you should attack servers. All right. So how do you protect a network or protect a server? Who here uses a firewall? Who here has a home router? So if you have a home wireless router, then you'll use a firewall or at least been. I mean, really, everyone period has been impacted by firewalls in the modern world. But if you have a home router, then you own a firewall and you actively use it every day. The firewall basically says, OK, what should be blocked and what should be allowed? What is an attack? Generally speaking, firewalls work on a synchronous model where everything going into the firewall. Actually, switch back to here. We'll redeploy this. There we go. We're doing that in time. OK, I think we're doing OK. OK. So this play the network diagrams is like a brick wall that's on fire. And your machine is here. The scary internet is out here. And the scary internet might attack you, right? And this applies to, of course, your house, but it also applies much more painfully to library computers, right, your ASU and so forth. So generally speaking, you want to be very careful with things coming in that you don't expect, right? So if something on the internet is scanning for whatever to try to exploit the latest vulnerability, you want to make sure that when it connects to you that unless you are actively trying to expose something to the internet, it stops, right? At the same time, you want to make sure that someone sitting inside the firewall isn't super negatively impacted by the presence of the firewall. So generally speaking, you want to allow anything going out unless it just actively looks super weird and then there's a question of how to detect that. We'll move on to that next. You want to allow it to happily connect out. And then, of course, you want the response to come back to you as well, right? So this is an interesting sort of problem with some applications you'll get into. Basic idea is, how do you create these firewalls to allow this to happen without making this a huge pain in the butt for everybody? Basically, what ends up happening is by default, a firewall tends to close all ports nowadays and this applies to your home wild shrouder. It also applies to the Windows, whatever they call it nowadays, Windows Defender Firewall, where by default, either you or an application that is listening on the port has to allow the ports through. And who here has had to forward a port for a video game or something? Exactly. And that's what you're doing when you're forwarding a port. You're basically creating new firewall policy that says, on port whatever, this is actually counter-strike when it does, right? And then we will allow incoming connections on that port. Oftentimes, nowadays, this is done in kind of an automated fashion using a protocol called UPMP. Basic idea there is using UPMP, a program running your machine and say, hey, I'm actually trying to play this game and I need this port. It'll talk to your router's firewall and forward that. That's, of course, some residential connections, connections that are corporate, much less forgiving. But I can tell you, you can still play a lot of games from my industry base. What's up? So basically, when you're doing your traditional home routing, you have one wireless router and it has one IP to that side world and just makes everything behind it look like it's IP. You can really only have one service on one port so you've got to choose. An interesting thing, actually, when was this class end? 1.15. 1.15. All right, let's go on a quick tangent. Did you guys talk about UTP? So I'm going to take you back to this firewall example and here's a question for you. So let's say you're here on one side of the firewall. Someone else is on the other side of the firewall. This is what the firewall considers internal, right? So this is inside your house. This is someone else. Maybe they're even behind a different firewall. Worst case scenario. And then there's the internet between you and this is what their firewall considers to be internal. You want to talk to each other, but you don't have the ports open on this firewall and they don't have a port open on that firewall, right? Or maybe they, and if we get to the more complex case of later. So you don't have any ports open. So how would you fix this situation with TCP? First, I'm going to tell you how a firewall works or a masquerading firewall works. This is the case where to the outside world, you appear as one IP address. How masquerading firewall works when there is someone behind it, I said two people behind it, talking to the same service outside. So kind of the inverse scenario, what it was just asked. So you go through the firewall and you talk to Google.com and this person goes through the firewall. Talk to Google.com. How does the firewall know when Google responds who to send that packet to? Obviously, multiple people on ASU's network can go to Google.com at the same time. So there is an answer. Let's give them some of your firewalls. Yep, exactly. So you create a, when you create a connection, every connection has a source port and a destination port. So you have a source port and you have a destination port and the destination port is for the AD, let's say, and you're a friend of the source port and the destination port. The destination port is the same, but the source port is not. So when Google responds, they will send a packet back on each connection to that connection's source port, right? Or now the destination works, they're sending to it. The firewall, of course, says, oh, you're going to port S0. I know where port S0 is. Port S0 is person A. If it gets a packet to port S1, it says, oh, I know S1, that's person B, right? That makes a lot of sense. So how can we apply that scenario to allow communication between person A and person B behind two different firewalls? I have at least some note in the work of the other department. Let's say there's no port S0. Of course, yes, if a person had a port open, that was configured to, you know, so I can traffic to them, that's nice and simple, right? You just talk to that port, boom. What if that wasn't the case? Inject essentially a spoofed state into the firewall, right? So this firewall, when these connections are made, it says, oh, okay, S0 is talking to D0, port-wide. So inside here, there is some sort of a status that says, okay, A, open up connection from S0 to D0, B, open up connection from S1 to D1, and so forth. And this is the table that is queried when Google.com responds. But you remember UDP, right? What's the difference between UDP and TCP? So let's say that's a drawback, what's an advantage? Or, I'm sorry, faster speed. Faster speed, why is there faster speed? There's no chats. So you can just start sending any crap you want over UDP, and it should work, right? Because that's UDP, UDP's supposed to work with that. So if I'm A, and I'm talking to, what's another hit question, Reddit? If I'm talking to Reddit, I might send a UDP packet. I mean, Reddit doesn't talk UDP, so there's a stupid example. Well, other than that, I can send a UDP packet just like I send a TCP packet. So instead of Reddit, let's talk about games. Those use a lot, or VoIP, or something like that. So let's say Skype. This isn't very good. What's the hate version of Skype? This is Skype. What? Discord. Oh my God. Don't tell anyone, oh, it's Discord.hiki, right? Or something? I will at least look presentable. Okay, you want to talk to the chat for gamers. So you send a UDP packet from S0, or let's say S2, to D1, right? And here, the awesome thing is, as far as UDP is concerned, there's no connection handshake. You just start sending data, right? You send a datagram. The server might or might not respond to the data, and you have no way of knowing it. You have no way of knowing if the server's even listening on that connection, right? But in order to be a good firewall, because above all else, firewalls and routers, they need to be able to not screw up your traffic. You need to, your connection needs to be usable. This mastering firewall has no choice but to lock that connection over UDP as having, as being active, right? Maybe there's a timeout, but it'll have to lock. So it's advocating S2 to D2 goes to Person A. At Person B, you can do the same thing, of course, right? They can say, okay, S3 to D2, D3 over UDP goes to Person B. And again, the server doesn't have to respond. The server doesn't have to have a connection open, but there's no way to really check. So how would you use that to enable communication across two firewalls between two people? So the first part is absolutely correct. The TCP part is not. UDP and TCP are two different worlds. I grew two different squares. They should have been more specific. The connection also has its protocol. So you can have the same connection, or the connection between the server and the network. So you can have the same connection between the server and the network. It also has its protocol. So you can have the same connection between the same ports on a different protocol. The firewall will see it as two different connections, but you're right. All that A and B have to do is agree on a port, port X and A sends a packet from port X to port X. And obviously there's going to be two different numbers, from X to Y and then mirror it on the other side. But let's just keep it easy. From X to X, send it to this other person's firewall. Another person's firewall says, what the hell is this? I have no knowledge of it. But this firewall says, okay, we'll record that A is talking from port X to B port X. And then person B, like you said, does the same thing in reverse. Person B says A, okay. Let's make a connection from port X to port X. And person B's router says the same thing. There is person B is making a connection from X to person A or X. And all of a sudden you have created a bi-directional connection with the agreement of both firewalls, even though there were no ports open. So you punch the port X through the firewall between A and B. And now you can communicate directly. Skype used to use this. I think nowadays Skype might just be a centralized system, but I'm not positive. Don't quote me on that. It could still be this style peer-to-peer. A lot of fire sharing platforms use this games. Don't tend to use it. It's considered fairly impolite. But using this, you can create a UDP packet, a UDP connection as much as a UDP connection exists between two devices. Very easily. Pretty cool, huh? This is still pretty predictable by ideas and stuff. Like you'd be like, oh, that portal. Yeah. For sure. This is especially like this pattern. I guess if you're careful about it, you could just make it look like any other UDP communication. Right? If you don't choose the same source and destination port, and if you often have to make this work, the two parties just flood each other with UDP connections until the states line up in the firewalls. If you don't do that, it's less accessible. But that's typically done or not. I'm actually sure why that's done. On paper, it doesn't seem like it'd be necessary because usually there's some timeouts and so forth. Other questions on this? Cool. Good insight. That was like immediate attack development. Moving on from firewalls is intrusion detection system. Intrusion detection system. We'll monitor all communication on the network for some large amount of communication on the network and try to say, oh shit, we're being hacked. My question with intrusion detection system is how to specify what being hacked looks like. Let's talk about some questionable UDP traffic being flooded from one port to the same port. Might be a questionable thing that might raise an alert for some human effort panelists to look at later. But there could be other ways to detect the tasks. For example, you might look at all TCP connections coming into your web server and try to match with all the signature for an expert. So typically, an expert has some sort of a detectable vulnerability to explain vulnerability or to send it, especially a crafted data, to attribute a vulnerability in a service. And you can, of course, have an IDS that looks at all data that comes across and says, this looks like the type of data that we have seen triggering this vulnerability in other analyses. So that's probably a guide. An intrusion detection system detects attacks and raises an alert. It doesn't actually stop the attack. An intrusion prevention system will actually stop the attack if it detects. These are more complex. Generally, you might have an intrusion detection system on the server and actually looks at all the data that's received before the server can process it. Whereas an intrusion detection system might just simply set up a network. Yeah, absolutely. So you put a, for a honeypot, you will put up a server on your network that shouldn't ever be connected to. And then you see, oh, someone's connecting to the server. This is either a very curious employee or an attacker that is scanning that network. Yeah. So that's a good example of an intrusion detection system that's non-traditional. Traditional ones just will monitor traffic and say, oh, the traffic looks weird. They're more active things like the honeypots. And then there are more heavyweight things like intrusion prevention systems. Interestingly, there is this new class of systems that have come out. I've gotten very popular, I would say, in the last eight, nine years now. So that actually sounds pretty silly saying it's new. But it's called the reverse firewall. Traditionally, I mentioned the firewall. The only thing concerned is what's coming in. A reverse firewall is actually more concerned about what's coming out. The idea behind the reverse firewall is you're going to get hacked. An organization the size of ASU, for example, an ASU is the size of a large company, is just you're going to have compromises. There's zero way to prevent this. NSA has compromises. You're going to have compromises. As in security compromises where hackers get on your network and are able to auto-release. So what you need to prevent from happening is those hackers begin to exfiltrate the data. So you do your best trying to keep the hackers out. You assume eventually the hackers will get in. And then you have a firewall that says, okay, but once they're in here, they're not getting out. They're not getting back out. And there's various techniques that you can use for that. A lot of, for example, botnet infections that have known command and control servers. So you can prevent communication out to the command and control servers. You can prevent communication out to popular data exploitation sites, all of this sort of stuff. That's a very active area of at least entrepreneurialism. There's a lot of companies in this space so a lot of money is being spent. Whereas intruding detection systems, traditional ones, have kind of had their big data back in the 90s, early 2000s that have mostly been standardized into boringness, let's say. Although with the rise of AI, now you can say, hi, it's an intruding detection system but it uses artificial intelligence. People still pay a lot of money. Hi, where is networking research nowadays? These slides are probably five years old where everyone first built them. But a lot of research actually is happening in software-defined networks. So everything you've learned about networking so far, at least in this course, really assumes that you have a physical switch that someone sat down and plugged tables in in favor. There's this worldwide network of physical switches that are all hard coded to be plugged into each other. This is less and less the case as software-defined networking rises up. The first kind of cracks in that perception was the rise of the cloud. So once you could boot up virtual machines on Amazon AWS, and later on it's out to Jir and Google for QdEntion and all of our app spaces offering and whatever, and you could also create virtual networks to connect these computers, people started thinking you need to have these very strict network policies applied to other switches that are physically plugged into specific other switches. And all of this is designed ahead of time and overseen by grumpy old men with big ears from the other networking in the 1980s. And people have been making moves to change that. To, for example, come up with an architecture where maybe instead you have, you started your switches, but they're all plugged into every other switch. And in software you define how all of the routing works and what switches they actually communicate with. And this introduces an industry new attack surface which is the controller of that software-defined network. They're called SDM controllers. That's another machine that is actually making the decisions talking to the switches and updating dynamically routing rules and access control rules and so forth. That's a new area of research that, for example, they're pursuing in our lab as well. Actually, Adam is in London, along with one of our students to present a, what do you know about the lab? Last year in Toronto, we presented a paper about software-defined and routing attacks and we're working on some follow-up stuff right now. Firewalls, you're still seeing research into firewalls and including technical systems. As I mentioned, big data and machine learning has started making its way into this field as well. And the idea is that you've been, if you need big data, firewalls and network traffic stuff, that's very big data. Maybe you can use that to identify attacks and so forth. Honey net, for example, and honey pots and honey controller and the products of all types are big research areas in networking. Research. IPv6, who here has heard that they're running out of like 94 addresses? Are we going to run out and we'll be killing each other in the streets over IP addresses? I've been hearing this for 20, I'm not committing this up for 20 years. Let's say 19 years, ever since I built my first server. I'm sure it'll happen. I'm sure it hasn't been happening and just like being resolved and so forth. But eventually we'll all be running IPv6, which will do away with a nice, you know, blah, blah, blah, blah, blah, blah, IP address system that you're used to and all familiar with and introduced an absolute freaking monstrosity of hexadecine numbers and colons. IPv6 is terrible, but it's definitely a little painful to get adjusted to this. Has that been talked to you about DEF CON? Yeah. Yeah. So one DEF CON, I think it was 2012, maybe 2011, spent all summer preparing, literally all summer. We had an absolutely insane analysis system that would redirect all traffic to this like insane, instrumented machine that would, I mean, basically you're unbeatable. Ready. Our automation was so incredible. We show up and instead of IPv4, it's IPv6. And nothing worked. It was so disheartening. A friend of mine quit grad school over there. So IPv6 can be painful. If you don't prepare for it, get ready for IPv6. And then IPsec, but more generally ways to secure communications on the internet. You talked about crypto, of course. IPsec with this idea that what if we have encryption on the IP layer, right? So when you reach out to a server, you immediately, all communications with that server would then be encrypted. This turned out to be a huge thing to ask because of many reasons, right? Basically fragmentation and different solutions on the layer right on top of the IP layer. The IP layer is kind of a pain. You can imagine it. Every major company that sold on networking appliance, I don't understand. This doesn't exist, but this is what's happening with IPsec. Instead of the true promise of IPsec, where you say, okay, bad IP all communications will be secure and instead have VPNs. We are using the VPN. VPNs basically create a virtual networking device on your computer. All traffic to that virtual network device gets routed through a UDP or TCP connection over normal IP space to a server and then out from there. For now, that's the actual reality of securing network connections. And who knows what's next. It's a lot of... If I were to remake this slide today, a lot of this 5G, you know, next generation wireless networking stuff. 5G heavily uses software defined network. For example, a lot of very interesting security properties and the networking properties with slicing pieces of networks across the world. So your phone could be on the same network IP-wise than it is when you're at home, even though you're across the world and so forth. It's an interesting security space. And a lot of new low-power devices. So since, let's say, five years ago, Bluetooth low-power has gotten super big. Everything is like with Bluetooth low-power thingy. You're talking over that with your scooters that you ran and so forth. So the big area that also has a lot of network relevance basically Bluetooth is essentially also networking protocol on top of connecting your headset. Any questions about networking? No? It's perfectly clear. Who's excited about it? There we go. Three people. Let's do it. No, it is good. I don't know. I feel that people don't get a lot of exposure to networking. When I was learning about computers, that was like all the rage. Everyone had like a TCP flash ID on their resume. And like literally skill, colon, like gardening, comma, karate, comma, TCP IDs. You can also put that down. But karate classes are probably next semester. Yeah, if I had to guess, that's why. Even when I was in undergrad, I didn't have an everything class environment. Yeah, I think it just started working so normally that just normalize. And then also back in the day, if you wanted to create a large distributed system, you had to really know TCP and you had to make decisions, right? You know, make the server listen to TCP or UDP, understand the location. Nowadays, everything is HTTP. So if you're even moved beyond that, no one even learns what they should speak for. Everyone just uses REST APIs, right? And all of their services. You can get away without ever making a TCP connection to a database. You spin up a cloud database in AWS and you talk with it over REST. I'm not saying that's a bad thing. I think it's actually a very nice step. And whenever I make anything that's distributed, it's all over TCP. But it's very different. So yeah, I don't know. I don't know. Do we have like a web application development course where we have REST API and so forth? Yeah, exactly. So that's where things are moving toward from like core network. I think this stuff is still very cool, but it's very cool in kind of a hacker way, not always extremely applicable in your daily life way. Although honestly, I mean, the amount of time even recently where I've had to debug my network in a coffee shop or on a plane specifically in a coffee shop, I just tether things don't work, but on a plane, those networks go down frequently, but often for stupid reasons like the DNS server died. And so you can still get internet if you put some effort into it. Cool. Okay. It's 111. So I'll let you go four minutes early. Next. Class can dive into application security. So this is where you get super in-depth. We're going to talk about assembly. We're going to talk about processes. I'm going to be pretty fat. What is the meaning of this? I don't know. That's a big explosion. No, that's a big explosion. Yeah.