Re: hop-by-hop and router alert options

On 26-aug-04, at 8:13, Pekka Savola wrote:

> But what
> I'm really worried about is that IP router alert -like options are
> options which a hardware implementation cannot process.  An attacker
> can just specify an undefined router alert option which forces the
> processing to go to the slow path (instead of ASICs etc., it must be
> put on the CPU), and overload the processing of the router that way.
> That's not good.  That can naturally be mitigated by rate-limiting the
> IP options to some small value, but such would effectively disable the
> processing of options, and require that you're able to match on those
> options.  In other words, anything which has to be forwarded that
> requires CPU processing seems bad to me..

Pekka, please don't worry about this. There are very many things that 
can happen that require that the CPU look at packets: the hop limit may 
reach zero, the packet may be addressed to one of the addresses of the 
router, the packet may be too big for the next hop link...

Router vendors are able to cope with this with rate limiting. Really.

> Btw, you might be interested that in PMTUD WG session at IETF60 where
> Michael Welzl proposed using IP options for PMTUD, Mark Allman (AFAIR)
> reminded of someone (him?) conducting tests on how big percentage of
> hosts respond or not when there are IP options.  Michael's
> presentation
> (http://www.ietf.org/proceedings/04aug/slides/pmtud-4.pdf)

Ok, now this is a VERY stupid idea. I really don't get how such a large 
collection of smart people can come up with some many stupid ideas. 
This isn't going to work any better than current PMTUD works.

The very obvious only correct way to do PMTUD is for the correspondent 
to notice incoming fragments and inform the source of the size of the 
biggest fragments.

But that wasn't what we were talking about.

> already said that 30% were ignored you completely (not just the IP 
> option!),

It doesn't say, but I'm pretty sure this is IPv4, where options are 
long dead because they are just too bizarre and hardly used.

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf