Subject: RE: [Ieprep] ieprep-requirements-01 - reqs 6-10 - discussion request

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Tue, 5 Nov 2002 15:32:26 -0600

> > Though, we have
> > methods to prevent DoS attacks on TCP/routing
> > sessions and Routing table,
> 
> Please cite reference or explain.  I don't think we
> can prevent all DoS attacks on TCP/routing sessions
> and the routing tables.
  I should have been more clear. 
 One can trace the source of the DoS attack by means
of many identification methods like ICMP 
traceback, Hash-base IP traceback, tight samplers 
across passive measurement collectors, IDS systems 
like Bro. Then, we can use packet filtering (sometimes 
distributed)/rate-limiting to nullify them. Other
than major vendors, many companies like arbor 
networks, packetdesign and asta networks has 
targeted products relating to DoS identification.
  The security loop holes in some operating systems 
is another major source. So, we can take precautionary 
measures by adding the respective patches (though, 
prevention is still difficult.) The important point 
here is, OS developers should follow robust coding
schemes to avoid security vulnerability. Sand boxing
(giving restricted access to resources) and use of 
safe languages (which allows taint mode) for coding 
is also another prevention method.
  what i could not understand is:  Though,Govt 
organizations, ICANN ,many open bodies, and Nanog 
(which has a mimimum of one discussion relating 
to DoS every month) discuss and work on 
DoS/DDoS, we still could not find a solution 
to this problem.

 There are many solutions from research labs too.
But, I am not aware of the deployment details. 

1. ratul, sally floyd & steve bellovin's work on
RED-PD, ACC and pushback schemes. The pushback 
scheme has a linux implementation too.

2. John Heidemann's mitigation scheme by means of
connection admission control.

3. Kihong Park and Heejo Lee DPF scheme.

4. Passive packet based sampling measurement 
 schemes ( UCSD Varghese et all and ATT duffield 
et all)

 I can  get into the above methods, but will
not be germane to the present discussion. Of the 
above, 1,3 and 4 are easier to deploy. RED or RED-PD
just need some little code modification at per-router
level. Operators generally employ flow/pkt passive
measurement tools like Netflow/sflo and so, it will
be easy to deploy 4 with some tight sampling methods. 

> >   Compared to DDoS, flash crowd is a legitimate
> > request. On days like 9/11, it is very important to
> > distinguish flash crowds and DDoS traffic.
> > though, it is hard to distinguish flash crowds/DDoS
> > traffic as both are of aggregate traffic type.
> 
> If someone has a method to distinguish an unexpected
> crowd from DDOS that is proven to work, I'd be surprised
> but would be happy to hear about it.
Paul barford and Dave planks has worked on this aspect
and have some results. They have used measurement based
approach by using flowscan.

http://www.icir.org/vern/imw-2001/imw2001-papers/47.pdf
( Look at fig 4 and 5)
http://www.icir.org/vern/imw-2002/imw2002-papers/173.pdf
( a follow-up work but using wavelets)

We can go into these too, but will be more relevant if 
this is a IMRG/nanog discussion.

>       On Tue, 5 Nov 2002, RJ Atkinson wrote:
>     > There is one misapprehension above.  Traffic graphs from
>     > 9/11/01 indicate that there was NOT a significant surge
>     > in IP traffic.  There was a modest surge, but much less
>     > than is regularly seen for non-calamity events (e.g.
>     > much less than for the Mars lander).

I accept. Fred Baker has actually pointed me to cowie's presentaion
which showed the robustness of BGP system on 9/11.
http://www.netsys.com/library/papers/renesys-030502-NRC-911.pdf

> 
> Correct.  There was a significant increase in traffic to the 
> CNN web site,
> and a few other news sites, but it was insignificant relative to the
> Internet generally.

yes again. http://www.tcsa.org/lisa2001/cnn.txt
Even with all their akamisation, anycast and CDN, CNN couldnot
withstand on 9/11.

> >  So, the requirement doc should clearly mention
> > the need for differentiating DDoS and flash crowd
> > problem.
> 
> I don't want to have any requirements that can't be met
> (with currently visible technology).  I think this is
> just that.  If you think that it can be met, please explain how.

All in the research stage - RED-PD, application level Network 
clustering based methods. 

But, if you ask about their deployment..sorry, I don't know. I have
not heard of even Diffserv/ RED deployment except for some RED 
deployment details from sean doran.

Atleast, the requirement doc should mention that "emergency traffic
should be distinguised from DDoS/flashcrowd traffic at the access"
One can do this by giving lower priority to flash crowd pkts 
thereby leaving way for emergency traffic. This can be done by 
configuring VPN or using RED/ECN 
or
https://www1.ietf.org/mail-archive/working-groups/ieprep/current/msg00015.html
https://www1.ietf.org/mail-archive/working-groups/ieprep/current/msg00016.html

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 5 Nov 2002 17:20:04 -0500

On Tuesday, Nov 5, 2002, at 16:32 America/Montreal, Ayyasamy, 
Senthilkumar (UMKC-Student) wrote:
> of many identification methods like ...

Unfortunately, a good DDOS attack packet looks identical to
legitimate traffic.  We've seen that sort of DDOS attack within
the past fortnight.  So I don't think we can *prevent*
DDOS attacks.  You did describe a number of ways to track
down DDOS attackers that aren't clever -- and those methods
are useful.  They just aren't totally effective at preventing
DDOS.

> DoS/DDoS, we still could not find a solution

I don't think it is solvable, at least not in the
sense where we all do <x> and after that, no
DDOS attack can happen.

A point Mike O'Dell mentioned earlier today is that deployment
of DiffServ actually *creates* a new potential DDOS vulnerability
for the ISP that deploys DiffServ.  He's right about that, too.

Sigh.

Ran
[email-masked]

---

From: Bill Woodcock <[email-masked]>
Date: Wed, 6 Nov 2002 00:38:25 -0800 (PST)

On Tue, 5 Nov 2002, Ayyasamy, Senthilkumar  (UMKC-Student) wrote:
    > of many identification methods...

None of which are likely to be deployed over a sufficient portion of the
Internet to actually be useful for at least another three or four years.
At the _very_ least.  Much as we'd all like to have those tools useful
sooner.

    > is another major source.

Yes, it is.

    > DoS/DDoS, we still could not find a solution

Get rid of users.  They cause trouble.

See, it's simple.  :-)

Short of that solution, it's not so easy.  These aren't engineering
problems, they're human-factors problems.  That makes them somewhat less
tractable.

    > I am not aware of the deployment details.

There are none to be aware of, speaking broadly.

    > Operators generally employ flow/pkt passive
    > measurement tools like Netflow...

No, they don't.

    > should be distinguised from DDoS/flashcrowd traffic at the access"

Thereby giving attackers yet another path into our CPUs.  What attack
wouldn't categorize itself as emergency traffic?

Not sure any of this is particularly germane, in any event.

                                -Bill