North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Echo

  • From: Brad Knowles
  • Date: Sat Aug 17 18:02:11 2002

At 3:48 AM +0200 2002/08/17, Karsten W. Rohrbach wrote:

 ...ip source address that is, thought it was obvious.
You mean, the IP address of the machine contacting you, or the IP address of the originating machine? If the former, keep in mind that many providers host a large number of customers, and you could deny service to a lot of innocent people. If the latter, then you would be vulnerable to forging.

                                                       a very logical
 algorithm would be ``n source ip adresses per /16 per minute'' which
 would catch at least the badly distributed DDoS attacks and does not
 impose large processing overhead in cycles and memory, i think.
Assuming you're talking about the transmitting relay (which would be difficult to fake), this would be some additional protection.

 i don't think that an echo service would be this popular that it
 needs to process very many messages for the same /16 in a short period
 of time.
Unless someone is trying to DoS your machine. Heck, they could just generate zillions of SYN packets with random source IP addresses, and that could cause you some significant problems.

 it was just a quick idea. but queueing and (rapidly) scheduled weedouts
 of those queues are nothing new, when you guard services with gpg/pgp.
Cron job every minute? Would you use a program to pull down the mailbox with POP3 or IMAP or somesuch, or would you directly access & process the mailbox? Or maybe pre-filter the messages with procmail into seperate mailbox files which could then be further processed by your script?

What do you do if they decide to start sending you a large number of really huge messages? They could potentially fill up your mailbox space on the disk, even in just a single minute.

 other soft capacity limitings can be done if the rate limiting
 described above lets through too much, such as deleting queue entries by
 random when hitting an excessive queue length. when measuring of link
 latency is done with it, the gpg approach might impose problems, since
 you need to rely on the outgoing mail timestamp of the echo relay
 because of variable queue length and gpg processing time.
Yeah, lots of interesting things to think about.


Thanks for an interesting discussion! This is turning out to be very educational.

--
Brad Knowles, <[email protected]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E W+++(--) N+ !w---
O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)