Echo

Sat Aug 17 21:36:49 UTC 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, <brad.knowles at skynet.be>

"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(+++)