RE: [tcpm] New I-D posted : draft-moncaster-tcpm-rcv-cheat-00

["Caitlin Bestler" <[e-mail]>]

I am very skeptical that there is a transport layer problem here,
as opposed to an application layer problem.

Basically, I do not accept the following premise:

	A large server relies on honest network congestion feedback to
	efficiently apportion its own resources between receivers. If
	such a large server devotes an excessive fraction of its own
	resources to misbehaving receivers, it may well hit its own
	resource limits and have to starve other half-connections even
	if their network path has spare capacity.

I would rather contend:

	A large server does not rely on network congestion feedback
alone
	to efficiently apportion its own resources between receivers. If
	such a large receiver devotes an excessive fraction of its own
	resources to any receiver (whether misbehaving, malicious or 
	merely greedy) it may well hit its own resource limits and
	have to starve other half-connections even if their network
	path has spare capacity.

A server application that is willing to transmit multi-megabit flows
to an anonymous client based solely on the alleged receive capacity
of the receiver is so gullible it almost qualifies as a "willing
accomplice".

My understanding of this problem assumes the following:

	DoS attacks that seek to cause a server to send very large
streams,
	and thereby cause local congestion at the server end, require
establishing
	actual connections. Therefore the source of the attack is
traceable.
	An attacker is unlikely to use their own machine for a traceable
attack.
	Therefore these attacks would be launched from compromised
machines, from
	a botnet.

	A compromised machine can already be used to "honestly" receive
a stream
	at the compromised machine's capacity rate. The installed
malware can
	simply throw the traffic away with very low CPU overhead. If
clever, it
	can limit the rate to a fraction of the local bandwidth to avoid
arousing
	suspicion of the machine's legitimate owner.

	Therefore the proposed test is intended as a countermeasure
against attackers
	seeking to use optimistic acking to get a multiplier effect. By
committing
	virtually all of the local machines receive bandwidth it can get
the server
	to commit several times that on the server's local network.

	The fake receiver will ack packets that are actually reeived as
though all
	prior packets had been received. An optimal attacker would
probably simulate
	a long NAPI poll cycle of 100 HZ and ack the highest TCP
sequence received
	ignoring all gaps. It would thereby simulate the behavior of an
honest
	receiver that consolidated ACKs on a 100 HZ collection cycle.

An important constraint is that the attacker wants to generate no fewer
acks than
an honest receiver actually receiving the packets would have. The
greatest ACK to
receive ratio that I can think of, this is also legitimate, occurs when
an honest
receiver generates a single ACK for all traffic received in a collection
period.

A receiver that is generating ACKs less frequently than every other sent
packet
or 100HZ AND is claiming that the connection is experiencing no
congestion is
inherently suspicious. Even if it manages to be RFC compliant, the
sender is
under no obligation to continue sending traffic to this client at higher
and
higher rates.

This is especially true since even with the proposed test, an attacker
can 
always recruit compromised attackers to act as a bit bucket drain at
typical
home broadband rates. Since the goal of optimistic acking is to get a
multiplier
effect, the rates in question would be several times higher than typical
home
broadband capacities.

So wouldn't having the application layer merely cap individual flows to
anonymous
clients be just as effective a counter-measure as fiddling with TCP?

And wouldn't it be less harmful?

The proposed test *is* harmful. It artifically increases the amount of
packet
re-ordering in the network. Receivers may already have engineered
resources
to provide resilient responses to re-ordered packets. Artificially
caused
packet reordering as a routine test eats away at those safety margins.
And
the duplicate acks generated ARE excess traffic.

As an *administrative* test done when a flow already appears suspicious
there would be no real problem. But as a routine test to determine when
a flow is suspicious there is an inherent problem. Either the test is
performed too seldom to be effective, or it is performed frequently
enough to have a measurable impact on the performance of at least
some receivers.




_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm