Internet DRAFT - draft-lindqvist-hip-tcp-piggybacking

draft-lindqvist-hip-tcp-piggybacking






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]