Re: New iTrace proposal

On Fri, 17 Oct 2003, Tomasz Grabowski wrote:
> 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).

Yep.. which is in some sense a feature.  Inventing a technical solution to 
a process problem may not help.  But perhaps we have different 
justification for this ind mind...

> 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.

How do you defined "don't forward any others iTrace messages"?  In the 
original mail you said this would be "router itself", which would 
obviously fail in a network of more than just one network.

Defining a scope or organization whose iTrace messages it would be OK to 
forward is difficult.. and it's even more difficul to ensure that nobody 
in that network can spoof *those* iTrace messages (e.g., if the site 
doesn't care, attacker within that site can spoof the iTrace, which by 
virtue will go out.)

So, I think this is far from trivial problem to tackle, and I'm not sure 
if we need that distinction.

> 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 :)

Yeah, I can sympatize with this .. and some separate toggles could be 
implemented, I guess, if it was straightforward enough.  I just think that 
any query/response protocol here is a non-starter, and without such there 
are very difficult problems to solve to get to where you want..

[...]
> > 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.

iTrace messages can be rate-limited, this should not be a problem.
 
> 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.

Such actions would also block the usefulness of iTrace in the first 
place..

> > 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.

I'm not sure if you know what you're talking about.  See 
draft-gill-gtsh-04.txt for an idea.

With that, you can ensure that every iTrace received with e.g. TTL=240 is
originated *at least* 15 hops away.  This is a great help if you want to
trace a source less than 15 hops away.

So, for reasonably local tracing, setting TTL=255 for outgoing iTraces 
should work just fine.  For global tracing, the attackers could try to 
guess the how many hops away the iTrace inspector is from the routers 
sending iTrace and do some iTrace injection of their own.

The point here, however, is that you don't do anything if you don't 
receive *coherent* *trace* of itraces, e.g. every router, with increasing 
hop-count, sends you about the same amount of itraces regularly.  Weeding 
out wrong itraces from that should not be a huge problem.

But this kind of security model would need more thinking, of course.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings