Jari and Pekka,
Thanks for stimulating discussion on this. I too agree that it should be a high priority and that if we can do something at the IP layer it should be done. I will also subscribe to the IPTRACE WG. Clearly there are other forms of attack such as stealing address, usurping addresses, using all addresses up on a subnet and application specific methods that should be addressed. I would definitely support activities that would help educate designers to the possible scenarios and even try to build specific layering mechanisms to guard against attacks. With this last meeting, I have seen many new proposals, especially related to mobility that significantly open up to door to more DoS attack.
After reviewing the IPTRACE mail list, I have noticed that many of the stumbing blocks they are faced with are due to the fact that there is a significant deployment of routers currently out there and that there is nothing mandated to be built into them to help facilitate proposed solutions. I believe that the identification of problem areas i.e. possible DoS attack could be built into IPv6 in a scalable manner if we are careful.
In beginning the discussion, I would like to bring up a discussion that occurred earlier this year on the list with Charlie Perkins, Frank and myself. This discussion is partly stimulated by some recent product announcements from some vendors on this type of functionality. I am thinking that perhaps now, since there are more products available which could be used to deploy the functionality, the standards discussion might be a bit more open to the proposals.
I would like to again float the idea that perhaps some sort of filtering on source address should be mandated on the first hop. My reasoning on this is that the existing filtering mechanisms are sort of a pariah i.e. it might be there or it might be not and we really have no idea where that "there" might be throughout the network. Clearly, the most scalable and effective place to do this filtering is on the first hop. Doing it at other points within the network is not guaranteed to be completely affective as it may not stop all slaves.
It seems that two mechanisms for these filters have been proposed. One mechanism is a simple ingress check on an interface. The other is an exception mechanism that I believe has been coined ACL access control lists.
The ACL list appears to allow specific addresses or range of addresses to pass through. It seems to me that if the ACL lists are used then there might be a glimmer of hope that mobile nodes could use their home address as source on visited domains and a whole range of solutions designed with this assumption will be able to be used with less change.
It seems that when a mobile enters a visited subnet, the ACL lists could be updated to allow them in as part of neighbor discovery and AAA operations. Furthurmore, it seems to me that handoff signaling between domains could provide the trust relationships necessary to transfer the necessary filter requirement.
The mobility and ACL lists aside, the mandate of just requiring even the simplist form of ingress filtering on the first hop, would signifantly improve IPv6's DDoS protection. It might make the job of Itrace a bit easier, as well, if instead of dropping the packets, the packets could be tunnelled or flagged in some manner to the attacked site. There might even be some valid reasons for tunneling the packet to the spoofed subnet as well in order to alert them that another node is impersonating it. With these mechanisms in place you could turn on and off slave monitoring software in the visited sites to try to surmise the masters and take more action.
Although these other ideas will certainly require some significant thinking and discussions on scalability etc.., I would really like people to seriously consider at a minimum just mandating the simple source address filtering on the first hop in IPv6.
Another area that I do not see much activity on is that of DDoS on routers, themselves. Tunneling of router advertisements is a major new hole that could be exploited. I believe Michael Thomas has tried to bring this up in the mobile IP WG and I agree with him that we have to be very careful in doing this sort of thing. I honestly see no way to safely do this without requiring strong encryption on the tunnels and extremely tight access authorization. I would like to stimulate discussion and work on these topics as well.
I think there might also be an issue with autoconfiguration address schemes. It seems that a rogue node could depleat all of the available addresses on a subnet if it wished. I'm hoping I am wrong about this and just have missed something. I beleive Pekka's 'PBK+ series of hashes' draft points out some other issues as well.
As others should be able to see by the mail list activity it may be a significant amount of bandwidth discussing these issues. The intent of my first mail was to politely ask the question to the chairs, "Do you want this bandwidth on this list at this time or would you rather have it separated. Perhaps you may wish to simply have a separate mailing list for organizational purposes?". I don't think we need or want another WG unless we want to do these application centric frameworks.
Thanks to all,
Glenn
-----Original Message-----
From: Jari Arkko [mailto:[EMAIL PROTECTED]]
Sent: Thursday, March 22, 2001 9:52 AM
To: Morrow, Glenn [RICH2:C330:EXCH]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: DDoS Work
Glenn Morrow wrote in the IPv6 mailing list:
>Is this the appropriate group to discuss possible improvements
>to detection, prevention, reporting and action against DoS
>and DDoS attack for IPv6?
>
>It seems to me that perhaps a less constrained set of
>mechanisms could be put in place to more effectively
>deal with the issue than in IPv4. It may also be possible
>to better harmonize these solutions with proposed node
>mobility, renumbering and multihoming solutions.
We believe addressing DoS and DDoS concerns should be a
high priority.
One idea we have played with is a general-purpose
IP-layer DoS protection scheme, applicable to both
existing and new protocols. For instance, servers could
use a combination of additional packet roundtrips,
client-stored state, and cryptographic puzzles to
prevent resource starvation, requests from forged
source addresses, and massive request generation from
distributed clients. Today, people seem to be hoping
that the application protocols do this by
themselves. And, frankly, we're not doing a very good
job at that. Most protocols, even security protocols,
are known to have DoS problems that would have been
possible to solve, had more attention be paid to them
in the design work.
The question is, is there something that could be done
as a general support in IP (IPv6) for this? Such as
ICMP mechanisms that demand puzzle solving from a
client before proceeding etc. Needless to say, these
mechanisms shouldn't create additional DoS
possibilities.
At this time we are not sure what the mechanisms in
detail could be, whether they work on the IP layer or
if they are reusable protocol components integrated to
application protocols (a la SSL), or whether it is
possible to avoid additional DoS dangers. Or if we
just need a protocol designer's guide that explains
how new protocols must deal with DoS attacks.
>Would people recommend a new WG to deal with
>these particulars or do people feel that this
>or another existing WG is sufficient?
Well, there are a number of potential discussion places:
* The current DoS and security issues in mobile IP would
call for some discussion in that group.
* The current DoS issues for some of the IPv6 signaling
and address autoconfiguration call for some discussion
in that group. There's also some autoconfiguration
issues in the zeroconf WG.
* In the Internet Area, there is the itrace WG which is
specifically chartered for looking into DoS, but is
looking only at a particular solution. Is this
solution sufficient for all DoS issues? We're not sure
but at least some of the individual DoS concerns such
as attacking address autoconfiguration don't really
fall on the area that i-trace can deal with.
* The HIP BOF on Tuesday seemed to decide that a
new WG will be created to implement new identity
mechanisms in IP, in order to deal better with
mobility and DoS attacks.
* Perhaps a completely new, separate working group might
also be a possibility.
In any case, we think DoS should get more attention
than many of the other issues such as confidentiality
and privacy that have been dealt with early.
Jari Arkko
Pekka Nikander
Ericsson
