From owner-freebsd-arch Wed Jul 18 14:20:13 2001 Delivered-To: freebsd-arch@freebsd.org Received: from InterJet.elischer.org (c421509-a.pinol1.sfba.home.com [24.7.86.9]) by hub.freebsd.org (Postfix) with ESMTP id 1694B37B405 for ; Wed, 18 Jul 2001 14:20:10 -0700 (PDT) (envelope-from julian@elischer.org) Received: from InterJet.elischer.org (InterJet.elischer.org [192.168.1.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id QAA95609; Wed, 18 Jul 2001 16:08:40 -0700 (PDT) Date: Wed, 18 Jul 2001 16:08:38 -0700 (PDT) From: Julian Elischer To: Chris Peterson Cc: freebsd-arch@freebsd.org Subject: Re: TCP Initial Sequence Numbers: We need to talk In-Reply-To: <001101c10fcc$7a7927f0$a586fa18@chris> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG And what if the encoded port number comes out to be teh same as an existing port number to the same destination? Is it guaranteed that there is exactly one cleartext input for each RC5 output? This succests that the clent selects (indirectly) both sequence numbers. A new sequence number may be in the TIMEWAIT window of a recently shutdown session.. The server cannot send any data until it hears from the client with an ACK again? (e.g. cannot send "login:") On Wed, 18 Jul 2001, Chris Peterson wrote: > Steve Gibson has written a paper describing his algorithm (called GENESIS) > to defend against SYN floods. I don't know if he has implemented it or if > his idea is even feasible. His algorithm is so simple, I suspect he must be > overlooking something. > > Basically, he proposes that the server responds to client SYNs with a > SYN/ACK whose ISN is the client SYN's ISN plus the RC5 encrypted client > source IP address. When the server receives an ACK reply, it subtracts the > client's ACK ISN and decrypts the result. If the decrypted value equals the > client's source IP address, then this is a valid ACK. The server postpones > maintaining TCP connection state until after receiving a valid ACK reply to > its SYN/ACK. > > More information about GENESIS: > http://grc.com/r&d/nomoredos2.htm > > > chris > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-arch" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message