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: [EMAIL PROTECTED] [mailto:p2p-hackers-
[EMAIL PROTECTED] 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.
-Ekr
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
