1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
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.
|
