Date: Fri, 23 Mar 2001 12:43:33 -0600 From: Scott Johnson <sjohn@airlinksys.com> To: freebsd-security@freebsd.org Subject: Re: DoS attack - advice needed Message-ID: <20010323124333.A65189@ns2.airlinksys.com> In-Reply-To: <019101c0b311$a2844fd0$0b6cffc8@infolink.com.br>; from apina@infolink.com.br on Thu, Mar 22, 2001 at 05:49:48PM -0300 References: <007101c0b311$0d67db60$2aa8a8c0@melim.com.br> <019101c0b311$a2844fd0$0b6cffc8@infolink.com.br>
index | next in thread | previous in thread | raw e-mail
Quoth Antonio Carlos Pina on Thu, Mar 22, 2001 at 05:49:48PM -0300:
> Source quench is supposed to be needed but is bad (big security risks). You
> should avoid it.
RFC 792 defines ICMP type 4:
The source quench message is a request to the host to
cut back the rate at which it is sending traffic to the internet
destination. The gateway may send a source quench message for
every message that it discards. On receipt of a source quench
message, the source host should cut back the rate at which it is
sending traffic to the specified destination until it no longer
receives source quench messages from the gateway. The source host
can then gradually increase the rate at which it sends traffic to
the destination until it again receives source quench messages.
The gateway or host may send the source quench message when it
approaches its capacity limit rather than waiting until the
capacity is exceeded. This means that the data datagram which
triggered the source quench message may be delivered.
All of which seems to be a good thing, except that source quench messages
can be used for DoS attacks. However, to pull it off you need to send a
message for every TCP stream you wish to disrupt, and each message must
contain the IP header + 64 bits of a real packet in the transmission.
(Well, it doesn't have to be an exact copy, but some values, like src and
dst ports and addresses, and the sequence numbers, must be correct.) Joe
script kiddie probably doesn't have access to enough traffic to use this
effectively or on a large scale. Correct me if I'm wrong, but this seems
low risk. You can just compare the risk to the benefits of congestion
control. At any rate, it wouldn't hurt to let source quench out.
The current Internet Standards for gateways and hosts say:
RFC 1009 (gateway requirements):
All gateways must contain code for sending ICMP Source Quench
messages when they are forced to drop IP datagrams due to
congestion. Although the Source Quench mechanism is known to
be an imperfect means for Internet congestion control, and
research towards more effective means is in progress, Source
Quench is considered to be too valuable to omit from production
gateways.
RFC 1122 (host requirements):
A host MAY send a Source Quench message if it is
approaching, or has reached, the point at which it is forced
to discard incoming datagrams due to a shortage of
reassembly buffers or other resources. See Section 2.2.3 of
[INTRO:2] for suggestions on when to send Source Quench.
If a Source Quench message is received, the IP layer MUST
report it to the transport layer (or ICMP processing). In
general, the transport or application layer SHOULD implement
a mechanism to respond to Source Quench for any protocol
that can send a sequence of datagrams to the same
destination and which can reasonably be expected to maintain
enough state information to make this feasible.
DISCUSSION:
A Source Quench may be generated by the target host or
by some gateway in the path of a datagram. The host
receiving a Source Quench should throttle itself back
for a period of time, then gradually increase the
transmission rate again. The mechanism to respond to
Source Quench may be in the transport layer (for
connection-oriented protocols like TCP) or in the
application layer (for protocols that are built on top
of UDP).
While "in general" the transport layer SHOULD respond to source quench, in
particular TCP and UDP MUST. RFC 1122 again, regarding TCP:
TCP MUST react to a Source Quench by slowing
transmission on the connection. The RECOMMENDED
procedure is for a Source Quench to trigger a "slow
start," as if a retransmission timeout had occurred.
and UDP:
UDP MUST pass to the application layer all ICMP error
messages that it receives from the IP layer. Conceptually
at least, this may be accomplished with an upcall to the
ERROR_REPORT routine (see Section 4.2.4.1).
--
Scott Johnson
System/Network Administrator
Airlink Systems
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010323124333.A65189>