Re: WG status 2003/08/13
Pekka Savola <[email protected]> Wed, 13 Aug 2003 22:16:28 +0300 (EEST)
| Newsgroups | gmane.ietf.itrace |
|---|---|
| Message-ID | <[email protected]> |
A few comments. On Wed, 13 Aug 2003, Leech, Marcus (EXCHANGE:FITZ:8M86) wrote: > Such reason would consist of: > o strong indication (and this is perhaps more important) that network operators > would actually deploy it. We'd defininitely deploy it if: - it'd get implemented by our vendors, - it would be simple enough to operate (read: current draft is too complex; we'd want to run it without any crypto/certificate/XML parts except the (weak) random number generator, a thing I tried to point out at SF IETF56), and - it would seem to be usable (see below). > o firm committments by WG members to actually do the work of moving both our > existing document, and a potential active/intention-driven itrace document > forward. That would include submitting text revisions to the existing document, > participating in WG discussions and meetings, etc. I've provided feedback and would continue to do so. > o strong indication that this technology continues to be forensically useful, > in the face of increasing adoption of ingress/egress filtering, and the > use of so-called diffuse DDOS attack scenarios. This is a very good question, and I believe one of the most important ones in this decision. I do not believe ingress/egress filtering adoption rate has risen significantly, but more and more worm-based attacks seem to indicate that the typical trend is not to attack by address spoofing from a few sources and try to cover your tracks, but by brute force. In the brute force attacks, it doesn't really seem to matter to be able to trace to the real sources of the attack; they're just compromised machines anyway, working more or less on their own. More likely than not, the network admins know themselves already that the machines are not working nicely. So, I don't think iTrace would really be applicable for these scenarios, but on the other hand, as the total packet generation probability is just 1/20000, it probably would not hurt, either. Regardless of that, there still exist a class of attackers which do use spoofed attacks, are not worm-based, etc.; iTrace would be useful in figuring out the real source of these. In addition, there are several threats of packet reflection (Cspoofs source to A, send to B, B responds to A) which could be mitigated and found out using iTrace. Therefore, it seems to me that iTrace is certainly not a complete solution for your (D)DoS problems, it might be able to mitigate certain aspects of the threats. (Note, personally I'm not sure if we should pursue intention-based itrace or similar anyway at this stage. We just need a basic mechanism now, and see it implemented and gotten used. If it's successful, we can always extend it -- but I fail to see an urgent need for to do "pre-emptive" work which could turn out out to be useless in the long run.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings