Transaction Internet Protocol (tip)
Chair(s):
Jim Lyon <
[email protected]>
Keith Evans <
[email protected]>
Applications Area Director(s):
Keith Moore <
[email protected]>
Harald Alvestrand <
[email protected]>
Mailing Lists:
General Discussion:
[email protected]
To Subscribe:
[email protected]
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.
