Cool. You should have seen already online that the midterm CTF has been released yesterday. You got a week until Wednesday. So get started on it. Shouldn't be too crazy. I think you all, I think there's some good progress getting made on there. So that's pretty exciting. It's applying the steps and concepts that you've learned before in the class to solving some CTF style challenges. Any questions on that? Is the room extra empty because people are working on the midterm CTF rather than coming to class? It's hard for you to answer because you're actually here. What was that? Ah, who said you're not going to work on it now? Yes, I'm sure yourself in a week from now or two weeks when you're doing the networking assignment will be thankful that you didn't pay attention to the networking stuff. But you'll have to learn it eventually. So, you know, It's up to you.  All right. Cool. Oh, maybe it's St. Patrick's Day, but shouldn't them people not be here tomorrow celebrating early, I guess. Cool. All right. Well, now we get into Honestly, what's the most complicated part of networking that we're going to be learning is TCP so how TCP works. So somebody remind us what UDP added on top of IP. So ports, the only concept that UDP adds is ports and we can actually verify this by looking at the actual bytes of what's in an IP header and how do we parse those bytes. So the first two bytes are the source port the second two bytes of the destination port then a message length and a checksum, and that's it. So with this, we can now send, rather than just sending data to an IP address we're sending data to an IP address and a port. And then when they respond, they will respond back with our IP address and the port that it came from so the source port so those are flipped. And that's how they know how to respond to us. Now, what guarantees did UDP add on top of IP? Are you guaranteed when you send an IP packet that it will get there? Are you guaranteed that the other side won't get two packets? Are you guaranteed that if you send packet A, then packet B, then packet C that they'll receive it in that order of A, B and C. None of that you get literally zero guarantees UDP adds nothing on top of IP except for this port so that's how you can reason about this so if you understand that IP doesn't guarantee delivery doesn't guarantee any anything about that the packet gets there that multiple packets don't get there that a packet isn't dropped at the packets aren't changed in the network when it goes out. And so you can reason and think oh the UDP header doesn't add any information to this IP packet the only thing it adds this port so there's no way. So if an application wants those things because some applications need them they have to encode them themselves in the data of that packet. Cool. Then we get to TCP so this TCP runs I'd say. I don't have a good number I could make one up I think like 80 or 90% of the traffic on the internet is probably TCP traffic would be my guess. And so, builds on top of IP but gives us things that we really want from a networking protocol, it gives us the ability to have a connection oriented. So, rather than just sending data, like a single packet from one side to the other, we can say hey send this string, this long string the operating system, and the operating system will figure out how to send that data, and it will. TCP will. It'll be reliable to some degree and we'll talk about exactly what that means. But it's a stream delivery service so rather than thinking about things in terms of packets, even though it uses IP packets underneath the application doesn't get a packet at a time. It gets it asked for data and it will get data that's available. And TCP will. This is maybe slightly so it's not how so can easy be guaranteed that no packet is ever lost.  Yeah, we're sending a packet literally from a machine that we control out into the wireless network to a router that we don't control that has to go to switches and other networks that we don't control right there's nothing TCP can do if the device has an outage and is dropping all packets. I can't magically guarantee that your packet gets there, but what can it guarantee so when we say no loss here what do we mean. Who knows. Yeah, so we know if the other side got our packet or not and that's the key detail here is we know if they've seen our packets or not. We can know for a fact that that other side saw the data and those that that data was not lost. Right, when we send it we don't know if it's ever going to be received but as we'll see they have a way to. I guess a modern example for this would be like read receipts on text messages or whatever right so we know that the other side got our message. We can't guarantee they're going to respond again we won't. We don't control that computer we don't know what it's going to do, but we'll know that they saw our message. So no loss. Similar thing no duplication we know when we send a string of bites ABCDFG we know we will know when that other side gets it that they will only get ABCDFG, and that there won't be two days or the order won't be flipped. There's no transmission errors that everything arrives in the correct order so that we when we send a huge block of data like a file or a web page or an image or a gift or whatever. Right, when you when you send that you know that the other side received exactly those bites in exactly the right order and no bites are duplicated. Cool. It also uses the concept of the port abstraction so that's very useful for application so TCP also has this concept of ports. So you can think of it as TCP is UDP. So ports, plus all these mechanisms that you need in order to guarantee these things that these properties that we're talking about. And this is kind of the thing we're going to focus on how does it actually provide a way to do this. And essentially the key concept in terms of TCP is it allows two nodes so two IP addresses to establish a virtual circuit or a virtual connection. And the core concept here of what defines a connection is a four tuple so tuple just fancy words like four items in a list right, but it never changes it's always for the source IP, the destination IP, the source port and the destination port. So it's a two bits of information, and it's a two way connection. So when I send data from one side to the other. I'm always using the same source IP destination IP source port destination port. When they send data back to me, they're sending the same thing but flipped. So, what was my source is going to be their destination, what was my destination going to be their source, and so the IPs and ports are flipped. So basically it's important that works when you're creating a packet to send because it's going to come back and define that that this tuple is unique so you can't have multiple tzb connections. If you have multiple tzb connections to one system like you're accessing Google.com through two different tabs in your browser, they will each, they'll have a diff each tzb connection one of a different four tuples so it will have. The only thing that'll be different because your IP remains the same, the destination IP remains the same, the destination port remains the same, the only thing that changes is your source port. Cool. So what we need by two streams. Yeah, so there's two circuits right one in each direction, and it just means that each side can send data to any other side at any point in this conversation. I see there's even mechanisms for one side to say alright I'm done talking to you but I'll keep list I won't send you any more data, but if you want to keep talking to me you can send me data. Other words to help with your vocabulary that you'll see when you're talking about this concept of an IP address port is often called the socket. And the two streams are called a socket pair because you have an IP port of the source IP port of the destination. And when you're doing when you get into network programming you can look up things like socket programming and those kinds of things there's libraries all offering systems of how to actually do this, because fundamentally, the nice thing about this is your application just can say hey, you can see any TCP traffic on port 80 support 80 is the standard web HTTP port. And then the operating system will handle all the mechanisms that we're talking about of accepting new connections negotiating with the other side and then when it's established a connection. It tells your application hey I got a new application I got a new connection for you. Here's ways that you can get data from it and so you can receive data you can send data on that socket. So let's take a look at the headers again just like we saw before. So what do we know for a fact is going to be different about this then udp. It's gonna be bigger. Yeah, it's a basic thing but if we just think. Okay what we know other stuff has to happen we fundamentally can't use the same header as udp. There must be some kind of additional information here to keep track of these connections in the state. So, but we will have some of the same things right we still have the port extraction which means we must have source port two bytes 16 bits destination port two bytes 16 bits. Now we'll have, and we'll see how these come into play because they're really important. We have a sequence number. And you can think of this right now as this kind of so if you think about a stream from, we've sent zero bytes up to we've sent two to the 32 bytes, the sequence number kind of tells us the data in this packet where is it in this stream of data. We also have an acknowledgement number, and this essentially is a way this is like the read receipt, where we tell the other side hey I've seen up to bite 1000 in the stream. And that way and this is, as we'll see this is how, once you get this back you know the other side has seen data that you've sent up to a certain point. You don't know anything after that but once you get this back you know for a fact they've seen your data. So these are the bytes for the header length because the unlike UDP which had a fixed size header. There's actually all kinds of crazy TCP options. Some reserve things, some flags, which will be very important we'll talk about some of the super important ones that you need to know. So what do you think of, what is this eight bits are just ones and zeros and each one and zero in that eight bits signifies a different flag. So some will be a sin some will be a sin, an act. There's a push flag I think and those are the only ones I know off the top my head. And I don't know where they are in there so don't worry about you don't have to know exactly what bit offset is each of these flags. The window we're not going to get into. So what goes with the problem of what if the other side doesn't have enough space to store all the data you're trying to send. So you think about there's a huge string we're trying to send a gigabyte file to somebody, but their computer has limited resources, they, their operating system doesn't have enough space to store a gigabyte at once. So we have this way this mechanism describing the sliding window. I will say we're going to go over literally just the basics of TCP of how to establish a connection how to send data. It is how it actually works is even more complicated than what we're going to get across because of things like the window because of things like how to deal with network congestion how to deal with that fairly so if you want to learn more about that take one of the networking courses I think you'll learn a ton in that. And then we have some, an urgent pointer which I think is almost never used multiple options, and then a padding to make sure we're on bite boundary. And we have data. So, honestly, for our purposes that you only actually need three things to get the reliability that we need you the sequence number the acknowledgement number and the flags. And that's actually it. It's kind of crazy to think about that we can get all of those properties that we can get the fact that we can send that as a stream and not as packets we can. We can know if our dad if our dad is getting to the other side or not, all these really cool things just with those three things the sequence number the acknowledgement number and the flags questions on that. Let's see it in action. Oh, just like before right to reinforce the onion model of networking will have the actual so the TCP data here will be the actual application level data. The IP header at the start, that will be placed inside of the IP data of the IP diagram that will have IP header attached to it, and that at each hop along the way will have that will say put a frame data and you have the internet frame attached to the start. And again just like before right to kind of check yourself. And then what happens at each step along the way, right. This, the internet frame basically completely goes away and a new one is constructed on each hop, because it's different MAC addresses that the packet is going to. And the only thing that they change in the IP header is the time to live gets decremented, but the TCP header and TCP data remains exactly the same. What's the purpose of this TCP encapsulation. Again phrase it as the purpose is goes back to our diagram of the networking let me. We look here. Yeah. So the purpose is that if you are writing late layer software right so you're writing a switch or something like that, you only ever have to worry about or think about the Ethernet header. And maybe the IP with that time to live, but you have to do very little you only need to look at the outside there, and it's totally okay so if somebody comes up with a new application layer. I don't know, zcp or whatever you want to call it right some new transport layer saying you don't have to change anything else, you just change that. And then everything else all the switches will work 100% the same somewhere with the IP layer. We could change we actually did change right we moved from well we've trying to move from IPv4 to IPv6. And this can happen because you don't have to change TCP or UDP. And you also don't have to change the link layer except for our stuff that has to translate between the two. So it's a nice. It's a nice way of thinking about designing different protocols. Actually I don't know if I'll get into this but an insane thing actually happened in networking so. There used to be a predecessor to TCP called the NCP. I think it's network control protocol and TCP is transmission control protocol I believe. Do I even have that on the slides yeah transmission control protocol. So, before TCP, there was a protocol called NCP. And it didn't have any of the congestion control issues, essentially at a high level what TCP does is when it's sending packets if it detects that something got dropped. It actually significantly reduces the rate at which it sends packets. And the problem is, if you don't do that and you've overloaded something and nobody stops transmitting, you'll keep losing packets and everyone has a massive problem. But if you significantly like it's called the exponential delay if you exponentially slow your sending rate you can let the network recover, and kind of everybody does that as soon as they detect a problem. And so it's actually a huge problem. And I believe I don't have the exact date. I think it was sometime in the 80s. They kind of had this proposal said hey NCP is not working we need to move to TCP. So they decided on one day, which was called the flag day if you look this up on Wikipedia can look up like the TCP flag day, where they literally everyone that was running a system on the internet. And on that day, shut down their system, updated the software to support TCP, and then turned it back on the next day. So like they literally had to reboot the internet in order to get something like this working. And so that showed you the difficulty of upgrading and changing these things, because I believe it wasn't a backwards compatible change so now if you think about, do you think you could do that in the internet today. Like, nope, sorry the internet's down for today, like needs maintenance like you literally can't do anything. So, so now all the changes are basically have to be backwards compatible. All right, let's go to. Okay, so TCP. So, what are these sequence and acknowledgement numbers for. Let's go through an example. Okay, it's actually easier to start here. You all cannot see my screen. I've prepared for this eventuality. All right. And how do I get you to go away. Oh, thank you software. I'd elaborate. There we go. All right. Thanks. Okay. TZV connection. So, think about this conceptually first before we even start. How do you get the property that some that you know that somebody else knows something. You just magically know it. If I send data to you. I know that you've received that data. Yeah, you have to tell me back, right? I need to, I need a response from you that says, Hey, I got, I got your data. We're all good. At that point that I know for certain that you have it. But if I don't get that reply, I can't just send that a magically hope that that you're there. We can do a TCP unlike UDP we're going to send a packet. And if that server is up or not we don't really care there maybe they will maybe reply to us maybe not. We have to before we start talking TCP, we don't know that that system is actually up and wants to talk to us. So think conceptually so from my perspective on the client. I'm going to make a connection to Google.com. So actually, we know what will happen is will make a UDP request to DNS to say what's the IP address of Google.com it'll tell us something let's say it's <IP_ADDRESS>. So I now want to send a TCP packet to port 80 because I know that's the HTTP port of the IP address <IP_ADDRESS>. I know my IP address. I need to ask hey, do you have anything running on port <IP_ADDRESS> or sorry IP address <IP_ADDRESS>.8 port 80. So I have to send. So conceptually I have to send a packet to Google to ask them that because I'm trying to initiate the connection. I'm the client. They're the server. So I say hey, do you have anything running there. Do you have anything running on port 80. Do they have a website. They run HTTP. Yes, you go to their websites all the time. They even though they're almost exclusively on HTTPS they still have something running on port 80 to tell you to go check out the HTTPS version but regardless, they will then get that message and say oh great somebody wants to send me the operating system will check is something listening on port 80 for TCP. If not, it either drops it or sends a response saying hey go away nothing's here. 443 is the is HTTPS port not necessarily SSL. Okay, so. So Google gets it they say okay great I have something running on port 80. So now Google needs to reply back that says okay, I got it. I am listening, and I want to start a conversation so Google replies back to us. We get that reply from Google. So now what do we know at this point that Google is ready that Google is listening there's something listening on port 80 on that IP address, and that it wants to talk to us. What does Google know. Google knows it wants to talk to us do they know if we turn off our computer at that point. So that packet was lost somewhere right fundamentally know this is why it requires this is a way you can reason about how many packets are required to start up a TCP connection you need three. I'm going to say hey, are you listening. They say yes I am and you go yes I got your yes I am. And then at that point, once both sides have got all those that that information, you know that the other side is up available and good to go. And how that works is with flags. So we need a TCP flag in the header that says, hey, I would like to start a conversation. So the Oh, it's called the sin flag stands for synchronize like hey let's synchronize our state or our connection or something like that. I actually never really referred to it ever by the full name except when I'm doing this in class and then I forget until the next time I teach this so you can just call it a sin the sin flag. You can think the other way this is referred to is a TCP packet with the sin flag set is just called a sin packet. Client server. So at the start the client will send a send TCP packet with the sin flag. So if you look at the header, you can see that that bite of the flags that represents the sin flag is set to one, and I believe all the other flags are set to zero. So we can do this a little bit more so we can send send TCP packet. Let's do my client here will be 10. And the server here will be a, which is kind of wrong because that's their DNS IP address but it's really easy to remember so, so send the CCP packet so we can actually go through layer by layer. Right so at the TCP layer. So what's the source IP at the TCP layer. Oh, it's a trick question. There's no IP addresses at the TCP layer. Sorry.  Okay, so the only things that are at the in the TCP layer that we care about is the source port. The operating system will actually generate a random source port. So we'll call it 4242 destination for what's the port we're trying to talk to was it for 80. And at this point all we need is flags. So the only flag set is the sin flag. And then we can look at the IP layer. So source IP is 19216801. The destination IP is 888888. I don't think there's any more information we need there. And then we can further kind of keep going and say what's the ethernet frame but we don't need to go through that every single hop because you understand what what is happening from here. Cool. So this package gets sent. The server receives the packet. The server will first check hey, do I have anything listening there if not tell you to go away. The server gets this. They respond. So what's the So the TCP responds with TCP. So the TCP layer source port, what will the source port be for 80. How do you know that. So this is a flip the destination port that we're sending to when the other side responds to us their destination will be their source. So destination port will be 4242 flags. So this is what we'll go to in a second we'll come back to this. This is actually just part of the protocol nothing that you can reason about here. So we have that and the source IP will be 888 destination IP IP will be 192168 0.1. All right, so now this is part of the protocol so part of and this is there's a these three packets here are very important to burn into your brain. So this is a very, very, very standard thing of networking. It's very, it's the way to remember exactly what flags are set. So the first flag is the sin by the just a sin packet from the client to the server, then the server responds with the sin and an act flag. So it stands for acknowledgement and it means that the acknowledgement number field is valid we'll get to exactly what that's doing here in a second. But for now, all you need to know is the flags. So you send a sin, the server responds back with a sin act. And then can we respond back with a sin. No, we kind of shouldn't because this is a special thing that indicates hey I want to start a connection. And the server will say hey go away we're already in the middle of starting a conversation so it'll restart the whole thing because it's like I don't like, basically the way you do networking protocols is anytime anything is is weird that you don't expect you say all right I don't know what you're talking about let's start from scratch, like I don't want to talk to you anymore. If you want to talk to me you start with the sin at the beginning, and then we'll go. And then the server responds with TCP packet. So then we'll respond back. Again, we'll have source port 4242 destination port. Maybe flags. So I won't have the sin flag but I will have an acknowledged flag. So this is how you can source port source IP 112 16601 destination IP. So this is the sin snack. These are the three packets. If you have these three packets you have an established connection at this point. And now and it's this is kind of the same thing, only at this point can you actually start sending data. Right, so you can't even talk to the other side or begin talking to the other side, until you've gone to the sin. The sin act questions on the high level process. So that's at least how we can kind of get the process started so get the, the connection going the what we need to do is, we need to be able to use the sequence and acknowledgement numbers in order to tell the other side hey. What's what bite are you going to start sending data from or so. So we need a way in order to we need to bootstrap something so that we each side can know what data they've been sending and what data the other side has received. So anything to do with the end in encryption on our messages now. The way encrypted messaging has to get set up is much more complicated than this. You have like TLS or SSL has a whole additionally have to first establish a TC key connection and that protocol has to establish encryption they have to negotiate on what ciphers and protocols and everything they're going to use, and then they can actually engage keys and then they can actually communicate it's kind of crazy but so there's way more in depth in here for all these things but the basics here are TCP, but it all has to start here. Okay, so we know we need to send we need to send an act. So the other thing. So the other thing is we need to establish the sequence and acknowledgement numbers. So you could think of this sequence number starting at zero. Technically and we'll see why each side actually generates a random 32 bit value well roughly random 32 bit value for the sequence number. And you can think of that as just starting and everything else is an offset right so you started that bite. And then every time you send you're saying I've seen up until this point but it's kind of arbitrary so right now we'll just call it sequence client so you can think of it as starting at zero doesn't matter. The client versus and the acknowledgement. You'll see what I mean when I talk about pseudo random I'm actually referring more toward to the different implementations, and actually the crux of the security here which I'll hint at depends on the randomness of the sequence number. So, I'm making a connection. And again, the only time the acknowledgement number is valid is valid is when there's an act flag set. It doesn't have a packet like a sim packet that doesn't have the acknowledgement flag set. It means that I don't care about what the value is in that header so let's go back and look at the packet. Yeah, so we can see we've looked at here. The source port destination port sequence number and acknowledgement numbers they're both 32 bit four by values. Okay. Now, so we're going to expand this packet. So we have the sequence. So now, this is basically the way actually think about the same packet is sending this side sequence number. So, this is basically the client we have saying hey, I'd like to talk to you and when I talk to you and send you data. I'm going to start sending from sequence client. The server says great I want to talk. And I'm going to use sequence server to send you data right because it's a two way street they can each send data at any point in time. And then the acknowledgement is acknowledging the sequence of the client plus one. When you're acknowledging back you're saying hey, I got your message. And finally, on the last one. The number here is going to be sequence of client plus one acknowledgement is going to be sequence of server plus one. Let me double check this to verify that this is correct and 90% sure. I don't know how do I move. Yep. Okay, it's correct. Cool. So, these plus ones may seem eventually to see how long I can lecture to empty screen. So, sequence of client plus one so the real reason why this is done and this may seem counterintuitive is, it's kind of a question of what's the unit number, you guys have taken your architecture right. So you have four bytes here, zero through a 1616 through 2424 through 32, which is the most significant bite. It depends on the end in this. Yeah, so the most significant bite. Remember there's four bites. So the most significant bite could be zero through eight, the smallest, or it could be 2024 through 32 or 31. The most significant bite to be here. So the thing about that is, if you have a number, let's say 1123344 right and hex. So, reminder of hex each of these represents a bite. So we have the bite 44 the bite 33 the bite 22 the bite 11. Right so this is the number this represents the number of whatever. Okay. So 33 is 51. Right. And so this number is 1123344, which represents the integer, whatever this is. I always got to do the, that's apparently phone number two. Cool. Okay. The question is for this number. How do we represent it in memory. Some systems will represent it exactly like this whereas other systems will flip the bytes around and will represent the number as 44332211. This actually will come up also later when we do exploitation of binaries. So this is the obscure concept. And so I believe most modern CPUs use little Indian like this where the lowest, the lowest bite in memory is the most significant is the most significant bite in the terms of the number, and basically like the CPU and it grabs stuff from memory just like flips it around and then computes on it. And I don't know I don't understand hardware but there's probably a reason why that's actually used. Network packets. So network packets in here in TCP. These are actually big Indian numbers. So the most significant bite will be 038. The point is that it's different and different machines have different end in this so I want to just reply. So what is so when I get something from the other side that has my sequence of the client plus one. So the client gets that back. It receives this packet. The client knows the sequence number of the client that it originally sent. It checks if that's one more than that. What does that tell us about the other side. It tells us if they don't understand the protocol correctly, right, because do they actually know that this sequence number is big Indian or little Indian, right, because they have to do the conversion or not depending on their own architecture. So the fact that I can detect this by the second packet, because think about what do you have to do. If you're not doing this, and you're just responding with the sequence of the client. Does that mean you can actually interpret that number. If you just respond with the sequence of the client, how would you write that code just like copy this number from this part of what I got and send it here, put it here in the reply. Right, you're just copying bytes from one place to the other you're not actually interpreting that as a number that you need to be able to increment. Because if they can't do that, then one side will say, oh, I sent you one bite and the other side says, whoa, you sent me, I don't know, whatever, two to the 24 bytes is, and you'll get very, very confused very quickly. So this is a nice clever way to determine that just in the handshake part of the TCP establishing the connection that both sides, essentially are talking the same language. Because if the client gets back anything except for the sequence of client plus one as the acknowledgement in this packet. It drops it it says alright let's stop this conversation like I don't know what you're doing, but I don't want to talk to you anymore. Something went wrong. Okay, cool. That was a quick aside into emptiness. And so now. Oh cool so these are the list of the flags so we have So that's what we talked about so since an act act is means that the acknowledgement number is valid. And as we'll see almost all packets in the connection have the acknowledgement flag set. Finn is a flag that gets set to shut down one stream. So if you want to stop talking to the other side you send a packet with the Finn packet set and that basically tells the other side this is the last packet you'll see from me data packet. Reset RST. I guess I did actually remember most of these reset is super important. It says, hey, like when something goes catastrophically wrong this is your way to say the other side. I don't know what you're doing but I'm stopping this communication so the reset basically from either side tears down that virtual circuit and says we can no longer talk anymore if you want to talk to me you got to start from the beginning and do a sin packet. Urgent. I've never seen that a push is sometimes set but I don't actually know if it's technically used so we don't need to worry about that. Okay, so what are we setting up so like we mentioned a server listening on a port gets a connection request from a client and so we know that that has a sin flag set and has a random initial sequence number of the here. The server says lower sub C. The server says, aha. I will send you a packet back. A sin and act packet with its own the servers initial random sequence number and the sequence number the client plus one is the acknowledgement number. The server receives that sends a packet with this act flag back with the sequence of the client plus one and the sequence of the server plus one is the acknowledgement. Cool. And let's look at a brief example of this so we can actually look at all the packets here so this is a packet from a client server. Okay, the way to read this diagram is you have the, we have the source port here so 1397 to port 22 port 22. I think a good fraction of you have already use. So that's the SSH port. So we've SSH into the phone 365 CC 365.io server you've used that and you've been sending packets on that port. So we're sending from 1397 to port 22. And we set our sequence number to be 6574 again just a random value doesn't really matter. And the acknowledgement again doesn't matter why doesn't the acknowledgement matter in this packet. It's not just that there's nothing to acknowledge that's definitely true though. But how does the other side know that there's definitely not anything in there. Yeah, I'm implicitly doing that but I have a way of saying if the acknowledgement number is valid or not inside every packet, or the flags, flag is zero, which means hey, don't worry about there is no acknowledgement number. That's just a helpful thing it's a it's multiple reasons right the reason is that it's the start of a packet so it has to be a certain flag with no acknowledgement flag, but also the fact that there's the acknowledgement is zero means that fundamentally that acknowledgement number is what nobody cares about. Cool. Okay, they get that packet they respond. They say, okay, so I'm sending a packet from port 22 to port 13987. And I'm setting my sequence number to be 7611. And I'm acknowledging your sequence number plus one so I'm acknowledging 6574 to 6575. We know SINAC, the SIN flag is set, the acknowledgement flag is set, and then the server, the client will respond when they get that packet. And they'll say okay great from port 13987 to port 22. My sequence number is 6575 and my acknowledgement number I'm acknowledging that I saw your sequence number of 7611 I'm adding one to it. So 7612. And I'm setting the SIN flag to zero and the acknowledgement flag to one. Yeah. Yep. So, SINAC act. Three-way handshake, TCP connection. Cool. So the question now is, how do we then send data so why does SIN become zero at the end, because SIN is only to, I mean the, the reason is because both sides have already sent their sequence numbers so they don't need to send their sequence numbers so that's where that SIN synchronized comes from is. When you send a SIN packet you're saying hey I want to talk to you and by the way, here's my sequence number. All right, let's then figure out how to send data. Okay, let's continue this conversation. Cool. So, now that we've actually established the communication, we can finally start sending data from one side to the other. So, what's the classic maybe programming thing that we want to send the test things. What would be a string that we would print out if we're doing a programming language for the first time. Yeah hello world thank you. So let's say we want to send those strings, send that string and again remember these are just bytes under the hood. So, we really cool if I knew what all this in hex was but what we're sending is<PHONE_NUMBER>011 bytes. So from the client we're going to send that. So, now what we'll do so now that the communication is established right, so you have establishment of the communication of the connection, the three way handshake sin SINAC act. Now we can start sending data so now the server. And the server technically can do this as part of their SINAC and you'll see this in examples, but for now we'll separate them. Let's say client wants to send this hello world which is 11 bytes.  So the data of the TCP packet will be 11 bytes will be the bytes hello world. So does the so think about who knows what at this stage so the client does the client know that they're trying to send 11 bytes to the server. Yeah, they initiated this application as the operating system great I'd like to send the string the bytes hello space world to the other side. If it doesn't takes that it says great okay I'm going to send an IP packet. I'm going to send a packet to 42 8888 on port 80 from 192 16801 on port 4242. And I send the data hello world. Now at this point, does the client know that the server got this packet or not. It's just sent it right. What has to happen fundamentally for the server for the client to know that the server got it. We need some kind of acknowledgement back right from that other side we need the other side to tell us, hey, I saw that data. So. So the next thing that hopefully happens if everything's working right in the world. So the server receives packet this packet that just got sense. So the server then responds so the server will send back a TCP packet. The source port is 80 destination port is 4242 flags will it set the sin flag. Just acknowledgement rates and is only the first two packets of the connection. So the sequence number now. So now what's what's the sequence number that the server is going to send as a server sent a data to the client. Yeah, this, it has not so it will just say hey the last thing I sent you was sequence of server plus one is my sequence number. So actually this is another mechanism where the other side when it gets that packet says oh great I am. So that's what I've seen as well so it knows that it's it's synchronized and what it said so it will send that. I think this will be clear as we go through here, it will then acknowledge so how much data has it seen so far from the other side 11 bytes. So it'll say all right since we started talking at the sequence number of the client plus one. And up till sequence of the client number plus one plus 11 bites. That's what I've seen so far. That's unfortunate, plus 11. And we don't have anything to send to the client. Well let's say we do what's our response to hello world, what do you want to say back<PHONE_NUMBER>0111212 bytes of goodbye world that's that. And this will be in a, this will be wrapped around an IP header. And this is coming from 8201. Okay. Now the client gets it. We're not even going over what happens if things are dropped or not God or whatever, we don't care we'll deal with that in a second. So the server receives that packet. And now it has to respond and acknowledge right because again, the server send us data, and the server won't know that we got that data until we respond to, right. So, but now at this point we got this packet back from the server. What do we know about the server state and view of the world. So once we get this packet back, what do we know that the server has seen. We know it's seen hello world we know it's seen because of this acknowledgement number it's seen 11 bytes that we've sent, and we can check and know how many bytes we've sent. We said great, we've sent the 11 bytes. Now we can actually as the operating system we can tell the application. I sent that data, the other side received it. Right, which is great when you're programming because then you know when you're sending data to another remote system you know that they received that data. But because the other side sent us data it means that we need to acknowledge so let's say we don't have any data to send right now. So we'll send a packet source port 4242 destination port 80 flags act. Now the sequence number here so what's the sequence number that that we have as the client. What's our sequence number. Yeah, let's do plus one plus 11 so that we can see that the plus one was part of the initial connection. And then we'll see that that way we know we did that plus the 11 that we've already sent. Why don't we increment this anymore. Yeah the initial increment is just to establish those baselines going forward. And now once the connections established we only increment that when we've actually sent the other side that. We're acknowledging what have we seen on the other side is 12 so I think unless I counted wrong, and we'll send empty data so we don't need to send anything source IP one and two one six eight zero one. Cool, the server gets this and now what does the server know. Yeah the client sent receive those 12 bytes so then the server can then tell its application, I sent those bytes like you are good, you don't need to worry. Maybe depending on that it will respond and it will just go back and forth like this. Each side, every time anyone sends data the other side will respond and acknowledge and potentially send new data which the other side then has to respond to and acknowledge. Do you have to acknowledge an empty data packet like this. Because this is just acknowledging that the client saw our risk or the data that we're sending. So right now both states, everybody knows exactly what everyone else has seen. So, yeah, so basically, which is this window. So, following the other example, right so the client sending a packet from 13987 to port 22 and saying. Yeah, so sending 25 bytes so it sequence number is 6575 the acknowledgement number is 7612 the act is one. So when the server gets this it goes Oh data great I need to reply. So what is the server going to acknowledge what's the acknowledgement number going to be, you can say the formula you don't do the math. Yeah it should be 6600 so it should be 6575 plus 25. So who can answer because, anyways, I guess I can see but the presenter, the zoom thing is blocking the screen anyways. So the server will reply and say okay from port 22 to port 3913987. I'm my sequence number is 7612. So what this is saying is what I've sent to you so far is 7612, which we know the client also knows because it acknowledged 7612 so we know we're all synced up there. I'm acknowledging hey I've seen up till bite 6600 and I'm acknowledging and also I'm sending 30 bytes. So what will the client then send us its acknowledgement number 7642. And what will it set as it, it's sequence number. Yeah, 66600 so it should be from 1397 to port 22 sequence number 6600 acknowledgement number 67642. And so at this point then we've exchanged data. So now both sides know that the data was sent so let's go through some scenarios to see why this is useful. So let's say that. The packet is dropped. So the hello world packet never got sent. This is super annoying. Not you all the situation. All right, how do I. So let's say like X this out. There is format. No, we're just gonna delete it. The other nice thing that we didn't mention is, we can actually send multiple packets. So we can use this to send multiple packets. So I can send hello world, and then I can send. How are you. And so I'm sending two packets without getting a reply that's perfectly fine I don't need to wait. That's part of the DCP window and everything of how much data can I actually send at once. So for our purposes here. We can see that. Okay, but let's think about this so I sent hello. Hello space W or RLD. So what should be my sequence number here, where does this data of how space R space you question mark startup. And then right because it's after. So I first sent 11 bytes, and then after that starting at 11 is the next bite. So the next data that I want to send. So I'm going to send both of these packets at once. Let's say this never makes it there. So it's a bad packet. It gets dropped but the second one makes it there right. It was just like we said does IP guarantee that if I send two packets one after the other they will get there in that order. But either of them will be delivered or they won't be duplicated. Right, these are all instances the same thing. So the server gets this. How should I acknowledge this packet. What is me as the server what do I think their sequence number should be should just be client plus one. So I respond. So I received this packet. Let's say, just to be clear, Internet drops packet one. So we'll actually respond back and say, and I let's say I'm not sending any data, but we'll respond back we get this packet. And actually technically what happens is we'll probably store that data in a buffer. So we'll probably have a buffer, and we'll say all right offset 11 put those bites in there. But I know I can't acknowledge that I've seen those bites yet because I don't know what happened I don't know what comes before that. And that's when I said tag like networking is confused is complicated because there's all these kind of details of how it actually works, how you make it fast how you make it perform well. But ignoring that for now, what we reply back is hey, the last thing I saw from you was sequence of client plus one so we go back to this. The last thing I saw was sequence of client plus one. Actually, all the way back. Yeah, only back here that's what I expect the next bite to be. And so now the client receives that packet. So what does the client then know at this point, if it. Yeah actually doesn't know if the first one made it or the second one didn't make it like it just knows that the other side hasn't seen any of the data that it was trying to send. So that those first two packets, it just knows, huh, the server so I'm here, or I think I've sent. We didn't do the size of this one but I think I've sent 11 plus. How are you was that 3369 1011 12. So 11 plus 12 data that's how much I've sent but the server's telling me I haven't sent any of that. So shoot maybe both of them got lost maybe something happened. So we'll actually resend those packets. And maybe it didn't get there yet, because so it will then basically send this data again. And then let's say it gets, it gets both of them let's say so the internet. Technically it will respond to each one. But let's say, you know, so now what am I acknowledging that I've seen it once I've received both those packets. Yeah, I'm acknowledging one plus 11 for the first one plus 12. And then as soon as the client gets that it goes great. What if the client never gets this acknowledgement packet gets dropped. This is the crazy thing you have to reason about when you're talking about networks, every packet in the communication to think what if that gets dropped. Yeah, it will. The client didn't know that the other side got it. And so there's usually a retransmission time out. So after a certain amount of time, the client will send that data to the server again. So we would send those two packets again. And then finally when that message came back that like no no I'm acknowledging I've got I've seen it all trust me like I've got it. So at that point, then now they're up to 23. So sequence of client plus one plus 23. They know that we're both there we've all seen it great and now we can move forward. And this is how it kind of gets back on track so yeah so and this is actually what you need to know to be dangerous as well. I guess see next week. Let's open to get to that today but but you know how TCP works is a very important thing. And shutting down the connection is very simple. Either one can say hey I'm done talking so they will send a to terminate its side of the connection and say hey I want to stop talking. I'm going to send a thin packet. The other one will acknowledge right we'll send an act packet back because again that's the same thing. How do I know that the other side got my request to stop talking. Right so you send a request to stop talking they need to acknowledge that. And then at that point I know that they know that I don't I'm not going to send them any information. And from that point a will never send any data to be. It'll just acknowledge data sent by B so when B sends it any additional data it will have to acknowledge that back.  And then send some fins to finish everything out. Okay yeah so that so here in this example the client to finish our example here 13987 will send a packet to port 22 sequence number 6936983. So they've been talking for a while I think we can see from the sequence numbers here. So acknowledging that they've seen 8777 setting the sin flag, the server will acknowledge that and said great the last thing I saw from you was 6984. I don't know if that's a mistake or not. I'll have to look that up I don't know if the final acknowledgement number is added one to. I guess that would make sense because you're acknowledging that you've actually seen that fin packet since they're not sending you any data. I guess that would be my, my thought there. Cool okay and then we're sending 30 bytes from the server to the client, the client and then the server can send a fin packet to say alright so I've sent 8807. So that's the previous sequence number plus 30. And then I'm done talking. So, I don't need to talk anymore.  So there's an additional plus one at the end. And at this point it's done poor down. No connections. Let's take this opportunity to look at some stuff. You can't see that. Since we were talking about it let's see. So options I'm using here on the dash and is to not by default TCP dump and other tools will try to when they see an IP address will try to do a reverse DNS name look up, and that can slow things down significantly so and just says show me the numbers don't try to translate anything into the names. The I option says the. What network interface to use so you can use is config or anything like that to figure out what your interfaces are already know my wireless one is this, I can set an option of I want for 80 reports, let's report 22. And what happens when I SSH into hacker. Yeah, so we can see a ton of stuff happens here. All right. So, we can look at this. So this is my current IP address is 1015153 3083. And this is the port says kind of the weird TCP dump way output of showing that so this is the IP address and then dot port. So from source port 54511 to 1356 97136 port 22. And then we can ask we can say dig. So dig is the DNS resolving so this will make a DNS query. And this says okay Pone CS 365.io is located this IP address so we can see that it's the correct IP address here. Port 22, setting the sin flag, my sequence number and let me change this a bit to make it more legible. My sequence number is this insane big number. A bunch of windows options all kinds of stuff that is happening the operating systems like optimizing these things for data transmission and reducing data loss is really important. So we see the packet come back from 1356 97136 port 22 to 10153 3083 port 54511 sin and the dot here is the act flag. And we can see the other side sending us its sequence number and we know that this should be 80 at the end because it should be the acknowledgement should be plus one. So the act here is correct. It's 80.  So that's the flag there the act, and we're acknowledging and at this point, because we've got the two random values here so we've started with random sequence numbers. And after that TCP dump normalizes them based on there so rather than do it showing like the initial sequence number plus one it just showed you the one, and then the two and then that way, it's a lot easier to read so I can see that here I'm acknowledging and I'm sending a length zero packet, the other side then sends the P packet here is the push. The remote server sends a push of 21 bytes, and, and then we acknowledge we've seen up to 22. Oh and the sequence number here it's doing one colon 22 so it's interpreting the length and saying even though it's technically not in the packet itself to help you it's saying this data is from bite one to bite 22. This is 21 it's 21 length 21. So we're acknowledging we've seen up to 22, and we're acting, and then we push data. So then we're pushing and sending data from. Oh I got the from and source back. Next up. This is us. Sorry. This is us we are sending 21 bites, they acknowledge that they've seen those, and then they're sending us 41 bites so in response to whatever those bites were that we sent we can actually, if we do the full. I think it's dash x option will show us the so x will actually show us the raw bites of these packets. And we can see that I don't have to worry about showing you all this data, you can't like break my stuff because this, the whole point of this encryption is that I can SSH into the server, even if you're watching my communication you can't break into it. But you can actually see that a lot of stuff is transmitted so this is what I was saying about all the different negotiations of ciphers and how they're doing everything this is all this stuff means like, you know you learned about some of the stuff Divvy helmet shot 256 right all these different hash and crypto stuff. It's telling us that it's SSH open SSH blah blah blah blah. Anyways, so lots of stuff going on until it finally establishes the connection. Actually, let's let's do that real quick. Doing a lot of stuff started challenge right fine. So now okay so now you can see we're at a state here where no packets are being sent. Every time I type in a letter L s space dash L a enter right packets are getting sent so this is actually how SSH works under the hood every time you type something. It's sending data to the server and then getting the response back and updating your terminal with what it got sent so kind of cool and I can show you all this because it's all encrypted gibberish. Which is good. Alright, that's it.