 Okay, folks. Let's get started. Hopefully, you all saw much. You have to post about assignment 4. Did you? Maybe. No. Let me check that thing. Is it the one that says that the solution sets up? No. It was the one that said assignment 4. The last part, the custom hash, was more difficult than I had anticipated. I basically moved that hash to extra credit. If you get that 10 points extra credit on the assignment, and then I created a new hash for part 5, still the same hashing algorithm, but I deliberately said that it's 5 characters all lowercase, so that should help make that feasible. Now people have actually completed all parts of the assignment, so that's good to know. Any questions about that? Is the only difference that the extra credit one now is just a bigger character set? I'm not going to say anything about it. Now that it's extra credit, I really can't say anything about it. I'm confident that somebody could do it. Keep your laptops and desktops warm. My computer was spinning last night while I was doing that. It's more difficult than I thought. Will you tell us after the assignment is submitted? We'll see. Somebody may get it. I don't want to rob them of that. Cool. Let's carry on to local network attacks. All right. Let's back up slightly. More slightly? No. We're going to go right to ARB 2, but we won't back up too much. Let me refresh our memory. What is ARP? That is what ARP stands for. What is ARP? What does that mean? The thing that tries to figure out what MAC address is associated with CERC-IV. Yes. The keyword in the title is protocol. Exactly. We talked about it's a protocol so that you can translate an IPv4 address to a MAC address. So it's the address where it's used in protocol. Yes. Converts Metis IP addresses with MAC addresses. Yes. Perfect. Okay. Cool. We're now thinking in terms of attacks. We talked about this in the context of a local network. Who verifies or validates that the ARP reply that you get back is actually the correct mapping of IP address to MAC address. Isn't it the computer that has the specified MAC address? Sorry, this is the IP address. Let's think about that. We'll go back to our hardware. We've used some crypto terminology. We can say we have two computers, Alice and Bob, and they are on a local network. There is our attacker Eve, who wants to say Eve's drop on their communications. So A wants to send a packet to B's IP. We'll call it 10-002. A is 10-001. So what's the process where A tries to figure out what's the MAC address of 10-002? And where does that go? It goes to the switch and then where does it go? It goes to everybody, right? It's a broadcast request, right? It's going to every person on this subnet. Not for IP address, FFF. Or, wait, MAC address FFF. It's a broadcast FFF at the link layer, yes. I thought switches, like a hub is what sends it to everyone, and a switch is what routes it specifically to... Yes, but who is an ARP request for? Everyone? Everyone, because you don't know who has, right? So the information you have is that IP address. You want to send a packet to 10-002, you don't know their MAC address, so you need to ask the entire subnet by sending a request to a MAC address of FFF, all Fs. So all ones, just like... Well, we talked about the IP address. No, we did not. Okay. So this means that even if a switch recognizes that and says, okay, this needs to go to every single port, right? So both Eve and Bob will get this ARP request. And now, what is Bob going to do? You have your hand up. Go with your instinct. I was going to say he's going to send back a reply with his MAC address to everybody. Yeah, so an ARP reply, so not to everybody, but just specifically to this person. So we'll call it A's MAC address or Alice's MAC address, and we have the MAC address of Bob. So Bob will create a reply. Oh, why it's so hard to spell today. I'm going to need more coffee, and I didn't bring any. All right. So this is going to be to the MAC address of A from the MAC address of B. B. Close enough. So when B sends this packet out, where does it go? It goes to switch, and then what does the switch do? Routes it just to A. So again, the key difference is this is not a broadcast packet. It's not being broadcast to the entire network. It's only going to machine A. Now, of course, when we talk about switch versus hub, it kind of depends on what happens exactly to that packet. But if we assume it's a switch, it should go out just to A. So if it's a hub, it will go out to everybody, but they're, yes, it'll go out to everybody, but their network card would drop it, because it's not to them. So they only listen to frames that are for either the broadcast or their specific MAC address. Okay, cool. So think about this from A's perspective. Right? Let's zoom in. That's exactly what I want to do. Okay. So just from A's perspective, what happened in this scenario? So think about this. Does A know what other machines are on the network? No. No. Does it know the topology of the network? No. Does it know? Let's talk about this again. Yeah, okay. A, wait, a little bit about the network. In terms of the network, what does A know? What was that? Maybe. Well, it doesn't know that yet. But let's, yeah, we'll think about it before this whole communication happens. Yeah. It knows it's IP address. What else does it know? Yeah, IP address wants to send a message. IP address wants to send it to? What else? The address of the switch. The, ooh, tricky. We'll say the address of the gateway, but we're not talking about gateways yet. Gateways and switches can be separate and different, which is why that's, it's not wrong as, yeah. So yeah, so needs to know the address of the gateway. If you think about the switches, just whatever's on the end of this cable, on this physical cable. So in that sense, it doesn't really care that the switch hub, whatever, as long as it can send out ethernet frames on there and somebody else will read them and do something with them. Yeah. It knows it's own MAC address. It knows it's own MAC address. What else? Yeah. What do you do? See what I get? It knows what data it wants to send. What else? Has it known that this is a local network delivery and not a multi-hop? Subnet. Subnet. It also knows it's subnet. But fundamentally, right, and this is what's kind of crazy when you think about networks, this machine doesn't actually know any facts about any other machines that exist on their network. All it knows is that network configuration, which is what we just talked about, right? It knows it's IP address. It knows it's subnet. It knows, or netmask. It knows the IP address it wants to talk to. It maybe knows it's gateway address, and it knows it's MAC address. And those are basically the only things that it knows. So now, when it wants to send a packet to... Whoa. Oh, we're super zoomed in. Okay. This is weird. I don't even know if I can make this work. Yeah. No. So when it wants to send a packet to 1002, it first needs to map that to the MAC address. So it first would check, is this on my local network? It would do that by checking the subnet. Then it would send an ARV request, which we know will go to all the machines. Does A know that it got to those machines? No. Does A know how many machines receive the message? No. No, it doesn't know anything. It just knows that it sent an ARV request, broadcasted it to the whole subnet, and is hoping that somebody will reply and tell it who has 1002. So now, in our scenario, we know we zoomed out, we see the whole topology, we can see A, B, and C. B responds with an ARV reply, and says 1002 is at the MAC address of B. So when A gets that packet in, 1002 is true about any of those values, yeah. It just knows that someone responded. It just knows that something responded, and it's telling it that 1002 is at the MAC address of B. Beyond that, there's no, we don't know where that packet actually came from. How does A know that E didn't send that packet, and B did? It doesn't. Fundamentally, A does not know. There's no mechanism in here to validate identities or authenticate or verify. So if A gets two ARP replies, and one says 1002 is at MAC address B, and it gets another one that 1002 is at the MAC address of E, does it know which one's correct? Fundamentally, if you think about it from the information that A knows, there's no possible way that A could know which one is correct. Right? Maybe that machine moved, maybe whatever, maybe something weird's going on. And so this brings up basically a fundamental problem of local networks is that there's essentially no authentication happening here, and it is trivial to spoof an ARP reply. Because what do you need to know in order to craft an ARP reply? What was that? You need to know which IP address. The destination IP address? The destination. Let's say this. The IP address of the person or the machine that made the ARP request. The MAC address of the person making the request, the requester. So we need the ARP address there so we can craft our reply to go to them. And we need our MAC address. Or whatever MAC address we want to spoof. And then fundamentally, we can control A's ARP cache and ARP table. So that, so let's say, depends on let's say the implementation, but let's say our packet gets there before B. And so A thinks 10-0-0-2 maps to the MAC address of E. So when A now sends that packet that it wants to send to 10-0-0-2, what's going to happen? Yeah, it's going to, the IP packet will be from 10-0-0-1 to 10-0-0-2. And the Ethernet frame will be from MAC address A to the MAC address E. When this gets to the switch, where's it going to go? Just on this port, on E, and B's never going to see that packet. Now, did E respond to that message? They have all the information they need to respond to that message. Now, what's the problem? Yeah, lots of hints. Let's go here. We'll go over here. So what did we say that we needed for the ARP-to-ARP spoof? I thought, so we said that we needed, so if A is the sender, and like B is the recipient, do we say that we need A's IP address and A's MAC address? Don't we also need B's IP address to make the reply? Because the reply is in the form of IP is at this MAC address. The request is in the form of who has this IP address. So we actually don't care that, it all depends on what we're trying to do. If we're trying to spoof an individual machine, then yes, we would need to know that machine's IP address that we're trying to impersonate or intercept their traffic. Otherwise, it doesn't really matter. We could essentially spoof any IP we want. But yes, that would be something we'd need to control. Yeah, sorry, we'll go this. Are you going to notice that it's not receiving what it was supposed to receive? How does B know that it was supposed to receive something? So you want me to zoom in on B? Google or something? Or do I expect to get like a wave? So who are you in this scenario? B. You're B? If you're going to Google, you're initiating the connection. So in this case, you'd be A. The question is, how do you know whether you're actually talking to Google or not? So what you're saying is that it will only send it to one. Not like both of them. Like if you have like a spoof one and a real one. So because of the way the switch works, right, when the switch sees this arc reply that says port, we'll call it 2, has MAC address M. Well, it would say it has MAC address M E and MAC address M B. So it may not, it depends on how the switch works, but it's highly possible that the packet doesn't get sent on that. So is it possible that like when you spoof it, like you don't get it? Like it would just go to B? No, wait, when you spoof it, being who? E. If you're E and A gets to MAC address as it's sent it to, is it possible that it just goes to B and it doesn't like send it to E for some reason? It all depends on how A updates its table because it will get two replies. So it can be the first one in or usually it's the last one in. And actually what you can do is most of the operating systems when they're dealing with arcs, they don't keep track of requests or replies. So they just update whenever they see an arc reply. So you can just keep firing off arc replies saying, hey, I'm 10-002 and I'm at this MAC address of E. So you can ensure that you're always in their cache. If you want to make sure E, like it doesn't just take the data that was meant for B, but also let it get traffic to what B was. Yes, we're going to get there in a second. Yeah, yeah. So let's say A got the 10-002, the M under packet address of B and up there first. Can E send a 10-002 to actually know how to do this like re-corrected or something? Yeah, in terms of arc replies. So it would just continually send arc replies. Most operating systems will just update the arc cache to say that, like, they don't keep track of requests or responses, right? Because that means more logic in your operating system. So what's the logic then? How many replies they got or how many? Usually you would just take the last one. So every reply would be a new mapping of this IP address and this MAC address, and then you just immediately update your table and then go forward. Yeah. What does the router cache again? Is it the MAC address? The router is keeping track of what MAC address are being used on which ports. Yeah, on the switch. So that way, when a packet comes in, it knows which ports to send it out on depending on what MAC addresses are behind it. And there can be more than one. If you think about if this switch is on one port, it's connected to another switch. It could be five or ten machines there. So those packets need to all go there. Heat pretend to be any... We'll talk about this in a second. Yeah. So not keep track of how many replies you get from the state? Are there? It's... Yes. So currently most... So most... It's all... So all this is done in the operating system level, like in the kernel, dealing with these art replies. So I believe by default, there are no protections like that. And I guess the reasoning would be you want it to be as simple as possible. So one... We'll actually talk about some defenses later on so then we can have a good discussion about how to deal with that. You may get... I mean... So the other thing is... So DHCP is basically automatic assignment of IP addresses. Or what happens if you have two machines in your network that think they are 10.002? Right? Yeah. You're gonna have a huge problem. And it's gonna be... Exactly this is the symptom is you'll see two art replies. So it's not always malicious. I think it's maybe one reason why you wouldn't want it detected and just block it. But it's also a real pain. It's never a good thing, let's say. Yeah. Is it possible for the switch to keep track of all the IP addresses along with the mannequin? What's going on? The switch... Most switches don't operate on the IP layer. All they need to do is deal with MAC addresses because the way to think about it is basically when you're plugged into switches you're on their local network. Modern switches are very complex. You can do all kinds of crazy things but in general that's the basic idea. There was one more hand. I'm just going crazy. You're messing with me. Totally possible. Okay. So going back to our tech scenario what we have essentially done is pretended to be B in terms of A. So what have we accomplished in terms of the attacker's goal here? A thinks that B is actually at E. So any packet that A sends for B it goes to E instead. Yes. So we're essentially impersonating B. Are we snooping on the traffic between A and B? No. Why not? It's not getting to B, right? All we can do is pretend to be B but we are not actually B, right? So if there's a super secret communication where they're exchanging keys or something if they now start talking to us we're not going to be able to do that whole communication. But is there anything special about this? Like why did we choose to impersonate B to A? Bob to Alice. Let's use names. It's actually I think slightly more or slightly less. Can you repeat that? Why did we choose to impersonate why did E choose to impersonate Alice? Because Alice is the one that sent out an ARP request? Yeah. Because Alice is the one that, exactly. Alice is the one that sent the ARP request. Is it set in stone? Could B send out an ARP request that we send a reply to? Yeah. Yeah, right? The same scenario can happen and we can do so simultaneously. So A thinks that Alice thinks that 10-0-0-2 is at the MAC address of E and Bob thinks that 10-0-0-1 is at the MAC address of E. What would happen in that scenario? So let's say we flood the network and we say 10-0-0-2 is at MAC E and 10-0-0-1 is at MAC E. Well, wouldn't you not get requests like if B sends something to A? Where does it go? It goes to E. Yes. If B sends something to A, it never gets to A, it just goes to E. Right, so in this case, any packet sent will be intercepted by us. Who knows the real MAC addresses of B and A? Yes, A and B both do, but they know their own MAC addresses, but who else? E. Well, that was the real MAC addresses. So let's say A is initiating a connection to B and this is a protocol or something that we can't fully impersonate B. Maybe it uses some other information, maybe whatever, but we want to snoop on that communication between A and B. So normally, I said earlier that we can sniff anything that comes across this line with TCP dump. So, thinking back, we're moving all of our ARP shenanigans. If we haven't messed with this network at all, will we ever see traffic between A and B on this network on this line that we can listen to? No, because why? Switch is not sending it. Right, the switch would never send it on our line. It's only sending it to the other two lines. So, now if we're playing our ARP games and we've convinced Alice that Bob's IP address is at the MAC address of Eve and we've convinced Bob that Alice's IP address is at the MAC address of Eve, and we just said we know that every packet that's in for them. So, let's think of a connection from A to B. So, A sends a packet from A to E. Eve gets it. Does Eve know how to respond to this packet? No, why not? Like you said, it might be a key transition so it doesn't know the full information. But who knows how to respond? B. So, that incoming packet, let's dissect that. Bless you. So, at the IP layer, what's going to be the source IP? Yeah, we'll call it Alice IP since... Hey, why is this... How do I make it? A thinner pen. Computers. Oh, there we go. Whoa, hey, brand new day. So, we have the source IP is A's IP address. What about the destination IP? Which is whose IP? B, Bob's IP. B, Bob's IP. And then at the MAC layer... Well, I guess we'd split these around, but sorry. So, at the MAC layer, what's the source MAC address? E. The MAC address of A and what's the destination MAC? E. MAC E. Great. So, now you're Eve, you want to send this packet such that it actually goes to Bob. What do you have to do? Can you just... What happens if you try to resend this packet out? It would come back. It comes right back to you. Why does it come right back to you? Your destination IP... Your destination... Sorry. Actually, the IPs don't matter. All we're talking about is the destination MAC address. Your destination MAC address is the MAC address of Eve. You try to send this out and switch and we'll just send it back to you. Actually, I don't know if that's true. Maybe it won't, but... Yeah, I have no idea what it will actually do, but conceptually it will not go anywhere else. Let's say that. So, what do we do? So, do we change the source or destination IP addresses? No. Why not? Do any of you talk to each other? I mean, A and B are talking to each other, right? And so, we don't want to mess with the IP header. We don't want to mess with any of the data in the IP packet because A specifically crafted that to send to Bob. What about... Do we change the source MAC address? Yeah. Okay, so we can change... So, why don't we leave the source MAC address as the MAC address of A? Right, the switch may send it back. It all kind of depends on how it actually works, but yeah, we want to make sure that we get the reply. And so, here I'm going to flip it. So, we have... What do I say? Source MAC? I like the thin pen. The source MAC... So, what do we want the source MAC address to be? The source MAC? Where is this packet coming from? MAC address of... Eve. Eve. Right? Now that we're pretending this is coming from us, and this makes sense because what is this packet source ID address? A. A. And Alice. And what does Bob think Alice's MAC address is? Eve's. Right? So, they would expect the packet to be from the MAC address of Eve. Cool. And the destination? What's the destination? The MAC address of Bob? And then, do we touch anything in the original packet? In the IP packet? Source destination? No, so Bob gets this reply, gets this, and then responds back. And then what does that packet look like when Bob responds? This is going over all the stuff we've talked about. So, what about the MAC layer? So, source MAC? B, MAC address of Bob? And what about the destination? MAC address of Eve because Bob thinks that... Bob thinks that Alice's IP address has Eve's MAC address. Yes. In the previous stage, how does Eve know the MAC address of Bob? So, how could Eve know the MAC address of Bob? Well, let's reflect that back to the class. Yeah. Can we send that out? Yeah. So, we can send an ARP request out and say, hey, who has 1001 before we do any poisoning? And they'll reply to us and who has 1002. And they'll reply back to us so we can keep the original mappings of IP address to MAC addresses. And then poison the network or do ARP poisoning to make A and B think that we have their MAC addresses. And then now we can do that translation because we have all that data. Yeah. First, our request is being sent out by A. Is Eve just modifying it or is it... So, at this point, we've moved on. We're not talking about MAC addresses. This is an IP packet. So, some kind of data that Alice is sending to Bob. And Eve is just modifying it or is it creating a copy of it and then just... Right now, we're not doing anything besides intercepting and looking at it. And we're going to get the reply as well. So, every packet that flows in either direction between these two hosts will go through Eve. So, then Eve has a number of choices. They can just sniff and learn all that data or they can inject and change and modify that data. Okay. So, going back to the reply from B to A. So, source MAC address, the MAC address of B. Destination MAC address, the MAC address of Eve. And then, source IP. IP of A. Yeah. So, IP of source. B. B. And that's... Well, I'll do something like this. Destination IP is what? IP of A. IP of A. And where is this packet going to go on this network? To Eve. Eve, right? Now we're going to A. And then Eve can just do exactly the same thing to change the source and destination MAC addresses. Send that back out. Goes to A. A may respond. And every packet flows through Eve. So, Eve is essentially not just sniffing on all their traffic, but also can man in the middle and change, modify, do whatever to any of the packet data that is happening between those two hosts. You don't seem to think this is as cool as it actually is. I'm a little bit upset. This is insane. Yeah. Packets, you can modify them? Yeah. You can do anything. Right? So, at this point, all communication flows through Eve. And Eve has a vantage point. Because she has access to the data, she can change, modify, do anything to that data. So, she can just view it. She can change it. She can drop packets. She can do whatever game she wants. Yeah. And this is all on, like, local... Local networks. Yeah. Yeah. So, how do we protect against this in a local network? Yeah, we'll talk about that in a second. Cool. Yes. Okay. So, these are everything that we talked about. So, I don't think we need to go into depth in these. Like we said, so our protocol is stateless. It's not keeping track of requests and replies. Yes. Does it not work if the data is encrypted? We'll get there and... I mean, I guess we have to talk about that. Or think about that. What do you think? Imagine it wouldn't work. Why? Because they... If it's symmetric encryption, they don't... Eve doesn't have the key to be encrypted. How do they share a key? Oh, well, yeah, I guess... Yeah. So, if they have shared a key, right, then Eve would not be able to tamper or work. What, I guess, of the things available, what could Eve do? What was that? Could flip random bits, which would cause... Would A or B be able to detect that? Depending on how they're encrypting it. Yes, right? If you're going to want them to be encrypt correctly, so they could just drop it. Right? So... But some can chain-finder bits, yeah? Could Eve just ask for the key or...? Eve's... Maybe. It depends on the protocol. Right? I mean, if the protocol has a way for A to ask me, hey, what's that key again? But, yeah, doing that, it would be difficult if you don't already know the key. So, Eve wouldn't be able to... Oh, yeah, please. She could just drop the packets. She could drop the packets, right? So, cause an availability attack, right? Which would be... Depending on what the communication is, it could be very bad. Wouldn't be able to break the confidentiality or the integrity. I mean, assuming the encryption is done correctly. But that availability component is very important. So... So, which is why you need encryption to be able to trust anything that's happening on the network, because other people could be messing with your traffic. So... So, anyways, this is a... You can step through this on your own time of how this happens. This includes both the... our caches on all the machines. So you can step through, but we literally just did this just by hand. So this is here for your information. Cool. And so... Part of the problem is, with this, is as we saw when we looked at the actual trace of network traffic, and by the way, that thing ran for like 10 hours or 12 hours on Tuesday. It wasn't until I got home that I noticed my TCP dump was dumping all the ARP requests. So we saw that there's some time out to the cache, so the machines will request and say, who has this IP address and make ARP requests? So you're an attacker. What do you do in that scenario? You still want to ARP spoof and man in the middle of the traffic. You just spam your own ARP replies? You just keep spamming, right? You keep spamming these replies. People will ever complain about that, and even if they manage to get it a little bit, your next reply will get that right back to where you want it to go. Cool. Okay, yes? How reliable of a technique is this? Is this going to just sort of race condition? Do we get there first? It is not because it is who gets there last. Okay. So it's a cache-based thing. So rather than being stateful and keeping track of requests and replies, they just always assume that the last reply is the most up-to-date version of that value and then update their table with it. So as long as you send every five seconds one of these ARP replies, they'll keep updating that table, and if any new information goes in there, they'll immediately overwrite it. So beyond... Okay, we've kind of been touching on this idea a little bit, but I want to talk about it a little bit more. It's getting a little messy. See, it now doesn't feel like a pen. Never win. All right, Alice, Bob, and a weirdly configured network. Eve. Okay. So, and we kind of... So when we think about even this scenario that we just talked about, and we talk about it in the context of ARP replies, but more generally, when... I'll zoom in again on B. So we think about all the information that B knows. When Bob gets a packet from 10.001 from Alice, does Bob know that that packet came from Alice? So what's in the information in that packet? And we'll compare that with Bob's information. So Bob gets a packet in from Alice. On the outer later, there's like some source MAC, destination MAC, and then source IP, destination IP. So the source IP says it's Alice to Bob. What are going to be the values here? Yeah, it could be Eve. I mean, we don't really care. The source, the source we don't actually know, it could be kind of anything, right? The destination would be the MAC address of the order. Sorry. Yeah, the destination is the MAC address of the order. Okay. So how does B know that this packet came from A? It has no idea. No idea. What could have happened? So what are the possible scenarios? I don't think it's B. Yeah, so it could be what we just talked about, like an ARP man in the middle. What else? It could actually be Alice? Yes. Everyone went to the negative security minded circumstance first, but in the normal case, it's probably from Alice, right? What else? Let's say Eve's not playing any ARP games. The switch, let's see, the switch doesn't care about IP addresses at all. The switch only cares about MAC addresses. I guess we don't technically know we just got this packet. Maybe B just sent out this packet. That's possible. I'll add it to the list. What if I unplug A? Does B have a way of knowing whether A is online or not? Does B have a way of knowing that this packet came from A and not Eve without any ARP shenanigans? So what does IP addresses mean? What, I guess, what in this information that B just received, can it trust? It was meant for B. It was meant for Bob, right? That's pretty much the only, especially when you think about the IP layer and just thinking about IP, that's the only piece of information that Bob knows is that this packet was destined for him. Therefore, it is trivially easy to spoof IP addresses, especially, I mean, on a local network, we'll see how this extends when we have multiple hops and different protocols and all that stuff. And so this is literally just kind of a case of what we just saw, is one machine on a network, you can pretend to be any IP address you want, whether it already exists or it doesn't. What do you have to do? So let's say you wanted to, Eve wants to pretend to be 10-0-0-10. What would Eve have to do? Could, but there's no 10-0-0-10 on the network. So would she need to poison anything? What does she have to do? What does that mean? Say that she's 10-0-0-10. Yeah, so she listens for our request. When she sees an ARP request for 10-0-0-10, replies and says, hey, this MAC address is at this IP address. And now she's 10-0-0-10 in this network. Maybe 10-0-0-10 is a super important machine that she can impersonate. Maybe she's taken over, or taken out that machine. So the key idea here about IP spoofing any machine can send basically on the wire any packet that it wants. It can put all the values. So when you're receiving a packet, the only thing you can trust is that it's for your IP address and probably your MAC address. Because otherwise it wouldn't have gotten to you. But that source IP and the source MAC can all be spoofed. So what's the difference between ARP spoofing and IP spoofing them? Because essentially you're just pretending to be another one. So ARP spoofing is more you're not necessarily trying to be another machine on the network. You are trying to trick the other machines on the network that a certain IP address is at your MAC address. So rather than trying to convince you that a new IP address exists, it's more about breaking that relationship between an IP address and a MAC address. So it's kind of more like, I don't know, impersonation is like creating a new machine, whereas like an ARP poisoning is like redirecting them to think that you're a different, like an actual different machine. So why would you want to create a new one then, in that case? Because wouldn't you not get any requests to that machine if it doesn't exist? You can because you can still do the ARP reply. Going back to what we were alluding to a little bit, rather than having to send out these fake ARP replies to do these poisoning, which is pretty noisy, you don't have to do any of that. You just act like a normal machine on the network and whenever there's an ARP request for that IP address, you respond to it and so you can communicate easily with every other machine on the network. And it's if there is inside your network, if there's a trust relationship based on IP, which happens a lot, like you can only come from this IP address or you can only SSH to a machine from this way or accessing a web server from a certain IP address, all these things are done frequently. I guess I'm not really understanding this kind of same question. Why would somebody be requesting a machine that's not on the network? So a good question. When you, well, in this case you would probably initiate that communication with them and they may do an ARP request for your IP address to be able to respond back to you. But yeah, actually, I mean, that's just so that they can respond to you, but yeah, in that sense, well, I mean, it could be, maybe, I mean, we'll actually see I think an example of a denial of service attack where basically you can take down B and denial of service B so it can never respond. Then you can just, people are already accessing B so you just pretend to be B and they'll come to you without any ARP poisonings. And it gets much a little bit more clear when we move to multi-hop networks because this kind of, we're studying, in essence we're studying kind of like the security of what and what data you can trust when you receive a packet and that's going to have implications later on in terms of what information we can trust and how other protocols work. Which then leads us to, now the next case is indirect delivery. So what was direct delivery? Local networks. So indirect delivery must be what? Unlocal networks. Non-local networks or remote networks. I would say the opposite of local would be remote. Different networks, right? And how do we know if a packet, or if an IP address is on our local network or not? The subnet. Yeah, the subnet, the subnet mask, the net mask, whatever way you want to think about it, we can compare and determine if that's on our local network. So if it is not, okay, we're going to get rid of our attacker scenario now. I'm going to fuss with this pen with just slightly. So we have a couple of machines. So A, B, and C are all on one subnet. I guess we can give them one 10, 0, 0, 0, slash, slash, we'll go 24. And this network is 10, 0, 0, or 10, 0, too many 0s, 10, 1, 1. Just 24. How many IP addresses does C have? Two, Y, two. It has one where it's on the network of A and B and another where it's on the network of G. Yeah, so it has two network interfaces. They each have a different IP address. They each have a different IP address. They have a different net mask. Okay. So we already know what happens when A wants to send an IP packet to either B or C. Direct delivery. We've been looking at this the last week. It's going to do everything we just talked about. It's going to make that ARP request for the MAC address. It's going to send the packet there, send it out, and it will be directly delivered. Now what if A wants to send a packet to G? So A is at 10, 0, 0. We'll go 2 this time. This will be 10, 0, 0, 1. This will be 10, 1, 1, 1. B we don't care about right now. This will be 10, 1, 1.2. There we go. All right. So A wants to send a packet to 10, 1, 1, 2. So we'll again talk about what people know. A knows its IP address. It knows this subnet. It knows that that IP address, 10, 1, 1, 2, is not in its local area network. So where does it send the packet? It sends it to C. Why would it send it to C? Because it sends the same subnet. How does A know that? Yeah. So we've been kind of talking about this term. Yeah. So the gateway is all of these things. So I'm drawing it. This is why I'm trying to separate this concept of switches and gateways and routers. Most home routers are all-in-ones. They are gateways and switches. So the gateway, you can think of it as the gateway says, and actually it's slightly more complicated than that, is what's my routing table? So you can have complex routing scenarios where different networks you route to different machines because they know how to get things there. But for now, we can think of a catch-all gateway as usually your default. So if you have no idea where to send this packet based on the IP address, you give it to 10, 0, 0, 1. So we'll construct this packet. So we have at the IP layer, we have source IP is, what was it? 10, 0, 0, 2, I think. And destination IP. So who's the IP address we're trying to send this data to? 10, 1, 1, 2. Cool. And in here is the data. So why isn't the destination IP address 10, 0, 0, 1? 10, 0, 0, 1 gets it. So no is the sender to the IP address. Yeah, so yeah. You want to elaborate or? I was just going to say an IP packet is like a letter when you drop it off to the post office. Yeah, you wouldn't put the destination of your post office when you put it in there. You put the destination of where is this data ultimately meant to go? But now what does the Ethernet frame look like? Do I have to ARP request for the? Do I have to do an ARP request that says who has the MAC address 10, 1, 1, 2? It's not on the subnet, right? It'll never get there. ARP replies only go out to your subnet. Otherwise that would be insane. You literally have to get replies from every machine that's ever connected to the internet about what people's MAC addresses are. So this is where you have this nice kind of encapsulation at each of these layers. So MAC addresses, all that link layer stuff only happens in this local subnet, and then we don't care what happens in everybody else's subnet. So whose MAC address do I need? The gateways, right? I need to send this packet. This packet needs to get sent to the gateway, and then the gateway will figure out what to do with it based on its routing table and so on and so forth. So we just go through this example. So how does A know the MAC address of C? Yeah, exactly what we're talking about. ARP request, who has 10-0-0-1? 10-0-0-1 is at the MAC address of C, and so I will send this to destination M, MAC address C. Yeah. How do we know that C is a gateway from A's perspective? Yes, it needs to be part of our configuration. Otherwise we'll have no idea what to do. So that's part of the, and if we go, let's see if this is a good idea or not, we'll see if this will tell us the MAC address or the gateway. So this is looking at, okay, so this does not, it has my IP address, the Ethernet address, and so on, I think on Linux, you can use IP route to view the route table. On Linux or on the MAC, you need to use NetStap, which is very annoying. And the way to read that is, so this is basically a complex routing table that tells you where everything goes, but the default gateway is 10-1-5-3-0-1. And so this is part of, for this, when you connect to the wireless, it uses DHCP to tell you what your IP address is, what your net mask is, and what your gateway is. And that's all the information that you need to do this. Cool, yes. So like in the previous example, if we don't have a gateway hooked up, it'll just mail. Yeah, it's when you get a, I think it's a no-route available to host message is what you'll get. It's just like, hey, I don't know how to get this packet where it's supposed to go. Because if you only know, if you're only on your local network, you only know how to get packets to other hosts in your subnet. You don't know how to get packets elsewhere, yeah. So if we send an ask request for an IP address, it's not local. And the gateway will send us the address. I think, no, if you do that, nobody will respond because nobody has that IP address. Right, because by definition, an ARP request goes out to all systems in your subnet. And if your subnet, so no system in your subnet should have the IP address of a system that's not in your subnet. So who sends us the IP address that says the destination is the MAC address of the system? Oh, okay, that's a good question. So what's the IP address of the gateway? Is it on our local network? So that's why. And this is actually, if you try to set a gateway that's not on your local subnet, your OS will not let you. Because the gateway must be on your local subnet because you need to be able to, A, send Ethernet frames to it, which means you need to know the MAC address, which means you need to be able to make hard queries. So A, very first, before this packet gets sent out, sends out a request, hey, who has the IP address 1001? They're supposed to be in my gateway. It doesn't say that, but it says, who has the MAC address 1001? And C will respond, because this goes out to every machine on the subnet, and C will respond, and C1001 is that MAC address C. For sure, yes. Yeah, that's the beauty of all these attacks. Like, these are just different scenarios, but you can do all of these. Gateways aren't special, and that's what I'm trying to demonstrate here. Why is the output request asking for the gateway to MAC address, but not G? Because in terms of indirect routing, so the whole idea is to get the packet to G, I, A doesn't care how many hops it takes to get there. It doesn't care how it traverses the network. All it cares about is where do I, where's the next hop? So if you think each machine only cares about the next hop, and that way no machine has to have a global view of the whole network, because that would be untenable. So A only cares about its local information, and how do I get this packet, essentially you can think of, to get it closer to 10.1.1.2, where do I send it? You send it to 10.001, and they'll take care of it. How can you trust that a gateway is a secret? You can't trust anybody. Just like a general question, so like what if, so sees the gateway, but someone spooks it, and is there a way of knowing if your message ever got to G or not? Nope. So that's part of IP, is there's no way to know once you sent, just like the previous thing we talked about, once you send out a packet, there's no guarantees at the IP level that your packet ever gets to G. So you will know if that G is down, if it never heard you, if it doesn't want to talk to you, if the packet somehow got lost, you'll never know. Yeah. So like in a real scenario, we would have like, like A sends it to its gateway, but then you like also continue that, so like C could send it to like another gateway. Yeah, it's continually, it's exactly, so every step of it, so here we have basically two hops, the packet you get from A to C, and then C to G. But in a, we'll look at real things, it can be 50 hops along the way, or however many hops it needs to get there. And so, yes, and at each point, each thing only cares about, based on this destination IP address, where do I send it next? And that's all that everything considers. And how long does like a hop actually take for that? We'll look at it that way in a second, yeah. So if A has an IP address, how does it know whether it should put the packet close or whether it should make it look like a gateway? Good question, how does it know? Subnet. So it looks at the subnet, yes. So that's the key, the slash 24 at the end is the key that tells A, this IP address you want to talk to is all the different that's on a remote network, not a mobile network. Exactly, yes. What if we have multiple gateways? Yeah, so then it gets to this routing table, where you can set up complex rules, where you can route different, different ranges of IP addresses, which is exactly how you read this and ask like 10, 15, 3, 18, does this, I think this actually means these are local networks, but yeah, you can set up whatever crazy topologies you want, you can spoof external IP addresses using stuff like this. Yeah, so this is like, they're like DEF CON, we had multiple different subnets, but physically kind of on one network, but we have GLANs, and it looks like this complicated system, but you just have, you can set up different static routes that say, so this is why this is the default, it's the catch all, if you don't know where to send it, send it to the gateway, but you may say, and this actually happens more so at like the ISP level, or in ISPs they have peering agreements with each other, and they may say, man, Netflix traffic is a lot cheaper if we send it through this pier than this other pier, so they may actually make cost-based routing decisions that have no, nothing to do with you in how you're trying to deal with that, and so, so yes, the answer is yes, and that's why it's a super flexible primitive of how to do networking, and by understanding and studying these principles, you can build the most complicated networks you can imagine. More questions? Cool, all right, let's break this down. So, for the packet to get from A to C, it needs to have on the ethernet frame the source MAC address of the MAC address of A and the destination MAC address of the MAC address of C. So, C gets this, what does it do with it? So, first thing it looks at is, is this packet meant for me? How does C know if it's meant for it? Destination IP address. It says, oh, I'm not 10-1-1-2, this must not be meant for me, so this means I need to do well with it. Yeah, so this is routing basically, or, and your computer will not do this by default, which is a good thing, but you can set this up very easily on, I think actually all the operating systems, Linux, Windows, MAC, you can set up your machine itself to act as a router. The basic idea is, what do you do with packets that you don't know how to send? Or that, sorry, what do you do with packets that you receive that aren't destined for you, like your IP address? So, this is configured, so then what does it do? What does C do? So it looks at the destination IP address, and what does it do with the destination IP address? Yeah, so it checks if it is 10-1-1-2 on a subnet of C. Yeah, because it knows it's on two subnets, right? It's on 10-0-0-0 slash 24, and 10-1-1-1-0 slash 24. And I don't know if you saw in that silly art table here, it says exactly what network interfaces each of these things are on. So this is how, so it would say, on C, if you look at C, network interface, whatever, 0, would have IP address 10-0-0-1 with that subnet, and network interface 1 would have the 10-1-1-1 with that IP address, that IP address in that subnet. So it would know physically where to send out this traffic. So C gets it. So how does C then, what does C do with this packet? Yeah, it needs to figure out the MAC address of G, or of 10-1-1-2. Does it change anything? So what does it do with the rest of this packet? Does it change source IP? No, source IP is still 10-0-0-2. Destination IP is 10-1-1-2. Data. And what about the Ethernet? Cool. So C would have had to have done an ARP request if it didn't already know the MAC address of G. It says, who has 10-1-1-2? G would reply, I'm 10-1-1-2, and I'm at the MAC address of G. It sends this packet out, the switch is going to send it back out on this, and it gets to G. So how does G know how to respond? It uses this source IP address, right? So it uses the source IP in order to send a reply back, and then it goes the same way. Yeah. I just wanted to know, what if there's like one more something so we can see you send it to its own gateway? Yeah. Yeah, so if there was another, so if it was not the network, let's say C has three, and it has whatever, it's connected to some switch that's connected to D, which is on, I don't know, whatever. Like, so you could have, yeah, you could have a gateway within here, and so the packet just keeps going until somebody knows, so there's going to be direct delivery in two places, at the start and at the end. I mean, there's direct delivery in every step of this process. Probably the way I should say. And so it doesn't matter how many hops go in. So another, so one important thing is, what happens if you've messed up this network, and A thinks C is its gateway, and C thinks A is its gateway? The packet will keep going back and forth, how long? Forever. Is that a good thing? It wasn't a resounding no. No, you do not want packets bouncing around forever, right? Otherwise you'd still have packets to this day bouncing around from the 70s, right? That would be crazy. We do not want that. So the idea is, and this goes back to the, let's see if I can do it better this way. There we go. So going back to the datagram, we had this time-to-live value, and this value is 8 bits, so it can store 0 to 255. Is that right? And so what happens is, so when I said that the IP datagram has kept the same between hops, that's actually not true. It's a bit of a lie, because at every hop, the time to live is decremented, decreased by 1, and if it ever gets to 0, the packet is dropped, and no longer forwarded on. So this prevents that scenario. So at every step along the way, this time-to-live value is decreasing from 255 to 254 to 253, and so on. Yeah? There'd be more than one gateway. And there'd be what? More than one gateway. Is there a one default? No, you'd need that well. You do not have to have a default gateway, but one packet can't be routed to two different gateways. It has to go to one gateway. Time-to-live decreases at every hop. Every hop. What if you have more than 256 hops? You cannot get your packet there. That's the truth. You cannot get your packet there, so do better. And you can play different games with this, right? Like it doesn't matter necessarily how many hops it takes to get from you to the ASU's gateway. So I don't know if they do this. I talked to you about matting. So they may reset the time to live there. It's all possible. I don't know if they do that or not, but you can play those games, but you can't not decrease that value because then if you get stuck, you could yourself get stuck in a loop, and that would be very bad. There's actually good, interesting work about how far things are on the internet. Cool. Okay, so this is just... Yeah, so this is a actually poorly animated diagram about this to help kind of get this process where it's going from hop to hop to hop. And the key thing to remember is that for more or less, the IP packet stays the same except for the TTL, but there are new link-level frames at every place, right? And this makes sense because the link layer is only about your local network. It doesn't care about anything else. So another way to think about is if these two remote posts are talking to each other, will they ever know the MAC address of each other? No, unless they deliberately tell each other, right? It will never be in that packet because the receiving host will get the MAC address of their gateway, and the sending host will get the MAC address basically of their... like they use the MAC address of their gateway. So I lied a little bit just historically because it's interesting. It used to be that you could actually say what route you wanted your packet to follow in the network. You would have to set this option called the IP source routing. It basically is never used anymore. Why? It's too big and it's crazy. Like, why would you allow people to send a packet and specify exactly the path that it should take? They used to do that because they would purposely route around unreliable hosts and networks. And you could know that because there were not that many networks on the internet. But once you start getting what we're into now, which is an insane amount, you just can't specify that. Is the source routing followed by routers on the public internet? I think no, but it would be interesting to look at. I'm fairly certain the answer is no, and they ignore that, but there's also a lot of IP options, so maybe there's some that you could force or trick a switch to follow. Okay, so as we mentioned, we actually looked at the routing table. This is a different way of looking at it on Linux. So I'm not going to go into it too much, but basically by setting up these routes properly, you can get different... you can route different traffic to different machines so you can play around with that. Yeah, I'm not going to do that. Cool. Okay. All right, so that's all about how data gets... So basically you should be able to describe the exact process that happens when routing data from one machine to the other. But now we need to talk about what... So now we've looked basically at these layers, right? We looked at the physical... Well, we mentioned it, it exists, we can't ignore physics, but we have the link layer and we have the IP layer, and just those two together is enough to get data between networks. Oh, okay, let's do this old regression. So one key question would be, what happens if the time to live value of my packet is reduced to zero? So what did I say happens? It's discarded, right? Yeah, it's discarded. One of the nice things about IP is it has a... it has a type of IP packet called ICMP, which is I believe Internet Control Message Protocol. Basically you'll get a response back that says, hey, I dropped this packet, FYI. The cool thing is you can actually use this to map and understand the hops that your packets take to go out, and that's called... what is that called? Tracer out, wow. Cool. So what this is gonna do? So first it has to translate Google.com into an IP address. We have to talk about DNS, but it has to do that. Then once it has this DNS address, what it does is it creates a packet with a TTL of one. What should happen in that case? It should go to my gateway, the gateway will drop it, and send me back an ICMP message that had dropped that packet. And then I'll do a new message with a TTL of two, in which case where should the packet get dropped? The gateway's gateway. And then three and four all the way until it either gets to the gateway or reaches the host. So this is exactly what this is gonna do. It sends out three packets and measures the time. So somebody was asking about the time, how long it takes. So it takes about right now 500 milliseconds to get from me to the gateway right now. So what's these stars that's happening? What was the two? That gateway doesn't respond to this kind of action. Yeah, so it doesn't send me an ICMP message when the packet drops. So we just have to time out, because we don't know if it ever got there, if it didn't get there, if the packet was lost accidentally somehow. So this is actually interesting. So it's going through. So it's going from 1015301 to 17230383. What's this value here? Is that the Wi-Fi? Where did that data come from? Anybody know? I thought somebody had their hands up. What about the gateway? What was that? Yeah, so what it does, all it has is the IP addresses now, right? So DNS went from Google.com to the IP address. And then we're sending out packets to IP address. And what we're getting back is this IP address 17230383. It's doing a reverse DNS lookup to match an IP address to a DNS address. And this is what it found. So it's kind of interesting. I don't know the exact structure here, but like core-vrf. So obviously this is something to do with our building and some router within our building. Tell one, I don't know, depth management. And then so Fusion, ASU, if you ever talked to the IT folks, has this crazy system of routing packets, but something, I don't know where this is. But we can see they're all fairly close. Like these ping times are, it's not going to be a question, but it won't be a question. I have no idea. Yeah. So why does it keep going like that? Because it doesn't know when it stops, right? Or it, actually, that's not true. What it's sending out are ping packets. So an IP ping, it basically says, are you alive? And you say, yes, I am. So it's sending a ping to Google.com. So if we go, actually, I should ping this specific IP address. So this is that other side of replying. So it knows that once it sets a TTL correctly with enough to get there, there's that many hops between this machine and Google's machine. It could be, so yeah. So the stars are when we get no reply. So we send this message with a, we send three messages with TTLs of sixes. We have no response back. We got no drop packet. We have no idea. And same with seven, eight, nine, 10, 11, 12, 13, 14, 15, 16, 17. So is it done? Huh? Is it done then? If it was done, it would receive a response and we would know exactly how many hops. So it's still being dropped. It could be ASU's gateway is not forwarding those responses to us. It could be, actually, a fun fact. Let's do this. How are we doing on time? You're all packing up. All right, we got a little bit. We're not out. So this is now from the perspective of, this is the machine that's running the homework submission system. It'll be super fast, I promise. Look at this. It's all internal lit. Yeah. So a lot of this stuff is, wow, okay. This is like way more than I thought. Wow, sorry. So you can see the first couple were very quick of getting out probably of, oh, there we go. So it's 23, it's about 24 hops away from EC2 to the system. Which, I think ASU is dropping the incoming ICMP messages. So that would make sense. So you can test this. This is actually kind of a fun thing to do if you're bored and want to learn more about networks. Do it from like different network perspectives of trace routing to the same host. You can try like from your own wireless, from ASU's wireless, connect through your phone to see what your phone does as a page into a server to do it from there. You can get interesting perspectives on the network. So yeah, you can see we got there 30 seconds, basically, through LA. So that's kind of, I don't know, but I would bet this EC2 instance is hosted. No, actually I didn't know why. Okay, but that's, yeah, so it's going to basically Google data center in LA, is what the LA is. That took, you said 30 seconds? 30 milliseconds. 30 milliseconds to get there. That's very fast. That's 30 milliseconds. That's very fast. That's very fast. I really wish this was kind of able to set up there. I don't know. I don't know. I don't know. I don't know. I don't know. Absolutely. Okay, alright. We said 30 seconds. Okay. From that other perspective, there's a lot of options to get out of it as well. So, Those are all the guests.