Re: New iTrace proposal

On Fri, 17 Oct 2003, Pekka Savola wrote:

> I'm not sure if I see the need for a protocol for these three modes.
>
> They could be operational modes, achievable by doing packet filtering on
> the specific ICMP type/code, end of story.

But it requires some admin action (e.g. configuring packet filtering).

Most networks that are used to todays DDoS attacks are administered by
people who don't care about security. They don't want to know what iTrace
is. They don't want to block anything. They just want to turn theirs
router on, make some essential configuration, and have their networks up
and running.
What, from the iTrace view point, we want from these networks?
- we want that theirs router will generate iTrace messages
- we don't want that host in theirs networks will generate spoofed iTrace
  messages.
- we want to protect them from flood of iTrace messages.

So, mode 1 (generate iTrace messages, don't forward any others iTrace
messages) is designed for them. It is ON by default, it makes that theirs
network *can't* be flooded with iTrace messages (which is important,
becasue iTrace is becoming less attractive for attackers as a flood tool
itself), and they even don't need to know that it is actually running (it
makes no difference for CPU and bandwidth utilization). Hosts in theirs
networks can't be used to generate spoofed iTrace messages.


If someone has more networks to administer (an ISP for example) he has
probably more qualified personel, that cares about security (more or
less). So, they actually *want* to know what iTrace is and how it works.
They will decide whenever they want to use mode 2 (because thay are small
ISP that want to analyze iTrace packet by himself) or mode 3 (because they
are big ISP or some company like GEANT [http://www.dante.net/geant/GEANTtopology0603.jpg])
and they want to let all iTrace messages flow, and generate their own
iTrace messages. Of course they don't need to analyze all iTrace messages.

The main goal is simplicity. There is almost no configuration. It can be
something like:
If you are ISP - turn mode 3.
If you care about security and want to analyze iTrace messages going from
and to your network - turn mode 2 and configure it.
If you don't read this text at all - leave mode 1 :)


> I fail to see how you'd have to complicate this with a protocol, when
> *apparently* at least, an operational procedure would be enough.

It's still easy to implement I think.


> The default bevivour would naturally be your mode 3 ("forward all iTraces,
> generate them").

In this case, iTrace would be attractive for attackers. Network which are
suffering from DDoS attacks usually turning packet filtering on. They
limiting protocols like ICMP, sometimes UDP and so on. But probably they
will want to let iTrace messages in, so they could use them. This way
iTrace is becoming attractive for attackers, because there is a great
chance that these packets will go through firewalls.

We need to render iTrace as useless to the attackers, as possible. If it
will be blocked on most routers by default, it will not be attractive
for attackers.


> I disagree about this.  In practice these query/response protocols
> re-invent security, and usually make a mess out of it.
>
> I think just using the TTL=255 when originating packets should be enough.

TTL can be easily spoofed. There need to be a way to check if particular
iTrace messages was sent by particular router.


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