- From: Vern Paxson <vern@ee.lbl.gov>
- Date: Wed, 10 Feb 1999 12:43:07 PST
- To: spreitze@parc.xerox.com
- Cc: discuss@apps.ietf.org, ietf-applcore@imc.org
> > > > 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 ..."]
Received on Wednesday, 10 February 1999 15:44:59 UTC