Network Working Group J. Lindqvist Internet-Draft TKK Expires: January 12, 2007 July 11, 2006 Piggybacking TCP to Host Identity Protocol draft-lindqvist-hip-tcp-piggybacking-00.txt Status of this Memo 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/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 on January 12, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies how to concatenate the TCP handshake to Host Identity Protocol (HIP) base exchange control messages. This extension gives a performance improvement by reducing one round trip for establishing the TCP connection when compared to a normal base exchange. Lindqvist Expires January 12, 2007 [Page 1] Internet-Draft HIP - TCP Piggybacking July 2006 1. Introduction Host Identity Protocol (HIP) architecture [HIPARCH] replaces the identity function of IP addresses. When the Host Identity Protocol (HIP) is used, Host Identities (HI) are used to identify hosts. IP addresses are used only as locators. In practice, a Host Identity (HI) is a public key of a public/private key pair. Because the public keys can be of different sizes, they are most of the time represented in a condensed form; a hash-based digest of a HI is called a Host Identity Tag (HIT). To authenticate peers and create the necessary IP-layer state, HIP defines a key negotiation state setup protocol called the base exchange. The base exchange can be used to establish IPsec ESP Security Associations [HIPESP], for example. In this document, we specify how to gain decrease connection set-up latency by reducing the amount of control messages when initiating a TCP connection with HIP. The motivation for the presented approach is as follows. We send the TCP SYN segment piggybacked to the I2 message. This way, the Responder can check the puzzle from I2 first, and only after that create TCP state. It should be noticed that the initiator does not send TCP SYN already in I1 because TCP ACKs can already contain application data that needs to be encrypted. The approach is designed to work normal and opportunistic base exchange and with the TCP Option initiated opportunistic mode [OPPHIP]. Lindqvist Expires January 12, 2007 [Page 2] Internet-Draft HIP - TCP Piggybacking July 2006 2. Terms and Definitions We assume that the readers are familiar with the terms and definitions given in [HIPBASE], hereafter referred as the HIP base specification. 2.1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2.2. Definitions HIP piggybacking: A HIP control message is followed by a segment from another protocol (e.g. TCP). Lindqvist Expires January 12, 2007 [Page 3] Internet-Draft HIP - TCP Piggybacking July 2006 3. Overview of TCP Piggybacking to HIP This section presents how to piggyback TCP to HIP base exchange. 3.1. Piggybacking TCP to Base Exchange The base exchange including piggybacked TCP is illustrated below. The I1, R1, I2 and R2 defined in the HIP base specification. The TCP segments are defined in [RFC0793]. The packets contain other parameters in the HIP messages not shown in this figure. Initiator Responder I1: trigger exchange --------------------------> select pre-computed R1 R1 <------------------------- check sig remain stateless solve puzzle I2 | TCP SYN --------------------------> check puzzle check sig R2 | TCP SYN+ACK <-------------------------- check sig compute D-H ESP(TCP ACK) --------------------------> ESP(TCP DATA) <-------------------------> Figure 1 The Initiator starts the base exchange as defined in the base specification or as in the Internet-Draft [OPPHIP], either sending a normal I1 or an opportunistic I1. The responder processes the I1 as usual and sends the R1. The Next Header field in I2 has the value protocol number 6 (TCP). Otherwise, the I2 format is the same as defined in the HIP base specification. The I2 is followed by TCP SYN segment. Thus, the packet format is IP((I2), (TCP SYN)). Lindqvist Expires January 12, 2007 [Page 4] Internet-Draft HIP - TCP Piggybacking July 2006 The I2 is processed by the Responder similarly as in the HIP base specification. The exception is the Next Header field. Value 6 indicates that a TCP segment follows and needs to be processed. If the base exchange is initiated by the approach defined in [OPPHIP], the peer just retransmits the TCP SYN segment with I2. The Next Header field in R2 has the value protocol number 6 (TCP). Otherwise, the R2 format is the same as defined in the HIP base specification. The R2 is followed by TCP SYN+ACK segment. Thus, the packet format is IP((I2), (TCP SYN+ACK)). The R2 is processed by the Initiator similarly as in the HIP base specification. The exception is the Next Header field. Value 6 indicates that a TCP segment follows and needs to be processed. After the base exchange, the hosts send data using the ESP transport format. The TCP ACK needed for the TCP handshake is sent with ESP, and thus, the possible data in the TCP is encrypted and integrity protected. Lindqvist Expires January 12, 2007 [Page 5] Internet-Draft HIP - TCP Piggybacking July 2006 4. Open Issues 4.1. Flags Should we have a flag in I1 and R1 to indicate the support for TCP piggybacking? This could simplify the processing of the packets and remove the need for unnecessary retransmits? 4.2. Integrity Protection for TCP segments The current approach does not allow a simple way to add integrity protection for the TCP segments. Is this a real problem? Lindqvist Expires January 12, 2007 [Page 6] Internet-Draft HIP - TCP Piggybacking July 2006 5. Acknowledgments Miika Komu, Teemu Koponen, Pekka Nikander and HIP RG. Lindqvist Expires January 12, 2007 [Page 7] Internet-Draft HIP - TCP Piggybacking July 2006 6. Security Considerations The piggybacking reveals to third parties TCP control data, e.g. what are the used TCP port numbers. This is at least a privacy issue. Lindqvist Expires January 12, 2007 [Page 8] Internet-Draft HIP - TCP Piggybacking July 2006 7. References 7.1. Normative References [HIPBASE] Moskowitz, R., Nikander, P., Jokela (editor), P., and P. Jokela (editor), "Host Identity Protocol", draft-ietf-hip-base-06 (work in progress), June 2006. [OPPHIP] Lindqvist, J., "Host Identity Protocol", draft-lindqvist-hip-opportunistic-01 (work in progress), March 2006. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. Informative References [HIPARCH] Moskowitz, R. and P. Nikander, "Host Identity Protocol Architecture", RFC 4423, May 2006. [HIPESP] Jokela, P., Moskowitz, R., and P. Nikander, "Using ESP transport format with HIP", draft-ietf-hip-esp-03 (work in progress), June 2006. Lindqvist Expires January 12, 2007 [Page 9] Internet-Draft HIP - TCP Piggybacking July 2006 Author's Address Janne Lindqvist Helsinki University of Technology (TKK) P.O. Box 5400 Espoo FIN-02015 TKK Finland Phone: +358 9 451 5851 Email: janne.lindqvist@tkk.fi URI: http://www.tml.tkk.fi/ Lindqvist Expires January 12, 2007 [Page 10] Internet-Draft HIP - TCP Piggybacking July 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Lindqvist Expires January 12, 2007 [Page 11]