Re: WG status 2003/08/13

On Wed, 13 Aug 2003, Leech, Marcus (EXCHANGE:FITZ:8M86) wrote:

>   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.
>
> If, in 30 days, there is no strong indication that this WG should continue, then
>   the existing document will be cleaned up so that it is implementable, and published
>   as an EXPERIMENTAL RFC.

Right now there are two options:

1. We want to implement strong anty-spoofing mechanisms to protocol itself
and make iTrace a complete and robust solution for tracing real source of
spoofed packets.

I think it has been proven a half a year ago that it requires complex
crypto/certiface/XML configuration. Even some kind of PKI deployment
would be necessary to make a strong antyspoofing infrastructure.
I we want to continue on that, it will be a very hard work and iTrace
*will* be so complex that nearly no one will deploy it.
It definetly will not be "on by default".


2. We want iTrace to help us in finding real source of spoofed packets.
Not a complete solution, but rather some kind of simple feature that will
mitigate todays attacks based on IP spoofing.

It is a lot easier to achieve. Most things are allready done and they only
need to be fine tuned (because we are dropping the
crypt/hash/certificate/XML parts now). In this scenario iTrace can be "on
by default" because no additional configuration and CPU overheat is
required.
There are still some attacks possible (spoofed iTrace packets, flooding
with iTrace packet, etc...)

Personally, my vote is for the second option.
It *will* help in tracing real sources of spoofed packet. Moreover,
iTrace.v1 could become some kind of background for a more robust iTrace.v2
protocol with all those fluffy crypto stuff.
Also, deployment of iTrace.v1 would give us some comprehensions of how
people will try to attack that protocol - what I mean here is that if we
decide to build strong iTrace from scratch, there are chances that we will
miss something important.

I think it *must* be "on by default" if we want iTrace to become something
more than just another "technique than you can deploy if you care about
other networks security, want to overheat you main routers CPUs, willing
to read a 100+ pages long documentation and spend a week on configuring
your devices". In a perfect scenario it need to have no configuration (or
a "configure once and forget about it" configuration) no additional CPU
overheat and do not breake any existing software and protocols.


Which option WG members prefer?


---
Tomasz Grabowski  (0-91)4494234
Akademickie Centrum Informatyki
mailto:[email protected]