 Alright, so on Thursday, we talked about UDP. So what was the entire point of UDP? Why do we need UDP? We already have nice ways to be able to send a packet of data from one IP address to another IP address. Once the packet gets here, so when the IP packet gets there, it needs to know what application it needs to go to. So how does UDP solve that problem? It specifies which gateway to go to, more specifically where the packet should go. Yeah, so it's just a number, right? So the important thing is a port is not anything special or specific. It's just a number. It says 16-bit number that specifies the source port of the application as such that it sends it, and the destination port of where this packet should go. So then what in this UDP packet specifies that the IP address that's sending this packet is actually the IP address that is able to send this packet? So where's the authorization and the authentication about this UDP packet? It doesn't have it. It doesn't have it? It seems bad. Is that bad? Yes, that's bad. That's definitely bad. I mean, in a sense of security, right? So we have UDP basically provides nothing on top of IP, right? It is connectionless, unreliable, best effort. It adds the port abstraction, but it doesn't provide us with anything more, really. Which means that all of the attacks that we looked at with IP still work on UDP. So specifically here IP spoofing. So if we're an attacker and we want to send a UDP packet to the server pretending to be the client, how would we do that? So create an IP packet with the source IP as the trusted client. What do we have to destination IP? The server, and then what about the UDP player? Whatever we want to send the UDP packet. So it would be the source port of the program that's listening on the server that we want to pretend to be the client form. And so we send now this spoofed UDP request. And again, the important thing to remember is when the server is in this packet, it hasn't know where it came from. What does it use to try to figure out where it came from? The source IP. The source IP, right? So when it replies to this, what's that packet going to look like? The destination will be the original source. The destination will be what? So the destination IP, the attacker? No. What's it going to mean? The trusted client. And the source IP? The server. The server, right? So is the attacker going to see that packet? Not in his current setup, right? Possibly, but we know, and again this is where, why we looked at exactly how packets travel and how E-directors is directly delivering those. When the server sends this, maybe you reply back. It goes through some hops and it keeps going until it gets back to the trusted client. So an important thing to check ourselves is does the attacker need to be either on a local network of this trusted client or on the server to send a spoofed UDP packet? To send. No. No. Right? Why? Yeah, so we looked at all those steps, right? So this attacker here is talking to some switch that's connected to another switch that's connected to another switch, right? Or rather those are the packets that are going to go on between there. It actually seems kind of crazy when you think about it. So here we have this, you can see this, right? So we have a switch here, right? So this attacker is now sending a packet to its gateway, right? Spoofing a source ID to be this client. Why doesn't this router drop that? Does the router have enough information to drop that packet? No. Seems fine. No, why not? Because for all it knows, it can just be being passed on. It can just be like being, like for all it does, it came from the client and then went through a couple different hops and then got to this one. So one way to look at it would be, well it doesn't really know, right? Because maybe the client is connected here somehow with the attacker and that's where it's going through. If this was, let's say, your ISP, so this is you at your house as an attacker. This is your ISP's router. Does the ISP know what IP address you got? Yeah, they gave you that IP address, right? The attacker knows, the ISP knows exactly what your IP address is. Could they drop that packet? It makes sense, right? Why would they let you? They know exactly what your IP address is. Why would they let you send a packet out of that spoof? But many ISPs don't. So why? You're about to do what you want from the attacker. You're about to do, and then they have to police it and that's where it comes into view. They don't police it so much. Yeah, so maybe that puts them in the role of like trying to decide what packets are allowed or not allowed, which they may not want to do. Is it legal to drop packets or to spoof packets? Yeah, we're just adding on to the thing that's like customs. I think people would just, like if they were to do that people would think that they're also reading whatever you're sending. It's just a privacy thing. Yeah, what about like you have to add more stuff here, right? You have to do more work. You have to keep track of for all your customers what IP address range is and who they have to do. Maybe you have to actually implement new equipment or technology or whatever that could raise and fail, okay? So there's also interesting business reasons of why you wouldn't want necessarily new business. Anyway, so very few places actually do this. It's called the egress filtering. So filtering out packets coming out of your network, but the source IP is only in your IP address range. It also doesn't necessarily, so we're talking about depending at the ASU level, I mean sure I can't spoof my packets as coming from some other network, but if this was a huge network in here I could spoof my IP addresses coming from any of the other internal IPs and the packet still comes out and nobody knows that I actually sent that packet. All right, cool. Another type of attack that we can look at that has the analogy in IP is hijacking, right? So we want to, so in this case let's go briefly over DNS. The whole parts of the internet was its job. The way it names two IP addresses, right? So you go to Google.com. We already know we've looked at exactly how the internet works. Google.com is useless to the internet, right? You cannot route an IP packet to Google.com. What do you need to route an IP packet? An IP address, but you need something that maps this domain name Google.com to an IP address. I'm not connected to the internet. Let's do it now because I want to show you this briefly. Okay, so you need some way to get this information. Think about this from a security perspective. So if you were trying to go to Google.com, what's the stop you from? So you wanted to go to Google.com. You're going to use DNS to say that, okay, there's Google's IP, but what if I actually am able to trick you as an attacker to go to my IP address? What can I do then? Intercept your packet. I can intercept all the packets you sent me to Google. What else? I can send you to a different web page, what else? It doesn't seem like sending you to a different web page. I'm like, have you been here talking credentials? Yeah, maybe not even a different web page. What if I showed you exactly the Google.com login page? And then you want to roll bar at the top, says Google.com because that's what you put in. And the login page is saying, oh, you're logging my Google account. So I can use a password, can enter that I sent to me as an attacker, and now I'm still on your Google username and password. So the security here is really important of mapping domain names to IP addresses. And DNS essentially uses UDP to do DNS queries and then give you the response back. So this is, I just ask what's Google.com and I got this IP address. So whenever your machine tries to do this, it's going to then ask, we can see what server told me this, 8, 8, 8, 8, 8, 8, 8, 8, because of I think some settings I have or something. Different servers, and yes, there we go. Different IP addresses back. Is that a good thing or a bad thing? This is .4, .174, this is .6, .78. Oh, it's in the same network. How do you know? We don't know the method. Yeah. Do you like some sort of load balancing or it's made sense to have a server on a short plus? Yeah, so the other thing is that it's very complicated, right? So Google can actually decide based on where you are geolocated of what DNS, what IP address you go to. So this may be an IP address on the west coast somewhere that gets us there closer, whereas if we did a DNS request from a different location, we'll get a different thing because Google has, again, right, it's just how do you get to Google.com. Google has a bunch of servers all around the world and they can figure out where to wrap your traffic internally within their own network. Anyway, it's nice to say it's very complicated but you would not want an attacker-controlled IP address to show up. Yeah. So how is something like this distributed? There's so many network-hard domain providers. How do they all sync up? So it's like a hierarchical level. So usually when you join a network, you get an IP address and you get a DNS address, which will usually be your router. So most of your home routers run DNS on there. So basically you ask that DNS server, hey, what's Google.com? If it has a cached result, it'll return it. Otherwise, it'll ask you that it's up strange whether your ISP is DNS. What's Google.com? If they have a cached response, it'll return it and then it'll go all the way up to what's called the root DNS queries. I don't really know exactly how it works but yes, there's a lot of redundancy up at that level to get and answer DNS queries. And there's different ones for .com.net. All the way. Cool. Imagine now we have a situation where we want to pull off the attacker we just looked at. So the client is making a UDP request for, hey, a DNS query to say, hey, what is the IP address of Google.com? And we want to be able as an attacker to spoof and hijack that reply. So how do we do that? Say again? Who replies to the request when you ask for what Google's IP is? So the server replies. So here, in this case, the server's the DNS server. So the client is asking the DNS server. What's the IP address of Google.com? So Google's server, is you're asking for any server? That doesn't matter for this case, but it could be Google's server or it could be our local DNS server. Question, how would the attacker know that the client's infected with UDP requests is not going to pollute the server? Exactly. That would probably similar to what we're talking about earlier. Just spam, send the message from the DNS server we think you're asking and say, this is Google's domain. This is Google's home. This is Google's home. Just spam that over and over again from whatever we think we're going to ask and wait for them to ask and then receive it. Yes. Let's look at something real quick. Okay. What does this UDP request look like in terms of headers, not the actual data? Right? So UDP has two important fields What were they? Source AP. Source and destination ports. Yes. So source port and destination port I should just do UDP port and S port but it doesn't matter. Okay. So, man, what's the UDP port? I'm going to go crazy if I'm wrong. I know which is a a pretty great one. Let's do that. Me here. Cool. All right. This UDP request. So, one key question is how does the client know when he gets a response back? Response back has to go back to the port of the center. So, there's just like IP addresses, IP source, IP destination. When you want to reply back, you just flip both of those. So, you say that, okay, great, this is the and then there's source IP, destination IP. So, fundamentally, this was just mentioned, if we don't know this request is made, well, what's the one piece of information that we don't know about this request? So, the thing about this, do we know the destination IP against the server, right? We know the server's IP. We assume we know the source IP of the client. We don't know. What about the destination port? DNS runs on the same port. I'm going to look that up. Got to tell one of you to do it. 53. 53? Okay, great. So, yeah, so, the destination port's going to be 53. It's DNS. It needs to be that. So, we know this part. What about the source port? Who generates the source port? The application. The application. So, yeah, for the, I guess technically the OS of the client, for all extensive purposes, you can think that the client chooses a random source port in the range of ports. 65,000 possibilities to the 16th, roughly. And so, how can we create a reply without that information? Could we guess? 65, 16 minutes, a lot less than brute-forcing seven-character passwords. Oh, yes. Yeah, a lot less. But you also need to get it right. But the easiest way is, what if we get a copy of this request? Right? How do we do that as an attacker? Convince a client that you are the server? We don't necessarily have to do that. I mean, if we did, yes, we would have to get it, but what else? Convince, like, where a mandatory, like, hop. Yeah, so, if we're out of any of the local networks between each of these components, right, or each of the client or the server, and we do, for instance, an arpine mapping, right, then we can get that traffic to flow through us and we can see this UDP request. Then, we need to create a spoof UDP reply that gets there before the server's reply. And now, again, the interesting thing here is that when the client gets this UDP reply, how does it know that it came from the attacker and not the server? What's that? It doesn't. It doesn't, right? There's fundamentally nothing here for the client to be able to tell which is which. Please. When the attacker sends it, does it say it's source site UDP? Say it louder. So, when the attacker sends a UDP reply back, does it pack and say, it's source site UDP is the server? Yes. So, yeah, just like the spoofed instance here in the sense that we're hydracking this communication. We still need to spoof this UDP reply so that the, so exactly the opposite, let me not exactly the opposite, but flipping around source and destination for the ports and the IP addresses for that UDP request, which is essentially exactly what the server would have done, right? And so, here we're able to spoof this reply and now we've essentially, in the case of DNS, now we've tricked this machine into thinking that Google's IP address is somewhere else. Maybe we have need control, right? We've actually given the attacker's IP address now and now they've connected us. They think the user thinks they're going to Google.com but they're really going to us. Yeah. Wait, so, if you're an attacker, in order to get that UDP request initially, you have to be on some local network. Either the client or the server or any of the hops in between. So, you could just span, effectively span replies, finding all the different combinations or does that just come on Facebook? This is more sure to work. So, yes, I would say it's potentially unfeasible. It's also very noisy. You're generating a lot of traffic because you're not sure exactly when they're going to make a request. It's different if you could maybe induce and trick the client into making a request that you can then inject. All right. Yep. So, the client needs to be expecting your response in order to accept the request. Exactly. It's not like ARP where clients are constantly listening for ARP replies and updating their internal cache. Here, unless you make a UDP request, you're not expecting a reply. So, if you just got a DNS response out of the blue and say, well, forget this. I'm not waiting on anything. I've got nothing. No application is listening for this reply. Yeah. So, the attacker must get a copy of a packet. So, they either need to guess it magically, or get very lucky to guess it, or they get a copy of that UDP request. Yeah. I'm a little confused on the cost of the ports and the client side. It's like a simple computer. Why do you need a bunch of ports? It's like four. So, AI is saying, what's the difference between a client and a server? The client is just one that requests data and the server gives it. Not necessarily. I mean, the client is the one that initiates the connection. But in terms of establishing communications, a client could both be a server and a client at the same time. So, there's no real reason to restrict it, in that sense. I think it'll make more sense when we look at TCP and what's going on. It also... So, let's say I'm making a thousand DNS requests to this server, because I've just opened up a web page that's got a bunch of domain names that I need to go resolve and then get IP addresses to go fetch. I need at least a thousand ports to keep all the replies consistent between each request. So, it gives you flexibility in that sense. I'll need over perhaps 2,000-5,000 UDP requests open at one time, but that gives you kind of SOL on that point. Yeah. We've got two cool questions. So, how often would the client then resend a UDP request to check, or, like, refresh their IPs on there? So, like, how often is the attachment going to have to continually spoof that UDP? It depends a lot on the application. So, actually, those DNS entries have a T... Anybody set up a DNS before? Like, on GoDaddy or something like for domain? Yeah. So, when you set up the IP address there, you can set up the time to live, like, the time that that DNS response is valid for. It can be as short as minutes or it can be as long as days. So, it depends on... So, if you're an attacker, if you really want to poison their DNS response, you would set a huge TTL that says, keep this for weeks or as long as possible. Or, you could take another tax that says, do it for a very short duration so that I can scan you once and there's no evidence of it. You're back to talkingtogoogle.com. So, you kind of go both ways. But, yeah, it's really application dependent on what specifically you're speaking of. The fault is that if the client is expecting the attacker to be Google.com, right, wouldn't the attacker have to provide content from Google.com? So, like, you can't just... Yeah, but how do you get content from Google.com? You just, like, forward it over. You can forward it over that way one way or you could just go to their web page, download, like, you can go to the web page, file, save as HTML, you download a copy of that website. You can then serve that to other people. You can then put it there at Google.com. Yeah, it kind of knows exactly how you want to do it for your particular scam. It can just connect to you and then get no content back while they think you're Google. Exactly. Yes, exactly. That would be silly. So, this is why, and this is just, like, we're getting there of, like, why do we need HTTPS? Because that is what actually validates that it's Google.com. With HTTPS, we're asking when we make a web request to any machine, we're saying, okay, this is essentially true that you have the private key of Google.com. And in this case, even though I've been able to trick someone into going to the attacker, the attacker doesn't have Google's private key that can't impersonate Google. So, is HTTPS used on top of UDP or is UDP kind of just not used anymore? UDP is used in DNS so it's used all the time. So, if you go to the web page and you're typing an angel name, that's UDP that... So, HTTPS is just on top. HTTPS is on top of UDP but the same concept here. Connections and everything. Cool. Okay. So, if it is real, if you, like, if you're rerouting the attacker to take your Google code and rerout it to the attacker, it's a complicated question. So, I think they're going away from there's a header that you can set that basically says no HTTP, only HTTPS. So, I believe in the case of specifically Google.com they use that header so it wouldn't even allow you to go to the HTTP version of the site. And if you try to impersonate the HTTPS you get a scary warning that says you're a attacker or whatever. So, yeah, you would be hopefully blocked from visiting their site which like Google put so much effort into doing that. Because this happens all the time. Do you have two different versions of the HTTPS? Yes. It actually comes back to ports. So, on TCP port 80 is HTTP port. HTTPS is 443. And so, that tells your browser which one you want to use. A little bit, still on the same topic. Do we talk about... networking into a bank? No. The last place? I mean forever this attack. Oh, yeah. Yeah. We did, right? What's the first step? Watch a lot of movies and then the second step. What do you learn from those movies? Gain information. Gain information, right? Reconnaissance. So, similar thing. We're talking about network applications. So, from a security perspective. In other scenarios, let's say we're a pen tester we're trying to break into a company. So, we know what IP addresses they have available. We're interested in one specific machine. So, there's some machine there. We... conceptually... So, we think about it. How do we... If we're not on the local network of this machine or somewhere else we know there's many hops from us to X. How are you trying to break into that machine? We're in one of the switches but we don't control these switches. These are ISPs in between us and them. We're not giving permission from the ISPs to try to break into their devices. So, it's a company that has given us permission to break into... one of the hops. Like between two hops. Yeah, I don't want to man the middle anything in the middle because I don't have legal permission to do that. So, I want to avoid jail. Conceptually. Okay, so... There's a server. What's happening on this machine? Machines, right? It's available directly on the internet and that's not in the address. It's probably talking to other machines. What is it talking? 1's and 0's, I guess it's technically correct. Yeah. UDP replies. Would the server ever send requests? Maybe. Who knows? What kind of server is it? What types of servers aren't there and what type of server is this? FTP server, how do you know that? Okay, so FTP is one type of server. What else? What's going on earlier? DNS? Web? Web server? Right, HTTP, web. Maybe it's a file server, NFS. Could be a mail server with... Yeah, something to be... I'm at RPC. RPC? How do we know which one it is? And in fact, more deeply, what does this mean? So if I say it's a web server, what does that mean about that server? So if I told you this is a web server, what does this mean about this machine? Yes, I'm not just saying that. Web software that is listening on those ports that are talking like the web protocol. We'll talk about that for now. So there are certain ports that correspond to web. We actually just mentioned them 80 and 443 53 21 23 23 Put that down. 21 Is 20 telling that? I don't know these ones, so we can just like that. So in each of these cases, you have a program running on this machine. So this is an FTP server. There's a program running on this machine called FTPP that's listening on port 21. And it doesn't matter at this point that this is TCP or UDP. We'll get to that in a second. So how many possible services could be running on this machine listening? It was 2 to the 16th, right? Minus 1, maybe? I don't know. I don't think you can use port 0, but I'm not 100% certain. So how do you know which one of these services are running on that machine? So actually we had a better question. If we knew that FTP was running on this machine, could we use that information to maybe break into it? We look and try to find out, identify what FTP server is, like what version of software is, are there any known vulnerabilities in that, and then we could launch an exploit against that FTP server that has local access to this machine. But we're missing a step. So how do we go from random machine on the internet that just exists somewhere to knowing, oh, this is an FTP server and a web server? Could you just send requests to all the ports so that they don't reply? It's not a news? Yeah, so in some sense we need to know what ports is this machine listening on, right? What? And specifically when we say listening, we mean not necessarily well-programmed, but of the programs running on this server or this machine which ones are listening to which ports and accepting connections. Because if we can say, oh, this server is listening to port 21 and it's port 53, then we know, oh, it's a DNS server and an FTP server, probably. Does that make sense? So this ability to be able to tell from a remote machine what it's listening on and what it has available gives us important essentially reconnaissance and intelligence about what's running on that machine. Yeah. Yes, that's already working. But we need to know how that works. That's just a tool. So essentially what we want to do is we want to be able to run this called a port scan. So we want to be able to scan the machine and determine what, in this sense, UDP ports are open and what are available to be listened to. So, we had one idea where we send UDP packets to every port and then what? It's a ladder. If we get a reply back, then we know it's open. What if we don't get any reply back? Yeah, maybe it's slow. Maybe we didn't send the right request. So this is one of these interesting things where there's different tricks and techniques of different types of packets that we can send and you need to be able to distinguish between the cases where nothing is listening on that port or something is listening on that port. So one of the ways we can do this is a zero link. So it's actually the inverse. So rather than see what replies we get, we send a bunch of packets and we receive, so there's an IP message that another machine can tell us that that port was unreachable. There was nobody there. So what we do is we send a UDP packet to every port and we see where do we get these port-unavailable messages back and then those places where we didn't get that message, then we will assume to be available. This is one type of UDP port scan. You can scan this whole range and then we can tell which ones. Of course, and this is where it gets really tricky because depending on the specific machine it may have different limitations. So for instance, on Linux you get 80 messages every 4 seconds of this port-unreachable. So you can scan at most 80 ports every 4 seconds and so you have to do this very slowly to test this whole range. So what would you do in that case? Okay, one way would be do a lot of machines and do it at once unless this is a global limit across all connections. What else? The only target ports that you really care about? Yeah, so just like password-cramming, you want to target the most common ports first to see what's on there and then maybe if you have time you scan all the rest of the ports. Other ways would be maybe there's different techniques you can use to detect UDP ports. We're not going to go into all these techniques. So as mentioned there are tools that you can use to best say, second best on ITCP done in terms of usefulness of network analysis tools is NNAP. So NNAP will in this case the dash S capital U scan means scan for UDP on that specific IT address. So this is that scenario we have a target 192.168.1.10 scan it for UDP ports. Did we specify the range of ports to scan? No, we did not. So by default NNAP has this limit where it's only going to scan so it scans the 1,445 ports and so it will show you that I found port 137 UDP open that is usually the service NNBIOS port 138 that is another NNBIOS and so it will tell you that it scans this. So you can use this on your own devices to scan to see what services are running you might be surprised as to what's running on there for printers or other weird things on your network so you can see what's running there. So this would be a local IT 192.168 network is a local IP address so this would be a local machine on the network that we're trying to figure out what's running there. How do we get to the server? Oh, same you just put there IP address and you'll scan it. I will warn so before you go too crazy with this knowledge. I think it's so port scans are very easy to detect because you need that response back so you can't exclude your IP address you need to know exactly what your IP address is they are very easy to detect because you make in 4 seconds we made a 1,445 UDP request right that's very easy to detect I'm not a lawyer my opinion would say that port scanning is illegal it's just not friendly if that makes sense imagine in your neighborhood or if you live in an apartment complex if somebody is going around jiggling handles to see which handles are lost technically you're not going inside so you're not breaking any laws but if you saw somebody doing that it's like that's not good that's sketchy so I regret doing this only on stuff that you know and have control over and permission of is my general recommendation what if you came into a VPN still the same thing still it's not nice or friendly or would they just would the server just get a VPN address there's no actual connection to where it came from yes unless they really wanted to press charges or whatever they could subpoena the VPN somebody could subpoena the VPN and say who was using this at that time and then that would link back to you to the server just to know you're doing this and be like we just don't want to talk to your ad address anymore possibly, yeah this happens not necessarily here but in other cases so like when I was doing my PHD I ran a crawler that was trying to download all the apps on the Google Play Store and I ran it from our labs IP address and then Google banned our lab type address so nobody with an Android phone could update apps or do anything for like a week while we were still banned so yeah similar concept but yeah yeah routers complicate things so we haven't talked about them yet so in this case we're assuming everything is publicly available but yes if you plug your machine directly onto your network most computers won't have anything shouldn't have anything accessible or running but you can always change that like you can set up SSH servers you can SSH into your laptop all this kind of stuff so it's possible I'd say unlikely other interesting thing I'll mention here is when you're doing a pen test you should specify the entire port range because you never know what could be running there so when I did a pen test at a company we scanned some of their internal networks and saw that on one of their servers they had the IPMI port open on their servers which means that that's the management portal port and through there you can upload a kernel so we investigated this I got super excited and then we talked to them and showed them what we found like upload a kernel so you can get access to their system and get onto that machine and they said oh that's our credit card processing machine please do not touch that as a live server and they were really pissed because they had people that were running scans of their network and they missed it and it's because they didn't set the flags correctly to scan all UDP all ports so port scanning is not necessarily a bad or good thing organizations use it internally to identify what ports are moving on what services which is a really good thing any questions on this moving on to TCP alright so TCP is similar to UDP a transport level protocol so it still has the concept of ports so that's why we start with UDP UDP is a lot simpler but TCP adds on a lot of nice features that we want specifically it is connection oriented so we can have a conversation with another side it is reliable in some sense where not necessarily that it can guarantee delivery if your wifi goes out it can't guarantee that your packet gets delivered but you have two programs talking on the network one side will know what the other side has received its data so that's in the sense of a liable it also means that you get no duplication no transmission error errors and the other side gets the data that you're sending in the correct order are these good things? very good things if I send you a request to say hey give me google.com I don't want the package google.com give me and the other side says I don't know what you're talking about go away we need to be able to have send data from one side to the other and the other side gets that in exactly the same order that we received it so it provides the port abstraction it's a really critical thing TZP is a two way street once we establish a connection both sides can send data to the other the important concept that specifies this connection in this idea of basically a four tuple source IP, destination IP, source port destination port which is kind of similar to what we talked about in UDP if you send the packet out and you're listening on a certain port for data to come back so similar here we'll see different concepts of TZP of okay establish a new connection to that machine then once a connection is established either side can send data and either side can tear it down and the entire reason why you know that you're talking in the same machine is this four tuple of source IP, destination IP source port, destination port both sides can talk this is also called a socket four tuple cool let's dig into the details because this is a very interesting to look at this so we have again source port destination port makes sense these are the same size it would be very weird if they were different we have the same transport level protocols we have next so think about this conceptually is TZP offering more than UDP connection oriented in the library no duplication that's all stuff that we had with UDP we had potential loss, potential duplication all of that so in some sense it makes sense that they're less UDP had source port, destination port that was it so we would expect that TZP has additional information because it's doing more in that sense it has to have some way to deal with this and to get that you can't get that for free of reliable communication and we'll see the mechanisms of how that actually works but we're going to first look at the detail of the header and then we'll come out to see how that works so two important essentially maybe one way to think about this is like a bookmark or is that too old of a term is anyone never seen a bookmark in a physical book bookmark or do you feel super old what's a book? it's the thing you print by the kindle okay we even know a place in our communication right so both sides need to know where they are in communicating just like a where the bookmark saves your place in the book so that you can go back and you know exactly how far you've read and how much you still have left to read similarly, we need two different important numbers here a sequence number and an acknowledgement number that are both 32 bits those as we'll see are ways of essentially specifying where our place is and where we think their place is and we'll see specifically how that works lengths of the header, some reserve some flags windows are interesting we won't go into them but basically you have this for now checksums, so again we're using checksums to make sure that we don't have any weird header options padding, data any questions on the format here we don't have to go into every detail here so you think about it like UDP plus right so we have UDP reports plus additional information that's going to let us establish communication and just like before we have our TCP packet with the UDP header TCP data with the TCP header encapsulated inside the IP data with the IP header encapsulated inside Ethernet on every top hole okay Alice is here Alice has the IP address of Alice what kind of server do you want Bob to be how about just a regular web server what was that mail server I'm sorry I already picked I don't have the ports okay so Alice and Bob so Alice and Bob Alice has the IP address of Alice Bob has the IP address of Bob we know how to get IP packets from one to the other so we touched on this a little bit Alice is a client she wants to initiate a TCP connection to Bob and you can go over DNS a little bit how did let's say she went to mob.com in her browser IP address so Alice's machine needed to use UDP to ask a DNS server what is the IP address of Bob.com it says oh IP address of Bob so now Alice knows the IP address of Bob that she wants to make a connection to Bob it was established that connection so we have Alice needs to send a packet to basically tell Bob hey I want to initiate a connection it's sometimes special because Bob needs to know is this part of a communication and are you guys with Alice is it not so we need some way to tell Bob hey I would like to start a new connection and so IP level we know this packet is going to be sent from Alice and Bob what's the source IP of the destination IP IP of Alice and the destination IP of Bob IP of Bob great now in the TCP packet what is the destination port yeah HPDP so it's going to be port 80 and the source port so just like UDP Alice is going to create some random so it's going to give me a 3 digit number and that is 999 Alice needs a way to say also needs a way to tell Bob hey I want to establish a new connection with you so this is through there's a number of flags that we saw in the header this is through the send flag that says I would like to establish a new connection with you then so okay the goal of this protocol is that both sides so then Alice can start sending data to Bob probably would seem like that idea why because Bob needs to respond to that and confirm the connection yeah Bob may not be listening on port 80 there may be no application listening on port 80 Bob may tell Alice go away I don't know what you're talking about so to send a bunch of data before you actually know if anybody is there listening would be very rude and a waste of network bandwidth so now Bob gets this packet is Bob listening on port 80 yeah it's a web server listening on port 80 great new person who wants to talk some web to me awesome so I need to reply back to Alice and say that I would like to establish this connection so then what is Bob's packet going to look like so at the I.T. level because that's to be the same thing but flip so I.P. so source I.P. and destination I.P. is what's the source I.P. I.P. I.P.B, I.P. and Bob and the destination I.P. I.P. I.P.A I.P. and Alice and then okay great so then we have source port B and the destination port 365 cool so think about it from each of their perspectives right I.P. at that point when she sends this packet again remember all of this is using I.P. there's absolutely no guarantee that packet ever gets to Bob right that packet gets to Bob he says great I would love to talk he sends he does some knowledge this is a sin act so it gets a sin request sends back a sin act so now when Alice gets that packet what does she know she can start talking right because Bob has acknowledged her packet right she said a packet Bob responds and says yeah that's good let's start a communication so can she start sending data from Alice's perspective but what about from Bob's perspective yeah so he doesn't know right so if you look Bob got one packet to initiate the connection to sin packet replied with a sin act packet back to Alice but now he doesn't know what's happening he doesn't know if Alice is okay with this communication maybe Alice went away maybe the wifi dropped out he has no way of knowing that this packet actually got sent to Alice so what does he need yeah so he needs an acknowledgement to his acknowledgement right and then at that point both sides have confirmed yes we are good to talk both sides have agreed to it now they can start sharing data and actually communicating so where does the concept of a sequence number come in so we'll get to it we're going to get to it right now so now we need the final packet so we've already used sin we've already used sin act it'll just use an act we'll get rid of sin source IP source IP is going to be IP of Alice then IP of Bob source port source is 365 destination is 80 so now when Bob gets this he knows oh and then sorry and then an act so this is the super important I mean from networking this is like the key to TCP is understanding the sin act act three way called a three way handshake you need to send three packets back and forth before the connection is actually established and then at that point you can communicate now with the web or wouldn't it be more common for the I guess Bob in this analogy we probably talk first after the communication because we have to load the web agent before you use the sender to take so practically we can use Bob in a sense to do that first no so the way ACD viewers is the client says I would like to get this URL because the server needs to know what URL you need to get so there's an HTTP request that the client sends and then the server sends back those ones okay cool every good sin act what does sin do the very first packet so that's the to initiate the connection packet that's the very first one so like SYN and it's named after the flags that are set in the TCP packet so we can look at one example here so now we have this problem of so we've established this connection and so when Bob receives a packet now how does he know that it's part of this connection Bob receives some packet he has multiple connections with multiple people how does he know which connection it's a part of we have a unique identifying for tough source IP destination IP source core destination for so that's how what it enables Bob to figure out exactly all the different kinds that allows Alice to make multiple requests to Bob right because she'll have different source ports and each of those communications will be different so if you add your web browser it will be a different source port from you exactly even yes it can get even more elevated alright so now we want to exchange data that's the whole reason why we're here Alice wants to send some requests to Bob so Alice can now we know everything I'm going to ignore the IP information 365 destination for 80 get for instance that would be the very bare bone I mean the barest of bones that Tom and I would usually request to Bob wants to reply to this Bob says great here's your web page another packet similar thing the HTML deport 365 however so Alice gets back to this page how does Alice know that Bob actually got this request because we go back to what we needed to do with TCP what do we want here a reliable string delivery service means no loss, no ordering, no transition errors so we want to be able to know what the other side got in our path so now we need some way for Alice to say for Bob to say hey I've heard you up till byte X so essentially this is where we have so technically okay this is where we're going to be I'm going to make it slightly simpler the Stephen Summers start at zero Stephen Summers are done randomly and incremented for roll over but that's not really important right now let's say we start at zero and we're going to send how many bytes in this 1, 2, 3, 4, 5 now Bob's going to do so for every packet that you send not either connection the acknowledgement is how many of your bookmarks how many of their bytes that you've seen up to acknowledging so this one when Alice received this packet Bob is acknowledging that he's expecting byte 6 right so start at zero read 5 bytes that means he's expecting the 6th byte so now if Alice is aiming more to send she can send that on the next one knowing for a fact that Bob has already received these first 5 bytes would you get the 5 bytes size for get get space slash oh god the size of the data that I'm trying to send so like for example let's take that for a second so let's say that this request never got to Bob it was dropped along the way this request never received a Bob but Bob is sending something to Alice so then what's the acknowledgement that Bob has seen up to zero but where did this zero come from we need to establish it in the in the three way handshake right so we need to establish what our starting sequence numbers are on either side so that we can know where we're expected to go we'll get to that in a second but now when Alice sees this acknowledgement from Bob of zero what does she know at this point yeah Bob has never seen I know that I've sent these 5 bytes but Bob never received them so I can re-send it which means doubling this packet let's say Bob gets both of these packets is this going to cause a problem so imagine a long strip so starting at zero where did these 5 bytes go starting at sequence number zero can we put these bytes here yeah 0 to 5 get space slash and then we're here so if I get 2 of these packets I can ignore them but I started at sequence zero so if I get 2 of these packets it would just overwrite itself yeah either overwrite itself or I can just ignore it because now I know I've read up until there so now I'm actually expecting sequence number 6 so anything before that I can ignore because I've read up to that we get this process and this happens both sides so every packet has both a sequence and an acknowledgement number and this allows either side to send that to the other and the other side to acknowledge where it received traffic where it's got tired from the important thing that we're missing here is the establishment of these sequence numbers so and this is actually something that I really love about networking so in this packet there will be an initial sequence number we'll call it sequence A so Alice's sequence number essentially and we'll get to why in a second she randomly chooses an initial sequence number 0 to 2 to 32 then Bob has to acknowledge that so Bob chooses first his own sequence number so the SIN comes in from Alice has her initial sequence number now Bob is going to reply back with a SIN act he needs to establish his own sequence number so he generates a new one of the sequence number, Bob and then he needs to acknowledge Alice's sequence number so does he one way to do this would be he's acknowledging the sequence of Alice so just put sequence of Alice and then in this part here what does Alice acknowledge so Alice hasn't sent any data yet so the sequence number is the same what does she acknowledge is not like this what Bob acknowledges is the sequence number of Alice plus 1 you don't include these packets this is just on setup which makes it very annoying so sequence number here 32 bits if I gave you a sequence number and I asked you a person would you be able to turn it into an integer specifically which byte is the most significant byte which byte is the least significant byte why maybe it's for this right so the end in this here actually matters which byte is the most significant byte which byte is the least significant byte to be perfect I believe probably the reason for that I think network is big indian almost x86 and everything is little indian so the interesting thing was they added this so doing this replacement of get data from this packet and then copy and paste it into this acknowledgment number it means that the other side knows how to speak the network byte order that you would expect so it's actually an interesting check that they added into here to say if you can add one to this number and I understand that you added one to this number we know we're both speaking the same indian in this which is the same for all of this networking but it's just that interesting and kind of historical thing so the acknowledgment here is the sequence number of A plus 1 and the act here is the sequence of A plus 1 and this should be the sequence of A plus 1 and then this is what they use going forward so this is their zero for this conversation and they just increment these numbers as they exchange data packets this is a nice service this is something that if you intercepted one of these packets of these three conversations and say I know a little bit about it but I can look at the four tuples that I've identified and I can look at their conversations after that you know they're at attack or something if I replicate that send it back but with a with a conversational place being like one thousand or a million suddenly it won't we really ignore all our packets and so you get above a thousand so it's going to just ignore everything for a little time yeah it won't be a really long time it'll time out it'll kill the connection as in not to restart long back there's another stuff that you can do better just as insidious okay we talked about the other flags so we talked about sin, act, thin is requesting to shut down one side of the connection so one side can say I'm no longer going to talk but I'll still receive data from you reset basically means we messed up let's start over from the beginning so I'm going to kill this connection so if I got that v-sync I think eventually it would be possible to reset it back up so this stuff's not important we talked about basically all this we have a three-way hand shape you can go through this example make sure that everything makes sense as far as sequence numbers and intelligent numbers we talked about the data exchange so here you can see that the client has sent 25 bytes with a sequence number 75 and the acknowledgement number is saying this is the next bytes that we expect and they sent 30 bytes so the interesting thing here that we didn't talk about is if you have nothing to send you still need to acknowledge what somebody sent so this is a zero byte acknowledgement packet where the server sent 30 bytes to the client the client has nothing to say but the server needs to know that I got received otherwise it will keep sending so this acknowledgement packet to the server now everyone knows exactly how much data has been sent and all the applications can process that data we'll go break this through shut down it's pretty easy it's not anything crazy the fin so you set the fin flag the other side says great we'll stop talking and then the server when it wants to close the connection sends a package with the fin flag and it sends it to someone acknowledges so this happens every time you visit any website any time you make any connection all of this communication happens so remember SIN and SINAC actions are the really important things for the networks