NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 27-Oct-97
Chair(s):
Jim Lyon <jimlyon@microsoft.com>
Keith Evans <keith@loc252.tandem.com>
Applications Area Director(s):
Keith Moore <moore@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Applications Area Advisor:
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>
Mailing Lists:
General Discussion:tip@tandem.com
To Subscribe: listserv@tandem.com
In Body: in message body: subscribe tip
Archive:
Description of Working Group:
The task of the TIP working group is to develop an Internet standard two-phase commit protocol specification, to enable heterogeneous Transaction Managers to agree on the outcome of a distributed transaction, based upon the Internet-Draft TIP protocol specification <draft-lyon-itp-nodes-01.txt. [Note that since <draft-lyon-itp-nodes-01.txt references a modified version of the Session Control Protocol (SCP), the TIP WG will also be responsible for progression of SCP to Proposed Internet Standard.]
In many applications where different nodes cooperate on some work, there is a need to guarantee that the work happens atomically. That is, each node must reach the same conclusion as to whether the work is to be completed (committed or aborted), even in the face of failures. This behavior is achieved via the use of distributed transactions, employing a two-phase commit protocol (2-pc). The use of distributed transactions greatly simplifies distributed applications programming, since the number of possible outcomes is reduced from many to two, and failure recovery is performed automatically by the transaction service (Transaction Manager).
Key requirements to be met are, 1) the 2-pc protocol be independent of the application-to-application communications protocol, such that it may be used with any application protocol (especially HTTP), and 2) the 2-pc protocol be simple to implement and have a small working footprint (to encourage ubiquitous implementation and offer wide applicability).
The first work item of the group is to develop a requirements document, which describes at least one complete scenario in which the TIP protocol is intended to be used, and describes the requirements on the protocol with regards to:
- Simplicity - Overhead/Performance - Security
The protocols developed by this working group will be analyzed for potential sources of security breach. Identified threats will be removed from the protocol if possible, and documented and guarded against in other cases.
The Internet-Draft document <draft-lyon-itp-nodes-01.txt is to be used as the input base document for the development of this 2-pc protocol specification.
Due to extreme differences in the approach, the group will not consider the CORBA OTS specification as a solution to its requirements.
Goals and Milestones:
Jul 97 |
|
Submit Versions 2 of the Session Control Protocol (SCP) document as an Internet-Draft. |
Jul 97 |
|
Solicit comments on TIP and SCP Internet-Drafts. |
Aug 97 |
|
Resolve all comments received on TIP and SCP Internet-Drafts, and submit revisions. |
Aug 97 |
|
Meet at Munich IETF. |
Sep 97 |
|
Submit updated versions of TIP, SCP, and Requirements Document as Internet-Drafts. |
Oct 97 |
|
Submit final version of TIP and SCP to IESG for consideration as Proposed Standards. Also submit requirements document for consideration as an Informational RFC. |
Internet-Drafts:
· Transaction Internet Protocol Version 2.0
· Session Control Protocol V 2.0
· Using the Transaction Internet Protocol (TIP) with HTTP
No Request For Comments
Minutes of the Transaction Internet Protocol (TIP) WG
Reported by: Keith Evans
Issues discussed with respect to the current TIP I-D:
I. Security
Harald A. has voiced concerns with the current use of TIP with TLS. To address these concerns, the group discussed a proposed change to the protocol. Instead of the TIPS: URL scheme and the use of different unsecured and TLS secured port numbers for TIP connections, it was decided to add a negotiated security protocol exchange. The exact details will be specified by a revised I-D, but basically a new command will be added, USETLS or somesuch, which is valid in Initial state. This command indicates that the primary requires TIP communication to occur over a TLS secured connection. The secondary either agrees or rejects the request if TLS is unsupported (in which case, it is up to the primary to decide whether any TIP communication can occur). Once agreed, the TLS protocol is used to secure the connection before any further TIP messages are sent (e.g., to authenticate each end-point). In addition, a new response is added to the IDENTIFY command, via which the secondary can request that the connection be TLS secured. The primary would then send a USETLS command and repeat the IDENTIFY. If the primary does not support TLS, then no further TIP communication can occur on the connection. Both parties should record the necessary information such that should recovery be necessary, the connection can be re-established with the same security attributes.
As well as this protocol change, further text will be added to the "Security Considerations" section, enumerating specific threats to TIP, and how those threats are dealt with (which for the most part is by using TLS encryption and mutual authentication). These changes will be made in the next revision of the TIP I-D.
A question was asked whether more than the minimum TLS cypher-suite is required for TIP? The answer is no.
Another comment was that use of TLS be optional. Whether or not TLS is required on a particular connection is determined by some means outside the scope of TIP (configuration information or whatever). Certainly, a party can choose to trust a partner and not use TLS. To support TLS or not is an implementation decision (it is not required). But obviously an implementation that does not support TLS would not be able to be used with a partner that requires TLS. All implementations must support receipt of the USETLS command and response (on IDENTIFY) (there will be a "CANTTLS" response to the USETLS command).
A question was asked regarding how does this security protocol protect against "man in the middle attacks." The answer is via the use of TLS mutual authentication.
II. URI's as end-point identifiers
Currently the TIP protocol specifies IP addresses as the only valid form of end-point identifier. It was suggested that this be extended to allow URI's to be used instead (which can also be used to specify IP addresses). That is, to redefine an end-point as a URI. This would mean changes to the IDENTIFY command and the TIP URL definition.
It was agreed that this would be a useful change. However, the details were not fully worked-out. It is intended that this change go into the next revision of the TIP I-D, but if it proves too disruptive, then it could be deferred until a subsequent version.
III. TMP and Deadlocks
A concern was expressed that the current text regarding the possibility of deadlocks when TMP is used with protocols other than TIP is too weak. The offending paragraph will be rewritten to remove the parentheses, and add text to the effect that TIP does not suffer from deadlocks because it is a request-response protocol.
This change will be made in the next revision of the TIP I-D.
IV. Pipelining
There was a short discussion about whether or not pipelining is useful, and should remain in the TIP I-D. The majority felt it is useful and should stay in - so it shall.
One comment was that the TIP I-D should state explicitly that in the normal case, TIP connections should only be closed by the primary, when in Initial state (and that it is undesirable for a connection to be closed by the secondary in any case). This change will be made in the next revision of the TIP I-D.
This concluded the discussion regarding the current TIP I-D. The objective is to make the described changes and publish a revised version by December 25, 1997. There are no other known issues against the current TIP I-D.
Other subjects discussed:
V. Use of TIP with HTTP <draft-ietf-tip-usehttp-00.txt>
Most of the discussion centered around how a client could get a guarantee that if a request is sent to a server with the new HTTP TIP transaction header, that the server would honor the transaction, or fail the request.
Yaron Goland (the author) described that there is a discovery mechanism, whereby the client can determine whether the server supports TIP transactions or not (via the OPTIONS method on the server resource). If a server receives a request with a transaction header, but does not want to participate in the transaction, then it should fail the request with an error 412. This does not address the problem of a server that does not support transactions and executes the request anyway.
One suggestion to help solve this problem is that a server which understands the TIP transaction header should include the header in its reply. This indicates to the client that the server correctly executed the request in the context of the specified TIP transaction.
Yaron will update the I-D to better explain the discovery mechanism, and the means to obtain deterministic behavior when sending a transactional request to a server (to either confirm that the request was executed in the transaction, or was not executed at all).
A question was raised regarding who appends the TIP transaction header? The answer is the entity that is building the HTTP request (CGI application or whatever).
VI. Use of TIP through firewalls.
Jim Lyon discussed the issue of how TIP connections can be set-up through intervening firewalls.
The majority thought that this was a potentially complex area and subject to change. So it was decided to defer any further activity on this subject until more actual usage experience with TIP has been obtained (to see the types of use, and what problems re firewalls etc. were encountered and how best they might be addressed).
VII. Acknowledged Commit
One of the items deferred for a future version of TIP is the problem whereby a client using BEGIN to delegate transaction coordination to a remote TIP TM, suffers some failure after requesting COMMIT, and hence does not receive notification of the outcome of the transaction (which must then somehow be determined privately).
Johannes Klein proposed a version of PULL, which indicates that the client ("puller") wishes only to be notified of the outcome of the transaction (and does not participate in the PREPARE phase). This notification is acknowledged, and the coordinating TIP TM must remember the transaction outcome until acknowledgement is received (just as for the COMMIT phase). In the event of failure, the client may later ask "what happened" to the transaction.
The group thought this was a good proposal. Johannes will write it up and circulate on the TIP mailing list.
None Received