Transaction Internet Protocol (tip) 

Chair(s):

Jim Lyon <jimlyon@microsoft.com>
Keith Evans <evans_keith@tandem.com>

Applications Area Director(s): 

Keith Moore <moore+iesg@cs.utk.edu>
Harald Alvestrand <Harald.T.Alvestrand@uninett.no>

Mailing Lists: 

General Discussion: tip@tandem.com 
To Subscribe: listserv@tandem.com 
In 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 .

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
behaviour is achieved via the use of distributed
transactions, employing a two-phase commit protocol (2pc).
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 TIP Internet-Draft document 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 Version 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.
- Transaction Internet Protocol - Requirements.
- Session Control Protocol.
- Using the Transaction Internet Protocol with HTTP.

Current Meeting Report

Minutes of the Transaction Internet Protocol Working Group  

Reported by: Keith Evans

Issues discussed with respect to the current TIP I-D:

1. 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 re how does this security protocol 
protect against "man in the middle attacks". The answer is 
via the use of TLS mutual authentication.

2. 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). i.e. 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.

3. TMP and deadlocks.

A concern was expressed that the current text re 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.

4. 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 re 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:

5. 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 was sent to a server 
with the new HTTP TIP transaction header, that the server 
would honour 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 which 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 behaviour 
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 re who appends the TIP transaction 
header? The answer is the entity that is building the HTTP 
request (CGI application or whatever).

6. 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).

7. 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.