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]