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 moriarty@ll.mit.edu. 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
moriarty@ll.mit.edu