 All right, let's get started today. So for those that I haven't seen, so the first homework assignment is up on the website. So assignment one, I have to make this bigger because this is a crazy high screen. OK, so assignment one is going to be due in two weeks before midnight. The first part is incredibly easy. You should have already done this. That should be the easiest 10 points you get in this class. Sign up for the mailing list. Hey, easy 10 points. All right. OK, so the other parts are intended to help you go through some of the stuff we've talked about in class to reinforce some concepts, to make sure you have the skills necessary to be successful in this class. So the first part is you're going to make a program that emulates some of the functionality of the Morris Worm. So it is not the propagation. So the key part of the propagation of the Morris Worm was A, that it had remote code exploitations in SendVail and the FingerData. But it also leveraged the trust between hosts on the network. So it would look for trusted hosts in the network and then use to try to leverage that trust in between them to propagate itself. So you're going to write a program that actually does this discovery or tries to identify these trust issues on a host. So when your programs run, it's going to basically output a list of all the host names known and that are possibly trusted by the currently executing hosts. So it'll be a single executable called discovery. The interface is very simple. You're going to run it. And it's going to look in the locations we've specified to look for new hosts, new and potentially trusted hosts. And you're going to output it one per line. The order doesn't matter. And note that we're specifically looking for host names. Because I think not IP addresses. So host names, in my mind, they're a little bit more likely to be trusted, right, if you've given them a name rather than just an IP address. OK, so here's the four places you'll be looking. ETC hosts, SSH configs, authorized keys, and known hosts. So how do you know how to extract host information from these files? You're using a set of letters of auth. Yeah, but how do you know what to set or rep or auth for it? You mean look into those and see the format of them. Yeah, so I would even say it's not exactly in the files themselves, right? You're looking at the documentation. So this is exactly why I provided links here to all these things, right? What is the specification say a host's file should look like? What are the host names in the host file? So you'll have to write parsers for each of these things to parse and extract the relevant information from each of these file formats. So other things to do, right? So here we want to get the SSH config for each user. Why do we want to do it for each user? Yeah, we want to try and find as many things as possible to try and find as many potentially trusted hosts. How do you find out all the users on the system? So that's true. Hm? Flash users, are they always going to be in there? You can look in like EDC password and... Yeah, you should look in the EDC password file, right, to see users and then you can see the home directory for all the users from there and use that information to then find everybody's config file, author's key, and not a host file. I mean, kind of debated even putting this line in there, but I guess it's better to be explicit, right? You must handle permissions correctly. Your program should not crash just because it can't access a certain user's SSH config file, right? So you should... You know, this is about... You're trying to write a worm, right? You don't want your worm to crash. You want it to run undetected and be very stealthy, right? So crashes attract attention. So we want to have as few crashes as possible. Questions on the goal of this part? So by handling the permission, do you mean the permission that has been set in EDC password file? Yeah, exactly. So... I just mean, handle permissions correctly doesn't crash when you can't read a file or something, right? Or don't have permissions in a directory to read that directory. So that's up to you to make sure that your program is robust, because these are things we're going to check for. Okay. But the... Well, there's a lot of different operating systems out there, so it could be, you know, BSD may do things differently than Linux, which may do things differently than, I don't know, any other UNIX derivative. So we're going to standardize on Ubuntu 14.04.64 bit. So this is going to be our test system and our environment for these assignments and all other assignments and hacking exercises in the course. So if you don't have access to one right now, you should set up a virtual machine to be able to test and develop these things. So program languages, I don't really care what language you write this program in. It can be in whatever you want. Your programs will run on a default version of Ubuntu 14.04.64 bit with the default packages installed. This is a little bit about if you want to use additional packages that aren't installed by default, like, let's say you want to write a Haskell program, which would be really cool. Somebody wants to do that. Then you need to include the GHC, the Haskell compiler, in your packages file, and the submission system will automatically install these packages for you before it runs and tests your program. You also, so submission instructions. So you need to submit your code. You'll need to submit a make file and a readme. So the readme is very simple. It should just contain your name, your ASU ID, the description of how your program works, right? Simple standards for courses. The make file. So who has experience with make files? Everyone who doesn't is, I guess, the opposite of that. Yeah. Who doesn't have experience with make files? All right. Cool. So you're going to learn stuff in this course. Awesome. All right. So I've tasked PSI with finding some resources. So we'll put resources on here for links to learn about make files. Just a series of steps to how to compile your program. At the end result, you should have an executable file called discovery. Whether that's an actual executable file or a shell script that executes your file correctly, whatever, doesn't really matter as long as it works. So this is the interface that you have to specify, right? So what we're going to do to test it is we're going to set up the environment in certain ways, run your program, and compare what you output to that testing environment. Questions on the first part? Yes. How are we going to populate those? Because we're going to install a clean version called we're doing a chance to do this assignment, right? Probably those, what you call, those files are not populated. So we need to populate them, right? So how do you test your software? I need to populate this part. You already test cases, right? So part of that is under, so that actually helps you know because that tests various things. You can say, put a host file in EDC host. You can put host names there. Make sure your program correctly detects those. Then you can put additional host names. There's other optional host name fields in there, right? To test that. So, you know, this will be good for you to test that. You will have... It's not set up yet. Hopefully by Wednesday I'll have it all set up. But there will be an online submission system that will get it and then get feedback about what test cases you're passing and not passing. You'll know right away exactly what your grade is. So that should help. It would be a one-time submission or... It would be a one-time submission or you can submit as many names. Definitely not one time. I don't know. I'm willing to entertain thoughts or arguments. The problem is I don't want people to just submit, make one code change, submit, make a code change, submit, make a good thing, submit. This happens. I'm not to disparage any of you good people. But people in previous classes have done that. So, you know, and this... We have machines that are constantly compiling, testing, all that kind of stuff. So, if the queue fills up with all your submissions then other people, if there's a delay between when they submit, right, then we have a problem. I'm not willing to giving a limit but a higher limit, like maybe 10 or 15 submissions, something like that because I think that would be reasonable because I would give... And I will... The other thing I'll definitely do is I'll let you do an unlimited number of smoke tests which just submit and compile to make sure it actually compiles correctly because that's a key thing, right? So, you don't want to burn your submissions by... If you want the submissions to test the actual functionality, not just if your thing doesn't compile, because your make file didn't make the file executable or something like that. Okay, so the questions over here? Yeah. The one you have mentioned that this could be, that could be executed with, if we write the code in a chance script then still that make file is relevant because that is going to execute great files. Yes, so you got your show scripting and you got your make files do nothing in that case, but you still have to have a make file. The idea is I want standard interfaces to take your code from source code to executable, so, yeah. So the make file will have the executable like now slash in this code you are... Make file is just a file and then you call make, you run the make command in that directory and it has to make sure that there is a file called discovery and that discovery is executable. Other questions? Comments? Cerns? So, the second part of the last, I guess the last part, I think it was the second part because you are going to make the list. You should be doing that already. Okay, the idea is you are a hacker when you break into a system, right, so you use certain vulnerabilities to get in, but, you know, if you want to come back to that system at a later point in time, you maybe don't want to re-exploit those same vulnerabilities over and over because what if they update the operating system or what if, I don't know, maybe that's more noisy and they are more likely to be discovered. So you are creating a web server in quotes. So this will be a real web server, so you will implement the minimal amount of functionality for the HTTP 1.1 spec. But it will be this web server will actually be a backdoor that will allow you to execute commands remotely on that machine. So why are web servers really good as backdoors? The ports are really popular? Yeah, port 80, what are the ports? 80 and port 43 is HTTPS, right? So, almost every firewall in existence will allow access to or from those ports because, you know, web traffic makes up the bulk of the volume of traffic, right? So yeah, that's definitely one reason or some other reasons. I guess they are all kind of related, right? So yeah, the network administrators looking at traffic and they see a bunch of connections on a weird port like, I don't know, 1-3-3-7 or something like that, right? Like that's very suspicious and you're going to look at that very closely to understand what's going on. Try to see port 80, port 43 traffic. Yeah, whatever, and there's a lot of content that can be over there, right? Like streaming services, all kinds of things use HTTP, so they may not even look very closely at the traffic, so that's the idea. So yeah, it's not going to raise any red flags and it's going to, you know, can use very dedicated, very simple ports. Okay, so what you're going to do is create an HTTP 1.1 server. You'll have to do this, you'll have to look at and read the RFC. So why is reading RFCs important to this class? Yeah, so you have to, well, understand how it works. Yeah, so sometimes the best resource for something, like you want to learn more about IP, or you want to learn more about DNS. Yeah, you can read the Wikipedia page, but if you read this spec, you'll understand much more in depth about the spec. So what's the point of RFCs? Yeah, so the idea is, right, people want to write web servers, people want to write web clients, we have to define a proper protocol and interface to do this, otherwise they'll be able to write software that communicates and interoperates correctly. So you can, so part of the goal is to read this, and yes, it's an incredibly long document, right? It describes all of HTTP, but it's from, you know, 1999. So part of the goal is, right, to go through here and understand, okay, what's relevant, what do I actually, what do I have to implement, and what's optional, because you don't need to do the optional things, but you need to create things that are necessary. So why is that critical for a backdoor? Because you need the packets to look the same as the web profit question. Yeah, the web traffic should look the same, right? The HTTP protocol that it's speaking should look the same. If an administrator decides to make a web request to the server, right, it should get a legitimate response back. It shouldn't get a response that says, I don't know, it shouldn't throw an error in Chrome that says, hey, this thing isn't speaking the right HTTP protocol, so you're trying to blend in as much as possible. And the other goal of this assignment is to get you familiar with network programming. So in that, in light of that, no HTTP libraries are allowed. So you'll have to do the actual sockets and read from a socket input, and you'll have to parse the header, the HTTP headers and the HTTP request based on the spec by hand. But you can use URL parsing libraries, so I'm gonna do that. That's what we can use. Yes, you absolutely should. I mean, always. I don't know how else you do it. How are we gonna, how will you guys keep the sectors from bumping into each other? Yes, you don't have to worry about that. So that's, so the, and the name of your back door program will be normal web server, very innocuous. So the interface will be normal web server and we give you a port on the command line and you'll have to listen to that port. So, yeah. If this port is already used, what should you do? Stop and die correctly, right? You shouldn't just crash. How about kill the thing running on the port? No. No, it's very too, too evil. Don't kill the thing that's running on that port and then try to connect to the socket. Yes, we're not gonna do that. So your goal is you're gonna listen for incoming connections on the port and you're gonna respond to most of the requests with a valid HTTP11 response with the 404 HTTP response code. So this is gonna be your default thing when people connect to you. You're gonna say, I don't know what you're looking for. It's weird. But it will be a valid 404 response that will show up and the browser will parse it correctly. And this is another key point that I wanna emphasize. So this should be regardless of whatever they request from you. So when somebody makes an HTTP request, they can send you additional data if they're doing a post request or any kind of stuff. So you have to follow the spec and make sure you're parsing all of the input bytes from that connection. Right? Even if you're not gonna do anything with that, you still need to make sure you're parsing everything. Otherwise the client's gonna hang because it set data to the server that it never acknowledged. And read things. So yeah, this is the key point. So this is why you're implementing the spec correctly and why you're gonna follow the spec because you need to be able to not cause any problems to the client. The client should not know that you're using this other weird web server. You should just think it's a normal Apache web server. Okay. So now the backdoor functionality. So when you receive a GET request, an HTTP GET request for a URL of the form slash exec slash bracket command. So what do I mean here by bracket command? So what's bracket command? The command that you want to run? Yeah, it's a placeholder. I mean, whatever is sent there in the URL from that second slash to the end of the string, you're gonna take that command and execute it in whatever is the equivalent of the system Linux or Linux syscall. So you can look at this to see exactly what it is to make sure that what you're using actually corresponds with what I mean here. So it should be the same as running the command with bin sh sh.c So this means that the command will use the current path. It will... It'll use the current path. It will pass all arguments correctly and it will do all the space part setting and everything for you. I'm not sure about that from the outside. You want this to be easy for yourself. So after you execute it, the HTTP response will be the standard out of the executed command. We're executing something on the server. We want to get that response back. And the status code should be 200. And there's no limitation. Well, there should be no limitations to the characters that are in command. Isn't there a limit where all the URLs could be, though? Yes, besides something that's specified in the spec, right? It's a valid HTTP request with a valid URL there. And you need to execute that. Okay, for instance, if you're... If I make a get request to exec slash ls, you're going to return whatever executing ls is on the server. You're going to output that. If I make an HTTP get request of exec ls space la, then I want to return the body of the... I didn't finish my thought here. It follows up here. The output of the execution of the ls-la command on the server. What is supposed to be the working? Whatever the working... Whatever it is when you start your program. Okay. So would that be actually slash exec with the space or the %20 event? That's a good point. Yeah. I'm going to follow the HTTP spec. I believe I'll have to decode the URL so it will translate %20 into spaces. Yeah. Or plus, yes, plus as well. So you should use a library for that. So you know it's right. You don't have to do it yourself. But if there are spaces in there, it should work too, right? This is for you. This is your own functionality. You want it to be as easy as possible to use. If you're killed, you have to clean up directly. This just means you're going to be a good software developer, right? If you kill the program, you're going to release all your resources, release the socket, and then safely terminate it. Any questions? You mean press Ctrl C on the program itself, like on the host, right? Yes, on the host. Yeah, on the server. Or you get a SIG in. That's the same thing. Ctrl C sends a signal to the program. It's a R64 bit. Same thing with packages. This is all the same stuff. SIG did find some good network. If you have any program, if you have little experience with network programming, there's good resources here. If you find other resources that are good, email the list or email me and I'll add it here, right? I think it's helpful if we have a collection of these resources. I think that's totally a good solution. Cool. You can earn a little bit of extra credit in part three if you implement GZIP encoding. But note that you'll have to, once again, go to the spec and learn when can I actually send a GZIP response from the server. The client, not all clients may support GZIP, right? So there's a mechanism, a little bit of a negotiation where the client says, hey, I accept and you can GZIP the encoding. So this should work transparently to a web browser when you access this. And obviously only on the you can do it for all of them, I guess it doesn't matter. And the submission site will be set up shortly and you'll get an announcement about it. Any questions on the assignment? Are there separate submissions? Yeah. Can you use external libraries? Maybe not at all. Maybe you all. No, you can use the library. Just know HTTP libraries. The focus is on understanding the spec and learning about network server programs. Any questions? Individually, I guess I didn't ever said that, but it's implied, right? All assignments are individual. So we have one more topic to talk about. So we talked about ethics, we talked about hacker. And so the other thing I want to briefly touch on is an aspect of legal hacking, which is pretty awesome, and that's penetration testing. So penetration testing is when a company hires you to breaking their system and they purposefully are doing this so that you can attempt to find possible flaws in their system. So the idea is not just finding vulnerabilities. So just vulnerability analysis is finding vulnerabilities. So that on its own in a penetration testing sense is not enough. Why? Because certain vulnerabilities might be very hard to exploit and might never be exploitable in the real world. So this company is hiring you. They're hiring you specifically to demonstrate security flaws in their system. So they want to see that what damage you could actually do. Not what damage you could theoretically do given whatever vulnerabilities you potentially found. An exploitation is the proof of yeah, I found a vulnerability and look you hired me and I got root on your dev servers. I got root in your database. I have all your customer records. These are really bad things. It's usually done in a black box manner. What does black box mean in this case? You have no knowledge of the source code or how it works. You're operating under the same capabilities of a bad guy or a malicious hacker. You're on the outside. Black box is also in quotes here because often times you know if you're targeting let's say a bank or a credit card processor you may need user accounts to get access to more functionality so often they'll supply that to you but you'll do multiple types of pen testing where you say without any account which would be really bad and then what can I do if I have an account on the system? Am I able to gain privilege or move horizontally something like that? So is this enough? Is this all the head of an organization you hire a bunch of hackers to bang on your stuff and you fix whatever they tell you and then you're like yeah we're secure? No. Because one of the hackers might find a vulnerability which you might choose not to disclose and they do use it for that's tricky. Let's say you're dealing with let's say this company has really good Yelp reviews. Fair phrase, right? Very good trust. You trust this company they're going to they're going to tell you about all the things that they find. Is that still enough? Are you secure? Have you developed secure software? The technology you use might have certain vulnerabilities which are discovered at a later point in time I mean you never know. What doesn't they tell you when you get a report that says we found a vulnerability? What does that mean? There's a known exploit. Yeah, they found a vulnerability. What does that say about the rest of your system? It might. Yeah, it doesn't say anything right? I mean if they're good they've probably tried a lot of other areas and these were the things that they were able to find but there's absolutely no guarantee that these are all of the vulnerabilities that actually exist in your system right? There could be other vulnerabilities that maybe they couldn't exploit but they thought were unexploitable. It could be outside the area of expertise. It could be something that I'm looking for. It could be something that's a vulnerability at a later date. Maybe somebody finds a vulnerability at a later point. So yeah, you know this but so is it good? Is it useless with what I just said? It should be like never hire penetration tests for our systems. Is it useless anything? That's a good point. So something I didn't mention but you can have an internal pen test where an internal team performs a penetration test. How good are you at testing your own code? Or sometimes it's better to get outsiders who have no steak in the game right? So they actively do want an exploit so that's a good thing. But is this even effective? Like why do it if we can't make any claims about the broad security of the system? Why might you want to do it for some other reasons? We'll do a little more. Who left the holes that can be found to minimize the risk of enough when you're only prone to some inventive attacks that many people can find? So if you're hiring and paying people to do this for professionals and they find stuff I mean it's very likely that a bad guy could have found those exact same problems and cause massive damage to your system. So yeah you pay to find those before a bad guy does, right? Yeah that's definitely one reason. What about maybe I have cases of maybe actually security is not a big deal to the higher ups in your firm, right? So they don't think they're not giving your department enough money for security and to buy the tools you need and they haven't bought into that idea so you hire a penetration test team to test your system and then you go to your bosses and say hey look these people were able to get into our systems look they hacked the bank accounts of our customers or they were able to you know if they found this who knows what other kind of stuff were out there, right? So even if you can't necessarily gain or claim anything, right? It's still a valid and useful technique to try to increase the assurance of our systems that they are secure. So yeah it's not definitely not a good way to ensure the security of the system, right? So it doesn't mean that your system is secure you get to take into all kinds of other aspects you can do static analysis you look at the policy you look at social engineering attacks all this kind of stuff make up a whole security approach So anyways we already had this discussion of is penetration testing is useful So in this class proceed ethically right? So only attempt to find vulnerabilities in web applications and systems that you control have permission, don't go to jail don't violate ASU's policy either that's also very important when you're doing these things Alright, any questions on this before? I think it's very important Sweet, alright Now we're going to move a little bit So the first topic we're going to cover is we're going to talk about the network So specifically we're going to focus on attacks on the network that we as an attacker leverage in order to try to migrate to other hosts and so we're not going to go we'll go into depth about certain things but there are lots of other classes here, there's a whole advanced network security class so we're not trying to step on those things but we want to go over and discuss what are the important things here So I expect that you have some network experience background and or you will gain some through the assignments So I'm going to cover these a little bit quickly but stop me at any point I do want to have some discussions at certain points So what's the IP? What's the IP? So the internet protocol Sweet is a set of protocols so the whole idea is we want to transport data between two nodes on network, it doesn't necessarily have to be the internet but it could be any nodes and any network, the internet is separate from the IP Sweet It's also known as the TCP IP stack and this is because there's kind of a tight coupling between TCP and IP or they're very closely related. The whole idea is that we take the network and we want to abstract different layers from it So each layer and each technology focuses on one particular thing and abstracts all the other details from below it So for instance the link protocols, so what are some examples of link protocols? What do we mean by link here? Like the guy on Zelda? Connecting two nodes Connecting two nodes, yeah, like the physical link that connects two nodes in a network or not necessarily nodes, it could be intermediary nodes, right? What are some examples of link protocols? What? What is it? OSPF I think that's a router Yeah What would be? What is it? OSPF is network built I guess I'm going to do a little higher up How does your phone talk to your wireless router? Wi-Fi Wi-Fi? Wi-Fi Wi-Fi at 802.11n or whatever the thing is A or G or B or an Ethernet plug in an Ethernet There's an Ethernet protocol of how one end of the cord talks to the other end of the cord, right? Above that we have the IP the internet protocols that we look at above that so the internet protocols deal with routing how do we get data from one host to the other Above that we have the transport protocols so how does one host send data to another host At this point we don't care how the data gets there I don't care if you put it on a ship in USB keys and then it took a month to get there We don't really care about that because we're abstracting how it physically gets there And finally we have where we actually want to be is in the applications You, the programmer and especially the user, you don't want to think about PCP packets and strings and connections You're going to think about that as a developer because you want to build applications on top of that that use these abstractions The whole point is that you don't when you're a programmer you don't have to worry about the link level Think about, okay, is this person connected by ethernet or wifi Obviously in some cases with mobile phones you actually do want to know that information But in general if I just want to send data from one computer to the other I don't care how it gets there how the other layers work as long as I can successfully do that So to think about this as a layer a layering system right from the bottom we have the physical layer which is communicating from one node to the next Above that we have the link layer So this gets into hardware interfaces which interacts with the internet layer which is IP Then above that the transport layer And then finally on top of that we have the applications that we know and love HTTP SMTP email protocol DNS the domain name So that's the thing that takes that domain name you type into the browser and turns it into an IP address so that you can actually make the second layer work NFS Never fileshare This is a file sharing not like a file sharing protocol but to allow people access to like a what's the example I'm thinking of Like on Windows when you share this folder with the network that's NFS that's using Or if you're on Linux I believe Samba is the SMD Or is that a different one? Point is there's a lot Okay So we're gonna start with IP addresses because this is going to be very key to what we want to look at in the security here of the network So each host if you want to talk to a host on the network it's got to have some kind of address that you can refer to it If you think about like homes and houses if you don't have an address I can't write a piece of mail to get to you because there's no place for it to go A host could have many IP addresses IP addresses So IPv4 is really what we're going to focus on because IPv6 adoption is not quite up to where we want it to be yet to talk about it So IPv4 has 32 bits The Classable way of thinking about it is a class, a net ID and a host ID It's represented hopefully in what is this very familiar dotted decimal location So each of these is 0 to 255 right which is a byte so you have 32 bits, so 4 bytes right And the classes used to be when you got a network you would get it in this space, so you would get a class A network that had a lot of hosts I wish I had 16 million hosts on it a class B network would have 65,000 and a class C network would have 256 What's the problem with hard coding separation here between different networks What's that? Is it okay? Yeah, waste IP yeah, waste IP addresses because as an organization to get the network or to get a slice of the IP network you'd have to fall into one of these super broad buckets where you're starting a business It's a problem I want an A, give me an A What do you need, 16 million hosts? Not now, but from the start I'm clearly going to grow to 16 million computers So yeah, I definitely want an A So then what happened is they said doing this routing or thinking about it in terms of these classes really isn't bad So waste enormous amount of space the number of hosts constantly increases IPv6 has is it 64 bit addresses or is it 128? Yeah, a ton of addresses So you can give every organization 12 million or whatever IP addresses and it's going to be fine They say that they can address each particle in the universe Yeah, with 128 bit addresses you can address the whole sand and the beach just in case they really want to get your data packets The problem is adoption is slow So the numbers I looked at said Google says they're getting about 9 or 10% IPv6 traffic which is actually pretty good So at some point I'll have to update all this for IPv6 but today is not that day So in 1983 they came up with a scheme called CIDR which is Classless Interdomain Routing So the idea is you could change the net ID and host ID boundary to be on any bit between 13 and 27 So you could arbitrarily adjust the size of the network which gives you 32 hosts minimum to 224,000 hosts maximum And so IP is really kind of the glue of the internet So this is what gets your data from one place to the other regardless of all the hops in between So your data comes from us here to probably some of the ISP Is it Clearlink? No Centurylink Probably the Centurylink servers Then depending on where it wants to go it may go to like a Verizon or an AT&T broadband which then gets sent down to LA if your traffic is going to go to LA So it gets all these hops The important thing here is that it's connectionless so IP doesn't care about who you've connected with or what or the state of the connection It's just concerned with I want to get this piece of data from this machine with this address to this machine with this other address That's all it ever cares about It's unreliable What does that mean? The packet can be dropped on the floor We don't care IP doesn't care anything could happen Best effort which means they'll try to do it It's kind of like a similar type of reliable Actually in the book it's mentioned that it makes no effort best effort is in euphemism Yeah, best effort It's optimistic Honestly, I mean packets nowadays fairly reliable but still doesn't offer anything Delivery of a packet The integrity What does integrity mean of a packet? Changing Yeah, it could be changed along the way Ordering What does ordering mean? Yeah, right? So I sent two packets to you one after the other Who's to say you'd get them in that same order? Because we're not saying how packets take to the network or anything like that Non-duplication You could get two of the same packet I could send one packet to you and somewhere along the way a router sends the packet but then thinks it didn't send it so it sends it again You get two packets at the host Bandwidth, there's no guarantee of bandwidth or anything So the whole idea is what IP is for is to exchange what we call datagrams or packets or just information between any two nodes that have IP addresses So do you all have Is this how you talk to other computers on the network? Say I know Google's IP address and they know my IP address so you guys exchange packets Why not? It would be very hard to remember all those sets of numbers It would be very hard to remember Exactly Nowadays there's a lot of networks in between you and Google Actually I think ASU NAT which I think we'll get into which makes it seem like all of us are coming from the same IP address to Google If you've ever done a Google search and it says, I think you're a robot fill in this captcha It's because all of your fellow students are searching for things on Google that's crawling Google There still is We have a way to know Google's IP address We have our own IP address either on the network or internally within ASU And when we send out that packet from here it says, hey, I want to talk to Google send this thing to Google The IP network knows how to get that packet there And so this is where So the other lower level protocols are how that packet actually physically gets from your computer to the next hop So from here to the router So RFC 791 So like I said, everything comes back to the RFCs They're pretty awesome It defines exactly the bits in an IP datagram and exactly what they mean So Do we actually care about what's in the data of the IP packet? No, not really It might be encrypted Yeah, it might be encrypted Who cares, right? We'll see if we care slightly But, yeah, in the general case we don't really care So here we're talking about basically the header of an IP packet This is additional metadata we add on top of that packet that specifies, hey, where it's going to go So if you think about Has everybody sent a letter? Like a physical letter? No? I'm still going to use this anyway So you've seen movies with people writing letters, right? Right, so your datagram in a letter equivalent would be what? The letter itself, right? I write a letter out to somebody then I fold it up So then what I do is throw that in the mail and they know how to get this to who I want to Exactly, so I put in an envelope first and I write some metadata on the front that tells the post office how to take this letter, this data from me to them So that's exactly what's on here So when I write on a letter, when I write the person's name their address their house number their city, their state their zip code everything on the front and I also put a return on their back in case there's any problems they can return it back to me So I put my name, my address, all that stuff This is all the same information So you've got to think of this headers like the addresses you put on an envelope So the first thing, the first four bits are the version of the IP that we're using So normally this will be what? Fourth, IPv4 Unless it's IPv6, right? So you know that this is an IPv6 packet The HL Yeah, the header length Okay, I forgot what that was I was going to cheat and look That's what I should just do So HL is the length of the header So this specifies how much, how far this packet goes down We'll see in the next slide exactly what the properties of this are But the idea is here, right As we know, so why do you have to include the length here? Because it could be Exactly So now we know Okay, by including this here that means the length of the header could be variable If it was fixed, we wouldn't need to include this It would always be whatever 20 bytes or five words or something like that Okay, after that we have some flags about the service type So this, as we'll see, specifies different flags Then we have the total length of the entire packet right at the data that we're sending We have an identifier that specifies uniquely the packet We have flags for the packet fragmentation offsets which get into really interesting and enable some really cool attacks here The time to live the protocol, so this protocol actually does break a little bit of the encapsulation So this is the protocol of the underlying packet, is it TCP, UDP, R, ICMP or different kinds of protocol in there A check sum So what's a check sum? Exactly, it's a check integrity of the header, right? So this is make sure that when you're reading this, I know I got all of these bits correctly, because every bit in here is important, so if one bit flips everything is done We have the source IP address, the destination IP address, any other options a variable length option section, padding and then finally the data So let's break here and when we come back we'll dig into kind of exactly what these mean Wow