rfc2371.txt

RFC 的详细文档！

   allow.

   Whether TLS is to be used on a connection, and if so, how TLS is to
   be used, and what operations are to subsequently be allowed, is
   determined by the security policies of the connecting TIP transaction
   managers towards each other. How these security policies are defined,
   and how a TIP transaction manager learns of them is totally private
   to the implementation and beyond the scope of this document.

16.2. PULL-Based Denial-of-Service Attack

   Assume that a malicious user knows the identity of a transaction that
   is currently active in some transaction manager. If the malefactor
   opens a TIP connection to the transaction manager, sends a PULL
   command, then closes the connection, he can cause that transaction to
   be aborted. This results in a denial of service to the legitimate
   owner of the transaction.

   An implementation may avoid this attack by refusing PULL commands
   unless TLS is being used, the remote party has been authenticated,
   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.







Lyon, et. al.               Standards Track                    [Page 23]

RFC 2371                    TIP Version 3.0                    July 1998


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.














Lyon, et. al.               Standards Track                    [Page 24]

RFC 2371                    TIP Version 3.0                    July 1998


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)", RFC 1738, December 1994.

   [5]  Evans, K., Klein, J., and J. Lyon, "Transaction Internet
        Protocol - Requirements and Supplemental Information", RFC 2372,
        July 1998.

   [6]  Moats, R., "URN Syntax", RFC 2141, 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.






















Lyon, et. al.               Standards Track                    [Page 25]

RFC 2371                    TIP Version 3.0                    July 1998


18. Authors' Addresses

   Jim Lyon
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052-6399, USA

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Keith Evans
   Tandem Computers, Inc.
   5425 Stevens Creek Blvd
   Santa Clara, CA 95051-7200, USA

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]


   Johannes Klein
   Tandem Computers Inc.
   10555 Ridgeview Court
   Cupertino, CA 95014-0789, USA

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]

19. Comments

   Please send comments on this document to the authors at
   <[e-mail]>, <[e-mail]>,
   <[e-mail]>, or to the TIP mailing list at
   <[e-mail]>. You can subscribe to the TIP mailing list by
   sending  mail to <[e-mail]> with the line "subscribe
   tip <full name>" somewhere in the body of the message.












Lyon, et. al.               Standards Track                    [Page 26]

RFC 2371                    TIP Version 3.0                    July 1998


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.







Lyon, et. al.               Standards Track                    [Page 27]

RFC 2371                    TIP Version 3.0                    July 1998


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

   +-------+-----------+-----------------------------------------+