Internet DRAFT - draft-dattathrani-tcp-ip-security
draft-dattathrani-tcp-ip-security
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]
