TCP/IP Analysis and Troubleshooting Toolkit phần 5 doc

UDP Header Figure 5-1 shows the UDP header. The fields of the UDP header are defined in the sections that follow. Source Port The source port is a 16-bit number greater than 1023 that is chosen by a user of a UDP based application. These ports are known as ephemeral ports because they are only used for the lifetime of the connection (ephemeral means short- lived). Ephemeral source port numbers are chosen by the IP stack and used by the transport layer for the delivery of data to upper-layer applications. They function essentially the same as the Ethernet Ethertype and the IP Protocol ID field. When a source host sends data using UDP to a destination host, it chooses an unused source port greater than 1023 to be placed into the UDP Source Port field. The application on the destination station in turn uses this port number in the Destination Port field when it sends data back to the host. Destination Port The destination port is also a 16-bit number, which may be greater or less than 1023. In the early ages of TCP/IP, most applications used what are called well- known port numbers. Unlike ephemeral ports, applications will keep a well- known port open for as long as the application is running. Well-known port numbers are in the range of 0 to 1023. Hosts using these applications would use a source (ephemeral) port greater than 1023 and a destination port (well-known) between 0 and 1023. For example, DNS uses UDP port 53. A DNS server allo- cates the use of port 53 on the local server. When a client sends a DNS request to that server, it will use a source ephemeral port and a destination port of 53. When the DNS server replies to the request, it will use the client’s ephemeral port as the destination UDP port and port 53 as the source port. So many appli- cations now use TCP and UDP that the defining line between which ports appli- cations use is blurred. It is typical to see applications using ports ranging from 0 to 65535. Table 5-1 shows some typical UDP well-known application ports. Table 5-1 Common UDP Application Ports APPLICATION UDP PORT NetBIOS Name Service 137 Simple Network Management Protocol 161 Domain Name Services 53 Routing Information Protocol 521 User Datagram Protocol 157 08 429759 Ch05.qxd 6/26/03 8:58 AM Page 157 Figure 5-1 UDP header. NOTE A listing of all UDP and TCP ports can be found on the Internet Ports Database at www.portsdb.org/. UDP Length The value of the UDP length field is the sum of the length of the UDP header (8 bytes) and the length of the data it is carrying. A quick way of determining the UDP length field is to subtract 20 bytes from the value in the IP length field. Because the IP header is always 20 bytes long, the resulting value will always be equal to the length of the UDP header and its data. For example, if IP is carrying 1,480 bytes, you know that UDP is carrying 1,452 bytes (1,480 – 20(IP) – 8(UDP Header) = UDP data). Of course, you can always look at the UDP length field, but sometimes it’s easier to just perform the subtraction in your head. UDP Checksum The UDP checksum field covers the entire UDP header and the data being car- ried by UDP. The UDP header checksum is optional; an application does not have to use it. Eliminating the UDP checksum calculation can sometimes speed up packet processing on slow hosts. If the checksum is not used, the sender must transmit the checksum as all ones. When a receiving station sees all ones in the checksum field, it will not attempt to recalculate the checksum. WARNING When you are making the decision to turn off UDP checksums, it is important that an application have the ability to guarantee data integrity. There is always the possibility that data could become corrupted after it is received by the MAC layer. In that case, if UDP checksums are not enabled and the application has no data integrity functions, then the data will be passed to the application, which will have no knowledge that the data it is receiving is corrupted. 16 bits Source Port UDP Length Data 16 bits Destination Port UDP Checksum 158 Chapter 5 08 429759 Ch05.qxd 6/26/03 8:58 AM Page 158 The UDP checksum includes something called the UDP pseudo-header. The pseudo-header is a virtual extension to the UDP header, which the entire UDP checksum is computed across. The pseudo-header is not included in the actual header but used to provide another guarantee that the UDP data has been received by the correct host. Figure 5-2 shows the UDP psuedo-header. When a source transmits a UDP packet, it builds a virtual UDP packet including the source and destination IP addresses, the IP Protocol ID, and the UDP Length field. The UDP checksum field includes these virtual fields when it calculates the checksum value. When the destination UDP layer receives the UDP data- gram, it takes the source IP address, destination IP address, and protocol ID from the IP header for use in recreating the virtual UDP psuedo-header. The destination host literally rebuilds the same virtual UDP packet that the source host used to calculate its UDP checksum. It then compares the checksum it cal- culated to the checksum received in the packet to make sure they are the same. Although you never actually see the pseudo-header in the UDP packet, it is important to understand that this process exists. Psuedo-headers make the UDP checksum more resilient in guaranteeing data integrity between hosts. By disabling the UDP checksum, you may gain performance, but lose the ability to provide data integrity to your applications, unless of course, the application has a way of providing it. Data The data field of the UDP datagram contains the data the destination applica- tion is to receive, the application being defined by the destination UDP port number. Figure 5-2 The UDP psuedo-header. 16 bits 32-Bit Source IP Address 32-Bit Destination IP Address pseudo-header UDP header UDP LengthProtocol IDZero Source Port UDP Length Data 16 bits Destination Port UDP Checksum User Datagram Protocol 159 08 429759 Ch05.qxd 6/26/03 8:58 AM Page 159 UDP Communication Process Communications at the transport layer are sometimes called client/server communications. Typically one host (the client) needs to use an application on another host (the server). NOTE Although there is no requirement for either host to actually be a server- type machine, it is easier to view the communications processes in terms of a client and a server. When a client needs to use an application on a remote host using the UDP protocol, it needs to know a couple pieces of information. ■■ The IP address of the host where the application resides ■■ The destination UDP port number of the application There are several different methods through which a host can obtain the IP address of a destination host. One is the Domain Name System (DNS); another is the Windows Internet Naming System (WINS). CROSS-REFERENCE I talk about these methods in Chapters 7 and 8. For now, assume that a host knows that an application resides on another host with the IP address of 172.16.1.15. After obtaining the IP address, it now needs to know what the applications destination UDP port number is. All UDP and TCP port numbers are stored in a file named the services file. On Unix sys- tems, the services file is typically located in /etc/services. On Windows 2000 hosts, it can be found in c:\windows\system32\drivers\etc. Figure 5-3 shows a typical Windows 2000 services file. The services file contains all mappings of applications to port numbers for both TCP and UDP. When a host needs to know the destination UDP or TCP port of an application, it searches the services file to find the correct port number. Custom applications install their respective UDP or TCP ports in this file. 160 Chapter 5 08 429759 Ch05.qxd 6/26/03 8:58 AM Page 160 Figure 5-3 Windows 2000 services file. (continues) # Copyright (c) 1993-1999 Microsoft Corp. # # This file contains port numbers for well-known services defined by IANA # # Format: # # <service name> <port number>/<protocol> [aliases ] [#<comment>] # echo 7/tcp echo 7/udp discard 9/tcp sink null discard 9/udp sink null systat 11/tcp users #Active users systat 11/tcp users #Active users daytime 13/tcp daytime 13/udp qotd 17/tcp quote #Quote of the day qotd 17/udp quote #Quote of the day chargen 19/tcp ttytst source #Character generator chargen 19/udp ttytst source #Character generator ftp-data 20/tcp #FTP, data ftp 21/tcp #FTP. control telnet 23/tcp smtp 25/tcp mail #Simple Mail Transfer Protocol time 37/tcp timserver time 37/udp timserver rlp 39/udp resource #Resource Location Protocol nameserver 42/tcp name #Host Name Server nameserver 42/udp name #Host Name Server nicname 43/tcp whois domain 53/tcp #Domain Name Server domain 53/udp #Domain Name Server bootps 67/udp dhcps #Bootstrap Protocol Server bootpc 68/udp dhcpc #Bootstrap Protocol Client tftp 69/udp #Trivial File Transfer gopher 70/tcp finger 79/tcp http 80/tcp www www-http #World Wide Web kerberos 88/tcp krb5 kerberos-sec #Kerberos kerberos 88/udp krb5 kerberos-sec #Kerberos hostname 101/tcp hostnames #NIC Host Name Server iso-tsap 102/tcp #ISO-TSAP Class 0 rtelnet 107/tcp #Remote Telnet Service pop2 109/tcp postoffice #Post Office Protocol - Version 2 pop3 110/tcp #Post Office Protocol - Version 3 sunrpc 111/tcp rpcbind portmap #SUN Remote Procedure Call sunrpc 111/udp rpcbind portmap #SUN Remote Procedure Call auth 113/tcp ident tap #Identification Protocol uucp-path 117/tcp nntp 119/tcp usenet #Network News Transfer Protocol ntp 123/udp #Network Time Protocol epmap 135/tcp loc-srv #DCE endpoint resolution epmap 135/udp loc-sr #DCE endpoint resolution netbios-ns 137/tcp nbname #NETBIOS Name Service netbios-ns 137/udp nbname #NETBIOS Name Service netbios-dgm 138/udp nbdatagram #NETBIOS Datagram Service netbios-ssn 139/tcp nbsession #NETBIOS Session Service imap 143/tcp imap4 #Internet Message Access Protocol pcmail-srv 158/tcp #PCMail Server snmp 161/udp #SNMP snmptrap 162/udp snmp-trap #SNMP trap print-srv 170/tcp #Network PostScript bgp 179/tcp #Border Gateway Protocol irc 194/tcp #Internet Relay Chat Protocol ipx 213/udp #IPX over IP ldap 389/tcp #Lightweight Directory Access Protocol User Datagram Protocol 161 08 429759 Ch05.qxd 6/26/03 8:58 AM Page 161 Figure 5-3 Windows 2000 services file. (continued) https 443/tcp MCom https 443/udp MCom microsoft-ds 445/tcp microsoft-ds 445/udp kpasswd 464/tcp # Kerberos (v5) kpasswd 464/udp # Kerberos (v5) isakmp 500/udp ike #Internet Key Exchange exec 512/tcp #Remote Process Execution biff 512/udp comsat login 513/tcp #Remote Login who 513/udp whod cmd 514/tcp shell syslog 514/udp printer 515/tcp spooler talk 517/udp ntalk 518/udp efs 520/tcp #Extended File Name Server router 520/udp route routed timed 525/udp timeserver tempo 526/tcp newdate courier 530/tcp rpc conference 531/tcp chat netnews 532/tcp readnews netwall 533/udp #For emergency broadcasts uucp 540/tcp uucpd klogin 543/tcp #Kerberos login kshell 544/tcp krcmd #Kerberos remote shell new-rwho 550/udp new-who remotefs 556/tcp rfs rfs_server rmonitor 560/udp rmonitord monitor 561/udp ldaps 636/tcp sldap #LDAP over TLS/SSL doom 666/tcp #Doom Id Software doom 666/udp #Doom Id Software kerberos-adm 749/tcp #Kerberos administration kerberos-adm 749/udp #Kerberos administration kerberos-iv 750/udp #Kerberos version IV kpop 1109/tcp #Kerberos POP phone 1167/udp #Conference calling ms-sql-s 1433/tcp #Microsoft-SQL-Server ms-sql-s 1433/udp #Microsoft-SQL-Server ms-sql-m 1434/tcp #Microsoft-SQL-Monitor ms-sql-m 1434/udp #Microsoft-SQL-Monitor wins 1512/tcp #Microsoft Windows Internet Name Service wins 1512/udp #Microsoft Windows Internet Name Service ingreslock 1524/tcp ingres l2tp 1701/udp #Layer Two Tunneling Protocol pptp 1723/tcp #Point-to-point tunnelling protocol radius 1812/udp #RADIUS authentication protocol radacct 1813/udp #RADIUS accounting protocol nfsd 2049/udp nfs #NFS server knetd 2053/tcp #Kerberos de-multiplexor man 9535/tcp #Remote Man Server 162 Chapter 5 08 429759 Ch05.qxd 6/26/03 8:58 AM Page 162 After an application finds out the destination UDP port of the application, the following happens: 1. It chooses a port number greater than 1023 for use in the source UDP port field. 2. Upon reception of the packet, the destination host examines the desti- nation UDP port number to determine what application should receive the UDP data. 3. When the application responds to the source host, it reverses the UDP port numbers, placing the destination stations source UDP port in the destination UDP port field and its own source UDP port in the source field. Figure 5-4 illustrates this process. A DNS name resolution request is sent from host 192.168.1.100 to the DNS server at 151.197.0.39. In frame 1 of the trace, the source UDP port is 3422 and the destination port is the well-known DNS port for UDP of 53. In Frame 2 the response from the DNS server to the client is from the source DNS port 53 to the client’s UDP port 3422. User Datagram Protocol 163 MICROSOFT PORT QUERY TOOL Microsoft has a tool called Port Query (portqry.exe) that allows you to query other hosts to see if the host is running a specific application over a well- known UDP or TCP port. This tool is a great way to confirm that an application is listening on a port and also to confirm that a firewall or router isn’t filtering out traffic destined to certain ports. It can be downloaded at www.microsoft.com.The following output shows the Port Query tool being used to verify that my ISPs DNS server is in fact listening for DNS Name Resolution Requests on UDP port 53: C:\apps>portqry -n 151.197.0.39 -e 53 -p UDP Querying target system called: 151.197.0.39 Attempting to resolve IP address to a name IP address resolved to home4.bellatlantic.net UDP port 53 (domain service): LISTENING 08 429759 Ch05.qxd 6/26/03 8:58 AM Page 163 Figure 5-4 UDP communication process. Case Studies in UDP Communications As I have discussed, UDP is a very simple protocol, providing only multiplex- ing and data protection services to upper-layer applications. In a very simple sense, it either works, or it doesn’t work. Its simplicity makes it very depen- dent on the lower-layer networking services to operate without errors. UDP has no methods to retransmit lost data or handle more than minimal flow con- trol issues via ICMP Source Quench messages. Client DNS Server Client DNS Server 192.168.1.100 151.197.0.39 3422 53 Source IP Addr Dest IP Addr Source UDP Port Dest UDP Port 192.168.1.100 151.197.0.393422 53 Dest IP Addr Source IP AddrDest UDP Port Source UDP Port 164 Chapter 5 08 429759 Ch05.qxd 6/26/03 8:58 AM Page 164 Given all that, it is important to understand the reasoning behind why applications use UDP over TCP when troubleshooting a problem. In this sec- tion, I take a look at several application protocols that use UDP. I discuss the basic functionality of the application and try to illustrate how the application handles reliability services that UDP does not provide. Name Resolution Services In Chapters 7 and 8, I discuss two kinds of name resolution services in IP net- works. One is used to resolve NetBIOS names, and the other is used to resolve IP host names. Both are similar in nature. Both of these application protocols use UDP as their method of transport rather than TCP. There are a couple of reasons that UDP is a good choice for these applications: ■■ The first reason is that they are request/response applications. A single request is sent and a single response is received. In file transfer applica- tions, a server often sends multiple segments of data back to a client. A protocol such as TCP can gather multiple small data segments and group them into a single large TCP segment. This method of grouping small segments together into one larger segment prevents wasting net- work bandwidth on multiple small packets (see the sidebar “Packet Efficiency” in this chapter). UDP has no such functionality. Every time an application writes data to the UDP layer, a packet is generated. UDP doesn’t provide segment assembly services, and therefore, is much faster. Every time UDP receives data, it creates a UDP header and passes its data down to the IP layer. For request/response applications, UDP is fast and efficient because it doesn’t provide any reliability. ■■ Second, most request/response applications will retry their requests if they don’t receive an answer. For example, if a client sends a DNS name resolution request to a DNS name server and does not receive a response, it will attempt the resolution process again and again, until it eventually gives up. In Figure 5-5, you see a client sending repeated DNS requests to a DNS server that is not responding. After the first attempt in Frame 1, the client tries again after 1 second, 2 seconds, 5 seconds, and 9 seconds, and then finally gives up and displays the Unknown host www.tracemasters.com message. Notice also that the attempts are roughly doubled after each name resolution request. The client host waits a little bit longer each time before making another request in the hope that the network problem, which is preventing name resolution, will be resolved. Here, the reliability is built into the protocol itself. There is no need to use a protocol (like TCP) that pro- vides reliability. The nature of most protocols like DNS is that they will perform their own retransmissions of data. User Datagram Protocol 165 08 429759 Ch05.qxd 6/26/03 8:58 AM Page 165 Figure 5-5 No DNS response. Routing Information Protocol The Routing Information Protocol, or RIP as it is commonly known, is used to distribute routing information among routers on an IP network. It operates by sending routing information in one or more IP broadcast packets. Routers using the RIP protocol send out routing advertisements every 30 seconds. Each packet can contain multiple route entries. When there are more route entries than can fit in a single RIP packet, the routes are sent in consecutive RIP packets. Each router sends out as many RIP packets during a single advertise- ment interval as are necessary to advertise its entire routing table. RIP is what is known as a distance vector routing protocol. A distance vector rout- ing protocol simply advertises what routes it knows to other routers, with those routers passing on information they have heard to other routers. The process con- tinues until all routers have built a routing table of all routes in the network. Since hosts depend on the network to provide end-to-end routing of data, it would seem that it would be important enough for routing protocols such as RIP to use a reliable protocol like TCP for advertising routing information. However, RIP does not; it uses UDP. If a single RIP packet is lost, UDP will not retransmit the data. Fortunately, because of the way RIP works, the loss of a single packet does not affect the routing process. Routers listening to RIP broadcasts will not automatically flag a route as unreachable if they miss a single RIP packet con- taining the route entry. Listening routers typically wait a multiple of several advertisement intervals before declaring a route unreachable. For example, RIP advertises route entries every 30 seconds. A router listening for RIP advertise- ments will delete a route from its route table only after not hearing an advertise- ment for the route after three route advertisement intervals. In the case of RIP, this amounts to 90 seconds until a router declares a route unreachable. So why then doesn’t RIP use a reliable protocol like TCP? To understand why a reliable protocol like TCP is unnecessary, examine Figure 5-6. The router at 10.239.1.81 is advertising 109 separate route entries every 30 seconds via the RIP protocol. In its second advertisement, you see only 100 route entries being advertised, as the last RIP packet containing the last 9 entries is lost. 30 seconds 166 Chapter 5 08 429759 Ch05.qxd 6/26/03 8:58 AM Page 166 [...]... 101.1241 85 102.1 258 13 103.130192 113.706383 114.710 654 120 .51 6427 Time 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 ... 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 255 . 255 . 255 . 255 Dst Other Addr 10.239.1.81 10.239.1.81 10.239.1.81 10.239.1.81 10.239.1.81 10.239.1.82 10.239.1.80 10.239.1.82 10.239.1.80... protocol 167 Figure 5- 6 Router RIP advertisements 30 second interval 30 second interval 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 Frame 31.036494 32.03772 33.042707 34.0400 45 35. 044908 51 .632907 52 .4 355 22 52 .637429 53 .4367 05 54.437882 55 .440118 56 .443 953 65. 07 658 66.077872 67.078963 68.080116 82.66 959 6 83.6741 85 86.4 759 79 87.477196 88.478409 89.47 954 7 90.484427 99.121799... RIP Response, 25 Entries (ver 1) Response, 25 Entries (ver 1) Response, 25 Entries (ver 1) Response, 25 Entries (ver 1) Response, 9 Entries (ver 1) Response, 25 Entries (ver 1) Response, 25 Entries (ver 1) Response, 8 Entries (ver 1) Response, 25 Entries (ver 1) Response, 25 Entries (ver 1) Response, 25 Entries (ver 1) Response, 9 Entries (ver 1) Response, 25 Entries (ver 1) Response, 25 Entries (ver... Entries (ver 1) Response, 25 Entries (ver 1) Response, 25 Entries (ver 1) Response, 25 Entries (ver 1) Response, 8 Entries (ver 1) Response, 25 Entries (ver 1) Response, 25 Entries (ver 1) Response, 25 Entries (ver 1) Response, 25 Entries (ver 1) Response, 9 Entries (ver 1) Response, 25 Entries (ver 1) Response, 25 Entries (ver 1) Response, 25 Entries (ver 1) Response, 25 Entries (ver 1) Response,... talk about TCP sequence and acknowledgement numbers in Chapter 6 169 170 Chapter 5 T I P When troubleshooting connections through a firewall, a protocol analyzer is an excellent tool to have on hand because by using it you can immediately determine what ports and protocols are being blocked by a firewall The following case studies illustrate why you sometimes need to utilize proper analysis techniques... feature called Port Mapper to find out Figure 5- 8 illustrates a situation we ran into after migrating several Unix systems to a different location and putting them behind a firewall Figure 5- 7 PCAnywhere session 171 172 Chapter 5 Figure 5- 8 NFS in action Unix administrators notified us that they could no longer mount remote Unix volumes across the network Figure 5- 8 shows a packet capture of what happened... source IP address and multiple port and destination IP address pairs Data Sequencing and Acknowledgment The 32-bit sequence and acknowledgment fields are used by TCP on hosts that are communicating with each other These fields allow two hosts to track the data they are sending to each other and to inform the sending host that they have received (or not received) TCP data The sequence and acknowledgment... KEVIN Notice in Frame 3 what host KEVIN’s initial sequence number was It was 55 4776182 You can see in Frame 4 that the acknowledgment field contains the number 1 85 186 Chapter 6 55 4776183, which is exactly the original initial sequence number sent by host KEVIN plus 1 This is the method used by TCP to acknowledge data SYN and FIN flags all consume one sequence number When a host wants to acknowledge... up higher and higher into each layer of the OSI model, protocols become more complex TCP is no exception to this statement Its complexity derives from TCP’s rich set of features and functionality By not learning its inner functions, you risk missing the ability to completely understand the protocol, which, in troubleshooting scenarios, can be deadly This chapter seeks to help you understand TCP from . (ver. 1) 7 52 .4 355 22 255 . 255 . 255 . 255 10.239.1.80 RIP Response, 25 Entries (ver. 1) 8 52 .637429 255 . 255 . 255 . 255 10.239.1.82 RIP Response, 8 Entries (ver. 1) 9 53 .4367 05 255 . 255 . 255 . 255 10.239.1.80 RIP. 25 Entries (ver. 1) 10 54 .437882 255 . 255 . 255 . 255 10.239.1.80 RIP Response, 25 Entries (ver. 1) 11 55 .440118 255 . 255 . 255 . 255 10.239.1.80 RIP Response, 25 Entries (ver. 1) 12 56 .443 953 255 . 255 . 255 . 255 . (ver. 1) 15 67.078963 255 . 255 . 255 . 255 10.239.1.81 RIP Response, 25 Entries (ver. 1) 16 68.080116 255 . 255 . 255 . 255 10.239.1.81 RIP Response, 25 Entries (ver. 1) 17 82.66 959 6 255 . 255 . 255 . 255 10.239.1.82 RIP