 everyone for being patient. Swarm of undergrads midterm on Friday. So you guys understand the feeling desperately need to know what's going to be on that midterm, right? Desperately can't tell them. Even though you want to any questions for skirt? This lights are on the line. Yeah, I suppose so. Yes, I'm going to email to remind me. I'll do that. Any other questions? It's a good question. All the way to being rated the latest one. They'll be submitted. I already answered this on the list. The max score, your max score. Okay, to go back. All right. So I looked it up. Reachable attacks are actually incredibly simple. And the basic idea is destination reachable can be that the hots like you couldn't actually get the packet to the host or one of the messages is, Hey, that port, I couldn't talk to somebody on that port. So the idea is if there's a communication between this one, two, three and this five, six, right? If I guess what port they're talking on, I can send a destination reachable ICMP message, spoof it as if it's coming from one end of the communication, and then the other end receives it, it will terminate the connections and things that it can't talk to that machine, which is actually pretty funny and weird because TCP and UDP have methods to do this, right? If you send a packet to a host that nobody's listening on, you get a reset or a thin packet, right? So, but because of this, they actually allows you to acknowledge service and communication, right? So you think about this can be really bad if you do that constantly as soon as this connection is always made, they can't ever talk to each other. All right. So that's what that is. I'm not anywhere near as complicated. Okay. So we talked about UDP. So somebody reminded us what's so special, what's important about UDP, what layer, where are we at? Your hand up. We are at layer. The numbers aren't clear. The numbers. Okay, we are at the transport layer. Above where? Above the internet layer. Yeah, above the IP layer, right? So it looks at IP, it looks at all the ICMP messages, and then we moved up into the transport layer into UDP or TCP by mainly, so now we've looked at UDP. So what's some interesting things about UDP that we looked at is in general, like some of the features of UDP, so we can context switch back into the stuff, right? Yeah, it's connected from this, it's done only over the, with packets, and there is no guarantee that the backup would reach to the output. Right, so it's basically, and yeah, UDP boiled down, right? Is a best effort, so no guarantees on ordering or delivery or repeated delivery, and it's just a packet. So we just send one packet and, but the important thing, right, is that it's opened up this host, I'm sorry, the port abstraction, right? So on one system, one IP address has 65,000 ports, right, and so any, you can send a packet to not just a UDP packet, not just to a host, but a host name at a specific port. So from a security perspective, right, we want to try to understand what ports are active on a given machine. Why do we want to know that? Is that, why is that useful? So to know what services you could possibly exploit? Yeah, so to know what's run, so we did, well, why do we do like a ping scan or an IP scan? So we do a ping scan, right, to see what posts are up, right, to see what IP addresses are responding to things, right? That tells us, gives us kind of a layout of the land to show us, okay, who's actually up. But a port scan, right, tells us what ports is that server listening on, right? So why does this tell us what services it's actually running? It's really just ports, right, it's just going to give us back some numbers. So it's, right, because if you think about it, this is the internet architecture. If I want to talk to you on a specific service, a specific in this case, UDP service, I even know where to send that packet to what port to talk to, right? If I don't have knowledge of that, how are we ever going to be able to communicate? Do I just try all 65,000 ports on your machine and hope that I get the one? No, and so there's a standard, right? So there's a standard definition of that map ports to services. So for using this, we can do, if we can scan that system to see what ports it's listening on, that will give us an idea of what software is running on that machine. Why is that important? Yeah, right. So if there's a server or some software application that's listening on a specific port, that's how we can get data into that system and potentially take over that machine, right? If the machine is not running any services, is not listening anywhere, oh, then it's really hard for us to attack it, right? Because we can't get information into that machine, right? So port scanning is very important because it tells you what services are open there. And so basically the way to do this with UDP is you send out a zero length UDP packet, you send it out to every port. A lot of ports, right? And then if you get a message that says, hey, port unreachable, then you assume that that port is closed. What's the problem here? What could be a problem here? How many packets are we going to send here? That's 65,000 packets, it's a lot of packets, right? And for each, we can get back to another message. Yeah, right, that's right. So what we're going to get is the machine that's going to send us 65,000 packets back of error messages or 65,000 minus the number of ports that it's actually using. So because of this, actually a lot of TCP stack implementations, they put a limit on counting error messages they sent, right? In this case, so that way they don't just flood the network by saying that the ports are closed. So this type, so a lot of the tools like Nmap have to do this very slowly and keep this into mind when they're doing a port scan of UDP. So they'll try to do, you know, 80 every four seconds, they probably do it slower. I'm sure there's configuration options in Nmap to specify exactly how many to send. So you do a port scan, boot up the old Nmap. I should change that thing. So it's going to do its work. Target this host, the U flag says to do a UDP scan and the S means to do a port scan. So it's doing a UDP port scan. And so it's looking for any interesting ports on this post. Yes. Okay. The other interesting thing about Nmap, right? So my default 65,000 ports is a lot, even if you're doing it, have not very fast of a rate. Oftentimes, right? So because we know what ports map to what interesting services, usually it'll keep them. I think in this case it's doing, so it's telling you here that it scanned 1,445 ports instead of the whole 65,000, because these are what it considers to be the most popular or most used ports, right? So if you want to do something quick, you can do this. There's another option in Nmap. I cannot remember what it is, but there's an option to do all ports, like all 65,000 ports. And so we'll tell you like, hey, port 137 of UDP is open. And it tells you the service name that that maps to. So in, I believe it's ETC services on a Linux machine is the mapping of port numbers to service names. So you can look there. It's pretty cool to kind of browse through there and see the stuff that was running. And so we can see by looking at the TCP dump trace of this port scan, we can actually dig in and see what it's actually doing, right? So we can see that, okay, our host here, 192.168.1.100 is sending a UDP packet, we can tell it's UDP because of here. 192.168.1.10 with the size zero of an ID 61284, right? So it sends that out to port, this is the port. So it's port 138 and it also sends to 134, 137, 140, 131, right? So it sends back all of these and then Nmap is keeping track, right, of what packets it sends out to what hosts, or sorry, what ports it sent out to what hosts. And then when it gets, so remember, it's going to get back an ICMP message, right? It says, hey, this port is unreachable. I couldn't get a message there. So then it keeps track. So it says, okay, that means 134 is probably close. And I'll kind of do this and say, okay, 40 is closed, 31 is closed, 32 is closed, 53 is closed, 49, let's see where are we at? Yeah, so you go, so basically the, where you, but is this any guarantee that those ports that it says is open are actually open? What's an alternative? What is this, right? We got to, this is part of what I want you to learn about why things are happening, right, at this low level is, yeah, it's really easy to just use this tool, right, you can use Nmap, you can go online, read some tutorials, right, to actually understand how it's doing it, that way you can interpret the results that it's giving you back. Right. So if it says that a host is, is open, what does that mean from here, from these kind of these traces? Yes, right? It didn't, we did not receive one of these ICMP port unreachable messages. Does that mean that that port is open and something is listening there? I might have gotten lost, right? It could have gotten lost. That ICMP message could have gotten lost. Maybe we accidentally sent too many packets and so it just dropped that error message, maybe the network's congested, maybe the network's busy, right? ICMP is an IP level packet, so it has absolutely no guarantee of delivery or anything like that. So yeah, so that's just something to keep in mind, right, about how is this actually, this tool actually working, so that I can interpret those results correctly, because you could run these results again and get a completely different output, you know, completely different, but maybe slightly different, right? So you need to know how to interpret that. Questions on UDPs and UDP port scanning? Yeah. There's an NMF stealth scan. It reduces the port, open port, even the ICMP. Yeah, we'll look at that with, does it do stealth with UDP? I actually don't remember. I don't think so, because it's, I think one other way you can use, we'll see when we look at TCP, we'll see that there's a bunch of different ways to try to do this, to be more stealthy, but that has to do specifically with how TCP is implemented. For UDP, that would be interesting. Anybody know? If you happen to look it up, let me know. That would be interesting to find out if they're stealthy. Yeah, you could be, I mean, you know what I'm talking about, stealth, right? You could be pretty stealthy if you, if the time in between sending these packets is on the order of days, or weeks. You still get the information about what ports are open, but do you think they're gonna look at every UDP port and every ICMP port closed message? Probably not, right? So yeah, stealth has a lot to do with time, right? So it's kind of like a function of what traffic you generate and how that traffic looks over time. Cool. All right, so now we move on to the main event in some sense, TCP. So what's TCP besides transmission control protocol? Like what, what do we, what's interesting about TCP? What are some of its properties? And compared to UDP, what are the differences? What's the difference? Yeah, it's, oh. Sorry, what? It's close to getting to the end engine. Okay, good. Re-transmissible. Yeah. At a high level, what does that mean, though? Maintain to state. It's like, yeah, so from the application level, right, we can use a TCP. We know we're gonna create a connection to another server, right? And then we know that we have some guarantees that our data gets to the other side, right? We can actually know that our data got there. We know that it got there in order and that there wasn't any retransmissions, at least from the application side when the application gets that data. Yeah, so we kind of actually is very nice because it provides this, on top of this unreliable IP connection, right? It provides reliable delivery, well, not delivery, but a reliable connection. So, specifically, there's, you know, there should be no loss of packets, no duplication, no transmission orders, this is the correct ordering, right? Does it guarantee that your packets are actually going to get, like the connection is going to be successful? You guarantee that you can send TCP data to anybody? Any IP? No, right? So, you could not get to them. What happens if you're in the middle of a TCP connection and your Wi-Fi shuts off, right? So, but the point is, is that you know, whereas in the case of UDP, right, you just send out a package and you never know that something bad happened, right? This way, you can actually know that the other host, you either couldn't establish that connection or you never got an acknowledgement of the data that you sent. So, this is kind of the key thing here. And TCP also has the port abstraction. So, this is why ports are so very important. So, when we talk about a connection, what's involved in a connection between two hosts? Just anybody, how do we define a connection between two hosts and TCP? The source port and the destination port? Source port, destination port for the protocols and encryption thing, like, There's no encryption in TCP, no encryption. Yeah, but they look for the, like, what sort of, some sort of protocol. So, source port, destination port, what else? Is that it? On the other side, sorry. Three main handshake, three main handshake. Three main handshake, that's how we establish a connection, right, but what defines a connection? Board and IP. IPs, yeah, that's the other thing, right? Source, source IP, source port, destination IP, destination port, right? This is a four-tuple that defines a connection. So, this is how, when you communicate from one client to the other, this is how both sides know that this connection is unique because they use this four-tuple, right? So, we can call it a virtual circuit, right? We have, abstractly, a circuit between us so we can transmit data and information across there. This is an important thing. So, source IPs, source port, destination IP, destination port. And, you know, some other stuff, right? We can both talk on this connection, so we can send data, and the other side can send data back to us. So, yeah, you can also, we refer to it as a socket, as an IP address port number. Okay, so let's look at the TCP header because it's gonna give us some kind of important information about how it operates and what it actually looks like. So, we have source port, destination port, right? These are the important things at the TCP level. Where does source IP and destination IP live? IP by destination IP, yeah. It's in the layer below us, right? So, at this layer, we actually don't know what that is. The next is gonna be a 32-bit sequence number, which we're gonna look at explicitly how that works. Then we have a 32-bit acknowledgement number. We have the length of the header if there's any, a field indicating the length, if there's any options. We have some reserve fields, flags that we'll see that are important. We have a window, which is also very interesting. Then we have a checksum, an urgent pointer that's supposed to say that this is really urgent to send. I don't know that anybody actually uses this anymore. Any kind of options, then some padding, and then finally the data of the packet. And so, right, so we go back to encapsulations. This is the beauty of Neverking, right? That TCP packet is encapsulated inside of an IP packet and that IP packet is encapsulated inside of a frame header, right? So each layer on the local network break, that frame header is ripped off and then the new frame header is added when it gets sent out on another physical medium and hops all the way through until it gets to your application where the application gets the data once the connection is established. Questions, TCP? Okay, so how do we actually make a connection, right? So this is something that is critically important because unlike UDP where we could just send a packet to somebody, anybody, right? And they just have to receive it and decide what to do with it. In TCP, we're actually establishing a connection between two machines. And so the idea is we use these sequence and acknowledgement numbers in order to specify, so if you think of it as a stream of data between two machines, right? These sequence and acknowledgement numbers basically say where the data should be in this string. And the acknowledgement numbers are a way for the other side to say, hey, I've got the data up to this point so that we can know if they've missed something or if they've not missed something. If, I hope this is kind of review-ish for you. If you get caught up in here, this is a really critical issue, so you should, you know, TCP rules everything, so you should study, you know, understand how it works. So the idea is the sequence number, or the SIN, the sequence number means that is the position of the data in this TCP packet. And so it means that from there to the length of the header, so in this case, let's see if I can do this in my head, 32, no, 35, 35 bytes, is that right? Different string there, math. Okay, they never told me in school I'd be doing math in front of a bunch of people. Okay, right, so this means that, okay, in this segment, this is data from byte, you know, 13, 4, 23 to this byte. And then when we send this out, essentially the other side is going to act back and say, hey, I've, this example doesn't follow, but the acknowledgement number means that, okay, whatever it is, if it's 16, 7, 53, it means that I've received up until that number minus one. I've received up till byte 16, 7, 53, and so I expect your next thing that you send to be 16, 7, 54, right? So this is the way we're able to each side to know what the other side has seen, right? We can know if there's problems dropped or anything like that. And so this is how all of the, if anything's lost, we handle it this way. If any packets are duplicated, the other side, one of the sites will drop it because it's already seen and acknowledged that data. We can do some cool stuff with flow control, which we're not gonna go over, so we try not to overload the network. The window size is actually very interesting. So the window was, I think it was a 16-bit field, right? Half a word in the header. And basically, it says, essentially the width, I think the kind of thing about it is the size of the buffer of the receiver that says, okay, this is how much data I can accept for you to send. So basically from the sequence number plus the window size, that's how much data I can send, or actually the acknowledgement number. The acknowledgement number plus the window size, that's where you can send me data, right? Which is actually, when you think about it, a very forward-looking feature because if you think about mobile devices and embedded devices, right, that maybe you have smaller hardware constraints, right? They can't accept if you're just Google and you just slam a bunch of data back at them. You're gonna get a lot of drop packets. So this is a way to each side can actually tell each other, hey, this is how much data you can send me. And this can, yeah, it can be changed. It can change our conditions. So the TCP flags are where it gets really important. So these allow us to specify certain properties of the packet. And specifically the flags we're gonna be interested in here are all going to be about how we actually establish this virtual circuit, right? Between source IP, source port, destination IP, destination port. So a SIN, so a SIN flag means that we're requesting a synchronous, it's used in connection setup, so we'll see that. Thanks for synchronization, SIN. So when we say, when I say something like a SIN packet, right, is there, it's not really such a thing as a SIN packet, right? It's just a TCP packet with the SIN flag set, right? So it's just one bit. The other bits of the flags, the ACK bit, is the acknowledgement number is valid. FIN, the FIN flag means I wanna shut down, so I'm not gonna talk to you anymore. After I send a FIN packet, it means I'm not gonna send you any more data. And we have a two-way connection, so this is how you can stop connection in one way, basically. And RST, a reset, is a request to basically like, hey, something went horribly, horribly wrong, we should stop and start over, because I don't know what you're saying, or something horrible happened. Urgent has to deal with the urgent pointer. I really don't think this is ever used. The push is interesting. It basically allows the client to request that the data be pushed up from the TCP stacks buffer into the application layer. So it means that, hey, the application really should get this, rather than you waiting for more and more data, and then giving it up to the application layer. So this actually is used, which is kind of interesting. Okay, so SIN packet has a SIN flag, a SIN AC packet. When I say something like that, it means the SIN flag and the AC flag is set. A reset packet, a FIN packet, these are all just flags. So just to make sure we're all clear. Any questions on this? Hopefully not crazy new. So how do we set up the circuit between two ports and two IP addresses? So this is what becomes critical to security, is how this process actually happens. So this is what people have been talking about, the three-way handshake. So I have a little idea of what happens. What does that mean? Do we have like a ring with three arms just like shaking hands? It seems like a misnomer. We only actually have two hosts. So how do we have a three-way handshake? So how does it work? Does anyone want to give us an overview? We send a SIN, then an AC, and then a SIN. Yeah, so basically it means three-way is in three communication, right? So we send a SIN that says, hey, I want to talk to you on this port. They send a SIN AC back, and then we send an acknowledgement back, and after that three steps, then that virtual circuit is connected and we actually have a way to communicate between the two hosts. But until that, we don't actually have anything. But from a security perspective, we can't just think at a high level, right? Because we want to know how it's actually built so that we can see how to mess with it and how to change it for malicious purposes. So the idea is a client wants to make a connection to a specific machine on a specific port, and so it's going to send a SIN flag, and the SIN, the sequence number is going to be a random, so it's a 32-bit number, right? It's a sequence, it's a whole word and a header. It's going to be some random initial sequence number. We'll call it S underscore C. So if the server wants to actually accept this connection, it's going to send back a SIN AC packet, and it's going to create its own random sequence number, because we have two ways of communication, right? So this allows basically, so they both kind of choose some random offset of 32, and it's both saying, okay, this is going to be zero for us. So that way when I send you additional sequence numbers above that, you know where that data goes in relation to this initial sequence number, right? Both sides have to do this because data has to be able to go both ways. So it has an initial random sequence number, and then in the acknowledgement field, right, what was the acknowledgement field before? It's the data, the sequence number that the other side is expecting, right? So it's received data up all the way to that point. So from this perspective, from the server's perspective, what's the next bit of data that it's expecting from? Is that the acknowledgement factor? The same SC plus one, Y plus one? It's always just confused me. I think it wasn't for like multiple years until I finally had a good answer for Y, it does plus one. So one explanation is what's exactly what I told you, right? I told you the acknowledgement number is acknowledging the next packet that you're expecting, right? So I told you give you a SIN, and I told you the sequence number is 10, so then you would tell me, of course, I'm expecting 11, right, because that's what the acknowledgement number means. But the protocol doesn't have to be designed like that, right? It could be designed as instead of the packet I'm expecting, just tell me the byte of the last thing that you got, right? So Y plus one. Deuce the number of transmissions and messages. I don't know, you have to prove to me that it actually would reduce it, right? I don't know, I can't show that. Maybe it does. Probably some networking people in here, right? So what's the size of the acknowledgement numbers? The 32 bits and the size of the sequence numbers are also 32 bits, right? How do we represent, how do we interpret those bits into a number, right? So we have to interpret this as a 32 bit number, right? So what are the different, so if we just have a series of bytes or sequence of bits, how do we interpret that as a number? Is there only one way to do that? How many different ways? There's probably a million different ways. But there's like two main ways, right? Little Indian and big Indian, right? And that actually doesn't change the bit order, it changes the order of the bytes. So basically it says, okay, I have, how many bytes there? Is it? Four bytes? Yeah, so I have four bytes. Is the least significant byte on the left or is the least significant byte on the right? Because I can interpret it either way. So what this actually does is it proves, so I believe most hosts, like x86 is little Indian, but network on the network, it's actually big Indian. So this shows that the other machine and you are speaking the same language before you make a connection, right? That the other side actually correctly interprets your number that you sent and gave you back that number plus one, right? Because if they tried to send you that number, if they tried to interpret the number, add one to it but had the bytes in the other order, you're gonna get a completely different number back, right? So this actually is kind of like a cool, it's almost like a built-in debugging check into the protocol and that's specifically why they did this. So if you just echo it back without doing any computation, well, anybody can do that, right? You just take whatever you're given and throw it in the acknowledgement section. But this proves that you can interpret it so I don't try talking to somebody who doesn't know how to speak the network language. Okay, so the client gets back to SINAC, right? Come back to the client. So what's it going to send back to the server? So it's gonna send back an act and say, yes, I got that. So what's the sequence number of that going to be? S, the sequence number of the client. S C plus one. S C plus one, right? Yeah, it's the client's sequence number and the acknowledgement number is going to be S S plus one. Yeah, exactly, right? And after we get this, now we're in business and we can send data back as long as we increment the sequence numbers correctly and the acknowledgement numbers correctly. So we have really gone into the security implications here. But what kind of choices are made here? See, like, so after you decide that you want to talk to somebody, what kind of choices are being made? Yeah, the initial, like S C and S S, right? Or both. So I just said random. It's kind of a weird thing to put in a standard, right? Now you're gonna come up with a random number. You got somebody typing away furiously, right? So how do we choose this initial sequence number? And so the TCB standard tried to specify that the number should be changed every four microseconds. It should change. Initial systems use a different way of, I don't know, trying to increment it every once in a while and every time you got a connection, you change it too. We'll see in a bit how this actually can affect the security of this entire operation. But part of the problem is that nobody really specifies how you do it, right? How do you get this random sequence number? It's like, hi, I can just increment a number, right? That should be fine. So let's look at this three-way handshake from the client to the server. So it's the first packet when the client wants to talk to the server. Zin, yes. So you can see here that we have, so what are these two at the top? Port, yeah, so we're saying two port, port 22 from port 13987. Why 13987? Why don't I send it from port 22? Yeah, right? So it actually is kind of funny, right? So we want to talk to port 22, right? But because of that four-tuffle, right? Source, source port, destination IP, destination port, destination IP, right? Because of that port in there from the source, we're gonna make sure that that source is essentially kind of unique, but it's not something that somebody incoming could talk to. So usually we just choose a random high-numbered port, and that's kind of how it works. But it looks a little weird because when you look at this, you're like, well, of course port 22, I say of course, is it SSH? I wanna say it's SSH, right? SSH, okay. It's SSH, right? It's coming from some random port. So when you look at it and you see that on the next one we're gonna send random traffic back to a random port. The only reason why it's important is this four-tuffle of client, source, port, server, server, source port, that's what's important. So if we make another connection, a concurrent connection to server, to that same port 22, right? We know that it's different if the source port is different. If the source port's the same, then it's, everybody considers that to be the same connection and the same traffic. Okay, so we send that, we set the sequence, so we just generate a random 6574. We set the SIN flag to one, which means that this is a SIN packet. The server gets this packet, right? And of course we're missing all of those crazy hops in the middle and the packets transfer out of our subnet into the other network and hops on the gateway, all that stuff. But let's say that it gets there, right? So then what does the server send back? A SIN and an ACK, so SIN's gonna be one, ACK's gonna be one, what's it gonna put in the sequence number and the acknowledgment numbers? Sequence is gonna be a new degenerative number. Sequence is gonna be what? Sequence is gonna be a new degenerative number. Yeah, so a newly generated random number, what's the ACK gonna be? Yeah, 6575, right? That number plus one. And the port numbers are switched, right? Then the client gets this, so the client responds, right? And says, okay, ACK, so SIN, SIN ACK, ACK. And it says, okay, so the same port numbers, right? If we change the port numbers, none of this would work. We use the sequence number, 6575, which was our original sequence number plus one, and then we acknowledge the server's sequence number by adding one to it, right? And now we've established a connection. So now if any side wants to send data, they send the sequence number, they send some data, and the other side acknowledges that whatever the previous sequence number was, plus the data, at least. So we can actually see this in a TCP dump trace, right? So one of these, yeah, our old friend, Arc. Yeah, right, Arc. We first, so I guess these two machines are on the same subnet, yeah, which makes sense. 192.168.10.192.168.20, we're trying to SSH there. So we set a SIN packet, and we have this sequence number, 101.54, 101.5043, and so dot 20 is going to do a SIN, so it's the SIN flag and the ACK, right? So we have a SIN ACK packet, back from 20 at port 22 to 10 at port 1026, and so it's acknowledging, we can see here, it's acknowledging this plus one, right, whatever that random thing is, plus one, and it's giving us a new sequence number. Right, so the client has to respond back with an ACK and acknowledge that sequence, that, yeah, this sequence number that was sent. 40565779, yeah, I don't know how to say it, this one. Okay, yeah. I have two questions. One is that you said, oh, okay. Oh, okay, so the first question is you said, we needed a four tuple to uniquely identify a connection, but then here we see that only the port numbers are sufficient to state, so. The port, well, this is because we're only looking at this specific trace, right, but for each host on each side, right, when they get a TCP packet that comes in, right, they need to map it to what connection, because you're having multiple TCP connections all the time. So the way each host decides is it looks at that four tuple to know what connection that is. The same way when you're manually looking at it on the network. At the same time, if another IP sends, I mean another host sends a packet to this particular port then. Yeah, so we have two people SSH-ing into this machine at the same time from different hosts, right, or even the same host SSH-ing concurrently to this machine. You'll see the same SIN-SINAC ACK, but with different client port numbers or IP if they're different. You'll probably see different client IP and client ports, so that's the right time. Yes, question two. Yeah, question two was that what happens if the destination actually uses the other Indian format apart from the one I use and send a plus one, and I get a different number here? I believe in this, when it gets that, dot 10 would send a reset, and it should be like, we should never talk to each other ever again. Okay. And you can get somewhere in error. That'd be interesting to look at what actually happens. That'd be cool. Okay, so once we've established, yeah, please. What would happen if a 32-bit number will flow through? Ah, so, yeah, actually that's a good point, right? So the sequence and acknowledgement numbers, right, are 32-bit numbers, so if we add one to it, right, and we're at the end, it could go over, or if our data's large, we'll go over. It's totally fine. They actually specify that if you modular arithmetic. So it's, you're basically, so yeah, you gotta think of, the sequence numbers are like, somewhere, it starts somewhere in the two to the 32-bit range, and they, during the connection, they increase, and if they go over, you just keep going. The window size kind of makes sure that it's never gonna be bigger such that you have packets outstanding that you don't know where they go. Because the window size specifies from the current thing, how much farther could I send it once? So that makes sure that you can't, you don't have to worry about that. Maybe I should put out an application on the ECP layer with the IP, is it? Ah, you have to know, yeah. So you either, I mean, DNS is the real answer, right? So you actually, like the way it actually works, right, you type in Google.com in your browser, it makes a DNS request, which is a UDP request. So it builds in and has to know, so it has to kind of bootstrap, right, to know what DNS server to contact. So it's either hard-coded or DHCP specifies what DNS server to use. So in the TCP packet, let's say that the source I send the TCP packet to the server. So by the time the server receives the packet, it just has the TCP data with it, which does that have the IP also, like which source IP has sent to me this. So, from this. Inside TCP data, there will be the IP. You can, yeah, because, so you get a socket from the operating system, right? When you get a connection. So basically the OS keeps track of that socket number and that portable, right? So when packets come in, it knows what socket those data is for based on that portable. Then it knows from that mapping, when you read from that socket, it knows what data to give you. And then there's also ways to query the socket to say who's on this IP address, right? Who's, I think you can get. You can see it's like remote address or something like that. There's a way to do it. But yeah, thinking about if you just kept the TCP layer, you actually don't know who you're talking to. But you know that every time you write out to that socket, that you're writing to the same person that's sending you that stuff, right? Even if you don't know who it is or what IP they are, you know it's the same connection. Cool, any other questions? TCP questions? Interesting question. You're gonna try to break my brain, I don't know. Okay, so now we've established a connection. Now we wanna actually send some data, right? So if you think about it, so what's the overhead here? It's over here. Every time we wanna make a TCP connection, we have to do these three round trip packets, right? And round trip means from me, well, I guess it's not round trip, round trip would be back, but a single trip, right? So it goes from me to you, from you back to me, and then from me back to you. So you have two, three, one, okay, two, three, okay. So that could be a pretty long latency if one of your hops, if you're on the International Space Station and you're trying to talk to people on Earth. Anytime you do this, it's gotta do the three hops. Okay, so now that we've established that, now we wanna actually start sending some data. So every time you wanna send any TCP packet, basically we're gonna say, if we wanna send data, we're gonna say our, the previous acknowledgement, the previous sequence number that started that packet, right? So that's where that data should go in the screen. And then we also will send an acknowledgement number that acknowledges what the last thing that we got from the other side was, right? What that sequence, what byte we're expecting, right, from the other side. Then when the partner gets that packet, assuming it's within that window size, right, and we didn't try to send some too much data, then it will acknowledge that and it will add that to its buffer and then send us a basically an empty segment. So it's the TCP packet with zero data that says, hey, I acknowledge and the acknowledgement number will be this new packet sequence number plus one, right? It says, I got this. And so we know, so this is the case of, what's up, man? Let's look at this. So now we, the client can send it to the server, right? So we've established a connection. So I say, hey, this is sequence number 6575, 2422. I'm acknowledging that the last thing I saw was 7612 and I'm gonna send 25 bytes. So then what's the server going to send back as its acknowledgement number? 65, so it's not 76, right? 76 means that's the last byte I got, right? So the last byte we have is 6575 plus 25 bytes plus one. Right, so it'll say, yeah, is that correct? No, there's plus one. No, it should be a plus one there, yeah, you're right. It should not be plus one, it's correct. Oh, so you're talking we checked the little indian and big indian only during the handshake and not after that? No, it should be the same. But is this number plus one? Is the sequence number SC plus one? I need to look at this more carefully since I'm gonna make a deal about the plus one. Yeah. Well, we'll go with this for now. It basically adds the size of the data. The important part here is that the delta is the data. If it should be plus one, yeah. So when that's five, then we have plus one. So we have to, the SIN is a synchronization that's only ever used when we initiate the connection. We have to, so the sequence number specifies how we tell the other side where this data goes. So basically we're telling them, just like fragmentation, right? Have the offset for each of the fragments. This says, hey, at 65.75, so if you take the initial sequence number, if you take this number, subtract the initial sequence number, that's how many fights into the packet that this data goes into. And it's specifically 25 fights. Yeah. Probably the collection is already established and it's finally asking server to acknowledge 25 fights. Yes. And it's the acknowledges 6.00. Correct. Yeah, that's, so yes, that's where we are. So we've already established the connection, right? We just solved it. 6575 to 6579 is actually 25 fights. Not 6570 or 6600. Say that again. 6575 to 6599. It's 25 fights. So it's actually expecting 6600. Wait, what? No, 6575 plus 25 is 559. No, you can't overwrite the 75th fight with the new one. 6575 has one fight, then it ends up with 6600. The number of numbers between 75 and 99 is 25. Oh, including that, it's the 75th fight. Yeah. Yeah, that's what I'm talking about. 6575 must be the first fight number of the data. Yes, yes, yes, okay, that does make sense. Okay, good, that's why we have all of you. Okay, yes, that does make sense because that is where the next fight goes, right? It's the last thing I sent plus one, right? So I sent you all the way up to bite 6575 or 6574 is where I sent it up to. So now I'm gonna send all of this, this next 25 bites are gonna be bites 6575 all the way up to 6599. And then the next fight we're expecting is 6600, the other side. Try not to write the TCVIV stack. When we're sending the 25 bites, is it like getting added by the server and then send back or else like, because if we are able to add 25 bites, one would not be a difference. Like, you know, if we just do 6575 plus 25, that plus one might not be necessary because we already know how to add up to 65. We always do the plus one because we always do the next, I mean, we always do the bite that we're expecting. Okay. Confuse everything too, but what happens when you send a zero bite? Ah, let's see that. Good. Okay, so yeah, let's look at this. So we can actually respond, right? So we know we're responding. This 6600 means that we've actually received all of those 25 bites, right? So now, at this point, now the other side knows, the client knows, hey, that other side, the server got my 25 bites, right? This is how we know that that was delivered and delivered successfully. But the server can also reply with data, right? So I can reply in this case with 30 bites. So let's see if we can all do this correctly. Let me check and make sure this adds up. No, I don't think it adds up. I think we may have done it. Something in here is not consistent. It should be 42. Should be 42? Oh yeah. Okay, good, that is what we said. Consistency. All right. So it's gonna be, yeah, sequence, right? So here, but here, this is a zero bite sequence. Zero bite TCP packet, right? So we have acknowledgement as one and we're saying, hey, we've acknowledged, we've seen up to six, five, seven, six, four, two. Up to seven, six, four, one, and I'm expecting seven, six, four, two. And I have sent you basically up to six, six, six, five, nine, nine, right? That's how many bites I've sent you as what this sequence number says. And because the length is zero, so if they just kept saying, yeah, I got your packet, it's length zero, yeah, this is what I'm expecting, right? We have a silly connection, we can talk forever. So when it gets a zero bite, it doesn't respond. So that's what happens here. So we get that and then we say, okay, both sides know that everything's good. We remember exactly where we're supposed to be. So oh shoot, we went over time, all right, sorry. All right, numbers in addition. Cool, yeah, so we're gonna go into some cool attacks and stuff that happens in TCD.