Although Mike isn't a principal to speak for T/TCP, he's a very
bright guy. Vern disagreed, but they both have to come to agreement
since HTTP-NG is slated to be in Vern's directorate... Then Keith,
from Apps directorate weighed in that any one-shot process has risks,
and they can be addressed in upper layers.
Brian Carpenter, from IESG, reaffirmed that the "politically correct"
answer is to wholly retrofit a session layer (referring to the
Requirements for Unicast Transport/Sessions BOF from Orlando).
Looks like fun for IETF Minneapolis :-)
> From: spreitze@parc.xerox.com
> MMDF-Warning: Parse error in original version of preceding line at
> paris.ics.uci.edu
> Date: Tue, 9 Feb 1999 09:46:47 PST
> Sender: Mike Spreitzer <spreitze@parc.xerox.com>
> Subject: Re: APPLCORE: An architectural question
> To: Graham Klyne <GK@dial.pipex.com>
> Cc: discuss@apps.ietf.org, ietf-applcore@imc.org
> List-Unsubscribe: <mailto:discuss-request@apps.ietf.org?Subject=unsubscribe>
>
>
>> PS: is T/TCP alive or dead these days?
> AFAIK, it is rather dead, due to problems inherent in the 1/2 RT
> startup. There is a comment on this in the minutes of the RUTS BOF
> at IETF-43
> (http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-142.html).
To: spreitze@parc.xerox.com
Cc: discuss@apps.ietf.org, ietf-applcore@imc.org
Subject: Re: APPLCORE: An architectural question
Date: Wed, 10 Feb 1999 12:43:07 PST
From: Vern Paxson <vern@ee.lbl.gov>
List-Unsubscribe: <mailto:discuss-request@apps.ietf.org?Subject=unsubscribe>
> > > > PS: is T/TCP alive or dead these days?
> > >
> > > AFAIK, it is rather dead, due to problems inherent in the 1/2 RT
> > > startup. There is a comment on this in the minutes of the RUTS BOF ...
> >
> > Which comment in the minutes are you referring to?
>
> In the minutes in the proceedings, under "Other (unattributed comments)",
> item 3 identifies a dilemma that T/TCP faces and points to a discussion
> in the next full paragraph.
That comment isn't specific to T/TCP. Any single-round-trip transaction
protocol faces that problem.
Vern
> Other (unattributed comments):
> ...
> (3) Dilemma: eliminating the three-way handshake to make for faster
> transactions reduces security [see below].
> ...
>
> Steve Bellovin then discussed some security implications of the requirements.
> First, removing the three-way handshake opens up security holes. The issue
> of sequence number guessing attacks is serious. IPSEC is reasonably cheap
> for 'over the wire' security, but a key question is where do you get the
> IPSEC keys? Unfortunately, multiple RTTs are needed to connect with a
> key manager, and one needs loosely-synchronized clocks (to address replay
> attacks). Other public key management systems will be similarly expensive.
> The best you can hope for is to cache key management state. But this
> doesn't work if you talk to a lot of other entities over a short time.
>
> However, it might be that object security is in fact cheaper than transport
> security (though you still need to watch for replays).
[there's a bug in the minutes above - it should be "*or* one needs loosely-
synchronized clocks ..."]
X-URI: http://www.cs.utk.edu/~moore/
From: Keith Moore <moore@cs.utk.edu>
To: spreitze@parc.xerox.com
cc: Vern Paxson <vern@ee.lbl.gov>, discuss@apps.ietf.org,
ietf-applcore@imc.org
Subject: Re: APPLCORE: An architectural question
Date: Wed, 10 Feb 1999 16:09:49 -0500
Sender: moore@cs.utk.edu
List-Unsubscribe: <mailto:discuss-request@apps.ietf.org?Subject=unsubscribe>
first, the relevant portion of those notes (about removing the 3WHS,
not specifically about T/TCP)
> First, removing the three-way handshake opens up security holes. The
> issue of sequence number guessing attacks is serious. IPSEC is
> reasonably cheap for 'over the wire' security, but a key question is
> where do you get the IPSEC keys? Unfortunately, multiple RTTs are
> needed to connect with a key manager, and one needs
> loosely-synchronized clocks (to address replay attacks). Other public
> key management systems will be similarly expensive. The best you can
> hope for is to cache key management state. But this doesn't work if
> you talk to a lot of other entities over a short time.
>
> However, it might be that object security is in fact cheaper than
> transport security (though you still need to watch for replays).
okay, first when we say "opens up security holes", we need to ask
"compared to what?" Seems like the important point is that a
connection that lacks a 3WHS may be more vulnerable to some kinds of
hijacking attacks than a traditional TCP connection. I'm by no means
an expert on security and my brain hurts too much today to analyze
this in detail. But I wonder how much this really hurts us.
For example, in the case of a very short "connection" of one request
and one response packet each, I don't immediately understand the
difference between a connection hijacking attack, and a simple
impersonation of the client or server host. The danger of using T/TCP
relative to using TCP, it seems, is that we will use some sort of
authentication mechanism which doesn't guarantee integrity for the
whole session, allowing someone else to steal the connection and
impersonate the authenticated party. But you cannot "hijack" a
connection when the server sends a FIN in response to the first SYN,
and for longer connections it's not difficult to define ways to
prevent connection hijacking - i.e. to make sure you're still talking
to the same host as when you started the connection.
So I don't think we should consider T/TCP "dead"; but we might need to
tweak it (not unusual for an experimental protocol), or ensure that
other kinds of protection (such as object security) are provided by
any "applcore" protocol that we define. But we knew we had to do that
anyway, didn't we?
Keith
(real authentication of your peer is of course still very difficult to
do, especially without adding steps. but we don't always need real
authentication, and in the cases we do, perhaps we can find a way to
piggyback that authentication along with payload - as long as we don't
trust the payload to be authentic until the authenticaiton is
complete.)
Date: Wed, 10 Feb 1999 11:10:59 +0000
From: Brian E Carpenter <brian@hursley.ibm.com>
Organization: IBM Internet Division
To: Graham Klyne <GK@dial.pipex.com>
CC: discuss@apps.ietf.org, ietf-applcore@imc.org
Subject: Re: APPLCORE: An architectural question
List-Unsubscribe: <mailto:discuss-request@apps.ietf.org?Subject=unsubscribe>
Graham Klyne wrote:
...
> (A) The approach taken by IMAP/AP is to build the concurrency into the
> basic request/response protocol, including identifying tags as part of the
> data stream.
Those who actually listened to the IETF plenary talk on transaction
processing at the Chicago IETF will realise that this is a very
non-trivial mechanism to get right. (BTW, XP doesn't even come
close to dealing with the requirements of a transactional
application.) However, it is a valid approach to build a generic
transactional layer, but then we are talking XA, Java RMI, or CORBA
IIOP, which takes us into another league and it is not obvious
that the IETF has anything to bring to the table.
>
> (B) The aproach taken by HTTP-NG is to have a separate multiplexing layer
> that allows a number of virtual duplex stream communications to be
> conducted on a single underlying connection. Thus, each concurrent
> request/response is conducted in a separate data stream.
That's where RUTS comes in: don't do an HTTP-specific solution,
and build on the T/TCP experience. As others have said, this
approach separates the problems and provides a better chance
of satisfying transactional requirements in a simple manner.
Brian Carpenter