 All right, folks, happy Monday. You can see here, this is the queue that's being used to grade your homeworks. There's no spikes, there's nothing in the queue. At a certain point, everything was horribly failing. There was like 14 jobs in the queue and nobody could keep up with them through, yeah. So, luckily I was able to mostly fix the issue so everything should be good now and I think jobs get created within about five minutes now. So, and that should continue. There's four pretty big machines that are grading so you can problem less. Well, I'll probably end up spinning up more tomorrow because I don't have them, it's been less. Last 24 hours. There will be, so we're gonna send out information after class. I don't wanna spend class time talking about it but we'll send out on the mailing list all the information for the CTF more Wednesday. So we will not be here. We will be in EDC, is that educational? One, what's that? It's a super nice room. It's a really big room with a bunch of tables so that you can reconfigure and stuff so you can sit by people but, so that'll be fun. There'll be a link to it if you won't be, if you have any questions, let us know but, like I said, I wanna get to, I'll grab it. So we've looked at networking so far. What type of communications have we looked at? Actually, we haven't looked at CCB at all. What was that? ARP? What was ARP used for? Yeah, right. To match up IPs with machine addresses, yes. So we want to, we know there's an IP we wanna talk to. Where do we know that IP address is located? Know the machines on our local network which means we can communicate it with it over a key minute and so we need to figure out, we know the IP address, we need to map it to a physical address and that's what ARP gives us. So we looked at that communication but what we haven't talked about is how do our packets get from our machine to a machine on the other side of the world? Right, so let's think about Google. When you go to google.com, how do your packets get from here to Google? Is Google in your local area network? Probably not. So the question then is how do your packets get there? So what do we have? So we talked about before in this situation, we as a node, we wanted to communicate with Google, what do we know, what do we have? So we think about what we know, what is our node? We'll get into it again because that uses UDP to the major request to translate Google.com to an IP address. So let's say now we know the IP address of Google. So we have Google's IP address. What else do we have? The gateway. We have the gateway? What's the gateway? There's information from your local network to the other side of the world. Yeah, so A, well if we go back to what we knew before, we know our subnet, right? So we'd ask the question, is this IP address on our subnet? No, the answer is definitely no. We are on a completely different subnet than Google.com. So now we actually need to know more things. So before, when it's on the local subnet, that's all we need to know. This IP address is on the local subnet. I know how to make an arm request on this network to find out that physical address. So we need something more. We need routing information. So we need to know, hey, so the way to think about essentially a router or a gateway, which are kind of essentially interchangeable terms, it basically means if I have a packet that's not destined to my local network, who does this go to? Exactly, that's what the router or the gateway is, right? So it's an IP address. What must be true about this IP address? Accessible to everyone, everyone on earth? Yes, on the local area network, so we should be able to communicate with it. What else must be true? Kind of inherent in that response. Yeah, exactly. It has to be an IP address on the local network. And so once we have those pieces of information, we have the destination IP address. We know our local subnet, we know our local router, we're actually able to then start the process of sending this packet off. So do we make an arm request for google.com's IP address? No, because we cannot communicate with them because they are on a completely different local network, right? This is kind of reinforcing that. Some people get this confused where they think, oh yeah, we translate these things and you just make the arm request, right? You're not on their network. So this is the idea behind routing and indirect delivery with one slide 54. So, and basically this is incredibly simple process. So the process is essentially, it's all local hops. So essentially, so if we can't send it to the final destination, right? If we can't send this packet to google.com, we have to send it to the router. So we know the router's IP address, what do we do next? Maybe, who's routing table? Ours? The routers? Ours. Not yet, before that. So we have the router's IP address. Capsulate our packet into another packet and send it to the routing information. What do you mean encapsulate our packet into another packet? Information into another packet in the data of another packet, which is another IP packet that we send it to the router. No, so we don't have to encapsulate our packet into anything. Essentially what's gonna happen is we're going to ask the router to send our packet on and that router will have a gateway or router where it knows where to send packets that is not on its local network. And that router knows how to send packets that are on its local network. At each step, it does local delivery. So exactly what we talked about. So I, the next hop, so you think of it in terms of hops, right? Your packet is hopping from your machine to the router and then from the router to the next router and that router to that router. Until finally, one machine, one switch or router has it that is on the local network of the IP address you're trying to talk to where it finally gets delivered. But at each step in the process is direct delivery what we just talked about. So the difference though is, so let's actually draw this packet. Back to the slides. Slide 55 is really just a diagram of what I presented programmatically showing that basically at every step of the process the Ethernet frame is recreated and the IP stays relatively the same. So it used to be that, we talked about some of the old IP options. It used to be that the person sending the packets could actually specify, hey, I want these, I want my packet to go through this route. This has really bad security problems because you could force all of your packets through maybe one router that can handle it and ended up taking down that router. And fundamentally, that's part of the whole point is you shouldn't have to care about what packets, what router packets take. As long as when you send it, the other side hopefully receives that. So okay, so the routing table, slide 58, so the idea is you can configure and you can actually configure all this manually so you can play fun games, creating your own networks, all kinds of stuff. It can be very useful. The idea is you can use the route command on Linux to list the routing tables. So this is exactly what we were talking about here. Basically, let's see. Okay, so the first entry is your IP address. The second entry, so the gem mask is essentially your subnet. So it says that, okay, 255, 255, 255, 0. So as you can think of, that's all ones except for the last octet is zeros. So that defined your subnet. It's the same thing as the slash 24. It says anybody here, so 192.168.1, that slash 24 is on physical interface zero. So this, you can also set up different interfaces with different networks so you can actually make, you can configure your own things as switches and routers. The default here is the destination of all zero. So basically, none of these rules apply to that destination IP address. Then send it to the gateway of 192.168.1.1. So this leads to several interesting attacks that are variations of what we saw before. So, all right, we're gonna move in. The idea being that you can't see the response. So you have to just create habits as an impersonated host. So, and you have to assume that you don't have access to the reply. Now, as we said, so on slide 61, so if we actually do get, so what can we do if we are one of those switches, if we take control of that or somehow compromise that, what can we do? Yeah, it depends. So, not always. So let's say, so the idea would be if there's some trust relationship between B and C, let's say that kind of a famous one or one that actually comes up very often in organizations is to say like, okay, you can log in to this server if only this IP address can log in to this server without password. And so if you're able to then basically send a command to that server saying delete everything on the server coming from that trusted IP address, it will just execute it. Or like a network file share is probably a better example as we'll see later. So you can maybe delete files coming from a trusted IP address. So this is actually why you really can't trust IP address as necessarily as an authentication mechanism. Because you don't know maybe that IP address is being spooked. Okay, so put on your black hats and you control a gateway on the network. Sorry, one kind of router on the network, what do you do? What was that? It's the packets. Hey, you set the packets so you can see all the packets that are going through the network. It's pretty nice. What else? Yeah? Can change the direction of the packets or if you can change the priority between the routers or if there are some routing protocols between the routers, consider that there's three routers, they have access to just one of them and the other router is a high priority router. So you can change your priority to the highest priority and so you can wrap all of the packets in there. So try to configure the other routers to maybe change- First of all, it was to get a five-pack. What else? What was that? Modify the packets. Modify the packets. Yeah, you can change any of the packets, right? So this is why it's important to think about when you think about the internet. So I like to use kind of the example of the mail service. So you have a letter and then you put it in an envelope and then you put it in the mailbox. But that's actually a pretty, that's a bad analogy because it's more like a postcard. Does anybody know what a postcard is? So it's like usually not something you put in an envelope and that's the key idea but it's usually like a picture on one side and then you write on it on the other and it has the address and everything. So you think about when you send that to the mail, every person who touches that piece of mail can read whatever you wrote on that postcard, right? And they could even write on it or do whatever they wanted to it, right? So this is an important thing to remember about the internet and this is why as we'll see other types of authentication and confidentiality, all this crypto has been built on top of these layers because fundamentally at the IP layer, there is nothing to prevent anyone in between from modifying or changing any packets or any data or reading anything that goes across. Oh, we didn't talk about it. We could block the traffic, right? So maybe we wanna stop these two machines from communicating, right? Yeah, so we can inject new data into their connection. We can basically do all kinds of super cool stuff. I'm gonna skip the presentation. So on slide seven, we're talking about ICMP. So it's actually an interesting design question. So you're developing this complex networking protocol with all these different layers and multi-hop routing and you're trying to build a way for the different machines that are running different operating systems operating across the world to be able to communicate with each other. How do you know when something goes wrong? So somebody asked the question earlier, how do you know where your packet is? How do you debug something like this? It took me like four hours or five hours on Saturday to try to fix the servers. That was only like three machines without any things that we looked at so far. A core screen mechanism you could do is control two machines, send one packet from one to the other and then look at what the TTL value is based on what you send and what you receive. Cool, so that may tell you how many hops are in between. Do you have sort of a check sum at each hop? Yes, we didn't talk about it, but there is a check sum value in most of these layers that just looks for bit flips and things like that. You know where, where you broke them. Right, so that's a good mechanism. What you really want is some kind of debugging mechanism. You want some way to get like error messages back. Or what happens, let's say if you send a packet to somebody and that host isn't up. How do you know if they didn't get your packet versus they're actually down? Or any number of things? What if your route's not configured correctly? So this is where ICMP comes in, the Internet Control Message Protocol. The idea is this is a protocol that's designed to communicate about any errors at the IT level. So it's kind of interesting because they're using IT in order to transmit these messages that are about IT problems. So if you have catastrophic failures, this is not going to help you. But as we'll see, it's a nice, not only debugging tool, but also used for attacks and reconnaissance. So we can send requests, get responses, or get error messages. So this is, and so we'll look at this very quickly. The headers are pretty simple. It's like 71. There's a type, a code, a check sum. So we're talking about check sum. There's a check sum at this level. And then the data. So they're very simple. There are all kinds of stuff. Let's skip over some of these. So PING, when you ping another machine, right, you want to see if that machine is actually alive. It uses an ICMP echo request. So that's a simple message that says, hey, send me back whatever I send you. So if it does that, it sends it back. So it's actually a great way to communicate that A, that the host is up, and B, to help debug that what you sent them is what you got back. Which means that no switches in between are accidentally maybe flipping bits or doing something. So back to our lovely friend, the TTL. The TTL zero, we'd want to know about it, right? Because we'd want to know, hey, something's wrong with the network. So the router or the switch that drops the packet will try to send an ICMP message, a TTL expired back to the source IP of that message. There are other fancy ways. Let's say you're on a network with maybe two gateways, and your machine is misconfigured. One gateway can actually tell you to use another gateway. Destination unreachable, this happens a lot when I'm doing stuff and it doesn't work. It's telling you, hey, this host is not up. Sorry, like. So ICMP echo request. So when you're on PING, this is exactly what it does. So the type, either request or reply, code zero, and identifier, so that that way the responder knows what request you sent in response to. So it's actually interesting that this has this concept of an identifier where it's something like ARP, does it not? So, and this is exactly what it's also used. So what other things do you use PING for? What was that? Yeah, what do you use that for? I mean, we haven't talked about that yet. What do you use the PING program for? Check if the host is accepting finishes. You have to check if the host is, that's one way. It can be misleading because oftentimes, I mean, you can configure a machine to not respond to PING requests. Yeah? You need to reply to another agency. Yeah, right? So if you think about it, you send a request. The time between you sending a request and getting a reply back is roughly the amount of time I can take to get from you to the other side. So this is, I mean, I use this all the time but I'm on either a crappy Wi-Fi or something to figure out what's going on. Is it the latency of the problem or package being dropped? Yeah? I think it also does the host PING program too. Yes, it will also, under the hood, we'll do a DNS query to map a domain name to an IP address. So it's going to be a nice quick dig. DIG is a better tool for that if I find it. Did you get more information back? We can also use this for attacks. So it seems kind of interesting. So it seems like this is such an innocuous functionality, right? It simply just said, hey, are you there? Yes, I'm here, right? So what can we use this for? Send a package with the, we can send a package with a destination as somebody else that actually was responsible for the destination of the problems with more packages. Right, so we know that a fundamental tenet of IP, of the IP layer, is that we can spoof the source address. So we can send a request with a source address to somebody else, and it will respond back to that person. We'll have to see how we can actually turn this into an attack in a second. That's one way. What else? Yeah? It's nice to see that we're quick to spend a lot of time. OK, so I'm going to try to maybe take the machine out by sending a lot of packets. What's that? It's not just knowing what hosts are up, right? So you want to try to break into some company or some website, right? What machines are up in their range? So you can send a ping request to every IP address in there, like, slash 24, and then see what replies you get. And this actually used pretty frequently. I'm thinking of this like a ping scan. So you're trying to figure out, so basically you send a packet to all hosts in a subnet, and you see who replies to you. And then that gives you then further directions to attacking. So this is an important concept. I don't know what you're talking about yet, so based on your, hopefully, just knowledge from movies, how do you rob a bank? Physically, not digitally. What's the first step? Get a gun. Get a gun first. And if you bring a gun, then it becomes like a temp. I don't know. It's like, how much higher tire did you get on movies? That's what changes security. Yeah, those do what? So I take the security. Ah, before that, there's a pre-step. You first have to assemble an awesome crew, right? Is it a montage, or you go to people, and they'll be like, no, I'm retired. One more job. So then you assemble your crew, and then you perform reconnaissance, exactly. So then you case the joint, right? You go, and you look, and you see, what are all the things you're interested in? The environment. So you're looking at the environment of the building, the layout. You're looking at maybe the traffic patterns. Routines. What was that? Routines. Routines, so you're looking at when do the guards change? When do they go on break? How many guards are there? Where's the manager? What days does what manager work? Which managers have kids, or maybe something that can be blackmail? No. Right? You spend a significant, and they usually don't show some movies. We spend a lot of time trying to figure out every possible detail you can about that bank, right? You're going to look and probably pay somebody to get the plans of the bank, so you can know the exact layout of everything. What type of security system are they using? What type of cameras? Do you have somebody in your crew who can hack those cameras? All this kind of stuff. And then only after you've done all this work, then you actually rob the bank, and then something inevitably goes wrong, and it all goes haywire. But with now doing that reconnaissance step, you don't know what you're walking into. So similar thing occurs in computer security. When you're trying to, let's say, as a pen tester, you're hired to break into some company, you need to know where to go, right? You need to know what hosts do I attack. Can you just ask the company for that? No, because the attacker wouldn't do that. They wouldn't give that information to an attacker, right? So this is part of what I want to be thinking about when we talk about different types of attacks is reconnaissance is a very big part of gathering intel information and trying to understand more things about the network that you're trying to attack. Don't rob banks. It never ends well. They almost never get away. Cool. So NMAP is a tool that will come up very frequently. So it's going to stand for network, like a network map. So it has all types of insane options to do different types of network scanning. So one option you can do is, I don't know what off the top of my head, is to do a ping scan. So you can do a ping scan of a network and send a ping request and see what replies you get. And so some of the things that people are talking about is, and I think it's interesting to look at historical vulnerabilities. Why? Or is it? Maybe I should pose that as a question first. Is it interesting to look at historical vulnerabilities? Why? Are you just there? Can I ask you a leading question? Yeah. If the way in response to those kind of problems, maybe it can still be useful? Yeah, so there's a couple, a lot of reasons. One is that, honestly, these same problems keep coming up in new areas. So you learn about an old attack, and then you found out. And then you think, oh, this is really dead. And then, so that's a good example. I mean, a good one is, let's say, well, that hasn't really been solved, but let's say a memory side channel. So basically, they show a long time ago that you can kind of tell if you're on the same machine as somebody, you may be able to tell what programs they're using just by the size of the memory that they're using. And you think, OK, that's a very academic thing. And if you're on the same machine, you already kind of had problems, and you're not in a trusted environment. That was dormant for a long time until Android came out. And they showed that one app can know everything that another app is doing based on the memory usage, like using that as a side channel to figure out what they're doing. So old attacks keep coming up again and again. So even though an ICMP, a SMERF attack, you can't really use anymore, it's still interesting thinking about why this is a problem. So before we talk about this, so this is going to be a denial of service attack I want to talk about. So a denial of service attack is an attack against one part of the security of an application. Yeah, availability, right? What are the other two? I'll put that in here. Yeah, it's difficult when you go in the other direction, right? Commit a shouting attack, right? So it's an attack against availability. So before, whatever reason, we want to take down a specific system. So let's say you want to take down Google.com. That would be great. Or let's take it at a different point. You're interested in causing mayhem, you want to take down Amazon.com. Let's say, and I don't know, maybe I have a rough idea of how much Amazon sells or makes in a half hour or an hour. I'm sure it's something insane, right? It's a very, very high number. So even taking them offline for maybe five minutes or 10 minutes would be a huge deal to them. And maybe if you're really good, you can take them down for an extended period of time. So before you do that, you can short their stock. And that way, when you do that, that's when their stock prices drop. Now, you've made a lot of money. So you want to take down Amazon. How do you do that? Do you just send a bunch of packets at them? Yeah? I mean, they have the apps on web services, right? So if you could probably just get a big account and see what you could do. Yes, think about network things at the start, though. So I mean, there's a couple different ways, right? We could maybe try to find some vulnerability, a remote vulnerability that exists on their servers. We could get into there and then just shut down. We get remote code execution on their servers. We could shut them down, right? Or worse, make them like, spin forever, or I don't know, make them burst into flames or something, if we know some kind of way to do that. Appear it from the network. So the first thing, as well, is just send in a bunch of packets, right? Is that going to work? Not just a bunch of them. Yeah, why not a bunch? Because they can handle it, they have. Yeah, they're a huge company. They can handle a queue sending for as many packets as your machine on your network can send. You can bet that Amazon can definitely handle it. So what do we need then? And so let's think about it this way. Let's think about Amazon is limited, they can only handle, I don't know, I'm going to make up a number because I know this is not true, but let's say a gigabit per second, let's say. So you, your machine, you probably don't have a gigabit per second connection. Let's say you can get 100 megabits. So you can fundamentally never take them offline because all the data that you send to them, they can completely handle all that just fine. Just like a bunch of machines, send a bunch of packets. Yeah, so we need some kind of lever or some kind of scale, right? So I can get, what is that, the numbers are going to be, if I can get 100 machines, control of 100 machines, which each have 100 megabits per second, and I guess I need 101 to get over the threshold, but let's say I send over a gigabit per second to Amazon, I can then get them down. But still fundamentally I then need to control one gigabit per second worth of bandwidth, right? Exactly the same amount of size as the attacker. So I can, so the question is how fundamentally, so the one gigabit per second is a little bit misleading because it sounds like, yeah, you could do that, but there are like terabytes, terabits, I guess, per second or petabits per second, something that really you're kind of out of the realm of doing even with if you control fast numbers of machines. I mean, you'd really have to have a huge infection. And at that point, ransomware is much more profitable than anything else. So what would you need instead? Then a lot of payments requests to the data server or that kind of thing. Even though the server is reachable, not you, it's reachable. So we can try to target other areas, so if you look at it as kind of like a dependency chain, if nobody can resolve amazon.com to an IP address, then that could be an average of the tax, so but let's say they're very good, all of their systems all have this, you know, terabit per second. Bandwidth limit, yeah. If you can get into a router and set the source, you can just all point back to the Amazon. Who's that again? If you can set the source IP every back would come in through some switch or router. So how does that help us? Then any packet going through that switch, not only yours, would go back to Amazon. So we need to depend on how many packets are going through that switch. Let's say it's a hundred or a thousand times the traffic we can generate, right? Then that could then be sent back to Amazon. And if we could do this with multiple switches, right? Essentially having to redirect all of their traffic towards Amazon. Or what if we sent one byte and Amazon received a hundred bytes, right? So the thing to think about in denial of service. So a lot of people focused on, they called distributed denial of service or DDoS where you just get a bunch of machines and then launch traffic, they had something to take it down. Really what you're going for with denial of service is some kind of lever, right? Some kind of multiplier, like a 10x or a 100x multiplier that says I can spend, let's say some type of resource, either it's bandwidth, time, or processing power. And I can force you to use 10 or 100 times that processing power. So that's when we get to, when we see these types of denial of service attacks, this is really what's at the core here. So the Smurf attack, which has a great name. The idea is, let's say, so there are three completely disconnected subnets, completely different subnets. There's some server that we want to take down. We'll say in this example, it's at 128, 111, 4110. And we are some attacker on the internet. So this machine, in this picture, it's kind of like a rack so you can think of, it has a pretty good processing power, it has pretty good network capabilities, much more so than us with our laptop. This is kind of the fun, because if we have more resources than you, then yes, I can take you down. That is very useful. That's actually not even cool. I think that's super lame. It's like when people take down, I don't know, a lot on top, like really small websites. It's like, okay, that's lame because they don't have anybody, but if you can take down like Amazon, that's like amazing. You're really doing something cool. Or very bad, so don't do that. Technically, it's technically cool and interesting. So what you would do, so the idea is if you just sent echo requests, let's say to the target server, the victim server, and then we get echo responses, we can't flood their network. There's no way we're gonna be able to flood their network. But what used to be the case is any ICNP echo request sent to the broadcast IP address of a subnet, that packet would then get split to all of the machines on that subnet. So what I would do is the attacker, let's say this subnet is 192.168.1. So what the attacker would do is send an ICNP request message of hanging request, set that from the source destination IP to 192.168.1.255. So this is to the broadcast address in that local subnet, in that subnet. And the source IP address, it's gonna pretend like it was from the victim. So this packet gets sent out, and then every machine in the subnet gets an ICNP request from the victim, 12811, what is it, 4110. And all of them reply back to that. So we sent one packet, and let's say there's 10 machines on the subnet even, or it's a 255, there could be 254 machines on that subnet. They're all then sending 254 packets to the victim. And so we can keep doing this for all these, all these subnets until we send enough to where we've completely wiped out. And then this would be even worse against a class A network, like a class eight, because we're sending basically a ping to their entire network, and so they're all responding. So this was a real problem. And this was a real attack that people would do to take down servers. And this is really cool because you're getting that leverage, right? The attacker is getting that leverage based on how many machines are on the subnet. I send one packet, they receive up to 254. That's awesome leverage. So how do you prevent this? I block ICMP packets. Yes, but you want to keep ICMP packets if you want to debug stuff. Like ping is super useful. Yeah, when you need it. When you need it, exactly. Block ICMP to the broadcast address. Yes, block ICMP to the broadcast address. So no more ICMP. So now, if I can't do this, and I want, and the attacker wants to send 255 packets to the victim, how many packets do I have to send? 255, I have to send all those packets, right? So there's no leverage there. They've reduced that from a 256X to 021X, which is nothing, right? Then why, at that point, why send the packets to the subnet and then back to the victim, right? You might as well just send them directly to the victim. That's that attack, that's one of my favorites. We're gonna skip over that. Okay, we're gonna go to TTL. So we talked about this. And time exceeded packet. So we do want to know for debug purposes, but also for, yeah. No, we want to able to send ICMP packets to the router or the subnet. Even a LAN connection to the local network can also only do that. Can we send ICMP ping packets to our local subnet? Yeah. I think the answer's no. Even a LAN connection. Yes, because I don't know how they would know. Basically, you have to send one ping request per machine on the subnet, which is not that much, I mean it's 255, yeah. What do you think happens if you put the source ID at the station like before us? So put both of them as the same? I think nothing. If you, you mean a source, say that again? It tries to send it, it tries to reverse this order and sends over and over to the subnet on your type. No, the, because the machine knows its IP address, so it would. Then no, I put the subnet on the source ID of the station on the subnet. Yes. And it would try to answer like this. I think it would know that it's IP address, so it would send it on the local interface and not the actual physical interface, and so it would just handle that and it would say that, I don't know, it's interesting, you should try that and see what happens. I don't think it'll loop forever, but I think it will access itself. It all sounds like an SRI or an SPU. So we wanna know if the TTL expires, right? We saw that, that's something that we definitely want to know. And we talked about it, it would be really nice to know the path that our packets take throughout the network. So by combining this, using this idea, this is how, so some of you are familiar with the TraceRoute program, this is how it actually works as it sends out one packet with a TTL value of one, and so that means that gateway is gonna decrement that, it'll be zero, and you'll get an ICMP timing seeded message back, and then you send out another packet with a TTL of two, and you see if you get a response back, then you send a TTL of three further and further, allowing you to map play. So yeah, so this is nice when you're actually testing things. It's actually really cool to just look at what's happening, because oftentimes you can tell, so TraceRoute will do like a reverse DNS lookup to try to map the IP address of the router with its domain name, and sometimes there'll be really interesting things, like you'll be able to see that the packets from here go to LA before going around the world, so it's pretty cool. You guys run TraceRoute, and then the IP address or the DNS address, and it will, you can get all these hops so you can see basically all the steps that these packets take. So we've looked at that. There's no definite rule between the source and the destination. What? There's no definite rule between the source and the destination. I can't hear it. There's no definite rule between the source and the destination. Is that a question, or is it? Yeah, I think that's right. What? There's no definite rule between the source and the destination. I mean, the packets can choose a different number. Yes, yes, yes. Then how does TracingRoute help with debugging? It can, so the routes are mostly static, except when they're not. Yes, the problem is there's no guarantee so you're sending these packets out one after the other. There's no guarantee that when you send out an actual packet, it's gonna go the same route. There's no guarantee that even these TracePaint packets you're sending, that they went the same route. They could go different routes. For the most part, it's fairly stable-ish, so it's more or less okay. So yeah, that's, but yeah, it's exactly that. It's all kind of approximation and best effort. So we looked at how we send packets on our local network. We've looked at how to send packets from one network to another. Now we get to look at actually sending information to each other. So this is where things get interesting. So UDP, so we actually just talked about this, is so it's the layer on top of IP, so it's going to view what the IP packet is sending. It basically provides nothing. So connectionless, unreliable, best effort, so no delivery integrity, no communication ordering, or bandwidth, none of that is guaranteed. So similarly like IP, so the reason, but it does add an important distinction on top of IP address. So you can think of a IP address as essentially a big apartment complex, right? So how do you live in an apartment? In an apartment, in a complex, what kind of complex? So how does the post office distinguish you between all the other people that live in that address? Unit numbers. Unit numbers, right? So similarly, in terms of services that we write that use the network, we want to be able to say, hey I want to talk to the HTTP server, sorry, the HTTP program running on this server, or I want to talk to the FTP program that's running on this server, right? I need to know different, essentially you can think of as different residences or houses, units in that apartment complex. So that's the idea of the important abstraction. So the ports specified in our program, different UDP is the way UDP and TCP both use this port abstraction. UDP is still really important even though it's not used quite as much as TCP. And when we look at on slide 85, a UDP message has a source port, destination port, how big, based on this table, are these values? 16 bits, so how many port numbers do we have? Yeah, zero to two, 65, 65, yeah. The length of the message, the check sum of the data, so we can see that the overhead for the UDP, so why isn't the IP source a destination in the UDP header? Yeah, because that's a nonsensical statement, but that's in the IP layer. All the UDP layer tiers, guys, what port do we want to talk to? And so just like before, so we have our UDP data with the UDP headers, that is encapsulated inside the IP data, which has an IP header, and that's encapsulated inside the frame data with a frame header. All right, when we come back, we'll talk about our fun application of this proofing.