Hi,
I got idea how to create anti-DDoS framework. I depicted
it here: http://luxik.cdi.cz/~devik/qos/ddos-blackhole.htm
I''d appreciate opinions whether it could work. Please Cc
me in replies.
Thanks,
-------------------------------
Martin Devera aka devik
Linux kernel QoS/HTB maintainer
http://luxik.cdi.cz/~devik/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
For TCP that works. There are, however, UDP applications that are one-way (e.g. streaming video/audio). Many multicast applications are one-way. On Mon, 2003-08-25 at 09:16, devik wrote:> Hi, > > I got idea how to create anti-DDoS framework. I depicted > it here: http://luxik.cdi.cz/~devik/qos/ddos-blackhole.htm > I''d appreciate opinions whether it could work. Please Cc > me in replies. > > Thanks, > ------------------------------- > Martin Devera aka devik > Linux kernel QoS/HTB maintainer > http://luxik.cdi.cz/~devik/ > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/-- Lawrence MacIntyre 865.574.8696 lpz@ornl.gov Oak Ridge National Laboratory High Performance Information Infrastructure Technology Group
I would ignore multicast ane let it go thru as aparently regular dialup and ADSL users have no access to it. Thus I consider it to be more secured by ISPs. Streaming audio/video, is not there some "feedback" channel so that server knows when client is dead ? There should be something like it IMHO. Note that I''d could every packet going to host (ignoring tcp/udp and/or port difference). Also thanks to Gerry to take it so seriously. I''m interested in result - especialy because I got the idea in night while being tortured by gnats ;-) devik On 25 Aug 2003, Lawrence MacIntyre wrote:> For TCP that works. There are, however, UDP applications that are > one-way (e.g. streaming video/audio). Many multicast applications are > one-way. > > On Mon, 2003-08-25 at 09:16, devik wrote: > > Hi, > > > > I got idea how to create anti-DDoS framework. I depicted > > it here: http://luxik.cdi.cz/~devik/qos/ddos-blackhole.htm > > I''d appreciate opinions whether it could work. Please Cc > > me in replies. > > > > Thanks, > > ------------------------------- > > Martin Devera aka devik > > Linux kernel QoS/HTB maintainer > > http://luxik.cdi.cz/~devik/ > > > > _______________________________________________ > > LARTC mailing list / LARTC@mailman.ds9a.nl > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > -- > Lawrence MacIntyre 865.574.8696 lpz@ornl.gov > Oak Ridge National Laboratory > High Performance Information Infrastructure Technology Group >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
If you are using RTP for the session, you may also use RTCP as a back-channel for reception reports. However, this is not required. On Mon, 2003-08-25 at 19:59, devik wrote:> I would ignore multicast ane let it go thru as aparently > regular dialup and ADSL users have no access to it. Thus > I consider it to be more secured by ISPs. > Streaming audio/video, is not there some "feedback" channel > so that server knows when client is dead ? There should be > something like it IMHO. Note that I''d could every packet > going to host (ignoring tcp/udp and/or port difference). > > Also thanks to Gerry to take it so seriously. I''m interested > in result - especialy because I got the idea in night while > being tortured by gnats ;-) > > devik > > On 25 Aug 2003, Lawrence MacIntyre wrote: > > > For TCP that works. There are, however, UDP applications that are > > one-way (e.g. streaming video/audio). Many multicast applications are > > one-way. > > > > On Mon, 2003-08-25 at 09:16, devik wrote: > > > Hi, > > > > > > I got idea how to create anti-DDoS framework. I depicted > > > it here: http://luxik.cdi.cz/~devik/qos/ddos-blackhole.htm > > > I''d appreciate opinions whether it could work. Please Cc > > > me in replies. > > > > > > Thanks, > > > ------------------------------- > > > Martin Devera aka devik > > > Linux kernel QoS/HTB maintainer > > > http://luxik.cdi.cz/~devik/ > > > > > > _______________________________________________ > > > LARTC mailing list / LARTC@mailman.ds9a.nl > > > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > -- > > Lawrence MacIntyre 865.574.8696 lpz@ornl.gov > > Oak Ridge National Laboratory > > High Performance Information Infrastructure Technology Group > >-- Lawrence MacIntyre 865.574.8696 lpz@ornl.gov Oak Ridge National Laboratory High Performance Information Infrastructure Technology Group
Aha. Ok. I just read about RTP and they argue that either RTPC or other session management protocol should be used. I''d guess that any sane protocol would use some kind of liveness reporting from users. If recieving app crashes then the server should recognize it in some reasonable time and stop sending RTP packets, am I right or do I miss something ? thanks, devik On Tue, 26 Aug 2003, Lawrence MacIntyre wrote:> If you are using RTP for the session, you may also use RTCP as a > back-channel for reception reports. However, this is not required. > > On Mon, 2003-08-25 at 19:59, devik wrote: > > I would ignore multicast ane let it go thru as aparently > > regular dialup and ADSL users have no access to it. Thus > > I consider it to be more secured by ISPs. > > Streaming audio/video, is not there some "feedback" channel > > so that server knows when client is dead ? There should be > > something like it IMHO. Note that I''d could every packet > > going to host (ignoring tcp/udp and/or port difference)._______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/