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]