Subject: RID-DoS Mailing list (Inter-network messaging)

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 28 Oct 2002 10:45:35 -0500

Hello,

I set up a mailing list to discuss the Internet Draft:

      Distributed Denial of Service Incident Handling:
               Real-Time Inter-Network Defense

http://www.ietf.org/internet-drafts/draft-moriarty-ddos-rid-02.txt

It is a managed list, so please send me an email message if you would 
like to be added to the list to [email-masked].  I am thinking 
about setting up a BoF in the Operations and Management Area at an 
upcoming IETF meeting and would appreciate some feedback on my draft.

Abstract:

     One of the latest trends attacking Internet security is the
     increasing prevalence of Denial of Service (DoS) attacks.  DoS
     attacks target system and/or network resources and seek to
     prevent valid access by consuming resources.  Internet Service
     Providers (ISPs) need to be equipped and ready to assist in
     tracing these attacks with tools and procedures in place before
     the occurrence of a DoS attack.  This paper proposes a proactive
     inter-network communication method to integrate existing
     tracing mechanisms across ISP boundaries to identify the source(s)
     of an attack.  The various methods implemented to trace attacks must
     be coordinated both on the ISPs network as well as provide a
     communication mechanism across network borders.  It is imperative
     that ISPs have quick communication methods defined to enable
     neighboring ISPs to assist in tracking a security incident across
     the Internet.  This proposal makes use of current tracing practices
     for traffic and performance management, which could be extended
     for DoS incident handling.  Policy guidelines for handling these
     incidents are recommended and can be used by Internet Service
     Providers (ISPs) and extended to their clients in conjunction with
     the technical recommendations.

Brief overview of messaging mechanism:

The main purpose of the messaging mechanism is to allow for traces of 
security incidents to be passed to the next upstream network, client to 
ISP or ISP to ISP.  The messages are merely requests and response 
messages to continue traces and to send notification of trace 
results/mitigation.  The receiving management system of a trace request 
can make a decision as to whether or not the trace will continue based 
on resources and/or the confidence rating.  The decision can be 
automated or left to be decided by the network management staff.  The 
trace continuance across each network is decided upon by the managers of 
that network since it requires access to the systems on that network. 
RID-DoS passes along the superset of information needed by all trace 
mechanisms used across a single network (non changing fields of IP 
header, first 8 bytes of payload, and time of event).  If there is 
additional information needed by a trace system I am not aware of, 
please let me know.  When the source is found, a message is sent back to 
the system who originated the trace to notify them of the source and any 
action taken (in accordance with SLA agreements).

Current Work:

1.  The security section needs to be extended to include authorization 
details on the trace requests and other messages.

2.  The details of the communication between systems needs to be 
expanded upon.
     a. The security of the machines themselves
     b. The security of the networks (out-of-band or encrypted tunnels)

3.  The draft needs to include details on how a confidence rating is 
chosen to help mitigate abuse of the system.

Social aspects:

Some of the social issues are not addressed in the draft, but I have 
several ideas of how they might be addressed.

1.  How do you get ISPs to use a system like this?
   a.  Establish RID-DoS communication mechanism when configuring 
peering points
   b.  Include the requirement for RID-DoS in peering agreements (larger 
ISPs may be able to drive this).
   c.  Peering agreements may be the place to set up the policy for the 
communication of these systems (may be similar to Certificate policy 
where physical security, access control, etc. are clearly defined).

2.  Where would funding come from to support the addition of this system?
  a.  Extend the service to client networks.
     Value added service
     Include arrangements in SLA

Finally, I presented this at the SANS DDoS Symposium last week and have 
received feedback from some ISPs and vendors.

Thank you for your time reviewing the draft and any feedback you may have.

-Kathleen

__________________________
Kathleen M. Moriarty
MIT Lincoln Laboratory
[email-masked]