Network Working Group M. S. Dattathrani Internet Draft Expiration Date: August 2003 February 2003 File name: draft-dattathrani-tcp-ip-security-01.txt Measures to prevent security attacks in TCP/IP draft-dattathrani-tcp-ip-security-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract The security problems in the internet are due to inherent problems in the TCP/IP stack. The purpose of this draft is to brief on some of the measures to prevent security attacks in TCP/IP network, by changing some of the ways in which the TCP/IP protocol stack works. The security attacks which are addressed in this draft are: 1) ARP(Address Resolution Protocol) spoofing and MAC address cloning 2) TCP Initial sequence number prediction This version offers backward compatibility with cards that do not support the security features mentioned in this draft. In view of this, changes have been made to section 2.3 and a new section (Section 2.4) has been added. M. S. Dattathrani [Page 1] INTERNET DRAFT draft-dattathrani-tcp-ip-security-01.txt [February 2003] 1. Overview 1.1 Introduction The measures to prevent security attacks in TCP/IP stack must be known to the Internet society. But at the same time, it must not be possible for the intruders to manipulate the features provided by the TCP/IP stack to hack a system. The measures to prevent security attacks in this draft have been derived keeping the above point in view. 1.2 Motivation In the current scenario, security over the Internet is one of the main concerns of the internet community. The Internet has not been exploited fully because of security concerns. Various encryption methods have been found to prevent secuirty attacks. But because of some basic problems in the protocol present in the TCP/IP stack , the various encryption methods have not been completely successful. This document aims at solving some of the basic problems in the protocols of the TCP/IP stack. 2. Methods of preventing Security attacks 2.1 Preventing ARP spoofing and MAC address cloning 2.1.1 Introduction to the ARP protocol in the TCP/IP stack ARP (Address Resolution Protocol) is used to map IP addresses to hardware addresses. A table, usually called the ARP cache, is used to maintain a correlation between each MAC address and its corresponding IP address. ARP provides the protocol rules for making this correlation and providing address resolution in both directions. When a host(Host 1) needs to send a data packet to another host(Host 2), it asks the ARP program to find a MAC address that matches the IP address of the destination host. The ARP program looks in the ARP cache and, if it finds the address, provides it so that the data packet can be sent to the destination. If no entry is found for the IP address, ARP broadcasts a request in an ARP request packet to all the machines on the network. Each machine receiving the ARP request packet, checks if the requested IP address is one of its configured IP addresses. A machine that recognizes the IP address as its own sends an ARP reply packet with its MAC address. ARP (in Host 1) updates the ARP cache for future reference and then sends the data packet to the destination. This is represented in Figure 1. M. S. Dattathrani [Page 2] INTERNET DRAFT draft-dattathrani-tcp-ip-security-01.txt [February 2003] +-------+ ARP request(broadcast) +-------+ | | (Sh-h1,Si-i1,Dh-?,Di-i2) | | |Host 1 |------------------------->|Host 2 | |(i1,h1)| ARP reply |(i2,h2)| | | (Sh-h2,Si-i2,Dh-h1,Di=i1)| | | |<-------------------------| | +-------+ +-------+ Sh - Source Hardware address Si - Source IP address Dh - Destination Hardware address Di - Destination IP address i1 - Host 1's IP address i2 - Host 2's IP address h1 - Host 1's hardware address h2 - Host 2's hardware address Figure. 1 ARP mechanism 2.1.2 Prevalent ARP spoofing mechanisms One might deduce that this addressing scheme could also be spoofed to provide a host with incorrect information "ARP Spoofing" involves constructing forged ARP request and reply packets. By sending forged ARP replies, a target computer could be convinced to send frames destined for computer A to instead go to computer B. There are two variations of ARP spoofing : - Case 1 This is the case where the requested MAC address is filled with an invalid MAC address(i.e, MAC address not available in the network). This would lead to packets being lost. The spoofing mechanism is depicted in Figure 2. +-------+ ARP request(broadcast) +-------+ | | (Sh-h1,Si-i1,Dh-?,Di-i2) | | |Host 1 |------------------------->|Host 2 | |(i1,h1)| ARP reply |(i2,h2)| | | (Sh-h2,Si-x,Dh-h1,Di=i1) | | | |<-------------------------| | +-------+ +-------+ (intruder system) Sh - Source Hardware address Si - Source IP address Dh - Destination Hardware address Di - Destination IP address i1 - Host 1's IP address i2 - Host 2's IP address h1 - Host 1's hardware address h2 - Host 2's hardware address x - MAC address not available in the network Figure. 2 Case 1 of ARP spoofing mechanism M. S. Dattathrani [Page 3] INTERNET DRAFT draft-dattathrani-tcp-ip-security-01.txt [February 2003] - Case 2 This is the case where the MAC address is not forged, but the intruder's system replies for an IP address other than its own with its own MAC address. This would lead to packets destined for the other system comes to this system. This scenario is depicted in Figure 3. Note that the destination address in the ARP request (x) is different from the IP address configured in the intruder system (Host 2). But the intruder system still replies with its MAC address. +-------+ ARP request(broadcast) +-------+ | | (Sh-h1,Si-i1,Dh-?,Di-x) | | |Host 1 |------------------------->|Host 2 | |(i1,h1)| ARP reply |(i2,h2)| | | (Sh-h2,Si-x,Dh-h1,Di=i1) | | | |<-------------------------| | +-------+ +-------+ (intruder system) Sh - Source Hardware address Si - Source IP address Dh - Destination Hardware address Di - Destination IP address i1 - Host 1's IP address i2 - Host 2's IP address h1 - Host 1's hardware address h2 - Host 2's hardware address x - IP address of trusted system (the destination IP address of the data packet) Figure. 3 Case 2 of ARP spoofing mechanism 2.1.3 Recommendations to prevent ARP spoofing The following recommendations will have to be incorporated in the TCP/IP protocol stack, to prevent ARP spoofing : 1. A sublayer in the Data Link layer should be introduced. This will be known as the Security sublayer. The Security sublayer should be placed below the MAC sublayer in the Data Link layer. This Security sublayer should be present physically on the NIC. The security sublayer will have to perform a host of security checks. The implementation of this sublayer will reside in the ROM of the NIC, so that the intruder does not manipulate this sublayer. M. S. Dattathrani [Page 4] INTERNET DRAFT draft-dattathrani-tcp-ip-security-01.txt [February 2003] +------------+ |LLC sublayer| | | |------------| |MAC sublayer| | | |------------| |Security | |sublayer | +------------+ Figure 4 Position of Security sublayer in the Data link layer 2. The Security sublayer needs to check if the source MAC address populated in the ARP & Inverse ARP response, is same as the MAC address burnt on the card. If they are not the same, the ARP / Inverse ARP packet is discarded. 3. The security sublayer needs to check if the source IP address populated in the ARP / Inverse response is same as one of the card's configured IP addresses. This check would be performed a. If the system is not configured as Proxy ARP server. b. If the system is configured as Proxy ARP server and the IP address in the ARP request is one of its configured IP addresses. If the IP address is not same as one of the configured IP addresses, the packet is discarded. This recommendation requires a change to be made in the function signature of the of the functions in ifether.c Points 2 & 3 ensure that the MAC address & IP address as got from the ARP / Inverse ARP response is credible. 4. If the system sending ARP response is configured as Proxy ARP sever,and the IP address in the ARP request packet is other than its own, the IP address check is not done. The IP address check needs to be done by the system receiving the ARP response. The check to be done by the system receiving ARP response requires the following standards to be followed: a. IP address of the Proxy ARP server needs to be configured in all the systems in the subnet. b. A separate frame type will have to be used when the Proxy ARP server sends an ARP response for an IP address other than its own. This frame type is populated by the Security sublayer. M. S. Dattathrani [Page 5] INTERNET DRAFT draft-dattathrani-tcp-ip-security-01.txt [February 2003] If the above two requirements a & b are satisfied, the system receiving the ARP response performs the following checks to establish that the ARP response is from a trusted Proxy Server: a. If the ARP response has the frame type indicating that it is from a Proxy Server & IP address other than its own and if the source IP address in the ARP response belongs to the same subnet as the receiving card, the ARP response is discarded. b. If the ARP response has the frame type indicating that it is from a Proxy Server & IP address other than its own and if the source IP address in the ARP response does not belong to the same subnet as the receiving card, the security sublayer will check for an ARP entry for the source MAC address (in the ARP response). If the MAC address is available in the ARP cache, the security sublayer checks if the IP address for the MAC address is same as the configured Proxy ARP server IP address. If they are the same, the ARP response received from the Proxy ARP server is accepted. If they are not the same or if the MAC address is not available in the ARP cache, an Inverse ARP is done for the source MAC address on the received ARP response. The IP address in the received Inverse ARP response must be the same as the configured Proxy ARP server's IP address. If the IP address is not same, the ARP response received from the Proxy server is discarded. If many (say 5) such spurious packets are received from a particular card, all subsequent packets from the card are discarded. 5. It must not be possible to configure MAC address in the NIC. 6. ARP must be made a stateful protocol. This means that ARP will not accept ARP response without having requested for it. 7. The set of APIs available for the ethernet driver developers would be restricted. The APIs to send and receive packets will not be made available to the the device driver developers. Only calls to the Security sublayer will be available to the developers. To be able to perform the IP address check(point 3 in this section), this call to the Security sublayer needs to have the arpcom structure as input parameter, so that the IP addresses of the interface card are available. M. S. Dattathrani [Page 6] INTERNET DRAFT draft-dattathrani-tcp-ip-security-01.txt [February 2003] 2.3 Preventing TCP sequence number guessing One of the more fascinating security holes was first described by Morris. Briefly, he used TCP sequence number prediction to construct a TCP packet sequence without ever receiving any responses from the server. This allowed him to spoof a trusted host on a local network. The normal TCP connection establishment sequence involves a 3-way handshake. The client selects and transmits an initial sequence number ISN C, the server acknowledges it and sends its own sequence number ISN S, and the client acknowledges that. Following those three messages, data transmission may take place. The exchange may be shown schematically as follows: C -> S:SYN(ISN C) S -> C:SYN(ISN S) , ACK(ISN C + 1) C -> S:ACK(ISN S + 1) C -> S:data and / or S -> C :data That is, for a conversation to take place, C must first hear ISN S, a more or less random number. Suppose, though, that there was a way for an intruder X to predict ISN S. In that case, it could send the following sequence to impersonate trusted host T : X -> S:SYN(ISN X) , SRC = T S -> T:SYN(ISN S) , ACK(ISN X + 1) X -> S:ACK(ISN S + 1) , SRC = T X -> S:ACK(ISN S + 1) , SRC = T , nasty - data Even though the message S -> T does not go to X, X was able to know its contents, and hence could send data. If X were to perform this attack on a connection that allows command execution (i.e., the Berkeley rsh server), malicious commands could be executed. How, then, to predict the random ISN? In Berkeley systems, the initial sequence number variable is incremented by a constant amount once per second, and by half that amount each time a connection is initiated. Thus, if one initiates a legitimate connection and observes the ISN S used, one can calculate, with a high degree of confidence, ISN' S used on the next connection attempt. TCP sequence number prediction can be avoided if the Initial sequence number(ISN) is unpredictable. The ISN is predictable because of the fixed formula. Instead of using pseudo random number generator, true random number generator is preferable. One way of achieving true random number is by using one of the free memory location address. We could choose from the free address available at a random. M. S. Dattathrani [Page 7] INTERNET DRAFT draft-dattathrani-tcp-ip-security-01.txt [February 2003] This way the Initial sequence number becomes highly unpredictable and so will avoid sequence number prediction. The sequence number was made a pseudo random number so that for a connection between two end-points(same source address, source port, destination address, destination port), the sequence number is unique. If some old connection's packet with a sequence number 'x' is still in the network. If suppose the old connection is closed and a new connection is established with the same peer. If suppose the new connection's initial sequence number is 'x-1', the old packet in the network could assumed to be from this connection. To avoid this, the initial sequence number is chosen such that it is greater than the sequence number in any of the previous connection with any peer. This is achieved by maintaining a counter for the initial sequence number. And this counter is incremented by one, once every 4 micro seconds. If the sequence number is purely random, this kind of uniqueness required between two endpoints can be achieved by use of the time-stamp(present in the optional parameters of TCP header). The timestamp can indicate if the packet belongs to the present connection or otherwise. So, the fixed incrementing counter(whose value can be predicted) need not be used. 2.4 Backward compatibility The above measures do not prevent an intruder from using an old system which does not support the above features. To avoid this, the NICs(Network Interface Card) which is compliant with the above security measures will communicate at a transmission speed different from the speed which are used by the NIC cards currently. This way, the old systems which are not security compliant will not be able to communicate with the new cards which are security compliant. This mandates that all cards in the LAN be replaced. This might need a restructuring of network. However, the network can be split into zones, with the secure zone having systems with the NIC implementing this feature. The secure zone would typically have servers and Proxy servers. M. S. Dattathrani [Page 8] INTERNET DRAFT draft-dattathrani-tcp-ip-security-01.txt [February 2003] Some typical network topologies are given below. ---------------------------------------------------------- | +-------+ +-------+ | | | | both using NIC cards |Proxy | | | |Server | implementing this draft |Server | | | | |<------------------------>| | | | | | | | | | | | | | | | +-------+ +-------+ | | Secure zone | | ---------------------------------------------------------- | -------------------------------- | | | +---------+ +---------+ +---------+ |client 1 | |client 2 | |client 3 | +---------+ +---------+ +---------+ Figure 5 Scenario 1 showing the topology using the NIC card implementing this draft --------------------------------------------------------------- | +---------+ +---------+ +---------+ | | | | | | | | | | |Server 1 | |Server 2 | |Server 3 | | | | | | | | | | | | | | | | | | | | | | | | | | | +---------+ +---------+ +---------+ | | | | | | | | All servers in| the lan use | | | ----------------------------------------------------------- | | |NIC implementing| this draft | | | | | | | | +---------+ +---------+ +---------+ | | | | | | | | | | |Server 4 | |Server 5 | |Server 6 | | | | | | | | | | | | | | | | | | | | | | | | | | | +---------+ +---------+ +---------+ | | Secure Zone | --------------------------------------------------------------- Figure 6 Scenario 2 showing the topology using the NIC card implementing this draft 3. Security considerations This document does not raise any security issues by itself. M. S. Dattathrani [Page 9] INTERNET DRAFT draft-dattathrani-tcp-ip-security-01.txt [February 2003] 4. References [Ref 1] Gary R. Wright , W. Richard Stevens.TCP/IP Illustrated, Volume 2. Addison Wesley Publication. [Ref 2] W. Richard Stevens.TCP/IP Illustrated, Volume 1. Addison Wesley Publication. 5. Author's address M. Sai Dattathrani Flat 1F, No.4,First Main Road, KasturbaNagar, Adyar Chennai - 600 020, India, e-mail: saidatta@vsnl.com M. S. Dattathrani [Page 10]