Copyright 1995, 1996 David F. Mischler See the file README.1ST for license information IPRoute PC-based Router V0.94 IPRoute is a software package that routes Internet Protocol (IP) packets between network interfaces on PC hardware. It requires a 286 or better CPU. It is intended to be useful for connecting a LAN to an Internet Service Provider, or for routing between LANs. It provides the following features: * Multiple ethernet interfaces. * SLIP, CSLIP and asynchronous PPP serial links. * Demand-dial and answer scripting. * IP packet filtering. * Network Address Translation (NAT). * Packet and event logging to a syslog daemon. * Routing Information Protocol (RIP). * Multiple transmit queue management strategies. * Administrative preference on routes. * IP tunnelling over ESP using DES-CBC (for US citizens and permanent residents only; not exportable at this time). THIS SOFTWARE IS PROVIDED "AS-IS". THE AUTHOR IS NOT RESPONSIBLE FOR ANY DAMAGES CAUSED BY THE USE OR MISUSE OF THE SOFTWARE, EVEN IF INFORMED OF THE POSSIBILITY OF THESE DAMAGES IN WRITING. THE AUTHOR MAKES NO COMMITMENT REGARDING THE USABILITY OF THE SOFTWARE OR ITS FITNESS FOR A PARTICULAR PURPOSE. SUPPORTED INTERFACES An ethernet interface may be configured by attaching to a packet driver loaded before IPRoute was started with the "packet" command. There is no hard-coded limit on the number of packet drivers allowed, but I have never tested more than two. Packet drivers from the Crynwr Packet Driver Release 11 or later are recommended. At present, only class 1 (ethernet) packet drivers are supported. Only ethernet packet headers are supported (i.e. IEEE 802.3 headers are not supported). Asynchronous serial ports using the standard PC UARTS (i.e. 8250/16450/16550) are supported. These interfaces may be configured with the "async", "slip", "ppp" and "command" commands. The 16550 FIFOs are used to provide far better performance than with the other UARTS. MODEM CONFIGURATION IPRoute can be configured to work with almost any modem, but certain modem settings are expected. Unfortunately, modem configuration commands are not standard enough for me to tell you exactly what commands are needed to configure your modem. IPRoute will generally work best when your modem is set for 8-bit data with no parity and hardware flow control. The data terminal ready (DTR) and carrier detect (CD) control signals should work as "normal" (i.e. a DTR transition from on to off will hang up the phone line, and CD will be on if and only if there is a connection to a remote modem). You may set your modem to return extended result codes if you wish to receive more information on each connection. COMMAND ENTRY All router commands must be entered in lower case. There are several special purpose characters. The backspace or delete characters will erase the last character typed, and the Ctrl-U character will erase the entire line. The enter key must be typed before a command will be executed. When a question mark is entered as a command component the command syntax or options available for the partial command will be displayed (try "route ?" for an example). SCRIPTING IPRoute is normally provided a script file at startup. The script file contains commands to be executed in a particular order under specified conditions. It is possible to specify packet, modem control signal, and timing events. A script processing task is normally run at startup, and additional script processors may be started for each asynchronous interface. This makes it possible for different interfaces to execute scripted commands independently. When a script command requires a string it should be enclosed in double quotes. The backslash character may be used as an escape for various control characters. In particular, \r is used to represent a carriage return, \n represents a line feed, \" represents an embedded double quote, and \\ represents a backslash. It is possible to define symbols for use in scripts with the "define" and "read" commands. The symbols must be preceded by a dollar sign to be expanded. Dollar signs in quoted strings must be preceded by a backslash unless symbol substitution is desired. Whenever a script process transfers control due to an enabled "on" event, all "on" events are disabled. The command reference includes many details about scripting. PACKET FILTERING Packet filtering can be a useful security tool. It is imperative that the network administrator understand how filtering improves security, and that it be used wisely. Most experts on packet filtering recommend that you only allow the packets through your filters that are required to provide the services you need, and drop all others. The best introduction to packet filtering that I know of is Brent Chapman's "Network (In)Security Through IP Packet Filtering", available in PostScript by anonymous FTP from ftp.GreatCircle.COM. The directory path has changed a few times, but the file is still called pkt_filtering.ps.Z. A filtered interface has two separate lists of filtering rules: one for inbound packets, and one for outbound packets. As packets enter or leave the router on a filtered interface they are checked against each filter rule in the order the rules were specified until a match occurs, or the end of the filter list is reached. When a match occurs the actions specified in the filter rule are performed on that packet. Packets that do not match any filter rules will be silently dropped if a filter list exists on the interface for the packet's direction. IP fragments, except for the initial fragment, are not completely filtered because they do not contain port numbers. It is possible for some data to "leak" or be tunnelled past the filter. In general, this is not a serious problem because normal TCP/IP implementations will drop the data if the initial fragments are not received. If you are concerned about packet sniffing or deliberate fragment tunneling then I recommend that you couple NAT with filtering because NAT drops IP fragments whose datagram IDs do not match recently forwarded initial fragments. Please note that a determined user of your internal network might still find a way to tunnel past your filtering scheme. I can not think of any way to make this absolutely impossible. The present implementation drops any initial or only fragment that is too short to contain all of its protocol headers (including the TCP, UDP, or ICMP header), and TCP packets with an IP fragment offset of 1. This prevents certain types of attempts to bypass filtering. Filtering has some performance impact. This impact can be minimized by constructing your filter lists so that, on average, the fewest possible filter rules are checked for each packet. For example, placing a rule that matches all TCP packets that are not connection open attempts (i.e. filter protocol "tcp-xsyn") at the start of the list should improve things a lot. NETWORK ADDRESS TRANSLATION Network Address Translation (NAT) allows a network with non-global addresses to connect to the Internet. This is done by assigning one or more globally valid addresses to the external interface of the router and specifying how addresses and port numbers are to be translated. NAT can be a good security tool for situations where a (potentially) large number of external services are desired by the internal users, but only a few services should be provided to the outside world. In particular, NAT can solve the problem of handling inbound FTP data connections without making all high-numbered TCP ports vulnerable from the outside. This problem has plagued most packet filtering schemes. Two separate tables are maintained for each interface running NAT. One table, the NAT configuration list, is entered as part of the router configuration. It provides a set of rules for setting up new NAT connections. It is always scanned in the order in which the rules were given. The other table is constructed dynamically by the router with one entry for each active translated connection. When a packet representing a new connection comes in on a translated interface it is compared to each entry in the NAT configuration list. A protocol of "*" will match any incoming protocol, but the internal and external IP addresses must be specified. The port numbers must be provided unless neither is given (this indicates that the same port numbers should be used internally as externally). These rules provide enough flexibility for an external address and port to be translated to an internal address and port, or for an external address to be translated to an internal address without port translation. Note that if port numbers are not specified then no service filtering can be performed by NAT. The rules are somewhat different for outgoing connections. When a packet representing a new connection goes out on a translated interface it is compared to each entry in the NAT configuration list. A protocol of "*" will match any outgoing protocol, and an internal address of "*" will match any internal address. Neither port number is usually specified, but it is sometimes necessary to set the external port number to be assigned for use with an internal port number (e.g. outgoing FTP data connections so that the remote system will see the connection originate from port 20 rather than a "random" port). It is also legal (but maybe a little weird) to use "*" for both the internal and external IP addresses, in which case neither the addresses nor port numbers will be translated, but the connection establishment and tracking rules will be enforced. It should be noted that packets that enter the router on a translated interface will have only their destination address and port number translated. Packets that leave the router on a translated interface will have only their source address and port number translated. It is possible to perform "double-blind" translation by enabling NAT on two interfaces, but it is not possible to connect two networks with the same address using this technique. An interface that runs NAT must always have an IP address that is valid on the external network to which it is connected. This is because ICMP error messages may be generated and sent out this interface using the interface's assigned address. If an interface has both filtering and NAT enabled then filtering is always performed first, then translation, except in a few cases where ICMP error messages or TCP resets are generated on the "wrong side" of NAT. This has implications on exactly what can be filtered, logged, and translated. The present implementation drops any initial or only fragment that is too short to contain all of its protocol headers (including the TCP, UDP, or ICMP header), and TCP packets with an IP fragment offset of 1. This prevents certain types of attempts to fool NAT. When NAT is used with PPP with dynamic IP addresses and the NAT external address must correspond to the IP address negotiated by PPP the PPP option "dynamic-nat" should be used. This causes the external IP address of each NAT list entry to be set to the negotiated IP address, all packets with the wrong IP source address to be dropped from the outgoing interface queue, and all dynamic NAT table entries with the wrong external IP address to be deleted. Note that if you are using a dynamically addressed PPP link to route to a fixed IP network then this option must not be used. WHO NEEDS NAT? Several users have told me that IPRoute doesn't work for them unless they enable NAT. Invariably, this is either because they are using unregistered IP addresses, or their Internet Service Provider is not correctly routing packets to their sites for the IP addresses in use. In either case, ordinary routing will not work so NAT is required. PORT NUMBERS, SERVICES, AND PROTOCOLS This information is provided as reference material to assist network administrators. Various network services are discussed with regard to protocol and port numbers. Most of this information comes from the "Assigned Numbers" RFC, which at the time of this writing was RFC 1700. DNS is implemented as both a TCP and UDP service to port 53 on the destination machine. Zone transfers and lists are performed using TCP, so many security experts recommend that machines other than your authoritative secondary DNS servers should be prevented from connecting to TCP port 53 (this could be a job for packet filtering), unless you are controlling zone transfers and listings by some other technique. Client to server communication is generally from arbitrary client ports greater than 1023, but server to server communication generally uses UDP port 53 for both the source and destination. FINGER is implemented as a TCP service to port 79 on the destination machine. In practice, the TCP port on the client machine is 1024 or greater, although this is not a protocol requirement. FTP is the most complicated service in common use. It uses a TCP service to port 21 on the destination machine to provide a control channel, and connects back from the server's TCP port 20 to a port specified by the client machine to provide the data channel. This means that FTP control streams must be monitored by NAT to allow the data connections to succeed. Some servers incorrectly use a source port other than 20. If you need to operate with a server that is broken in this manner then tell NAT about it with the "set nat ftp-data-any on" command. There is also a less common technique ("PASV" mode) that allows the client to connect outward to the server for data connections. If you need to allow incoming passive FTP then you should tell NAT with the "set nat ftp-pasv on" command. HTTP (web service) is implemented as a TCP service to port 80 on the destination machine. The client machine's port is almost always 1024 or greater. NNTP is implemented as a TCP (or UDP?) service to port 119 on the destination machine. In practice, the TCP port on the client machine is 1024 or greater, although this is not a protocol requirement. NTP is implemented as a UDP (or TCP?) service to port 123 on the destination machine. Some client functions use arbitrary ports greater than 1023, but server to server UDP communication uses port 123 on both ends. PING is normally implemented to send ICMP echo requests and receive ICMP echo replies. SMTP (mail) is implemented as a TCP service to port 25 on the destination machine. In practice, the TCP port on the machine sending the mail is 1024 or greater, although this is not a protocol requirement. TELNET is implemented as a TCP service to port 23 on the destination machine. In practice, the TCP port on the client machine is 1024 or greater, although this is not a protocol requirement. TRACEROUTE sends UDP datagrams to the target machine at arbitrary port numbers (usually above 32768), and with the IP TTL field initially set to 1 and increasing for each hop. The destination port number is changed for each hop as well. Each IP router decrements the TTL, and the router that decrements it to 0 sends back an ICMP Time Exceeded (type 11), TTL Exceeded (code 0) message. The target machine should send back an ICMP Destination Unreachable (type 3), Port Unreachable (code 3). Microsoft's TRACERT send ICMP echo requests with a varying time to live rather than UDP messages. LOGGING Events can be logged to a file or a UDP server. Filter entries, as well as various flags, control what is logged. See the "set log" commands for more information. RIP The present RIP implementation is based mostly on RFC 1058. Split horizon is always enabled. RIP requests are not generated or responded to, and no triggered updates are sent. Routes learned by RIP are poisoned for approximately 2 minutes when lost. An administrative preference value may be assigned to routes learned on each interface. See the "rip" command description for more info. TRANSMIT QUEUING All transmit queues are limited. This means that packets will be dropped if the limit is exceeded. In addition, all transmit queues are aged every few seconds if packets are not being transmitted on the interface. During queue aging, the time each packet was queued for output is examined, and any packet whose remaining IP time-to-live (TTL) is less than the time that it has been on the queue is dropped. The TTL of packets that are not dropped is not affected by this process. This behavior is intended to prevent router constipation caused by an interface that fails, or whose modem dropped, etc. If transmit queuing is set to "fifo" then packets are always sent in the order they were queued. In addition, if packets must be dropped due to queue limiting then the first packet on the queue will be dropped. This queuing strategy is especially good for fast interfaces, like ethernet, where the computational overhead of priority queuing would hurt performance, and provide little or no benefit. The optimal tradeoff between link speed and queuing strategy is dependent on the hardware and network characteristics. If transmit queuing is set to "priority" then packets are sent in priority order. The present algorithm uses the IP precedence and type of service to determine a send priority and a save priority. Precedence has a greater effect on these priorities than the type of service. Packets are sent in the order of highest send priority first, and are dropped in the order of lowest save priority first. This queuing strategy is especially good for low-speed SLIP lines, where interactive users will benefit from the improved response time, and high reliability services will benefit from fewer packet drops under congested conditions. Perhaps the biggest weakness of this strategy is that there are still some TCP/IP implementations that do not set the type of service as required by RFC 1122. If transmit queuing is set to "fair" then packets are sent in priority order, but the priority of any packet directly preceded by a newer packet is increased by one. This has the effect of providing better response time than FIFO queuing, but fairer service distribution than strict priority queuing. This queuing strategy is most useful when FIFO queuing provides decent throughput but inadequate response, and priority queuing provides OK response but lousy throughput. It is also less subject to abuse than strict priority routing (e.g. smart users might start doing high-priority file transfers). It has, however, a slightly higher computational overhead than the priority queuing strategy. By default, all async lines use priority queuing, and all ethernet interfaces use FIFO queuing. ADMINISTRATIVE PREFERENCE Each routing table entry includes an administrative preference value. Lower preference values indicate that a route should be preferred over another route with a higher preference value. This can be used to control backup routes, etc. By default, the preference value for all routes is 1. This may be overridden when a static route is created, or by interface for RIP. ENCRYPTED IP TUNNELLING An encrypted IP tunnel can be created with the US-only version of IPRoute using the "tunnel" and "esp" commands. Under current US regulations these functions cannot be exported or provided to persons that are not citizens or permanent residents of the United States. An encrypted security payload (ESP) tunnel allows secure operation of a virtual private network over insecure networks, including the Internet. At the present time only DES-CBC with manual key distribution is supported. Due to the short (56 bit effective) key this encryption technology is not suitable for protecting military secrets or information worth millions of dollars. The security is sufficient, however, to make spoofing very difficult. An ESP tunnel is created by routing packets to the destination network(s) through a tunnel driver, and specifying encryption and decryption keys. Each key has an associated security parameters index (SPI). Outgoing TCP/IP packets routed through the tunnel driver will be encrypted and encapsulated in an ESP/IP packet. Incoming ESP packets will be matched by source IP address and SPI so that the appropriate key can be used to decrypt the encapsulated packet so it may be forwarded. Only true point to point tunnels are supported. Users should be aware that ESP tunnelling has a negative effect on throughput because the resulting packets are larger than the original packets, and are not compressible using any common compression algorithms. COMMAND REFERENCE Warning: all router commands must be in lower case. async [