Default behaviour of IP Options processing

[Sam Leffler]

On Thursday 06 May 2004 04:06 pm, Julian Elischer wrote:
> On Thu, 6 May 2004, David W. Chapman Jr. wrote:
> > > You mean ip options not tcp, right?  I do not understant why we
> > > invent a new mechanism if we already have one.  Put an example in
> > > /etc/rc.firewall.
> >
> > Yes, I stand corrected, ip option it is :)
> >
> > > You mean "more obscure", right?  Where net.inet.ip.process_options
> > > documented?  How does it operate with f.e. IPSTEALTH?
> >
> > I definitely agree it should be documented, but that's just a minor
> > detail which can be easily taken care of.
>
> I know these are "options" but what does the standards say about not
> supporting them.. ? (I have seen non optional options before :-)
>
> 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.
>
> or maybe even:
> net.inet.ip.options.RecordRoute: 1
> net.inet.ip.options.TimeStamp: 0
> etc.
>
> if they are usually turned off then the test would only be done if that
> option exists and it would still be faster that actually doing the
> option.

For fine-grained selection packet filtering is the better solution.  This is a 
simple, much lighterweight, mechanism that doesn't require touching every 
packet.

	Sam