and the remote party is trusted.
16.3. PUSH-Based Denial-of-Service Attack
When the connection between two transaction managers is closed while
a transaction is in the Prepared state, each transaction manager
needs to remember information about the transaction until a
connection can be re-established.
If a malicious user exploits this fact to repeatedly create
transactions, get them into Prepared state and drop the connection,
he may cause a transaction manager to suffer resource exhaustion,
thus denying service to all legitimate users of that transaction
manager.
An implementation may avoid this attack by refusing PUSH commands
unless TLS is being used, the remote party has been authenticated,
and the remote party is trusted.
16.4. Transaction Corruption Attack
If a subordinate transaction manager has lost its connection for a
particular prepared transaction, a malicious user can initiate a TIP
connection to the transaction manager, and send it a RECONNECT
command followed by either a COMMIT or an ABORT command for the
transaction. The malicious user could thus cause part of a
transaction to be committed when it should have been aborted, or vice
versa.
An implementation may avoid this attack by recording the
authenticated identity of its superior in a transaction, and by
refusing RECONNECT commands unless TLS is being used and the
authenticated identity of the remote party is the same as the
identity of the original superior.
16.5. Packet-Sniffing Attacks
If a malicious user can intercept traffic on a TIP connection, he may
be able to deduce information useful in planning other attacks. For
example, if comment fields include the product name and version
number of a transaction manager, a malicious user might be able to
use this information to determine what security bugs exist in the
implementation.
An implementation may avoid this attack by always using TLS to
provide session encryption, and by not putting any personalizing
information on the TLS/TLSING command/response pair.
16.6. Man-in-the-Middle Attack
If a malicious user can intercept and alter traffic on a TIP
connection, he can wreak havoc in a number of ways. For example, he
could replace a COMMIT command with an ABORT command.
An implementation may avoid this attack by always using TLS to
provide session encryption and authentication of the remote party.
17. References
[1] Gray, J. and A. Reuter (1993), Transaction Processing: Concepts
and Techniques. San Francisco, CA: Morgan Kaufmann Publishers.
(ISBN 1-55860-190-2).
[2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
2068, January 1997.
[3] Dierks, T., et. al., "The TLS Protocol Version 1.0", Work in
Progress.
[4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC1738, December 1994.
[5] Evans, K., Klein, J., and J. Lyon, "Transaction Internet
Protocol - Requirements and Supplemental Information", RFC2372,
July 1998.
[6] Moats, R., "URN Syntax", RFC2141, May 1997.
[7] Faltstrom, P., et. al., "Namespace Identifier Requirements for
URN Services", Work in Progress.
[8] Berners-Lee, T., et. at., "Uniform Resource Identifiers (URI):
Generic Syntax and Semantics", Work in Progress.
[9] Leach, P., and R. Salz, "UUIDs and GUIDs", Work in Progress.
18. Authors' Addresses
Jim Lyon
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399, USA
Phone: +1 (206) 936 0867
Fax: +1 (206) 936 7329
EMail: JimLyon@Microsoft.Com
Keith Evans
Tandem Computers, Inc.
5425 Stevens Creek Blvd
Santa Clara, CA 95051-7200, USA
Phone: +1 (408) 285 5314
Fax: +1 (408) 285 5245
EMail: Keith.Evans@Tandem.Com
Johannes Klein
Tandem Computers Inc.
10555 Ridgeview Court
Cupertino, CA 95014-0789, USA
Phone: +1 (408) 285 0453
Fax: +1 (408) 285 9818
EMail: Johannes.Klein@Tandem.Com
19. Comments
Please send comments on this document to the authors at
<JimLyon@Microsoft.Com>, <Keith.Evans@Tandem.Com>,
<Johannes.Klein@Tandem.Com>, or to the TIP mailing list at
<Tip@Lists.Tandem.Com>. You can subscribe to the TIP mailing list by
sending mail to <Listserv@Lists.Tandem.Com> with the line "subscribe
tip <full name>" somewhere in the body of the message.
Appendix A. The TIP Multiplexing Protocol Version 2.0.
This appendix describes version 2.0 of the TIP Multiplexing Protocol
(TMP). TMP is intended solely for use with the TIP protocol, and
forms part of the TIP protocol specification (although its
implementation is optional). TMP V2.0 is the only multiplexing
protocol supported by TIP V3.0.
Abstract
TMP provides a simple mechanism for creating multiple lightweight
connections over a single TCP connection. Several such lightweight
connections can be active simultaneously. TMP provides a byte
oriented service, but allows message boundaries to be marked.
A.1. Introduction
There are several protocols in widespread use on the Internet which
create a single TCP connection for each transaction. Unfortunately,
because these transactions are short lived, the cost of setting up
and tearing down these TCP connections becomes significant, both in
terms of resources used and in the delays associated with TCP's
congestion control mechanisms.
The TIP Multiplexing Protocol (TMP) is a simple protocol running on
top of TCP that can be used to create multiple lightweight
connections over a single transport connection. TMP therefore
provides for more efficient use of TCP connections. Data from several
different TMP connections can be interleaved, and both message
boundaries and end of stream markers can be provided.
Because TMP runs on top of a reliable byte ordered transport service
it can avoid most of the extra work TCP must go through in order to
ensure reliability. For example, TMP connections do not need to be
confirmed, so there is no need to wait for handshaking to complete
before data can be sent.
Note: TMP is not intended as a generalized multiplexing protocol. If
you are designing a different protocol that needs multiplexing, TMP
may or may not be appropriate. Protocols with large messages can
exceed the buffering capabilities of the receiver, and under certain
conditions this can cause deadlock. TMP when used with TIP does not
suffer from this problem since TIP is a request-response protocol,
and all messages are short.
A.2. Protocol Model
The basic protocol model is that of multiple lightweight connections
operating over a reliable stream of bytes. The party which initiated
the connection is referred to as the primary, and the party which
accepted the connection is referred to as the secondary.
Connections may be unidirectional or bi-directional; each end of a
bi-directional connection may be closed separately. Connections may
be closed normally, or reset to indicate an abortive release.
Aborting a connection closes both data streams.
Once a connection has been opened, applications can send messages
over it, and signal the end of application level messages.
Application messages are encapsulated in TMP packets and transferred
over the byte stream. A single TIP command (TMP application message)
must be wholly contained within a single TMP packet.
A.3. TMP Packet Format
A TMP packet consists of a 64 bit header followed by zero or more
octets of data. The header contains three fields; a flag byte, the
connection identifier, and the packet length. Both integers, the
connection identifier and the packet length must be sent in network
byte order.
FLAGS
+--------+--------+--------+--------+
|SFPR0000| Connection ID |
+--------+--------+--------+--------+
| | Length |
+--------+--------+--------+--------+
A.3.1. Flag Details
+-------+-----------+-----------------------------------------+
| Name | Mask | Description |
+-------+-----------+ ----------------------------------------+
| SYN | 1xxx|0000 | Open a new connection |
| FIN | x1xx|0000 | Close an existing connection |
| PUSH | xx1x|0000 | Mark application level message boundary |
| RESET | xxx1|0000 | Abort the connection |
+-------+-----------+-----------------------------------------+
A.4. Connection Identifiers
Each TMP connection is identified by a 24 bit integer. TMP
connections created by the party which initiated the underlying TCP
connection must have even identifiers; those created by the other
party must have odd identifiers.
A.5. TMP Connection States
TMP connections can exist in several different states; Closed,
OpenWrite, OpenSynRead, OpenSynReset, OpenReadWrite, CloseWrite, and
CloseRead. A connection can change its state in response to receiving
a packet with the SYN, FIN, or RESET bits set, or in response to an
API call by the application. The available API calls are open, close,
and abort.
The meaning of most states is obvious (e.g. OpenWrite means that a
connection has been opened for writing). The meaning of the states
OpenSynRead and OpenResetRead need more explanation.
In the OpenSynRead state a primary opened and immediately closed the
output data stream of a connection, and is now waiting for a SYN
response from the secondary to open the input data stream for
reading.
In the OpenResetRead state a primary opened and immediately aborted a
connection, and is now waiting for a SYN response from the secondary
to finally close the connection.
A.6. Event Priorities and State Transitions
The state table shown below describes the actions and state
transitions that occur in response to a given event. The events
accepted by each state are listed in priority order with highest
priority first. If multiple events are present in a message, those
events matching the list are processed. If multiple events match, the
event with the highest priority is accepted and processed first. Any
remaining events are processed in the resultant successor state.
For example, if a TMP connection at the secondary is in the Closed
state, and the secondary receives a packet containing a SYN event, a
FIN event and an input data event (i.e. DATA-IN), the secondary first
accepts the SYN event (because it is the only match in Closed state).
The secondary accepts the connection, sends a SYN event and enters
the ReadWrite state. The SYN event is removed from the list of
pending events. The remaining events are FIN and DATA-IN. In the
ReadWrite state the secondary reads the input data (i.e. the DATA-IN
event is processed first because it has higher priority than the FIN
event). Once the data has been read and the DATA-IN event has been
removed from the list of pending events, the FIN event is processed
and the secondary enters the CloseWrite state.
If the secondary receives a packet containing a SYN event, and is for
some reason unable to accept the connection (e.g. insufficient
resources), it should reject the request by sending a SYN event
followed by a RESET event. Note that both events can be sent as part
of the same TMP packet.
If either party receives a TMP packet that it does not understand, or
an event in an incorrect state, it closes the TCP connection.
+==============+=========+==========+==============+
| Entry State | Event | Action | Exit State |
+==============+=========+==========+==============+
| Closed | SYN | SYN | ReadWrite |
| | OPEN | SYN | OpenWrite |
+--------------+---------+----------+--------------+
| OpenWrite | SYN | Accept | ReadWrite |
| | WRITE | DATA-OUT | OpenWrite |
| | CLOSE | FIN | OpenSynRead |
| | ABORT | RESET | OpenSynReset |
+--------------+---------+----------+--------------+
| OpenSynRead | SYN | Accept | CloseRead |
+--------------+---------+----------+--------------+
| OpenSynReset | SYN | Accept | Closed |
+--------------+---------+----------+--------------+
| ReadWrite | DATA-IN | Accept | ReadWrite |
| | FIN | Accept | CloseWrite |
| | RESET | Accept | Closed |
| | WRITE | DATA-OUT | ReadWrite |
| | CLOSE | FIN | CloseRead |
| | ABORT | RESET | Closed |
+--------------+---------+----------+--------------+
| CloseWrite | RESET | Accept | Closed |
| | WRITE | DATA-OUT | CloseWrite |
| | CLOSE | FIN | Closed |
| | ABORT | RESET | Closed |
+--------------+---------+----------+--------------+
| CloseRead | DATA-IN | Accept | CloseRead |
| | FIN | Accept | Closed |
| | RESET | Accept | Closed |
| | ABORT | RESET | Closed |
+--------------+---------+----------+--------------+
TMP Event Priorities and State Transitions
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.