Re: Default behaviour of IP Options processing

Let me take this email from Julian to summarize and answer all the
previous questions of this thread that has spawned...

> I know these are "options" but what does the standards say about not
> supporting them.. ? (I have seen non optional options before :-)

RFC791 (IP specification) requires them to be implemented for IP packets.
However this can be interpreted to say that it must be able to deal with
them (like ignoring them) and not fall over if it gets some.

RFC1812 (router requirements) differentiates between the options.  Security
option should be implemented but is not and has never been used.  Stream
identifier option must be ignored and has never been used.  Source route
options must be implemented but is considered evil and disabled by default.
Record route may be implemented.  Timestamp option may be supported.

> also I dislike the all-or-nothing mechanism
> I would rather see:
> net.inet.ip.options.RR: 1
> net.inet.ip.options.TS: 0
> net.inet.ip.options.SECURITY 0
> net.inet.ip.options.LSRR: 0
> net.inet.ip.options.SATID: 0
> net.inet.ip.options.SSRR: 0
> net.inet.ip.options.RA: 0
> 
> where options we DON'T support exist and are stuck at 0.

This goes far to much into the detail and is beside the point, see next.

> Rationale.

The sysctl is supposed to provide an option to disable IP options processing
on the local host without having to set up firewall rules.  Some settings of
the sysctl prevent the IP options code from being run at all.  Thus it can't
be exploited in any way.

I agree after the explanation by Julian and Maxim that the RR together with
ping has its good uses.  On the other hand the IP Options processing can be
quite nasty for a machine if you send it enough normal packets with options
that have to be processed.  Doing the IP options requires a packet copy in
many cases.  Additionaly there are the security concerns in which the seldomly
used IP options are likely to contain bugs or other nasty properties either
in our implementation or some other down the stream.  Jaques as one of our
Security Officers had likely this in mind when he voted for a strict default.

My goal was/is to take out a potentially complex processing path of ip_input()
without much current purpose except for ping with RR.  Ping packets are small
and few.  Empirical evidence (as on my core routers) suggests that the use of
IP options is extremely rare and few in between.

May I propose an default setting for IP options which allows for RR but
restricts the packet size that will be acted upon and is rate limited like
many of our ICMP replies to certain other events like closed ports etc?
This would satisfy the RR tracers and make Jaques and me more happy than
we are with the current situation.

> Documentation.

I have agreed with Ruslan to go through all ip and tcp related man pages
and sync/update them with reality.  There are many things that have changed
in the past year that need to be correctly reflected in the man pages.  He
will do the mdoc markup.  This will be done before 5.3R.

-- 
Andre