 Cool. All right. So we've talked about, uh, let's see, what are the, all the things we've covered. We covered IP addresses, we've covered how IP packets, uh, work. We've covered how, uh, your OS decides if your destination IP addresses on your local network network or not. Um, and it's, uh, we also covered, um, direct delivery. So if you are on the local network, how does a packet get delivered directly there through the link layer? We talked about ARP, the address resolution protocol, which maps, uh, IP addresses to physical MAC addresses. And then we talked about, um, ARP poisoning or ARP spoofing. So we showed that like the fundamental basics of networking, ARP has no way of knowing, you know, it's really important job is to map an IP address to a physical MAC address, but it has no way of verifying that that's actually true and that actually happens. So this is something that we need to do, um, that, that as an attacker, we can take advantage of in order to pretend to be other devices on the network. Uh, we can even, so we looked at ARP spoofing, we can even do, uh, similarly, IP spoofing on a local network. So, uh, we can, we can send an IP packet from one host to another, but impersonate the destination target host. Uh, sorry, I'm all the hot. I need. Cool. Okay. So, uh, okay. So yeah, so our goal here is we want to be able to send and, uh, IP datagram. And so, uh, I don't know Christian, are you out there? Can we use you again? All right, cool. Thank you for being a good sport. Fun fact, there's a Christian in both sections. So on the rewatch on Tuesday, uh, that Christian was quite surprised that they got, uh, that they were getting chosen to represent a bad guy. We'll have to have you all fight at the end so we can figure out which one is the real Christian. So cool. Okay, so what we, okay. So, and similarly, like what we did with ARP, so we looked at the network. And we go back to the network that we had, we talked about, we have my machine, which is 1921680.10 and the printer, which is 1921680.20. And when we get in, so we looked at direct, direct delivery, how that works. When we send that, so let's say the printer gets an IP packet. And so, so now we're on like I back to IP. So, let's say, you know, there's M, there's P, we'll just keep this kind of simple right now. P gets a packet. And that packet will be composed of multiple layers because it's Ethernet. So that out, outermost layer, the source, let's say has the MAC address of M. The destination has, so if it's going to P, what's the destination MAC address going to be? Yeah, MP. And this is a, so we've already established, so we can assume that M is already established ARP because this is now an IP packet that's getting sent there. So the outermost layer is Ethernet. The innermost layer is also going to have a source and a desk. So the source here is going to be M192.168.0.10 in our example. The destination, what's the destination going to be? You don't have to give me the exact IP address, but is it going to be MP? Yeah, it'll be the IP of P. Great. It's not MP, right? Because MP is actually 48 bits that doesn't even fit in the IP. So it is, and this is, you know, a big callback when we originally designed this crazy network. The destination is 192.168.0.20. Oh, okay, here's what we can do. This will actually bring us back. I think both classes enjoyed the concept of printing currency. And the message is print money. Only three, we don't want to be too greedy. So that's the body of the message. So the printer gets this. So, and just to be clear, this is the Ethernet headers. This is the IP headers. And for right now we can just call this, this will be IP data. Questions on this packet? Okay. So I've set up my printer. I've set up my printer very secure. I have a policy that says only print from 192.168.0.10. Right, sounds good. Printer gets this print message. Should the printer start printing? So it passes the policy. It says only 192.168.0.10. Great prints. The printer starts printing out money. The printer itself detects that it calls the FBI, the FBI bust into my house and arrest me for being a currency forger. And I go, hey, I never printed currency. What the heck's going on? And they say, hey, but you have a policy here that only 192.168.0.10 can print. And your machine has that IP address and therefore it must have been you that said this, right? Now, is that true? Is am I the only person who can send that packet out? Yeah, why not? So imagine Christian, I'm going to use you again. How do we know that Christian's not on my network? Think about it like this. What's stopping Christian from sending out a packet that looks exactly like this? Yeah, absolutely nothing. Christian, don't talk about ethics. You don't have ethics in this example. In the, in the note, notability world. I don't want to hear about your real life. That's just getting too weird. Okay, so. Okay, so yeah, so fundamentally there's nothing at anything we've talked about and there is nothing secret that I've been holding back. The switch can't tell that this is a that Christian is forging this packet because for all the switch knows maybe M did switch to whatever port C Christian is now using. So that doesn't even really matter. And so fundamentally, and this is the fundamental problem. So let's look at this packet. P your printer. What of this packet can you trust? Let's look at the ethernet headers. Can you trust that this was sent actually from a source address of M lowercase M? Nope, because nobody validates that on the way you can't trust that. Can you trust that the destination is the MAC address of P? Yep. That's good, right? Why do we know that this is good? Why can we trust this? That's a real terrible color. Yeah, because it's for us, right? Otherwise we wouldn't get it. Exactly. Exactly. Okay, then we think about the IP packet. Can we trust the source of this IP packet? No, we can't, because fundamentally anybody could put any value in there and we wouldn't know what their actual quote quote their assigned IP address is in the network, because nothing stopping them from doing that. What about the destination? Can we trust the destination IP address? Yes, similar logic, because it's meant somebody is trying to send this to us. We don't know where it came from, but we know it's actually coming to us. There's actually a fun analogy with surprisingly enough phone calls in the telephone network. So what are you supposed to do if you get a phone call that's allegedly from your bank saying that there's been a problem with your bank account, they're going to have to lock it down unless you can verify that you still have possession of your card. Can you trust the caller ID that shows up on your phone that says this is 1-800-CHASE? Yeah, so fundamentally the telephone network works actually in the technical reasons are super interesting. We've studied this in some of our research where the reason is that actually having caller ID was optional for a long time in the telephone network. So it got added as an optional header and nobody along the call path actually verifies that and authenticates that that caller ID actually belongs to the person calling you. And so, yeah, somebody's mentioning in the chat that they downloaded an app that allowed them to spoof their caller ID so they could call somebody from their own telephone number. It's the exact same way on IP. You can send a, you can technically I guess send an IP packet to somebody from themselves. And so yeah, the other thing that you'll see is I'm sure you've all gotten what they call neighbor spoofing telephone attacks where they will call your phone number with a phone number that has the like the area code and at least four or five of the first digits the same and they can call their own phone number. And I think that's praying on people thinking that it looks like their own number so they answer it. And they can randomize that every time and change it for every call so it makes caller ID based blocking basically useless. So anyways there's actually a lot of interesting parallels between network security here and how networks work and how the telephone network works. Cool. Yeah, they're super annoying. We're trying to, you know, we do some research into stopping that so that's cool. Anyways, so fundamentally the only things that at the, at the Ethernet and the IP level that we can trust are the destination. Did the destination get there for the IP. And this is similarly with a call, you can't trust the number that you're calling from but you can trust that the telephone network when you try to call chase or whoever your bank is back, that it will actually go to chase or they could hijack those calls they would be breaking in the dough so. Okay. Cool. So this is how we can perform an IP smoothing attack and it works. It's, it's literally trivial. So we can pretend to be another host on the network so in this example. Christian has the IP address 111 1021 21 and they want to send a packet to dot 14 in this network, pretending to be from this phone dot 16 so there's some trust relationship here. And so then Christian could just create this packet and can even this kind of the crazy thing they can even lie at the Ethernet level so they can set the MAC address to be their MAC address and send it to the target MAC address. Because again, nobody's checking that so it really doesn't matter. So, this is how you can do IP spoofing at the local level and we'll see how this can be extended further on any questions about this. Okay. Now we got to go beyond into the wide wide world of the web. Do we have a diagram for this. Kind of. Is it super annoying when I zoom when I scroll up and down between these things. Okay, thanks. It's like refreshing the material in your head. Sorry Colin you got out voted so be quicker next time. Okay, cool. So, so we've seen and actually, what we've seen is my machine here talking to either an Xbox or printer or anything on the local network. So, everyone agree that we all understand how a packet gets from one machine to another machine on the local network. Yep, cool. Now we just have to figure out how a packet gets outside of our network and that same process happens at every single hop along the way. That's exactly how the internet works. So, the packets that are getting sent right now from my machine to zoom are making all of these local hops and so we have to change this diagram slightly. Basically, so what's missing in our current network diagram this one. Right we have our machine, we have a printer, all these other devices connected to the network. How do I actually get to the internet here. Yeah, I need some way to get out of this network right so my. So remember we had that decision tree this decision tree here I want to send some data to an IP address. We say is this IP address local then yes I know exactly the procedure to follow. I make this our request I do all of this. So, but we haven't studied the what if it's not local. And actually in this network. So, to get some things to work like let's say your printer. Technically your printer doesn't need access to the internet. So you could be printing, you know, you could be printing documents and not currency because you're not a criminal. You could be printing documents, let's say Amazon return, whatever our codes or one of the thing I'm thinking of return forms or whatever you could do that without the internet at all labels thank you how did I not remember that. Yeah, so you don't even need access to the internet at all to do this right and this would all happen locally. But of course we do want access to the internet. So, the way this works is we're going to take our diagram, and we're going to change it ever so slightly. So, we're going to have our machine. And now I'm going to deliberately keep this as a switch. Oops, hello. Hello again. Okay. Man, I'm just, there we go. So we'll add in the watch for now and the printer but I don't want this to get too complicated. And we're going to add in another special device we'll call our for router right now. And there's really nothing special about our. And this is why I want you to kind of start deconstructing in your mind the notion of a router being this. This is a wifi box or this box that also does switching, because and because it can do different kinds of things. Because a router can literally just be a machine as we'll see with two network interface cards and that's all that's basically required at a basic level. So if you guys that then it allows you to say, set up your own machine to act as a router so that you can give access to, let's say a local network that is not accessible through wifi on your own machine and all this kind of stuff. Yeah, so we can go with our network so the router is probably connected to we'll call it mo or modem, which is then connected to and now I'm going to draw it as a squiggly thing because I have no idea what goes on in there. And we'll call this the ISP at some point, but it'll come to another ISP, and then it'll come to a router, which is connected to some kind of switch, which is connected to zoom. Cool. So we'll still have our same network so I'll be 192.168.0.10 and it was a slash 24 if I remember correctly. Is that right. So let's say zoom, because the problem is I guess all of the nice IP addresses are taken will do all twos. How does that sound. Oh, twos are like Z's that actually makes sense maybe 2.2.2.2. So that's not actually zooms IP address but let's say that's the IP address I want to make send an IP packet or IP datagram to writer IP packet to. So we'll just walk through this exactly like before. Right so I know what I know about the local network is my IP address 192.168.0.10. I know the netmask is slash 24. And so just like before we'll say I want to send data to 2.2.2.2.2. Okay, so now it'll ask is 2.2.2.2 local. No, it's not local. Otherwise why the heck would I do this insane example. Okay, but now we don't know where to go. So why in this diagram is the router special. Like we can already kind of see it in this diagram what what makes the router different than the watch or the printer, or even my machine. Yeah. So, thank you I think Amadeus and Eric and chat just mentioned that it's our it's our way to get from local to the internet. Right or it's a way it's the only way if you think of this as a you don't have studied the internet and trees right. Yeah so it's the only way so we're a little connected network in there. Right, with our switch. There's only one possible way we could get out of this local network and that's through the router. Right that's our only connection to the internet so it must somehow be important, but we need to know that so we actually have up the information that we need to know we need to know our IP address, our net mask, and so we need. Now we need IP net mask, and we'll call it right now a gateway. But this is actually a very general approach that will kind of come back to in a second. So we say is to to to to local. And basically say okay. Okay, where to send to to to to to because we can think. Hello. I love that in this case this makes sense right we have a router with one modem to one ISP, but if we're running a business right our router actually may have a second modem attached with a different redundant ISP, which has its own connection to it. So I may have different rules about which IP address I want to use through which modem and which ISP maybe it's actually cheaper for me to send certain traffic through certain ISPs. And that's why routing itself the idea of, and routing is basically the notion of okay I have this packet it's destined for 2.2.2.2, where does that, where's the next hop. The local home network it's simplified basically by the gateway. So your gateway is the next hop so here I know my IP 192 168 0.10 slash 24 is my net mask and my gateway I'll call 192.168.0.1. This means that, and by default the gateway says okay if you don't know where to send this packet, aka it's not on the local network then send it to the gateway and the gateway knows how to route that packet. Yeah, and then it's their job. So what's a requirement can I have a gateway of 192.168.10.1. Why does it have to be on the local network. Yeah, so I can send the packet to it right basically I'm going to what I'm going to do is leave the IP packet the same but send the packet to the router. Yeah, otherwise there's literally no way for me to get there so it has to be something on my local network yeah that's an important point, and this will help you out if you're ever setting up a machine and it's giving you like an invalid gateway error and you're like what is going on I don't really understand it's because you've messed up the net mask so the net mask doesn't actually match the network and your gateway is not in there and things are failing very poorly. Okay. So, we say okay where do I send it to 2.2.2 this is basically the routing question. And so what's the answer in this network where do I want to send it to. I want to send it to 2.2.2 but where do I. I need to first send it to R I need to first send it the gateway so this is 192.168.0.1. Okay, so where to send so the answer is 192.168.0.1. Okay, so I need to think about what we actually want to send. So ultimately, what's the IP packet I want to send. I want to send it to source RIP. Yeah, so this will be, and I've messed up because I've used internal IP addresses here. I'm trying to decide if I want to cover that a little bit okay. Let's do it very briefly. Okay, source 192.168.0.1. And the destination is to so with the destination be 192.168.0.1. Because I want my my ultimate destination is 2.2.2.2 right that's where I want the packet to go. And then I have some data in there this is my video frame. But the next hop needs to be 192.168.0.1. And for the next hop so I know that 192.168.0.1 is on my local network. So I'm going to need to wrap this IP packet in a direct do direct delivery of this IP packet. I need to add an Ethernet header. So what's my source Ethernet header. Yeah MAC address of M perfect. And the destination. How do we get the MAC address of our. Yeah, I need to ask with ARP. So I need to say ARP. What is 192.168.0.1. That's supposed to be a question mark sorry. Right what is ARP ARP. It's not a pirate protocol ARP. Okay. So I'm going to say it will return us the MAC address of Z. And so then I put here in the destination MAC address of Z. And so I go back up I'm M I send this out to the switch. The switch says, and we actually know so the switch is keeping track and because these machines just communicated using ARP, there'll be entries in our switch port so will the switch send this packet out to every device on the net on the net. Nope, it'll send it out only on the port that has the router. So the packet goes from here to here. The router gets it it says is this so the router gets this whole packet. It says is this destined is this at the Ethernet level it says is this destination for me. Yes, MAC address of Z. Great. So it will then take off that whole layer. And then it says is this IP address for me is this packet meant for me. Nope, it's not. And so it needs to know it's routing table that says okay if you have a packet. So the router needs to know. Let's call slow. What's supposed to be MR sorry. Ah, wait, yep, good call. Thank you. Somebody messed me up. Yeah, so this should not be the MAC address of Z otherwise you get dropped it is the MAC address of our right the router. So we fundamentally so if you think about it ARP only happens on a local network do we have any way to ask about the MAC address of Z. No possible way. The only device in this entire diagram that can ask for the MAC address of Z is our their zooms router, which is way the heck over there I've actually no way to even talk to that router itself. Cool. Okay, great catch. So our packet travels to the switch. The switch then travels to the router. The router looks that packet it looks at the IP address so it takes off this other this outer Ethernet layer. It says okay. Is this IP address destined for me. Why does the router care if the packet is destined for it or not. Yeah to know where to drop it or to know to reply to it right so this is why when you access your routers IP address directly. Often it shows you a web interface where you can configure things. And that's how it knows because your destination IP address is that router, whereas the whole other time you're trying to use the internet. Your destination IP address is not that so it looks at that and it just routes it along its way. So your router actually. So the very cool thing is this behavior that happens on your machine that decides where does the packet go when it's not local is something that happens exactly on the router and it's the same process is definitely not something we're going to get into the weeds with that's something that you can study in your networking classes. But essentially, this router will have something that says, if so we'll call this interface one, and this one interface two, because I don't want to use zero and one. Basically, it'll have something that says if 192.1. And it's the important thing is if desk is 192 actually it'll be a starts with but whatever 192.168.0 then send on interface one else. Well, it'll be like an else if desk. Okay, in this case it's just an else. This is why I see we're not going to get into this send out to interface to send out to interface to to whatever the IP of modem zero is. So this is, we talked about it very briefly like DHCP so this is actually why your router if you go in and check the settings your router depends on the specific ISP sometimes you have a fixed IP address sometimes not, but oftentimes it uses DHCP itself to get its external. So this is usually called on a router, the land side so the wide area network side and this is the land side. So then your router says okay, I need to send this to IP of the modem, which it now knows because it knows its gateway and where it should send packets. So it does exactly the same thing. So at this point, our frame of reference has just shifted. And now we're focusing here and considering these two devices as a local network but directive delivery happens exactly the same way. So your router needs to figure out the MAC address of the IP of the modem. It figures out that out through ARP it then will take this packet, add a new Ethernet frame to it. The source will be the MAC address of the router and the destination will be the MAC address of the modem. And then that's how that packet goes from the router to the modem so it goes here. And then the modem sends it to the ISP and does all kinds of stuff. And now do we care or actually know anything about what they're using in here are they using Ethernet or IP addresses or anything do we even really care. No, we don't care. They could be it could be carrier pigeons I don't care as long as they get my packet there. Right and even then I don't have a guarantee that they will. But, and then at some point it will cross ISPs so it'll cross from our ISP maybe to somebody else to some other internet service provider. It'll finally come to the router at zoom, where the router at zoom will say okay is this for one of my packets. Do I know how to get there to do to do to yes. For me is and let's say this is a 2.2.2.1 slash 24 is that IP address of the router. So the router says okay yes this is for my network and it's on my local network because it's 22222. It starts with three twos. And so I can do direct direct delivery here, the router uses ARP to say, so it gets this packet. It uses ARP to say who has IP address 22222. What's your MAC address, and that zoom machine will will respond so finally, the packet will arrive the MAC address of a ZR for zoom router, and the desk will be the MAC address of zoom. Finally that packet gets to zoom zoom gets it. Now to zoom again similarly to zoom know about my MAC address. And no because that information gets stripped off at every single step right that doesn't make it out of my local network because it doesn't need to that MAC address information is only used inside my local network. Cool, it gets it. It looks at it. And that whole process was just to do one frame of video. And then that keeps happening with all of this is how the internet works. I mean this is how literally how your packets are getting from me to zoom and then from zoom to you. It's crazy. Yeah, I can't believe how fast I can't believe how fast this happens and how actually reliable this is in practice. So you know, think, think about this a little bit when you, you know, happen to get some instability in your network, you can say how much it sucks but yeah it's still super crazy that this happens, and that everything actually still kind of works. Cool. So yeah this is why indirect delivery is is actually nothing fancy the only fancy thing is this routing part. And the other fancy thing that has to happen which will get to get into really quick. Normally I don't cover this in too much in depth but since it's such an important part. So why was the 192 168.0 network important. Why did I say that that's why I chose that. What's special about 192 168. Yeah it's a private IP address range. Which means when, which means when zoom gets this packet, they'll say, I don't know how to reply to this packet because I can't talk to that IP address it's a private and it's a local IP address only. There's literally probably, if not thousands probably millions of machines out there who think their IP address or 192 168.0.1. So that is a fancy thing that does network address translation which essentially sits your router is smart enough to know that hey, I know the local network, and I know my private my public IP address. So you'll have a. So some public IP address. And so, essentially, when the packet crosses from your local network and your router out, it will replace the public your private IP address with your IP public address, and the packet just goes out. And it does it in a very clever way using some extra information that we haven't talked about but essentially it encodes information in there. So it can do the reverse when it comes back so when your reply comes back from zoom. It looks like zooms are applying to 192 168.0.10. And it keeps track of all of that. So anyways that's how network address translation works, and this is actually why we kind of haven't run out of IPv4 devices because your house really only needs if you're not running a service so as we'll see on the network to run a service you need to be connected so people need to be able to connect to you like zoom right people in this case need to be able to talk to 2.2.2.2 they need somewhere to send their data. Due to the magic of Nat, you don't need a public device for every single device inside your network as long as you're not accepting connections. Now where that maybe ties into another thing is, and we haven't even talked about ports. But you can think of port forwarding as a way to accept connections now the problem is if you have like Xbox here, and you want people to be able to connect into your machine so you're trying to run a server. You need a way to tell the router hey when you see packets like this send them to the Xbox because somebody is trying to connect to me and I want that to happen. That's basically to get around that so all of these. So it's super funny we like develop network address translation so that we could deal with having many devices on our local network without having to worry about having public IPs for them. But it's like we want sometimes somebody to contact us so we have port forwarding, but poor foreign things actually a super pain to set up so there's no stun and turn or all ways that you can try to basically automatically set up port forwarding there's also other things. Anyways, all kinds of crazy stuff so. Yeah, that that are real world things that actually do this so let's look at this. This indirect delivery example. So the gateway is. And the other thing I didn't mention in this diagram. Is that I said that this the IP level of the packet doesn't change that's kind of true. Right there was actually one field that has to change. And that is what we talked about the time to live. So every single hop that value gets decremented and when it reaches zero, the packet is dropped. And so that's. That's so that the packets don't live forever in the network if something fails. Cool. Alright, so let's look at this example. So again indirect delivery, we're on two different non local networks, right and we know that and we're able to tell that so we need to send our packet to our gateway. And the gateway is just a machine that is connected to at least two or maybe more networks and so it has to figure out which way the packet goes from there. And this process just continues network to network until somebody finally gets us to a sub network that has the same destination as the host. Cool. All right, so here we have another example will briefly walk through it where we're trying to send this packet from 111 10.20.1 21 to 128.11.41.10. And we'll see that that packet gets sent from switch to switch or essentially here we're using it as routers so from router to router to router to router, all the way there until it gets there. And the important thing is the TTL field is decremented at every step, the link level addresses and headers change on every step. The interesting thing here this this is where networking gets super complicated of how do you decide to get a packet to the closest destination and continue it going here. It may surprise you and this is one of the fun facts I love about networks that. So if you were to just think about number of hops did this packet take the least number of hops. What's the shorter path. 123451234. What's the shorter path. Yeah, the shorter path is up here. Right there 12345. So five hops. So does this ever happen that a packet can take a longer route there. And again, remember things are fast right but they still every hop has to do some computation and some work it's not free. So these routers may be in completely different physical locations so why would have so would, why would. So if you're choosing optimally, right, you actually probably maybe never want this to happen, but why might it happen in practice. Yeah, maybe traffic so good ones are. Maybe the network knows that this link is saturated and it can't handle any more traffic. So the shorter path there's something wrong with it. Yeah, one of the. One of the most fascinating ones is let's say this router represents an ISP, and it's trying to decide where to send traffic, and it's cheaper. It's all about those dollar bills right you should think about that these are companies right. So it's actually cheaper for it to send it out on one path than the other path. And companies have agreements with each other, and it's actually gets very complicated of how this all works. But, and it's partly complicated because of the fact that it's a business relationship between them. So that actually literally factors into these routers decisions of where to send packets. And that's why a packet can take longer to get there, because and the other crazy thing is, these monetary relationships aren't always symmetric. So it that means that when the packet goes from 121 over here, it can go this way, but there's absolutely no guarantee that the return packet travels that same way. For this person it may be cheaper to send the traffic this way. And so when the reply happens it goes back this way. It's going to be crazy. And so, add those those things to the reason of, of why, of why it's magic that things kind of work. Cool. Okay. Okay, so some fun historical facts. Obviously, so right now like I mentioned we do hop by hop routing. When they're smaller they actually envisioned a reason why when you're sending a packet you may want to choose your route through the network so why would you want to choose your route through the network. What would be an example. Yeah, so security or privacy. So you look at it multiple ways. There used to be stories of, I don't know if it's true anymore but people, you can trace and time. Actually, there's a whole area of networking research is understanding what's actually going on in the internet, and people are able to determine that packets let's say from like Germany to or Russia or whatever to other countries, for some reason made a stop in the US before going back out so the theory that the NSA was listening to that traffic is who knows draw your own conclusions but anyways if you had source routing you could choose to avoid that right. You can think about countries that do censorship these kinds of things right is you can think about that so yeah it's super interesting so. Okay, I'm not going to go in depth in here but if you want more information about routing this what I mentioned you can actually look in your, you can use this command route dash and this does not work on Mac it. For some reason, it uses the net set tool and I even think route is deprecated I think it got moved into the IP command on Linux. So this is slightly out of date but basically the way to read this is it says hey if you have, if you don't know where the packet goes. So the destination is anything and this is kind of a top down approach send it to 192 168 1.1. I'm going to skip these. Cool. All right, questions on indirect delivery you now understand how packets move through the Internet isn't that crazy. It's like what is it taking us three courses. So now we're going to talk about TCP and we're going to add that layer to the top so that we're going to actually start getting closer and closer there so going back to the layers we've looked at the physical layer. We looked at the link layer we looked at ARP. The one thing I didn't mention was RARP I guess reverse ARP so reverse ARP is basically goes so what's the input for ARP and the output of ARP. The input is what what's the input of ARP. Think of it like a function what do you give no no no like conceptually not be IP. Yes, you give it an IP address and what does it return for you. A MAC address awesome so reverse ARP is the opposite so you give it a MAC address that returned you an IP address. It's a way to ask a machine on your network say hey what's your IP address I see your MAC address. It's kind of a nice thing at the IP level so at the IP level. We have we didn't go into it in depth but there's various protocols here at the IP level one of those is ICMP which is a ping packet so when you send ping it's sending it at the IP level. Now we got to build up so we've think about this we built up all of that knowledge and machinery and understanding just to get a packet from one IP address to another. Right we had to build all of that local stuff we had to build all the physical stuff we didn't build the physical stuff we used it whatever we had to understand how packets moved locally and then moved from hop to hop. So we want to do stuff with it so we want to actually send data so this happens at the transport level with TCP and UDP and we build applications on there. We're going to start with UDP because it's the simplest. So UDP builds on IP right so just like that stack that we looked at it uses IP to provide a connection list. Again no concept of a connection you're just sending packets unreliable best effort datagram delivery service so again, we have delivery integrity non duplication ordering and bandwidth is not guaranteed none of that stuff is actually guaranteed. So what it adds is something super important. So, we've been thinking of IP addresses like physical mail addresses right so you can think of that like the street number when trying to mail a letter. But how do I mail a letter to an apartment building I think some of you are maybe in apartments I think that's probably a fair guess. I need some other bit of information right I can't just send a letter to an entire building, I need to send it to a particular place inside that building. And this is what TCP and UDP provide, which is this notion of a port abstraction. And why this is incredibly important. Let's say. So let's say your IP address is zoom. So, so you are zoom 2.2.2.2 to many twos. 2.2.2.2 to zoom. What kind of services to zoom have so we saw that there's like a meeting service right video let's call it video to a text chat what else does it have audio, maybe the website. Right, so again we saw that packet right that. So I sent an IP packet from my IP. The destination is to 2.2.2.2. Now the question is how the heck do I specify which of these services should get it because if my videos, my video frames are going to the text chat that would be very very bad. That's why we need this concept of a port number. So you can think of. So you can think of an IP address specifies the street address, and the port number specifies the apartment number. And so that's why. So you can think of having different services in here. And that's how the operating system is able to know which packets are meant for which service. Cool. So UDP is still used a ton this is what we talked about so we'll compare and contrast it to TCP a bit later, but a lot of things. Actually so incredibly important things. So DNS is the thing that maps Google. And just like remember ARP was a function that took in IP addresses and gave you MAC addresses DNS is a function that gives you a domain name and returns. Whatever the IP address of Google is yeah it's that's not that's one of their IP addresses but tons of stuff. So services like DNS which are, which also underpin the entire Internet if they fail that's a massive problem use UDP. Other things like this video call that we talked about, because it can handle dropped packets and you actually don't want that for real time things games also use DNS, all kinds of cool stuff. Just like everything else that shouldn't surprise you there's a header for UDP and there's a specific format for a UDP message. So it leads with the most important addition here, the source port. So there's 16 bits how many different source ports are there. So what is that somebody type it out please. Yeah 65,536. So it can. So this number can be zero all the way up to 65535 right because it's one less so it's two to the 16th minus one is the highest value because you have to include zero. And the other 16 bits are the destination port, the message length a check some and then the data so this really this is why UDP literally adds nothing on top of IP. If the only thing it adds is the port abstraction. And so this is nice because it's not adding a ton of overhead and it's not giving us additional features that we may not need. So the question is about ports. It's very different. I don't know how zoom actually makes their thing work so it's super difficult for me to say. Yeah UDP. So for something like let's say DNS it needs to be on a port where everyone knows it and so they can ask for DNS packets. Usually. Yeah, so I'm not I'm not really sure that's a good question. Cool. And so, just like we saw with IP headers and the IP data being encapsulated inside of a Ethernet header and that packet being the Ethernet data. The exact same thing happens here so we have the UDP data which is the actual data we want to send like look up this request what is this packet. We have that UDP data and then we have those UDP header which we just saw which is very very small. Then that is inside the IP data and we have an IP header. And then that is then fit into the frame of the Ethernet packet which is then has its own frame header so it's like headers all the way down until you finally get to the data. It's very cool I kind of like this it's like a nice, you know the layers analogy makes a lot of sense here. And that's it. So there's nothing fancy to UDP there's literally nothing. All that it adds is this port abstraction and so for our purposes, what we want to think about here is, how can we spoof and IP address. All right, how can we spoof UDP packets. Well, does anything in here. Add anything to what we've talked about with IP spoofing. Yeah, fundamentally no so the only new things are these ports right so let's say I wanted to spoof and ID a UDP packet, and I wouldn't to pretend in this case I'm getting revenge on Christian, so I want to make a DNS request on behalf of Christian. So what do I need to control here, or what does the DNS server need. Yeah, it needs the port so I need the DNS port. Can somebody look that up is it 53. If you're on Linux, you can do. That's too many L's, I think ADC ports it's in there. Yeah so port 53. So all I need to do I can just do IP spoofing. I can set. But now this time my data is not a printer command, it's a UDP message. My source port is 53 my destination port is whatever I want, or sorry my my source port is random it's for me, so I should get rid of that and this is where this lack of a race sure is annoying. And so I set the destination port to be 53. I set in that packet I set the IP source to Christians IP address and then I'm going to make a DNS query for I'm going to get him back for the printer thing so I'm going to make a DNS query for I am a, I am a currency. What's the word currency fraud why am I blanking on that word forger there we go I am a currency forger.com what's that IP address. And so I'm going to do that a bunch and fake a bunch of those DNS messages so it looks to his ISP like he's a currency forger is ISP is going to turn them in. And bad things are going to happen to him, but I wouldn't really do that of course Christian. No, not you the other Christian from the other class. And so this is how we can do that so this is we can also leverage trust relationships so if. So I mentioned another protocol here. Oh yes. I want to do that better. I mentioned another protocol here. What's NFS does anybody use that, or as have heard of it. Yes the network file system. If you've set up on the implementation that's usually used on. Well, is SMB the same no I think it's actually different so we'll stick with the NFS for now, but I think SMB Samba is very similar to NFS. It's basically a way like Samba or file sharing to say hey share this drive on the network. And of course you may want to limit who can access that drive you may want to say only my machine can access or my machine can delete files but other machines can add files for instance. And so, that's why we may find ourselves in a situation where now we'll give Christian his do back so now the server is here. There's some so there's a network file share server. There's a trusted client. And the attacker now wants to pretend to be the trusted client and send a spoof a UDP packet to the server. And let's say that that message is delete all files. So, the attacker can do this what is the spoof UDP request look like so if we zoom in on that. So, can we safely ignore the ethernet header for right now. Yeah, let's ignore it for now. So we'll start at the IP level. So what's the source IP that Christian's going to put here. Yeah, client. And the destination server. And then at the so this is IP. And then at the UDP. So as port. So the source port. I can put whatever I want ABC. And destination port. I'm going to write NFS refer here because I don't know what that port is if somebody can look that up I will rewrite that 2049 thank you. Cool. So with this, this packet gets sent. And does it matter to the server whether I'm in the local network or not. Yeah, no, because it depends on this server and this client right if they have private IP addresses, and I'm outside there's no way I could get a packet in that would actually do that right because the router would never accept a packet for an internal network. So it all depends on the specifics of the circumstances, but fundamentally, if I'm, I don't even need to be on their local network. So I can Christian can just send an attacker can just, you know, send this packet out and spoof pretending to be the source IP of the client, the destination IP of the server, the server gets it, and it checks it right it says okay. Where's this packet coming from. It's coming from client is the client allowed yes that client is trusted I trust that client. The packets for me great. I take out this IP layer. The source port. Okay, it's for source port ABC, or you don't care about that destination port 2049. Hey, that's my NFS service. Great. And so the operating system sends this data to the NFS server and deletes all the files. Now, the server is going to reply, it's going to reply back and it's going to say, it's going to say at this level. So at the IP level what's the source of this packet server. How come the destination is not Christian. Yeah, because spoof thank you because you the server has literally no way of knowing that this packet came from Christian and not the client so all that it knows is that it went from client so great. Now, a little bit more about UDP. So it's going to flip the source and destination ports just like it did the source and destination IP so the source port now will be 2049 and the destination port will be ABC. Cool. So what happens when the client gets this only freak out if they're really careful. Yeah, so fundamentally, right so a question to think about is how does this normally work right. We send a UDP request and the way that we know we're getting a response back is we look for a packet that has that that that is to that destination port. So remember how we talked about with ARP there's no way to link those two packets, but here, we do know a way to link these packets because we chose that source port so we choose it randomly. And we expect that that same thing is sent back and so we know this message is a reply to the request that we sent. And in this case if we get a packet for something we're not expecting we just drop it. We just say great okay this is weird who would send me this and like nothing literally nothing happens with that packet. That makes sense. Yeah the next morning when the client checks the server they or when the client actually accesses it they'll be like what happened, and the server will gladly show them the logs like hey trusted client, I deleted all those files like you asked. And the client will be like, no, I didn't and then we'll have to figure out what happened. So this is spoofing right so the notion here is we're spoofing a trusted client to a server. Now let's look at the situation of we want to do hijacking. So this is the case where the client has made a request to the server in this case think DNS. So in this case, the client is asking hey what's the IP address of Google.com. So why might Christian want to change the results of a query. So what, why might Christian want to change that response. Yeah so Christian may want to change it from all eights to. I don't know I don't know what a bad looking upside one dot, go leet. So 1337 or something IP address that Christian controls that way the client thinks they're going to Google.com but they're actually going to Christian. Now in this case the client sent a UDP request. So let's go through what that looks like that UDP request. So at the IP level, the source is going to be what client destination will be the server, the source port, let's use something different BCD. So it'll be a random thing that we we choose the destination port report I say DNS was 2049 was NFS 53. Thank you. So now for Christian to reply. What is the packet that Christian must reply with. Or let's think about like like this. What's the server going to reply with. Right the good packet what's the good packet going to be. The source there server thank you destination will be the client, the source port will be 53 and the destination port will be what BCD thank you. 8.8.8.8.8. Right. So that's the request that the server is going to send so if Christian wants to forge his own request. What does that packet look like. So the source is going to be the server. The destination will have to be the client. The source port has to be 53. The deport yeah so thank you you're getting there BCD and now 1.3.3.7. So everything needs to be exactly the same except for the payload right this whole all the headers need to be exactly the same. What's the problem there what problem does Christian have. The packet that Christian wants to send. Yeah, what information does does Christian not know to even construct that packet. So can can Christian know the server's IP address. Yeah, of course they know the server's IP address. I know that I know Christian uses this DNS server, let's say yes. Right, I know this, I know the client's IP because I'm deliberately trying to target this client. I know the source port here 53 because this is the server source so I know DNS is on 53 I know it's going to be there. What about this destination port. Where did that destination port come from the client exactly and it should be randomly generated each time, because that's what links the response. So, what can I do. Well, what if I change the situation. What if I say I'm on the same local network as the client in the server. So I can do art. I can art poison so that the client actually sends that packet to me first instead of the server and I can just reply. Or I can do what we talk about I can turn that switch into a hub and get that packet. Right. Or maybe another thing I can try. Any source ports did we say 65 535. Yeah, why don't I just, what if I tried, what if I sent out 65,536 packets, each with a different destination port. Now the client will just ignore all of them, except for the one that we, the one that we want. And I do though have to race this one because this one is also coming back, right. Great. Yeah, that took a little bit longer but this is what I want to harp on. So, so you can see how these attacks build on each other right so we can think about the capabilities that we have as an attacker for on the local network, we can use art poisoning to steal that UDP request, because fundamentally I need that port to be the same. And so I need a copy of that packet. Maybe I can try to guess it maybe it's not as random as I think it is and I can break it that way there's other ways to think about approaching this, but this is, and, and you can see this is a fundamental difference from UDP spoofing where I'm pretending to be somebody else when making a UDP request, but to actually spoof the reply requires a local network and requires me. I also don't necessarily have to be on the local network and use art poisoning. If I'm on the path, right if I own any of those routers on the path of that packet takes from the client to the server, then I can send that back. What's a case where you may be on a local network with somebody who's making DNS requests at coffee shops, Wi Fi public Wi Fi public unencrypted Wi Fi is something that you should be scared of when using unencrypted communications because of what we talked about art poisoning plus DNS hijacking. All this stuff is because these protocols don't have any sort of authentication or integrity here so we'll stop here we'll look at one more aspect of UDP then we'll move into TCP. And of course, don't be, don't go away from this so terrified right there actually are mechanisms we've put in the web in the higher level protocols to try to mitigate this but fundamentally the core this is what's happening. So thanks everyone, and that was fun.