zwang@CS.UCL.AC.UK.UUCP (06/29/87)
Hi, Does anyone know of the implementation of IP options( source route, timestamp and so on) under UNIX? In our dept, there is only one line: m_free(opt); for the IP options. Thanks in advance! zwang@uk.ac.ucl.cs (UK) zwang@cs.ucl.ac.uk (US)
karels%okeeffe@UCBVAX.BERKELEY.EDU (Mike Karels) (06/29/87)
4.3BSD implements most of the IP options (except security); 4.2 BSD did not. Mike
tucker%mycroft@gswd-vms.Gould.COM (Tim Tucker) (06/30/87)
Why didn't Berkeley implement the security option? Those of us selling systems to the DOD need to add it anyway and it would probably be nice if a common implementation across all users of 4.3BSD TCP existed. Why do I care? The security option requires some user space changes to programs like FTP and TELNET besides just kernel changes. Tim Tucker Gould Computer Systems Division tucker@gswd-vms.Gould.COM
randy@DBNET.CS.WASHINGTON.EDU (Randy Day) (07/04/87)
Been looking at this code in the last few days myself.
I've been looking at the 4.2BSD and 4.3BSD implementations of ip_output()
in /sys/netinet/ip_output.c.
As far as I can tell (and I feel fairly confident about this), the
4.2BSD code just ignores any options passed to the ip_output routine.
The 4.3 code replaces the initial call to m_free(opt) with
if (opt)
m = ip_insertoptions(m, opt, &hlen);
Where ip_insertopitons() is a new function that does about what you
would expect: it inserts mbufs containing the options in the
data about to blasted out over the net.
The 4.3BSD "Changes to the Kernel in 4.3BSD" manual section says:
"Support was added for IP source routing and other IP options....IP properly
updates source-route and record-route options when forwarding (and leaves
them in the packet, unlike 4.2 which stripped them out after updating)."
The 4.2BSD networking code is brain damaged, and would certainly not
pass even the most modest validation suite if one existed for TCP/IP
implementations.
Randy Day.
Internet (ARPA): randy@dbnet.cs.washington.edu
CSNET: randy%washington@relay.cs.net
UUCP: {decvax|ihnp4}!uw-beaver!uw-june!randyvan@LBL-CSAM.ARPA (Van Jacobson) (07/04/87)
>Why didn't Berkeley implement the security option? Those of us selling systems >to the DOD need to add it anyway and it would probably be nice if a common >implementation across all users of 4.3BSD TCP existed. Why do I care? The >security option requires some user space changes to programs like FTP and >TELNET besides just kernel changes. The part of the security option ftp & telnet need is implemented in 4.3. User level programs can stick a security option on any TCP, UDP or IP socket. The option will be tacked onto every IP datagram sent on that socket. The code to do this looks something like /* format a legal security option in a 12 byte array */ ipopt[IPOPT_OPTVAL] = IPOPT_SECURITY; ipopt[IPOPT_OLEN] = 11; ... ipopt[11] = IPOPT_NOP; /* pad */ /* put the option on socket "s" */ if (setsockopt(s, IPPROTO_IP, IP_OPTIONS, ipopt, 12) < 0) perror ("setsockopt:ipopt:"); On the incoming side, 4.3 ip ignores the security option and 4.3 tcp discards it. But the option is passed intact up to the tcp layer and it would be trivial to change tcp_input to process it (If you were trying to make a secure Unix, you'd be re-writing the kernel. This change would be the least of your worries and, anyway, it couldn't be done until the rest of the system security model was in place.) - Van
ron@TOPAZ.RUTGERS.EDU (Ron Natalie) (07/04/87)
Because nobody at the time had any idea what you would use the security option for. -R t
gnu@hoptoad.uucp (John Gilmore) (07/05/87)
tucker%mycroft@gswd-vms.Gould.COM (Tim Tucker) wrote: > Why didn't Berkeley implement the security option? Those of us selling systems > to the DOD need to add it anyway and it would probably be nice if a common > implementation across all users of 4.3BSD TCP existed. I have an idea -- why doesn't Gould implement it, and post the changes to the net, or send them to Berkeley? You seem to be the first to need it, and making it available for free, like Berkeley did with the whole protocol implementation, makes it likely that "a common implementation across all users" will exist. -- {dasys1,ncoast,well,sun,ihnp4}!hoptoad!gnu gnu@ingres.berkeley.edu Alt.all: the alternative radio of the Usenet. Contributions welcome - post 'em
STJOHNS@SRI-NIC.ARPA (07/06/87)
For single level systems (those evaluated at less than B2), the only place you need to deal with the IP security option is at the IP level. You need to have a configuration item which sets the level of your system. This must be reflected in the outgoing packets, and muct also be checked in the incomoing packets. Incoming packets without the proper security option in them must be logged and dropped. (Err, this is what the rules say, if I were imple,menting this, I'd add a configuration item for dropping non-compliant incoming datagrams and leave it off until you connect to BLACKER, or are reasonably certain everyone else is in compliance.) By the way, which IP security option is everyone out there concerned about? The one in the RFC? If so, hang on to your horses. You might want to take a look at the revised IPSO in [NIC]ps:<stjohns>ipso.txt. Mike