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]