[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                        Arifumi Matsumoto
INTERNET DRAFT                                           Masahiro Kozuka
                                                          Kenji Fujikawa
                                                             Yasuo Okabe
                                                        Kyoto University
                                                              7 Oct 2003


                         TCP Multi-Home Options

                     <draft-arifumi-tcp-mh-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 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.


Abstract

   In the existing TCP, only one local and one remote address is used
   through a TCP session, even when a client or a server is located
   under multi-homed site and has multiple IP addresses.  When a network
   outage occurs and the access-line associated with the local and
   remote addresses is down, the TCP session itself gets lost even if
   another access-line is alive.  TCP MH option makes it possible to
   handle multiple local and remote address pairs in one TCP session and
   to survive network outages by finding out an alternative network
   path.  Our path transition mechanism is simple, fast, lightweight and
   as secure as existing TCP.





Arifumi                   Expires 7 April 2004                  [Page 1]


draft-arifumi-tcp-mh-00.txt                                   7 Oct 2003


1. Introduction

   Multihoming nodes that connected to the global network through
   multiple up-stream access-lines are expected to have multiple
   addresses given by each ISP. The existing TCP, however, is not
   designed to manipulate multiple addresses in one TCP session.  When a
   network outage occurs and the access-line associated with the local
   and remote addresses is down, the TCP session itself gets lost.

      These new TCP options specified in this document enable a
      host to get benefit from multi-home in a end-to-end
      multi-homing[E2E] manner.
      By introducing these simple options, TCP
      becomes much more reliable and powerful without loss of security
   and
      without dependency on IPsec.
      In this model, both end
      nodes exchange their addresses using these options.  TCP manages
      all possible network ''paths'', which means a quartet of local and
      remote IP addresses and ports, and switches from one to another
      rapidly when a path becomes unavailable. A session can even switch
      from IPv4 address to IPv6 address and vice versa.

      These processes resemble SCTP's[SCTP] multi-homing method.
      And in fact, this paper is based on and resembles SCTP's new
      multi-homing method[ADDIP].
      In this paper we try to prove that TCP can be improved
      and can support multi-homing relatively easily.
      This kind of multi-home solution can be rapidly deployed
      and we believe our solution is of great advantage.


2. MH-Permitted Option

   This two-byte option may be sent in a SYN by extended TCP that can
   recognize (and presumably process) the MH options once the connection
   is opened. It MUST NOT be sent on non-SYN segments.

     MH-Permitted Option:
     Kind: 22
     0                   1
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Kind = 0x16   | Length = 2    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






Arifumi                   Expires 7 April 2004                  [Page 2]


draft-arifumi-tcp-mh-00.txt                                   7 Oct 2003


3. Address Configuration Options (MH-Add/Delete)

   The MH-Add and MH-Delete options are to be used to convey local
   address information from the sender to the receiver over an
   established TCP connection. These options MUST be acknowledged by MH-
   Ack or MH-Non-Ack as described in the next section.

   MH-Serial : 16 bits (unsigned integer)

   This value represents a Serial Number for MH-Add and MH-Delete
   options. The valid range of Serial Number is from 0 to 65535 (2**16
   -1).  Serial Number wrap back to 0 after reaching 65535.

     MH-Add-IPv4 Option:
     Kind: 23
     Length: 8
     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 = 0x17   | Length = 8    |           MH-Serial           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       IPv4 Address                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     MH-Delete-IPv4 Option:
     Kind: 24
     Length: 8
     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 = 0x18   | Length = 8    |           MH-Serial           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       IPv4 Address                            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     MH-Add-IPv6 Option:
     Kind: 25
     Length: 20
     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 = 0x19   | Length = 20   |           MH-Serial           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                       IPv6 Address                            |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



Arifumi                   Expires 7 April 2004                  [Page 3]


draft-arifumi-tcp-mh-00.txt                                   7 Oct 2003


     MH-Delete-IPv6 Option:
     Kind: 26
     Length: 20
     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 = 0x1a   | Length = 20   |           MH-Serial           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    |                       IPv6 Address                            |
    |                                                               |
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


4. Address Configuration Acknowledgment Options(MH-Ack/Non-Ack)

   These options are used by the receiver of MH-Add or MH-Delete Option
   to acknowledge or reject the address presented by the remote peer.

   MH-Serial : 16 bits (unsigned integer)

   This value represents a Serial Number for the received MH-Add
    or MH-Delete option that is acknowledged or rejected.  This value is
   copied from the received MH-Add or MH-Delete option.

     MH-Ack Option:
     Kind: 27
     Length: 4
     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 = 0x1b   | Length = 4    |           MH-Serial           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     MH-Non-Ack Option:
     Kind: 28
     Length: 4
     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 = 0x1c   | Length = 4    |           MH-Serial           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+








Arifumi                   Expires 7 April 2004                  [Page 4]


draft-arifumi-tcp-mh-00.txt                                   7 Oct 2003


5. Procedure

   This section will lay out specific procedures for generating and
   processing of these options defined in Section from 2 to 4.


5.1 MH-Permitted Option Procedures

   When an endpoint is able to handle MH options it should do the
   following:

   1) Create an MH-Permitted option as defined in Section 2 and include
     it in the sending SYN packet.

   2) When the incoming SYN packet doesn't contain MH-Permitted option,
     MUST NOT include MH-Permitted option in the sending SYN packet.

   3) MUST NOT include MH-Permitted option other than SYN packet.

   4) The local and remote addresses used to successfully exchange MH-
     Permitted option should be shortly registered as a valid path and
     thereafter the local address should not be notified to the peer.
     Both endpoints should label the path as the primary one and send
     packets through the path as far as path switching is not activated
     (see section 6 for details).


5.2 Address Configuration Option Procedures

   When an endpoint successfully exchanges MH-Permitted option in the
   connection establishing state and the connection is established, it
   should do the following:

   1) Lookup local addresses and create an MH-Add-IPv4 or MH-Add-IPv6
     option defined in Section 3. Here SHOULD NOT include IPv6 link-
     local address in this option.

   2) A serial number should be assigned to the option.  It should be a
     monotonically increasing number.  It SHOULD be initialized at the
     start of the connection to the value ISS modulo 0xffff, stored as
     ''local serial number'' and every time a new MH-Add or MH-Delete
     option is created it is incremented by one after assigning the
     serial number to the newly created option.

   3) If no MH-Add nor MH-Delete option is outstanding (un-acknowledged)
     with the remote peer, prepare the option to be piggybacked within
     the next sending packet.  If there is no data and outgoing packet,
     MH option should not be sent in the no data packet.  Two or more



Arifumi                   Expires 7 April 2004                  [Page 5]


draft-arifumi-tcp-mh-00.txt                                   7 Oct 2003


     address configuration options SHOULD NOT be sent in one packet.

   4) In the case of MH-Add option, the sender MUST NOT register or use
     the local address or associate the address with the existing TCP
     session until the acknowledgment(MH-Ack) to the option is received.
     The same is true for MH-Delete option, and the sender MUST NOT un-
     register the local address before the arrival acknowledgement
     option.

   5) If the RTO timer expires, the endpoint should retransmit the same
     outstanding MH option last sent.


5.2.1 Congestion Control of Address Configuration Options

   One and only one MH-Add or MH-Delete option MAY be in transit and
   unacknowledged at any time.  If a sender, after sending an MH option,
   decides it needs to transfer another MH option, it MUST wait until
   the appropriate MH-Ack/Non-Ack option returns before sending a
   subsequent MH option.  Note this restriction binds each side, so at
   any time two MH option may be in-transit on any given connection (one
   sent from each endpoint).


5.3 Upon reception of an Address Configuration Option

   When an endpoint receives an MH option from the remote peer,

   1) Compare the value of the serial number to the value the endpoint
     stored as the ''peer serial number''. This value MUST be
     initialized to the ISS modulo 0xffff at the establishment state.

   2) If the value found in the serial number is equal to the (peer
     serial number + 1), the endpoint MUST process the MH option and
     perform the following action.

     2-1) For MH-Add options, register all the paths those can be
       created using the address included in the option.  For MH-Delete
       options un-register all the paths using the specified address.

     2-2) However, the endpoint MUST NOT un-register paths too soon so
       that it can receive a packet through deleting paths for a certain
       amount of time, at least for 2 or 3 times RTT, for security
       reasons.  (This is discussed a bit more in security
       considerations section).

     2-3) Soon after the reception and process of the option the
       endpoint SHOULD build a response MH-Ack message with the serial



Arifumi                   Expires 7 April 2004                  [Page 6]


draft-arifumi-tcp-mh-00.txt                                   7 Oct 2003


       number contained in the received MH option so that the message
       can be piggybacked in the next outgoing packet.  If the address
       family specified in a option is not supported by the endpoint or
       the address in a MH-Delete option has not notified before, the
       endpoint SHOULD build a MH-Nack option.

     2-4) Update the peer serial number to the value found in the serial
       number field.

   3) If the value found in the serial number is equal to the value
     stored in the peer serial number, the endpoint should build the
     same response option last sent and should not update the peer
     serial number.

   4) If the value found in the serial number is not equal to these
     values, send RST segment to the remote peer and MUST ABORT the
     connection shortly for security reasons.


5.4 Upon reception of acknowledgement Option

   When an endpoint receives an MH-Ack or MH-Nack option from the peer,

   1) Compare the value of the serial number to that of the stored
     outstanding address configuration option last sent.

   2) If there is a stored outstanding address configuration option and
     the serial number is equal to that of the stored option, the
     endpoint perform the following.

     2-1) If the incoming option is MH-Ack for MH-Add option last sent,
       register all the paths that can be created using the local
       address specified in the outstanding option.  In the same way, if
       the incoming option is MH-Ack for MH-Delete option last sent un-
       register all the paths using that address.

     2-2) If the incoming option is MH-Nack, do nothing and should not
       repeat sending the same option at least until the peer processes
       some other address configuration options correctly.

     2-3) Update the ''local serial number'' to the value found in the
       serial number field + 1.

   3) If there is no outstanding data and the serial number is equal to
     the (local serial number - 1), just discard the option.

   4) In other case, send RST segment to the remote peer and MUST ABORT
     the connection shortly for security reasons.



Arifumi                   Expires 7 April 2004                  [Page 7]


draft-arifumi-tcp-mh-00.txt                                   7 Oct 2003


6 Path Transition (Setting of the primary path)

6.1 In connection establishment state

   A TCP client endpoint should do the following to establish a session
   if the socket is not bound to a certain address other than
   INADDR_ANY.

   1) In the case of active open, TCP layer is told to connect to one
     remote address specified by the upper layer, which is usually the
     user land.  Here, one local address, corresponding to the given
     remote address, is chosen by source address selection mechanism and
     a SYN packet are sent through that path.

   2) If the SYN packet is retransmitted several times and not
     acknowledged, the endpoint should switch the source address to
     another one if available.  As stated above, IPv6 link-local address
     should not be used here.  IPv6 link-local address can only be
     selected in the 1) state.

   3) The endpoint should not stop connecting until all the existing
     paths failed.

   4) When a connection is established label the path used for
     connection establishment as a primary one and afterward should send
     packets through that path.  The endpoint should not notify the
     address that is used for successful connection establishment to the
     peer.


6.2 After the connection is established

   In order to make the both endpoint use the same path and to survive a
   network outage, the endpoint do the followings:

   1) When a sending data retransmits several times,

     1-1) The endpoint should choose another registered and available
       path.  and label the path as ''temporary path''.  Use the
       temporary path if exists to send a packet.

     1-2) Switch the temporary path to another one if data
       retransmission repeats several times.  Continue changing the
       temporary path as far as an acknowledgement packet doesn't arrive
       and session is not aborted by a timer.

   2) Or when a packet is received through not a primary path, label the
     path as a temporary path and send a packet through the temporary



Arifumi                   Expires 7 April 2004                  [Page 8]


draft-arifumi-tcp-mh-00.txt                                   7 Oct 2003


     path.  Use the temporary path if exists to send a packet.

   3) If a ICMP error, such as host un-reach, is received through not a
     primary path, the endpoint should not shutdown TCP session itself
     but just try to use another path.  In the same way, when the
     endpoint received TCP RST segment through an unused path, the
     endpoint should try to use another one.  When a RST segment comes
     from a used path, through which a packet is successfully received
     at least one, the endpoint should regarded it as a message from the
     valid remote peer and should abort TCP session.

   4) If a packet arrives at the existing temporary path, label the path
     as the primary one.


7. Security Considerations

   This kind of Add/Delete of IP address option seemingly introduces an
   additional mechanism to hijack existing TCP connection.  But some
   measures are taken in this specification so as not make TCP more
   vulnerable than ever.

   As for man in the middle attack, existing TCP protocol is known to be
   vulnerable and this is not improved nor degraded in this
   specification except that the connection can be taken to another
   place in the network.

   As for an attack by wiretapping host, which is often the case when
   shared media like wireless LAN is used, an endpoint can not easily be
   connected to a faked host.  This is owing to delayed MH-Delete
   execution (2-2 in section 5.3) , stringent serial number management
   and address configuration only through legitimate path.


8. References

   [E2E]     M. Ohta, ``The Architecture of End to End Multihoming,''
   Internet-draft, IETF (Nov 2002),
       draft-ohta-e2e-multihoming-03.txt.

   [RFC2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H.
   Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson,
   ``Stream Control Transmission Protocol,`` RFC2960, IETF (Oct 2000).

   [ADDIP]
      R. Stewart, at el, ``Stream Control Transmission Protocol (SCTP)
   Dynamic Address Reconfiguration,'' Internet-draft, IETF (Feb 2003),
   draft-ietf-tsvwg-addip-sctp-07.txt. (Work In Progress)



Arifumi                   Expires 7 April 2004                  [Page 9]


draft-arifumi-tcp-mh-00.txt                                   7 Oct 2003


9. Authors' Addresses

      Arifumi Matsumoto
      Graduate School of Informatics
      Kyoto University
      Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN
      Tel: +81 75-753-7468
      Fax: +81 75-753-7472
      Email: arifumi@net.ist.i.kyoto-u.ac.jp

      Masahiro Kozuka
      Faculty of Law, Kyoto University
      Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN
      Tel: +81 75-753-7468
      Fax: +81 75-753-7472
      Email: ma-kun@kozuka.jp

      Kenji Fujikawa
      Graduate School of Informatics
      Kyoto University
      Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN
      Tel: +81 75-753-5387
      Fax: +81 75-753-4961
      Email: fujikawa@real-internet.org

      Yasuo Okabe
      Academic Center for Computing and Media Studies
      Kyoto University
      Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN
      Tel: +81 75-753-7458
      Fax: +81 75-751-0482
      Email: okabe@i.kyoto-u.ac.jp



















Arifumi                   Expires 7 April 2004                 [Page 10]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/