 Okay, folks, happy Tuesday. Maybe I shouldn't have recorded this, but I think it's fine. What did you think about the talk on Thursday? I hope it was useful. I can't believe nobody answered the question on account takeovers. I'm still very upset about that. We talked about that the week before, guessing people's passwords or reusing them, stealing them from other sites and reusing them on other sites. You all have that. We talked about that literally the week before. And it's definitely not going to be on the next exam. Cool. Okay, anything else? Our work is going... Yeah, both of them said it hit much weak. Yeah, you have to be there to get it. Yeah, I was there. Okay, then you got it. That's it, and we're not going to talk about it anymore. Yeah. Do you have any advice for the last one, the customer? Ashley? Nope. You've seen my good notes on the piazza, right? Yeah, no. When I see a post, I hit good note when I agree with the student's answer. So, you should be looking at those things. I don't feel like I need to contribute because you're helping each other think about the assignment, which is perfect. Cool. All right, let's continue on with networking. So, we talked about IP. So, what is basically the purpose of the IP layer in networking? Do we need more lights on? Why is there that third row of lights? Is that half out, or am I just can't see? All right, nails. I feel like there's like four dark spots in the room. All right, nobody cares. All right. Cool. So, what's the IP? What is the IP for? What is the internet protocol? Yep. What is it for roughly? What does it kind of do? I don't know, anything about it to help dark memories. A series of protocols to solve practical problems transferring data? What does that mean? Just a way to transfer data. Right, so a way to, not even just transfer data, I mean that's part of it, but it's also how do you even address where does that data go? How do you refer to another machine? Right, these are core problems that need to be solved of how you can transfer data or information from one machine to another on the network. Anything else that we talked about? Yeah. You said it was the glue or the internet. Yeah, the glue, so it's kind of, it's very critical and that's kind of why we're starting here at this layer rather than just building top down or, top down or bottom up. It's kind of thinking through that way. So, yeah, this is something we talked about. So the ID protocol is where C gives very little guarantees. In fact, I'd probably say almost no guarantees in this sense. So there's nothing that guarantees that the data that you send actually regets to the other side. There's no guarantee that what you send is actually what's received by the other side. There's no guarantee that if you send things A, B, and C that the other side will receive them in A, B, and C. They could be C, B, A. Or they could be duplicated and you get A, A, C, B, B, or maybe N not something else. So all these things are basically not guaranteed by the network itself. And, but the cool thing that it does allow is that we can exchange datagrams or we'll think about those as just some packet or some piece of information that we don't really care what it is too much. We can exchange that between any two nodes provided they have an IP address. So this kind of, this is really why it's that glue because without this layer, you can't possibly communicate between two nodes in the internet, right? So, but the cool thing is, as long as you both have IP addresses, you can then talk to each other using this protocol or you can try to send data from one side to the other. Questions? Yeah. So is it like a good thing that it doesn't have all those guarantees or is that a bad thing? I don't know. What do you think? I mean, that's why I asked. Because the way, so initially you were like, this is bad because it doesn't do any of these things that we would like. But then also you're saying sort of that it has to be flexible because of its role, I guess, in the suite. So the way I think about it is it's not, some of these things would be nice, right? For a lot of applications. The question you have to think about is every application that you're building where you want to transfer data from one point to the other doesn't need every single one of these things. And the answer is probably not. And they may need some combination of these things so that they can potentially build these things on top of each other. And to say, to do integrity, integrity would probably be the only one that I'd say would have been really nice to have. But even then, you don't really get that. So that's okay. But you can build that up in other layers basically. So I'd say it's an interesting design. It's probably the way I kind of think about it. It's good in terms of flexibility. It's bad in terms of, well, if you want these things, you may need to do them yourself, which can cause problems. Cool. And so basically, so this is what we talked about with the low level, like link layer protocols of how things actually talk to each other. There's a number of them. We've talked about them. So we'll look at and the view of things. So what's an RFC? Request for comments. What does that mean? It's not like a Facebook post where you're asking for people to comment on it. So I'd say that's what the request for comments part comes in. It's some group of authors comes together, writes up a specification or a protocol or a specification of a protocol and says here's how. So if you look up RFC 791, this will tell you exactly how IP works. And it will tell you exactly what an IP or a datagram looks like. Everything I'm going to show you comes directly from these RFCs. So this is again part of the, there's no magic here in anything that's going on. You can go download these RFCs. They're even text files. They're not even fancy word docs or PDFs. So it's all ASCII. You can read and understand exactly what's going on for this protocol and how it works. And so this is really important when you think about understanding a different protocol. If you're finding some new protocol, you don't know how it works. If you look it up and it has an RFC, you can read through and understand how it works. Of course, you have to deal with sometimes the length of these. Do you remember how long the HTTP spec is? I don't think I'm going to make them do that. So in my grad class, yeah, I make them implement a HTTP11 compliant web server in C with no libraries. And so by reading the RFC, it's not crazy, but it is a 150-200 page document, roughly. But it's part of it is reading it and learning which things apply to what you want to do and which things don't, right? Because it's a HTTP that defines both the client and the server. And so if you're only doing a server, you only need to concern yourself with those things that you must do to make an HTTP 1.1 compliant spec or server. So when we think about it, so what we're going to diagram here, we're going to look at what do the bytes on what actually gets sent as part of an IP datagram. So let's think through and try to engineer this ourselves. We're thinking, okay, we need some way to... So what needs to go in here if we think about it in terms of that way? So before we start digging in and see how they built it, we should check and see how would we build it or what things need to go in there, yeah. Where is it going? Where is it going? So you need the destination address? What else? What else is going on? The type of data? Maybe the type of data? Maybe somebody wants to know, what types would you go in? Okay, maybe types of data and maybe that would... I don't know. That could be useful in the sense of maybe if it's a video, you'd want to route that over different links than if it's a HTML document or something like that. You could view that, yeah. Where it's going and where it came from all in terms of... And how many bits do we need to represent those information? How big are IPv4 addresses, yeah? What do you say? Okay. How much actually do we need? We need 32 bits. Yeah, so we need 32 bits per address. So we need 32 bits for the source IP address and 32 bits for destination IP address. Awesome. Cool, what else do we need? Yeah. Is this assuming we're giving IPv4? Yes, everything we're going to be talking about is IPv4. Yeah, so when we talk about IP, we're talking about IPv4. So what else do we need? We need maybe something to do with types, source IP, destination IP, what else? Maybe encryption? This was done way before they'd actually thought about encryption, so there's absolutely no encryption. So it's like going back to that analogy, it's much more like a postcard than it is an envelope that you're sending. Yeah. The actual data itself. You need the data. You need somewhere to put the data. What else do you need? Protocol. What do you mean? Protocol to send the data. Say it again? Protocol that you're using to send this over. So it kind of goes back to the types maybe. So right now I'm thinking about the type of the data, maybe the protocol that you're using. I was going to say like a way to package up the data. A way to package up, in what sense? Yeah, so like, I know that they use headers and bodies for data packets. So yeah, so the question is, I guess, what are we sending and how much information should we care about what we're sending? What's one thing we absolutely need to know about the data that we're sending? Where it's going. Where it's going? So that's in the source IP address. What was that? Where it's from. Where it's from? Our IP address? What type of data? We don't care what type it is. What was that? We need the data itself, and we need one more thing. Eh, maybe. We'll see about that. Yeah. The length of the data? The length. Why do we need the length? Because we need to know how many datagrams we'll need or how big the datagram will be. Yeah, we need to figure out how long this thing's going to be, right? We're sending a piece of information, right? Computers need to know, okay, how many bytes do I expect this data to be? Right? Otherwise, we'd have to come up with some way of indicating when we've read the end of the IP datagram that then how can we distinguish that from the data itself? So you have this complex problem of encoding. So we need to know the length of the data as well. Cool. So these are actually all types of things that we have in there. So actually, the first thing that you always want, and this is an important point if you're ever designing some kind of protocol, why do you want the version to be the first thing? You can update the spec. So you can update the spec in what sense? Be elaborate. So that if the standard changes, you immediately know how to interpret the data. Yeah, so this will tell you, right? The very first, these are all bits, so the first four bits tell you what version of IP this is. And so the very first thing you read will tell you, do you interpret the rest of this as an IPv4 packet or an IPv6 packet or IP7 or 5 or, I don't know, any of the other ones. Right? So having that version number is an incredibly important thing. So what happens if you didn't have that version number? You'd have to read the entire thing. You have to read the whole thing and have to interpret from context clues what version it means. But again, these are all just bytes, right? These are all just bits, one and zero. So without being explicitly told what version it is, this is a good thing in general. If you're designing pretty much any type of API, even like a web rest API, it's good to put the version in the URL, so that way you know exactly. And you can upgrade versions just like we talked about and people can deal with that. All right, so we have, I believe this is the header length. So this will tell us how much of the information is headers. So when we think about this, at a broad level, we have two different types of things we need to send in parts. We have kind of the metadata, and the data that we want to send. So we call this kind of the header information of the packet, which has things that we talked about of IP source, IP destination. So there's other stuff in here, the total length of the packet. So I believe this has the total length in there, in bytes of the packet. We have an identifier, which we'll get into later about how that's used. We have various flags that we can set. We do run into this problem where I believe the... Well, anyways, we'll get into it later. So we have a value that we didn't talk about. Are we talking about the time to live? No, we didn't. Okay, so we'll talk about that in a second when we talk about routing. We have the protocol. So this does actually tell us a little bit about there. We have a header to check some. So you mentioned check some over here. What is the check some for? We're finding that no errors occurred in the data. Yeah, so what does the check some actually do? I'm not quite sure how it works, but I know it adds up the values in a way. If you do that same operation on the data, you should get the same check some as you apply the hash. Yeah, so it's kind of a way of checking that you could think of it as a bad hash in some sense. So it's not a cryptographically secure hash for a number of reasons. But if you take, and I actually don't remember the operation either, it's not actually very important, but the idea is you're able to verify that all the bits are roughly the same so that if there's a random bit flip, you'll be able to tell the check some fails. However, you can get it in an instance where bit flips occur, like you have two bit flips that occur in opposite directions and your check some passes, even though the header is not okay and this is what you get with not using the cryptographically hash, yes. How often is that checked throughout the process? Is it just at the end point or at every stage? And I think datagram, I believe, would be checked every hop. But this thing, I don't actually know. I'm guessing basically how it's used. So I think it'd be up to kind of each switch to check that if they were going to. That's interesting. They do, oh, yes, it must be because so as we'll see every switch is updating this time to live packet, which means they need to recalculate this header check some. I guess I suppose they could not check, but if you're already doing that, why not check? Why continue on a packet where you know it's got bad? Of course the destination's down. So if the check some doesn't match, what do we do with the packet? I'd drop it. I would just drop it because you'd say this is not, because you don't know what flipped, right? What if the source IP or the destination IP changed? What? The packet's not going to the right place. Anything in here flipped wrong or the length changes? That messes everything up. So yeah, better to just chuck it and then you get the unreliability. So there's options that get set. Patting, so that way you're always on a 32-bit boundary. And finally then the data that gets set. So we have all this additional, you can think of this as like all of the operation that's on the envelope in order to make sure this data goes from the source IP address to the destination IP address. And you can basically get these diagrams, like I said, for every single protocol. So it's very cool to just look at them and see, okay, this is exactly how these bits work. So if you were, I don't know, dropped out of desert island and needs to craft IP data grams by hand, if you could do that. It would actually work. Not useful. Okay. So what's going to happen to this IP datagram packet? So when this gets sent, so we talked for a bit about our good friend. There we go. Okay. So we talked about unplug it, unplug it back in. Hey, there we go actually. Use, why do I need to do that? I have no idea. Okay, so we just saw in this packet, so we just saw that we have a source IP, destination IP. So going back to what we talked about, so we have a destination IP, we're machine A. We're connected to some switch, which is connected to some switch, which is connected to, let's say B is over here and just make things confusing, C will be right here. Okay. So we're machine A. We want to send out a packet. So how do I know where that packet goes? Where should A send the packet? To the destination IP. Look at the destination IP and do what? It's the hop, the switch. Nope. That's all the information that's what we talked about. I know it's about a week and a half or two weeks or something, so I'm not judging. DNS servers? Not DNS, because it's all IP addresses right now, so it's got a source IP and destination IP. Yeah. What's that to do with the subnet? The subnet or the, yeah. So we really can't even answer that question without knowing what actually is the destination IP and what's our source IP with our subnet. So let's say we're going to be in the 10 network, 10-0-0-0-slash-16. So we are, we'll go with our IP address is slash 1. C is 10-0-0-0-2 slash 16. The gateway or the switch will be 10-0-0-3-16. And B will be 10-0. I can't do that. 10-1-0-0-slash-16. Okay. Cool. All right. So let's say the destination IP is 10-0-0-2. So where A, our IP address is 10-0-0-1, is this IP address, the destination IP address, in our local network? Yes, why? Or no? The first 16 bits are the same. So the first 16 bits are the same. So we look at our IP address, we say the first 16 bits are 10, well, decimal representations of 10 and 0. And the destination, the first 16 bits are 10 and 0. So it's a local IP address. I guess when we say the first, we mean the uppermost, right? That makes sense. Cool. So it's a local. So do I need to send this out on any other hops? No, it's on my local network. So I can just send this to 10-0-0-2. How does the packet actually get from A to C? Through what? Not quite. So that would be a better answer for A to B. So going from A to B, we need to go through routers because we need several hops because B is not in our subnet. We are? Can you pass it over to the internet frame? So we need some way to communicate that locally to this machine. So even though it looks slightly confusing, which I understand because we have A and C, so we're going to consider this one hop because we'll see exactly how the packets get there. But fundamentally, we need to encapsulate that IP address into a link, sorry, that IP packet into a link layer packet so that it can go from A to C on our local network. So you can think of the link layer deals with how do I get packets from one point to another in my local network? So it could be either a machine connected on a switch or to the gateway, which I realize this may be, or maybe I'll change this slightly. Let's go like this. N1003, which is also connected there. So on this thing, that's IP address, and on this, let's say it's N103. Definitely made things more confusing, but that's okay. We'll deal with it. So the whole thing is going down a layer, essentially. Just like we had on our IP data, Graham, we had the IP data and we had an IP header. We're going to essentially put that. That is the data we want to send for the link layer. So the link layer, we'll talk about this in terms of frames, but it's basically kind of the same concept. You have some header and then the data, and the very first part of that header, sorry, the very first part of that data is your IP header, which is your IP data, and as we'll see when we go up, there's headers in here that tell you more about that. So just like we said, okay, we have two hosts. They're in the same physical network. Why do we know they're in the same physical network? Yeah, we checked those same bits. They're in the same subnetwork. They're in the same physical network. So we can deliver this data directly in IP. So exactly the same example, but we need to know now, we've been talking about IP level addresses, but now we're moving down to the more the link layer, and so we need to know these physical addresses of how to send these packets. And now we need to go one step below and look at what an Ethernet frame is. So like I mentioned earlier, this actually depends on what the physical, there's different link layer protocols depending on what you're actually doing. We'll look at Ethernet because it's, I think the most standard that you're going to experience. So this is in terms of bytes rather than bits. So the Ethernet frame first, so again, exactly the same concepts we talked about. We have a source link address, a destination link address, and these all have to be present in the header. So we have six bytes for our destination address, six bytes for our source address, two bytes for the type, and then the data which can be up to, and finally at the very end we have our CRC checksum again to do. So we actually have another checksum at this level. So the different types here are important because this is going to explain how this thing actually works. So the easiest one is this type in the hex 0800, I don't know if I can memorize that, I don't know that. So this means that the data is an IP datagram, and we have other types here of our request or reverse our request. So the whole idea is we need to now look at how does Ethernet work, so we looked at that packet. So if you've seen an address like this, addresses are written in this decimal note, or this colon separate notation that represents 48 bits. Everyone seen that? Where have you seen that? Yeah, where, like a maximum. So a MAC address, but where? Just like on a wall somewhere? Yeah. So like a sticker on a device? What else? Yeah, so you can look at, maybe ifconfig does that, IP address. I think it's IP con in Windows, is that right? Yeah, so all those will tell you what the specific MAC address is of your computer. And that is, man, I don't have a, oh, there we go, cool. So this is a USB-C to Ethernet port, so this is probably the most best representation of this. So this IP address, this physical device has a specific MAC address that's going to be different than other devices on the network. They're more or less randomly assigned, but you can change them, but that's not really that important. But it's enough bits that you're highly unlikely to have a collision in terms of MAC addresses. And similarly, so the source address is 48 bits, and so, yeah, okay, perfect, that's what I thought. Okay, so you need at least, you know, you can send between 46 or 1500 bytes in here, and there's the CRC check. So going back to our example, so we have computer A, it has an IP data, it has an IP packet it's trying to send, which consists of some data, source IP, destination IP, and we know this is, and I'm going to harp on this again, but we know this is a local delivery, so we know this is a single hop, so we know this destination IP exists on our network. So when we construct the Ethernet frame that this is going to live in, what do I need here to be able to send this on Ethernet? The source MAC address. Yeah, so I need, we'll call it MACS, like the source MAC address, do I know my source MAC address? Yes, you have the physical thing there. What else do I need? The destination MAC address. The destination MAC address, we'll call it MACD right now. How do I know what the destination MAC address is? Looking at these headers, what information do I know? So we just said we know the source MAC address, because that's our MAC address, we know that for a fact. What else do we know for certain? We know their IP, can we use their IP? We know their IP, why do we know their IP? Somebody asked us to send this IP packet to this IP address, that's where we got that IP address from. Cool, what else do we know? Not what we do not. Do we know our gateways? We know our gateway, but we don't need our gateways, this is a local, so we're just sending data to our local network so the gateway is not involved. What else do we need, what else do we know in here? IP address? Our own IP address, our source IP address. Yes, this is a not-trick question, right? We know our source IP, we know the destination IP we want this to go to, we know our source MAC address, but fundamentally we don't know the destination's MAC address. And going back to the layering of all these stacks, this is where I mentioned that these layers get blurry, because I want to send this IP packet, but in order to actually send that, I need to send a link layer ethernet packet, but in order to do that I need to know the destination's MAC address, so should we just know, create this MAC, why have differences between MAC addresses and IP addresses? You can change your network, but your MAC address maybe remains the same in terms of this link layer. You maybe want to wholesale change this link layer, maybe 48 bits isn't enough, maybe you want huge, or think about it from first way, they upgraded IPv6 but left ethernet alone, so they could upgrade this layer without this layer, but there needs to be some way to translate between the layers, and specifically what piece of data do we need to be able to translate? No. Can it be IP address? What's address? IP address? We have four different addresses. Destination MAC address, destination IP, destination MAC. Yeah, we need to map, figure out from this destination IP, who has that MAC address, where should we send that on the ethernet level? So this is where you get some blurring between these layers, because you have an IP address that you need to map to a MAC address. And the easiest way to do this is to just ask. You ask the whole network, hey, who has this IP address? I need to talk to this IP address. And then if everybody's listening, they can respond, whoever has that IP address says, hey, I have this MAC address and I have that IP address. So this is everything that happens. So this is, in essence, all that ARPIC is. Oh, how will I ever find this? There? Okay, so that is, now, again, you need another protocol. So you can look up, I'm sure I actually don't have the RFC here. I'm sure it's another RFC for what ARP is. But basically, you can think of it as answering this question of, I have a destination IP address. What is the MAC address associated with that? So I can send out a packet over ethernet. And so there's a few things we need. So we actually have a really interesting conundrum. Okay, so here's machine A. Its IP address is 10-001. We have machine C. Its IP is 10-002. A wants to send a packet to a destination IP of 10-002. It knows it's on its local network because of the slash 16 here and it knows it's on its local subnet. So that's all fine. But it needs to know that destination address. But how does it ask who has this IP address if it doesn't know who to ask? Have the gateway asked? So the way to think about it is what we're operating on now, we actually don't care about gateways at all. There's no gateways. We just yell at everyone. Yell at everyone. So who is IP 10-002? You ask the entire network. So there's a... So basically an ARP. So ARP is going to have two basic forms. So the ARP request will say basically who has 10-002. And it will send that out on a broadcast address which I believe is all ones. So it would be FFFFFF whatever 48 bits of one is. And that means it goes to everyone on the subnet, on that local network. So when a switch gets... Think of it in terms of switches, right? Switches have ports. So when it gets in an ARP request on one port, it sends it out on every other port. And then every single machine on that network should get that message of who has this IP address. And then the machine who has that IP address will respond and they will say, now is this a broadcast? No, why not? Because you know who's sent it. Yeah, so you have a packet, right? It's just like we talked about. You have a letter from somebody. You had to ask... Essentially you can think about, like, I don't know, everyone in the building, who's this name? Or like, if I had to do that, I guess... I don't think I've ever had to do that. But if somebody didn't put their name on there, it would be a term or something. And I had to be like... Or maybe just their first name. I don't know. But the idea is you get this broadcast request. I went to everyone. You are 1002, so you say, I am 1002. And I'm at... MAC address, we'll call it C, because C is that machine. And you'll send that directly, basically... from MACC to who? The person that made the request. And now, machine A knows, aha, 1002 maps to this MAC address. Now they can actually send the packet that they were originally going to send to that machine. What do they do in case another packet comes in? So now there's a new packet. I want to make a new request to 1002. Or send a new packet to 1002. Because they know the MAC address before. So I think that it depends. So you could keep track of this. So you could cache this in the computer and say, aha, now A knows 1002 is at MACC. And so there's any more requests. But what happens if that machine gets unplugged or maybe they change from wireless to Wi-Fi or something on your network? You can still have the same IP address without having that MAC address. So you still need to deal with that. But essentially... So if you think about it, it's kind of crazy. I mean, you have to have some kind of sort of caching in here. Your performance would be terrible. Every packet you tried to send, you had to ask the entire network, who has this IP address? I think... let's look at... I have no idea if I'm actually on the network. Why is this taking so long? There you go. Okay, cool. I'm on the network. Okay, so I can see I am on... My IP address is 10152. Can you read this in the back? Yeah, I'll make it bigger just in case. Okay, 1052894. And the net mask here is a little weird. I'm not sure why they do it like this. But you can see all the ones are all of the bits there that tell me my net mask. And what else? Oh, my Ethernet address. So my Ethernet address on this machine is apparently whatever this value is. And I can... I don't have TCP. So I can run a... basically a sniffer on my... my physical device. So EN0 is my physical Wi-Fi device. So I'll just listen for any ARP packets on there. I'm not sure if this will work. Okay, and it should... That's crazy. It's not helpful. Okay. Okay, so I put a filter on there, I think, to do just ARP requests. So what was my IP address again? So I can try to do... This is my gateway. So this is me sending an ARP request to say who has... Oh, there we go. Cool. 1052894. So who's at this IP address? Tell 1052894. All right. Who's at E5? Tell 904. And then I'm not getting any replies. I just made up some address that doesn't exist. But we can see I'm actually getting replies. I'm seeing replies from other machines. Oh, it's Netsat. Netsat and our... There's my gateway. Yeah, that's why I told me to just... All right. That was... I thought there'd be a lot more. Whatever. I'll just let this run and we'll check it later. And so here's kind of another example of this thing where we have two, three hosts on a network, A, B, and C. You can see there are different IP addresses. One is... The whole network is 192.168.1. This is .100 and this is .10. And so from host aid, the other thing you can do on a Linux machine, you can check the ARP cache. Let's just see if I can do this online. Yeah, okay, perfect. So this shows me the ARP table of my machine, so it shows me the current mapping of IP address to Ethernet address, to MAC address. So you can see all of the addresses on there. And you can do the same thing here. So now we're going to send... We'll see what a ping exactly is later, but we're on host aid. We're going to ping 192.168.1.10, which essentially means we want to send an IP packet. We need to figure out... We know that there's nothing in our ARP tables, so we've cached nothing. We don't know anything about this network, so we need to make an ARP request. So we'll see an ARP request. This is exactly the same output that we were looking at before with TCP dump, where it'll be an ARP request, so it's from... And this is... Everything here is coming exactly from this diagram. So the source Ethernet frame here, 80467483, is matching exactly host aid. So you can see the destination is all Fs, which is all ones at the broadcast address that means this request goes everywhere. Who has .10 tell .100? So this will go out to every machine on the network. Host B will then reply and say, this is from this IP address... Sorry, this MAC address to this MAC address. .10 is at this MAC address. And then finally, the IP packets can start flowing. So these are different IP packets that are sent. And now on both machines, we can check that there aren't tables they actually know about each other. So this means that... What does this mean that host B is doing during this communication? So host B also cached host A's MAC address? Yeah, so host B, why? Because... So that knows where to send... How did it do that? It sent the source MAC address. Yeah, so in this broadcast message, it has all the information about what... So this means that .100 is at this MAC address. So actually, everyone who receives that can update their tables to see, oh, this actually is this person. So you can actually keep track of things that way. Yeah. Are those, like, dropped after a while? What do you think? I would imagine they would be held indefinitely. Why? A lot of space. Space? Why else? They can change. They can change or get stale, right? Or machines could drop off. Like, if you think about ASU's network, on the Wi-Fi, there's all the machines connected to the Wi-Fi. If you're keeping track of all the machines on that network, that would just go insane, right? So then you got to worry about duplicate entries, maybe over a long period of time, after one machine disconnects, it comes back that they reused that IP address to that new machine. So, yeah, so yes, definitely. The exact values are definitely operating system-dependent. And you can even flush... I can't remember. I think it's R-F, I think, if you run it with, it has root will flush your IP tables to give you fresh IP tables. So, if host C has the host B's MAC address in its ARP table, can it reply back? Or is it only directed at host B that host B will reply back? Okay, let's think about that in a... Let's flip that in a different way. Let's think about this from host... Well, first, we'll go back to this diagram and do it from host C's perspective. So, C gets a broadcast request. What does it know about that? Well, I'll go. Actually, maybe it'll be better to... Oops. Yeah, it's a good question. Okay, so, here. So, host B gets this ARP request. What can it trust from the data that it received from this packet? Yeah, maybe that it came from host A. That it came from host A? How? What's in that packet? Yeah, so there's a source MAC address, the destination, which is everybody, and then this IP and this IP. So it's not going to be the same source IP. But who's enforcing that source MAC address and those IP addresses are correct? Protocol, yeah. Protocol, yes. The protocol does do that. Should we trust protocols and what they... Nothing right now. Nothing, man in the middle of the time. Yeah, so nothing from what we've seen in this diagram or anything in here. So then let's think about this reply. This is a roundabout way to answer that question. So we think about this reply. Host A gets this reply. What do they know? And we can see this reply here. Source MAC, destination MAC, the IP they were asking for, and the MAC address. What do they now know? So what can they trust about that reply? Their own MAC address? They can trust their own MAC address, why? Because it's their MAC address. Yeah, the destination, right? The packet is getting to them. They could definitely check that that's actually the same. What about the rest of the data? It thinks it came from B. It thinks it came from B, but can it trust that it actually came from B? We know at least that it did get to a IP address that matches the one we sent out initially. Okay, good. So we do know that this is a response to a request that we made, at least, right? That's pretty much the one thing we can hold our hat on. We don't actually know what machine it came from. If it came from C, so it kind of goes back. Who asked that question? Okay, you asked that? Oh, thanks. Sorry. About could C respond for B? So by the protocol, no. So if you're following a protocol, you'd only respond to our request for your IP address only. And it makes sense why you'd have massive havoc happening. Let's say you reply, but this plug gets pulled. Like, why would you be replying for a machine that's down if you don't know it's now? It's just the network. You don't know the state of other machines on the network. But more fundamentally, there's nothing in any of this that is stopping C from applying as if they were B, which feeds very nicely into local area network attacks which is what we're going to talk about, of how we can basically take advantage of this trust that is inherent in the protocols on local networks to cause havoc. And this is still a problem in most networks and most systems. So what do we want to do? So we're attackers. We want to think through this. So when we say local area network, what does that mean? So your apartment Wi-Fi? Yes. That's a good example. What else? If you're ready, like ASU, perhaps, like any machine types of network? Yeah, maybe ASU's Wi-Fi or all the ethernet networks. So we've talked specifically, we're talking local area network. It means we're on the same subnet as, how much damage can we cause if we're on the same subnet as other people? So we're not really concerned at this point with multiple hot attacks or trying to do anything like that. We're just worried. We're thinking about our local network. So what are our goals? I want somebody to remember here. Andy was good about making sure both sides. Personally, I'm someone else. Why is that useful for us? Yeah, so maybe, so in a lot of networks, there can be IP-based trust relationships between hosts. So you can do, in a, let's say, like a web environment, you could have access to the database only through from certain IP addresses. So if you can spoof and pretend to be an IP address, then you may be able to do that. So we may want to be able to impersonate machines on the network. What else? Getting onto the network? Say it again? So do you want to get onto the network? Getting onto the network? We'll say we're already on the network, but how do we get there? Put on your attacker hats. Plug in. Yeah, wait, just like that. You plug in. Yeah, by the way, physically plug in. How else? Log into the Wi-Fi. Log into the Wi-Fi. Guess the password. Or just log in because they have guest accounts. Yeah. Get into, break into a server. So you can maybe password guess or do other things we've talked about to break into a server that's on their local network. Yeah. Social engineer to pretend to be someone that they trust in order to get those credentials to log into the server remotely or system remotely. What else? Yeah, if they have a device laying around, you can use that. Device laying around? In what sense? Like, they have like a laptop that isn't like, is it password protected and it's connected to the same network? Yeah. So you could use a machine that they already have that's connected to the network. What about tricking somebody inside that network to install your piece of malware? Then you now have control over a machine in that network which is very similar to the guessing passwords, all these kind of things. Ask. You just ask for the password of the network. The Wi-Fi. So some of these attacks will differ depending on the specific if you're on Wi-Fi. Wi-Fi routers behave a little differently than switches and routers and hubs, but we'll talk about that. Okay, so we want to impersonate people. We want to get connected to the network but we're pretty sure we can get connected. What else? Think about your, sorry, another thing, your phone. So if you're connecting your phone to your work or corporate network and then you install my app, that's a flashlight app but actually is scanning your corporate network and doing all these kind of attacks, that's possible. So what else do we want to do? Want to impersonate? Listen. Listen? Why do we want to listen? Is listening important? Think to ask into the older class. So people are going to say, yes, they're already listening and the people that would say no are not listening. So if you listen to the traffic, you can understand what other people are talking about and maybe intercept some confidential data. Yeah, so we may not even want to impersonate a host. We may just want to listen in on the communication so that we can maybe steal username passwords that are being sent in the clear. We may want to be able to steal documents and data and emails and anything that's kind of happening on that network. I was also going to say something else that we want to do is intercept, not impersonate someone, not to get the data or to like spoof into something, but just so that they don't get it. Okay, so maybe availability, right? So these go back to all the things that we were talking about. Confidentiality, integrity, and availability, right? Yeah. We could try and destroy the network entirely. Yes. Yeah, and when would we want to do that? Because they can't get their data. They can't speak to you. Like a real scenario. What is that beneficial to an attacker? A bomb threat? In what sense? In like, say, there's like a community thing and it requires a bomb threat. Nice. Okay, good. Yeah, so that's, so yeah, another way I think about is like when you're going to rob a bank, you would really want their network to be down so they can't call out or do anything, right? That would be another instance. Or you're going to try to steal information. Maybe you shut down the network of their security team while you're like in their network stealing stuff. Yeah. You probably use it as ransom, too. Yeah, you could take down their network and send them a thing saying if you don't, your network will come back up and you send 20 bitcoins to this address. Yeah. Even just taking down like email services for some organizations could be millions of dollars. Exactly. Yeah, yeah. Yeah. People have trolled others online. Troll? So in what sense? Can you? Like, say you're on the game, some of these gasses, get rid of your network. Yeah, so similar type of things. Like shutting down network. Maybe it's for revenge. Maybe it's a corporate revenge or a petty online game revenge. So these are all kind of the goals that we want to think about when we think about our local area network attacker. We want to impersonate hosts, denial of service, access information, maybe tampering. And it kind of, the three things. And the other thing we didn't talk about is maybe we want to inject fake information into these networks. Right? And so I think of it in kind of three ways of sniffing. So we want to sniff and learn what is being sent on this network. We may want to spoof traffic, or spoofing is essentially an impersonation we talked about, pretending to be another system on the network. And hijacking would be basically hijacking communication between two systems and performing basically a man in the middle and injecting your own information there. So this could be good, you know, if you think about, I don't know, I like many Heising movies. I think they're a good analogy to think about. But this could also be kind of, maybe the hijacking is getting on their, like get intercepting all of their emails. That way when somebody says, hey, I saw a weird alert on machine seven. So you intercept that and either delete it or change it to say maybe different machines and send them on a wild goose chase or whatever you can do to try to confuse and confound your target here. So we're going to see how, and we've really only looked at kind of two protocols, right, IP and Ethernet. And we'll see how that combination along with local area networks is how you can carry out all of these attacks essentially. The first thing we need to talk about is the difference between hubs versus switches. So has anybody ever used a hub? Has anybody used a switch? What is the difference between them? I can switch everyone by switches specific to when it knows like the back address. Yeah, so hubs are incredibly dumb. They look exactly the same. I mean, they're just like, you know, whatever machine switch, whatever, you want to think about it with different ports. So the idea with a hub is every, when a packet comes in on one port, it's very dumb, it just sends that packet out to every other port. Why is that useful for our goals when you just snip or any open port? You just listen to every traffic, right? So you think if the hub is sending out every packet that comes in to your device, all you have to do is snip every packet that's coming into your device, because normally your network interface, the NIC will drop all packets that aren't destined for its back address. But that's just an operating system thing. You can easily change that. You'll see it's called Permissuous Mode of looking at all packets that are destined on this physical device so you can see everything. So it's a super easy way to snip on local area networks. If you're on a hub, it's incredibly easy. So, we'll think about this. So how does a switch work then? So a switch is smarter. How smart is it? Okay, it's going to be a terrible drawing. Bear with me. These are all ports. Okay, connected to this port. We have C. So, and it's unlike a hub. So in a hub mode, A sends a packet out to C, and it gets broadcast to every single port. So D will see all of the traffic between A and C. A switch is smarter. How does a switch work? I'm going to be smarter. Let's go back again. It will send a packet specifically to C. How does it know? I have a table and an ARP table. Yes, and how does it create that table? I just always tell before, like you will first create a request then whoever has that IP address will send that IP address and then the table will update itself. Yeah, so essentially you can think of the switches is sniffing all the packets that are going across. And so when A first needs to talk to C, it sends a broadcast packet as we just saw in our request that says who has IPC and C will reply back that says I am with an ARP reply says I am this IP address I have this MAC address. So the switch basically for every single port just has a mapping of what MAC address. So here it would have a table that says MAC C and here it would have a table that says MAC A here would have a table MAC B so it just has exactly a table per port that says exactly so when a packet comes in so when A sends a packet to MAC C it looks up and says okay, which of these ports has the MAC address MAC C oh, port, I don't know, whatever I don't know port's a number, but let's say two sends it out only on this link and not on these. Does this protect us from our adversary sniffing on our network? Does it prevent it? No, why not? So think about this if we're D what do we need to do to enable us to receive packets that are meant for MAC C? Just basically say that our MAC is that or more specifically we need to update this table in the switch to say actually MAC C is on port 3 we'll go 1, 2, 3, 4 right? So we want to be able to add well, that's not right I don't even think of the letter this is the problem one I could zoom in but it gets all 3 so we add MAC C to this table now any packet that comes in MAC C if we keep it on hold it's great now we get their packets and so we can trick the switch into giving us their packets so exactly what we talked about all broadcast traffic is sent to everyone but directed traffic is sent to those specific ports based on the MAC address so as we mentioned sniff, yeah so if it's that easy to do it's much faster than just having a switch versus a hub it's much faster so you think about it a hub is limited in bandwidth because every packet that comes in has to go out on every other link and so that you can get collisions there if you're sending as soon as somebody else is sending but this other way it's much faster because the packets only go out on whoever's talking other ways of dealing with it we'll talk about much later when we talk about defending so it's not like all hope is lost cool it's incredibly easy all you have to do is set your network interface to promiscuous mode if you're using switched ethernet then you need to convince the switch to send stuff to you which is very easy so yeah it allows, so by default your your network interface like both Wi-Fi and physical like whatever ethernet port we'll say will reject and not send any packets to your operating system that aren't destined for your MAC address or a broadcast address so you need to enable something basically in the device that says send me everything I don't care what the destination MAC address is, send it to me so the trick then is if we're on a switched ethernet how do we actually intercept that traffic and we'll look at that in a minute but first why do we want to snip so we talk about that as high level goals an idea of what we're working with on the network so you can figure out one way would be maybe reconnaissance and figuring out what are the different systems on the network this may be able to help you understand what's an admin machine versus I don't know a marketing machine so you want to get on the admins computer because that will allow you more access through the network what else what they use say again figuring out what they use the most on the network so you can start coming up with a list of things to attack on the network yeah so exactly so part of reconnaissance right understanding the services that are on the network how valuable they are so you can prioritize your list of what to attack if they're sending valuable information in like plain text or the good packets you can intercept that yeah for sure so a lot of protocols at the higher level this is just a kind of list FTP POP, HDP, IMAP they all transmit authentication information in the clear those means as long as you can read that data and that information and we saw IP provides no encryption or anything like that we'll see even far enough of the stack TCP doesn't offer that at all so a lot of these protocols so what do you use FTP or what do people use FTP for transferring files or like updating web servers I was doing a pentest one we were just running a sniff on all outbound traffic and we got their FTP credentials so one of their marketing websites because somebody was using FTP and not either like S the secure FTP which uses an encrypted version sending that in the clear and so they one of the cool things about DEF CON is they there's a a group there they do a thing called the wall of sheep so they sniff all the traffic on the DEF CON network and they put a big list of usernames and passwords that they've stolen from people using a network so and this is trivial they have I may have it in the slide but there's a program you can run that will look for these protocols and pull out usernames and passwords in them so sniffing tools are actually so I'm going to present them in a way that makes them seem I don't know like they're mainly used for hacking or whatever or like network sniffing and doing this kind of reconnaissance and it's true you can use them for that but honestly I use them much more to like do shooting in networks if you're ever wondering I don't know you'll get into a point where you're building like a complex network or system and you'll be like why aren't packets getting from this host to the other host so you go to every system in between and you TCP dump on every single port to trace the packets I have this craziness happen in my lab where our connection would go like up and down every 20 or 30 minutes I couldn't figure out what was going wrong so I had to run TCP dump on a number of machines and then set up a number of like pings and trace routes going to like map the network to show the networking people of ASU like something insane is happening and it's not my fault everything's leaving the lab fine it's something on your end or oh man one time I set up a system for like a web security hacking challenge that was living within ASU's network it was going just fine scripting exploit like the request hung and so I had to sniff all the things to figure out where it was hanging and it turned out it was a ASU web application firewall that was blocking my request coming in so it was never getting to my servers but I would not have known that without this so this is you can really kind of step up your network analysis by getting familiar with these tools so you can actually see what's going on on the network I'm a big fan of the command line tools so there's TCP dump which is a great tool that just collects traffic usually you want to dump it to a file because it's a little bit annoying to just keep having all this output which maybe if we see here yeah so we can see all of these oh so here so you can actually see here what's the time out of my ARP cache based on these results roughly oh maybe I misinterpreted and you can figure it's like roughly a minute 45 or something in between these packets yeah 3 so 130 it looks like anyways so you can look at the replies between here because this is my gateway but anyways other cool tools TCP flow you can use TCP replay to replay a connection against another system so you can say hey take this traffic I'm going to record it from A and B and send it from me to C which is kind of cool Wireshark is the popular open source graphical tool it is actually super awesome because it supports a number of parsers for a lot of different protocols so it can show you nicely the traffic one of the funny things about Wireshark is this is basically how people in like DEF CON CTF will analyze network traffic to try to steal exploits and so what people do is before the competition they'll find a vulnerability in Wireshark so that when they send traffic it will cause Wireshark to crash and they'll flood the network with those packets so nobody can use Wireshark at the network traffic okay and alright we'll stop here because our spoofing is a little bit long topic