Network Working Group J. Lindqvist Internet-Draft TKK Expires: May 9, 2006 November 5, 2005 Establishing Host Identity Protocol Opportunistic Mode with TCP Option draft-lindqvist-hip-opportunistic-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 May 9, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document specifies an alternative opportunistic mode for the Host Identity Protocol (HIP). The opportunistic mode is initialized by adding a 128 bit Host Identity Tag (HIT) as a TCP option to a TCP SYN packet. The mode introduces a performance improvement by allowing piggybacking of the TCP handshake to the HIP base exchange. Also, the mode allows a TCP connection to be established directly without a timeout delay in the case the peer does not support HIP. Lindqvist Expires May 9, 2006 [Page 1] Internet-Draft Opportunistic HIP November 2005 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. The base exchange specification [HIPBASE] describes how to use HIP when the peer's HIT is known. The HIT can be preconfigured or fetched from DNS [HIPDNS], for example. If the peer's HIT is not available, the base exchange can be initiated in opportunistic mode. The HIP base exchange specification specifies syntax for packets in opportunistic mode. However, the base exchange specification does not describe the handling of exceptional situations, for example, if the peer does not support HIP. In this document, we specify an alternative way for initiating HIP opportunistic mode using a new TCP option. The motivation for the approach is as follows. TCP provides a fallback mechanism: if the peer does not support HIP, a normal TCP handshake is done. Additionally, we can gain a performance improvement since the TCP handshake can be piggybacked to the HIP base exchange. The use of TCP option instead of other alternatives (e.g. IP option) is also motivated by recent research that shows TCP options are widely accepted. Only 0.2 % of servers in the conducted research did not respond to TCP SYN packets with an arbitrary TCP option. [MEDINA] Lindqvist Expires May 9, 2006 [Page 2] Internet-Draft Opportunistic HIP November 2005 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 TCP option: A TCP option which includes the Initiator's HIT sent in TCP SYN segments. HIP piggybacking: A HIP control message is followed by a segment from another protocol (e.g. TCP). Lindqvist Expires May 9, 2006 [Page 3] Internet-Draft Opportunistic HIP November 2005 3. Extensions to TCP and HIP This section presents the format for the new TCP option called the HIP TCP option. We also define a Next Header value used for piggybacking TCP segments to HIP control packets. We give an overview of processing alternatives for the opportunistic mode. 3.1. HIP TCP option Instead of sending an opportunistic HIP I1 packet, an implementation MAY send a TCP SYN segment that includes the following option. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Kind: # | Length = 18 | Host Identity Tag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Host Identity Tag (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Host Identity Tag (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Host Identity Tag (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Host Identity Tag (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Kind: TBD. See Section 7. IANA Considerations. Length = 18. The format of the Host Identity Tag is defined in [HIPBASE]. The HIT is the Initiator's HIT as in a regular I1 SRC HIT field. 3.2. New HIP Next Header Value The HIP implementation MAY support protocol number 6 (TCP) as Next Header value in the HIP control messages such as R1, I2 and R2. 3.3. Opportunistic Mode Processing Alternatives A recipient that implements this specification SHOULD interpret the HIP TCP option defined above as if it had received a corresponding opportunistic I1 packet. In such a case it MAY ignore the TCP SYN segment and reply with an R1. This causes the peer to retransmit the TCP SYN segment once the HIP connection has been established. Lindqvist Expires May 9, 2006 [Page 4] Internet-Draft Opportunistic HIP November 2005 Alternatively, it MAY create a corresponding TCP SYN+ACK segment and piggyback it into the R1. In either case, it SHOULD NOT create any state at the TCP level. The approach used for processing the TCP segments has the same Denial of Service resistance motivation as in the HIP base protocol. We do not want to create unnecessary state to the Responder before verifying with the puzzle that the Initiator is sincere. Next, we outline the packet processing alternatives for the new opportunistic mode. The Initiator sends a TCP SYN with the HIP TCP option but neither of the hosts support HIP piggybacking. The opportunistic base exchange is handled similarly to the normal base exchange defined in the HIP base specification. The Initiator supports HIP piggybacking but the Responder does not. The opportunistic base exchange is handled similarly to the normal base exchange. When the Responder does not piggyback a TCP segment to the R1, it is a signal for the Initiator that the Responder does not support HIP piggybacking. Thus, the opportunistic base exchange is handled similarly to the normal base exchange defined in the HIP base specification. The Initiator does not support HIP piggybacking but the Responder does. The HIP TCP option format does not include information for the Responder does the Initiator support HIP piggybacking. Therefore, the Responder MAY send a piggybacked TCP SYN+ACK, but since the Initiator does not support HIP piggybacking, the Initiator MUST resend the TCP SYN packets after completing the base exchange. This behavior adheres to the requirement of keeping the Responder stateless until the puzzle has been verified. The Initiator and the Responder both support HIP piggybacking. If the Responder sends an R1 piggybacked with TCP SYN+ACK, the Initiator SHOULD reply with an I2 piggybacked with TCP ACK. The R2 MAY be piggybacked with TCP DATA in a way to be defined. Lindqvist Expires May 9, 2006 [Page 5] Internet-Draft Opportunistic HIP November 2005 4. Overview of Opportunistic Base Exchange This section presents the two main alternatives for the new opportunistic base exchange: without and with piggybacking. For now, the without piggybacking alternative is the RECOMMENDED way to implement the new opportunistic mode. 4.1. Opportunistic Base Exchange without Piggybacking The opportunistic base exchange is illustrated below. The R1, I2 and R2 defined in the HIP base specification. TCP SYN is defined in [RFC0793]. The packets contain other parameters in the HIP messages not shown in this figure. Initiator Responder TCP SYN incl. HIT: trigger exchange --------------------------> select pre-computed R1 R1 <------------------------- check sig remain stateless solve puzzle I2 --------------------------> compute D-H check cookie check puzzle check sig R2 <-------------------------- check sig compute D-H Figure 2 The Initiator starts the opportunistic mode by sending a TCP SYN. The TCP SYN segment includes the HIP TCP option defined above. When the Responder processes the TCP SYN packet and notices the HIP TCP option, the Responder SHOULD act as if it had received an opportunistic HIP I1 packet. If the local policy allows, the Responder sends an R1 as defined in the HIP base specification. The Initiator's HIT is taken from the HIP TCP option. If the local policy does not allow opportunistic base exchange, a NOTIFY message with BLOCKED_BY_POLICY parameter SHOULD be sent, as defined in the HIP base specification. The rest of the messages (I2 and R2) are defined and processed according to the HIP base specification. Lindqvist Expires May 9, 2006 [Page 6] Internet-Draft Opportunistic HIP November 2005 After R2, the Initiator MUST retransmit the TCP SYN segment. Next, we describe an alternative packet processing to the above. It includes piggybacking TCP to the R1, I2 and R2 messages. 4.2. Opportunistic Base Exchange with piggybacking TCP The opportunistic base exchange with piggybacking TCP is illustrated below. The R1, I2 and R2 defined in the HIP base specification. TCP SYN, TCP SYN+ACK, TCP ACK and TCP DATA are defined in [RFC0793]. The packets contain other parameters in the HIP messages not shown in this figure. Initiator Responder TCP SYN incl. HIT: trigger exchange --------------------------> select pre-computed R1 R1 | TCP SYN+ACK <------------------------- check sig remain stateless solve puzzle I2 | TCP ACK --------------------------> compute D-H check cookie check puzzle check sig R2 | TCP DATA <-------------------------- check sig compute D-H Figure 3 The Next Header field in R1 has the value protocol number 6 (TCP). Otherwise, the R1 format is the same as defined in the HIP base specification. The Initiator's HIT is taken from the TCP Option. The R1 message is followed by a TCP SYN+ACK segment. Thus, the packet format is IP((R1),(TCP SYN+ACK)) The R1 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. The Initiator MAY ignore the TCP SYN+ACK. If the Initiator ignores the TCP SYN+ACK, the Initiator MUST resend the TCP SYN after sending I2. 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 ACK. Thus, the packet Lindqvist Expires May 9, 2006 [Page 7] Internet-Draft Opportunistic HIP November 2005 format is IP((I2), (TCP ACK)). The I2 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. The TCP ACK could have TCP DATA as payload. Therefore, the TCP ACK MAY need to be encrypted. There are two options for sending the R2: it MAY follow TCP DATA. The format for the TCP DATA (encryption) and signature placements need to be defined. The R2 without following TCP DATA is the same as defined in the HIP base specification. The R2 with following TCP DATA has the Next Header value protocol number 6 (TCP). The rest of the packet format needs to be defined. Other possibilities such as peers sending TCP SYN packets simultaneously are handled as defined in [RFC0793]. A fundamental problem with the piggybacking approach is that the TCP messages starting from TCP ACK may contain data. The data should be encrypted. We could concatenate ESP to I2 and R2, but this approach was removed even from the current base specification. Therefore, the piggybacking approach is NOT RECOMMENDED at the moment. Lindqvist Expires May 9, 2006 [Page 8] Internet-Draft Opportunistic HIP November 2005 5. Acknowledgments Pekka Nikander picked the idea from floating around at the IETF corridors, and handed it over to the present author. Pekka Nikander and Miika Komu have given detailed comments, which have had considerable impact on this document. Lars Eggert provided information on the acceptability of TCP options in today's Internet. Lindqvist Expires May 9, 2006 [Page 9] Internet-Draft Opportunistic HIP November 2005 6. Security Considerations The opportunistic mode is vulnerable to man-in-the-middle attacks, because the Responder's Host Identity is not known before connection initiation. Additionally, the opportunistic mode provides a fallback mechanism to unencrypted TCP. The fallback mechanism can mislead the user to think that the connection is encrypted when it is not. Thus, applications SHOULD notify the user when the fallback mechanism is used. Lindqvist Expires May 9, 2006 [Page 10] Internet-Draft Opportunistic HIP November 2005 7. IANA Considerations Values in the TCP Option Kind Field are assigned following an IESG approval or Standards Action process [RFC2780]. IANA has not assigned an experimental value for TCP Option Kind field. Thus, the use of an experimental value requires IESG Approval [RFC3692]. Lindqvist Expires May 9, 2006 [Page 11] Internet-Draft Opportunistic HIP November 2005 8. References 8.1. Normative References [HIPBASE] Moskowitz, R., Nikander, P., and P. Jokela (editor), "Host Identity Protocol", draft-ietf-hip-base-04 (work in progress), October 2005. [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. [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. 8.2. Informative References [HIPARCH] Moskowitz, R. and P. Nikander, "Host Identity Protocol Architecture", draft-ietf-hip-arch-03 (work in progress), August 2005. [HIPDNS] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) Domain Name System (DNS) Extensions", draft-ietf-hip-dns-03 (work in progress), October 2005. [HIPESP] Moskowitz, R., Nikander, P., and P. Jokela (editor), "Using ESP transport format with HIP", draft-ietf-hip-esp-01 (work in progress), October 2005. [MEDINA] Medina, A., Allman, M., and S. Floyd, "Measuring the Evolution of Transport Protocols in the Internet", ACM SIGCOMM Computer Communication Review Volume 35 Issue 2, April 2005. Lindqvist Expires May 9, 2006 [Page 12] Internet-Draft Opportunistic HIP November 2005 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 May 9, 2006 [Page 13] Internet-Draft Opportunistic HIP November 2005 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 (2005). 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 May 9, 2006 [Page 14]