Re: WG status 2003/08/13

On Wed, 13 Aug 2003, Leech, Marcus (EXCHANGE:FITZ:8M86) wrote:
> > 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
> 
> The really onerous crypto bits are OPTIONAL. 

Sure, that's what I recall, but those are still (IMHO) non-essential 
parts; we could just put them in a separate iTrace extension document, so 
the "base spec" would be very simple.

>  I don't remember the details
>   of your random-number proposal (some kind of out-of-band packet verifier?),
>   but it sounds, on the surface, to be computationally about the same cost
>   as the existing proposal (which only needs to trigger 1/N, N=large packets
>   anyway).

Sorry for poor choice of words.  I meant that routers could just send 
their iTrace packets with TTL/Hop-Limit of 255, and the recipients could 
verify (to very large extent) how authentic it aappears by combining the 
address pairs and hop-limit's from messages received.

That seemed to offer a base protection against spoofing etc.

The only crypto that would be needed is some kind of weak randomn number 
generator or LCPRNG for picking which packets to perform iTrace on.

The rest is just extra and a hindrance at the moment.  They may prove to 
be useful later on, but now the first priority should be getting a simple 
spec out ASAP.

> > >   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.
>
> It would be useful to get the perspective of providers on this--if they aren't
>   adopting ingress/egress filtering, why would they adopt itrace?

I can't say because we implement filtering, but a few guesses:

 1) iTrace doesn't really break anything (e.g. ingress filters could if 
the list is not up-to-date, RPF problems with asymmetric/multihomed, 
maintenance troubles)

   caveat: could raise the number phonecalls due to weird ICMP messages 
sent to valid parties;

     fix: write a good web page explaning the issue ("www.itrace.org"), 
and point people to that.

 2) iTrace is relatively lightweight, some vendors' ACL implementations 
can't handle linespeed.  E.g. with STM-16 (2.5 Gbit/s) interface, iTrace 
might result in some 10-20 iTrace packets a second.  Could be doable even 
on sloppy CPU's if there are no crypto requirements :-)

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