 Welcome to the annual DEF CON Convention. This meeting was held at Exciting Las Vegas, Nevada, from July 9th, through the 11th, 1999. This is video taken at number 18. Introduction to TCP-IP. Unfortunately, I wasn't able to make copies of these slides. This isn't going to be kind of a slide intensive presentation, so if anybody does want to copy the slides, just grab me any time during the con. I'll throw them on a floppy for you, or send me an email and I'll get them to you. And for those of you who don't know, I will be doing a brief introduction to TCP-IP this morning. What this lecture is going to cover, this lecture is going to be a low-level, it's basically a low-level overview of TCP-IP. This lecture is geared towards novices. This obviously is the new B-track, so it's not going to be a real high-tech presentation. If you do want a high overview of TCP-IP, this is the book to get. TCP-IP Illustrated, W. Richard Stevens, by this book we did it from cover to cover. After we read this one, there's two more volumes after this. Excellent book. First off, I want to cover a little bit of the history of TCP-IP, where it all began. Essentially, TCP-IP started in 1969 when the Advanced Research Project Agency, also known as ARPA, decided to fund some research and development into making basically a novel, a global network, but there's one to start putting all the resources together and make a network that they could put all these resources together and network the computers together and essentially make all their computers work a little better together. ARPA's goal was, and originally the internet, as we know it today, that was not our original goal, it was more of a research project. ARPA's goal was to study techniques for providing robust, vendor-independent data communications. So basically, they could put all these different machines together regardless of operating system, regardless of vendor and have these machines be able to talk to each other on a network. ARPANet was so successful that many organizations attached to it began to use it on a daily basis. Obviously, areas proved to be a very important resource people are using on a daily basis, so they grow rather rapidly. In 1975, ARPANet converted from an experimental network to an operational network when the Defense Communication Agency, also known as DCA, took control of it. They took full control of it and released it from ARPANet. In 1983, a couple different things happened with TCPIP. The TCPIP protocols were developed as military standards. They were then enforced as military standards. All hosts on the network were then required to be able to use this communication suite to talk to each other. Also in 1983, ARPA funded the implementation of TCPIP in Berkeley or BSD Unix. And also in 1983, the term that we know today is internet came into common use. Also in 1983, ARPANet split into both the neural net and also a newer smaller ARPANet was controlled by two bodies at this time. In 1985, the National Science Foundation, or the NSF, created NSFNet and connects it to the internet. In 1987, NSF created a faster new backbone and a three-tiered topology that includes both backbone, regional networks, and local networks. Basically, NSFNet was the whole backbone for the entire internet at this time. And then in 1990, ARPANet passed out of existence. This is probably a lot more memorable for a lot of people. In 1995, NSFNet seizes its role as the primary backbone for the internet. Basically, that's when it came to be known as what we know today as the internet in 1995. So basically, this all can be wrapped up in a nutshell. What has come to be known as the internet was originally designed and experimented, or it was originally designed as an experimental network that really had no intentions of it going into the network that has come to be known as today. The internet has grown much larger than it was originally intended for, obviously. And also the original networks and agencies involved in the creation of the internet are no longer involved in that process today. They no longer play in a real event. A couple of myths of TCPIP. Contrary to what you think, Al Gore did not create the internet. He did not invent the internet. When the internet was funded, Al Gore was only 21 years old. He was a college student. I don't think he had anything to do with it. Okay, now we're going to go into some of the definitions we'll be using. TCPIP defined as the transmission control protocol, internet protocol. Essentially, this is the suite of networking protocols that have been used to construct the global internet. Also referred to as DOD or Open App Protocol Suite. Y'all already hear it referred to these days. Sometimes you still may, because they were involved in the early development of the suite. So TCP, defined in nutshell, is a series of protocols that allows computers to communicate on a network, regardless of operating system, regardless of vendor. It doesn't matter what operating system you're running. It doesn't matter what type of computer you're running. As long as you're running a TCPIP stack, you can still communicate with other computers on that network. Okay, I really hate the OSI model. We're not going to go into that at all with this talk. The thing we are going to talk about is the four layers of TCPIP. This is what's really important. I think when it comes to TCPIP, the OSI model is not really that important. There's a lot of layers that are not even used in TCPIP. So let's talk about the four layers of TCPIP. Starting from the bottom, we have the link layer, which is the device to run an interface card. Your network interface card is as simple as that. Moving on up the stack, we have the network layer, which is typically comprised of IP, ICMP, and IGMP. Moving on up the stack, we have the transport layer, which consists of either TCP or UDP. And at the very top of the stack is our application level. These are the actual applications that the users interact with, such as Telnet, FTP, Mail, what have you. A little description of what each layer is comprised of and what it does. The data link layer, this is the very bottom of the stack. This layer includes the device driver in the OS and the corresponding network interface card in the computer. This is both your network interface card and whatever driver is required to interface that NIC with your machine. This handles both the hardware details of physically interfaces and network. Moving on up to the network layer, this is also sometimes known as the internet layer. This handles the movement and routing of packets around the network. Moving on up the third layer, which is the transport layer. This provides a flow of data between two hosts for the application layer above. Two different transport protocols are used at this level. I'll give you a brief description right now and go a little bit further in-depth into those in a few minutes. It uses both TCP and UDP as I mentioned a few minutes ago. TCP is an extremely reliable protocol. It breaks data pass from the application layer above and two chunks for the network layer below. It acknowledges every packet it better receives, sets timeouts and a couple more things which I'll go into in a few more minutes. Instead of being very reliable, it should actually establish a connection with the machine on the other end of the network. The other protocol used at this level is UDP. This can serve to be very unreliable. It sends these packets of data, also known as datagrams, from one host to another. The problem with this is there's no guarantee that those packets that you're sending to a remote host are actually being received by that remote host. And at the very top, we have the application layer. This layer handles the details of the particular application being used. Some of the standard TCP IP applications include Telnet, FTP, SMTP, and also SNMP. Okay, another definition, encapsulation. What encapsulation is? When an application sends data using TCP IP, it's sent through each layer in the protocol stack. As it passes through each layer, each layer adds its own information to that data by adding its own header and sometimes affords that information. The data is then sent as a stream of bits across the network. This is a little graphical representation of exactly how encapsulation works. We start off with our user data. First, it's run through the application layer. Remember, it has to work its way through the top of the stack, go down to the bottom of the stack. Once it runs through the application layer, the application layer adds on its own application header. The next layer runs down to the TCP layer, so obviously that's going to add on its own information. As we can see, it does add on a TCP header. Now, this piece of data or this segment is what's known as a TCP segment. Both your application data and TCP header comprise a TCP segment. We run down. The next layer we have is our IP layer. As you can see, the IP layer adds on its own IP header. This piece of data is what's known as an IP datagram. It's comprised of your application data, your TCP header, and your IP data. I'm sorry, your IP header. Obviously, the very bottom of the list or the bottom of our stack is the link layer, our Ethernet card. The link layer, if you notice, adds both an Ethernet trailer and an Ethernet header. This piece of data is what's known as an Ethernet frame. This is going to be what's sent across the Ethernet. Not that data would not go across the Ethernet and once it's handled by another machine. Once that piece of data is sent across the wire, what happens is demultiplyxing. It's the exact opposite of what happened just a minute ago. When an Ethernet frame is received by a host, it starts to sway back up the protocol stack. Each layer then will look at its respective header and its footer if there was a footer for that layer, and it decides what to do with that data next before it passes on to the next layer up. So when you're sending data from a host, it moves its way down the stack, goes to the host, moves its way back up the stack, and strips all the headers and footers off that are required for that layer, then passes off the application layer and decides what to do with it from there. Okay, now I'm going to talk a little bit about some of the TCP IP networking protocols that are in use today. First, we're going to talk about IP, some of the features of IP or the Internet protocol. IP is the dominant network layer protocol used by the TCP IP suite of protocols. IP defines the rules for packaging network traffic into IP datagrams, and also defines the rules for moving these datagrams across the network. So you can see IP is a very important layer, a very important protocol. IP is also responsible for fragmenting the data whenever necessary, and to properly reassemble datagrams at the other end. This will make a little more sense in a few more minutes. And this is actually what an IP header looks like. It might be a little bit hard to reach the lights up here. We couldn't get these lights shut up off up here. But I'm going to go ahead and describe what each piece of this IP header actually means. Up in the left-hand corner, the very first item on there is the version number. This indicates which version of IP is being used, which is typically version 4. Obviously, we're very slowly converging into version 6. There's probably a very slow convergence with that. The next item is the 4-bit header length. This indicates how many 4-byte words are in the actual header. The next item is the 8-bit type of service. I'm not going to go into real big detail on this. TZPI IP Illustrator really breaks this down really well, and exactly what the different types of service are. But essentially, this indicates the level of service the IP datagram should be assigned. The next item is the 16-bit total length in bytes. This is the actual datagram length. This is the length of the entire datagram, including the header. The max size of this is 65,535 bytes. The next item is the 16-bit identification. This is actual datagram identification. This uniquely identifies each datagram being sent by a host. You want to have your IP datagrams each having an individual identification. It's the ones that are received by their host. The host knows how to handle that. The next item, we have a couple of different flags. There's three flag positions there. The first one is not being used. It's represented by the zero. The next flag, DF, is don't fragment. And the next flag is more fragment. This controls how the actual IP datagram is being fragmented as it's being sent across the wire. Percenting a lot of information across the wire, obviously it's going to have to fragment this information. It can't send it all in one giant chunk. We have that limitation on how big the actual package can be with this. The next item we're looking at is the fragment offset. The fragment 13-bit fragment offset. This indicates how many units from the start of the original datagram the current datagram is. Now this would be used when you're sending quite a bit of data across the wire. That number is going to increase with every packet of data that's being sent across the wire. If you're sending just a very small packet across the wire, the fragment offset's going to be zero. If it's being broken down to, say, three packets, it's going to increase with every packet, one, two, three. That way, once it was received at the host, it's going to know how to interpret that data, how to put that data back together. It's also going to know when it's done receiving data, basically when it's received the end of that data. The next field is the time to live, or TTL. This is an 8-bit number. This indicates how many routers the datagram may traverse before being dropped, the max TTL being 255. If you don't set a time to live on a packet and you send it out across the wire, let's say at a particular time it can't find its host, it's going to bounce across the internet forever until that host comes up. It can't have that happen on the internet. It could probably cause a lot of problems. The next field is the 8-bit protocol field. This identifies which protocol has handed the IP to data. The next fields are pretty obvious. The 32-bit source IP address. The 32-bit destination IP address. Obviously, it's the IP address which is sourcing this information and the IP address which is the destination of this information. The next field is the options. This field is not always used. Currently defined options are security and handling restrictions, record route, time stamp, loose source routing, and strict source routing. These options are rarely used. There's a lot of routers out there on the internet that do not know how to handle these options, so it's very rare that they're used. Obviously, your last field's data is very obvious what that's going to be. That's your data that you're sending to the application sending to the urmode host. This is an actual TCP dump on IP headers to give you an example of what it might look like. As you can see at the very top, our version is version 4. That's what's most commonly used on the internet these days. The header length is 20 bytes, that's obvious. The service type, as I said, I'm not really going to go into that today, but that hexadecimal representation represents the level of service that this datagram will be. The next item, datagram length, this is the length of the entire datagram, including the header. It's 40 bytes. Next, we have our unique identification, which we would have for every packet going across the wire. Next, we have our two flags, the must fragment and don't fragment. As you can see in this case, must fragment is off, don't fragment is on. That means we're sending a very small packet across the wire. It's only going to be one packet going across the wire. Next, fragmentation offset. As I mentioned, this will increase exponentially when you're sending large amounts of data across the wire. In this case, it's zero. It's a very small piece of data we're sending. The next item, time to live, 32. This packet can only traverse 32 routers or 32 hops before its destination, before it's actually dropped. The next item is the encapsulated protocol that's being used in this instance, which is TCP. The next item is the header check sum. This is basically just a bounce checking that the remote host will use to make sure that the data being received is not corrupted in any way. Then we have our source IP address and destination IP address. Those are both obvious. Okay, I just wanted to mention a little bit about the trace route program. This can be a very useful diagnostic program, especially since there is no guarantee that two connective IP data grams from the same port, same source to the same destination will take the same route. They usually will, but let's say you're sending data across the wire, a large amount of data going across the wire. If one of those routes should drop, automatically they will be rerouted to that host. That host should still receive all that data. Trace route is a good program. It's a good tool that can be used to trace the flow of IP data grams from one host to another. An explanation of how trace route works. Trace route sends an IP datagram with a time to live of one to the destination host. If you remember a minute ago I mentioned the time to live is essentially how many routers that packet can traverse before it's going to be dropped. So obviously once it gets to the first router and it's path to the host, that packet is going to be dropped, is going to be decremented by to zero, that packet is going to be dropped by that router. That router is then going to send an ICMP time exceeded back to the host. What happens next? Trace route then sends another datagram with a time to live of two. We then find the next IP address of the second router. It will decrement to zero once again, be dropped, it will send back the ICMP time exceeded back to the host, so on and so forth. We'll keep doing this until it eventually does reach the host. Here we have a real simple sample of trace route output. We're tracerouting to victim.com. Trace route to victim.com is going to be a maximum of 30 hops which is a time to live of 30 and is setting 40 byte packets. That's the size of the entire packet including the header is going to be 40 bytes in this case. You can see the first hop is Satan and we have, it's actually saying three packets every time so we have a ravage for every packet. 20 milliseconds, 10 milliseconds and 10 milliseconds. The next hop, which is our actual destination host is victim. So we can see we have 120 milliseconds for all three of those. So for each TTL, three datagrams are actually being sent. These values are then recorded in your output. Moving on to TCP, some of the features of TCP. TCP is a transport layer protocol. I mentioned that a little bit earlier. This provides a way to connect hosts across a network reliably. As I mentioned before, TCP is considered to be a very reliable protocol. Actually, TCP provides a virtual circuit between two hosts. These hosts are actually connected from one end point to another. It's basically a virtual connection between the two machines. Communicating hosts are required to acknowledge receipt of network traffic. That way you're guaranteed that that information you're being sent to that host is actually being received by that host. But for some reason that host drops in the middle of the transmission to be notified all the information you're sending to that host was not received. Some more features of TCP. TCP packages this data into segments which contain both data and session control information. And since segments traversing a network may arrive out of order, TCP provides proper reassembly of these segments. As I mentioned before, all your packets may not necessarily take the same path. Some of these packets may arrive out of order. So we have to have a means for assembling these packets in the proper order once they arrive at their destination host. This is where sequence numbers come in. Sequence numbers are used to properly reassemble all these packets that are being sent to your host. You can think of that the sequence number basically has a 32-bit counter and it can range anywhere from 0 to 4,294,967,295. So it's a pretty broad range that the sequence number can fall into. And this is an example of how this is an FTP transfer TCP dump output. As we can see on our first line, we have TCP. It's obviously an FTP that's telling us. And the sequence number, we're just going to look at the last four digits of this at 1397. And as you can see, the data payload is 1,460 bytes. So next we increment up 1,460. The sequence number is going to increase by 1,460 for packet 50. It's going to jump up to 2857. Once again, it's 1,460 bytes in this packet. So our next packet obviously is going to increase by that same amount of number for the sequence number. It increases to 4317. The same thing for packet 52. So essentially if these packets arrive out of water, the receiving host can still put these packets back into the proper order. And they acknowledge what this data being sent across the wire is. And one of the other features of TCP it maximizes performance of a connection by ensuring TCP segments are neither too large or too small. There's a lot of bounds checking to make sure it's not saying too much data. If you don't want to send too much data because if that receiving host can't handle that much data, you're going to lose data and you're going to have probably corrupted data being sent across the wire. So everything I've said about TCP can pretty much be wrapped up in a nutshell. It provides a virtual circuit. TCP connections behave like a live two-way communication or a two-way connection. You can basically think about it as basically a telephone conversation. You're connected from one endpoint to another endpoint. It provides reliable connections. TCP segments are guaranteed to reach their destination. And if for some reason they're not receiving their destination, the user is notified about this. And there's also a lot of stuff put in a TCP that provides performance optimization. TCP can modify transmission variables depending on network conditions. For some reason if a route seems to drop, a route seems to really be lagging. That information will re-route across the network and it essentially will still reach the host even if a route does drop. And now we're going to go ahead and take a look at the TCP header and all the fields that were included in the TCP header. The first two items we have, the 16-bit source port number, the 16-bit destination port number, obviously this is the IP address of your originating host and your destination host. The next field is your 32-bit sequence number. As I mentioned the sequence number is a four byte number assigned by TCP starting with a randomly chosen number. Actually the older operating systems it wasn't really very random. I'll talk about that in a few minutes. I think Pete's actually going to elaborate on this in the next speech on TCP IP sequence prediction. This number is used to determine how many bytes have been transmitted across the network so it can properly assemble those packets once they're received. The next field is the 32-bit acknowledgement number. This acknowledgement number acknowledges the last segment sent by the host. We can't have all these packets traversing the network and hitting the host and host not acknowledging that they're being received otherwise there's no way we're going to have a good connection there's no way we're going to have a reliable connection going across the wire. The next item is the four-bit header length. This measures the header length and four byte loads. The next field is reserved. I'm not going to discuss that. In the next field we have these different flags. I'll give you a brief description of what each of those flags mean. These flags may either be turned on or turned off. These flags are used when negotiating and managing a connection. The first flag which is urge, or URG this indicates the segment being sent as urgent. She can prioritize the urgency of segments being sent across the wire. The next flag is ACK or acknowledge. Indicates the ACK number as valid. The next field is bush PSH. This automatically tells that to pass the data to the application as soon as possible. It puts a precedence on this information to pass to the application layer ASAP. The next field is RST or reset. This flag is used to reset a connection. The next flag which is sin synchronize. This synchronizes the numbers used to initiate a connection. I'll talk about initiating connection in a few minutes. And the last field is FIN. This indicates that the sender is finished sending data. A FIN would be finished obviously at the very end of your flow of data indicating they are no longer sending data. You're receiving hosts as you know that it has received all this data at that time. The next field is the 16-bit window size. This is the number of bytes the receiving host is willing to accept. This is a sliding window and this can actually scale to paying all kind of traffic that host is receiving. The max being 65,535 bytes. The next field is the 16-bit TCP checksum. This is a checksum of the TCP heather and data. Once again, this is used by the receiving host to ensure that data being sent across the wire is not corrupted. The next field is the 16-bit urgent pointer. This is used only if the urgent flag is set so a sense of precedence on your information going across the wire. The last field are options. The most commonly used options in TCP heathers are both MSS which is maximum segment size. This determines the maximum size segment the sender is willing to receive. This basically coincides with the 16-bit window size I just discussed a minute ago. And then obviously at the bottom we have our data. Data is not always going to be sent across the wires. You're going to see in a few minutes when you're establishing a connection no data is being sent. You must first establish that virtual connection before any data can be sent across the wire. So essentially this portion of the TCP segment is optional. And also jumping back to the synchronized numbers I was talking about how the host they use these numbers to determine how much data is being sent across the wire and it's also used to properly reassemble these packets. On older systems when you first bootstrap the system this number is set at 1. Every second it increases by 128,000 and every connection it would increase by 64,000. That's why in a lot of older systems it was a lot easier for people to try and predict TCP sequence numbers. With the current TCP IP stacks this number is generated randomly so it's not quite so easy to try to hijack the connection with that. I think Pete's going to be elaborating on that a little bit more in the next segment. And this is natural TCP dump of a TCP header giving you an idea of what it looks like. Our source port is 22 it's a well-known port SSH. Destination ports 1,714 it's an unknown port it's an FRM report. It's a reference number our acknowledgment number the header length which is 20 bytes is telling us there's no data in this payload. Our flags the urgent flag is turned off the acknowledged flag is turned on the pushed flag is turned off reset flag is turned off the synchronized flag is turned off because we're not establishing a connection we're already connected to this host and the fin flag is turned off. The window advertisements 22,736 bytes this is how many bytes of data our remote host is willing to accept at that particular time. We also have our checks on that is used by the receiving host to ensure this data being sent across the letters not being corrupted and our urgent pointers being set to 0 because of the fact that the urgent flag is off. This is just a little graphical representation of what actually happens when you establish a throughway connection to a remote host. It's what's known as a throughway handshake. Initially the client will send a SIN packet to the server with an ISN of X we'll say it's X right now it's not really important what number that is. The server is then going to apply with a SIN, it's going to set its own ISN as Y and it's also going to acknowledge the client's ISN by adding 1 to it so it would be X plus 1 in that case. The client then sends back another acknowledge with the server's ISN which would be Y plus 1. Once this happens we have a full connection established data can actually be sent across the wire at this time. And this is a packet dump showing exactly what it looks like when this throughway handshake is being established. As you can see we're connecting from TC port 24,616 to an FTP port we have our sequence number I'll scope it off the last four that's 1453. The requesting client sends a SIN or a synchronized segment specifying the port number of the server which is connected to and the client's ISN our initial sequence number. Part two of the handshake the server responds with the SIN segment including the server's own ISN which is in blue the last four being 5737. An acknowledgement was also sent with the client's ISN plus 1. So as you can see that didn't increase by one it's at 1454 now it was originally at 1453 when we first initiated this connection. And the last part of the throughway handshake the client acknowledges the server's SIN and sends an act segment with the server's ISN plus 1 which is the number in the blue. As you can see that didn't increase by one it's now at 5738 whereas before with the last packet it was 737. If there's any questions you can feel free to ask them anytime or send them to the end. Moving on to UDP user datagram protocol I mentioned before UDP is also another transport layer protocol such as TCP. UDP does not use the benefits of error detection error correction handshaking or verification of delivery like TCP it provides a connection list to your hosts. And because of the fact that there's no error checking error correction it doesn't ensure that your packets are receiving the host UDP does have very low overhead it's typically only useful as a very simple application such as TFTP If you have a real intensive application you're not going to want to use UDP because there's no guarantee that this information being sent across the wire is actually receiving its host. With an intensive application you want to guarantee that the information is not going across the wire. Now we'll take a look at all the fields in the UDP header as you can see it's a very small header because of the fact that it doesn't have a lot of these error correction bombs checking like the information did. At the very top the first two areas of the UDP header the 16 bit source port number 16 bit destination port number those are both pretty obvious. The 16 bit UDP length this indicates the length of the entire UDP dated RAM including the header. Next we have the 16 bit UDP check sum this is a check sum of the entire UDP dated RAM. Once again this is used by the receiving host to ensure that data being sent across the wires not being corrupted. And the last field is our data. It's obvious what that's going to be is our data we're sending to the application on the remote machine. Yes. He was asking he said UDP does not do error detection. It's not actually an error detection it's just ensuring that that packet is properly formed once it's received the host. Let's say that packet does hit the host and it says there's something wrong with this packet it's not going to let you know if there was something wrong with it. Right. And next we'll take this is natural TCP dump of a UTB header see what it actually looks like. Our source port is 2167 this once again is an ephemeral port that the user is interacting with. The destination port is 53 domain service domain name service port it's a DNS request. Datagram length is 37 bytes 8 of which is the header and 29 of which is the actual data being sent and then we have our check sum. It actually pretty much wraps up my speech. There's a couple of references I have in my slides as I mentioned before TCPIP Illustrated Volume 1 an excellent resource it's kind of difficult to get into it first but the more you read up on it the easier it does seem to get. Also TCPIP Network Administration is one of O'Reilly's books written by Craig Hunt is a pretty decent book also. Like I said before if anyone does want to copy these slides you can drop me an email it's punkus at attrition.org I'll be glad to send you a copy of these and let's see. Also having the references the TCPIP fact the frequently asked questions is broken down into two parts there's a URL for that I could give to you. I'm not going to read it and also TCPShow TCPShow is a really good program if you're trying to learn about TCPIP I really recommend this program it's a program that's used in conjunction with TCP Dump TCPShow essentially reads the TCP Dump save file provides a reasonably complete decode of Ethernet, TALP, WALP, IP, ICMP, UDP, and TCP headers and packets that match the Boolean expression all the dumps that I showed on the screen in this presentation were done using the program TCPShow I don't know how familiar people in here are with TCP Dump but it doesn't really provide an output that's really easy to determine what's going on with that information so both TCPShow and TCP Dump used in conjunction with each other are excellent tools to examine exactly what's going on with TCPIP email address on the screen is punkus or nkis at attrition.org for those of you who weren't in here before who in here is familiar with attrition just out of curiosity a couple people just so everyone gets a heads up we are going to be changing the focus on attrition there are going to be a lot of changes coming up in the near future on that so keep your eyes on that we're going toward a more technical content with that so I'll change our focus a little bit on that we're not dumping anything we're ending a couple things we're going to finish on a couple things there's a couple things that we feel we don't need to pursue anymore we think we've proven our point on a couple of issues that we've been making a lot of section will not go away reporters okay is there any other questions yes yes what's that what's that he was asking if tcp show will do both ethernet and token ring is that correct to my knowledge it does ethernet only I don't myself no this sequence why doesn't it increase by one peace can we talk about this with the tcpip vulnerabilities if it increases by one it's going to be very easily for an attack or can send basically a fake packet coming from wherever he wants to when they're receiving hosts and send back an acknowledgement number you're going to know what the next number should be in that sequence so it'll be very easy to hijack a connection with that the older tcpip stacks every second will increase 128,000 every connection that's made will increase by 64,000 so with a little bit of luck on older systems it was a little bit easier to actually hijack a cd session yes UDP really is used anymore I mean let's use TFTP is one of the only stock applications that come with most systems that use UDP anymore like I said before it's just used for if you have a very non-crucial application I guess I could say where it's not really totally important the data being sent across the wires being acknowledged if you're just using a system where you want a very low overhead UDP would be a good time to use that I got in here all with your sense I don't think he asked about UDP being used with video transmissions I doubt you'd actually want to because you'd probably be dropping a lot of frames not actually knowing it so typically video applications being sent across the internet are pretty intensive and you'll want to use something like TCP to send in information it would be obvious for instance if you have some kind of service where people are paying for this information and you're dropping frames obviously your video output is not going to look really good they'll be kind of up to the user that's pushing that information across the wire the checks I'm not going to go into that a little bit above what I'm working on right now I can't answer it it's a hexadecimal number that's generated by examining the contents of the payload the same things don't once it's received by it's receiving host to ensure that the data is being received properly any other questions comments death threats what about it what about it there's not a time to live okay if he was asking what could be a potential problem of sending information across the wire without a time to live obviously if I'm sending information to a host on the internet that's not actually up at that time this information is going to be bouncing across the internet forever let's say that host never comes back up this internet is always going to be bouncing across the internet so you're going to cause a lot of overhead problems obviously hosts are dropping every day using the TTL they will without the TTL they will not well the TTL cannot be set above 255 so there is no problem with that and back what about the host what do you call a little bit of an internet that's not going to be enough his question is with the exponential increase in the internet more and more routers being pushed out there is there ever going to be a time when a time to live of 255 is not enough at this point no if you have that many options you're bad enough, I apologize typically if you trace without a host even if you're trace riding to the other side of the world you're probably not going to have more than 20 or 30 hops I've never done a trace ride where I've had probably more than 40 hops but I think actually 255 is very reasonable yes it is being done automatically by trace route there are modifications I think actually while it has written one where you can increase the way that can be changed but that's the default that it sets it as is 30 that's why sometimes if you're doing a trace ride and you'll get your first three lines of information then you'll get a couple rows of asterisks it's succeeding, it's time to live if those packets are being dropped any other questions actually it depends on who you ask about it some people say it's one some people say it's other typically it's just how many hops yes the urgency set automatically unless you actually build a program where you're constructing your own packets read TCPIP volumes one through three and learn how to program and see what pets do you have? well it does look like a program called LiveNet I'm not sure what his site even is these days I'm going to don't even know if it's up it's L-I-B-N-E-T and I know it's about to see folks in my party that does all the investing back for you packetfactory.com I believe is the new URL for that and actually they were supposed to be releasing a newer and bigger version of that and then the real near future I believe any other questions