[lkml]   [1996]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[RFC Editor: RFC1948 on Sequence Number Attacks]

Steve Bellovin's proposal for defending against TCP connection hijacks
has just been published as an RFC. As an aside, the RFC also discusses
common TCP implementation bug. I assume that we're hopefully proof
against it since we're not descended from the BSD stack, but we've added
enough algorithms from BSD that's worth checking. Alan?

A Common TCP Bug

As mentioned earlier, attackers using sequence number guessing have
to "gag" the trusted machine first. While a number of strategies are
possible, most of the attacks detected thus far rely on an
implementation bug.

When a packet is received, the first thing that must be done is a
search for the TCB for that connection. If no TCB is found, the
kernel searches for a "wild card" TCB used by servers to accept
connections from all clients. Unfortunately, in many kernels this
code is invoked for any incoming packets, not just for initial SYN
packets. If the SYN-RCVD queue is full for the wildcard TCB, any new
packets specifying just that host and port number will be discarded,
even if they aren't SYN packets.

To gag a host, then, the attacker sends a few dozen SYN packets to
the rlogin port from different port numbers on some non-existent
machine. This fills up the SYN-RCVD queue, while the SYN+ACK packets
go off to the bit bucket. The attack on the target machine then
appears to come from the rlogin port on the trusted machine. The
replies -- the SYN+ACKs from the target -- will be perceived as
packets belonging to a full queue, and will be dropped silently.
This could be avoided if the full queue code checked for the ACK bit,
which cannot legally be on for legitimate open requests. If it is
on, RST should be sent in reply.

I'll note that RFC1948's method of protecting against sequence number
attacks requires either the use of a per-host secret (very hard to
administer), OR the use of true random numbers as specified by RFC1750.

- Ted

------- Forwarded Message

To: IETF-Announce:;@IETF.CNRI.Reston.VA.US
Subject: RFC1948 on Sequence Number Attacks
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 17 May 96 10:08:00 PDT
Sender: ietf-announce-request@IETF.CNRI.Reston.VA.US
From: RFC Editor <>


A new Request for Comments is now available in online RFC libraries.

RFC 1948:

Title: Defending Against Sequence Number Attacks
Author: S. Bellovin
Date: May 1996
Pages: 6
Characters: 13,074
Updates/Obsoletes: none


IP spoofing attacks based on sequence number spoofing have become a
serious threat on the Internet (CERT Advisory CA-95:01). While
ubiquitous crypgraphic authentication is the right answer, we propose
a simple modification to TCP implementations that should be a very
substantial block to the current wave of attacks.

This memo provides information for the Internet community. This memo
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@CNRI.RESTON.VA.US. Requests to be
added to or deleted from the RFC-DIST distribution list should

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@ISI.EDU with the message body
help: ways_to_get_rfcs. For example:

To: rfc-info@ISI.EDU
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 admin@DS.INTERNIC.NET. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds
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.

Content-Type: Multipart/Alternative; Boundary="OtherAccess"

Content-Type: Message/External-body;

Content-Type: text/plain
Content-ID: <960517100606.RFC@ISI.EDU>

SEND /rfc/rfc1948.txt

Content-Type: Message/External-body;

Content-Type: text/plain
Content-ID: <960517100606.RFC@ISI.EDU>


------- End Forwarded Message

 \ /
  Last update: 2005-03-22 13:37    [W:0.031 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site