Default behaviour of IP Options processing

From: Andre Oppermann (andre_at_freebsd.org)
Date: 05/06/04

  • Next message: Jacques A. Vidrine: "Re: Default behaviour of IP Options processing"
    Date: Thu, 06 May 2004 21:16:03 +0200
    To: freebsd-current@freebsd.org, freebsd-net@freebsd.org
    
    

    I have just committed the attached change to ip_input() to control the
    behaviour of IP Options processing. The default is the unchanged
    current behaviour.

    However I want to propose to change the default from processing options
    to ignoring options (or even stronger to reject them).

    The rationale is as follows. IP Options do not have any legitimate use
    in todays Internet at all. For a long time now we have disabled source
    routing. The remaining IP Options are RR (record route) and TS (time
    stamp) which are both useless. For finding out which path a packet takes
    we use traceroute instead of RR. Besides that RR is limited to the space
    in the IP Options field and can possibly record only a few hops (9 IIRC).
    Time stamp is useless for the same reason and since it doesn't have a
    fixed and synchronized timebase it is even more so useless.

    Opinions? Discussion? Yes/Nay?

    -- 
    Andre
    > andre       2004/05/06 11:46:03 PDT
    > 
    >   FreeBSD src repository
    > 
    >   Modified files:
    >     sys/netinet          ip_fastfwd.c ip_input.c ip_var.h
    >   Log:
    >   Provide the sysctl net.inet.ip.process_options to control the processing
    >   of IP options.
    > 
    >    net.inet.ip.process_options=0  Ignore IP options and pass packets unmodified.
    >    net.inet.ip.process_options=1  Process all IP options (default).
    >    net.inet.ip.process_options=2  Reject all packets with IP options with ICMP
    >     filter prohibited message.
    > 
    >   This sysctl affects packets destined for the local host as well as those
    >   only transiting through the host (routing).
    > 
    >   IP options do not have any legitimate purpose anymore and are only used
    >   to circumvent firewalls or to exploit certain behaviours or bugs in TCP/IP
    >   stacks.
    > 
    >   Reviewed by:    sam (mentor)
    > 
    >   Revision  Changes    Path
    >   1.11      +10 -2     src/sys/netinet/ip_fastfwd.c
    >   1.271     +13 -0     src/sys/netinet/ip_input.c
    >   1.87      +1 -0      src/sys/netinet/ip_var.h
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
    

  • Next message: Jacques A. Vidrine: "Re: Default behaviour of IP Options processing"

    Relevant Pages

    • Default behaviour of IP Options processing
      ... I have just committed the attached change to ip_inputto control the ... stamp) which are both useless. ... > net.inet.ip.process_options=0 Ignore IP options and pass packets unmodified. ... > This sysctl affects packets destined for the local host as well as those ...
      (freebsd-current)
    • Re: IPS with no IP address?
      ... concept of the stackless control channel. ... Basically directing control ... Stackless Control Channel - AES encrypted packets directed through the ... Recognizer - Code running on the appliance capable of interpreting ...
      (Focus-IDS)
    • Re: Im newbie so I might understand more
      ... aircraft was useless because it is a control had not been ... It had been proven useless, ... Furthermore make it observer. ... u make false assumption by assuming a car is useless. ...
      (sci.engr.control)
    • Re: Request for Help
      ... They are simply easier throws to control, ... the margin of error on those throws will always be higher. ... useless for ITs above the chest. ... I think you've made some people consider using the thumber forehand on ...
      (rec.sport.disc)
    • Re: Controlling rate of tcp/ip data transmission
      ... is a slow speed device. ... the size of the data packet with 1/4 the wait between packets. ... but I've got 4x as much overhead on the control packets I'm sending... ... receiver has 0 TX and the sender has 0 RX on the connection. ...
      (comp.os.linux.networking)