Subject: Re: Calculations of ISN for new TCP sessions

From: Vernon Schryver <[email-masked]>
Date: Tue, 19 Sep 2000 13:10:38 -0600 (MDT)

> From: stanislav shalunov <[email-masked]>

> ...
> > 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    [email-masked]

---

From: stanislav shalunov <[email-masked]>
Date: 19 Sep 2000 21:24:11 -0400

Vernon Schryver <[email-masked]> 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.

> 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.

> 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 <[email-masked]>	Internet Engineer, Internet2

A large number of installed systems work by fiat.  That is, they work
by being declared to work.                             -- Anatol Holt