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]