Re: New iTrace proposal

At 05:51 PM 10/17/2003, Mikael Olsson wrote:


>Tomasz Grabowski wrote:
> >
> > On Fri, 17 Oct 2003, Mikael Olsson wrote:
> >
> > > > So, mode 1 (generate iTrace messages, don't forward any others iT=
race
> > > > messages) is designed for [nincompoops].
> > >
> > > Mandating such a mode means that suddenly all routers need to
> > > apply ACLish behavior on all traffic.  This was unlikely in
> > > the first place, and even less likely now.
> >
> > Why? Because of routers performance overheat? What is the reason?
>
>You hit the nail on the head.  Routers and switches are rated
>according to what they can _forward_, not what they can pass up to
>the main CPU.
>
>Not everything is a PC.

And not every router is built with distributed CPUs. And not every router=
=20
relies on a central CPU to handle ACLs, options and other special cases.

Let's be careful when designing protocols to NOT design around specific=20
hardware designs.

Present router architectures evolved based on the needs of the protocols=20
and the performance required. If new protocols or practices require new=20
router designs for optimal handling, then let the router vendors do that=20
piece of engineering.

A frequent argument against doing ingress filtering is that "the cpu will=
=20
die" and yet hardware vendors HAVE implemented ACLs that work in line=20
cards, ASICs and so forth. Don't short-change ideas JUST because the=20
routers of today may not be sufficient. Yes, the economy is tight and all=
=20
that, but by the time a new mechanism is specified and released, there wi=
ll=20
be new routers purchased. When we first proposed ingress filtering (1996)=
,=20
the routers in the core were Cisco 7000s. Those were replaced with 7500s,=
=20
then 12000 series and Junipers. They'll be replaced again over time.

Note that I'm not commenting on the underlying discussion here, just tryi=
ng=20
to keep from having folks shade design decisions based on present-state=20
hardware design.



> > > > their network *can't* be flooded with iTrace messages
> > >
> > > No, but their internet connection can.
> >
> > True. But they can keep theirs internal network immune to such attack=
s.
> > Better than nothing, I think.
>
>This is why we have network firewalls.
>
>
> > And it's making iTrace as attractive to attackers as other blocked
> > protocols.
>
>And I still think you're accomplishing nothing by having
>random edge routers block itrace.
>
>What is your specific attack scenario?  -- Please remember that
>people without firewalls are susceptible to any kind of flood,
>from GRE to 123/UDP to ping to whatever have you.  Also remember
>that the Internet connection usually dies from overload long
>before your internal LAN even _begins_ to slow down.
>
>
>--
>Mikael Olsson, Clavister AB
>Storgatan 12, Box 393, SE-891 28 =D6RNSK=D6LDSVIK, Sweden
>Phone: +46 (0)660 29 92 00   Mobile: +46 (0)70 26 222 05
>Fax: +46 (0)660 122 50       WWW: http://www.clavister.com