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