 Yeah, very lame. Oh, midterms this week. Yeah, okay. I guess I'll let you offer that, although I don't know if we can trust what Christian has to say on the matter. Cool. All right, let's get started. Congratulations on all surviving your, at least midterm in this class. Good luck with your midterms in the other class. And now we're gonna right on go with UDP. So we looked at UDP and what was, what does UDP add on top of IP? Yeah, it adds a header. What information that header is important that we care about? Ports. Yes, thank you. IP, source IP, destination IP is all done at the IP header. UDP adds ports. Let's go back to that. I saw my crazy drawings. Awesome. Zoom in. That's weird. Right. So this is the UDP message. So UDP adds source port and destination port. We also have some other things that we don't really care about. But for our purposes, the main thing that UDP adds on top of IP is the port abstraction. So as we mentioned here, when a client wants to, let's say, make a request to a service, it sends a UDP packet. So let's actually go to that. So let's go back here and let's say that I, so we'll use me again. I want to make some, and so I got my switch here. I got a router here that I can ignore all those other details because we already went over all of them. And then somewhere I have my DNS server. And so I want to make a DNS request to the DNS server. So what's that packet going to look like? So the topmost header is going to be the UDP header. What's going to be my source port? M of M is the MAC address of M. Yeah, whatever is correct. Thanks, Sam. Right. So the source port can be whatever our machine wants. And we'll choose not to erase everything, but we'll choose 2222, just to make things easy. And what's the, can I just choose anything for the destination port? No, why not? Why can't I just pick and choose whatever the heck I want for my destination port? It's not just specific to the machine. Yeah, it's I want it to go to not just this machine, right? To get it to go here. All I need is the IP of DNS. Where am I specific? Yeah, I'm specifically good. Thanks, chat. So I'm specifically trying to get it to a specific service, right? I'm trying to get it to the DNS service on that app. So I need to know what port to talk to. So this will be the default port I believe is 53. Do I just remember that correctly? Or is that wrong? And at the IP level, the source will be the IP of M and the destination will be IP of DNS. And I said, I'll say what is IP of Google.com, right? So I send that packet out, it goes to the router, it goes bank, it goes hop, hop, hop gets to the DNS. So the DNS server knows that port on port 53, there's an application running that's listening to that that has told the operating system, whenever you see a UDP packet for port 53, send it back to me. So it sees this packet and then it sends a packet back to reply. So what's the source port on the reply going to be? 53. Thank you. And the destination 2222. Thank you. And the source here is the IP of the DNS server. The destination is the IP of M and we'll say 8.8.8.8, right? That packet goes out, it goes back, and M knows that's a reply to the original request because it matches up the source and destination ports. Awesome. Cool. So let's think, okay, that was just review. Let's say there's some server out here, X, we'll just call it X for unknown. And Christian, can we use you as the bad person again? Oh, no, Christian's not paying attention. We'll skip Christian. Anybody else want to be our new? Okay, Christian said yes in time. I'll take it. Okay. So Christian is our new bad person. They want to, Christian wants to, let's say Christian wants to break into server X. What does Christian need to know? So how does that happen, right? We haven't actually talked about that. So you want to break into some server. What does that actually mean, right? So does Christian know where the server is located physically? Yeah, probably not. There's a way to like geolocate IP addresses and try to determine what area they're in, but that can actually be a lie oftentimes. So it can be very difficult to know physically where an IP address is. So Christian can't break into the system, right? Or physically break into the facility with that computer. Furthermore, we can assume this system is running somewhere that has pretty good security. They have a man trap that will fall on anyone and trap them in who tries to access the facility unauthorized. So okay, we can't physically break into the server. So think about, has anyone ever watched a heist movie where they've tried to steal things? What's the very first thing they do? Yeah, first one is assemble the crew. And then the second one is what? Yeah, you got to plan stuff. You got to case the joint. You need to surveil the target. And why do you need to do that? Why is that necessary? Yeah, so if we think about a bank, right? Do you care if you're going to break into a bank, do you care that there's an entrance here? And there's an employee entrance here? Why do you care about that? What if you get in there and then you plan to go out the employee exit, but you find out it's actually bricked closed and they're doing construction so that this doesn't exist? What happens to your plan? Yeah, it is not fundamentally not good for you, right? Because you need to know the exact layout. You need to know exactly how to get into the bank. You need to know all the entrances into the bank. You need to know the windows of the bank. You need to know the exact layout, how many floors are there so that that way you can properly understand how to break into it. What are the ways into the bank, right? Maybe instead of going through the front door, it's a lot easier if you go through this employee entrance back here. Or maybe you know that you can disable the alarm so if I know the vault is here and I know now I'm making this a weird... I'm changing the dimensions of this picture because I can. So the doors are here, the vault's here, Christian's hideout is here, right? Now what about drilling a hole into where the vault is? Right, steal everything at night, go back through, problem solved. So fundamentally what we're trying to do here is we're trying to understand what are all the ways that I can get into this bank, right? Or the vault maybe is another thing, right? We're trying to think of what are all the different ways that we can actually do that. And so we want to take that similar mindset when applying it to a server. So fundamentally can we just like wave our fingers and magically something will happen to the server that will give us control of it? Yeah, if you can I have a bunch of magic beans I would like to sell you. So fundamentally what are the ways that I as an attacker can influence the operation of this server? Yeah, send requests, send requests where? So what do I have to know? Let's say I need to know the IP address, right? So let's say I have the IP address because I know that server is my target. Yeah, fundamentally, I want to know what's running on this server. And in other ways, what services are open there that are things that I can talk to? For instance, if there's DNS running, I may want to know is DNS running? And then I may want to know what version of DNS is running. And then I may want to know, are there any known vulnerabilities of that version of DNS server running that I can exploit remotely? It may be a web server, so there may be, let's say Apache. Apache may be running. I don't know if SMTP would be listening or not, but maybe there's a mail server there. Maybe there's SSH was a good one for remote access, right? If my SQL is publicly available, you probably have massive problems. So your day as an attacker is about to be fun. So fundamentally, what we want to know, and again, we can't ever guarantee that these exact things are actually listening. But what we want to know and the equivalence of doing reconnaissance on the internet is what's called the port scan. So Christian's first act is going to be, okay, what ports are open and available on that IP address X. Since we're talking UDP, we'll first look at a UDP port scan. And that way we can see, and Christian can see, oh, is DNS open, is what if their NFS server is open? Maybe there's some cool tricks I can play there, right? By doing this, then Christian can start understanding what is this server for to figure out how to get access. Cool. And the way we do that is basically just a brute force. So we literally send 65,000, what was the port size? So ports one through six, five, five, three, five, I think I have three, two, five, but maybe I'm wrong. And then, and then we have to, so we can send a bunch of these packets. And we already know in this case that the service is up, what do we get back? Right, we'll get back a response packet. And so we can know if we get a response back that somebody is listening on that port. The question then is what if something is not listening to this port? What if I instead here sent it to port 1010 and nothing is actually listening on that port? So what happens is operating system specific. So sometimes at the IP level, there'll be an ICMP message that gets sent back saying the port is unreachable. But oftentimes, if that's even sent, some stacks will let like the implementation of TCP IP in the operating system will limit the error message rate. So it can be pretty slow, depending on your target. So do you want to see this on an actual target? I actually have no idea what's running on this machine. So this should be fun. Okay, so I will use the IP address of 192168.0.1, sorry, local host 127001. So I never remember how to run the different commands of Nmap. So of course, I will read the page and then I'll type in the thing correctly. I want UDP. And so you can see it's telling me here that this dash S capital U is to do a UDP scan. The other thing that's important, and I noticed I've done this a bunch, is the port range. So by default, it'll only do a certain amount of ports. So if you want all of them, you have to do P1265535. So let's do that. Let's do I'm not sure if I have to do it like this, MAP dash S capital U is for UDP scan dash P1 dash P1 dash 65535. And we'll do the local host 127001. So is it illegal for me to do this? Why not? It's my machine. Yeah, so this is my machine, right? I'm giving myself permission. It's just like what we talked about with finding vulnerabilities in software and those kinds of things. So okay, it's going to run. We'll see that it runs slow. I should have set up another system here. Okay, while that's running. Okay, here's the TCP dump. So we can actually see what's happening. So this is scanning all the ports and it's sending UDP packets to a bunch of different ports on my on my router. So if I go between them, you can see it's just scanning, scanning, scanning. And if I look at the traffic here, so the way to read this is, let me see if I can, can I actually, I'll just kill it. Yeah, so we can see. So it's telling me at the specific timestamp, I'm seeing a packet from 127001 my machine with the source port of 49855 to 127001 port 1439 UDP packet length zero. So it's doing exactly what we looked at and trying to see if anything responds. I actually don't think this is going to do anything. I don't think there's any UDP services on this, but I guess we'll find out and that'll be fun to see what happens. Cool. So now that we've seen it actually go and we'll pop back, maybe Dropbox is using UDP, I don't know. But it'll be interesting and we'll see the results there in a bit. But we can see this. So Nmap is a super cool network utility tool for doing these types of things. So you can scan it, an IP address, it will show you all the ones that it thinks are open. So this was a scan. And now you can see this command didn't specify the port dash P1 to whatever. So it shows 1445 likely interesting ports. So port 137 was open port 138. And then the service name on the right is what was in the ETC services file of the mapping of port to service name. So this shows that like NetBIOS was open on this machine. So I guess it's just, oh cool. Two minutes remaining. That's interesting. But we'll show me that. I don't know how come you died. You don't like just dumping. It's kind of fun to watch, right? Yeah, if you ever get interviewed and you want to have something cool, hackerish showing up, you should you can do this on your on your computer. Okay, this will be done in two minutes. We'll come back. Apparently it has longer to go. So using that, this is a way of understanding what ports are open on UDP, which is very simple because UDP is just send the send a packet. If you got a reply back, you know that it's open. If you don't get a reply back, then you don't. You can't tell if it's you think of that it's closed. All right. All right. Now on to TCP. So TCP was the other application was the other application layer protocol. So we had UDP and TCP both built on top of IP. But TCP is going to add a lot of the things that we actually want from our from our network protocols. So TCP and the cool thing is it's built on IP. So we're going to go over how this actually works and it is super cool. So TCP uses IP to provide connection oriented. This means that connection oriented means unlike a connection list where we just send a packet and get a packet, we can actually send data in a stream and actually establish connections. And we'll also get a reliable stream delivery service. So we can just send data from one side to the other. And all that data goes across and we know that it'll get there in ordering. And specifically, it's guaranteeing and this is crazy like think about this. This is this is all done using the unreliable crazy protocols that we looked at. It does this with no loss. So without packet loss, no duplication of packets, no transmission errors, and that the packets arrive in exactly the right order from one side to the other. It's really cool when thinking about this. So TCP also uses the port abstraction. So it's the same in both models and UDP and TCP. Makes sense. And essentially, this connection oriented means that there's a what we think of as a circuit, like a virtual circuit, which is identified by this four tuple on this four tuple is incredibly important. It comes up a lot in networking for TCP. So that's the source IP, the destination IP, the source port and the destination port that four tuple those four values represent a circuit from one machine to the other. So any traffic from one machine to the other, you can tell that it's supposed to be there based on those values. The circuit basically has what they call what two streams. So basically one side sending information to the other and the other side sending information back. So that's the what full duplex means is either side can talk and receive data. And cool. Okay. So let's look at what the TCP header looks like. So just like UDP, we first have the source port and then the destination port followed by some very important values. So again, the sizes of these are just the same as in UDP. So we have 16 bytes, sorry, 16 bits for source port, 16 bits for destination port. Again, this allows us 65,536 different ports and a sequence number. So this is really important. It defines and it's going to be used so that we send data in order. We'll see how this is used. An acknowledgement number, which is used to say, Hey, I've seen up to this point, but again, the details here don't matter yet, but we'll get into that. The length of the header, some reserve bits, some flag bits, a window, which we're not going to get into, but that's pretty interesting when you look at that and flow control and everything checks them again. So now we have a checksum again to try to make sure there's no errors in our headers and data. An urgent pointer, some options and finally padding and then the data. So what's one thing that immediately stands out between this and UDP headers? Anything? Did they look exactly the same? Yeah, more involved, right? There's just more stuff in here, right? There's like everything. There's just more. There's a sequence number, an acknowledgement number, flags, a window, urgent pointer, options, padding, checksum. All this stuff is all new and all different from UDP, but the cool thing is what we'll see is that the flags are super important and the sequence number and the acknowledgement number are incredibly important, but we'll see how all this overhead, you can think of it as overhead, right? Because every single TCP packet you send is going to be using these headers. So it adds additional like metadata data about the data on top of there. So there's some overhead, but it's actually a great payoff because we get this reliable communication mechanism that powers so much of the web as we know it and the internet too as well. Cool. Okay. Sweet. So just like before, our TCP header goes to the start of the TCP data that's put inside the IP data. So we have the IP header and then we have the ethernet header with the ethernet data. And again, the IP header and the TCP header don't change from hop to hop. Cool. Okay. Now we need to see how all this works. How is that not done yet? Are you guys hacking my server? Is that what's going on? All right. I think 10 minutes so far. Now we need to draw a picture. Okay. No, it's not that the, it doesn't need more threads or whatever. UDP scans are configured to run this slow so that they don't go over that error message rate. So you just got to wait, especially doing all of the, actually, so a fun pen testing story is we did pen testing for this company and we were scanning, you know, this is one of the classic things you do is do port scans of their systems to see what's open. Anyways, we did some port scans, found out that they had accessible, I think it was to the developers, a port that was the management port on a server. So if you ever, so if you didn't know, there's like, obviously modern servers have like CPUs, right, which you obviously use for stuff, but there's usually another, the problem with a server is it lives in a rack. It's like a, like a pizza box. It lives on a server rack somewhere. And so if you hose that CPU and you can't get access to it, it's really pain to go there to physically restart the server. So oftentimes there's this management connection where you can get access to the server and you could do things like reboot the whole box. You can also drop a new kernel on there, all kinds of stuff. You have full disk access. I think, I think iDark is the name of this for Dell. Anyways, there's a bunch of different names here, but we were scanning their servers and we found that they actually had this port open for one of their servers and it was their management port. And so I start poking around and I find out, of course, this management port has a default username password, which they hadn't changed. And then I started looking at more and I was like, oh, I can put my own. So like there's obviously like the hard disk in here, right, which is where the OS is. And I could put my own kernel on there for the operating system and completely take over that system. And as I'm looking this up, we see the name of this server. And again, I wasn't scanning it remotely. It wasn't remotely accessible, but like one of their developers could have got access to this and done this kind of stuff. So anyways, I'm finding this stuff out and we tell our contact in the company, hey, this is what we're finding. This is kind of what we're planning. It'd be really cool to demonstrate that we could take over the system. And they're like, oh yeah, that is crazy. What server is that? And we tell them the name of the server. And they're like, absolutely do not do this. This server is processing credit card transactions. If you take that server down, we'll be down like, you know, a lot of money. So we will trust you and we will fix that. So please do not test that server at all. So that was pretty fun. But then the funny thing was then they came back to us and was like, how did you find this? Like we have, they're a really secure environment and they do things like scan all like they port scan and everything, all of their servers all the time. And I said, well, yeah, but I changed the configuration. So it would scan all ports, not just the standard ones. And that's what ended up detecting this. So anyways, I guess the moral of the story is you can think that you're scanning things, but if you're using the default configuration, you're not exactly sure what you're scanning, you may not pick up what you think you are. So yeah, that was a fun story I like to tell. Anyways, TCP. So what is a good website? We want to talk to Bing. There we go. Thanks. So me, I want to make a connection to Bing. The X Microsoft person in me appreciates your fanboy ism. Cool. Okay. So just like before, I want to, I know, so I know the IP address of me, I know the IP address of Bing, right? And because I've done and the interesting thing is what we already saw, I'd used what protocol to get go from Bing.com to the IP address of B of B. Yeah, thank you. DNS, which was UDP. So we already, so think about that. We, you've learned exactly how that request works, that DNS request. So you can think of when you put Bing.com in your browser, you hit enter, you know exactly all the networking steps that happen for that UDP request to make it from your machine to the DNS server and then back to you to get to the IP of B. Now you're going to study on what looks at how do we make that TCP connection to Bing? Okay. So, so I'm going to want to try to make a connection to Bing. So I'm going to send them a packet. Trying to think of how I want to do this. I'm going to do my packet slightly differently with IP at the top, and then the next layer of TCP. Is that going to be okay? Or is everyone going to freak out? I just realized it's slightly more accurate to the diagrams I was making. So, so source IP, what's the IP source? Now it can't be whatever. Yeah, IPM, thank you. The destination IP is IP of Bing. Cool. Now I'm at the TCP port. So now I have to basically, I'm trying to ask them to start a connection. So all need, I have my ports here. So again, now this is where you can say whatever. So the TCP source port is my port. I can choose a random port. So that can be whatever I want. So we'll do two, two, two, two. The destination port. Now, what did I say? What kind of request was I making? No, I already made the DNS request to get this, the DNS request was here. I'm making a TCP request. What kind of service am I talking to? What port is the web port? Yeah, we'll go with AD. We will ignore HTTPS for now, but you, but yes, default port for webs, web servers, HTTP is port 80. So I'm going to make a TCP request, sorry, I'm going to make send a TCP packet to port 80. And okay. Now I need some way to signal to Bing that, hey, I want to make a new connection. Essentially, what I'm trying to say is, I'm a new person. We haven't talked before. I need to, I would like to establish a new TCP connection. And so there was those flags. So I'm going to send a packet and I'm going to set the sin flag. The sin stands for synchronize. So it's kind of, you can think of it as a way of saying like, hey, let's start talking. I want to start talking. Okay. So this packet comes out from M, goes over to Bing. What does Bing's operating system do when it receives this packet? What's one of the things? Yeah, it needs to respond. And well, it almost needs to respond, but it first needs to ask the question, well, A is this packet meant for me, which it will look at the destination IP address and say, yes, it was meant for you. Great. The second thing it'll do is it'll say, is there, do I have a service that's listening for TCP port 80? And lucky for us, actually, it's definitely not going to be a patchy if it's Bing. Is it definitely not? Probably not. Is it ISS? Is that, or is IIS? What's the, what's Windows web server? Does anybody know? IIS. Thank you. Yeah, information, something server. I don't even know what it stands for. IIS. Cool. Okay. So the SIN packet comes into B. It says the new request. Yes, I have something listening on port 80. Excellent. I will try to establish this connection. And then now B needs to send a reply back. So it's the reply back from B, from Bing to my machine. So at the IP level, source will be IP of B, destination will be IP of M, internet information service. Thank you. I appreciate that. Oh, I guess that makes sense. One is information. What is the internet? Cool. So I guess let's think about it at this point, even before B sends something back. So a packet was sent, M sent a packet from M to B. Should M send all the data that it wants to send to B right now? If no, why not? Yeah, the service could be down. The host could be down. Anything could happen, right? So M has no way of knowing that B is actually up. So why send data before you actually know that somebody can listen to it? So we need to wait until we've established a connection. Okay. So B is preparing its reply. It now says, okay, so my source port is, so things are flipped when they're going the other way. So the source is from IPB. The destination is IPM. The source is port 80. The destination is port, which port? Can I choose a port? Yeah, it has to be 2222, right? That four tuple, right? Of basically IPM 2222, IPB port 80. However you want to do that, that four tuple basically defines that connection. So it has to go back to 2222. Okay. And so it also sets the sin flag because it's trying to synchronize. So it sends out this packet. This packet goes out, goes back to M. M receives this packet. So now does it know that B is up? Yeah, doesn't know that B wants to talk to it? Yep, we think so. Actually links these two packets together though. So I guess we should ask a question. Does anything link these two packets together? And what is it? Yeah, it actually goes back to this tuple, right? That combination links those two packets together. Okay. Okay. But we need something more. And so the way this is going to work, let's fast forward. So let's think about a stream, right? Let's start at zero. So this is the sender. And this at zero is the receiver. Okay. So the sender is going to want to send data, right? So the sender is going to want to say, let's say sends a packet first with 100 bytes, and then sends a second packet of another 100 bytes, right? So the receiver, how does the receiver know which is which? So let's say the receiver gets a packet of 100 bytes. How could it know that it goes here or here? Could it say, aha, this is the first one that I see, it must go here? Yeah, let's think about the header of what's going to arrive. This is good. So it's getting sent from us. So source IPM in this case, destination IP of Bing. The source port here is 2222. Destination is port 80. And here's my 100 bytes, right? So just think about this fundamentally, the receiver, Bing gets this packet. How does it know where in this stream that I meant this to be? Is there any way for it to know what we have in here? Yeah, but what we have in this packet, we're not talking about what should be in there. Just going off of what we have in here, do we know where to place these 100 bytes in this stream? Yeah, no, right? We don't have enough information for this. We actually need additional information. So yeah, exactly. We want something like the offset. So if we said, hey, these start at zero. So if we say the sequence number is at zero, now can the receiver put these 100 bytes where it's supposed to go right here? So it would know that precisely these 100 bytes go right here. What if the sequence number was 100? Then would it know where to put it? Would it put it here? Yeah, no, it wouldn't put it there. It would put it, I regret using these colors, right? It would say here and would the receiver know that it's missing 100 bytes? Yeah, because it knows that it hasn't got any data from here, right? It knows the only data that it's got. It starts at sequence 100 and is 100 bytes, right? And it'll say, hey, what happened to, like, I never got anything starting at zero. Okay, so we actually need to set up this information as part of our communication. So when we're trying to connect to the other side, what we've missed in our diagram is some kind of sequence number so that the two sides can start communicating so they can start at zero. And for reasons that will be apparent later, they actually do not start at zero. It's all relative, but the first number is actually specified this. So what M is going to do is when it... Actually, I'm going to do this. There we go. Beautiful, just like I planned it like this. So let's say for reasons that will become apparent very shortly, our sequence number is... Now, for reasons that'll be apparent quickly, our sequence numbers want... We want to be random. Let's say this one is 999. Let's just say. So the other side... So this is when we send our SIN packet and we set a sequence number. Now, the other side wants to... Needs to acknowledge that it actually got that. So now it's not going to use the sequence number, right? Because so you got to think of it in terms of directions. So M to Bing, that sequence number defines where data is on there. What we want to do is we want to acknowledge that we... Your sequence number. So again, this is something else that links these two packets, but there's a wrinkle. We actually don't acknowledge the initial sequence number. What we acknowledge is one plus the sequence number. Why would that be? How easy is it to just copy these bytes in this header that I got and put them here? Good guesses. Zero bytes indexing. Yeah, it's actually not because it's the next one in the sequence of packets because all of these packets are zero bytes. So we're not sending any data here. Yeah, that's a good guess. So let's go back to these diagrams. Hey, welcome back. Five seconds ago. So sequence number, 32 bits. Acknowledgement number, 32 bits. What's the most significant byte in this sequence number? What's the difference between endianness? Anybody remember from architecture? Yeah, not quite the bits almost. It's in terms of bytes. So the sequence number is split up into bytes. And the question is, which is the most significant byte? So for instance, if this is all zeros, zero, zero, let's say one, oops. And the question is, as a 32 bit integer, does this represent... And I honestly don't remember which one is little indian or big indian. So bear with me. But the point is in one version, I always have to look it up because the specifics are not important. But anyways, is it one or is it hex one, zero, zero, zero? So is that one the most significant byte or the least significant byte? Yeah, little starts on the right. And I think most modern CPUs are little indian. And the network is big indian. So if we go by that, I believe... So your CPU... So think about this, it's crazy. The numbers that are being spit out on the network are different than the numbers that your CPU thinks. So it has to translate it every single time. And as a bit of a way of actually debugging and trying to understand, that's what this one is doing. So the question is, taking those... That sequence bytes and just putting it in as acknowledgement doesn't mean you actually understand that it's the correct byte order. So this is why you have to add plus one to it so that you can prove that you're speaking big indian packets. So anyways, it's a fun little quirk that actually has a very cool technical reason behind it. So when you're designing things, you can think about, hey, how can I design this such that it's part of the protocol that your system will actually work? Okay. Cool. And let's... Okay. So we've now proved from one side to the other. And remember, once the connection is established, either side can send packets. So this packet gets sent. Now n can check, okay, is this for my connection? It checks the tuple. It says yes. The tuple looks great. It checks the sin flag. It says great. This other side is acknowledging me. So it's a sin and an acknowledgement. So the acknowledgement field is set and the sin flag is set. And then... So now, can they start communicating? So does M know that B is up and wants to talk? Yeah. It just got that packet back. It says, yes, I am available. I have a service running. I want to talk to you. I'm trying to establish a connection. Now, what about from B's perspective? Does B know that M still wants to continue the communication? Or think about it another way. Think about it from M's perspective. When M gets the second packet back, does it know for certain that B got its first packet? Yes. Why yes? Yes, because it got a response because it got the response. So M got the response from its packet that it was thinking about. And so that means that that's great. So this means that from M's perspective, it knows that B got that packet. But from B's perspective, how can B know that this packet that it sent was received by M? Yeah. Fundamentally, B has no way of knowing. M actually has to reply again to demonstrate that it has received that packet. Exactly. Cool. So we have the final step where M sends at the IP level, the source IP of B, destination IP of M, the source, wait, I missed. Yeah. Okay. No, no, these are wrong. The source is from me going to the IP of B and the source port is port 2222. The destination port is port 80. My sequence number is now a thousand because we went through this response and I haven't sent any data yet. And now wait, how do I acknowledge that I got their packet? And what if they want to send me data? How will I know what their sequence number is? So B in its response also creates its own sequence number. So this one, let's see, I like, I don't want 80. We'll use nine as the sequence number. So it needs to acknowledge which number. What's it going to send back? Ten. Thank you. And it drops the SIN flag. I'm missing an important flag. Let me double check. But yeah, there we go. Cool. Okay. So basically this AC flag says that the acknowledgement is correct. So you have an AC flag and an acknowledgement in the header, acknowledgement number in the header. Cool. So M then sends this off to B. When B gets it now, what does it know? Yeah, B knows that this packet was received, that the other side got its packet, and that the connection is a fully established now. So both of them have set up their sequence numbers and they can start talking and sending data either way. Amazing. That's great. So this is how the, so this is a three-part process. This is why it's known as the TCP three-way handshake. Super important. This is something you should burn into your brain is SIN, SINAC, AC. This is the steps of the three-way process. And you can basically derive all of this from that. So you first send a SIN packet. The other side responds with the SINAC packet, and these are referring to the flags. So these are the TCP flags. So let's check this. Make sure, okay. Yeah. So the sequence number, like we said, specifies as we'll see, and we'll do actually data sending in a second. But the TCP, the sequence number in the packet defines where we are and where I'm trying to send you data. And the acknowledgement number we'll see basically is a way for one side to tell the other, hey, I've received up until this much in the stream in the sequence, and I'm missing everything after it. And this is exactly how things like retransmission, so if a packet is lost, the two sides will actually be able to detect this and resend that data if we get duplicates. So if we get, yes, it should say sequence number 1342. Thank you. Yeah, that's a typo. Luckily, I can fix this. All of this. So duplication. So if two packets arrive, right, and we can actually see this. So just like we looked at here, if I get a second packet that says the sequence number is 100 for 100 bytes, I'll say, hey, I already have data here and drop that data, and I won't actually send it up to the application. So the application has no idea that the IP is going haywire and multiple packets are coming and packets are getting dropped. It's so cool. So all of that is for that. So the flags that we've talked about, SIN, so synchronization of a sequence and acknowledgement numbers. ACK is stating that the acknowledgement number is valid. So almost every packet except for the first one has that set. SIN is a request to shut down of one stream. So one side can send a SIN packet from the other. And to shut that down and says, basically, a SIN says I am done talking with you. I don't need to send you any more data. A reset basically says is when things go haywire, like if something ever happens that like, oh, let's say here, if I just received a SINAC packet that I wasn't expecting, like the second step of something that like, hey, I don't recognize this. I don't have this IP, like this tuple in my data. I have no idea what you're talking about. I'm going to send you back a reset packet to basically tell you to go away. Urgent is not really used and push is also kind of not really used. So let's walk through setup. This could answer that question. So so basically the SIN packet of the initial thing says, hey, this is my initial sequence number. The server responds with the SINAC and has its own random sequence number from the server. The sequence number of the client plus one as the acknowledgement number. And the client then sends a TCP packet back with the AC flag set and with the sequence number of SC plus one and SS plus one, just like we talked about. So okay. Yeah, basically, we want initial sequence numbers to be random is what this means. And so we can walk through the TCP handshake. So to answer the question, the server knows that this is a first packet because it has the SIN flag set and none of the other flags set. So when it receives a packet from a certain IP port and a different packet, it's because all the rest of them, as we'll see, all have the acknowledgement flag set. Oops. Hello. Okay. Didn't unplug anything. So in this example, the client is sending data to port 22. What's port 22? Yeah, SSH. Thank you. Right. So trying to make an SSH connection to their system. So it's a random source port 13987 to port 22. It generated a random sequence number in this case 6574. And the acknowledgement number is zero. And again, the SIN flag is set. So this is the first step of a three-way handshake, which is SIN, SIN, ACK, and ACK. So the server will reply, flip the ports, and it will say, okay, I'm going to generate my own random sequence number. This time 7611. I'm acknowledging your sequence number plus one 6575 and sets the SIN flag and the ACK flag. Now finally, the client wants to complete the three-way handshake and says, okay, I'm game. Let's play. My source port is 13987, just like before. My destination port is 22. My sequence number is 6575, which is what we just agreed on. And I'm acknowledging 7612. And I'm setting the ACK flag. Cool. Any questions on the setup of a TCP connection? And so think about this. It's kind of crazy, right? In the time that a, let's say DNS, right? When you make a DNS request and you get a DNS response, you're done. The game's over, right? For UDP connections. But here I need three packets back and forth just to even establish a connection. Literally zero data has been exchanged at this point. We're just sending packets back and forth. And then we can share data, which is very different from a UDP model where you say make a request in one packet and you expect one response back. So you can see the overhead that adding all of those things on top of IP, including like a reliable stream delivery service, you have to pay in terms of the overheads in the individual packets like we saw, but also overhead in this three-way handshake setup. Cool. Any other questions? That wasn't a question. That was just something I thought of. Now we want to send data. So let me make room because I want to reuse our connection. So send, send, act, act. Cool. Oh, how's the UDP scan going? I feel like somebody's just trying to get me off topic so I can, still not done. An estimated 11 minutes remaining. How's that even possible? All right. I'm just going to do a thout. There we go. Okay. All ports were closed. Cool. So you can see with a thousand ports, it is very quick. 1.67 seconds. Kind of surprised it's taking this long, but you know what? That's okay. All right. So now we want to send data. So let's say, so we've established a connection, right? And actually our application would know that our application knows that now a connection has been established. So actually all of this, I believe on Linux happens under the system call connect. So if you look that up, it's a function you can ask the operating system, give it an IP address and port and it will make the connection there. Cool. So now let's say our application wants to send data and it's a web request. So it'll probably look something like get space slash space HTTP slash 1.1, something like that. host equals bing.com, whatever, whatever, other stuff. So let's call this 25 bytes. Does that sound good to everyone else? Well, thank you. Okay. So now we need to send that data. So we need to make a new packet. We can't reuse or expect any of our old ones necessarily to work. So we have a new packet at the IP source IP of me destination IP of Bing. Now at the TCP level, I have the source port of 2222 destination port of 80. And let's see my sequence number is 1000. And what was the last sequence number I saw? So that's what we need to think of for the acknowledgement. So the acknowledgement number is always the last sequence number you saw. The last sequence number I saw from them was basically 10. So I'm going to acknowledge 10. And my flags, I'm going to put the AC flag. And now I'm going to have 25 bytes of data. Okay. So this gets sent from me to Bing. Now at this point, can I tell the application, hey, great job. The other side saw your, your 25 bytes that you sent. Yeah, no, why not? Yeah, I need the other side to acknowledge again, this is where we get act from. I need the other side to act that it actually got that and saw that because this packet could have been dropped. Anything could have happened along the way. So I can't tell the application that I sent it's their data until I've actually sent it. So these 25 bytes get sent. And then the other side, uh, replies, uh, IP of Bing destination IP of M. These are all at the IP level. Then at TCP, we have the source port is 80 destination is 2222. Now this sequence number is going to be 10 because we haven't sent any data yet. And the AC is going to be the, where it's expecting the next data from. So if we think that this, if we go all the way back here and we say, actually, these are both now at, in this case, uh, what was it, a thousand or was it 10? So the sequence number here is a thousand. And so I've seen so 1000. I have, they sent 25 bytes. I've seen 25 bytes. And now, and now the next byte that I'm expecting should be 10,025. Right. Because that's the next thing that I'm expecting to receive from the other side. So my AC should be a 10,025 and I'm sending zero bytes. Now, when I send this and it gets back now, what can, what do I know about what Bing knows? Has Bing seen my data? Yes. And I know that because I see that they've acknowledged up to 10, 25, right? So I think I've sent 25 bytes. So I was at a thousand. I sent 25 bytes. That means I'm now at 1025. And Bing has, uh, was at a thousand bytes and they're telling me they're now expecting 1025. So they've seen the 25 bytes that I've already sent. And at this point, I tell the application, Hey, great. I sent your data and I know for a fact the other side got it. And I know for a fact it wasn't dropped, it wasn't duplicated. It went in exactly that order. So if you send first 25 bytes and another 25 bytes, I know those 50 bytes are exactly in the right order that they should be. Cool. But actually I don't even have to, and just to illustrate what can happen, I can actually, and usually this doesn't happen. Usually you get zero byte acts from one side to the other, but I can send data back. I can send, let's say a hundred bytes back. Let's not do that. I don't like that. Let's send 50 bytes back. So now Bing has sent us 50 bytes, but again, does Bing know that we've actually received it yet? No, it waits for an acknowledgement from us. So now we actually need to send another packet back. And this will be source IP of me, destination IP of Bing. And at the TCP level, source 2222, destination to, nope, 80. And the sequence number here is, so I've sent you up to 1025. And I'm acknowledging that I've seen up to 60. And of course I'm missing here the flags, right? There's always the act flag set. Cool. Zero bytes. Send back. And then now when Bing receives it, does it reply back? Yeah, no, it doesn't need to, right? No data was sent. So you'd never have to reply to a single, it's a zero byte act, but they can continue on this way, exchanging data back and forth. And this way both sides will know when to actually do this. Man, why did I, 10 minutes remaining? Well, you won't ever see the results of that. So that was fun. Okay. So cool. So we can walk through the data exchange. So just like we did before, it's all about how many bytes you've sent. So in this case, 25 bytes a cent. So the server then increments the sequence number by 25 and says, okay, I'm acknowledging that I've seen that I'm expecting next byte 6600 and can also send 30 bytes. And that will just continue back and forth. And then finally we can shut down the connection. So either side can send a fin packet to say, I'm no longer talking to you. The other side responds with an act. And from that point on, A will never send any data. So it's just shutting down one side. And then finally B can shut down its side and then it's considered closed. So basically one side sets the fin flag on the packet. And then the other side can continue to send data, which it will acknowledge until finally it sends its fin packet. And it may or may not send that last acknowledge. Again, the fin packet doesn't say I'm never going to send you any packets. It says I'm never going to send you any data. So this is why we can send a zero byte acknowledgement. So that at this point, that virtual circuit is shut down. The virtual circuit was source IP source port or destination IP destination port. And there you go. That is how TCP works. It's kind of crazy, right? And that happens for every single web request you ever make. This happens constantly. And think about now, if you're on like a internet connection like a satellite or something, like literally every packet you're sending is going from your house up to a satellite and back down to earth, all of these sequence acknowledgement packets. Same with your cell phone. When your cell phone does this, it has to send packets through the air to a cell phone tower, which then have stuff happens to. Yeah, it's crazy that this like actually works. And there's again, so don't not take a networking course because of this, but this is the basics of how this actually works. There's a lot of really cool complications that we're not even touching of how to, there's like making this work and then there's making this work in a practical way and a fair way so that people aren't sucking up unfair bandwidth. Anyways, networking is super cool. And yeah, you would be, it'll help you in your career to understand networking at a fundamental level. And with that, we are done. So thank you, everyone.