[p2p-hackers] IETF rejects Obfuscated TCP
ekr at networkresonance.com
Wed Aug 20 13:31:17 EDT 2008
At Tue, 19 Aug 2008 20:57:33 -0700,
Alex Pankratov wrote:
> CC'ing cryptography mail list as it may be of some interest to the
> folks over there.
> > -----Original Message-----
> > From: p2p-hackers-bounces at lists.zooko.com [mailto:p2p-hackers-
> > bounces at lists.zooko.com] On Behalf Of Lars Eggert
> > Sent: August 19, 2008 5:34 PM
> > To: David Barrett; theory and practice of decentralized computer
> > networks
> > Subject: Re: [p2p-hackers] IETF rejects Obfuscated TCP
> > On 2008-8-19, at 17:20, ext David Barrett wrote:
> > > On Tue, 19 Aug 2008 4:19 pm, Lars Eggert wrote:
> > >> Actually, in 1994, the IETF standardized Transactional TCP (T/TCP)
> > in
> > >> RFC1644, which allows just that. However, there are serious DDoS
> > >> issues with T/TCP which have prevented it seeing significant
> > >> deployment.
> > >
> > > Hm, I'm sorry I don't know the history there -- why is this more
> > > costly
> > > or abusive than SSL over standard TCP? Is it due to something
> > > specific
> > > to SSL, or due to it a simple lack of congestion control on those
> > > first
> > > payloads?
> > The issue is unrelated to a specific kind of SYN payload (SSL or
> > otherwise.) The issue is that a SYN flood of SYNs with data consumes
> > much more memory on the receiver than a regular SYN flood, because the
> > receiver is obligated to cache the data if a T/TCP liveness check
> > fails. You can't use SYN cookies with data SYNs, either.
> This is just a quick thought, but a variation of SYN cookies for TLS
> appears to be quite easy to do. It does require defining new record
> type, but latter is permitted by TLS spec as per Section 6, RFC 2246.
> The idea, obviously, is to include a copy of ClientHello message in a
> second batch of records sent by the client. This should allow server
> to generate ServerKeyExchange parameters from the original ClientHello
> message (ClientHello.random + IP/port quintet + server "cookie secret"),
> then discard ClientHello and delay creating the state .. exactly the
> same way SYN cookies mechanism does it.
May I ask what you're trying to accomplish? Recall that TLS doesn't
start until a TCP connection has been established, so there's
aready a proof of the round trip.
That said, a mechanism of this type has already been described
for DTLS (RFC 4347), so no new invention would be needed.
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography