------------------------- Week 15 Notes for CST8165 ------------------------- -Ian! D. Allen - idallen@idallen.ca Remember - knowing how to find out an answer is more important than memorizing the answer. Learn to fish! RTFM! (Read The Fine Manual) ------------------- INDEX to this file: - IPV6 - FTP - Network Address Translation (NAT) - FTP through NAT using ALG - IP Tunneling (IP in IP) ------------------- ============================================================================= State of IPV6 and DNS --------------------- http://tools.ietf.org/html/rfc3363 "Working group consensus as perceived by the chairs of the DNSEXT and NGTRANS working groups is that: a) AAAA records are preferable at the moment for production deployment of IPv6, and b) that A6 records have interesting properties that need to be better understood before deployment. c) It is not known if the benefits of A6 outweigh the costs and risks. "Thus, we are forced to conclude that indiscriminate use of long A6 chains is likely to lead to increased user frustration." Q: Which DNS record type is currently preferred for IPV6 addresses? Q: How many bits are in an IPV6 address? ============================================================================= File Transfer Protocol - FTP ---------------------------- http://tools.ietf.org/html/rfc114 (Apr 1971, 17 pages, no index) http://tools.ietf.org/html/rfc454 (Feb 1973, 35 pages, no index) http://tools.ietf.org/html/rfc686 (May 1975 "leaving well enough alone") http://tools.ietf.org/html/rfc691 (May 1975 "one more try on the FTP") http://tools.ietf.org/html/rfc765 (Jun 1980, 70 pages, no index!) http://tools.ietf.org/html/rfc959 (Oct 1985, 69 pages, no index!) - another text-based protcol (you can run it with "nc") - commands are not case-sensitive - but it's tricky to handle the parallel data connection at the same time... "The objectives of FTP are 1) to promote sharing of files (computer programs and/or data), 2) to encourage indirect or implicit (via programs) use of remote computers, 3) to shield a user from variations in file storage systems among hosts, and 4) to transfer data reliably and efficiently. FTP, though usable directly by a user at a terminal, is designed mainly for use by programs. Q: Give two (of four) objectives of the FTP protocol. Q: T/F, FTP was designed for humans to use directly (e.g. via netcat). 2.3. THE FTP MODEL (p.8) - nice ASCII art diagram PI - protocol interpreter DTP - data transfer process http://en.wikipedia.org/wiki/File_Transfer_Protocol "FTP runs exclusively over TCP. The FTP server always listens on port 21 for incoming connections from FTP clients. A connection to this port from the FTP Client forms the control stream on which commands are passed to the FTP server from the FTP client and on occasion from the FTP server to the FTP client. For the actual file transfer to take place, a different connection is required which is called the data stream. Depending on the transfer mode, the process of setting up the data stream is different. In active mode, the FTP client opens a random port (> 1023), sends the FTP server the random port number on which it is listening over the control stream and waits for a connection from the FTP server. When the FTP server initiates the data connection to the FTP client it binds the source port to port 20 on the FTP server. In passive mode, the FTP Server opens a random port (> 1023), sends the FTP client the port on which it is listening over the control stream and waits for a connection from the FTP client. In this case the FTP client binds the source port of the connection to a random port greater than 1023. Q: Describe how FTP works (including port numbers), and including a description of the difference between FTP "active" and "passive" modes. http://slacksite.com/other/ftp.html "One of the most commonly seen questions when dealing with firewalls and other Internet connectivity issues is the difference between active and passive FTP and how best to support either or both of them. Hopefully the following text will help to clear up some of the confusion over how to support FTP in a firewalled environment. - The diagram on this site is wrong: no [4] is sent from client - uses the TELNET protocol on the control connection Q: What protocol does FTP use for its control connection? - control channel can extend across multiple servers (Fig. 2 p.9) http://en.wikipedia.org/wiki/FXP Q: T/F, the FTP control channel can chain across multiple servers. Q: T/F, an FTP client can arrange to transfer data from one remote server to another without routing this data through the client's connection. - FTP servers can be told to open ports on *any* machine! http://en.wikipedia.org/wiki/FTP_bounce_attack http://www.cert.org/tech_tips/ftp_port_attacks.html "To conform with the FTP protocol, the PORT command has the originating machine specify an arbitrary destination machine and port for the data connection. However, this behavior also means that an attacker can open a connection to a port of the attacker's choosing on a machine that may not be the originating client. Making this connection to an arbitrary machine for unauthorized purposes is the FTP bounce attack. Q: What command in the FTP protocol set permits an "FTP bounce attack", and how is that command used to do the attack? - ftp commands only have one argument! - a rename requires RNFR followed by RNTO Q: How do you implement a "rename" using the FTP command set? - server responses are 3-digit codes followed by message text - client "should wait" for server reply before issuing next command (5.4 p.49) Q: T/F, FTP is a pipelining/streaming protocol - you can send many commands without waiting for server responses in between. - multi-line server responses use the SMTP '-' trick, e.g. 220-message for the first line, and code followed by space (e.g. 220 end) for the last line - but, unlike SMTP, the intervening lines may look like anything! - if a server response might generate something that looks like it might prematurely end the response, the line must be prefaced with "some neutral character" (e.g. a space) Q: How does the FTP server produce a multi-line response? - reply codes are structured (Section 4.2 p.36) 1yz Positive Preliminary reply 2yz Positive Completion reply 3yz Positive Intermediate reply 4yz Transient Negative Completion reply 5yz Permanent Negative Completion reply x0z Syntax x1z Information x2z Connections x3z Authentication and accounting x4z Unspecified x5z File system Q: T/F, FTP 3-digit response codes have assigned meanings for both the first and second digit. [do not memorize these codes!] - command response sequences (5.4 p.49) - state diagrams (6 p.54) - see RETR, p.51 125, 150 (110) 226, 250 425, 426, 451, 551, 552 Using netcat on the control connection -------------------------------------- Because FTP has a separate data connection, you would need two netcat sessions going to transfer a file, and you would have to get the port numbers right. The FTP control connection is essentially the same as Telnet - it uses the same protocol. Note: The STAT command does the same as LIST; but, it receives the server info over the control connection instead of over the data connection; this makes it useful on a (single) netcat connection. Some basic directory listing is possible with STAT, even without a data connection: $ nc -v ftp.idallen.ca 21 ftp.idallen.ca [72.18.159.15] 21 (ftp) open 220---------- Welcome to Pure-FTPd [TLS] ---------- 220-You are user number 3 of 50 allowed. 220-Local time is now 20:46. Server port: 21. 220-This is a private system - No anonymous login 220-IPv6 connections are also welcome on this server. 220 You will be disconnected after 15 minutes of inactivity. ---> HELP 214-The following SITE commands are recognized ALIAS CHMOD IDLE 214 Pure-FTPd - http://pureftpd.org/ ---> USER idallen 331 User idallen OK. Password required ---> PASS XXXX 230-User idallen has group access to: idallen 230 OK. Current restricted directory is / ---> STAT .twmrc 213-STAT -rw-r--r-- 1 32096 idallen 14706 Jun 21 2002 .twmrc 213 End. ---> NOOP 200 Zzz... ---> QUIT 221-Goodbye. You uploaded 0 and downloaded 0 kbytes. 221 Logout. or 421 Timeout - try typing a little faster next time Q: What is the difference between the FTP "STAT" and "LIST" commands? Q: T/F, since the FTP "LIST" returns data via the data connection, there is no way to use FTP to see a directory listing of a remote site without opening a data connection first. Active FTP session with server responses ---------------------------------------- Section 7, p.59 Many FTP commands have options that let you see the server/client dialog: $ ftp -vd ftp.idallen.ca Connected to ftp.idallen.ca. 220---------- Welcome to Pure-FTPd [TLS] ---------- 220-You are user number 1 of 50 allowed. 220-Local time is now 23:13. Server port: 21. 220-This is a private system - No anonymous login 220-IPv6 connections are also welcome on this server. 220 You will be disconnected after 15 minutes of inactivity. Name (ftp.idallen.ca:idallen): idallen ---> USER idallen 331 User idallen OK. Password required Password: ---> PASS XXXX 230-User idallen has group access to: idallen 230 OK. Current restricted directory is / ---> SYST 215 UNIX Type: L8 Remote system type is UNIX. Using binary mode to transfer files. ftp> ls i.sh ---> PORT 192,168,1,250,164,39 # 164*256 + 39 = 39424 200 PORT command successful ---> LIST i.sh 150 Connecting to port 39424 -rwxr-xr-x 1 32096 idallena 1737 Oct 19 2005 i.sh 226-Options: -a -l 226 1 matches total ftp> get i.sh local: i.sh remote: i.sh ---> TYPE I 200 TYPE is now 8-bit binary ---> PORT 192,168,1,250,172,40 # 172*256 + 40 = 44072 200 PORT command successful ---> RETR i.sh 150 Connecting to port 44072 226-File successfully transferred 226 0.132 seconds (measured here), 12.86 Kbytes per second 1737 bytes received in 0.15 secs (11.5 kB/s) ftp> quit ---> QUIT 221-Goodbye. You uploaded 0 and downloaded 2 kbytes. 221 Logout. Passive FTP session with server responses ----------------------------------------- Same as above, but using PASV mode where the server tells the client what port to connect to: $ ftp -vd -p ftp.idallen.ca Connected to ftp.idallen.ca. 220---------- Welcome to Pure-FTPd [TLS] ---------- 220-You are user number 1 of 50 allowed. 220-Local time is now 23:24. Server port: 21. 220-This is a private system - No anonymous login 220-IPv6 connections are also welcome on this server. 220 You will be disconnected after 15 minutes of inactivity. Name (ftp.idallen.ca:idallen): idallen ---> USER idallen 331 User idallen OK. Password required Password: ---> PASS XXXX 230-User idallen has group access to: idallen 230 OK. Current restricted directory is / ---> SYST 215 UNIX Type: L8 Remote system type is UNIX. Using binary mode to transfer files. ftp> get i.sh local: i.sh remote: i.sh ---> TYPE I 200 TYPE is now 8-bit binary ---> PASV 227 Entering Passive Mode (72,18,159,15,164,151) # 164*256 + 151 = 42135 ---> RETR i.sh 150 Accepted data connection 226-File successfully transferred 226 0.000 seconds (measured here), 24.03 Mbytes per second 1737 bytes received in 0.02 secs (85.7 kB/s) ftp> ls i.sh ---> TYPE A 200 TYPE is now ASCII ---> PASV 227 Entering Passive Mode (72,18,159,15,218,170) # 218*256 + 170 = 55978 ---> LIST i.sh 150 Accepted data connection -rwxr-xr-x 1 32096 idallen 1737 Oct 19 2005 i.sh 226-Options: -a -l 226 1 matches total ftp> quit ---> QUIT 221-Goodbye. You uploaded 0 and downloaded 2 kbytes. 221 Logout. Q: What response does an FTP server give to a PASV command, and what do the arguments in the response mean? Aside: Network Address Translation (NAT) ---------------------------------------- http://tools.ietf.org/html/rfc2663 (Aug 1999, 30 pages, "informational") http://tools.ietf.org/html/rfc3022 (Jan 2001, 16 pages, "informational") "Basic NAT and NAPT are two variations of traditional NAT, in that translation in Basic NAT is limited to IP addresses alone, whereas translation in NAPT is extended to include IP address and Transport identifier (such as TCP/UDP port or ICMP query ID). NAT and NAPT allow machines on a private, internal network to send their packets through a NAT router. Network Address Translation modifies the *source* address (and with NAPT, possibly the port) of TCP or UDP packets leaving the router for the Internet, and it modifies the *destination* address (and possibly the port) of reply packets returning to the router from the Internet. The saved source address is placed into the destination address of the reply packets when they return. Example of NAT: A. client - 192.168.0.2 B. router - internal network interface: 192.168.0.1 C. router - external network interface: 206.47.37.39 D. server - 72.18.159.15 1. Client sends packet destined for server with [src=A, dst=D] 2. Packet arrives at router internal interface B on the way to D: - Router applies NAT, removing and remembering the internal src address A and changing the src address A to be its own external interface address C in the IP packet header - Router saves the src address A in a table for later use (Every NAT connection needs its own separate saved address!) 3. Packet leaves router external interface C with new [src=C, dst=D] 4. Packet traverses Internet and arrives at server dst D. 5. Server constructs a reply packet with [src=D, dst=C] 6. Reply packet traverses Internet and arrives at router interface C: - Router recognizes that this packet is a reply to the earlier packet for which the router saved the src address A. The router takes the saved src address A out of its table and puts it back into the dst address of the reply packet 7. Reply packet leaves router internal interface B with new [src=D, dst=A] 8. Reply packet arrives at client interface A. Round trip complete. - The client has no idea that the packets were changed by the router. - The server thinks it is talking directly to the router. - The server has no idea that the *actual* source of the packets is the client behind the router. - The data portion of packets is untouched by plain NAT/NAPT. - TCP checksums also have to be fixed! (pseudo-header) - IP packet fragments cannot be translated (missing header info) - in "NAPT" (Port Translation), the router also saves and changes the TCP/UDP port numbers on packets leaving the router for the Internet, and the router replaces the saved port numbers (as well as replacing the saved IP addresses) as the reply packets return - NAT provides some security against unexpected incoming TCP/UDP packets. - your private net is hidden behind the router - mappings from Internet to private net cannot be triggered from the Internet side of the router; the internal net client must initiate the first packet through the NAT process in the router - NAT can also map ICMP packets to/from an external network Q: How does NAT work? Describe the changes made to a packet as it leaves a client, traverses a NAT-ing router to a server, and then the reply packet returns from the server to the router to the client. Q: T/F, a router's NAT translation table can be initialized either by a packet going from internal net to external, or by a packet going from external net to internal http://tools.ietf.org/html/rfc2663 (considerations, Aug 1999) "NAT devices are application unaware in that the translations are limited to IP/TCP/UDP/ICMP headers and ICMP error messages only. NAT devices do not change the payload of the packets, as payloads tend to be application specific. Q: T/F, a basic NAT device changes IP addresses only in the IP header, not in the data portion of a packet. "NAT devices (without the inclusion of Application Level Gateways [ALGs]) do not examine or modify transport payload. For this reason, NAT devices are transparent to applications in many cases. There are two areas, however, where NAT devices often cause difficulties: 1) when an application payload includes an IP address, and 2) when end-to-end security is needed. Q: T/F, if an application protocol puts an IP address into the data portion of a packet, a plain NAT router (no ALG) can't find it. On designing new protocols: http://tools.ietf.org/html/rfc3235 (Jan 2002, 13 pages, "informational") "This document discusses those things that application designers might wish to consider when designing new protocols. While many common Internet applications will operate cleanly in the presence of Network Address Translators, others suffer from a variety of problems when crossing these devices. Q: Why is it a bad idea for a protcol to put IP information in the data portion of a packet (as FTP does)? Active FTP through NAT using a smart router ------------------------------------------- http://tools.ietf.org/html/rfc2616 - section 7.1 p.24 "7.1. FTP support" Normally (without an Application Level Gateway [ALG]), NAT doesn't change anything in the *data* in each packet. For active FTP, which sends a local FTP client IP address to the remote server in the data part of the PORT command packet, NAT isn't clever enough to fix the IP address hidden in the PORT packet's data. The server gets the local client IP address from the PORT command and is unable to use it to contact the client; because, the IP address in the data packet is the client's *internal* network address, not the Internet-visible address of its NAT router. To fix this, better routers have "application specific gateways [ALGs]" built in that reach into the data portion of the FTP PORT packet and modify it, replacing the client internal address in the PORT command with the public external address of the router (and fixing all the checksums and TCP window sizes as well!). - note that this sort of ALG intervention requires unencrypted data packets! http://tools.ietf.org/html/rfc2616 "[The] "PORT" command and "PASV" response in FTP control session payload identify the IP address and TCP port that must be used for the data session it supports. The arguments to the PORT command and PASV response are an IP address and a TCP port in ASCII. An FTP ALG is required to monitor and update the FTP control session payload so that information contained in the payload is relevant to end nodes. The ALG must also update NAT with appropriate data session tuples and session orientation so that NAT could set up state information for the FTP data sessions. "Because the address and TCP port are encoded in ASCII, this may result in a change in the size of packet. For instance, 10,18,177,42,64,87 is 18 ASCII characters, whereas 193,45,228,137,64,87 is 20 ASCII characters. If the new size is same as the previous, only the TCP checksum needs adjustment as a result of change of data. If the new size is less than or greater than the previous, TCP sequence numbers must also be changed to reflect the change in length of FTP control data portion. A special table may be used by the ALG to correct the TCP sequence and acknowledge numbers. The sequence number and acknowledgement correction will need to be performed on all future packet of the connection. Q: T/F, an ALG in a router may need to change the size of an FTP packet to fully implement NAT. Example of NAT through a router with an FTP ALG: Below are two ethereal TCP stream dumps. The first dump shows the TCP stream as seen on the local net side of the router (the side connected to the FTP client). The second dump shows the same TCP stream as seen on the external Internet side of the router. Note that the ALG in the router has changed (and remembered!) the IP address in the PORT command. The ALG in a smart router has to notice the FTP traffic and reach into the data portion of the control stream TCP packet to replace the actual PORT IP address 192.168.1.250 with the Internet address 206.47.37.39. Dump 1: This TCP stream trace is taken on the client side of the router. Traffic leaving host 192.168.1.250 heading to router (from ethereal): 220---------- Welcome to Pure-FTPd [TLS] ---------- 220-You are user number 1 of 50 allowed. 220-Local time is now 23:34. Server port: 21. 220-This is a private system - No anonymous login 220-IPv6 connections are also welcome on this server. 220 You will be disconnected after 15 minutes of inactivity. ---> USER idallena 331 User idallena OK. Password required ---> PASS XXXX 230-User idallena has group access to: idallena 230 OK. Current restricted directory is / ---> SYST 215 UNIX Type: L8 ---> PORT 192,168,1,250,181,11 # 181*256 + 11 = 46347 200 PORT command successful ---> LIST i.sh 150 Connecting to port 46347 226-Options: -a -l 226 1 matches total ---> TYPE I 200 TYPE is now 8-bit binary ---> PORT 192,168,1,250,237,226 # 237*256 + 11 = 60898 200 PORT command successful ---> RETR i.sh 150 Connecting to port 60898 226-File successfully transferred 226 0.000 seconds (measured here), 21.22 Mbytes per second ---> QUIT 221-Goodbye. You uploaded 0 and downloaded 2 kbytes. 221 Logout. Dump 2: The same TCP stream traffic as above, seen on the other side of the router. Traffic leaving the router 206.47.37.39 heading to Internet (from ethereal): 220---------- Welcome to Pure-FTPd [TLS] ---------- 220-You are user number 1 of 50 allowed. 220-Local time is now 23:34. Server port: 21. 220-This is a private system - No anonymous login 220-IPv6 connections are also welcome on this server. 220 You will be disconnected after 15 minutes of inactivity. ---> USER idallena 331 User idallena OK. Password required ---> PASS XXXX 230-User idallena has group access to: idallena 230 OK. Current restricted directory is / ---> SYST 215 UNIX Type: L8 ---> PORT 206,47,37,39,181,11 # note new IP addr from the ALG 200 PORT command successful ---> LIST i.sh 150 Connecting to port 46347 226-Options: -a -l 226 1 matches total ---> TYPE I 200 TYPE is now 8-bit binary ---> PORT 206,47,37,39,237,226 # note new IP addr from the ALG 200 PORT command successful ---> RETR i.sh 150 Connecting to port 60898 226-File successfully transferred 226 0.000 seconds (measured here), 21.22 Mbytes per second ---> QUIT 221-Goodbye. You uploaded 0 and downloaded 2 kbytes. 221 Logout. ============================================================================= IP Tunnelling - running IP inside IP ------------------------------------ How do you take an IP packet and "wrap" it inside another IP packet? - note difference between "informational" and "standards track" RFC http://tools.ietf.org/html/rfc1853 (informational) IP in IP Tunneling (Informational only) Oct 1995 "the original unadorned IP Header is retained, and simply wrapped in another standard IP header. http://tools.ietf.org/html/rfc2003 (standards track) IP Encapsulation within IP (Standards track) - Oct 1996 - protocol #4 "The inner IP header is not changed by the encapsulator, except to decrement the TTL as noted below, and remains unchanged during its delivery to the tunnel exit point. No change to IP options in the inner header occurs during delivery of the encapsulated datagram through the tunnel. Q: How does IP-inside-IP work? Give a block diagram of the original and new packets showing the headers and data sections of each. http://tools.ietf.org/html/rfc2004 (standards track) Minimal Encapsulation within IP (Standards track) - Oct 1996 - protocol #55 "This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram, with less overhead than "conventional" IP encapsulation [4] that adds a second IP header to each encapsulated datagram. Q: How does "minimal encapsulation" differ from IP-inside-IP? Give a block diagram of the original and new packets showing the headers and data sections of each for "minimal encapsulation". http://tools.ietf.org/html/rfc4459 (informational) MTU and Fragmentation Issues with In-the-Network Tunneling - Apr 2006 "All these protocols and scenarios have one issue in common: how does the source select the maximum packet size so that the packets will fit, even encapsulated, in the smallest Maximum Transmission Unit (MTU) of the traversed path in the network; and if you cannot affect the packet sizes, what do you do to be able to encapsulate them in any case? "This yields that there is no trivial solution to this problem, and it needs to be further explored to consider the trade offs, as is done in this memo. Q: T/F, what limit often prevents a router from simply adding a second header to an existing IP packet, to implement IP-inside-IP? http://tools.ietf.org/html/draft-heffner-frag-harmful-02 Fragmentation Considered Very Harmful - June 2006; expires Dec 2006 Google Search: "considered harmful" "IPv4 fragmentation is not sufficiently robust for general use in today's Internet. The 16-bit IP identification field is not large enough to prevent frequent incorrectly assembled IP fragments, and the TCP and UDP checksums are insufficient to prevent the resulting corrupted datagrams from being delivered to higher protocol layers. This note describes some easily reproduced experiments demonstrating the problem, and discusses some of the operational implications of these observations. Q: T/F, if an IP-inside-IP packet is too big, it can be fragmented with little performance impact. http://tools.ietf.org/html/draft-ietf-pmtud-method-10 Packetization Layer Path MTU Discovery - Sep 2006; expires Mar 2007 "This document describes a method for Packetization Layer Path MTU Discovery (PLPMTUD) which is an extension to existing Path MTU Discovery methods described in [RFC1191] and [RFC1981]. In the absence of ICMP messages, the proper MTU is determined by starting with small packets and probing with successively larger packets. The bulk of the algorithm is implemented above IP, in the transport layer (e.g., TCP) or other "Packetization Protocol" that is responsible for determining packet boundaries. "This document does not update RFC1191 or RFC1981; however, since it supports correct operation without ICMP, it implicitly relaxes some of the requirements for the algorithms specified in those documents. "The methods described in this document rely on features of existing protocols. They apply to many transport protocols over IPv4 and IPv6. They do not require cooperation from the lower layers (except that they are consistent about which packet sizes are acceptable), or from peers. As the methods apply only to senders, variants in implementations will not cause interoperability problems. Q: T/F, the latest draft of "Packetization Layer Path MTU Discovery" [PLPMTUD] is intended to replace and make obsolete the existing PMTU discovery RFCs (for PMTU that uses ICMP messages). ============================================================================= //EOF - end of notes CST8165 Fall 2006 ============================================================================= http://www.pengalert.com/