TCP IP Analysis and Troubleshooting

TCP/IP Analysis and Troubleshooting An introductory guide to TCP/IP packets, troubleshooting tools and techniques Laura ...

Author: Laura Chappell

182 downloads 1704 Views 3MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

TCP/IP Analysis and Troubleshooting An introductory guide to TCP/IP packets, troubleshooting tools and techniques Laura A. Chappell + Understand how DHCP, DNS, UDP, TCP, and IP are supposed to work. + Identify problems with connectivity, configuration, and design based on network traffic. + Optimize your network design based on data flows and ICMP messages. + Troubleshoot typical TCP/IP problems with the latest techniques and tools. This book is distributed through podbooks.com in electronic format (downloaded) and bound hardcopy format. Trace files included with this book are considered part of the book content. Additional copies may be ordered online through www.podbooks.com.

Featured Products This book shows numerous packet structures using Network Associates Sniffer Pro. Although the Sniffer Pro is not the only analyzer on the market, it does have very strong decodes for the TCP/IP suite. Another good analyzer is the AG Group Etherpeek/Tokenpeek product set. This book also introduces a combination tool, NetScanTools Pro 2000 which should be in every troubleshooter’s toolkit. As a combination tool, NetScanTools Pro provides you a multitude of utilities necessary to effectively test and diagnose network problems.

Sniffer Pro [Network Associates]

Summary Window Decode Window Hex Window

NetScanTools Pro 2000 [Northwest Performance Software]

nslookup ping port scan

traceroute

TCP/IP Analysis and Troubleshooting An introductory guide to TCP/IP packets, troubleshooting tools and techniques Laura A. Chappell

Distributed electronically and in print form through

TCP/IP Analysis and Troubleshooting By Laura A. Chappell Superhero artwork by Norman Felchle Published by podbooks.com 5339 Prospect Avenue, Suite 343 San Jose, CA 95129 USA

Copyright © 2000, podbooks.com. All rights reserved. No part of this book, including interior design, cover design and trace files, may be reproduced or transmitted in any form, by any means (electronic, photocopying, recording, or otherwise) without the prior written permission of the publisher. Podbooks, AnalysisMan, AnalysisGal, and the AnalysisKids are trademarked by podbooks.com.

Library of Congress Catalog Card No.: 99-68508 ISBN: 1-893939-01-4 Printed in the United States of America (Saratoga, California) 10 9 8 7 6 5 4 3 2 1 Distributed worldwide through podbooks.com.

For general information on podbooks.com, including information on corporate licenses, book update procedures, and future titles, contact podbooks.com at 408/378-7841 or [email protected]. For authorization to photocopy items for corporate, personal, or educational use, contact the copyright division at [email protected]. Trademarks: All brand names and product names used in this book are trade names, service marks, trademarks, or registered trademarks of their respective owners. Podbooks.com is not associated with any product or vendor mentioned in this book.

Limit of Liability/Disclaimer of Warranty. Authors and publishers have used their best efforts in preparing this book. Podbooks.com and authors make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. There are no warranties that extend beyond the descriptions contained in this paragraph. No warranty may be created or extended by sales representatives or written sales materials. The accuracy and completeness of the information provided herein and the opinions stated herein are not guaranteed or warranted to produce any particular result, and the advice and strategies contained herein may not be suitable for every individual, especially individuals named ‘Fred’. Neither podbooks.com nor author shall be liable for any loss of profit or any other commercial damages, including without limitation special, incidental, consequential, or other damages. Copy Protection. In all cases, reselling or duplication of these materials without authorization is expressly forbidden.

podbooks.com [email protected] www.podbooks.com

Developed through the cooperation of: The Protocol Analysis Institute, LLC www.packet-level.com

Welcome to podbooks.com

The first podbook was released in May 1999 and introduced a new type of book to the technical industry -- pods are typically smaller and less formal than industry books. Pods address the immediate need for information on a variety of subjects ranging from IP addressing to ICMP traffic analysis to switched network design. Pods often come with supplemental materials (such as trace files). Over the next year, we will introduce new pods written by other authors who have specialized knowledge in the areas that are of greatest interest to our readers. If you are interested in writing a pod, please send us an email at [email protected]. We are also most interested in your feedback on this and all other pods. Please send your thoughts and comments directly to me at [email protected].

Enjoy!

Laura A. Chappell Founder, podbooks.com

i

About the Author

Laura Chappell, Sr. Protocol Analyst, is a highly-energetic speaker and author who has trained thousands of LAN/WAN administrators, engineers, technicians and developers. She admittedly ‘lives, eats and breathes’ packets and packet-level communications. She analyzes and documents network performance by providing onsite and offsite network analysis, troubleshooting and optimization services. Her international client base ranges from governments to healthcare to financial and banking institutions. Ms. Chappell is the author of “Introduction to Network Analysis” (podbooks.com), “Novell’s Guide to LAN/WAN Analysis: IPX/SPX,” “Novell’s Guide to Internet Access Solutions,” and “Novell’s Guide to Multiprotocol Internetworking” (Novell Press/IDG Books/Sybex Books). Ms. Chappell has also edited three Cisco Press titles, “Introduction to Cisco Router Configuration,” “Advanced Cisco Router Configuration,” and “Cisco Internetwork Troubleshooting” (Cisco Press/Macmillan Technical Publishing). Ms. Chappell can be reached at [email protected].

ii

For Scotty and Ginny again. With special thanks to Jill.

iii

About this pod…

This ‘pod’ is designed to provide fundamental information on TCP/IP analysis and troubleshooting. It defines the typical TCP/IP packet structures, basic protocol functionality and the core set of troubleshooting tools for network engineers. The trace files included with this book provide a basic set of communications to peruse as you work with the book. The trace files are provided in CAP format (Sniffer native format) and PRN format (in case you don’t have an analyzer handy). More files can be found online at www.packet-level.com. Chapter 1, “Basic TCP/IP Communications and Packet Structures,” examines how TCP/IP packets are built and sent onto the network. The port resolution, name resolution, route resolution and MAC address resolutions are defined in this chapter. At this point you learn the elements of the typical and not-so-typical TCP/IP packet structures. This chapter works hand-in-hand with Appendix B, “The Basic Flow of Data,” which contains basic knowledge for all network analysts and troubleshooters. Chapter 2, “Packet-Level Protocols,” focuses on the format and functionality of various TCP/IP packet structures. Emphasis is placed on the function and format of IP header structures, UDP header structures, TCP header structures, ICMP packets and ARP packets. These are the fundamental structures seen on all TCP/IP networks. The most exciting area of this chapter is the section that interprets the ICMP messages that you may see on your network (ok… exciting may be a bit strong for anyone other than a geeky analyst). Chapter 3, “Troubleshooting Tools and Techniques,” details the required tools needed for any analyst/troubleshooter. The tools listed include the very basic ones (ping and traceroute) as well as some more advanced tools, such as the Sniffer Pro and NetScanTools Pro 2000. (Additional details on network analysis can be found in the podbook “Introduction to Network Analysis.”) Appendix A provides the answers to the chapter tests. Appendix B, “The Basic Flow of Data” is a must-know area for anyone working in networking today. It details how packet contents are handled and affected by hubs, switches and routers. iv

Appendix C, “UDP/TCP Port List” is referred to in each of the chapters and included as a basic reference of the assigned port numbers from 1 to 1024. The complete list of port numbers (as of September 1999) is included with this book in the file portlist.pdf. Appendix D, “Disk Contents,” focuses on the trace files that are included with this book. If you downloaded this book, the trace files will unzip with the book itself. This appendix lists the trace files and provides a basic description of the processes shown in the traces. Appendix E, “Hex-Decimal-Binary” is a staple in most books dealing with analysis. You should certainly become acquainted with the scientific mode of the Windows calculator.

My clients have been my primary source of inspiration on creating these books. The ability to ‘plug in’ to a wide variety of network types and designs presents many challenges and unique opportunities for understanding communications in a variety of configurations.

v

Table of Contents CHAPTER 1: BASIC TCP/IP COMMUNICATIONS AND PACKET STRUCTURES...................................................... 1 THE BASIC TCP/IP STACK ELEMENTS ..................................................................................................................................... 2 BUILDING A TCP/IP PACKET .................................................................................................................................................. 4 Port Number Resolution .................................................................................................................................................... 7 Name Resolution ............................................................................................................................................................. 10 The Route Resolution Process ......................................................................................................................................... 11 The MAC Address Resolution Process ............................................................................................................................. 12 THE BASIC TCP/IP PACKET STRUCTURES.............................................................................................................................. 14 Overall Packet Structure ................................................................................................................................................. 14 UDP/IP Packet Structure................................................................................................................................................. 15 TCP/IP Packet Structure ................................................................................................................................................. 18 ARP Packet Structure ...................................................................................................................................................... 19 ICMP Packet Structure.................................................................................................................................................... 21 ROUTING AND SWITCHING IP PACKETS ................................................................................................................................. 23 Switching IP .................................................................................................................................................................... 23 Routing IP....................................................................................................................................................................... 24 5-MINUTE GLANCE AT IP ADDRESSING ................................................................................................................................. 27 IPv4 Addressing .............................................................................................................................................................. 27 Class-based Addressing .................................................................................................................................................................. 27 Subnetting.................................................................................................................................................................................. 29 Private Addresses ........................................................................................................................................................................... 29 Classless Addressing ...................................................................................................................................................................... 29

IPv6 Addressing .............................................................................................................................................................. 30 Unicast Addresses ........................................................................................................................................................... 31 Multicast Addresses......................................................................................................................................................... 31 Broadcast Addresses ....................................................................................................................................................... 32 Anycast Addresses........................................................................................................................................................... 32 TRACE FILES TO PRACTICE ON .............................................................................................................................................. 33 CHAPTER TEST ..................................................................................................................................................................... 34 EXTRA CREDIT: INTERPRETING A TRACE ............................................................................................................................... 36 CHAPTER 2: PACKET-LEVEL PROTOCOLS................................................................................................................. 37 THE FIRST STEP: CAPTURING PACKETS ................................................................................................................................. 39 ANALYZING YOUR IPV4 PACKETS......................................................................................................................................... 40 What’s IP For Anyway?................................................................................................................................................... 40 IP Header Fields/Functions............................................................................................................................................. 41 Version Field.................................................................................................................................................................................. 41 Header Length Field ....................................................................................................................................................................... 41 Type of Service Field...................................................................................................................................................................... 42 Total Length Field .......................................................................................................................................................................... 43 Identification Field ......................................................................................................................................................................... 43 Flags Field...................................................................................................................................................................................... 43 Fragment Offset Field..................................................................................................................................................................... 44

vi

Time to Live Field .......................................................................................................................................................................... 44 Protocol Field ................................................................................................................................................................................. 46 Header Checksum Field.................................................................................................................................................................. 46 Source Address Field ...................................................................................................................................................................... 47 Destination Address Field............................................................................................................................................................... 47 Options Field.................................................................................................................................................................................. 47

ANALYZING YOUR BROADCAST/MULTICAST TRAFFIC ............................................................................................................ 48 What are Broadcasts/Multicasts For Anyway?................................................................................................................. 48 How Many Broadcasts/Multicasts Are Too Many?........................................................................................................... 49 What Should You Do with Your Broadcast/Multicast Trace? ........................................................................................... 49 ANALYZING YOUR UDP-BASED COMMUNICATIONS ............................................................................................................... 50 What is UDP for Anyway? ............................................................................................................................................... 50 UDP Header Fields/Functions......................................................................................................................................... 50 Source Port Field ............................................................................................................................................................................ 51 Destination Port Field..................................................................................................................................................................... 51 Length Field ................................................................................................................................................................................... 51 Checksum Field.............................................................................................................................................................................. 51

What Can You Learn from Analyzing UDP Traffic?......................................................................................................... 53 ANALYZING YOUR TCP-BASED COMMUNICATIONS................................................................................................................ 54 What is TCP for Anyway?................................................................................................................................................ 54 TCP Header Fields/Functions ......................................................................................................................................... 55 Source Port Field ............................................................................................................................................................................ 55 Destination Port Field..................................................................................................................................................................... 55 Sequence Number Field.................................................................................................................................................................. 55 Acknowledgment Number Field...................................................................................................................................................... 55 Data Offset Field ............................................................................................................................................................................ 56 Flags Field...................................................................................................................................................................................... 56 Window Field................................................................................................................................................................................. 57 Checksum Field.............................................................................................................................................................................. 57 Urgent Pointer Field ....................................................................................................................................................................... 57 TCP Options Field(s)...................................................................................................................................................................... 58

Analyzing the TCP Startup/Handshake Process ............................................................................................................... 59 Analyzing the TCP Sequencing/Acknowledgment Process................................................................................................ 60 Analyzing the TCP Windowing Process ........................................................................................................................... 62 ANALYZING YOUR ARP COMMUNICATIONS .......................................................................................................................... 64 What is ARP for Anyway?................................................................................................................................................ 64 ARP Packet Fields/Functions .......................................................................................................................................... 64 Hardware Type ............................................................................................................................................................................... 65 Protocol Type ................................................................................................................................................................................. 66 Length of Hardware Address........................................................................................................................................................... 66 Length of Protocol Address ............................................................................................................................................................. 66 Opcode ........................................................................................................................................................................................... 66 Sender’s Hardware Address............................................................................................................................................................ 66 Sender’s Protocol Address .............................................................................................................................................................. 67 Target Hardware Address ............................................................................................................................................................... 67 Target Protocol Address.................................................................................................................................................................. 67

ANALYZING YOUR ICMP COMMUNICATIONS ........................................................................................................................ 68 What is ICMP Anyway?................................................................................................................................................... 68 ICMP Packet Fields/Functions ........................................................................................................................................ 68 Type ............................................................................................................................................................................................... 70 Code............................................................................................................................................................................................... 71 Checksum....................................................................................................................................................................................... 75

CHAPTER 2 TEST .................................................................................................................................................................. 77 EXTRA CREDIT: BUILD A TCP/IP PROTOCOL DISTRIBUTION CHART ....................................................................................... 79

vii

CHAPTER 3: TCP/IP TOOLS AND TECHNIQUES. ........................................................................................................ 80 TCP/IP PROBLEMS TO WATCH FOR ...................................................................................................................................... 81 Addressing Problems....................................................................................................................................................... 81 Routing Problems............................................................................................................................................................ 81 Service Discovery Problems ............................................................................................................................................ 82 TCP Connection Problems .............................................................................................................................................. 82 IP Fragmentation Problems............................................................................................................................................. 82 DHCP Problems.............................................................................................................................................................. 82 Denial of Service Attacks ................................................................................................................................................ 83 TROUBLESHOOTING TOOLS AND UTILITIES ............................................................................................................................ 84 Network/Protocol Analyzers ............................................................................................................................................ 84 General Utilities.............................................................................................................................................................. 87 Windows Utilities........................................................................................................................................................................... 88 Ping............................................................................................................................................................................................ 88 Traceroute (Tracert) ................................................................................................................................................................... 90 ARP ........................................................................................................................................................................................... 92 Route ......................................................................................................................................................................................... 92 Netstat........................................................................................................................................................................................ 94 Winipcfg .................................................................................................................................................................................... 95

COMBO-TOOLS YOU MUST HAVE!..................................................................................................................................... 97 AGNetTools..................................................................................................................................................................... 97 NPS NetScanTools Pro 2000 ........................................................................................................................................... 98 IP Addressing Calculators............................................................................................................................................. 105 TRACE FILES TO PRACTICE ON ............................................................................................................................................ 107 CHAPTER TEST ................................................................................................................................................................... 108 EXTRA CREDIT: TRACKING YOUR ICMP TRAFFIC ............................................................................................................... 110 Building Your Analysis Report....................................................................................................................................... 111 APPENDIX A...................................................................................................................................................................... 112 APPENDIX B...................................................................................................................................................................... 118 THE DAMNED OSI MODEL REVISITED ................................................................................................................................. 119 BASIC HUB/REPEATER COMMUNICATIONS ........................................................................................................................... 120 BASIC BRIDGE AND SWITCH COMMUNICATIONS (LAYER 2 DEVICES)..................................................................................... 121 BASIC ROUTER COMMUNICATIONS (LAYER 3 DEVICES)........................................................................................................ 122 EXCEPTIONS TO THE RULES…............................................................................................................................................. 124 APPENDIX C...................................................................................................................................................................... 125 APPENDIX D...................................................................................................................................................................... 138 SIMPLE PING..................................................................................................................................................................... 139 FRAGMENTED PING........................................................................................................................................................... 140 TCP HANDSHAKE .............................................................................................................................................................. 141 BASIC ARP ........................................................................................................................................................................ 142 BASIC IGMP ...................................................................................................................................................................... 143 DNS CONFIGURATION FAULT ............................................................................................................................................. 144 DHCP BOOTUP SEQUENCE ................................................................................................................................................. 145 APPENDIX E ...................................................................................................................................................................... 146

viii

Chapter 1.

Basic TCP/IP Communications and Packet Structures This chapter delves immediately into TCP/IP functionality as shown at the packet level. I always say that the best way to understand a protocol (or protocol stack) is to see it in action. We’ll start with a functionality diagram that covers the basic process of building a packet for transmission on a TCP/IP network. This process includes name resolution, address resolution and route resolution.

The Basic TCP/IP Stack Elements TCP/IP is definitely the protocol of choice these days. If you don’t have TCP/IP in-house, you’re probably getting ready to implement it in one form or another. Before we check out the communications and the packet structure of TCP/IP communications, let’s take a quick glance at the general TCP/IP stack elements as shown in Figure 1.1. Now, I didn’t put in all the application-layer elements such as FTP, HTTP, SNMP and all because it just simply wouldn’t fit. You can figure that IP-based applications, such as FTP, reside up there in the area of ‘Other Apps’ in my diagram.

Figure 1.1: The basic TCP/IP stack elements with the lovely ICMP highlighted.

If you really need to map this stack to the OSI model (yucko), you would place the IP block at the network layer and the UDP/TCP blocks at the transport layer. Just shove the other stuff above that (they don’t map exactly to the model – don’t push too hard, you might hurt your back). Here’s a quick bullet list defining these basic elements: n

Internet Protocol (IP) acts as the routable network layer protocol used to get packets from end-to-end. Routers use the information contained in the IP header to make their forwarding decisions.

TCP/IP Analysis and Troubleshooting Copyright  2000 podbooks.com

Chapter 1: Basic TCP/IP Communications and Packet Structures

2

n

User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) provide connectionless and connection-oriented transport layer services, respectively. The UDP and TCP headers define the process or application that has sent the packet.

n

Routing Information Protocol (RIP) and Open Shortest Path First (OSPF) provide network and path information exchanges between routing devices.

n

Internet Control Message Protocol (ICMP) can save your butt by providing reachability testing and feedback mechanisms. It serves as an all-purpose message delivery system for the protocols. We’ll focus on ICMP a lot in this podbook.

n

Domain Name Services (DNS) provides host name-to-IP address resolution services. When you type “telnet station3,” DNS resolves the name station3 to its IP address.

n

Dynamic Host Configuration Protocol (DHCP) provides dynamic client configuration and service discovery services – it ain’t just for IP address assignment folks. This is another protocol we’ll spend a fair amount of time looking into in this podbook.

n

Address Resolution Protocol (ARP) enables us to get the hardware address of the destination device or next hop along the path. ARP also enables us to check and see if our own IP address is already in use (duplicate address test).

As I said before, there are many more application elements to the entire complex TCP/IP protocol stack, but since this podbook is focusing on the basic elements of TCP/IP analysis and troubleshooting, we’ll look at the core elements of the stack. First, let’s focus on how a packet gets out onto the TCP/IP network – how do you go from a simple command, such as “ftp corpfs1” to creating and sending a packet that contains the address and application identification needed to get from end to end?



3

Building a TCP/IP Packet In the world of TCP/IP, we can use names or even nicknames to identify devices on the network. For example, if we want to perform file transfer to a server, we can type in “ftp corpfs1.” We don’t have to type in the entire IP address of the desired server – we can just use a symbolic name. Heck, we can even use aliases that allow us to address a single device by multiple names. Note There are several trace files included with this book so that you can see these packet structures. These trace files are in .CAP format which can be read by Sniffer and Etherpeek products. If you aren’t familiar with the basic steps of analysis mentioned in this chapter (including capture and display filtering), order “Introduction to Network Analysis” from podbooks.com (ISBN 1-893939-00-6). We’ve also included these trace files in PRN format in case you don’t have an analyzer handy. – Laura

Remember, however that you will eventually need to build a packet to send on the wire and there are certain requirements to building that packet. We must know: ♦ The port number of source and destination process/application ♦ The IP address of source and destination ♦ The MAC (media access control) of source and destination or next-hop router

In order to build this nice legal packet out of a request such as “ftp Herbie01,” the TCP/IP stack must undergo a series of resolutions. These resolutions are: ♦ Port resolution (‘ftp’ = port 20 or 21) ♦ Name resolution (‘Herbie01’ to 10.1.22.4) ♦ Route resolution (Herbie is local) ♦ MAC address resolution (Ethernet address for 10.1.22.4 is 0x00-00-1B-22-3E-11) Note Information displayed in hexadecimal format is preceded by ‘0x.’ – Laura

Let’s take a quick look at how TCP/IP communications work – we’ll do this focusing on our example in Figure 1.2. It is imperative that you understand the basic process of getting the packets built and onto the wire – this is the key fundamental info of network analysis – make sure you follow these steps all the way through.



4

Figure 1.2: The basic resolution process in TCP/IP.

TCP/IP uses a multi-step resolution process that is listed below: 1.

Resolve the application to the port number. In our example, the user has typed “ftp Herbie01.” The FTP protocol uses ports 20 and 21 (see Appendix C, “UDP/TCP Port Numbers”). Port 20 is used to transfer data and port 21 is used for commands (such as login and password submission functions). In our example, since the client is attempting to login, our stack would define port 21 as the appropriate port. This number would be placed in the TCP header of the packet that is sent out.

2.

Resolve the host name to the IP address. First, the local TCP/IP stack dictates that you must look at the local host file (if one exists). Next, it will send queries to the DNS (Domain Name System) server, if one has been configured for the local system. If there is no answer from the first DNS server on the configured DNS server list, the client will go to the next DNS server configured on the client. Still no answer? No more DNS servers configured? Then you can’t get there. In our example, we may see the client sending a DNS query to the first DNS server listed in the client’s local configuration. We should (if all goes well) see a reply that contains Herbie01’s IP address from a DNS server.

3.

Determine if the destination address indicates that the destination device is local or remote. Upon determination of the IP address, the client should place its own network mask on the destination address and compare the network portion of the destination address to the desired target’s network address portion.



5

In our example, Herbie01’s IP address is 10.1.22.2. Consider the possible results depending on the client’s IP address and subnet mask:

Source Address 10.1.22.4 10.1.22.4 10.2.22.4

Subnet Mask 255.0.0.0 255.255.0.0 255.255.0.0

Is Herbie01 Local or Remote? Local (go to step 4) Local (go to step 4) Remote (go to step 5)

At this point, there are two alternatives – find the MAC address of the destination (assumes the destination is local) or… find the MAC address of the next-hop router that can get the packet to the destination (assumes the destination is remote). 4.

If the destination device is local, resolve the MAC address of the local target. The client will check ARP cache for the information. If it does not exist, the client will send an ARP broadcast looking for the target’s hardware address.

5.

If the destination device is remote, perform route resolution to identify the appropriate next-hop router. The client will look in its local routing tables to determine if it has a host or network router entry for the target. If neither entry is available, the client will check for a default gateway entry. The default gateway offers a path of ‘blind faith’ – since the client does not have a route to the destination, it will send the packet to the default gateway and just hope the default gateway can figure out what to do with the packet. Default gateways typically either forward the packet on (if they have the best route to the destination) or send you an ICMP reply that points you to another local router that has the best route to the destination or tell you they have no idea where to send the packet.

6.

If the destination is remote and we know a next-hop router or default gateway that will be able to forward the packet, resolve the MAC address of the next-hop router or default gateway. Naturally, the client will check its ARP cache first. If the information does not exist in cache, the client will send an ARP broadcast out to get the MAC address of the next-hop router.

The client has slugged its way through the entire process and finally (whew!) spit that packet onto the wire. Thank goodness this process is transparent, eh? Ok… now why was that so damned important to know? Well, if you are analyzing a TCP/IP trace, you should be able to determine which processes have completed successfully. You should also be able to determine where the communication went wrong. For example, consider a user that complains that she cannot FTP to the desired server. By looking at the trace, you can see her system generate a DNS query and receive a reply with the IP address of the desired server. You can then see her system generate an ARP broadcast looking for the MAC address of the server – however, no ARP reply occurs. What could have gone wrong? n

The client can only ARP for devices that are local – perhaps the actual destination is remote (check her subnet mask and the server’s IP address).

n

Perhaps the server is local, but it is not replying to the ARP because it is not completely functional (duplicate IP address detected or simply down.



6

n

Maybe the IP address she received from the DNS server is incorrect (manually-built DNS host table is wrong).

When you look at the communications at the packet level, you can find the definitive answers to these questions – unlike ‘blind’ troubleshooting where you simply guess at the solution until one works out. In the next section, we check out each of these processes in more detail to define how they are used to build the packet for transmission.

Port Number Resolution When you type in “ftp corpfs1” your local TCP/IP stack needs to interpret the application name, FTP, and replace it with a number – a port number. This port number is placed in the UDP or TCP header of the packet. The port numbers are divided into three ranges: the Well Known Ports, the Registered Ports, and the Dynamic and/or Private Ports.

n

Well-known ports are assigned numbers 0 through 1023.

n

Registered ports are assigned numbers from 1024 through 49151.

n

Dynamic and/or private ports are assigned numbers from 49152 through 65535.

Well-known port numbers are assigned to the most commonly found processes and programs found on systems. For example, SNMP uses well known port numbers. Interestingly, IANA used to only allow 0-255 for well known ports, enabling application developers to register the higher numbers for application identification. For example, Novell registered 524 for NCP-over- IP (also referred to as pure IP). Now, IANA allows 0-1023 for the well known port numbers and applications are assigned number above 1023. Registered port numbers are used by third-party developers for end-to-end communications of their applications. For example, Cisco’s Hot Standby Router Protocol (HSRP) uses port 1985. HSRP provides transparent fault tolerance in the case of router failures. For more information on HSRP, refer to www.cisco.com. Dynamic port numbers, also referred to as private port numbers, are used on a temporary basis by an application or process. For example, an application can send data to a well known or registered port and open a dynamic port for the replies. Note that the dynamic port numbers once started with 1024, and sometimes we see some overlapping here in the numbers. For example, you might see a packet to destination port 21 (FTP command) from source port 1031 (registered to BBN). In this case, port 1031 is being used as a dynamic port. To work properly, the application that set up the dynamic port number would need to select a different port value if the BBN application was already running on that system.



7

The following list shows some of the more common port numbers used in TCP/IP communications. Appendix C, “UDP/TCP Port Numbers” provides the complete list of port numbers assigned by IANA. Process/Application Port (decimal) Character Generator (chargen) 19 DNS 53 DHCP/BOOTP Server 67 DHCP/BOOTP Client 68 HTTP 80 FTP data 20 FTP commands 21 NTP 123 POP3 110 SLP 427 SNMP Traps 160 SNMP 161 Telnet 23 Remember, the port number is identified in either the TCP or UDP header. Decent analyzers provide you with the interpretation of the port number value. If you want to view the actual number (in hex), highlight the port number field in the detailed decode window (as shown in Figure 1.3). The field location will be highlighted in the hex dump window. Translate the hex value to decimal to match up with the port listings in this book and at IANA. For example, in Figure 1.3, I highlighted the port field in the decode window. Let’s assume that the analyzer couldn’t translate the value into text. In that case, I would look into the corresponding area of the hex field and translate the value (0x01ab) over to decimal (427). Then I would look it up to see what application the port number was assigned to. Note What can you do if an application uses only dynamic port numbers and you can’t just look it up on a table to find out what application is on the wire? Typically, I’ll look for a larger packet (more likely to contain some data) and look into the data portion of the packet to see any recognizable patterns. Many times, you’ll see the name of the application or some text that identifies the application. – Laura



8

Figure 1.3: Use the ‘detail-to-hex’ association to locate the actual value of the port fields.

Name Resolution In the TCP/IP world, we can use a symbolic name when referring to and communicating with another device. For example, we may use the name ‘corpfs1’ to refer to the corporate server. This ‘device naming’ process enables us to use a more intuitive and user-friendly manner of locating devices. For example, which would you rather type: ftp corpfs1

…. or ….

ftp 10.2.3.1

Ok, inevitably one or more of you readers will opt for the more geeky IP address option – you know who you are – but try to think of the typical user on the network. They certainly won’t want to memorize a bunch of IP addresses. During the name resolution process, the local system tries to resolve the name supplied with the desired device’s IP address. In order to build the packet, the client must create an IP header with the appropriate source and destination IP addresses. The source IP address is easy to figure out –it’s the IP address of the system that’s sending the packet. The destination IP address however must be learned through the name resolution process.



9

The following steps are part of the name resolution process: 1.

Examine local cache to determine if you know the IP address of the desired device.

2.

Examine the local hosts file for the IP entry.

3.

Check for a DNS server entry.

Figure 1.4 shows a sample hosts file. As you can see, this file does not have an entry for corpfs1. In this case, the client will send a DNS query to the DNS server that is listed first in the client’s DNS server configuration.

Figure 1.4: Sample hosts file.

The Route Resolution Process The route resolution process is used to determine if the packet should be sent directly to the destination (the destination device is on same network) or the packet should be sent to a router (the destination device is on a different network). As mentioned earlier, the method of route resolution requires the source to apply its own network mask to the destination address. This process is performed internally – no traffic is generated during this process. The result of this process, however, should be evident from the MAC address resolution process that follows. If the source ARPs for the destination device’s hardware address, then the route resolution process indicated that the destination is local. If the source ARPs for a router’s hardware address, the route resolution process indicated that the destination is remote. Note The source may not ARP at all if it already has the hardware address in memory (cache). In this case, you can use the ARP command to read the ARP cache. See Chapter 3, “Troubleshooting Tools and Techniques” for more information about the ARP command. –Laura

It is not uncommon for problems to occur in the route resolution process. In Figure 1.5, we can see that the network mask placed on the source is 255.0.0.0. When we place this mask on the destination IP address of 10.1.22.4, it implies that the destination is local to the source (on the same network). The source will begin to ARP for the hardware address that is associated with 10.1.22.4.



10

Figure 1.5: A subnet mask error fools the route resolution process. Will 10.1.22.4 answer? No. ARP broadcasts are not forwarded by routers and no one else on the network is set up to reply on behalf of that device.

The MAC Address Resolution Process MAC address resolution is used to get the destination address for the MAC header. Up to this point, we only have the destination’s IP address and the knowledge whether that destination is local or remote. We now need to finish up the process and get the darned packet out there on the wire. Note The MAC header is also referred to as the data link header. It may also be referred to as its network type -- Ethernet header, Token Ring header, FDDI header, etc. -- Laura

The MAC address that is being sought will either be the destination device’s MAC address or the MAC address of the next-hop router along the path to the destination. As mentioned earlier, the route resolution process is used to determine which address should be sought. Either way, the MAC address resolution process is only looking for the hardware address of a local device. When a device is running the MAC address resolution process, it first looks in cache to see if it already has the hardware address of the destination IP device. If the MAC address is in cache, the source can go ahead and build the MAC header and send the packet on its way. Note ARP cache information has an aging timer to keep ‘stale’ information out. For example, in NT 5.0, the ARP Cache aging timer (ArpCacheLife) is set to 2 minutes on unused entries and 10 minutes on used entries. –Laura

If the address is not in cache, the source broadcasts an ARP request that contains the destination IP address. The reply will contain the hardware address of the device, as shown in Figure 1.6. Interestingly, the destination will update its own ARP cache to include the IP address and MAC address of the device that was looking for it. This is a logical step since most likely there will be a two-way conversation between the devices coming up, so the destination will need the local source's address eventually.



11

Figure 1.6: When the destination replies, it places its hardware address in the source address field.

Now that you are familiar with the data flows of TCP/IP and the points at which packets can be sent onto the wire, let’s examine some typical TCP/IP packet structures to get you familiar with the basic format. Note I have used Sniffer traces and screenshots in this book exclusively since Sniffer has better TCP/IP decodes than many other analyzers – with one exception, ICMP. In that case, we must do some decoding by hand (a good skill to master). Another good analyzer is Etherpeek (by the AG Group). More analyzers and troubleshooting tools are listed at www.packet-level.com. --Laura



12

The Basic TCP/IP Packet Structures By the time you finish this book, you should be intimately familiar with the TCP/IP packet structures… here are a few packets to whet your appetite. Chapter 2, “Packet-Level Protocols,” will examine the packet structures and functionality of the key protocol elements. Chapter 3, “Troubleshooting and Tools and Techniques” will give you a chance to identify communication problems based on the packet sequences. Note Several TCP/IP trace files are included with this book – more can be found online at www.packet-level.com in the Traces section. –Laura

Overall Packet Structure TCP/IP packets start with the MAC header -- Ethernet, Token Ring, FDDI, etc. The MAC header will include a protocol ID field (PID) that identifies IP as the upcoming protocol. Figure 1.7 shows a TCP/IP packet that uses the Ethernet II frame structure (by far, the most popular frame structure for TCP/IP communications). The Ethernet type (‘Ethertype’) field acts as the PID field and includes the value 0x0800 denoting IP as the upcoming protocol. TCP/IP communications also use the value 0x0806 to denote that ARP is the upcoming protocol.

Figure 1.7: The Type value 0x0800 indicates that IP is coming up next.



13

Note You can get a complete listing of Ethernet type numbers at www.iana.org. –Laura

UDP/IP Packet Structure Figure 1.8 shows a nice DNS packet. You’ll notice the Ethernet header (using the Ethernet II frame type) indicates the protocol type is 0x0800 (IP). The Ethernet header is followed by the IP header which contains the source and destination IP addresses. The IP header also contains a protocol field that identifies the next protocol coming up (UDP). Finally, the UDP header contains a destination port field that indicates the packet is destined for the DNS (Domain) process. Every header indicates what’s coming up next. Simple, eh? If you know the available field values, you too would know what’s coming up next. Note UDP and DNS communications are covered in greater detail in Chapter 2, “Packet-Level Protocols”. –Laura

In the DNS query packet shown in Figure 1.8, you’ll notice that the source port is different from the destination port. The source port is a dynamic port number (1031) whereas the destination port is a well known port number (53). This is typical of many communications. When the DNS server responds the port order is swapped. By looking in the packet shown in Figure 1.8, we can also see the source and destination IP address for this packet. The IP header also includes a Time to Live (TTL) count that denotes how many more hops/seconds this packet may have in its life. In Chapter 2, “Packet-Level Protocols” you will learn more about the specific fields of the IP header and the functionality of the TTL field. Note UDP-based communications are typically request/reply type of patterns, whereas TCPbased communications support the request/reply/reply pattern. For more information on pattern analysis, refer to the book entitled “Introduction to Network Analysis” from podbooks.com. –Laura



14

What’s coming up next?

Figure 1.8: A DNS query packet.



15

TCP/IP Packet Structure Figure 1.9 shows a TCP-based packet. As you can see, the Ethernet header indicates that an IP header is coming up next. The IP header indicates that TCP is coming up next (protocol 6 = TCP). The TCP header indicates that this packet is destined for port 524 (decimal). Do you recognize this port number? (It’s pretty recent in our industry.) This port number is assigned to Novell’s NetWare Core Protocol (NCP) for their communications over IP.


Figure 1.9: NCP uses the connection-oriented transport of TCP.



16

TCP has a much more detailed and complex header structure than UDP. This is an indication of how much more functionality TCP has than UDP. TCP offers connectionoriented communications and has fields specifically designed to identify the window size and ordering packets (sequence and acknowledgment number fields). See Chapter 2, "Packet-Level Protocols," for more information on TCP windowing and sequencing. Like UDP, however, TCP uses port fields to identify the application or process that is using the TCP transport. There are some de facto standards used to determine which transport protocol an application uses. For example, FTP uses TCP and Trivial FTP uses UDP. It is important to know, however, that the same ports numbers are registered for UDP use and TCP use. In other words, TCP port 20 is defined for FTP data use -- UDP port 20 can also be used for that purpose (although UDP is not the preferred transport).

ARP Packet Structure Most of your TCP/IP traffic is likely to be TCP-based or UDP-based communications. There are some protocols that do not use either transport, however. ARP doesn’t use IP (making ARP packets unroutable), UDP or TCP. The ARP data sits directly after the MAC header. Figure 1.10 shows an ARP packet that uses the Ethernet II frame structure.

Figure 1.10: ARP communications do not rely on a network layer or transport layer headers.

As you can see in Figure 1.10, the ARP packet structure does not rely on IP, UDP or TCP headers. The ARP request follows directly after the MAC header.



17

Now what does this strange packet structure mean? n

ARP communications must be local-only because they do not contain a routable header.

n

ARP communications are connectionless because they do not have any connectionoriented functionality.

n

ARP communications are not ‘IP’-based specifically.

Note For more information on ARP requests and replies, refer to Chapter 2, “Packet-Level Protocols.” --Laura

ICMP Packet Structure ICMP also uses an interesting packet structure. Figure 1.11 shows a very simple ICMP echo packet that is used during an IP ping operation. Does ICMP use UDP or TCP? Neither. ICMP (and several other protocols in the TCP/IP stack) sits directly behind the IP header. The protocol type field in the IP header indicates that ICMP is coming up next. Other protocols that use this odd structure include Open Shortest Path First (OSPF) and Internet Group Management Protocol (IGMP). Note Later in this podbook you’ll learn about these ICMP packets that contain two IP headers! Funky stuff, eh? --Laura

In the next section, you will see how these packets are handled by switches and routers and how the content of an IP-based packet is affected by routing processes. This information is defined further in Appendix B, "The Basic Flow of Data."



18


ICMP Header

ICMP Data (sometimes includes IP header of packet that triggered the ICMP reply)

Figure 1.11: An ICMP echo request packet.



19

Routing and Switching IP Packets Earlier in this chapter, we examined the steps used to create a packet and send it off to the ‘ether…’ How will this packet be affected by the network switches and routers? We’ll start by looking at how IP packets are handled in a switched network.

Switching IP Basic switches (and bridges) are considered layer 2 devices – they forward packets based on the destination MAC address. As a network ‘starts up,’ switches learn what MAC addresses reside off which ports based on the source address in the MAC header. Switches keep this information in a MAC address table. When packets come in to the switch on one port (referring to an interface in this sense), the switch examines the destination MAC address. The switch refers to its MAC address table to see if it knows which port the packet should be sent to. If an entry exists, the switch forwards the packet down the appropriate port. If no entry exists, the switch sends the packet down all ports, in hopes of learning the address during the reply phase of the communication. Figure 1.12 depicts a basic switched network. This network consists of four 12-port switches with devices on each switch port (except the ports used as uplinks/downlinks between switches).

Figure 1.12: Switched network design.

Basic switches forward all multicast and broadcast traffic down each port. This can be a problem on a large switched network. As you will learn later, routers are often used for broadcast control in TCP/IP networks. Which protocols in the TCP/IP stack use broadcast/multicast communications? ARP, RIP1, RIP2, OSPF, DHCP, SLP and IGMP are just a few examples. Spanning tree communications and vendor device discovery communications also use broadcast/multicast transmissions.



20

Note I highly recommend that you categorize your broadcast/multicast traffic. Stick an analyzer off any switch port and you’ll easily see your broadcast and multicast traffic. If you need a bit more information on basic analysis setups for switched networks and classification of broadcast/multicast traffic, refer to “Introduction to Network Analysis” by podbooks.com. –Laura

What happens if a broadcast storm occurs on a switched network? Look back at Figure 1.12 for example. What if a PC connected to the first switch suddenly begins broadcasting ARP packets continuously onto the network?

Many switches offer both layer 2 and layer 3 (routing) functionality these days. In a sense, they are ‘cross-dressing’ and can be easily mistaken for routers.

In the case of these ‘cross-dressing’ switches, their routing functionality of the switches enables the switch to keep broadcasts from flooding throughout a network.

Routing IP IP is a routable protocol. IP headers contain several critical fields used to get packets through an internetwork. IP headers contain source and destination network addresses as well as a Time To Live (TTL) field that defines the remaining lifetime of the packet in hops/seconds. The purpose of the source and destination addresses is to identify a specific device through an internetwork based on a network address and host address. The purpose of the TTL field is to ensure that packets do not circle endlessly on networks that contain a loop. Although the IP specification states that the TTL field is defined in ‘seconds,’ this value is commonly defined as a hop-based value since each router decrements the field value by 1 when packets are routed. Figure 1.13 shows a network that contains a loop between routers B, C and D.

Figure 1.13: This network contains a loop between routers B, C and D.



21

Routing information is exchanged between the routers using either RIP or OSPF. Each router maintains a route table that lists known networks and their distance away (RIP) or the cost to reach the network (OSPF). Note RIP and OSPF are referred to as routing protocols, while IP is referred to as a routed protocol. –Laura

The following steps are performed when a TCP/IP packet is processed by a router: 1. The router checks the incoming packet at the data link layer to ensure it is not corrupt. For example, the Ethernet FCS (frame check sequence) value is examined to determine if the packet is been damaged during transport. 2. The router examines the destination address to see if the packet is actually destined for the router (or the broadcast address or an accepted multicast address). I know… I know…. Seems like this should be Step 1. The IEEE 802.3 specification, however, indicates that packet validity should be checked before the MAC destination field value. Interesting, eh? 3. The router strips off the MAC header – now it holds a naked little IP packet in its hands. 4. The router examines the destination IP address and looks in its routing table for a host entry (a route entry that matches the entire destination address), a network entry (a route entry that matches the destination network address), or a default gateway (a place to send all packets destined to unknown addresses). 5. The router decrements the TTL value by 1 (if the packet is held in the router’s queue for more than a second, it should also be decremented by the number of seconds it was held). 6. The local router checks ARP cache or sends an ARP broadcast out the destination port to obtain the MAC address of the next-hop router or destination device. 7. The router builds the new MAC header, performs a hardware-layer cyclical redundancy check (CRC) and sends the packet out the appropriate port. Note Refer to Appendix B, “The Basic Flow of Data” for more examples of how data moves through hubbed, switched and routed networks. –Laura



22

5-Minute Glance at IP Addressing You cannot write about TCP/IP analysis and troubleshooting without mentioning the IP addressing system (heck… a high number of TCP/IP network problems are caused by faulty address schemes). So – although I do not want to turn this into a book on IP addressing, I will give you a quick review of the addressing fundamentals for class-based and classless addressing systems. We’ll also look at unicast, multicast, broadcast and anycast addressing implementations in this section. Note I highly recommend a book entitled, “IP Addressing” by Buck Graham (ISBN 0-12-2946308). Imagine -- over 300 pages filled with information and examples of IP addressing! –Laura

IPv4 Addressing IPv4 supports a four-byte address that can be split into two basic parts: network and host portion. If you have configured a large network that must be split up by a router at a later date, you can add a subnetwork portion to your address. A network/subnetwork mask is used to identify which part of an address is the network and subnetwork portion and which portion of an address is the host portion. Class-based Addressing

In class-based addressing, IP addresses are defined by class letters that help differentiate the network and host portion of the address (and therefore the size and scalability of the network). Default network masks are used to denote the portion of the address that should be used for the network address as opposed to the host address portion. n

Class A addresses start with numbers between 1 and 126. (“0” is not allowed and “127” is used for the loopback address.) Class A addresses have the default structure of N.H.H.H where “N” is the network address portion and “H” is the host ID portion.

n

Class B addresses start with numbers between 128 and 191. Class B addresses have the default structure of N.N.H.H where “N” is the network address portion and “H” is the host ID portion.

n

Class C addresses start with numbers between 192 and 223. Class C addresses have the default structure of N.N.N.H where “N” is the network address portion and “H” is the host ID portion.

Class A addresses have the most space in the host ID portion and can therefore have a greater number of individual hosts on a single network. Class C addresses have the most space in the network number portion and can offer more network addresses, but fewer hosts per network.



23

Subnetting In many instances, a network with a single address must be subnetted into two or more networks. For example, consider a network that used network address 10.0.0.0. When a router is connected to this network to split it in half, the single network address must be subnetted into two or more pieces. Subnetting is done by applying a network mask that grabs a portion of the host ID. For example, applying a network mask of 255.255.0.0 to network 10.0.0.0 will mask off the second byte for a subnet ID number. Now the address can be represented as N.S.H.H where “N” is the network number portion, “S” is the subnet number portion, and “H” is the host ID portion. Note RFC 1878 defines the various subnetting options for IPv4 addressing. One myth is that ‘all zero’ or ‘all one’ subnet numbers are not allowed. This limitation has been removed from the specification as obsolete, stating that “modern software will be able to use all definable networks.” RFCs can be found online at www.ietf.org. –Laura

Private Addresses

The following addresses have been reserved for private use. They can be used on the inside of a network address translation gateway (NAT) only – they cannot be used on any network that is connected directly to the Internet.

10.0.0.0 – 10.255.255.255 “10 net”(10/8 prefix) 172.16..0 – 172.31.255.255 (172.16/12 prefix) 192.168.0.0 – 192.168.255.255 (192.168/16 prefix)

‘10-net’ addresses are extremely common and offer tremendous flexibility in IP address assignment. Classless Addressing

Because of the inherent limitations forced by class-based addressing, we are gradually moving over to a world of classless addressing. In classless addressing, we do not use designators such as ‘A,’ ‘B,’ or ‘C’ to denote the size of a network or the length of its network address/host address portion. Instead, we provide a network address and a prefix number. The prefix number indicates how many bits are masked off for the network portion of the address. For example, the address 10.2.0.0 with a prefix of ‘/16’ contains the structure N.N.H.H (the first two bytes, or 16 bits, are masked off for the network portion). In another example, the host address 205.30.10.3 with a prefix of ‘/8’ can be considered to have the structure N.H.H.H where 205 is the network address and 30.10.3 is the host portion. This classless addressing structure is used to support CIDR (Classless Interdomain Routing) which uses route summarization (also referred to as route aggregation). Route summarization reduces the amount of routing update information that is exchanged and maintained by summarizing addresses based on common bit values in the addresses. TCP/IP Analysis and Troubleshooting Copyright  2000 podbooks.com


24

Note Check out RFC 1519 for supernetting information and there's also a nice article at www.internexis.com/mcp/article_9-30-98.htm. –Laura

Ok, that’s seriously all the coverage I’m going to give to IP addressing. There are a slew of resources on how IP addressing works. If you want more information (in a podbook form) on IP addressing and address designs, send us an email at [email protected] and we’ll check it out.

IPv6 Addressing So… you’re sick of the ugly IPv4 addressing scheme, eh? Well…. You might actually start appreciating it when you see the breakdown of an IPv6 address. In fact, I have often referred to my IPv6 address lecture as “IPv4 Appreciation 101.” . As you can see in Figure 1.14, an IPv6 address is 16 bytes long and represented in hexadecimal format with 2-byte sets separated by colons. Leading 0’s within the 2-byte sets can be dropped to shorten the address representation. In the case of an ‘all-0’ set, the set can be removed completely (this can only be done once within the address). If there are several adjoining ‘all 0’ sets, they can all be removed along with the embedded colons within the sets.

Figure 1.14: The elements of an IPv6 address.

So what’s the big advantage of IPv6 addressing? Well… for one thing, the specification for IPv6 addressing dictates that IPv6 devices should be able to auto detect their local network and self-assign the host ID portion of their address. Imagine that…. No more assignment of addresses manually or through DHCP! Gee… those Internet architects are pretty smart. Here are some RFCs to check out for more IPv6 information:. n

RFC 2373, IP Version 6 Addressing Architecture

n

RFC 2732, Format for Literal IPv6 Addresses in URLs

n

RFC 2529, Transmission of IPv6 over IPv4 Domains without Explicit Tunnels



25

n

RFC 2526, Reserved IPv6 Subnet Anycast Addresses

n

RFC 2470, Transmission of IPv6 Packets over Token Ring Networks

n

RFC 2467, Transmission of IPv6 Packets over FDDI Networks

n

RFC 2464, Transmission of IPv6 Packets over Ethernet Networks

n

RFC 2463, Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification

n

RFC 2428, FTP Extensions for IPv6 and NATs

n

RFC 2374, An IPv6 Aggregatable Global Unicast Address Format

n

RFC 2365, Administratively Scoped IP Multicast

Unicast Addresses Unicast addresses define a single device on the internetwork. They are unique for each host. When you send a packet to a unicast address, other devices do not process the packet (except to route the packet as required). Most of your network traffic is probably unicast traffic.

Multicast Addresses Multicast traffic is destined for a group of devices. For example, the IP address 224.0.0.5 can be used to address all OSPF routers and the address 224.0.0.9 can be used to address all RIP2 routers. The following is a list of some of the more commonly seen multicast addresses for TCP/IP. You can keep up with the latest list at www.iana.org or www.packet-level.com. 224.0.0.1 All Systems on this Subnet 224.0.0.2 All Routers on this Subnet 224.0.0.3 Unassigned 224.0.0.4 DVMRP Routers 224.0.0.5 All OSPF Routers 224.0.0.6 OSPF Designated Routers 224.0.0.9 RIP2 Routers 224.0.0.10 IGRP Routers 224.0.0.11 Mobile-Agents 224.0.0.12 DHCP Server/Relay Agent 224.0.0.22 IGMP 224.0.1.1 NTP (Network Time Protocol) 224.0.1.22 SVRLOC TCP/IP Analysis and Troubleshooting Copyright  2000 podbooks.com


26

224.0.1.24 Microsoft-DS 224.0.1.33 RSVP-encap-1 224.0.1.34 RSVP-encap-2 224.0.1.35 SVRLOC-Directory Agents 224.0.1.39 Cisco-rp-announce 224.0.1.40 Cisco-rp-discovery

Broadcast Addresses Broadcasts are used to reach all devices on a network or subnetwork. There are two ‘flavors’ of broadcasting: an all-nets broadcast and a subnet broadcast. All-nets broadcast packets are addressed to 255.255.255.255 in the IP header. Literally, the packets are addressed to all networks. Does that mean that when you analyze your network you should see broadcast packets coming from other networks onto your network? Absolutely not. Routers should not forward broadcast packets (although many routers can be configured to allow broadcast forwarding – yuck). Subnet broadcasts contain the subnetwork address in the broadcast packet. For example, the subnet broadcast designation on network 10.0.0.0 (prefix 8) would be 10.255.255.255. On a network 168.23.0.0 (prefix 16), the subnet broadcast would be 168.23.255.255. Typically the all-nets broadcast and subnet broadcast have the same effect on the network traffic flow –one is more precisely addressed, however.

Anycast Addresses In the world of IPv6, we have a new addressing type to consider – anycast. Anycast addressing is used to locate on device (the nearest) of a group of devices. You can think of anycasting as a technique used to address a single device within a group. As of March 1999, when RFC 2526 (Reserved IPv6 Subnet Anycast Addresses) was written, only one anycast address had been assigned – 126: mobile IPv6 Home-Agents.



27

Trace Files to Practice On We have a number of trace files at www.packet-level.com. I suggest that you download and review these files. Keep checking out there for more files as we release our lab files (with some documentation) publicly. When you view these trace files, remember to focus on the summary portion first – get a general feel for the traffic and look for recognizable patterns. Then begin to focus on one conversation. Make sure you get a good screen capture utility that will help you document your findings in a graphical manner, as well. Note If you have a suggestion of a trace that you’d like to see, send it to [email protected]. –Laura

The following lists some of the trace files that are included with this book and related to this chapter: ♦ ARP1.CAP/ARP1.PRN – This trace shows a typical ARP lookup sequence. The client (10.0.0.1) is looking for the hardware address of 10.0.0.99. Notice the structure of the packets – no IP or UDP/TCP headers are in use. ♦ IGMP1.CAP/IGMP1.PRN – This trace only contains two packets. Packet #1 is a multicast to all routers on this subnet (224.0.0.2). ♦ PING1.CAP/PING1.PRN – This trace shows a simple ICMP echo request/reply sequence. Notice the structure of the ICMP packets – no UDP/TCP headers are in use. Now it’s time to take your first chapter test. This test will cover the topics defined in this chapter.



28

Chapter Test This test covers the basic process of building an IP packet, the typical packet structures and addressing principals. Do your best. The answers are in Appendix A – but don’t cheat – really give it a good try before looking up the answers.

1.1

What are the two most common transport protocols used in the TCP/IP suite? _______________ _______________

1.2

What is the purpose of ARP? _________________________________________________________

1.3

1.4

Which of the following source devices should ARP for the listed destination? Source

Destination

ARP?

10.1.2.6 (prefix 8)

10.1.6.1 (prefix 8)

Yes

No

10.1.2.6 (prefix 8)

11.2.22.4 (prefix 8)

Yes

No

130.57.26.4 (prefix 24)

130.57.22.6 (prefix 24) Yes

No

127.2.4.4 (prefix 8)

127.0.2.1 (prefix 8)

No

Yes

Name at least three resolution processes that are used to get an IP packet out onto the network when a user types ‘ftp server24.” _____________________ _____________________ _____________________

1.5

Which packet types are not routable? a.

TCP

b.

ARP

c.

DHCP broadcast

d.

UDP

e.

FTP



29

1.6

1.7

1.8

1.9

Which headers are used for ICMP communications? a.

MAC header

b.

UDP

c.

TCP

d.

IP

e.

ARP

Which headers are used for ARP communications? a.

MAC header

b.

UDP

c.

TCP

d.

IP

e.

ICMP

Which statement about layer 2 switched IP traffic is true? a.

TTL is incremented by 1 when packets are switched.

b.

MAC headers are stripped off/replaced by the switch.

c.

IP broadcasts are not forwarded by switches.

d.

Switches don’t examine the contents of the IP header.

You have captured a packet with the following values: n

Ethernet Type 0x0806

n

Destination MAC address 0xFF-FF-FF-FF-FF-FF

What is the purpose of this packet? ________________________________________________________

1.10 What MAC header field is used to identify packets as IP-based? __________________________



30

Extra Credit: Interpreting a Trace 1.11 Open the file MISC1.CAP/MISC1/PRN. Answer the following questions:

What address is packet #1 looking for? __________________________________________________

Is there an answer to ARP packet #1? __________________________________________________

Is DHCP using a subnet or all-nets broadcast in this trace? __________________________________________________

What field in the IP header denotes that packet #51 is a TCP packet? __________________________________________________

Are there any multicast packets in this trace? __________________________________________________

What upper layer protocol is seen in packets 94-100? __________________________________________________



31

Chapter 2.

Packet-Level Protocols This chapter delves into each of the primary protocols seen in the TCP/IP stack -IP, TCP, UDP, ARP, and ICMP. It provides you with the basic functionality of each protocol and gives you a look at what happens at the packet-level with each of these protocols. Future titles will provide additional packet-level analysis information on other applications/protocols within the TCP/IP suite. Note If you want to start looking into the other protocols, grab some packets and then check out their RFCs for the details of how those protocols should work. It’s always nice to have a visual representation of the often-dry RFCs. If you’d like more information on the future releases of packet-level podbooks, join the mailing list over at www.packetlevel.com. –Laura

In this section, we’ll look at each of these protocols at the packet level -- this book is not intended to focus on advanced packet-level analysis. It is, however, designed to provide a basic understanding of how TCP/IP communications typically look on the cable while providing references for more in-depth study. Between this chapter and Chapter 3, “Troubleshooting Tools and Techniques,” you should be comfortable with the functionality and packet structures seen in the TCP/IP environment. Note This is the time to fire up your analyzer and follow along using the trace files that accompany this book. Additional trace files may be found online at www.packetlevel.com. –Laura

Each of the protocols listed in this chapter includes pointers to additional reference materials on the protocols (in many cases, we list the RFCs that deal with the protocol). This enables you to research specific protocols in more depth.


Chapter 2: Packet-Level Protocols

33

The First Step: Capturing Packets To get the most out of this chapter, you should have some traffic to look at with a protocol analyzer as you peruse the protocols being examined. Set up and capture packets using the following capture filters to follow along with the protocols shown in this chapter.

Filter on:

Capture at least:

All TCP/IP Traffic Broadcast/Multicast Traffic All UDP Traffic All TCP Traffic All ARP Traffic All ICMP Traffic All RIP Traffic (if using RIP) All OSPF Traffic (if using OSPF) All DNS Traffic All DHCP Traffic (if using DHCP)

1000 packets 250 packets 500 packets 500 packets 50 packets one hour’s worth 15 minutes’ worth 15 minutes’ worth 100 packets 100 packets

Note Ok… it’s the moment of truth folks. If your analyzer does not enable you to make these capture filters easily – get rid of it and get yourself a decent analyzer. Yes – those of you who have LANalyzer for Windows (LZFW) – it’s time to buckle down and get yourself a real analyzer like Sniffer Pro or Etherpeek. –Laura

Some traces are on the diskette that accompanies this book. If you downloaded this book, the trace files are included in the book zip file. The trace files are listed in Appendix D, “Disk Contents.”. Refer to the podbook, “Introduction to Network Analysis” available at www.podbooks.com for more details on analyzer elements including capture and display filters.



34

Analyzing Your IPv4 Packets In this section we examine the purpose and content of an IPv4 packet (hereinafter referred to simply as IP) and define the functionality of each field contained therein.

What’s IP For Anyway? IP is a routable protocol used to get packets through an internetwork. IP headers include network source and destination addresses, a counter for the remaining lifetime of the packet, and an identifier for the upcoming protocol. Routers (and other layer 3 devices) forward packets based on the contents of the IP header. Refer to Figure 2.1 below to see a basic IP header.

Figure 2.1 A lovely IP header.

By looking briefly at this packet we can tell that it is from host 10.0.0.99 to host 10.0.0.1. What else can you tell about this packet (go ahead – write your observations here.) Observation #1 _________________________________________ Observation #2 _________________________________________



35

Observation #3 _________________________________________ Observation #4 _________________________________________ Observation #5 _________________________________________ Observation #6 _________________________________________

Let me tell you what I see when I see this packet – Observation #1: This packet is IP version 4. Observation #2: This packet has probably not crossed a router yet. Observation #3: This packet has no data in it. Observation #4: This packet does not use any special service routes. Observation #5: This packet cannot be fragmented. Observation #6: This communication is connection-oriented. A few of the observations are simple to understand (#1, #4, and #5, perhaps). The others (#2, #3, and #6 perhaps) might be a bit tough to figure out. You need to understand the purpose and interpretation of the fields to make those observations. In this next section (and following each protocol subtitle in this section), we’ll look at the purpose of the fields in each protocol’s packet. Note In December 1999 we made a geeky protocol poster that defines the purpose/functionality of the IPv4 header. You can get more information on the poster or order it online at www.podbooks.com. – Laura

IP Header Fields/Functions This section details the header fields and their functions. For more details on each field, refer to RFC 791. Version Field

The first field in the IP header is the version field. We are currently at version 4 – version 6 is in development. Header Length Field

This field is also referred to as the “Internet Header Length” field or IHL. This field denotes the length of the IP header only – just the IP header. This is necessary because the IP header can support options and therefore, may be varying lengths. This field value is provided in multiples of 4 bytes… for example, the actual decimal decode will be 5. The analyzers multiply that value by 4 bytes to come up with the true IP header length value of 20 bytes. In Figure 2.1, we can see the IP header is 20 bytes long.



36

Note In my experience, the Options are rarely used – you can count on 20 byte IP headers as the typical size IP header. –Laura

Type of Service Field

The Type of Service (TOS) field actually has two components: Precedence and Type of Service. Precedence is defined in the first three bits and may be used by routers to prioritize traffic that goes through queues. Type of Service is defined in the next four bits and may be used by routers to follow a specified path type. The last bit of the entire TOS field is reserved and set at 0. Here is a quick list of the possible settings in the Precedence/TOS bits: Precedence 111 Network Control 110 Internetwork Control 101 CRITIC/ECP 100 Flash Override 011 Flash 010 Immediate 001 Priority 000 Routine Type of Service Bits 0000 Default (no specific route defined) 0001 Minimize Monetary Cost 0010 Maximize Reliability 0100 Maximize Throughput 1000 Minimize Delay 1111 Maximize Security Ok, so if you saw a packet that had the binary value 00010000 in the TOS field, you should know that the packet requires routine services (000) through the lowest delay path (1000). Interestingly, many analyzers only show the four basic service types (default, delay, throughput and reliability). Note That whole TOS stuff is very exciting to explore. Imagine if you could prioritize all the traffic on the network – there are great advantages to that type of communication style, but there are also some pitfalls. For example, how do you keep low-priority traffic from timing out? If you are familiar with Cisco’s prioritization schemes, you will see a number of these issues addressed – very interesting stuff. –Laura

RFC 2474, “Definition of Differentiated Service Field (DS Field) in the IPv4 and IPv6 Headers” recommends a complete redefinition of the TOS field values and functions. Most likely you will find this field set at 00000000 (default).



37

Total Length Field

Length fields galore! This field defines the length of the IP header and any valid data (does not include any data link padding). In the example shown in Figure 2.1, the total length is 40 bytes. The first 20 bytes of that is the IP header – this indicates that the remaining packet length is 20 bytes. (TCP headers are at least 20 bytes long, hence my statement that there is no data in the packet –after the TCP header -- in observation #3). Identification Field

Each individual packet is given a unique ID value when it is sent. If the packet must be fragmented to fit on a network that supports a smaller packet size, the same ID number will be placed in each fragment. That’s how we know that these fragments are part of the same ‘set’ of data. Note If you’d like to see a fragmented packet, check out the PINGFRAG.CAP/PINGFRAG.PRN files included with this book. This trace shows a fragmented ICMP echo packet. –Laura

Flags Field

The Flags field is actually three bits in length and has the following bit value assignments: Bit 0:

Reserved – set to 0.

Bit 1:

The Don’t Fragment Bit (0=may fragment; 1=don’t fragment)

Bit 2:

The More Fragments Bit (0=last fragment; 1=more to come)

Typically, fragmentation is allowed. An application may for some reason decide not to allow fragmentation. If so, it will set the Don’t Fragment bit to 1. If fragmentation is allowed and a packet must be fragmented to cross a network that supports a smaller packet size (or Maximum Transmission Unit – MTU), the Don’t Fragment bit would be set to 0. When the packet is split into multiple fragments (three fragments, for example) the first and second fragments will have the More Fragments to Come bit set to 1. The last fragment will have the More Fragments bit set to 0 to indicate that it is the final fragment in the set. Note Ok, down-and-dirty – is fragmentation a good thing? Sometimes. Of course, if you’ve mixed media types (Ethernet and Token Ring, for example), you may need fragmentation to get that big fat 4,096 byte packet through that little 1,518-byte Ethernet pipe by splitting it up into multiple packets. Fragmentation does take time and extra overhead however. Basically, you’ve unloaded the bus and put everyone on scooters to get to the destination. Now… you Ethernet folks shouldn’t be offended by the ‘scooter’ reference here – my experience is that scooters and buses travel at the same rate, ok? For more information on fragmentation – look at the Time to Live field information later in this section. –Laura



38

Fragment Offset Field

If the packet is a fragment, this field shows where to place this packet’s data when the fragments are being reassembled into a single packet again (at the destination device). Just to make it less obvious to you, this field gives the offset in 8-byte values. For example, the first fragment may have an offset of 0 and contain 1400 bytes of data (not including any headers). The second fragment would have offset value 175 (175 x 8 = 1400). This field is only in use if the packet is a fragment. Time to Live Field

This field denotes the remaining lifetime (in seconds and hops through routers) of the packet. Typical starting TTL values are 32, 60, and 128. (That’s where I figured that the packet in Figure 2.1 had not crossed a router in Observation #2. Of course, you can also look at the source and destination IP addresses to come up with that guess.) Default TTL values are incorporated into the vendor's TCP/IP stack. Applications (such as traceroute) can override these defaults as desired. Each time a packet is forwarded by a router, the router must decrement the TTL field by 1. If the router must hold the packet in a queue for an extended period of time (longer than one second), it must decrement that TTL value by the number of seconds the packet was held in the queue. Ugly situation there – we really only want to see a decrement of 1 each time we hop through a router. If a packet with TTL=1 arrives at a router, the router must discard the packet because it cannot decrement the TTL to 0 and forward the packet. If a packet with TTL=1 arrives at a host, what should the host do? Process the packet, of course. The hosts do not need to decrement the TTL value upon receipt. Note Interestingly, when a packet gets fragmented, all fragments are given the same TTL value. If they take different paths through a network, they may end up at the destination with varying TTL values. When the first fragment arrives at the destination, however, the destination host will begin counting down from the TTL value of that packet. All fragments must arrive before that timer expires or the fragment set is considered ‘incomplete’ and unusable. The destination would send an ICMP reply to the source stating that the packet’s lifetime had expired. –Laura

Chapter 3, “Troubleshooting Tools and Techniques,” explains how traceroute uses the TTL value and the timeout process to trace the end-to-end path through and internetwork.



39

Protocol Field

Every decent header should have some field that defines what is coming up next. For example, in a TCP/IP packet, an Ethernet header should have a Protocol ID field to indicate that IP is coming up next. The IP header, likewise, has a Protocol field to indicate what is coming up next. The more commonly seen values in the protocol field are listed below: Num.

Description

1 2 6 8 9 17 45 88 89

ICMP IGMP TCP EGP Any private interior gateway, such as Cisco’s IGRP UDP IDRP Cisco EIGRP OSPF

The values 130-254 are unassigned (as of January 1, 2000) and 255 is reserved by IANA. To obtain the most current list of Protocol field values, visit www.iana.org. Header Checksum Field

The IP header checksum field provides error detection on the contents of the IP header only – this field does not cover the contents of the packet other than the IP header. This checksum does not include the checksum field itself in the calculation, of course. Some folks ask why there is another error detection mechanism when the packet is already checked through the data link error detection mechanism (such as the Ethernet CRC). Simple – when a nice lovely Ethernet packet, for example, arrives at a router, the router performs the data link CRC to ensure the packet has not been corrupted along the way. After the packet passes the CRC check and is considered ‘good,’ the router ruthlessly strips off the data link header – leaving behind a naked little network-layer packet. If the packet did not have any error detection process in place, a nasty router could mess around with the data and then apply a new data link header (with a new CRC on the invalid packet) and send the packet on. We definitely want a method to check router packet corruption. Note Interestingly, if you are accustomed to the IPX world – the old IPX over Ethernet_802.3 (raw) frame type did not allow the use of the IPX checksum feature – therefore, with that protocol and that Ethernet header structure you could not identify packet corruption caused by routers. –Laura



40

Source Address Field

This is the IP address of the device that sent the packet. In some cases, such as during the DHCP bootup process, the client may not know its IP address, so it may use 0.0.0.0 in this field. This field cannot contain a multicast or broadcast address. Destination Address Field

This field can include a unicast, multicast, broadcast (and in the case of IPv6, anycast) address. This is the final destination of the packet. Options Field

The IP header can be extended by a number of options (although these options are not often used). If the header is extended with options, those options must end on a 4-byte boundary because the Internet Header Length (IHL) field defines the header length in 4-byte boundaries. The following list only displays a partial set of options. For the complete list, refer to www.iana.org. Number 0 3 4 7 9

Name End of Options List Loose Source Route Time Stamp Record Route Strict Source Route

Note All the options listed above are defined further in RFC 791. –Laura

Ok, now go out and get some of your own. Capture a conversation between two devices and note the following details in your trace: •

What source/destination addresses are used for the communication?

•

What TTL value is used in each direction?

•

How does the Identification field increment?

•

What protocol typically follows the IP header (UDP? TCP? Another?)

•

Are there any fragmented packets in the exchange?

Alternately, you could open one of the trace files that accompany this book. Refer to Appendix D, “Disk Contents” to find out more about the files.



41

Analyzing Your Broadcast/Multicast Traffic Once again, now is the time to set up a capture filter for only broadcast and multicast traffic on your network. Compare your broadcast/multicast traffic with the traffic types defined in this section.

What are Broadcasts/Multicasts For Anyway? There are two basic types of broadcasts/multicasts on the network: lookups and announcements. n

An example of a lookup would be the discovery broadcast that a DHCP client sends when it boots up. It is looking for a DHCP server. Another example of a lookup broadcast is the ARP MAC-to-IP address resolution process.

n

An example of an announcement would be a RIPv1 broadcast or RIPv2 multicast. These packets are unsolicited announcements about known routes.

The ugly traffic is the second type – the announcements. Take a look at Figure 2.2. This is a graphical representation of a network’s most popular destination addresses (Top 10 Hosts by ‘In Packets’). As you can see, the most popular destination address on this network is broadcast (all-nets broadcast). The second most popular destination is a subnet broadcast. In fact, the two broadcast sets account for almost 50% of the traffic on this network.

Figure 2.2: The most popular destinations are broadcasts (all-nets and subnet broadcasts).



42

How Many Broadcasts/Multicasts Are Too Many? Aaaah…. This question falls under that ‘How High is High?” “How Blue is Blue?” and “How Many Collisions are Too Many?” question category. Let’s look at it this way –the broadcasts/multicasts can take up valuable bandwidth and processing power in the receiving devices. Unsolicited broadcasts (the announcement type) should not account for more than 10% of all traffic during the hours that data exchange is occurring. Now that I’ve made that statement, you must think about the traffic on your network. If you take a trace from midnight to 2:00 a.m. and view the pie chart, it might look pretty disturbing with broadcasts/multicasts accounting for 90% or more of the traffic. But think about that folks – your network is probably quiet at that hour – nothing except periodic broadcasts and multicasts floating around. In this case, the number of broadcasts/multicasts is not a big problem. Make sure you look at the broadcast/multicast rate during the busiest time of the day to get an idea if the rate is too high (over 10% of the traffic).

What Should You Do with Your Broadcast/Multicast Trace? The first thing you should do is figure out what type of broadcasts/multicasts your network is experiencing. Are they routing broadcasts? Are they unanswered ARPs? Many times you can figure out ways to decrease your broadcast traffic simply by figuring out what type of broadcasts they are. Note In one instance, I examined a network that had an extremely high broadcast rate. When I examined the trace, I discovered thousands of unanswered ARPs coming from a couple of machines. We found that those machines had a new HP print driver that attempted to locate all the print servers on bootup using the ARP process. Naturally, the print servers that were on the other networks would not hear or answer the ARPs, so the print driver process would repeat the ARP continuously. Very ugly traffic patterns on the network. –Laura



43

Analyzing Your UDP-based Communications Chances are good that if you captured a trace of broadcast/multicast traffic you already have a lot of UDP-based communications to look at. Broadcasts and multicasts are typically connectionless.

What is UDP for Anyway? UDP is used for connectionless transport. The UDP header identifies the application in the port fields. Because it uses a simplistic little 8-byte header that consists of four fields, as shown in Figure 2.3, UDP rarely causes us much trouble.

Figure 2.3: The IP protocol field value 17 indicates that the UDP header is coming up next.

UDP is defined in RFC 768.

UDP Header Fields/Functions The UDP header is defined with the value 17 (decimal) in the IP header Protocol field. The UDP header only contains four fields. Source Port Field

The source port fields are extremely important in UDP and TCP headers because they define the applications or processes that are sending the packet. Refer to Appendix C for a partial list of the assigned port numbers and a definition of the three types of port numbers found in UDP and TCP headers.



44

Appendix C is a valuable reference in your analysis procedures. You should be familiar with some of the more common port numbers. A more complete list of port numbers can be found in the file PORTLIST.PDF that accompanies this book. The source of the packet shown in Figure 2.3 is the BOOTP/DHCP server process (port number 67). Destination Port Field

This field value defines the destination application or process for the packet. In some instances the source and destination port numbers are the same for client and server processes. In other instances, you may find a separate and unique number for the client and server process (as in the case of DHCP). Still another variation is to allow the client to use dynamic port numbers for their side of the communications and a well known port number for the server side of the communications. Length Field

The length field defines the length of the packet from the UDP header to the end of valid data (not including any data link padding, if required). This is a redundant field and really quite unnecessary in the whole communication process. Consider the following three length fields and their interpretations: •

IP Header Length = 5 (denoted in 4 byte increments) The IP header is 20 bytes long.

•

IP Total Length Field = 329 bytes The data after the IP header is 309 bytes – remember, 20 bytes is the IP header.

•

UDP Length Field = 309 The data after the IP header (including the UDP header) is 309 bytes. Duh…. Didn’t we just learn this from the Total Length Field in the IP header? Subtract the 8-byte UDP header and you know there are 301 bytes of data.

Checksum Field

Ok… this is where UDP can be a bit strange. The checksum is performed on the contents of the UDP header (except the checksum field itself), the data and a pseudo-header that is derived from the IP header. That funky pseudo-header is made up from the IP header source address field, destination address field, protocol field and UDP length field. Wow… are you impressed? UDP-based communications do not always require a checksum – sometimes you will see this field set to all zeros (0000).



45

What Can You Learn from Analyzing UDP Traffic? The most interesting areas of the UDP traffic are the source and destination port numbers. You will also notice that broadcasts/multicasts typically use UDP for their transport type. Capture a few hundred UDP packets and break down the traffic type by the applications or processes in use. Look at Figure 2.4, for example.

Figure 2.4: Most of this UDP traffic is NetBIOS.

Note It’s no secret to many of you that I dislike NetBIOS. The chatty, broadcast nature of this protocol makes it quite unattractive. –Laura



46

Analyzing Your TCP-based Communications TCP is much more interesting and complex than UDP communication. The primary areas of interest when analyzing TCP communications are: •

The startup sequence (handshake)

•

The sequence/acknowledgment process

•

The window size

Let’s start with a view of what TCP is all about.

What is TCP for Anyway? TCP offers a connection-oriented transport that begins with a handshake between two devices. Data is sequenced and acknowledged to ensure proper delivery. Where UDP may be considered similar to the standard mail system, TCP would be considered similar to Federal Express. Figure 2.5 shows a TCP packet. TCP is covered in RFC 793.

Figure 2.5: The TCP header structure is much more complex than the UDP header structure.

TCP supports windowing – the process of sending numerous data packets in sequence without waiting for an intervening acknowledgment. The size of the window is based on the amount of traffic the network can handle (the network congestion rate) and the receiver’s available buffer space. We will cover TCP windowing in greater detail a little later in this section. First, let’s look at the TCP header and its functions. TCP/IP Analysis and Troubleshooting Copyright  2000 podbooks.com


47

TCP Header Fields/Functions Examine the TCP header structure shown in Figure 2.5. You should be able to understand a few characteristics of the TCP header, such as the source and destination port values. Now let’s examine the other aspects of the TCP header structure. . Source Port Field

See UDP source port field definition, Appendix C and the PORTLIST.PDF file that accompanies this book Destination Port Field

See UDP source destination field definition, Appendix C and the PORTLIST.PDF file that accompanies this book. Sequence Number Field

This field contains a number that uniquely identifies the TCP segment (at the transport layer, we refer to the data that is preceded by the TCP header as a ‘segment’). This sequence number provides an identifier that enables TCP receivers to identify when parts of a communication stream are missing. The sequence number increments by the number of data bytes contained in the packet. For example, in Figure 2.5, the current TCP sequence number is 2288714 and the packet contains 11 bytes of data (as seen at the bottom of the TCP header). The sequence number this host will use in the next TCP header it sends will be 2288725 (2288714 plus 11). The screen shot shows a Sniffer interpretation of a TCP header. In their interpretation, they have added a line ‘Next Expected Sequence Number’ that does not truly appear in the packet. They have calculated this value based on the TCP windowing scheme, covered later in this section. Each TCP device self-assigns its own sequence number. The process of incrementing this sequence number is covered further under the “TCP Windowing” heading. Acknowledgment Number Field

The Acknowledgment Number field indicates the next expected sequence number from the other side of the communications. For example, in Figure 2.5, the sender believes the next TCP header from the other host will contain sequence number 969864. Data Offset Field

This defines the length of the TCP header. In actuality, it is defined in 4 byte increments, so a value of 5 in this field indicates that the TCP header is 20 bytes long. We need this field because the TCP header length can vary depending on the TCP header options used. While the UDP option field is rarely used, the TCP option field is almost always used during the TCP connection setup to establish the maximum amount of data TCP/IP Analysis and Troubleshooting Copyright  2000 podbooks.com


48

that can be placed after a TCP header. We'll look into this further in the "TCP Options Field" section. Flags Field

The following list describes the flags used in the TCP header: URG (Urgent): Indicates Urgent Pointer field should be examined. ACK (Acknowledgment): Acknowledgment packet. PSH (Push): Bypass buffering and pass data straight to upper layer. RST (Reset): Close the connection. SYN (Synchronize): Synchronize sequence numbers – handshake process. FIN (Finish): Transaction finished, but don’t close connection. These fields are most important in understanding TCP communications. The following list gives a brief interpretation of how you can use these field values in your analysis. URG: Rarely seen. This application wants you to read the data in this packet in a special order – only time I’ve seen this was when an application had a patch embedded in the executable. Note If you see this flag in use or you program an application to use this field, please send me email at [email protected]. -- Laura

ACK: Typical acknowledgment packet. If this is missing from the process, then the data stream cannot continue to be sent. Back-to-back ACKs indicate a packet is missing from a set (see RFC 2001). PSH: There are two ‘TCP buffer’ areas. One TCP buffer gathers outgoing data so the window is a decent size. The other is on the incoming side to receive data and pass it up in an ordered fashion. The PSH flag indicates that this TCP segment should not be held in the outgoing or incoming buffers – plunge it through, folks! An application that is very single-packet driven (such as character-at-a-time telnet) may set the PSH flag on every packet making TCP act in a ping-pong (packet out, ACK in, packet out, ACK in, etc.) manner. Ugh. RST: If an application does not send a RST when you shut it down, that means that the application holds the connection open (probably in case you relaunch it soon). The application will rely on a TCP connection timeout to shut down the connection. If an application encounters a fault, it may send a RST in the middle of the communication – that’s a pain. SYN: This is a sign of a host attempting to establish a TCP connection by exchanging the starting sequence number values. One form of a Denial of Service attack sends back-to-back SYNs incrementing the sequence number in each packet. Some firewalls can block SYN packets coming in from an untrusted source to stop connections between the inside and outside world.



49

FIN: This indicates that a process has completed and the data stream has been sent. The sender does not want to shut down the connection, however. Many times the PSH flag will be set with the FIN flag. Window Field

This field indicates the size of the TCP receiver buffer in bytes. For example, in Figure 2.5, the sender indicates that it can receive a stream of data up to 8577 bytes in length. A window size of 0 indicates that a sender should stop transmitting – the receiver’s TCP buffer is full. It is not unusual to see an analyzer report a “frozen window.” This alert indicates that the same window size has been used in several transmissions in a row. This may be due to the TCP stack’s limitation in window size or a “ceiling” of available bandwidth on a network. Sometimes these are settable parameters (i.e., in the Windows registry) – work with them in a lab before changing them globally on a network. See ‘TCP Windowing’ later in this section. Checksum Field

This TCP checksum is a bit strange, just like the UDP checksum. The checksum is performed on the contents of the TCP header and data (not including data link padding) as well as a pseudo header derived from the IP header. You probably don’t need to know any more (unless you love mathematical equations). You can get more information on this field from RFC 793. Urgent Pointer Field

This field is only relevant if the URG pointer is set. If the URG pointer is set, the receiver must examine this field to see where to look/read first in the packet. This is definitely a strange function. Note If you are a programmer and you use the Urgent Pointer process, please send me an email at [email protected] to explain how you are using this field. I am most interested to hear your views. –Laura

TCP Options Field(s)

This option field is… well, optional. One option you will certainly see in use is the Maximum Segment Size (MSS) option – it is used in the first two packets of the three-way handshake process. The purpose of this option is to define what segment size of the hosts supports. The hosts will use the lowest common denominator between the two MSS values. Other TCP options can be found at www.isi.edu/in-notes/iana/assignments/tcpparameters.



50

Analyzing the TCP Startup/Handshake Process Figure 2.6 shows the three-way handshake process in the summary window (top) and the first packet in the handshake in the detail window (bottom). The basic handshake process requires three packets in the following order: SYN >>>>> > The SYN packets synchronize the sequence numbers to ensure both sides know each other’s starting sequence numbers. This is how they will keep track of the sequence of data exchanged between them.

Figure 2.6: The TCP handshake process is shown in the summary window; the first packet of the handshake is shown in the decode window.

Although most handshakes occur in this fashion, there are some exceptions – for example, when a host needs to establish multiple connections at one time, you may see the following handshake sequence: SYN >>>>> (source port #1309) > (source port #1310) > (source port #1311) > (source port #1312) >



51

These two-way handshakes finish up with a standard three-way handshake. We know they are separate connections because the source port number is different in each request. Web browsers typically open up multiple connections to a web server when they connect. Note One Denial of Service attack uses this two-way handshake with the incrementing source port to overload the destination. If you see excessive connection establishment routines back-to-back, be suspicious of the cause. –Laura

Analyzing the TCP Sequencing/Acknowledgment Process The sequencing/acknowledgment process guarantees that packets are ordered properly and protects against missing segments. During the handshake process, each side of the connection selects its own starting sequence number. They will increment this sequence number by the amount of data included in each packet. For example, in Figure 2.7, you can see a packet (#448) from 10.0.0.1 to 10.0.0.99. The TCP header shows that 10.0.0.1’s sequence number is 97009 and there are 24 bytes of data in the packet. The next sequence number 10.0.0.1 will use is 970123 (970099 plus 24). The acknowledgment field value indicates that this host believes that 10.0.0.99’s next sequence number will be 2288791. In the reply packet (packet #449) shown in Figure 2.8, we can see that the sequence number for 10.0.0.99 is indeed 2288791. Packet 449 is an acknowledgment and contains no data, therefore, 10.0.0.99’s sequence number will be the same in the next TCP header. The sequence number does not increment on packets that do not contain data (such as a simple ACK packet).

Figure 2.7. The current sequence number for 10.0.0.1 is 970099.



52

Figure 2.8: The ACK bit is set in the acknowledgment.

When you are analyzing the sequencing/acknowledgment process, keep in mind this simple equation: Sequence Number In + Bytes of Data Received = Acknowledgment Number Out

Clear as mud? Note To make this easier for an analyst, the Sniffer Basic and Sniffer Pro products include the result of this calculation in a field called “Next Expected Sequence Number.” This field does not actually appear in the packet. – Laura

Here’s a quick rundown of how a sequenced communication may occur in simple terms/numbers (remember, the acknowledgment number filed contains the value of the next sequence number expected from the other side): à Host 1: Sequence number 1 with 9 bytes of data. Acknowledgment number field = 100 ß Host 2: Sequence number 100 with no data (ACK) Acknowledgment number field = 10 (in 1 + 9 bytes of data) à Host 1: Sequence number 10 with 5 bytes of data. Acknowledgment number field = 100 ß Host 2: Sequence number 100 with no data (ACK) Acknowledgment number field = 15 (in 10 + 5 bytes of data) ß Host 2: Sequence number 100 with 20 bytes of data * TCP/IP Analysis and Troubleshooting Copyright  2000 podbooks.com


53

Acknowledgment number field = 15 à Host 1: Sequence number 15 with no data (ACK) Acknowledgment number field = 120 (in 100 + 20 bytes of data) * Host 2 is now sending data to Host 1. Hopefully, you followed that enough to figure out that the Acknowledgment number field only increments when data is received. You should also note that the example starts with Host 1 sending data and then reverses when Host 2 has something to send. This is typical of two-way communications. Just when you have this whole thing figured out, there will be a ‘catch’ of course. During the TCP startup and teardown sequence there is a ‘phantom byte’ that causes the sequence number and acknowledgment number fields to increment by 1 even though no data is exchanged. Don’t let this confuse you when you are just learning the process. Note Practicing with these sequence/acknowledgment number fields can be a bit tedious, but well worth your while. Once you ‘get it’ then it’s like riding a bike – you won’t forget it. Just try to remember that equation: Sequence Number In + Bytes of Data Received = Acknowledgment Number Out. –Laura

Analyzing the TCP Windowing Process TCP communications can send multiple packets in a row without requiring an intervening Acknowledgment for each packet sent. This called a ‘window.’ The size of the window is dependent upon two basic factors: The receiver’s TCP buffer space advertised The amount of traffic allowed on the network (network congestion) The window will always be the lower of the two values. Network congestion is defined as a condition that causes packets be lost in transmission because the network itself cannot support the data transfer rate. For example, on an Ethernet network suppose a receiver advertises a window of 4096 bytes, but packets are lost in the transfer of multiple 1024 byte frames due to a high collision rate on a very busy network. In this case, the actual window is not 4096 bytes –it will be about 50% of the last window attempted when packets were lost. This process of altering the window in case of data loss is eloquently defined in RFC 2001. Note RFC 2001 is a very well-written document that defines TCP’s windowing methods. I highly recommend that you download and really try to get through the paper to get a better grasp on the whole windowing thing. –Laura

You may wonder why it’s called a ‘sliding’ window. Simple – really. If you look at the data that’s sent and you move a window over it, the left side of the window is the data that’s been acknowledged. The right side defines the boundary of data that



54

can be sent based on the receiver’s advertised window. Figure 2.9 illustrates this more clearly.

Figure 2.9: The window moves to the right to send more data.

Note One of the best definitions and examples of windowing is contained in “TCP/IP Illustrated, Volume I: The Protocols” by W. Richard Stevens. [Addison-Wesley Professional Computing Series] ISBN 0-201-63346-9. –Laura

As you can see in Figure 2.9, the data set A+B has already been sent and acknowledged. The current window has sent data set C+D+E+F and the sender is waiting for an acknowledgment. The window will now move to the right to send the next data set G+H+I+J. The window continues to slide to the right as acknowledgments are received. Note Take a trace of a nice HTTP session to see how windowing works. It’s best if you access a very graphics-intensive site to obtain a large data download. You can also try using FTP to get a nice large file off a remote system. – Laura



55

Analyzing Your ARP Communications ARP is a weird little protocol – it is not routable – in fact, it does not even have a network layer component in the packet structure as shown in Figure 2.10. As simplistic as ARP is, it is often the protocol that signals problems with network addressing or configuration, as you will learn later in this section. ARP is defined in RFC 826.

What is ARP for Anyway? Typically ARP is used for two purposes on a TCP/IP network: n

to resolve the MAC-layer address of a destination or next-hop router or

n

to test for a duplicate IP addresses.

Viewing the packets in a simple ARP transaction should clarify ARP’s usage further.

ARP Packet Fields/Functions There are two basic ARP packets – the ARP request packet and the ARP reply packet. Both packets use the same format, as you can see in Figures 2.10 and 2.11.

Figure 2.10: The ARP request.

The most confusing part of ARP is the interpretation of the sender and target address information. When an ARP broadcast is being sent from a host (host A in this example), the sending host – host A – will put their hardware and IP address in the sender address fields.



56

The target protocol address field includes the IP address of the device being sought. The target hardware address field is set to all 0’s to indicate the information is not known, as shown in Figure 2.10. Note The ARP specification dictates that the target hardware field can be set to a value other than all 0s. In some implementations of ARP, the source sets the destination address to all 1s which may confuse some routers causing them to broadcast the ARP packet onto all connected networks. This type of problem is easy to spot with an analyzer. Hopefully, you are realizing how wonderful an analyzer can be. --Laura

Figure 2.11: The ARP reply packet.

Figure 2.11 shows the ARP reply packet. You can see in this reply that the target and sender information is reversed to show that the ARP responder is now the sender. The original station performing the lookup is now the destination. Hardware Type

This defines the hardware or data link type in use. This field is also used to determine the hardware address length, which makes the ‘Length of Hardware Address’ field redundant.



57

The following is a partial list derived from the online list at www.iana.org. Number 1 7 11 14 15 17 19 20 21

Hardware Type Ethernet ARCNET LocalTalk SMDS Frame Relay HDLC Asynchronous Transmission Mode (ATM) Serial Line Asynchronous Transmission Mode (ATM)

Protocol Type

This field defines the protocol address type in use. This field uses the standard protocol ID values that are also used in the Ethernet II frame structures. These protocol types are defined at http://www.isi.edu/in-notes/iana/assignments/ethernetnumbers. This field also determines the length of the protocol address making the ‘Length of Protocol Address’ field redundant. Length of Hardware Address

Defines the length (in bytes) of the hardware addresses used in this packet. This field is redundant since this value is determined by the hardware type field. Length of Protocol Address

Defines the length (in bytes) of the protocol (network) addresses used in this packet. This field is redundant since this value is determined by the protocol type field. Opcode

This defines whether this is a request or reply packet and the type of address resolution taking place. The following lists the ARP and RARP (reverse ARP) operation codes: 1 2 3 4

ARP request ARP reply RARP request RARP reply

RARP is a process that enables a device to learn a network address from a MAC address. RARP is defined in RFC 903. Sender’s Hardware Address

The hardware address of the device that is sending this request or reply. Sender’s Protocol Address

The protocol, or network, address of the device that is sending this request or reply.



58

Target Hardware Address

The desired target’s hardware address, if known. In ARP requests, this field is typically filled with all 0s. In ARP replies, this field should contain the hardware address of the device being sought (or the next-hop router to that device). Target Protocol Address

The desired target’s protocol, or network, address.



59

Analyzing Your ICMP Communications ICMP is my favorite protocol in the world these days. I use it to troubleshoot network problems and examine network designs. If you only have a few minutes to spend really learning a protocol, this would be the one to spend time on.

What is ICMP Anyway? ICMP is used as a messaging system for errors, alerts, and general notifications on an IP network. There is a range of ICMP message types, but the ones that I find most useful and helpful are: Echo messages: used by ping and traceroute to test end-to-end connectivity. Too many of these might signal a Denial of Service attack. See Chapter 3, “Analysis Tools and Techniques,” for more information on ping and traceroute. Redirect messages: used by routers to let the source know there is a better path to a destination. Destination unreachable messages: used to tell the source that their packet could not be delivered for some reason – the reason is stated in the destination unreachable message. By examining the ICMP traffic on your network for a few hours or days, you can determine how efficiently the network is designed and spot numerous configuration errors, or functional problems. There are more examples later in this chapter. ICMP is defined in RFC 792.

ICMP Packet Fields/Functions ICMP packets only contain three required fields after the IP header: type, code and checksum. In some ICMP packets, however, there are added fields to provide information or details on the message. For example, an ICMP redirect packet needs to include the address of the gateway that a packet is being redirected to. (Upon receipt of this packet, a host should add a dynamic route entry to their routing tables and begin using the new routing information immediately.) Figure 2.12 shows a simple ICMP echo request packet.



60


ICMP Header

ICMP Data (sometimes includes IP header of packet that triggered the ICMP reply)

Figure 2.12: The IP header Protocol field value “1” indicates that this is an ICMP packet.



61

RFC 792 is the best reference on the various frame structures possible with ICMP. Type

The following list defines the types of ICMP messages that can be sent on the network. This list is based on IANA documentation as of January 1, 1999. To obtain the most current version of this list, access www.iana.org. Type

Name

0 Echo Reply [RFC 792] 1 Unassigned 2 Unassigned 3 Destination Unreachable [RFC 792] 4 Source Quench [RFC 792] 5 Redirect [RFC 792] 6 Alternate Host Address 7 Unassigned 8 Echo [RFC 792] 9 Router Advertisement [RFC 1256] 10 Router Solicitation [RFC 1256] 11 Time Exceeded [RFC 792] 12 Parameter Problem [RFC 792] 13 Timestamp [RFC 792] 14 Timestamp Reply [RFC 792] 15 Information Request [RFC 792] 16 Information Reply [RFC 792] 17 Address Mask Request [RFC 950] 18 Address Mask Reply [RFC 950] 19 Reserved (for Security) 20-29 Reserved (for Robustness Experiment) 30 Traceroute [RFC 1393] 31 Datagram Conversion Error [RFC 1475] 32 Mobile Host Redirect 33 IPv6 Where-Are-You 34 IPv6 I-Am-Here 35 Mobile Registration Request 36 Mobile Registration Reply 37 Domain Name Request 38 Domain Name Reply 39 SKIP 40 Photuris 41-255 Reserved [JBP] Note The initials JBP identify Jon B. Postel. Jon Postel was one of the founders of the Internet protocol suite. With a long beard and an intensely brilliant mind, he helped shape the communications system of the Internet and millions of private networks until his untimely death in October 1998. You can learn more about this luminary at www.iana.org/postel/index.html. –Laura



62

Code

Many of these ICMP packet types have a "code" field. Here are the types that use code fields and their assigned code field values. Type 3

Name

Destination Unreachable Codes 0 Net Unreachable 1 Host Unreachable 2 Protocol Unreachable 3 Port Unreachable 4 Fragmentation Needed and Don't Fragment was Set 5 Source Route Failed 6 Destination Network Unknown 7 Destination Host Unknown 8 Source Host Isolated 9 Communication with Destination Network is Administratively Prohibited 10 Communication with Destination Host is Administratively Prohibited 11 Destination Network Unreachable for Type of Service 12 Destination Host Unreachable for Type of Service 13 Communication Administratively Prohibited 14 Host Precedence Violation 15 Precedence cutoff in effect 5 Redirect Codes 0 Redirect Datagram for the Network (or subnet) 1 Redirect Datagram for the Host 2 Redirect Datagram for the Type of Service and Network 3 Redirect Datagram for the Type of Service and Host 6 Alternate Host Address Codes 0 Alternate Address for Host

11 Time Exceeded Codes 0 Time to Live exceeded in Transit 1 Fragment Reassembly Time Exceeded 12 Parameter Problem Codes 0 Pointer indicates the error 1 Missing a Required Option 2 Bad Length



63

40 Photuris Code 0 Reserved 1 unknown security parameters index 2 valid security parameters, but authentication failed 3 valid security parameters, but decryption failed The following list provides the descriptions of the more common code fields. 3

Destination Unreachable Code 0

Net Unreachable - ICMP sender knows about network, but believes it is not ‘up’ at this time –perhaps it is too far away through known route

1

Host Unreachable - ICMP sender knows about host, but doesn’t get ARP reply indicating host is not ‘up’ at this time

2

Protocol Unreachable - Protocol defined in IP header cannot be forwarded

3

Port Unreachable - ICMP sender does not support the port number you are trying to reach

4

Fragmentation Needed and Don't Fragment was Set - Router needed to fragment to forward the packet across a link that supports a smaller MTU (maximum transmission unit) size, but application set the Don’t Fragment bit.

5

Source Route Failed - ICMP sender cannot use the strict or loose source routing path specified in the original packet.

6

Destination Network Unknown - ICMP sender does not have a route entry for the destination network indicating it may never have been an available network.

7

Destination Host Unknown - ICMP sender does not have a host entry indicating it may never have been available on connected network.

8

Source Host Isolated - ICMP sender (router) has been configured to not forward packets from source (the old electronic pink slip, folks). Most routers will not generate this code – they will generate a code 0 (network unreachable) and code 1 (host unreachable) – whichever one is appropriate – instead.

9

Communication with Destination Network is Administratively Prohibited - ICMP sender (router) has been configured to block access to the desired destination network.



64

10 Communication with Destination Host is Administratively Prohibited ICMP sender (router) has been configured to block access to the desired destination host. 11 Destination Network Unreachable for Type of Service - The Type of Service (TOS) indication used by the original sender is not available through this router for that specific network. 12 Destination Host Unreachable for Type of Service - The TOS indication used by the original sender is not available through this router for that specific host. 13 Communication Administratively Prohibited - ICMP sender is not available for communications at this time. 14 Host Precedence Violation - Precedence value defined in sender’s original IP header is not allowed (for example, using Flash Override precedence) 15 Precedence Cutoff in Effect – Network administrator has imposed a minimum level of precedence to be serviced by a router, but a lowerprecedence packet was received. 5

Redirect Codes 16 Redirect Datagram for the Network (or subnet) - ICMP sender (router) is not the best way to get to the desired network. Reply contains IP address of best router to destination. Dynamically adds a network entry in original sender’s route tables. 17 Redirect Datagram for the Host - ICMP sender (router) is not the best way to get to the desired host. Reply contains IP address of best router to destination. Dynamically adds a host entry in original sender’s route tables. 18 Redirect Datagram for the Type of Service and Network - ICMP sender (router) does not offer a path to the destination network using the TOS requested. Dynamically adds a network entry in original sender’s route tables. 19 Redirect Datagram for the Type of Service and Host - ICMP sender (router) does not offer a path to the destination host using the TOS requested. Dynamically adds a host entry in original sender’s route tables.



65

6

Alternate Host Address Codes 20 Alternate Address for Host - Reply that indicates another host address should be used for the desired service. Should redirect application to another host.

11 Time Exceeded Codes 21 Time to Live Exceeded in Transit - ICMP sender (router) indicates that originator’s packet came in with a TTL of 1. Routers cannot decrement the TTL value to 0 and forward it. 22 Fragment Reassembly Time Exceeded - ICMP sender (destination host) did not receive all fragment parts before the expiration (in seconds of holding time) of the TTL value of the first fragment received. 12 Parameter Problem Codes 23 Pointer indicates the Error - Error is defined in greater detail within the ICMP packet. 24 Missing a Required Option - ICMP sender expected some additional information in the Option field of the original packet. 25 Bad Length - Original packet structure had an invalid length.

You can also see some details in the online number listing at www.iana.org. Checksum

The checksum field covers the ICMP header only. Note Decode Warning: Some analyzers do not decode enough of the ICMP packets. In some cases, such as a port unreachable message, the IP header of the misdirected packet is included inside the ICMP packet. Some analyzers stop decoding just before the source and destination port fields. To find out what the original source and destination port fields are, you must look at the hex values.



66

Destination Port = 0x0035

Source Port = 0x0407

Figure 2.13: The source and destination port fields are within the first 8 bytes of the originating message.

To identify these undecoded packets, highlight the text after the destination IP address inside the ICMP header portion. Be careful not to highlight the actual IP header that is placed after the Ethernet header. Most analyzers will automatically highlight the corresponding bytes in the hex window, as shown in Figure 2.13. The port number fields are the first four bytes of this undecoded data. In the example shown in Figure 2.13, the source port was set at 0x0407. The destination port was set at 0x0035. Convert the destination port 0x0035 to decimal using the hex chart in Appendix E or the Windows calculator in scientific mode. 0x0035 = 53 decimal = Domain Services (DNS) Practice with the ICMP packets on your network. What are they telling you?



67

Chapter 2 Test Here we go. These questions are based on this chapter and the accompanying trace files (ARP1.CAP, PING1.CAP, and TCPSHAKE.CAP). The answers are in Appendix A – but, once again, don’t cheat – really give it a good try before looking up the answers. 2.1

Open the ARP1.CAP or ARP1.PRN file (refer to Appendix D, “Disk Contents,” for more information on the trace files included with this book). Answer the following questions based on the contents of the captured packets: 2.1.a. What opcodes are used in each packet? _____________________________ 2.1.b. What is the hardware address of the discovered device? _____________________________

2.2

Open the PING1.CAP or PING1.PRN file. Answer the following questions based on the contents of the captured packets: 2.2.a.

Does the echo request appear to have crossed a router? _____________________________

2.2.b. What field identifies packet #1 as an ICMP packet? _____________________________ 2.2.c.

What field identifies packet #1 as an echo request packet? _____________________________

2.3

Open the TCPSHAKE.CAP or TCPSHAKE.PRN file. Answer the following questions based on the contents of the captured packets: 2.3.a.

What field identifies packet #1 as a TCP handshake packet? _____________________________

2.3.b. What MSS size will both sides of the connection use? _____________________________ 2.3.c.

Will the sender and receiver use the same window size? _____________________________

2.4

Open the WHATIS.CAP or WHATIS.PRN file and identify the packet contained in that file. What action, if any, would you take if your network were flooded with these packets? ______________________________________________________



68

______________________________________________________

2.5 How would you set up an analyzer filter to capture the following packets? 2.5.a.

IP ______________________________________________________

2.5.b. ARP ______________________________________________________ 2.5.c.

DHCP (both source and destination issue) ______________________________________________________

2.5.d.

DNS ______________________________________________________

2.5.e.

UDP ______________________________________________________

2.5.f.

ICMP ______________________________________________________

2.5.g

FTP ______________________________________________________



69

Extra Credit: Build a TCP/IP Protocol Distribution Chart 2.6 Use your analyzer to create a chart or graph of your protocol distribution. What percentage of your traffic is HTML? What percentage of your traffic is FTP? DHCP? ICMP? If your analyzer has predefined filters or a built-in charting capability, you are set. Otherwise, you’ll need to build these filters yourself. Build these filters based on the source/destination port values in the packet. Figure 2.14 provides an example of a protocol distribution chart.

Figure 2.14: The protocol distribution indicates that much of the network IP-based traffic is NetBIOS.



70

Chapter 3.

Troubleshooting Tools and Techniques This chapter is the one that you immediate gratification folks will jump to. It lists the most common problems that I see on TCP/IP networks. It also defines the tools that you must have (including basic TCP/IP utilities, analyzers and combination tools). If you did just jump to this chapter, consider spending some time back on Chapter 1, “Packet-Level TCP/IP.” That chapter shows you how the host name, address and route resolution process works.

CAUTION Some of the tools listed in this chapter are used by hackers to break into networks. Do not give these tools to a ‘Fred.’ You know who ‘Fred’ is – he’s the ‘user from hell’ that intentionally or unintentionally messes up the network. –Laura

TCP/IP Problems to Watch For In the complex world of TCP/IP internetworking, there are numerous problems that can occur. These problems typically fall into one of these categories: n

Addressing problems

n

Routing problems

n

Service discovery problems

n

TCP connections problems

n

IP fragmentation problems

n

DHCP problems

n

Denial of Service problems

Let’s take a brief look at the possible symptoms of each of these problems and some ways to figure out the cause.

Addressing Problems IP addressing-related problems are the most common problems in IP networks. Manually entered errors, DNS-DHCP conflicts, invalid host file entries, and so on…. These problems can be seen on the wire when a device’s ARPs go unanswered or an ICMP reply comes back stating that the ‘Destination Network Unknown’ or ‘Destination Host Unknown.’ These problems are actually not too tough to figure out because they will cause some inability to reach a device.

Routing Problems Start your analyzer and filter on all TCP/IP traffic. What type of routing traffic do you have? Are you using RIP version 1, RIP version 2, or OSPF? Ideally, you should try to use only a single routing protocol. Do you see many ICMP redirect messages? These messages occur when traffic is sent to an inappropriate router (not the best way to go). If you do see lots of ICMP redirects messages, who do they go to? That is pointing at the device that may have a default gateway setting that doesn’t match their typical communications pattern. Do you see any messages indicating that a service is unreachable? How many routing broadcasts are sent on the network (seen with RIP version 1)?


Chapter 3: TCP/IP Tools and Techniques

72

Service Discovery Problems There are several ways that an IP device can ‘discover’ a service. •

They can identify the address in a local host file.

•

They can use DNS to find the IP address of a device.

•

They can use SLP (Service Location Protocol) to find the IP address of a device.

•

With NetWare 5, they can use NDS over TCP/IP, as well.

Once the client has the address and they send communications to another device, do they receive ICMP destination unreachable messages? If so, why? Look at the ICMP code coming back.

TCP Connection Problems In Chapter 2, we covered the TCP three-way handshake. TCP connection problems are typically evident in the handshake process. TCP windowing problems may be due to network congestion, a client application not freeing up buffer space fast enough, or a minimal-sized predefined TCP window. Check to see that a TCP-based application (such as FTP) closes the TCP connection when you close the application. Make a nice trace of a simple FTP operation to get a feel for how TCP works.

IP Fragmentation Problems IP has the capability of fragmenting packets and unfortunately, applications can set this bit to not allow fragmentation. Fortunately (again), an ICMP message can be returned indicating that ‘fragmentation was needed, but the Don’t Fragment bit was set.’ Look for these ICMP messages on your network to identify fragmentation problems.

DHCP Problems Look at your DHCP communications to identify its pattern. What if the discovery process fails? What if more than one address is offered (more than one DHCP server)? Did the client NACK (negative acknowledgment to not accept the address) the second address? What did the client ask for in the request? Did the server reply with all required information? I do love DHCP, but there are times when I think it’s just plain dumb. For example, DHCP includes a ‘Release’ function that is used when a client is logging off – the client sends an address ‘release’ to the DHCP server that assigned it that address. This should free up the address for someone else to use. What if the DHCP Release gets literally ‘smashed to bits’ along the way? There is no ACK required for those packets, so the DHCP client just assumes that if it sent the packet, it got there. Duh….. The DHCP server won’t release this address until the lease time has expired. TCP/IP Analysis and Troubleshooting Copyright  2000 podbooks.com


73

Note You can get the list of DHCP options from the reference section of www.packetlevel.com. Also, checkout the March 1999 BrainShare Daily article on DHCP (www.nwconnection.com). –Laura

Denial of Service Attacks Denial of Service attacks are far too common these days. A denial of service attack is based on the theory that if you hog up all the CPU of a device, that device must deny services to anyone else. Note It appears that good ol’ DOS is back… and it’s pissed. --Laura

There are two primary types of Denial of Service attacks: • •

Brut force attacks Stealthy attacks

Brut force attacks are typically easy to spot with an analyzer. We’d think of a brut force attack if a device were sending out 10,000 pings in rapid succession to another device. Stealthy attacks typically only require one or two packets to kill the target. For example, a TCP SYN packet that uses the target’s IP address in both the source and destination address field of the IP header can kill some implementations of IP. Note Network analysts can create these attacks with a number of transmitting analyzer products. Always consider them suspect. If I am doing a test onsite at a client office, I use a unique identifier of (0x99-99-99) in the packet padding. I suggest you do the same to avoid alarming someone unnecessarily. –Laura

Take a look at the TCP/IP troubleshooting tools that are included with most implementations of TCP/IP. See also "TCP/IP Troubleshooting Tools" (January 1999, pp. 20-28) at www.nwconnection.com. That article covers ping, traceroute, route, and more.

Ok… now you know there are other problem types – but this podbook is not designed to put you to sleep with long lists of lists of lists…. Let’s move on to the tools that you can use to identify and resolve some of these problems.



74

Troubleshooting Tools and Utilities This section focuses on the tools and utilities that you should be familiar with as a TCP/IP network troubleshooter. Some tools are freebies (included with an OS or available freely on the Internet. Some of the tools must be purchased -- they range from inexpensive tools ($50) to expensive ($10,000 and over). Price is relative, of course. You should know at least the basic set of tools that comes with the operating systems and operating environments (Windows 95/98/2000, NT, NetWare, Unix and Linux, etc.). Note Personally, I highly recommend you also get and use NetScanTools (from Northwest Performance Software). Excellent tool and the Help was written with intelligence! We’ll cover this software later in this chapter. –Laura

Network/Protocol Analyzers Of course, I believe everyone should have a protocol analyzer (a.k.a. ‘network analyzer’). There are times when you really can’t tell what is going on from the outside of the network. It’s just like being a doctor. If you could not listen to a patient’s heartbeat or lungs, you wouldn’t be able to diagnose them efficiently. See “Introduction to Network Analysis,” (available at www.podbooks.com) for more information on standalone and distributed analyzers. –Laura Let’s see how an analyzer can help troubleshoot a DNS problem.

Figure 3.1: ICMP messages indicate the DNS port is unreachable at 10.0.0.1.



75

As you can see in Figure 3.1, the analyzer clearly indicates that the desired port (the DNS port) on 10.0.0.1 is not available. DNS services are not loaded on that device. An analyzer can help in so many ways if you know what the typical communication should look like. Refer to Chapter 2 for more details on typical TCP/IP communications. Currently I use the Sniffer Pro and Etherpeek as my primary analyzers. Each analyzer has a number of alarms and alerts to note when IP-specific problems are occurring on the network. The following list provides a subset of the Sniffer Pro Expert alarms that are of interest on a TCP/IP network: ♦ Application > FTP Connect Time (FTP Slow Connect) ♦ Application > FTP Login Time (FTP Slow First Response) ♦ Application > FTP Interframe Time (FTP Slow Response) ♦ Application > FTP Interframe Count, FTP Interframe Interval (FTP Slow Transfer Diagnosis) ♦ Application > Telnet Connect (Telnet Slow Response to Login) ♦ Application > SMTP Slow Connect Time ♦ Application > NNTP Slow Connect Time (NNTP Slow Response Time) ♦ Application > POP3 Slow Connect Time ♦ Application > NFS Retransmission ♦ Session > Local Xfer (KB/s), Remote Xfer (KB/s) (Low Throughput) ♦ Session > Filter Time (ms) (Loops on same request) ♦ Session > Min appl req, Loop % (Too many loops on same request) ♦ Session > IP NetBIOS Session Reject ♦ Connection > Local Routing (Packets routed back onto same network) ♦ Connection > Idle Time (Idle Too Long) ♦ Connection > UDP Bouncing Frames (Frames returning to same net) ♦ Connection > Fast Retransmission (ACK Too Long) ♦ Connection > Zero Window Time(Zero Window Too Long) ♦ Connection > Window Frozen Time (Window Frozen) ♦ Connection > Window Size Exceeded ♦ Station > Duplicate Network Address ♦ Station > IP Fragment Missing ♦ Station > IP Fragment out of order TCP/IP Analysis and Troubleshooting Copyright  2000 podbooks.com


76

♦ Station > Multiple Remote Routers (Multiple Routers to Remote) ♦ Station > Multiple Local Routers (Multiple Routers to Local) ♦ Station > ICMP Port Unreachable ♦ Station > ICMP Network Unreachable ♦ Station > ICMP Redirect for Network ♦ Station > Time-to-live exceeded in transmit ♦ Station > Time-to-live expiring (near death) ♦ Station > ICMP Inconsistent Subnet Mask ♦ Station > ICMP Source Quench (slow down source) ♦ Station > Source Address in Broadcast ♦ Station > Zero Broadcast Address (old technology) ♦ Station > ICMP Parameter Problem ♦ Station > Router Storm ♦ Station > Router Not Updating Routers (stopped participating) ♦ Station > Route Flapping (router here-gone-here-gone…) ♦ Station > Router Superseded too Frequently ♦ Global > Broadcast Frames/sec (Broadcast/Multicast Storm) ♦ Global > Broadcast Frames/sec (Broadcast/Multicast Storm Diag.) ♦ Global > LAN Load (LAN Overload) ♦ Global > LAN Overload % (LAN Overload percentage) ♦ Global > Spanning Tree Topology Change

This list only pertains to the Sniffer Pro. Many of the elements in this list are self explanatory. The online help provides a fair amount of detail on each alarm. Note If you are unfamiliar with general analysis techniques, refer to “Introduction to Network Analysis” at www.podbooks.com. –Laura

General Utilities Let’s first concentrate on the types of tools that you probably have available at the customer site – tools that are bundled with Windows. These are tools that you can and should try out immediately to get familiar with.



77

Windows Utilities

When you enable the TCP/IP stack on a Windows 95/98 computer, a set of TCP/IP troubleshooting utilities are placed on the local drive (in the Windows directory). These utilities include: ping traceroute (tracert) ARP route netstat winipcfg Let’s look at how each one of these can be used to locate the source of IP network problems. Ping Ping (packet internet grouper) is used to query another IP device on the network to determine if it is alive and how long it takes to get there. This is one of the first tools that should be used for any problem that appears to be caused by a lack of connectivity between network devices. The syntax for the PING command is: PING [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS] [-r count] [-s count] [[-j host-list] | [-k hostlist]] [-w timeout] destination-list

Where: -t -a -n count -l size -f -i TTL -v TOS -r count -s count -j host-list -k host-list -w timeout reply.

Ping the specified host until interrupted. Resolve addresses to hostnames. Number of echo requests to send. Send buffer size. Set Don't Fragment flag in packet. Time To Live. Type Of Service. Record route for count hops. Timestamp for count hops. Loose source route along host-list. Strict source route along host-list. Timeout in milliseconds to wait for each

If a device is having problems communicating, run ‘ping 127.0.0.1’ from that device – the address 127.0.0.1 is the loopback address. The station will ping its own IP stack. If it does not see that it’s own stack is alive it naturally cannot communicate on the network.



78

Figure 3.2 shows the results from a ping across the Internet to the www.packetlevel.com website.

Figure 3.2: Pinging a web server.

Note Microsoft places an identifiable pattern in ping packets generated from their IP stack. They typically send the alphabet inside the ping packet padding area, as shown in Figure 3.3. This is useful when you are trying to identify the source of ping packets on the network. –Laura

Figure 3.3: The ping packet source can be identified as a device using Microsoft’s IP stack.



79

Don’t set the -t flag unless you are going to track and manually terminate the ping test; this flag causes continuous transmission of ping packets and adds traffic to the network. Set the -l flag and define a maximum packet size with the -f flag in order to test the end-to-end MTU. Without these flags set you can send a large packet through the network and find out where it would require fragmentation to continue. Traceroute (Tracert) This is a wonderful tool used to determine the possible path that a packet may take to get from one device to another (if a path exists). This tool helps define the time to reach the routers along the path and identify any ‘sluggish’ spots along that path. The syntax of the tracert command is: tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name

Where: -d -h maximum_hops target. -j host-list -w timeout

Do not resolve addresses to hostnames. Maximum number of hops to search for Loose source route along host-list. Wait timeout milliseconds for each reply.

Figure 3.4 shows an example of the results when you traceroute to the www.packet-level.com website.

Figure 3.4: This route hits four devices.

Be careful of tracerouting. If a network supports load balancing (as the Internet does), separate traceroute tests can yield different paths. The paths that are resolved may not be correct due to an assumption of connectivity between devices in a path. Consider Figure 3.5, for example. As traceroute determines the ‘next hop’ along the path, the load balancing router sends the separate path tests in TCP/IP Analysis and Troubleshooting Copyright  2000 podbooks.com


80

different directions. The path appears to be Router A-Router B-Router F-Router D-Router H (an impossible path).

Figure 3.5. Trace route may yield strange results on a load balanced network.

The following lists the traceroute syntax for Unix/Linux and NetWare servers. Unix/Linux: tracert [-m max] [-n] [-q qcount] [-w time] host

Where: -n Do not resolve addresses to hostnames. -m maximum_hops Maximum number of hops to search for target. -q qcount Sets the number of packets sent for each hop. -w time Wait timeout seconds for each reply. NetWare 5 server: [load] iptrace destination [hops=maximum_hops] [wait=time] [port=port_value] [noresolve] [newlog]

Where: hops=maximum_hops wait=time port=port_value noresolve

Max. number of hops to search for target. Wait timeout seconds for each reply Destination port Do not resolve addresses to hostnames.



81

Newlog

Restart iptrace.log

ARP The ARP utility can be used to view the local device’s ARP cache and can be used to force an ARP broadcast in an attempt to resolve an IP-to-Ethernet address. Use ARP when you doubt the validity of a client’s local ARP cache or you want to determine how entries are being acquired. You can also use this to force an entry into the tables or delete an incorrect entry. The syntax for the ARP command is: ARP - s inet_addr eth_addr [if_addr] ARP - d inet_addr [if_addr] ARP -a [inet_addr] [-N if_addr]

Where -a

Displays current ARP entries by interrogating the current protocol data. If inet_addr is specified, the IP and Physical address for only the specified computer are displayed. If more than one network interface uses ARP, entries for each ARP table are displayed.

-g

Same as -a.

inet_addr

Specifies an internet address.

-N if-addr Displays the ARP entries for the network interface specified by if_addr. -d

Deletes the host specified by in_addr.

-s

Adds the host and associates the Internet address inet_addr with the Physical address eth_addr. The Physical address is given as 6 hexadecimal bytes separated by hyphens. The entry is permanent.

eth_addr

Specifies a physical address.

If_addr

If present, this specifies the Internet address of the interface whose address translation table should be modified. If not present, the first applicable interface will be used.

Route The client looks at it’s local route tables first when considering how to route packets to a remote destination. Entries can be placed in the table manually (using the route command), but they are most often dynamically learned from the network. For example, consider Figure 3.6, where the client, Ginny, is sending a ping packet to Drake. Her station’s IP stack will look in the local route tables to see if there is an entry for Drake’s host address (204.10.11.5) first. If she does not have an entry for that specific host address, the IP stack will look for a network entry (an entry TCP/IP Analysis and Troubleshooting Copyright  2000 podbooks.com


82

for 204.10.11.0). If no entry exists for either the host or network, the IP stack will look for a default gateway setting. In this case, Ginny’s station has a default gateway (204.10.10.3) that connects to the Internet. Unfortunately, that is not the best path to network 204.10.11.0, but Ginny’s station does not know that. She sends the packet to the default gateway. The default gateway returns an ICMP packet to the client that indicates there is a better route through router 204.10.10.4. This packet is called a Redirection message and it dynamically updates Ginny’s routing tables. The next time she sends a packet to Drake, she will find a network entry for 204.10.11.0 in her routing tables that indicates she should forward such traffic to router 204.10.10.4.

Figure 3.6: Sample redirection scenario.

Note: If almost all of a host’s packets to other devices must be rerouted, perhaps the default gateway specified is not the most appropriate. The syntax for route is: ROUTE [-f] [command [destination] [MASK netmask] [gateway]

-f

Clears the routing tables of all gateway entries. If this is used in conjunction with one of the commands the tables are cleared prior to running the command.

Command

Specifies one of four commands PRINT ADD DELETE CHANGE

destination

Prints/views a route Adds a route Deletes a route Modifies an existing route

Specifies the host to send command.



83

MASK

If the MASK keyword is present, the next parameter is interpreted as the netmask parameter.

netmask

If provided, specifies a sub-net mask value to be associated with this route entry. If not specified, if defaults to 255.255.255.255.

gateway

Specifies gateway.

To view your routing tables, type ROUTE PRINT. If you want to force the station to rebuild the route tables because it is sending packets to the wrong router, use the -f parameter. If you use the print or delete command, wildcards may be used for the destination and gateway, or the gateway argument may be omitted. Netstat Netstat provides details on the current protocol operations for TCP/IP connections. For example, if you established an FTP connection to the server and then left to take a break, you could use netstat to determine whether your connection is still valid upon your return. Netstat shows statistics for TCP, UDP, ICMP, and IP. Figure 3.7 shows the output from the netstat command on a NetWare 5 Pure IP client who has made a connection to a NetWare 5 server over IP.

Figure 3.7: The netstat command shows a live Pure IP connection (port 524).



84

The syntax for the netstat utility is shown below: NETSTAT [-a] [-e] [-n] [-s] [-p proto] [-r] [interval] Where: -a

Displays all connections and listening ports.

-e

Displays Ethernet statistics. This may be combined with the -s option.

-n

Displays addresses and port numbers in numerical form.

-p proto Shows connections for the protocol specified by proto; proto may be TCP or UDP. If used with the -s option to display perprotocol statistics, proto may be TCP, UDP, or IP. -r

Displays the routing table.

-s

Displays per-protocol statistics. By default, statistics are shown for TCP, UDP, and IP; the -p option may be used to specify a subset of the default.

interval Redisplays selected statistics, pausing interval seconds between each display. Press CTRL+C to stop redisplaying statistics. If omitted, netstat will print the current configuration information once.

Netstat can be used with the -r parameter to display the routing tables. If you want to watch the netstat information dynamically updated as connections are established and terminated, enter an interval (in seconds) following the parameters. For example, type “netstat 5” to see the statistics updated every 5 seconds. CTRL+C stops the display. Winipcfg Winipcfg is a utility located in the c:\windows directory (available only after the IP stack is enabled on the host). Run winipcfg to see the current host hardware address, IP address, default gateway configuration, and address lease and renewal times (for DHCP-assigned addresses). Details are available (the ‘More Info’ button), as well, as shown in Figure 3.8. Winipcfg is a great way to check a local station’s configuration details. If you have DHCP address problems, you can use the Renew/Renew All feature to force an IP station to attempt renewing an assigned address. Be careful of using Release/Release All because the station will release it’s IP address and cannot continue any IP-based operations.



85

Figure 3.8: Select More Info in winipcfg to see device configuration details. Note IPCONFIG is the Windows NT version of this utility. –Laura

Try these utilities out – they are the first level of analysis and can be found at almost any customer site. Once you become accustomed to the way that data flows and you can read the static and dynamic station configurations, you should be able to troubleshoot many of the more common communication problems.



86

Combo-Tools You MUST HAVE! No kidding folks. Just pay the man the money! This is the time to break open that piggy bank and get yourself some really slick combination tools that will make your life better. The two tools that I absolutely love are: •

AG Group NetTools (price $50)

•

NetScanTools 2000 (price $150)

In this section, we will examine two toolkits that are available online today. These tools are not by any means the only tools in the industry. They are, however, both recommended by the Protocol Analysis Institute (www.packet-level.com).

AGNetTools AGNetTools (by AG Group) is a simple TCP/IP troubleshooting combination utility. You can download a demo version of the toolkit at www.aggroup.com. Click on the ‘demos/registration’ button to access the download screen. The AGNetTools demo only runs for 10 minutes at a time. AGNetTools includes the following utilities: •

Ping – send ICMP echo test to a single device

•

Pingscan – ping a range of addresses.

•

Traceroute – determine routes and roundtrips using TTL timeouts.

•

Name lookup – [nslookup] resolve names to IP addresses

•

Name scan – resolve a range of IP addresses to names.

•

Port scan – identify active ports on a single device.

•

Service scan – identify active services on a range of IP addresses.

•

Finger – get user information on an email address.

•

Whois – query a whois server for Internet directory information.

•

Throughput – test the throughput of FTP and HTTP downloads.

•

Network statistics – runs the NETSTAT –r –s command.

•

Network IP configuration – runs IPCONFIG.

•

ARP cache content – runs ARP –a.

•

Port definitions – lists assigned port numbers.

CAUTION Use of port scanning and service scanning may be construed by your Internet access provider or the target system as a hostile action or intrusion and may be in violation of your Internet service provider’s agreement.

Figure 3.9 shows the ping screen (default opening screen) of AGNetTools.



87

Figure 3.9: Pinging a device with the AGNetTools product.

NPS NetScanTools Pro 2000 NetScanTools Pro 2000 was developed by Northwest Performance Software, Inc., as a comprehensive ‘all-in-one’ tool. Figure 3.10 shows the main NetScanTools Pro 2000 screen. One of the key features of NetScanTools Pro 2000 is the reliance on the standards and the clear, accurate description of the tools included in the product. The product makes no assumptions of the platform that it is running on or the environment that it is used in. The authors considered the dangers of various portions of the product (such as the port scanning area).



88

Figure 3.10: NetScanTools Pro 2000 offers a tremendous variety of troubleshooting tools.

Purchase NetScanTools Pro 2000 at Northwest Performance Software’s web site http://www.netscantools.com/nstpromain.html. Note You will need to ensure your workstation is running Winsock 2.0 in order to take full advantage of the tools in NetScanTools Pro 2000. The Winsock 2.0 upgrade can be found at www.microsoft.com. – Laura

The following section provides details on the NetScanTools Pro 2000 elements: ARP - View, add and delete ARP entries from local ARP cache. Character Generator Client - The Character Generator client tab connects to one of the TCP services supplied by the Windows NT Simple TCP Services or the INETD on UNIX operating systems or the basic service ports enabled in the NetWare TCP/IP stack. When a connection is made on the Chargen Server port, the server sends a stream of ASCII characters as fast as the connection will allow. This feature is used to test network speed.



89

Note Chargen is one of the 'Simple TCP/IP Services' optionally installed on Windows NT. The Simple TCP/IP Services are Chargen, Daytime, Discard, Echo and Quote. Chargen uses UDP or TCP port 19 to send a continuous stream of ASCII characters. Unfortunately, some hackers have built denial of service attacks using the chargen port as input and redirecting it as output to another port, for example port 53 (DNS). You may wish to disable or monitor the chargen port on your servers that are not behind firewalls. If you would like to simulate this attack, use the following UNIX command: telnet {ipaddress host} 19 > telnet {ipaddress victim} 53. –Laura

Database Tests - Used to analyze and test your system’s Winsock capabilities. Daytime - Daytime is an old protocol defined in RFC 867. This is a service provided by many computers which can be used as a quick way to determine the local time at that remote computer’s location. Detection - The Detection Tab is designed to allow you to monitor for incoming TCP/IP connections to your system. You can specify up to 32 ports, TCP or UDP, to monitor. Monitored ports can be specific to a single IP address or to all IP addresses found on your system. Any connections made to your system are logged with the date, time and the IP address of the system making the connection. Audible alarms can be set for notification of incoming connection attempts. Echo - Echo is a TCP or UDP service which 'echoes' back all characters received on the port that it is listening on. Due to security considerations--specifically Denial of Service attacks, this feature is often disabled on internet connected computers. Email validate - The Email Validate tab is used to confirm the existence (or nonexistence) and validity of an email address without sending an email message to that address. Finger - The Finger tab provides a client interface to a finger server, as shown in Figure 3.11. A finger server is usually located on a remote computer. Prior to the advent of the World-Wide-Web, people wanted to exchange information about themselves, however, they had few options--web pages were not around. One of the original ways people could gather information about each other anonymously was through a 'Finger' message. The Finger protocol and message structure are defined in RFC 1288. NetScanTools Pro includes a Finger client that is compliant with RFC 1288 and NetScanTools Pro also includes a companion IDENT server which is often required to be concurrently operating by many finger servers before they return any information to you.



90

Note The National Institute of Standards and Technology (NIST) has issued a warning regarding ‘finger’ services: “The ``finger'' service provided by the finger client program and the fingerd server program displays information about users. When finger is invoked with a name argument, the /etc/passwd file is searched and for every user with a first name, last name, or username that matches the name argument, information is displayed. When the finger program is run with no arguments, information for every user currently logged onto the system is displayed. User information can be displayed for remote machines as well as for the local machine. The output of finger typically includes login name, full name, home directory, last login time, and in some cases when the user received mail and/or read mail. Personal information, such as telephone numbers, are often stored in the password file so that this information is available to other users. Making personal information about users available poses a security threat because a password cracker can make use of this information. In addition, fingerd can reveal login activity. Versions of fingerd older than November 1988 are vulnerable to abuse because they contain a bug.” NIST can be contacted at www.nist.gov. – Laura

Figure 3.11: Finger utility.

HyperTrans - HyperTrans (Hyperfast Translation) translates IP addresses to hostnames or vice versa in a completely multithreaded, parallel mode. It requires a connection to a DNS server for operation. IDENT Server - The IDENT Server tab controls the activities of the NetScanTools Pro identification protocol as defined in RFC 1413. The Ident Protocol (formerly known as Authentication Server Protocol) is intended to provide a means for determining the identity of a user of a TCP connection. Some services, most often Finger and sometimes POP3 mail servers, require an IDENT server to be running TCP/IP Analysis and Troubleshooting Copyright  2000 podbooks.com


91

on your system before they will respond with the information you are requesting from them. The IDENT server listens for incoming connections on port 113 (decimal). Launcher - Launcher is a simple, but effective program launcher. It works by using the registry to determine which program to launch to connect to the given hostname or IP address. Name Server lookup - The Name Server Lookup tab is used to query DNS servers (nslookup), as shown in Figure 3.12. NetScanTools Pro 2000 includes several related advanced functions such as List Domain (also known as Zone Transfer or AXFR), Dig and Dig with Zone Transfer (AXFR).

Figure 3.12: DIG w/AXFR is an advanced option on the Name Server Lookup tab.

Net Topology – This feature is intended to provide a map of routers and gateways along the various routes to a user-defined list of target hosts. The origin for this map is the system running NetScanTools Pro. Information is gathered using TraceRoute and is placed in a graphical tree-like interface and also stored in a simple database format. NetBIOS information - The NetBIOS Info tab provides information about NetBIOS protocol network shares and LANA adapters. NetBIOS is defined in RFCs 1001 and 1002, which are accessible from the RFC button on the NetBIOS Info Tab. NetScanner - The NetScanner tab is one of the most powerful and popular features in NetScanTools Pro. NetScanner sweeps a sequential IP address range and pings every IP address in that range of IP addresses. It will optionally attempt to use NetBIOS to gather MAC addresses and Remote Machine Name Tables from TCP/IP Analysis and Troubleshooting Copyright  2000 podbooks.com


92

Windows targets, translate the responding IP addresses to hostnames, run a whois query on the responding domain name or IP address, query the target for a subnet mask, and request ARP info. One of the most useful purposes for this tool is locating active computers on a subnet. Network Info and Stats - This tab supplies information about the Physical Interfaces, Connections and Statistics by Protocol for all TCP/IP interfaces on this computer. Ping - Standard ICMP echo request test. Port Probe - Port Probe is an active scanning feature designed to determine which ports on a target computer are active and being used by services or daemons, as shown in Figure 3.13. Port Probing is useful in determining many things such as whether a user is running a clandestine web server on an internal corporate network, or possibly determining what type of operating system and vulnerabilities a target host might have. Because this feature can be used maliciously, we have included a warning dialog which is presented when you start a probe. Other possible uses of this feature are to test the response of scanning detection alarm programs.

Figure 3.13: Port probes can be done with an IP address or host name.

Preferences - The Preferences tab is used to set user preferences and control the general operation of the program. Quote - This client function retrieves the 'quote of the day' from a target host per RFC 865. This is also known as QOTD or Cookie and it consists of a short saying or message which is usually randomly selected and therefore different for each client connection. When the quote of the day server receives an incoming TCP/IP Analysis and Troubleshooting Copyright  2000 podbooks.com


93

connection, the contents of the incoming message are ignored and one of the quotes is selected and sent back to the requesting computer. SMTP Email Generator - The SMTP Email Generator tab is provided for sending simple email messages to a target email address using any SMTP mail server. It is intended for test purposes only, not as a replacement for any existing email program. SNMP - NetScanTools Pro supports SNMP v1.0 to gather snapshot data about network or other parameters remotely. You can assess the health of a system and its status to a fine degree depending on the data requested. The SNMP client accesses SNMP servers running on Windows NT, UNIX or NetWare systems. TCP Term - TCP Term is a simple general purpose TCP protocol communication client that operates much like Telnet. TCP Term uses the Telnet protocol to exchange handshaking bytes between the client and server when the connection is made. You can use TCP term as a general purpose testing tool. One very good use is to connect to a mail server and verify a user. It can be used with most any service as a diagnostic tool, provided the target service can operate using ASCII text communication. Time Sync - Time Sync allows your computer to communicate with precision internet based time servers for determining the current time. It also allows you to correct your computer clock to closely match the time at the time servers. If you are running a time synchronization process (such as NTP) on your network, it is not advisable that you re-synch to an external source. TraceRoute - TraceRoute defines the route packets are taking between your computer and a target host. TTCP - TTCP is short for Test TCP connection. Originally written in 1984 for use on BSD UNIX, NetScanTools Pro includes a port of this UNIX network speed test function. It can be used to test the speed of routers and various other network devices. It is a client/server feature. NetScanTools Pro can operate as either a client (receiver) or server (transmitter). Whois - Whois is a client utility that acts as a client interface to a remote server database of domain or IP address registries. One of the largest domain registry databases is maintained by Network Solutions, Inc. (formerly Internic), currently serves as a registry for domains ending with 'com', 'net', 'org', or 'edu'. Other organizations maintain Whois databases for other domain extensions. Many countries also maintain their own Whois servers. NetScanTools Pro has a 'Smart Whois' feature which uses a database to determine which Whois server to use based on the domain extension or IP address. WinSock Info - This tab gives basic information about the active Windows Sockets (Winsock) software interface layer that is running on your computer system. Daytime - Daytime is an old protocol defined in RFC 867. This is a service provided by many computers which can be used as a quick way to determine the local time at that remote computer’s location. Note Ok, we’ve spent a lot of time on NetScanTools. I highly recommend you pay the $150 to get this product. –Laura



94

IP Addressing Calculators There are several calculators available to help calculate subnet addressing for TCP/IP. The Net3Group’s IP Subnet Calculator is a freeware calculator that offers a range of functions. For a given IP address class (A, B, or C) and the number of subnet bits in use, the IP Subnet Calculator's General Info Tab displays the subnet to host ratio. A bit map showing you the location of the class bits, network bits, subnet bits, and host bits within the 32-bit IP address. Also, the class mask and network mask (shown in dotted decimal and dotted hexadecimal) are computed. The Address Info area shows you the hexadecimal equivalent of that address plus the entire range of addresses on the given subnet, as well as the subnet mask, subnet ID, network ID, and host ID, as shown in Figure 3.14.

Figure 3.14: Check your IP subnet values using the IP Subnet Calculator.

The IP Subnet Calculator also includes a subnet host range table. For each possible subnet, a range of IP addresses belonging to that subnet is displayed. From this table, you can copy and paste these subnet/host pairs into a word processor or spreadsheet program. For ISPs and corporations with many Class C addresses, the CIDR (Classless Inter-Domain Routing) Tab displays information on supernetting IP addresses. Within the CIDR area, you can enter an IP address and the number of supernet bits you wish to use and the IP Subnet Calculator displays the number of possible supernets and their address allocation range. The route address and supernet mask used are displayed in dotted decimal and dotted hexadecimal notation, as well. Go to http://www.net3group.com/ipcalc.asp to download the IP Subnet Calculator from Net3Group, Inc.



95

Note RFC 1878 is the most recent document on subnetting. This document allows for an all 1’s and all 0’s subnet value as quoted: “For the sake of completeness within this memo, tables 2-1 and 2-2 illustrate some options for subnet/host portions within selected block sizes using calculations which exclude all-zeros and all-ones subnets [2]. Many vendors only support subnetting based upon this premise. This practice is obsolete! Modern software will be able to utilize all definable networks.” RFC1878 [Pummill & Manning], 1995 -- Laura

The IP Subnet Calculator can be configured to support the ‘all 1s’ value using the Options tab. You should note that the ability to support ‘all 1s’ subnet value is supported by Microsoft NT and Windows 95 and NetWare (with the most recent versions of TCPIP.NLM). Prior to the acceptance of an ‘all 1s’ and ‘all 0s’ subnet, the ‘all 1s’ was considered the only address used to broadcast to a subnet. The ‘all 1s’ subnet was used to broadcast to the entire subnet. The following is an example of binding in an "all ones" subnet. n

address: 192.168.100.195 (195 =1100 0011 binary)

n

mask 255.255.255.192 (192 =1100 0000 binary)



96

Trace Files to Practice On There are numerous trace files included on disk with this book (see Appendix D, “Disk Contents”). We also have a number of trace files at www.packet-level.com. I suggest that you download and review these files. Keep checking out there for more files as we release our lab files (with some documentation) publicly. When you view these trace files, remember to focus on the summary portion first – get a general feel for the traffic and look for recognizable patterns. Then begin to focus on one conversation. Make sure you get a good screen capture utility that will help you document your findings in a graphical manner, as well. Note If you have a suggestion of a trace that you’d like to see, send it to [email protected]. –Laura



97

Chapter Test This test section deals with the troubleshooting tools and techniques defined in this chapter. The answers are in Appendix A – but don’t cheat – really give it a good try before looking up the answers.

3.1 Match the troubleshooting tools with their purpose.

a. ARP

1. Perform an ICMP echo test.

b. Route

2. Perform DNS entry lookups.

c. Traceroute

3. Analyze packet-level communications.

d. Ping

4. Read the MAC-to-IP address tables.

e. Protocol analyzer

5. Read and manipulate local route table entries.

f. SNMP manager

6. Obtain a list of all routers along a path.

g. Nslookup

7. Query agents for a distributed management solution.

3.2 What protocol does ping use? ______________________________________________________________ 3.3 How do you test the MTU of a path using ping? ______________________________________________________________ 3.4 What IP address should you ping first when you are having connectivity problems? _____________________________________________________________ 3.5 Why should you be wary of believing traceroute information? ______________________________________________________________



98

3.6 What command do you use to delete an ARP table entry? ______________________________________________________________ 3.7 How do you view your routing tables? ______________________________________________________________ 3.8 How do you execute netstat to update information every 10 seconds? ______________________________________________________________ 3.9 Why is port scanning considered a possible security breach? ______________________________________________________________ 3.10 What utility enables you to get user information from an email address? ______________________________________________________________



99

Extra Credit: Tracking Your ICMP Traffic This exercise requires the use of a protocol analyzer. If you don’t already own a protocol analyzer, download a demo copy from www.aggroup.com (The AG Group Etherpeek/Tokenpeek products) or www.nai.com (Network Associates Sniffer products). Note In this example, we’ll set up a capture filter using the Sniffer. If you are using a different analyzer you may need to check out the manufacturer’s documentation to learn how to perform a similar function. – Laura

If you have a Sniffer, define a capture filter using the Advanced tab and look under IP, as shown in Figure 3.15. (ICMP does not use either UDP or TCP, so it’s not filed under those folders.)

Figure 3.15: Setting up an Advanced Filter for ICMP on the Sniffer.

Follow these steps to complete the ‘Extra Credit’ assignment: 1. Capture all the ICMP traffic you can on your network. 2. Classify the types of errors you get. 3. Create a short report (complete with screen shots) that details your findings. Be sure to document the devices that are sending the ICMP messages and purpose of each message.



100

Building Your Analysis Report In January 2000, we placed a sample analysis report online at www.packetlevel.com in the references section. This report is in Word format and uses a standard report template. Use this report format to build your ICMP report. Note We would enjoy reading your report –best reports sent to us may be posted (with permission) on the Protocol Analysis Institute website. –Laura



101

Appendix A

Answers to Chapter Tests If you have any suggestions for additional questions that should be added to future revisions of this book, please send them to us at [email protected]. Be sure to let us know which chapter/book the question is located in.

Chapter 1 Answers 1.1 UDP and TCP are the two most common transport protocols used in the TCP/IP suite.

1.2 ARP is used to associate a MAC address with a destination device IP address or the next-hop router’s IP address.

1.3 The following source devices should ARP for the listed destination: Source

Destination

ARP?

10.1.2.6 (prefix 8)

10.1.6.1 (prefix 8)

Yes

10.1.2.6 (prefix 8)

11.2.22.4 (prefix 8)

No

130.57.26.4 (prefix 24) 130.57.22.6 (prefix 24) No 127.2.4.4 (prefix 8)

127.0.2.1 (prefix 8)

No (loopback)

1.4 Some resolution processes that are used to get an IP packet out onto the network when a user types ‘ftp server24” include the port resolution (FTP = port 20/21), route resolution (local v. remote), name resolution (server24=IP address) and MAC resolution.

1.5 ARP and DHCP broadcasts are not routable.

1.6 MAC, and IP headers are used for ICMP communications.

1.7 Only a MAC header is used for ARP communications.


Appendix A: Answers to Chapter Tests

103

1.8 Switches don’t examine the contents of the IP header.

1.9 This is an ARP broadcast packet.

1.10 The protocol ID field is used to identify packets as IP-based.



104

Chapter 2 Answers 2.1

Answers are based on the ARP1.CAP/ARP1.PRN file: 2.1.a. Opcode 1 is used in packet 1; opcode 2 is used in packet 2. 2.1.b. The hardware address of 10.0.0.99 is 0x00A0CC30C8DB.

2.2

Answers are based on the PING1.CAP/ PING1.PRN file: 2.2.a. The echo request does not appear to have crossed a router because the TTL time is still 128 (a common starting TTL value) 2.2.b. The protocol field in the IP header identifies packet #1 as an ICMP packet. 2.2.c. The ICMP Type field identifies packet #1 as an echo request packet.

2.3

Answers based on the TCPSHAKE.CAP file. 2.3.a. The SYN setting in the Flags field of the TCP header identifies packet #1 as a TCP handshake packet. 2.3.b. Both sides of the communications recognize an MSS of 1460 bytes. 2.3.c. The sender and receiver will not use the same window size unless the network congestion creates a common window size for both sides. 130.57.20 1 is advertising an available window size of 32,768 bytes. 130.57.20.10 is advertising a window of 8,760 bytes.

2.4

The WHATIS.CAP/ WHATIS.PRN file contains an ICMP port unreachable packet. The value 0x008a was contained in the original packet that caused the ICMP reply. This hexadecimal port value translates to 138 (NetBIOS) in decimal. If your network becomes flooded with these ICMP port unreachable messages, examine your NetBIOS traffic and configuration for faults.



105

2.5 The following lists how to set up an analyzer filter to capture the following packets: 2.5.a.

IP: filter on MAC header protocol ID field value of 0x0800.

2.5.b. ARP: filter on MAC header protocol ID field value of 0x0806. 2.5.c.

DHCP: filter on UDP source and destination port values 67 and 68 (decimal).

2.5.d.

DNS: filter on the UDP (and TCP) port value 53 (decimal).

2.5.e.

UDP: filter on the IP header protocol field value of 17 (decimal).

2.5.f.

ICMP: filter on the IP header protocol field value of 1 (decimal).

2.5.g

FTP: filter on the source and destination ports 20 and 21 (decimal)



106

Chapter 3 Answers 3.1

Troubleshooting tools with their purpose: a. ARP = 4 b. Route = 5 c. Traceroute = 6 d. Ping = 1 e. Protocol analyzer = 3 f. SNMP manager = 7 g. Nslookup = 2

3.2

Ping uses ICMP echo requests/replies.

3.3

Test the MTU of a path using ping with the -l parameter.

3.4

You should first ping the loopback address (127.0.0.1) when you are having connectivity problems.

3.5

Be wary of believing traceroute information on load balanced networks. The path information may be invalid.

3.6

Use the arp –d command to delete an ARP table entry.

3.7

Use the ROUTE PRINT command to view your routing tables.

3.8

Use the command netstat 10 to execute netstat with a 10 second update timer.

3.9

Port scanning considered a possible security breach because it is often the first exploratory process performed by hackers to see what process are running on remote systems.

3.10 The finger utility enables you to get user information from an email address.



107

Appendix B

The Basic Flow of Data This information is MUST READ for anyone who works on networks. It’s not a lot to go through and it is required reading – find a nice spot where no one will bother you for 30 minutes. Really concentrate and make notes to yourself so you remember the information. Note Here’s a hint on how to retain this information a bit better – I’m sure you have read zillions of books and articles and they are just a blur in your mind. Make extensive notes. The process of getting this information from your brain to your hand will leave a little groove (or scar) inside your arm and you’ll remember it better from the painful process of note taking. Seriously folks – if you want to remember something, try to write it down as you learn it. Try to make a drawing – try to explain it to someone else. There’s no better way to learn than to teach! -Laura

The Damned OSI Model Revisited Ok, ok… you really can’t avoid the OSI (Open Systems Interconnect) model. No matter how much you try. We won’t focus on the entire model, however – we’ll only focus on the layers that deal with the flow of data through an internetwork. Figure B-1 shows the OSI model and the interconnecting devices that must abide by the rules of that layer.

Figure B-1: The OSI model and the interconnecting devices.

In the next section, we’ll examine each of the devices shown and check out how the communications flows through those devices.


Appendix B: The Basic Flow of Data

109

Basic Hub/Repeater Communications As you can see, hubs (and basic multistation access units and repeaters) are the most basic forwarding devices. They forward bits from one port to another. All they see are 1s and 0s. They really aren’t very smart. A packet goes in one port of a hub and it is copied down all other ports of a hub. This, of course, can be very ugly if one device is sending out a broadcast storm. It will affect all other devices connected to the same hub. So, you decide to control the traffic with another device – a bridge or a switch.



110

Basic Bridge and Switch Communications (Layer 2 Devices) Bridges and switches forward based on the destination MAC address. They learn where devices are located when the devices initially communicate on a network. They put this address information in a table, as shown in Figure B-2.

Figure B-2: Switches forward based on the device MAC address.

As you can see from Figure B-2, the contents of the packets do not change when they go through a switch (or a bridge). These devices do not change the network address information or the MAC address information. Interestingly, broadcasts and multicasts are forwarded out all ports (because, after all, they are addressed to the group or entire set of devices). Note These days, it would be very tough to buy a bridge –they have been replaced by switches. And many switches are beginning to ‘cross-dress,’ acting more like routers than switches. –Laura



111

Basic Router Communications (Layer 3 Devices) Routers make forwarding decisions based on the network layer addressing contained in the packet. This information is contained in the IPX and IP headers, for example. Local devices address packets to the router’s MAC address in the MAC header. Upon receipt of the packets, the router must perform the following four steps: 1. Check the Incoming Packet for Corruption; Remove the MAC header Upon receipt of the packet, the checks the packet for MAC-layer errors. The router strips off the MAC header and examines the network layer header to determine what to do with the packet. 2. Examine the Age of the Packet The router must first determine that the packet has not come too far to be forwarded on. IP packets contain a Time to Live value in the IP header. The IP TTL value decrements as the IP packet is forwarded through each router. If an IP packet comes in to a router with a TTL value of 1, the router will discard the packet. A router cannot decrement the value to 1 and forward it on. 3. Determine the Route to the Destination These routers maintain a routing table that lists available networks and the outgoing interface and distance to those networks. Once the router has determined which direction to forward the packet, it must build a new header. 4. Build the New MAC Header and Forward the Packet Finally, the router will build a new MAC header that addresses the packet from the router’s MAC address to the final destination’s MAC address or the MAC address of the next router in the path. Figure B-3 shows the contents of a packet before and after it has gone through a router. It also shows the contents of the router’s routing tables.



112

Figure B-3: Routers forward packets based on the network address.

Go ahead – capture the packets on each side a router on your network. You should be able to see the change in the hop count or TTL value and the new MAC header. This is key – if you ever want to analyze a communication, look at the network layer to determine the actual source and destination of the packet.



113

Exceptions to the Rules… Nowadays, switches and routers are taking on a ‘cross-dressing’ role. Routers can switch data from one port to another without accessing their primary routing tables. Switches can route data when they do not have the MAC address in their tables. The two devices are melting together to create what we now call, “Layer 3 switches” or “switching routers.” These devices typically switch whenever possible (an entry exists in the MAC address table) and route whenever necessary (no MAC address exists in the table and the packet is addressed to another network).



114

Appendix C

UDP/TCP Port List This list was compiled from published records of IANA. You can get the up-todate list from www.iana.org or www.packet-level.com. Note A more complete version of this list accompanies this book on the diskette. The file name is portlist.pdf. – Laura

The port numbers are divided into three ranges: the Well Known Ports, the Registered Ports, and the Dynamic and/or Private Ports. •

The Well Known Ports are those from 0 through 1023.

•

The Registered Ports are those from 1024 through 49151

•

The Dynamic and/or Private Ports are those from 49152 through 65535

This appendix only lists assigned port numbers from 0 to 1023. Keyword ------tcpmux compressnet compressnet rje echo discard systat daytime

qotd msp chargen ftp-data ftp ssh telnet smtp nsw-fe msg-icp msg-auth dsp

time rap rlp graphics name nameserver nicname mpm-flags mpm mpm-snd ni-ftp

Decimal ------0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 42 43 44 45 46 47

Description ----------Reserved TCP Port Service Multiplexer Management Utility Compression Process Unassigned Remote Job Entry Unassigned Echo Unassigned Discard Unassigned Active Users Unassigned Daytime (RFC 867) Unassigned Unassigned [was netstat] Unassigned Quote of the Day Message Send Protocol Character Generator File Transfer [Default Data] File Transfer [Control] SSH Remote Login Protocol Telnet any private mail system Simple Mail Transfer Unassigned NSW User System FE Unassigned MSG ICP Unassigned MSG Authentication Unassigned Display Support Protocol Unassigned any private printer server Unassigned Time Route Access Protocol Resource Location Protocol Unassigned Graphics Host Name Server Host Name Server Who Is MPM FLAGS Protocol Message Processing Module [recv] MPM [default send] NI FTP


Appendix C: UDP/TCP Port List

116

auditd tacacs re-mail-ck la-maint xns-time domain xns-ch isi-gl xns-auth

48 Digital Audit Daemon 49 Login Host Protocol (TACACS) 50 Remote Mail Checking Protocol 51 IMP Logical Address Maintenance 52 XNS Time Protocol 53 Domain Name Server 54 XNS Clearinghouse 55 ISI Graphics Language 56 XNS Authentication 57 any private terminal access xns-mail 58 XNS Mail 59 any private file service 60 Unassigned ni-mail 61 NI MAIL acas 62 ACA Services whois++ 63 whois++ covia 64 Communications Integrator (CI) tacacs-ds 65 TACACS-Database Service sql*net 66 Oracle SQL*NET bootps 67 Bootstrap Protocol Server bootpc 68 Bootstrap Protocol Client tftp 69 Trivial File Transfer gopher 70 Gopher netrjs-1 71 Remote Job Service netrjs-2 72 Remote Job Service netrjs-3 73 Remote Job Service netrjs-4 74 Remote Job Service 75 any private dial out service deos 76 Distributed External Object Store 77 any private RJE service vettcp 78 vettcp finger 79 Finger http 80 World Wide Web HTTP www 80 World Wide Web HTTP www-http 80 World Wide Web HTTP hosts2-ns 81 HOSTS2 Name Server xfer 82 XFER Utility mit-ml-dev 83 MIT ML Device ctf 84 Common Trace Facility mit-ml-dev 85 MIT ML Device mfcobol 86 Micro Focus Cobol 87 any private terminal link kerberos 88 Kerberos su-mit-tg 89 SU/MIT Telnet Gateway ########### PORT 90 also being used unofficially by Pointcast dnsix 90 DNSIX Securit Attribute Token Map mit-dov 91 MIT Dover Spooler npp 92 Network Printing Protocol dcp 93 Device Control Protocol objcall 94 Tivoli Object Dispatcher supdup 95 SUPDUP dixie 96 DIXIE Protocol Specification swift-rvf 97 Swift Remote Virtural File Protocol tacnews 98 TAC News metagram 99 Metagram Relay newacct 100 [unauthorized use] hostname 101 NIC Host Name Server iso-tsap 102 ISO-TSAP Class 0 gppitnp 103 Genesis Point-to-Point Trans Net acr-nema 104 ACR-NEMA Digital Imag. & Comm. 300 cso 105 CCSO name server protocol csnet-ns 105 Mailbox Name Nameserver 3com-tsmux 106 3COM-TSMUX rtelnet 107 Remote Telnet Service snagas 108 SNA Gateway Access Server pop2 109 Post Office Protocol - Version 2 pop3 110 Post Office Protocol - Version 3 sunrpc 111 SUN Remote Procedure Call mcidas 112 McIDAS Data Transmission Protocol



117

ident auth audionews sftp ansanotify uucp-path sqlserv nntp cfdptkt erpc smakynet ntp ansatrader locus-map nxedit unitary locus-con gss-xlicen pwdgen cisco-fna cisco-tna cisco-sys statsrv ingres-net epmap profile netbios-ns netbios-dgm netbios-ssn emfis-data emfis-cntl bl-idm imap uma uaac iso-tp0 iso-ip jargon aed-512 sql-net hems bftp sgmp netsc-prod netsc-dev sqlsrv knet-cmp pcmail-srv nss-routing sgmp-traps snmp snmptrap cmip-man cmip-agent xns-courier s-net namp rsvd send print-srv multiplex cl/1 xyplex-mux mailq vmnet genrad-mux xdmcp nextstep bgp

113 113 114 115 116 117 118 119 120 121 122 123 124 125 126 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179

Authentication Service Audio News Multicast Simple File Transfer Protocol ANSA REX Notify UUCP Path Service SQL Services Network News Transfer Protocol CFDPTKT Encore Expedited Remote Pro.Call SMAKYNET Network Time Protocol ANSA REX Trader Locus PC-Interface Net Map Ser NXEdit Unisys Unitary Login Locus PC-Interface Conn Server GSS X License Verification Password Generator Protocol cisco FNATIVE cisco TNATIVE cisco SYSMAINT Statistics Service INGRES-NET Service DCE endpoint resolution PROFILE Naming System NETBIOS Name Service NETBIOS Datagram Service NETBIOS Session Service EMFIS Data Service EMFIS Control Service Britton-Lee IDM Internet Message Access Protocol Universal Management Architecture UAAC Protocol ISO-IP0 ISO-IP Jargon AED 512 Emulation Service SQL-NET HEMS Background File Transfer Program SGMP NETSC NETSC SQL Service KNET/VM Command/Message Protocol PCMail Server NSS-Routing SGMP-TRAPS SNMP SNMPTRAP CMIP/TCP Manager CMIP/TCP Agent Xerox Sirius Systems NAMP RSVD SEND Network PostScript Network Innovations Multiplex Network Innovations CL/1 Xyplex MAILQ VMNET GENRAD-MUX X Display Manager Control Protocol NextStep Window Server Border Gateway Protocol



118

ris unify audit ocbinder ocserver remote-kis kis aci mumps qft gacp prospero osu-nms srmp irc dn6-nlm-aud dn6-smm-red dls dls-mon smux src at-rtmp at-nbp at-3 at-echo at-5 at-zis at-7 at-8 qmtp z39.50 914c/g anet ipx vmpwscs softpc CAIlic

180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216

dbase mpp uarps imap3 fln-spx rsh-spx cdc masqdialer

217 218 219 220 221 222 223 224 225-241 242 243 244 245 246 247 248 249-255 256 257 258 259 260 261 262 263 264 265-279 280 281 282 283

direct sur-meas dayna link dsp3270 subntbcst_tftp bhfhs rap set yak-chat esro-gen openport nsiiops arcisdms hdap bgmp http-mgmt personal-link cableport-ax rescap

Intergraph Unify Unisys Audit SITP OCBinder OCServer Remote-KIS KIS Protocol Application Communication Interface Plus Five's MUMPS Queued File Transport Gateway Access Control Protocol Prospero Directory Service OSU Network Monitoring System Spider Remote Monitoring Protocol Internet Relay Chat Protocol DNSIX Network Level Module Audit DNSIX Session Mgt Module Audit Redir Directory Location Service Directory Location Service Monitor SMUX IBM System Resource Controller AppleTalk Routing Maintenance AppleTalk Name Binding AppleTalk Unused AppleTalk Echo AppleTalk Unused AppleTalk Zone Information AppleTalk Unused AppleTalk Unused The Quick Mail Transfer Protocol ANSI Z39.50 Texas Instruments 914C/G Terminal ATEXSSTR IPX VM PWSCS Insignia Solutions Computer Associates Int'l License Server dBASE Unix Netix Message Posting Protocol Unisys ARPs Interactive Mail Access Protocol v3 Berkeley rlogind with SPX auth Berkeley rshd with SPX auth Certificate Distribution Center masqdialer Reserved Direct Survey Measurement Dayna LINK Display Systems Protocol SUBNTBCST_TFTP bhfhs Reserved RAP Secure Electronic Transaction Yak Winsock Personal Chat Efficient Short Remote Operations Openport IIOP Name Service over TLS/SSL Arcisdms HDAP BGMP Unassigned http-mgmt Personal Link Cable Port A/X rescap



119

corerjd

284 285-307 novastorbakcup 308 entrusttime 309 bhmds 310 asip-webadmin 311 vslmp 312 magenta-logic 313 opalis-robot 314 dpsi 315 decauth 316 zannet 317 pkix-timestamp 318 ptp-event 319 ptp-general 320 pip 321 rtsps 322 323-343 pdap 344 pawserv 345 zserv 346 fatserv 347 csi-sgwp 348 mftp 349 matip-type-a 350 matip-type-b 351 bhoetty 351 dtag-ste-sb 352 bhoedap4 352 ndsauth 353 bh611 354 datex-asn 355 cloanto-net-1 356 bhevent 357 shrinkwrap 358 tenebris_nts 359 scoi2odialog 360 semantix 361 srssend 362 rsvp_tunnel 363 aurora-cmgr 364 dtk 365 odmr 366 mortgageware 367 qbikgdp 368 rpc2portmap 369 codaauth2 370 clearcase 371 ulistproc 372 legent-1 373 legent-2 374 hassle 375 nip 376 tnETOS 377 dsETOS 378 is99c 379 is99s 380 hp-collector 381 hp-managed-node 382 hp-alarm-mgr 383 arns 384 ibm-app 385 asa 386 aurp 387 unidata-ldm 388 ldap 389 uis synotics-relay

390 391

corerjd Unassigned Novastor Backup EntrustTime bhmds AppleShare IP WebAdmin VSLMP Magenta Logic Opalis Robot DPSI decAuth Zannet PKIX TimeStamp PTP Event PTP General PIP RTSPS Unassigned Prospero Data Access Protocol Perf Analysis Workbench Zebra server Fatmen Server Cabletron Management Protocol mftp MATIP Type A MATIP Type B bhoetty (added 5/21/97) TAG (assigned long ago) bhoedap4 (added 5/21/97) NDSAUTH bh611 DATEX-ASN Cloanto Net 1 bhevent Shrinkwrap Tenebris Network Trace Service scoi2odialog Semantix SRS Send RSVP Tunnel Aurora CMGR DTK ODMR MortgageWare QbikGDP rpc2portmap codaauth2 Clearcase ListProcessor Legent Corporation Legent Corporation Hassle Amiga Envoy Network Inquiry Proto NEC Corporation NEC Corporation TIA/EIA/IS-99 modem client TIA/EIA/IS-99 modem server hp performance data collector hp performance data managed node hp performance data alarm manager A Remote Network Server System IBM Application ASA Message Router Object Def. Appletalk Update-Based Routing Pro. Unidata LDM Version 4 Lightweight Directory Access Protocol UIS SynOptics SNMP Relay Port



120

synotics-broker dis embl-ndt netcp netware-ip mptn kryptolan iso-tsap-c2

392 393 394 395 396 397 398 399

work-sol ups genie decap nced ncld imsp timbuktu prm-sm prm-nm decladebug rmt synoptics-trap smsp infoseek bnet silverplatter onmux hyper-g ariel1 smpte ariel2 ariel3 opc-job-start

400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423

opc-job-track

424

icad-el smartsdp svrloc ocs_cmu ocs_amu utmpsd utmpcd iasd nnsp mobileip-agent mobilip-mn dna-cml comscm dsfgw dasp sgcp decvms-sysmgt cvc_hostd https snpp microsoft-ds ddm-rdb ddm-dfm ddm-ssl as-servermap tserver sfs-smp-net sfs-config creativeserver contentserver creativepartnr macon-tcp scohelp

425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457

SynOptics Port Broker Port Data Interpretation System EMBL Nucleic Data Transfer NETscout Control Protocol Novell Netware over IP Multi Protocol Trans. Net. Kryptolan ISO Transport Class 2 Non-Control over TCP Workstation Solutions Uninterruptible Power Supply Genie Protocol decap nced ncld Interactive Mail Support Protocol Timbuktu Prospero Resource Manager Sys. Man. Prospero Resource Manager Node Man. DECLadebug Remote Debug Protocol Remote MT Protocol Trap Convention Port SMSP InfoSeek BNet Silverplatter Onmux Hyper-G Ariel SMPTE Ariel Ariel IBM Operations Planning and Control Start IBM Operations Planning and Control Track ICAD smartsdp Server Location OCS_CMU OCS_AMU UTMPSD UTMPCD IASD NNSP MobileIP-Agent MobilIP-MN DNA-CML comscm dsfgw dasp sgcp decvms-sysmgt cvc_hostd http protocol over TLS/SSL Simple Network Paging Protocol Microsoft-DS DDM-RDB DDM-RFM DDM-SSL AS Server Mapper TServer Cray Network Semaphore server Cray SFS config server CreativeServer ContentServer CreativePartnr macon-tcp scohelp



121

appleqtc ampr-rcmd skronk datasurfsrv datasurfsrvsec alpes kpasswd digital-vrc mylex-mapd photuris rcp scx-proxy mondex ljk-login hybrid-pop tn-tl-w1 tcpnethaspsrv tn-tl-fd1 ss7ns spsc iafserver iafdbase ph bgs-nsi ulpnet integra-sme

458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484

powerburst avian saft

485 486 487

gss-http nest-protocol micom-pfs go-login ticf-1

488 489 490 491 492

ticf-2

493

pov-ray intecourier pim-rp-disc dantz siam iso-ill isakmp stmf asa-appl-proto intrinsa citadel mailbox-lm ohimsrv crs xvttp snare fcp passgo exec comsat biff

494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 512 512

login

513

apple quick time ampr-rcmd skronk DataRampSrv DataRampSrvSec alpes kpasswd Unassigned digital-vrc mylex-mapd proturis Radio Control Protocol scx-proxy Mondex ljk-login hybrid-pop tn-tl-w1 tcpnethaspsrv tn-tl-fd1 ss7ns spsc iafserver iafdbase Ph service bgs-nsi ulpnet Integra Software Management Environment Air Soft Power Burst avian saft Simple Asynchronous File Transfer gss-http nest-protocol micom-pfs go-login Transport Independent Convergence for FNA Transport Independent Convergence for FNA POV-Ray intecourier PIM-RP-DISC dantz siam ISO ILL Protocol isakmp STMF asa-appl-proto Intrinsa citadel mailbox-lm ohimsrv crs xvttp snare FirstClass Protocol PassGo remote process execution used by mail system to notify users of new mail received; currently receives messages only from processes on the same machine remote login a la telnet; automatic authentication performed based on privileged port numbers and distributed data bases which identify "authentication domains"



122

who

513

shell

514

syslog printer videotex talk

514 515 516 517

ntalk utime efs router

518 519 520 520

ripng ulp ibm-db2 ncp timed tempo stx custix irc-serv courier conference netnews netwall mm-admin iiop opalis-rdv nmsp gdomap apertus-ldp

521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539

uucp uucp-rlogin commerce klogin kshell appleqtcsrvr dhcpv6-client dhcpv6-server afpovertcp idfp new-rwho cybercash deviceshare pirp rtsp dsf remotefs openvms-sysipc sdnskmp teedtap rmonitor monitor chshell nntps

540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563

9pfs whoami

564 565

maintains data bases showing who's logged in to machines on a local net and the load average of the machine cmd like exec, but automatic authentication is performed as for login server spooler videotex like tenex link, but across machine - unfortunately, doesn't use link protocol (this is actually just a rendezvous port from which a tcp connection is established) unixtime extended file name server local routing process (on site); uses variant of Xerox NS routing information protocol - RIP ripng ULP IBM-DB2 NCP timeserver newdate Stock IXChange Customer IXChange IRC-SERV rpc chat readnews for emergency broadcasts MegaMedia Admin iiop opalis-rdv Networked Media Streaming Protocol gdomap Apertus Technologies Load Determination uucpd uucp-rlogin commerce krcmd appleqtcsrvr DHCPv6 Client DHCPv6 Server AFP over TCP IDFP new-who cybercash deviceshare pirp Real Time Stream Control Protocol rfs server openvms-sysipc SDNSKMP TEEDTAP rmonitord chcmd nntp protocol over TLS/SSL (was snntp) plan 9 file service whoami



123

streettalk banyan-rpc ms-shuttle ms-rome meter meter sonar banyan-vip ftp-agent vemmi ipcd vnas ipdd decbsrv sntp-heartbeat bdp scc-security philips-vc keyserver imap4-ssl password-chg submission cal eyelink tns-cml http-alt

566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591

eudora-set http-rpc-epmap tpip cab-protocol smsd ptcnameservice sco-websrvrmg3 acp ipcserver urm nqs sift-uft

592 593 594 595 596 597 598 599 600 601-605 606 607 608

npmp-trap npmp-local npmp-gui hmmp-ind hmmp-op sshell sco-inetmgr sco-sysmgr sco-dtmgr dei-icda digital-evm sco-websrvrmgr escp-ip collaborator aux_bus_shunt cryptoadmin dec_dlm asia passgo-tivoli qmqp 3com-amp3 rda ipp bmpp servstat

609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633

ginad rlzdbase

634 635

streettalk banyan-rpc microsoft shuttle microsoft rome demon udemon sonar banyan-vip FTP Software Agent System VEMMI ipcd vnas ipdd decbsrv SNTP HEARTBEAT Bundle Discovery Protocol SCC Security Philips Video-Conferencing Key Server IMAP4+SSL (use 993 instead) Password Change Submission CAL EyeLink TNS CML FileMaker, Inc. - HTTP Alternate (see Port 80) Eudora Set HTTP RPC Ep Map TPIP CAB Protocol SMSD PTC Name Service SCO Web Server Manager 3 Aeolon Core Protocol Sun IPC server Unassigned Cray Unified Resource Manager nqs Sender-Initiated/Unsolicited File Transfer npmp-trap npmp-local npmp-gui HMMP Indication HMMP Operation SSLshell Internet Configuration Manager SCO System Administration Server SCO Desktop Administration Server DEI-ICDA Digital EVM SCO WebServer Manager ESCP Collaborator Aux Bus Shunt Crypto Admin DEC DLM ASIA PassGo Tivoli QMQP 3Com AMP3 RDA IPP (Internet Printing Protocol) bmpp Service Status update (Sterling Software) ginad RLZ DBase



124

ldaps

636

lanserver mcns-sec msdp entrust-sps repcmd esro-emsdp sanity dwr pssc ldp dhcp-failover rrp aminet obex ieee-mms udlr-dtcp repscmd aodv tinc spmp rmc tenfold url-rendezvous mac-srvr-admin hap pftp purenoise secure-aux-bus

637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 666 667

mdqs doom disclose mecomm meregister vacdsm-sws vacdsm-app vpps-qua cimplex acap dctp vpps-via vpp ggf-ncp mrm entrust-aaas entrust-aams xfr corba-iiop corba-iiop-ssl mdc-portmapper hcp-wismar asipregistry realm-rusd

entrust-kmsh

668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689-703 704 705 706 707 708 709

entrust-ash

710

cisco-tdp

711 712-728 729

elcsd agentx borland-dsj

netviewdm1

ldap protocol over TLS/SSL (was sldap) lanserver mcns-sec MSDP entrust-sps repcmd ESRO-EMSDP V1.3 SANity dwr PSSC LDP DHCP Failover Registry Registrar Protocol (RRP) Aminet OBEX IEEE MMS UDLR_DTCP RepCmd AODV TINC SPMP RMC TenFold URL Rendezvous MacOS Server Admin HAP PFTP PureNoise Secure Aux Bus Unassigned doom Id Software campaign contribution disclosures SDR Technologies MeComm MeRegister VACDSM-SWS VACDSM-APP VPPS-QUA CIMPLEX ACAP DCTP VPPS Via Virtual Presence Protocol GNU Generation Foundation NCP MRM entrust-aaas entrust-aams XFR CORBA IIOP CORBA IIOP SSL MDC Port Mapper Hardware Control Protocol Wismar asipregistry REALM-RUSD Unassigned errlog copy/server daemon AgentX Unassigned Borland DSJ Unassigned Entrust Key Management Service Handler Entrust Administration Service Handler Cisco TDP Unassigned IBM NetView DM/6000 Server/Client



125

netviewdm2 netviewdm3 netgw netrcs flexlm fujitsu-dev ris-cm kerberos-adm rfile loadav kerberos-iv pump qrh rrh tell nlogin con ns rxe quotad cycleserv omserv webster phonebook vid cadlock rtip cycleserv2 submit rpasswd entomb wpages multiling-http wpgs concert qsc mdbs_daemon device fcp-udp itm-mcell-s pkix-3-ca-ra rsync iclcnet-locate iclcnet_svinfo accessbuilder cddbp omginitialrefs xact-backup ftps-data ftps nas telnets imaps ircs

730 731 732-740 741 742 744 745-746 747 748 749 750 750 750 751 752 753 754 755-757 758 759 760 761 762 763 764 765 767 768 769 770 771 772 773 774 775 776 777 778-779 780 781-785 786 787 788-799 800 801 802-809 810 811-827 828 829 830-872 873 874-885 886 887 888 888 889-899 900 901-910 911 912-988 989 990 991 992 993 994

IBM NetView DM/6000 send/tcp IBM NetView DM/6000 receive/tcp Unassigned netGW Network based Rev. Cont. Sys. Flexible License Manager Unassigned Fujitsu Device Control Russell Info Sci Calendar Manager kerberos administration kerberos version iv

send Unassigned

phone Unassigned

Multiling HTTP Unassgined Unassigned Concert QSC Unassigned Unassigned FCP Unassigned itm-mcell-s PKIX-3 CA/RA Unassigned rsync Unassigned ICL coNETion locate server ICL coNETion server info AccessBuilder CD Database Protocol Unassigned OMG Initial Refs Unassigned xact-backup Unassigned ftp protocol, data, over TLS/SSL ftp protocol, control, over TLS/SSL Netnews Administration System telnet protocol over TLS/SSL imap4 protocol over TLS/SSL irc protocol over TLS/SSL



126

pop3s

995

vsinet maitrd busboy garcon applix puprouter cadlock ock

996 997 998 999 999 999 1000 1000 1001-1009 1008 1010 1011-1022 1023 1024

surf

pop3 protocol over TLS/SSL (was spop3) vsinet

Applix ac

Unassigned Possibly used by Sun Solaris???? surf Reserved Reserved Reserved



127

Appendix D

Disk Contents This section lists the trace files that accompany this book. These files are presented in two formats: n

CAP format (Sniffer)

n

PRN format (open with a Word processing program)

If you have an analyzer that reads CAP file formats, open the native CAP files for complete decodes, alarms and trending. The PRN files are only included in case you do not have an analyzer handy. There are some files that are not listed with detail in this section. They are WHATIS.CAP/PRN and MISC1.CAP/PRN. These trace files are used in the chapter tests -- defining their packet sequences and purpose is up to you! Note We regularly put new trace files online at www.packet-level.com. These files can be duplicated and used by all Protocol Analysis Institute members. Join the Protocol Analysis Institute mailing list for more information on upcoming trace files. – Laura

Simple PING PING1.CAP PING1.PRN

A nice, simple little ping from one device (10.0.0.1) to another device (10.0.99.2) on the same network. Ping uses ICMP type 8 (echo) and type 0 (echo reply) packets. This ping was executed on a NetWare server. Notice the matching identifiers in the ICMP header.


Appendix D: Disk Contents

129

Fragmented PING PINGFRAG.CAP PINGFRAG.PRN

This trace is the result of the command "ping -l 4096 10.0.0.1" from a Windows 95 client (10.0.99.2). Notice the fragmentation of the ping packet into multiple packets using a common identification number in the IP header (19485). Look closely at the contents of the ping packet's payload (in the hex window of your analyzer) -- the Microsoft ping utility pads the packet with the alphabet. What would happen if you used the -f parameter (don't fragment parameter) in the command line?



130

TCP Handshake TCPSHAKE.CAP TCPSHAKE.PRN This trace shows the three-way handshake process used to establish a TCP connection. In this trace, the source (130.57.20.10) sends a SYN (synchronize sequence number) request to the destination (130.57.20.1). The second packet is the reply that contains a SYN request (since both sides maintain separate sequence numbers) with an ACK. The final packet is the ACK that finishes up the process. One interesting area to examine is the MSS (maximum segment size) negotiation that takes place in the first and second packets of the handshake process. Each side of this connection offers an MSS value of 1460 bytes. Where did that come from? Well.... 1460 bytes + 20 bytes typical TCP header length + 20 bytes typical IP header length + 18 bytes Ethernet header and CRC = 1518 bytes. That is the maximum allowable packet size on an Ethernet network. Question: Can you tell what application has prompted this handshake process to occur? Do you recognize port value 524? Appendix E contains the basic port value list. A more complete version is on the accompanying disk (portlist.pdf). Answer: Port 524 is assigned to Novell for pure IP (NCP over IP) communications.



131

Basic ARP ARP1.CAP ARP1.PRN These two frames show the basic ARP (Address Resolution Process) that enables one IP device to obtain the MAC (media access control) address of another local device. The MAC address is required to build the Ethernet (or Token Ring.... or FDDI....) header for packets going from one local device to another local device. In this example, you will notice that ARP packets do not have an IP header – ARP is actually protocol independent. The Ethernet type field value for ARP communications is 0x0806 (whereas IP packets use 0x0800). Inside the ARP request, you'll notice that the target hardware address field is filled out with all 0s (0x000000000000). This is an indication that the source does not know the hardware address for 10.0.0.99 (the target's IP address). In the reply, the source and target devices are now reversed with 10.0.0.99 being the source of the reply. The desired MAC address is seen in the reply.



132

Basic IGMP IGMP1.CAP IGMP1.PRN IGMP (Internet Group Management Protocol) is one of the most flexible and exciting protocols in the TCP/IP protocol family. IGMP enables a device to dynamically join and leave groups on the network. If a router or switch is IGMPcapable, it will only send group traffic down ports that contain member devices. In this trace, you will see a device (10.0.0.99) join two groups by sending out a multicast to 224.0.0.2 (all routers this subnet) and 224.0.1.22 (Service Location Protocol, SLP, group). One of the interesting aspects of IP multicasting is process of creating a MAC multicast address from the IP multicast address. For example in packet #1 of this trace, the destination MAC address is 0x01005E000002. Now the leading 0x01 indicates that this is a multicast address. The last three bytes (0x000002) is taken from the end of the IP address (decimal 0.0.2). Before you look at the second packet, can you figure out what the last three bytes of the MAC address should be? Hint: Convert 0 first, then 1, then 22.



133

DNS Configuration Fault DNSFAULT.CAP DNSFAULT.PRN This trace contains 9 packets that show what happens when DNS configurations are done improperly. In this case, we can see in packets 1 and 2, the client (10.0.0.99) is ARPing for two devices that never answer. Those were the client's first choices as DNS servers, but they are not up currently. In packet 3, we can see the client make a DNS query to 10.0.0.1. The reply (ICMP port unreachable) indicates that the desired port number (53) is not in use at the destination -- 10.0.0.1 does not have the DNS server daemon loaded. The poor pathetic client tries desperately to ARP for his first two DNS queries, but again receives no answer. He again tries 10.0.0.1 and gets the ICMP port unreachable message. <sigh> It's a bad day for this client.



134

DHCP Bootup Sequence DHCPBOOT.CAP DHCPBOOT.PRN This trace depicts the typical four-packet startup sequence of a DHCP client. The DHCP Discovery (sent to the broadcast address) indicates that this client last used 10.0.99.2 as it's address (see 'Request Specific IP Address' in the trace file). You will also notice that the Discovery packet came from source IP address 0.0.0.0. The offered address is 10.0.99.2 (how nice) -- this packet is sent directly to the clients known hardware address and the assumed IP address (won't conflict with duplicate IP address yet because it was directed to the correct host at the data link layer). When the client sends the DHCP Request packet (packet #3), look at the source and destination addresses – the client does not assume anything yet. Finally, the server ACKs the client and provides the desired information regarding default gateway server IP address, subnet mask, lease time (short), DNS server and DNS domain. Note Cool clean trace. More DHCP traces to be released soon. –Laura



135

Appendix E

Hexadecimal-DecimalBinary Conversion Chart It may look a bit ugly, but it’s quite useful. This chart contains the conversion between hexadecimal, decimal and binary numbers from 0 to 255. Remember, you can always use the Windows calculator (in scientific mode) to perform these calculations.

You can download a softcopy (PDF) format of this chart from the References section at www.packet-level.com.

Decimal Value 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44

Hexadecimal Value 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C

Binary Value 0000 0000 0000 0001 0000 0010 0000 0011 0000 0100 0000 0101 0000 0110 0000 0111 0000 1000 0000 1001 0000 1010 0000 1011 0000 1100 0000 1101 0000 1110 0000 1111 0001 0000 0001 0001 0001 0010 0001 0011 0001 0100 0001 0101 0001 0110 0001 0111 0001 1000 0001 1001 0001 1010 0001 1011 0001 1100 0001 1101 0001 1110 0001 1111 0010 0000 0010 0001 0010 0010 0010 0011 0010 0100 0010 0101 0010 0110 0010 0111 0010 1000 0010 1001 0010 1010 0010 1011 0010 1100


Appendix E: Hex-Decimal-Binary Conversion Chart

137

45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94

2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E 3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E

0010 1101 0010 1110 0010 1111 0011 0000 0011 0001 0011 0010 0011 0011 0011 0100 0011 0101 0011 0110 0011 0111 0011 1000 0011 1001 0011 1010 0011 1011 0011 1100 0011 1101 0011 1110 0011 1111 0100 0000 0100 0001 0100 0010 0100 0011 0100 0100 0100 0101 0100 0110 0100 0111 0100 1000 0100 1001 0100 1010 0100 1011 0100 1100 0100 1101 0100 1110 0100 1111 0101 0000 0101 0001 0101 0010 0101 0011 0101 0100 0101 0101 0101 0110 0101 0111 0101 1000 0101 1001 0101 1010 0101 1011 0101 1100 0101 1101 0101 1110



138

95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144

5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E 7F 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90

0101 1111 0110 0000 0110 0001 0110 0010 0110 0011 0110 0100 0110 0101 0110 0110 0110 0111 0110 1000 0110 1001 0110 1010 0110 1011 0110 1100 0110 1101 0110 1110 0110 1111 0111 0000 0111 0001 0111 0010 0111 0011 0111 0100 0111 0101 0111 0110 0111 0111 0111 1000 0111 1001 0111 1010 0111 1011 0111 1100 0111 1101 0111 1110 0111 1111 1000 0000 1000 0001 1000 0010 1000 0011 1000 0100 1000 0101 1000 0110 1000 0111 1000 1000 1000 1001 1000 1010 1000 1011 1000 1100 1000 1101 1000 1110 1000 1111 1001 0000



139

145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194

91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E 9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE BF C0 C1 C2

1001 0001 1001 0010 1001 0011 1001 0100 1001 0101 1001 0110 1001 0111 1001 1000 1001 1001 1001 1010 1001 1011 1001 1100 1001 1101 1001 1110 1001 1111 1010 0000 1010 0001 1010 0010 1010 0011 1010 0100 1010 0101 1010 0110 1010 0111 1010 1000 1010 1001 1010 1010 1010 1011 1010 1100 1010 1101 1010 1110 1010 1111 1011 0000 1011 0001 1011 0010 1011 0011 1011 0100 1011 0101 1011 0110 1011 0111 1011 1000 1011 1001 1011 1010 1011 1011 1011 1100 1011 1101 1011 1110 1011 1111 1100 0000 1100 0001 1100 0010



140

195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244

C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4

1100 0011 1100 0100 1100 0101 1100 0110 1100 0111 1100 1000 1100 1001 1100 1010 1100 1011 1100 1100 1100 1101 1100 1110 1100 1111 1101 0000 1101 0001 1101 0010 1101 0011 1101 0100 1101 0101 1101 0110 1101 0111 1101 1000 1101 1001 1101 1010 1101 1011 1101 1100 1101 1101 1101 1110 1101 1111 1110 0000 1110 0001 1110 0010 1110 0011 1110 0100 1110 0101 1110 0110 1110 0111 1110 1000 1110 1001 1110 1010 1110 1011 1110 1100 1110 1101 1110 1110 1110 1111 1111 0000 1111 0001 1111 0010 1111 0011 1111 0100



141

245 246 247 248 249 250 251 252 253 254 255

F5 F6 F7 F8 F9 FA FB FC FD FE FF

1111 0101 1111 0110 1111 0111 1111 1000 1111 1001 1111 1010 1111 1011 1111 1100 1111 1101 1111 1110 1111 1111



142

Index

A ACK · 51. See acknowledgment flag acknowledgment · 17 flag · 49 number · 53 acknowledgment flag · 49 address translation · 24 addressing problems · 72 AG Group · 12 AG Group NetTools · 87 aggregation · 24 aging timer · 11 all ones subnet · 24, 96 all zero subnet · 24 analysis procedures analyzing broadcast/multicast traffic · 42 analyzing ICMP communications · 60 analyzing IPv4 packets · 35 analyzing UDP-based communications · 44 TCP sequencing/acknowledgment process · 52 TCP startup/handshake process · 51 TCP windowing process · 54 TCP-based communications · 47 analysis procedures ARP communications · 56 analyzer hex field · 8 translation problem · 8 anycast · 23, 27 application developers · 7 application name · 7 application-layer elements · 2 ARP · 10, 13, 20 broadcast · 6, 11, 22 cache · 6 cache aging timer · 11 command · 10 definition · 3 hardware type field · 57 length of hardware address field · 58 length of protocol address field · 58 opcode field · 58 packet structure · 17 reply · 58 request · 58 sender’s hardware address field · 58 sender’s protocol address field · 58 target hardware address field · 59 target protocol address field · 59 unanswered ARPs · 43 utility · 82, 87, 89 ARP cache · 10, 11, 22

ARP protocol type field · 58 ARP reply · 56 ARP request · 56 ARP1.CAP/ARP1.PRN · 28

B basic switched network · 20 BBN · 7 blind faith · 6 BOOTP/DHCP server process · 45 BrainShare · 74 bridges · 20 broadcast forwarding · 27 broadcast · 6, 11, 20, 21, 23, 41 255.255.255.255 · 27 adresses · 27 all-nets broadcast · 27 connectionless communication · 44 controlling with routers · 20 excessive · 43 RIP 1 routing · 72 storm · 21 subnet broadcast · 27 trace · 43 unanaswered · 43 brut force attacks · 74

C cache · 11 CAP format · 4 capture filter · 100 capture filtering · 34 capturing packets · 34 ARP traffic · 34 broadcasts · 34 DHCP traffic · 34 DNS traffic · 34 ICMP traffic · 34 multicasts · 34 OSPF traffic · 34 RIP traffic · 34 TCP traffic · 34 UDP traffic · 34 Character Generator · See chargen chargen · 8, 89 Windows NT · 90 CIDR · 24 Cisco EIGRP · 40 Cisco prioritization schemes · 37 class A addresses · 23


index

143

class B addresses · 23 class C addresses · 23 class-based addressing · 23 classless addressing · 23, 24 Classless Interdomain Routing · 24 collision rate · 54 connectionless · 44 connectionless communications · 18 connection-oriented communication · 47 connection-oriented communications · 17 CRC · 22, 40 cross-dressing · 21

D data link error detection mechanism · 40 data link header · 11 data portion, reading the · 8 daytime protocol · 90 de facto standards · 17 decode warning · 66 decode window · 8 decrementing TTL · 21, 22 default gateway · 6, 22, 72 default gateway problem · 83 default network masks · 23 Denial of Service · 52, 60, 74, 90 destination address · 21, 22 destination port · 22 destination unreachable messages · 60 detail window · 51 DHCP · 20, 45, 72 ACK · 73 bootup process · 41 definition · 3 lease time · 73 NACK · 73 negative acknowledgement · 73 release · 73 typical problems · 73 DHCP/BOOTP Client · 8 Server · 8 Dig · 92 discovery · 20 display filtering · 34 distributed analyzers · 75 DNS · 5, 8, 72, 73 definition · 3 query · 10 sample packet · 14 sample problem · 75 server entry · 10 DNS query · 5 domain extensions · 94 Don’t Fragment bit · 38 DoS · See Denial of Service downlink · 20 duplicate IP address test · 56 dynamic port numbers · 7, 14, 45

dynamic route entry · 60

E echo messages · 60 echo packet · 18 EGP · 40 email validate utility · 90 equation for sequence/acknowledgments · 53 Ethernet header · See MAC header Ethernet II frame structure · 13, 17, 58 Ethernet II frame type · 14 Ethernet type field · 13 Ethernet_802.3 (raw) frame type · 40 Etherpeek · 12, 34 Ethertype 0x0800 · 13 Ethertype 0x0806 · 13

F favorite protocol · 60 FCS · See Frame Check Sequence FDDI header · See MAC header Federal Express · 47 FIN · See finish flag finger · 87, 90 finger services warning · 91 finish flag · 49, 50 firewalls · 49 fragmentation · 38 a good thing? · 38 reassembly · 39 timer expiration · 39 typical problems · 73 frame check sequence · 22 FTP · 5, 73 commands · 8 data · 8 FTP, File Transfer Protocol · 2

G Graham, Buck · 23

H handshake · 47 hex window · 67 hexadecimal format · 4 hops · 14, 21, 39 host entry · 22 host file · 10, 73 host name · 5 Hot Standby Router Protocol · 7 HTTP · 8 HTTP, Hypertext Transfer Protocol · 2


index

144

I IANA · 7, 8 ICMP · 31, 40, 67, 72, 100 alternate address for host · 66 alternate host address code list · 63 Alternate Host Address code list intpretation · 65 bad length · 66 communication administratively prohibited · 65 communication with destination host is administratively prohibited · 65 communication with destination network is administratively prohibited · 64 definition · 3 destination host unknown · 64, 72 destination host unreachable for type of service · 65 destination network unknown · 64 destination network unreachable for type of service · 65 destination unreachable code list · 63 Destination Unreachable code list interpretation · 64 fragmentation reassembly time exceeded · 66 fragmentation needed and don't fragment was set · 64 host precedence violation · 65 host unreachable · 64 missing a required option · 66 parameter problem code list · 63 pointer indicates the error · 66 port unreachable · 64 precedence cutoff in effect · 65 protocol unreachable · 64 redirect code list · 63 redirect datagram for the host · 65 redirect datagram for the network (or subnet) · 65 redirect datagram for the type of service and host · 65 redirect datagram for the type of service and network · 65 source host isolated · 64 source route failed · 64 time exceeded code list · 63 Time Exceeded code list interpretation · 66 time to live exceeded in transit · 66 ICMP echo packet · 38 ICMP echo request/reply sequence · 28 ICMP messages · 62 ICMP packet structure checksum field · 66 code field · 63 type field · 62 ICMP Packet Structure · 18 ICMP redirect · 6 ICMP redirect messages · 72 ICMP redirection message · 83 IDRP · See Inter-domain Routing Protocol IEEE 802.3 specification · 22 IGMP · 18, 20, 40 IGMP1.CAP/IGMP1.PRN · 28 IGRP · 40 incoming buffers · 49 Inter-Domain Routing Protocol · 40 Internet Group Management Protocol · See IGMP Internet, connecting to the · 24

Introduction to Network Analysis · 4, 14, 21, 34, 75 IP address in packet · 4 addressing system · 23 definition · 2 destination address field · 41 flags field · 38 fragment offset field · 39 header · 9 header checksum field · 40 header fields/functions · 36 header length field · 36 identification field · 38 IPv4 addressing · 23 IPv6 addressing · 25 options field · 41 protocol field · 40 routing · 20, 21 source address field · 41 time to live field (TTL) · 39 total length field · 38 type of service field · 37 version field · 36 IP · 4, 72, 100 IP addressing calculators · 95 IP internet header length (IHL) field · 41 IP options · 37 IP protocol poster · 36 IPCONFIG · 86, 87 IPv6 · 27 IPX · 40

L LANalyzer for Windows · 34 large switched network · 20 last fragment · 38 layer 2 devices · 20 [email protected] · 50 length fields calculating · 45 IP header length calculation · 45 IP total length calculation · 45 UDP length calculation · 45 local cache · 10 local routing table · 6 login and password · 5 loop · 21 loopback address 127.0.0.1 · 78 loose source routing · 41 loving DHCP can hurt · 73

M MAC address · 4 resolution process · 4, 10, 11 MAC address table · 20 MAC header · 11, 13, 17, 22 mapping of routers and gateways · 92


index

145

Maximum Transmission Unit · 38 media access control · 4 monitor incoming TCP/IP connections · 90 More Fragments to Come bit · 38 MTU · See Maximum Transmission Unit mud · 53 multicast · 20, 21, 23, 28, 41, 44 excessive · 43 multicasts addresses · 26 multiple connections · 51

N naked little IP packets · 22 naked little network-layer packet · 40 name resolution · 4, 9 name scan · 87 names · 4 nasty router · 40 NAT · See network address translation gateway NCP-over- IP · 7 NCP-over-IP · 16 NDS over TCP/IP · 73 Net3Group · 95 Protocol Analysis Institute · 87 NetBIOS · 46, 92 NetScanner utility · 92 NetScanTools · 75, 87, 88 netstat · 84, 87 network address translation gateway · 24 network analyzer · 75 network congestion · 54 network entry · 22 network mask · 5, 10 network topology utility · 92 Next Expected Sequence Number (Sniffer) · 48 next-hop router · 4, 6, 22, 59 nicknames · 4 Northwest Performance Software, Inc. · 88 Novell · 7 nslookup · 87, 92 NTP · 8

O OSI model · 2 OSPF · 18, 22, 40 definition · 3 outgoing buffers · 49

P packet, building a TCP/IP · 4 padding · 45 pattern analysis · 14 phantom byte · 54 PID · See Protocol ID Field

ping · 18, 60, 74, 78, 82, 87 PING1.CAP/PING1.PRN · 28 PINGFRAG.CAP/PINGFRAG.PRN · 38 ping-pong in networking · 49 pingscan · 87 POP3 · 8 port number · 4 port resolution · 4 port scanning · 87 warning · 87 PORTLIST.PDF · 45, 48 ports port 1031 (BBN) · 7 port 1985 (HSRP) · 7 port 20 (FTP data) · 5 port 21 (FTP command) · 7 port 21 (FTP commands) · 5 port 524 (NCP-over-IP) · 7 port 53 (DNS) · 14 precedence · 37 precedence bits · 37 prefix number · 24 print servers · 43 private address · 24 10 net · 24 172.16 net · 24 192.168 subnet · 24 private port numbers · 7 PRN format · 4 protocol analyzer · 75 protocol ID field · 13 PSH · See push flag pure IP · 7 push flag · 49

Q quote utility · 93

R RARP reply · 58 request · 58 RARP · 58 redirect messages · 60 registered ports · 7 request/reply pattern · 14 request/reply/reply pattern · 14 reset flag · 49 RFCs RFC 1001 - NetBIOS · 92 RFC 1002 - NetBIOS · 92 RFC 1288 - finger protocol · 90 RFC 1413 - identification protocol · 91 RFC 1519 - supernetting · 25 RFC 1878 - subnetting · 24 RFC 2001 - TCP Windowing · 54 RFC 2474 – DS field · 37


index

146

RFC 2526 – IPv6 reserved anycast addresses · 27 RFC 768 - UDP · 44 RFC 792 - ICMP · 60 RFC 793 - TCP · 47 RFC 826 - ARP · 56 RFC 865 - Quote · 93 RFC 867 - Daytime · 94 RFC 903 - RARP · 58 RFC1878 - subnetting · 96 RIP · 22 definition · 3 version 1 · 72 route · 74 route resolution · 4, 10 route summarization · 24 route utility · 82 routed protocol · 22 router · 6 router queues · 22, 37, 39 routing problems · 72 routing protocols · 22 routing table · 22, 83 RST · See reset flag

S scalability · 23 sequence number · 53 sequencing · 17 service discovery problems · 73 Service Location Protocol · 73 sliding window · 54 SLP · 8, 20, 73 Smart Whois utility (NetScanTools) · 94 SMTP · 94 SMTP Email Generator utility · 94 Sniffer · 100 Sniffer Pro · 34 Sniffer Pro alarm list · 76 Sniffer traces · 12 SNMP · 7, 8, 94 SNMP on NetWare · 94 SNMP on Unix · 94 SNMP on Windows NT · 94 SNMP Traps · 8 SNMP, Simple Network Management Protocol · 2 source address · 21 source port number · 52 spanning tree · 20 stack elements · 2 standalone analyzer · 75 starting sequence numbers · 51 stealthy attacks · 74 Stevens, W. Richard · 55 strict source routing · 41 subnetting · 24 subnetwork · 23 subnetwork mask · 23 summary window · 51 supernetting · 25

switch interface · 20 switches · 20 switching IP packets · 20 symbolic name · 4, 9 SYN · 51, 74. See synchronize flag synchronize flag · 49

T target protocol address · 57 TCP · 40 acknowledgment · 47 acknowledgment number field · 48 available bandwidth · 50 buffer space · 47 checksum field · 50 connection problems · 73 data offset field · 48 destination port field · 48 flags field · 49 frozen window · 50 options field(s) · 50 pseudo header · 50 receiver buffer · 50 sequence number field · 48 sequence/acknowledgment process · 47 source port field · 48 startup sequence · 47 urgent pointer field · 50 window field · 50 window sizes · 47 TCP buffer · 54 TCP connection · 49 TCP header · 7 TCP header length · 48 TCP segment · 48 TCP teardown sequence · 54 TCP Term test · 94 TCP/IP Illustrated, Volume I The Protocols · 55 TCP/IP Packet Structure · 16 TCP/IP Packet Structures · 13 TCP/IP problems · 72 telnet · 8, 49 throughput tests · 87 Time to Live · 14 Token Ring · 38 Token Ring header · See MAC header trace files · 4, 13, 28, 33, 97 traceroute traceroute for NetWare · 81 traceroute for Unix · 81 traceroute · 39, 74, 80, 87, 94 traceroute for Linux · 81 traceroute warnings · 80 tracert · See traceroute transmitting analyzer products · 74 transport layer · 2 Trivial FTP · 17 TTCP (Test TCP connection) · 94


index

147

TTL · 14. See Time to Live two IP headers · 18 two-way conversation · 11 two-way handshakes · 52 type of service bits · 37

U UDP · 40 checksum field · 45 definition · 3 destination port field · 45 length field · 45 port fields · 44 source port field · 44 UDP/IP packet structure · 14 UDP header · 7 undecoded packets · 67 unicast · 23 unicast addresses · 26 unknown addresses · 22 unroutable · 17 untrusted source · 49 uplink · 20 URG · See urgent flag urgent flag · 49

W weird little protocol · 56 well known port number · 45 well known ports · 7, 14 whois · 87, 94 window size · 17 windowing problems · 73 Windows calculator · 67 Windows utilities · 78 winipcfg · 85 WinSock · 94 Winsock 2.0 upgrade · 89 www.iana.org · 40, 41, 58, 66 www.ietf.org · 24 www.packet-level.com · 28, 87 www.nist.gov · 91 www.nwconnection.com · 74

Z Zone Transfer · 92


index

148

TCP/IP Analysis and Troubleshooting An introductory guide to TCP/IP packets, troubleshooting tools and techniques Laura A. Chappell

Chapter 1: Basic TCP/IP Communications and Packet Structures This chapter examines how TCP/IP packets are built and sent onto the network. The port resolution, name resolution, route resolution and MAC address resolutions are defined in this chapter. This chapter works hand-inhand with Appendix B, “The Basic Flow of Data,” which contains basic knowledge for all network analysts and troubleshooters.

Chapter 2: Packet-Level Protocols This chapter focuses on the basic format sets of various TCP/IP packet structures. Emphasis is placed on the function and format of IP header structures, UDP header structures, TCP header structures, ICMP packets and ARP packets. These are the fundamental structures seen on all TCP/IP networks. The most exciting area of this chapter is the section that interprets the ICMP messages that you may see on your own network.

Chapter 3: Troubleshooting Tools and Techniques This chapter details the required tools needed for any analyst/troubleshooter. The tools listed include the very basic ones (ping and traceroute) as well as some more advanced tools, such as the Sniffer and NetScanTools Pro 2000. (Additional details on network analysis can be found in the podbook “Introduction to Network Analysis.”)

Each chapter includes a test to check out your level of comprehension.

ISBN: 1-893939-01-4 EAN: 978-1893-939011 US $34.95 Electronic Version US $59.95 Hardcopy [Binding kit available from www.podbooks.com.]

TCP IP Analysis and Troubleshooting

TCP IP Analysis and Troubleshooting Toolkit

Troubleshooting Windows 2000 TCP IP

IP Analysis and Troubleshooting Toolkit

TCP-IP. плох.кач

Curso Arquitectura Tcp - Ip

TCP IP. Сетевое администрирование

TCP IP. Учебный курс

TCP-IP Illustrated

Эффективное программирование TCP-IP

Семейство протоколов TCP-IP

Introduccion A Tcp Ip

TCP IP Explained

TCP IP: biblia

Analisis Seguridad Tcp Ip

TCP IP Protocol Suite

Bulletproofing Tcp Ip Windows Nt

Curso De Protocolos Tcp - Ip

Troubleshooting IP Routing Protocols

Troubleshooting IP Routing Protocols

Troubleshooting IP routing protocols

TCP IP Illustrated. The Protocols

TCP-IP. Архитектура, протоколы, реализация

TCP IP Illustrated. The Implementation

TCP IP For Windows 2000

The ABCs of TCP IP

Introduction to TCP-IP sockets

Practical TCP-IP and Ethernet Networking

Advanced IP EIGRP - Troubleshooting 315

TCP IP Analysis and Troubleshooting