Internet DRAFT - draft-abhi-covert
draft-abhi-covert
Abhishek Singh
SafeNet Infotech Pvt. Ltd.
Normalization in the unused header fields of TCP/IP.
draft-abhi-covert-00.txt
By submitting this Internet-Draft, each author represents
that any applicable patent or other IPR claims of which he
or she is aware have been or will be disclosed, and any of
which he or she becomes aware will be disclosed, in accordance
with Section 6 of BCP 79."
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 unused fields in TCP/IP can be used to establish malicious communication
channel[1][2][3]. This draft presents the fieldsin TCP/IP and ICMP messages and
the values which must be enforced before the packets are streamed to the network
so as to prevent the malicious communication channel.
[page 1]
Table of Content
1.0 Introduction ......................................2.0
2.0 TCP................................................3.0
3.0 IP.................................................3.0
4.0 ICMP...............................................5.0
References ............................................6.0
Authors Address .......................................7.0
Full Copyright Statement ..............................7.0
1.0 Introduction
-----------------
The use of malicious communication channels is becoming an integral part of the
malicious software agents and tools including those employed for remote access tools
and distributed denial of service tools. These malicious software agents use the unused
fields of ICMP and TCP/IP packets to establish malicious communication channels. Since
TCP/IP comprises of 96% of the traffic, this draft proposes enforcing the semantic
consistency or fixed values in the unused header fields.
The normalization MUST be done before the packets are streamed to the network, or
it can be done by the routers, or it can be done at the end host recieving computer
before the incoming packets which are streamed are send to the upper application layer.
Normalization can be done at the Network Layer. The normalization can be done either
by inserting some predefined values in the fields or it can be done by inserting some
random values in these fields.
2.0 TCP Protocol
----------------
The TCP header as discussed in RFC 793[5] provides various idle fields that can
be used for establishing malicious tunneling. Idle fields in TCP header and
its usage for establishing malicious tunneling are explained below.
* Acknowledgement Number: The TCP handshake is a three-step process that computers
go through when negotiating a connection. Simplistically described,
in a normal TCP handshake
[Page 2]
a) Computer A sends a SYN packet
b) Computer B acknowledges the connection attempt and sends back its own SYN packet.
c) Computer A acknowledges Computer B's response.
When the ACK control bit is set, the acknowledgement number field contains the value of
the next sequence number the sender of the segment is expecting to receive. Once a connection
is established this sequence number is always sent. A value for the acknowledgement number field
is not required when the ACK control bit is not set. When the ACK bit is not set, the value of the
acknowledgement field MUST be normalized. It must be set to some predefined value.
* Reserved: Bits tagged as reserved are not being used currently and are kept for the future use.
There are 6 reserved bits. The values in these bits must be normalized and set to some predefined value.
* Urgent Pointer: The urgent pointer field communicates the current value of the urgent pointer as a
positive offset from the sequence number in this segment. The urgent pointer points to the sequence
number of the octet following the urgent data. Under the condition that the URG bit is not set the
urgent pointer field is disregarded. This field is only interpreted in segments with the URG control
bit set. This field provides 16 bits for covert channels. The value of the urgent pointer bit must be
normalized and must be set to predefined value.
3.0 Internet Protocol
---------------------
IP protocol is defined in RFC 791[4]. The next section discusses the fields in the IP packets
which must be normalized to prevent the malicious channel. The normalization MUST be done before
the packets are streamed to the network, or it can be done by the routers, or it can be done at
the end host recieving computer before the incoming packets which are streamed are send to the
upper application. The normalization can be done either by inserting some predefined values in
the fields or it can be done by inserting some random values in these fields.
* Identification: The 16 bit identification field is set to a different value for each IP datagram
and is used for fragmentation and reassembly. The identification field can be used for covert channels
when a packet is not being fragmented, the DF (Do not Fragment) bit is set and the MF (More Fragment)
bit is zero. Hence when the DF bit is set ands the MF bit is zero the value in the identification field
MUST be normalized. It must be set to some random value.
* Flags: The flags field has three bits. The first bit of the flags field is always zero. The other
two fields are the do not fragment (DF) bit and more fragment (MF) bit. An IP packet should not be
fragmented if the DF bit is set. If a router needs to fragment a packet and the DF bit is set, then it
will discard the packet and send an ICMP "fragmentation needed but DF set" (ICMP type 3, code 4)
error message to the sending station. It MUST be ensured that the first bit of the flags field is
always zero and that if the DF bit is set then the MF bit has to be zero.
[Page 4]
* Fragment offset: If an IP packet is a fragment of a datagram that has been fragmented,
the fragment offset indicates the location of the fragment in the final datagram. Packets
that are not getting fragmented have the DF bit set. The fragment, offset field can provide
13 bits for covert channel when the DF bit is set. It must be ensured that the Fragnment offset
bit is normalized and set to some defined value when the DF bit is set.
* IP Options: The options field is 40 bytes in length. These options provide various functionalities.
Examples of IP options include: timestamps, record route, loose source route, and strict source route,
as defined in RFC 791[6]. The format of the IP options varies depending on the option, however if
multiple options are included (more than one option may be included in an IP header), padding must be
used to ensure that option data is padded to end on a 32-bit boundary, and the IP header ends on a
32-bit boundary. The value of padding must be normalized and set to some defined value.
4.0 Internet Control Message Protocol
--------------------------------------
Details about the ICMP messages and its uses are explained in RFC 792[4].
Some of the most commonly used ICMP messages are
* Destination unreachable - This message is generated when there is some
problem delivering packets.
* Time exceeded - This message is sent when the counter in the looping,
or bad congestion.
* Parameter problem - This message is generated when there are illegal header values.
* Source quench - This message is generated for congestion control.
* Redirect - This message is generated to correct routing problems.
* Echo request / echo reply - This message is used for debugging network routing problems,
and discovering topology (used by ping).
* Timestamp, timestamp reply - This message is the same as echo, but with performance
measurement
The detailed header structure of each message is addressed in RFC 792 [4].
[Page 5]
Table 2 shows the fields of ICMP messages which must be normalized to prevent the malicious channel
The normalization MUST be done before the packets are streamed to the network, or it can be done by
the routers, or it can be done at the end host recieving computer before the packets are send to the
upper application layer. The normalization MUST be done either by inserting some predefined
values in the fields mentioned in table 2.0 or it MUST be done by inserting some
random values in these fields.
--------------------------------------------------------------
| * ICMP Message | Field |
--------------------------------------------------------------
|* Destination Unreachable | Bit 32 - 64 |
--------------------------------------------------------------
|* Time Exceeded Message | Bit 32 - 64 |
--------------------------------------------------------------
|* Parameter Problem Message | Bit 40 - 64 |
--------------------------------------------------------------
|* Source Quench Message | Bit 32 - 64 |
--------------------------------------------------------------
|* Echo_request/ Echo _reply | Bit 64 - End of data field |
---------------------------------------------------------------
Table 2.0 ICMP messages and the idle fields.
5. References
------------
[1] Stateless Model for the prevention of Malicious Tunnels ,
International Journal of Computer and Applications, Volume 28, Number 3, 2006. ACTA Press
[2] Using consistency checks to prevent Malicious Tunnels , Communication, Networks and
Information Security (CNIS 2003). December 10 - 12, 2003 , New York, USA.
[3] Malacious ICMP Tunneling : Defense Against the Vulnerability , (ACISP'03) The Eight
Australasian Conference on Information Security and Privacy , July 9th - 11th 2003, Australia.
[Page 6]
[4] Internet Control Message, RFC 792, "http://www.faqs.org/rfcs/rfc792.html", J Postel, September 1981.
[5] Transmission Control Protocol, RFC 793, "http://www.faqs.org/rfcs/rfc793.html", september 1981.
[6] Internet Protocol, RFC 791, "http://www.faqs.org/rfcs/rfc791.html",September 1981.
Author's Address
----------------
Abhishek Singh
SafeNet InfoTech Pvt. Ltd.
Logix TechnoPark
5th & 6th Floor, Plot No.5
Sector - 127
Taj Express Way
Noida - 201301. U.P.
Email: asingh3@in.safenet-inc.com
abhicc285@gmail.com
Phone : 9899835649
Copyright (C) The IETF Trust (2008)
-------------------------------------
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights."
"This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
[page 7]
