From owner-freebsd-net@FreeBSD.ORG Thu May 6 17:09:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77C3516A4CF for ; Thu, 6 May 2004 17:09:56 -0700 (PDT) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB78443D1D for ; Thu, 6 May 2004 17:09:54 -0700 (PDT) (envelope-from andre@freebsd.org) Received: (qmail 91698 invoked from network); 7 May 2004 00:09:53 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 7 May 2004 00:09:53 -0000 Message-ID: <409AD3D0.DF5114F@freebsd.org> Date: Fri, 07 May 2004 02:09:52 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: "David W. Chapman Jr." cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: Default behaviour of IP Options processing X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 May 2004 00:09:56 -0000 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