diff options
Diffstat (limited to 'usr.sbin/pppd/RELNOTES')
| -rw-r--r-- | usr.sbin/pppd/RELNOTES | 295 |
1 files changed, 295 insertions, 0 deletions
diff --git a/usr.sbin/pppd/RELNOTES b/usr.sbin/pppd/RELNOTES new file mode 100644 index 0000000..b993de2 --- /dev/null +++ b/usr.sbin/pppd/RELNOTES @@ -0,0 +1,295 @@ + pppd-2.1.1 release notes + Paul Mackerras 27 May 1994 + +This file details the new and changed features in pppd since version 1.3. +Briefly: + - the protocol code has been updated to conform with + RFCs 1548, 1549, 1332 and 1334 + - security has been improved + - functionality has been improved in various ways. + + +NEW FEATURES + +* The option negotiation automaton has been updated to RFC1548. LCP +now rejects the Quality Protocol option, since LQR is not implemented +yet. IPCP now uses the IP-Address option, and falls back to the old +IP-Addresses option if the IP-Address option is rejected. IPCP also +uses the new form of the VJ-Compression option. + +RFC1548 defines the "passive" option to mean that the automaton +outputs configure-request packets initially, but does not close down +if no answer is received. A valid configure-request received will +restart the negotiation. The "silent" option has been added with the +old meaning of "passive", i.e. the automaton will not output +configure-requests until it receives a valid one from the peer. + +* More systems are supported: in addition to SunOS 4.x and BSD/Net-2 +derived systems, Ultrix and Linux are supported, thanks to Robert +Olsson, Per Sundstrom, Michael Callahan and Al Longyear. + +* Options can be taken from files as well as the command line. pppd +reads options from the files /etc/ppp/options and ~/.ppprc before +looking at the command line, and /etc/ppp/options.<ttyname> after +interpreting the options on the command line. An options file is +parsed into a series of words, delimited by whitespace. Whitespace +can be included in a word by enclosing the word in quotes ("). +Backslash (\) quotes the following character. A hash (#) starts a +comment, which continues until the end of the line. In addition, the +`file' option causes pppd to read options from a file. pppd will +report and error and exit if ~/.ppprc or the file given as the +argument to the `file' option cannot be read by the user who invoked +pppd. + +* On those systems, such as NetBSD, where the serial line speed is +stored in the termios structure in bits per second (i.e. B9600 == +9600), it is possible to set any speed. + +* If desired, pppd will output LCP echo-request frames periodically +while the link is up, and take the link down if no replies are +received to a user-configurable number of echo-requests. This can be +used to detect that the serial connection has been broken on those +systems which don't have hardware modem control lines. + +AUTHENTICATION + +Previous versions of pppd have provided no control over which IP +addresses the peer can use. Thus it is possible for the peer to +impersonate another host on the local network, leading to various +security holes. In addition, the authentication mechanisms were quite +weak: if the peer refused to agree to authenticate, pppd would print a +warning message but still allow the link to come up. The CHAP +implementation also appeared to be quite broken (has anybody actually +used it?). + +This new version of pppd addresses these problems. My aim has been to +provide system administrators with sufficient access control that PPP +access to a server machine can be provided to legitimate users without +fear of compromising the security of the server or the network it's +on. In part this is provided by the /etc/ppp/options file, where the +administrator can place options to require authentication which cannot +be disabled by users. Thus the new pppd can made setuid-root and run +by users. + +The behaviour where pppd refuses to run unless the /etc/ppp/options +file is present and readable by pppd is now the default behaviour. If +you really want pppd to run without the presence of the +/etc/ppp/options file, you will have to include -DREQ_SYSOPTIONS=0 on +the compilation command line. + +The options related to authentication are: + + auth Require authentication from the peer. If neither + +chap or +pap is also given, either CHAP or PAP + authentication will be accepted. + +chap Require CHAP authentication from the peer. + +pap Require PAP authentication from the peer. + -chap Don't agree to authenticate ourselves with the peer + using CHAP. + -pap Don't agree to authenticate ourselves using PAP. + +ua <f> Get username and password for authenticating ourselves + with the peer using PAP from file <f>. + name <n> Use <n> as the local name for authentication. + usehostname Use this machine's hostname as the local name for + authentication. + remotename <n> Use <n> as the name of the peer for authentication. + login If the peer authenticates using PAP, check the + supplied username and password against the system + password database, and make a wtmp entry. + user <n> Use <n> as the username for authenticating ourselves + using PAP. + +The defaults are to agree to authenticate if requested, and to not +require authentication from the peer. However, pppd will not agree to +authenticate itself with a particular protocol if it has no secrets +which could be used to do so. + +Authentication is based on secrets, which are selected from secrets +files (/etc/ppp/pap-secrets for PAP, /etc/ppp/chap-secrets for CHAP). +Both secrets files have the same format, and both can store secrets +for several combinations of server (authenticating peer) and client +(peer being authenticated). Note that each end can be both a server +and client, and that different protocols can be used in the two +directions if desired. + +A secrets file is parsed into words as for a options file. A secret +is specified by a line containing at least 3 words, in the order +client, server, secret. Any following words on the same line are +taken to be a list of acceptable IP addresses for that client. If +there are only 3 words on the line, it is assumed that any IP address +is OK; to disallow all IP addresses, use "-". If the secret starts +with an `@', what follows is assumed to be the name of a file from +which to read the secret. A "*" as the client or server name matches +any name. When selecting a secret, pppd takes the best match, i.e. +the match with the fewest wildcards. + +Thus a secrets file contains both secrets for use in authenticating +other hosts, plus secrets which we use for authenticating ourselves to +others. Which secret to use is chosen based on the names of the host +(the `local name') and its peer (the `remote name'). The local name +is set as follows: + + if the `usehostname' option is given, + then the local name is the hostname of this machine + (with the domain appended, if given) + + else if the `name' option is given, + then use the argument of the first `name' option seen + + else if the local IP address is specified with a + host name (e.g. `sirius:') + then use that host name + + else use the hostname of this machine + (with the domain appended, if given) + +When authenticating ourselves using PAP, there is also a `username' +which is the local name by default, but can be set with the `user' +option or the `+ua' option. + +The remote name is set as follows: + + if the `remotename' option is given, + then use the argument of the last `remotename' option seen + + else if the remote IP address is specified with a + host name (e.g. `avago:') + then use that host name + + else the remote name is the null string "". + +Secrets are selected from the PAP secrets file as follows: + +- For authenticating the peer, look for a secret with client == +username specified in the PAP authenticate-request, and server == +local name. + +- For authenticating ourselves to the peer, look for a secret with +client == our username, server == remote name. + +When authenticating the peer with PAP, a secret of "" matches any +password supplied by the peer. If the password doesn't match the +secret, the password is encrypted using crypt() and checked against +the secret again; thus secrets for authenticating the peer can be +stored in encrypted form. If the `login' option was specified, the +username and password are also checked against the system password +database. Thus, the system administrator can set up the pap-secrets +file to allow PPP access only to certain users, and to restrict the +set of IP addresses that each user can use. + +Secrets are selected from the CHAP secrets file as follows: + +- For authenticating the peer, look for a secret with client == name +specified in the CHAP-Response message, and server == local name. + +- For authenticating ourselves to the peer, look for a secret with +client == local name, and server == name specified in the +CHAP-Challenge message. + +Authentication must be satisfactorily completed before IPCP (or any +other Network Control Protocol) can be started. If authentication +fails, pppd will terminated the link (by closing LCP). If IPCP +negotiates an unacceptable IP address for the remote host, IPCP will +be closed. IP packets cannot be sent or received until IPCP is +successfully opened. + +(some examples needed here perhaps) + + +ROUTING + +Setting the addresses on a ppp interface is sufficient to create a +host route to the remote end of the link. Sometimes it is desirable +to add a default route through the remote host, as in the case of a +machine whose only connection to the Internet is through the ppp +interface. The `defaultroute' option causes pppd to create such a +default route when IPCP comes up, and delete it when the link is +terminated. + +In some cases it is desirable to use proxy ARP, for example on a +server machine connected to a LAN, in order to allow other hosts to +communicate with the remote host. The `proxyarp' option causes pppd +to look for a network interface (an interface supporting broadcast and +ARP, which is up and not a point-to-point or loopback interface) on +the same subnet as the remote host. If found, pppd creates a +permanent, published ARP entry with the IP address of the remote host +and the hardware address of the network interface found. + + +OTHER NEW AND CHANGED OPTIONS + + modem Use modem control lines (not fully implemented + yet) + local Don't use modem control lines + persist Keep reopening connection (not fully + implemented yet) + + lcp-restart <n> Set timeout for LCP retransmissions to <n> + seconds (default 3 seconds) + lcp-max-terminate <n> Set maximum number of LCP terminate-request + transmissions (default 2) + lcp-max-configure <n> Set maximum number of LCP configure-request + transmissions (default 10) + lcp-max-failure <n> Set maximum number of LCP configure-Naks sent + before converting to configure-rejects + (default 10) + + ipcp-restart <n> Set timeout for IPCP retransmissions to <n> + seconds (default 3 seconds) + ipcp-max-terminate <n> Set maximum number of IPCP + terminate-request transmissions (default 2) + ipcp-max-configure <n> Set maximum number of IPCP + configure-request transmissions (default 10) + ipcp-max-failure <n> Set maximum number of IPCP configure-Naks + sent before converting to configure-rejects + (default 10) + + upap-restart <n> Set timeout for PAP retransmissions to + <n> seconds (default 3 seconds) + upap-max-authreq <n> Set maximum number of Authenticate-request + retransmissions (default 10) + + chap-restart <n> Set timeout for CHAP retransmissions to + <n> seconds (default 3 seconds) + chap-max-challenge <n> Set maximum number of CHAP Challenge + retransmissions (default 10) + chap-interval <n> Set the interval between CHAP rechallenges + (default 0, meaning infinity) + +The -ua option no longer exists. + + +SOFTWARE RESTRUCTURING + +Many of the source files for pppd have changed significantly from +ppp-1.3, upon which it is based. In particular: + +- the macros for system-dependent operations in pppd.h have mostly +been removed. Instead these operations are performed by procedures in +sys-bsd.c (for BSD-4.4ish systems like NetBSD, 386BSD, etc.) or +sys-str.c (for SunOS-based systems using STREAMS). (I got sick of +having to recompile everything every time I wanted to change one of +those horrible macros.) + +- most of the system-dependent code in main.c has also been removed to +sys-bsd.c and sys-str.c. + +- the option processing code in main.c has been removed to options.c. + +- the authentication code in main.c has been removed to auth.c, which +also contains substantial amounts of new code. + +- fsm.c has changed significantly, and lcp.c, ipcp.c, and upap.c have +changed somewhat. chap.c has also changed significantly. + + +STILL TO DO + +* sort out appropriate modem control and implement the persist option +properly; add an `answer' option for auto-answering a modem. + +* add an inactivity timeout and demand dialing. + +* implement link quality monitoring. + +* implement other network control protocols. |
