IP Security Protocol Working Group (IPSEC) J.H. Moon INTERNET-DRAFT and H.Y. Yeom Category: Standards track Seoul National University Expires: June 2, 2003 DEC 2, 2002 The Concatenation of IP Packets draft-moon-ipsec-ipconc-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distibute 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire in June, 2003. Abstract This draft defines method to concatenate and separate IP packets to improve throughput in environments configured to use IPsec tunnel mode. Moon, Yeom [Page 1] INTERNET DRAFT December 2002 1. Introduction IP packet concatenation is a method of reducing the number of IP packets. This method will increase the overall communication performance between a pair of IPsec gateways. The number of packets to be processed in gateways is a significant parameter in determining network throughput. IP packet concatenation is useful when IPsec mode is applied to a pair of communicating gateways with tunnel mode. When communicating through an IPsec channel, an IPsec gateway needs some information for packet processing. This information will be transmitted to the CPU or hardware accelerator with every packet, by using the communication channel, PCI bus, memory bus, and so on. IP packet concatenation will reduce the overhead for this communication by reducing the number of IP packets. This method will also reduce the load when copying packets from then Network Interface Card to main memory (usually a socket buffer in kernel memory). This draft defines the IP packet concatenation method (IPConc). 2. Auxiliary Procedure 2.1. IPConc Association (IPCNA) Negotiation To utilize the IPConc protocol, two nodes MUST first establish an IPConc Association (IPCNA) between them. The IPCNA includes the mode of operation. The policy for establishing IPConc is a node-to-node policy where IPConc is applied to every IP packet between the nodes. Two nodes may choose to negotiate IPConc in either or both directions. The IPCNA is established by dynamic negotiations or by manual configuration. The dynamic negotiations SHOULD use the Internet Key Exchange protocol (IKE) [RFC 2409], where IPsec is present. The dynamic negotiations MAY be implemented through a different protocol. 2.1.1 Use of IKE For IPConc in the context of IP Security, IKE provides the necessary mechanisms and guidelines for establishing IPCNA. Using IKE, IPConc can be negotiated as stand-alone or for use in conjunction with other IPsec protocols. An IPConc Association is negotiated by the initiator using a Proposal Payload, which includes one or more Transform Payloads. The Proposal Payload specifies the IP Concatenation Protocol in the protocol ID field and each Transform Payload indicates whether to use IPConc. Moon, Yeom [Page 2] INTERNET DRAFT December 2002 In the Internet IP Security Domain of Interpretation (DOI), IPConc is negotiated as the Protocol ID PROTO_IPCONC. The following attributes are applicable to IPConc proposals: Encapsulation Mode To propose a non-default Encapsulation Mode (such as Tunnel Mode), an IPConc proposal MUST include an Encapsulation Mode attribute. If the Encapsulation Mode is unspecified, the default value of Transport Mode is assumed. 2.1.2. Use of Non-IKE Protocol Dynamic negotiations MAY be implemented through a protocol other than IKE. Such protocols are beyond the scope of this document. 2.1.3. Manual Configuration Nodes may establish IPComp Associations using manual configuration. 2.2. Local Configuration When IPConc is used for processing packets, the IPsec processing SHOULD be done by batching and information for IPConc SHOULD include the locally set period, the threshold, and the transport layer protocol that will be applied by IPConc. 'Period' is the term that defines how often to transmit or receive packets. The system will transmit enqueued packet periodically. The system thus needs a timer source. 'Threshold' determines the maximum size of packet that can be concatenated. IPConc can reduce throughput because this protocol uses some additional memory copies of packets. If the concatenated packets is small enough, the IPConc improves IPsec throughput. If packets are large, IPConc MUST NOT be applied. The threshold SHOULD be set after thorough consideration of system performance and the additional overheads causeb by memory copying. IPConc SHOULD only be applied to specified transport layer protocols. The policy planner SHOULD select the protocols with due consideration of environments and applications. In addition, the implementer of this method MUST consider the characteristics of the transport layer protocols, such as the TCP urgent flag and the TCP NO_DELY option. IPConc MUST NOT influence upper layer protocols other than the IP layer. 2.3. Batching Process To concatenate, a queueing mechanism is needed. The queueing mechanism SHOULD provide some policies to determine whether Moon, Yeom [Page 3] INTERNET DRAFT December 2002 a packet is enqueued or processed immediately. The following describes the procedure for basic queueing and packet processing with consideration of TCP urgent message: 1) If the SA [RFC 2408] is configured to use IPConc, it SHOULD have its own queues for each specified protocol. 2) If a packet is destined for hosts within an IPsec channel, the packet SHOULD be enqueued to the appropriate SA and transport layer protocol of the packet. If a packet MUST be transmitted immediately, such as a TCP packet with its urgent flag set, IPsec will be applied immediately without queueing. 3) Packets are transmitted periodically following the local policy. 4) When packets are transmitted, IPConc SHOULD be applied. 3. Concatenated IP Datagram Header Structure A concatenated IP datagram COULD be encapsulated by a new IP header. This section defines the IP header modifications in IPv4. The following IPv4 header fields are set before transmitting the concatenated IP datagram: Total Length The length of the entire encapsulated IP datagram, including the IP header and concatenated packets. Protocol The Protocol field is set to 109, IPConc Datagram Header Checksum The Internet Header checksum [RFC 0791] of the IP header. 4. Concatenation and Separation Procedure IPConc has two phases: concatenation of outbound IP packets ("concatenation") and separation of inbound packets ("separation"). The IP packets that are delivered to the destination host are identical to the original IP packets. The concatenation of outbound IP packets MUST be applied to packets that have the same destination and the same transport layer protocol. Processing of outbound IP packets MUST be done before any IPsec processing, such as encryption and authentication. In contrast, the separation of inbound IP packets MUST be done after the completion of all IPsec processing, such as authentication and decryption. 4.1. Concatenation Moon, Yeom [Page 4] INTERNET DRAFT December 2002 Concatenation SHOULD be applied to small packets, and their combined size MUST be smaller the the MTU. This method change some small packets into one packet with a large IP payload. Actually, IPConc does not alter packets, but only arranges small packet consecutively. When IPConc is configured in non-encapsulation mode, IPsec MUST NOT use the size stated in the IP header, but the sum of the concatenated packets for encrypting and authenticating. After IPsec processing, the packet will look like one encrypted and authenticated packet with a large IP payload. IPConc MUST be carried out with consideration of the characteristics of application, network environments, and so on. For example, if an application requires IPConc to guarantee FIFO for UDP packet, IPConc MUST enqueue all UDP packets that are passing through the IPsec channel using IPConc and without changing packet order. If another application requires IPConc to reduce the number of packets as much as it, IPConc need not guarantee FIFO but MUST optimize the number of packets. The following is an example of an IPConc procedure to guarantee the order of packets. 1) If there is no packet in queue, go to 5. 2) Fetch one packet from the queue. We call this packet the 'previous packet' in this section. 3) If the size of the previous packet is larger than the threshold, IPsec will proceed to encryption and authentication on the previous packet. Go to 1. 4) If the packet size is not larger than the threshold: a) If there is no packet in the queue, go to 5. b) Fetch one packet from the queue. We call this packet the 'fetched packet' in this section c) If the sum of the two packets is larger than the threshold, IPsec will process the previous packet, the fetched packet becomes the previous packet, and go to 3. d) If the sum of the two packets is not larger than the threshold, the fetched packet will be copied to the tail of the previous IP packet payload, and the fetched packet will be freed. Go to 3. 5) If the previous packet is not empty: a) If the previous packet has been concatenated and IPCNA has been proposed in the Encapsulation Mode, add a new IP header with protocol number 109. IPsec will be processed with the encapulated packet. b) If the previous packet is normal IP packet or IPCNA has not been proposed in the Encapsulation Mode, IPsec will be processed with the packet. 6) Terminate the IPConc procedure for this queue. As described above, the concatenation procedure is very simple. The policy determines which packets are concatenated, and which packets Moon, Yeom [Page 5] INTERNET DRAFT December 2002 MUST NOT be concatenated. After deciding the policy, the actual procedure for concatenation uses only memory copies. Our method reduces the total size and the number of packets that IPsec will process. ----------------- ----------------- | IP | IP | | IP | IP | | hdr | payload | | hdr | payload | ----------------- ----------------- || || \ / IPsec processing \ / IPsec processing \/ \/ -------------------------------- -------------------------------- | new | IPsec | secure | IPsec | | new | IPsec | secure | IPsec | |IPhdr| hdr | payload| tail | |IPhdr| hdr | payload| tail | -------------------------------- -------------------------------- ----------------- ----------------- | IP | IP | | IP | IP | | hdr | payload | | hdr | payload | ----------------- ----------------- || \ / just concatenation \/ --------------------------------- | IP | IP | IP | IP | | hdr | payload | hdr | payload | --------------------------------- || If encapsulation mode, \ / add newer IP header \/ with protocl number 109 ----------------------------------------- | newer | IP | IP | IP | IP | | IP hdr| hdr | payload | hdr | payload | ----------------------------------------- || \ / IPsec processing \/ ---------------------------------------------------- | new | IPsec | secure | IPsec | |IPhdr| hdr | payload | tail | ---------------------------------------------------- 4.2. Separation The separation procedure MUST NOT affect packets that are sent without the concatenation procedure of IPConc. The separation procedure MUST be performed when the size of the packet is larger than the size stated in the IP packet header in Moon, Yeom [Page 6] INTERNET DRAFT December 2002 non-Encapsulation mode. In Encapsulation mode, the separation procedure MUST be done when the protocol number of the IP header is 109. After IPsec processing, such as authentication and decryption, the IPConc receive routine is called. By comparing sizes, IPConc determines whether the packet is concatenated or not. When the packet is concatenate, the following MUST be performed: 1) Remove the IP header that is used encapsulate the concatenated packets (Encapsulation Mode only). 2) Copy the received packet. We call the copy the 'copied packet' in this section. 3) Separate one packet from the head of the received packet where the size of the separated packet is stated in the IP header of the received packet. 4) deliver the separated packet to upper protocol layer. 5) Cut the head of the copied packet by an amount equal to the size stated in the IP header; this packet becomes the received packet. Go to 2. decrypted, authenticated packet | \|/ Is the protocol number of IP packet 109? | no, go to last <---| \|/ yes ---------------------------------------- | IP | IP | IP | IP | | hdr | packet 1 | packet 2 | packet 3 | ... ---------------------------------------- remove IP hdr | \|/ Is the stated size in first IP hdr equal to the packet length?<----- | | yes, go to last <---| | \|/ no | ---------------------------------- | | IP | IP | IP | | | packet 1 | packet 2 | packet 3 | ... | ---------------------------------- | | copy | \|/ | ---------------------------------- ---------------------------------- | | IP | IP | IP | | IP | IP | IP | | | packet 1 | packet 2 | packet 3 | | packet 1 | packet 2 | packet 3 | | ---------------------------------- ---------------------------------- | original copied packet | | | | \|/ \|/ | ------------ ----------------------- | | IP | "last" | IP | IP |------ | packet 1 | | packet 2 | packet 3 | ------------ ----------------------- | concatenated packet \|/ upper protocol stack Moon, Yeom [Page 7] INTERNET DRAFT December 2002 5. Security Consideration Because IPConc is used in the context of IPsec, it is believed to have no effect on the underlying security functionality provided by the IPsec protocol. 6. Reference [RFC 2409] D. Harkins and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC 2408] D. Maughan, M. Schertler, M. Schneider and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [RFC 0791] J. Postel, Editor, "Internet Protocol", STD 5, RFC 791, September 1981. 7. Authors' Address Moon Jung Hwan Distributed Computing Systems Lab., School of Computer Science and Engineering, Seoul National University, Shillim-dong, Kwanak-gu, Seoul, Republic of Korea, 151-742 E-mail: jhmoon@dcslab.snu.ac.kr Yeom Heon Young Distributed Computing Systems Lab., School of Computer Science and Engineering, Seoul National University, Shillim-dong, Kwanak-gu, Seoul, Republic of Korea, 151-742 E-mail: yeom@dcslab.snu.ac.kr