Re: icmp rpf

2006-09-26 Thread Fernando Gont


At 10:06 25/09/2006, Ian Mason wrote:


One of the largest North American network providers filters/drops
ICMP messages so that they only pass those with a source IP
address that appears in their routing table.


This is clearly reasonable as part of an effort to mitigate ICMP
based network abuse.


As a matter of fact, most ICMP-based attacks don't require spoofing 
of the source IP address. You do have to spoof the addresses in the 
"original datagram" included in the ICMP payload, though.


Kindest regards,

--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1







Re: TCP receive window set to 0; DoS or not?

2006-09-26 Thread Fernando Gont


At 21:55 08/09/2006, Jim Shankland wrote:


Travis Hassloch <[EMAIL PROTECTED]> writes:
> The part where it becomes a DoS is when they tie up all the listeners
> on a socket (e.g. apache), and nothing happens for several minutes until
> their connections time out.  Whether intentional or not, it does have
> a negative effect.

Ah, that makes sense.  I was assuming a deliberate attack, which is
not actually implicit in the term "DoS".  A deliberate denial of
service is not made easier by shrinking the window.  But an implementation
that advertises a 0 window in lieu of sending FIN or RST can certainly
deny service inadvertently by tying up resources that should have been
freed.


FYI, this issue was raised at the IETF TCPM WG mailing-list a month 
ago or so. The OP argued to reduce the amount of time for which a 
peer could advertise a 0 window.


However, the problem is that if the goalis to perform a DoS attack, 
the attacker could advertise a 1-byte window (or ay other small 
window). Or he could advertise a 0-window for some time (less than 
the "threshold" the OP proposed), then increase the window to, say, 
one segment, and then go back to advertising a 0 window.


The OP had suggested seeing this behaviour tying up all system 
resources, hence leading to the attacked system to not be able to 
service legitimate systems.


There seemed to be agreement as at the TCPM WG that yu should handle 
these scenarios at the application layer.


Kindest regards,

--
Fernando Gont
e-mail: [EMAIL PROTECTED] || [EMAIL PROTECTED]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1