Re: hop-by-hop and router alert options

On Thu, 26 Aug 2004, Iljitsch van Beijnum wrote:
> 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.

All of these, except "packet may be addressed to one of the addresses
of the router" (obviously) are already situations which can be handled
(and AFAIK, are already handled in some equipment) on hardware.  
That's good.  The situation where the packet is aimed at one of the
addresses is also OK because you can actually set up filters for such
packets whether at the router or at your borders: it might not be
possible to check the "magic" packets which we're discussing.

Obviously, a specific kind of router alert option could be checked in
hardware as well, if the semantics were simple enough, there was
suffiicient customer demand, etc. (which there apparently isn't).  
But the real problem is that out of 16 bits of Router Alert option
codes, only about 3 values have been specified.  What does the router
do with an unspecified option code?  Even if it wanted, it couldn't
implement processing for the rest of the option codes, which are
unspecified, because it doesn't know how.  So either they need to be
ignored (which would lead to long introduction curve, if it would
require replacing hardware), or would need to be put on the CPU.  But
the latter provides an attack vector.

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

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