[ Pobierz całość w formacie PDF ]
.12 I must caution any implementor considering such a scheme that doing this13 greatly weakens security.Before considering any such short hold option, espe-14 cially for ISDN or regular dial-up, a cautious implementor would first exhaust15 all possible ways to speed up normal PPP authentication.On most media, this16 can be made to be much faster than any circuit-switched set-up time.In particu-17 lar, ISDN, which is about 100 times faster in call set-up than common analog18 modems, still has a call set-up time in the hundreds of milliseconds, while PPP19 negotiation can be an order of magnitude faster when well implemented.Thus,20 the security cost of implementing a short hold option is much higher than the21 supposed reduction in negotiation time.22 It is highly recommended that the system that initiated the link should also be23 the system that tears down the link to save toll charges when the link is idle.This24 rule avoids thrashing when demand dialing is used.Of course, in some unusual cir-25 cumstances, such as toll-reversing lines, a separate negotiation of either callback26 or Bandwidth Allocation Control Protocol (BACP, page 228) might be needed.27 Note that the distinction between caller and callee should be made available28 to the PPP authentication layer.See Authentication Protocols and About Security29 in Chapter 4.303132 Null-Modem Connection to Windows NT3334 Windows NT requires a small handshake before it will begin running PPP on a35 dedicated serial port connected to a device speaking PPP.(Such a cable often36 needs to be wired with the modem control signals reversed on each end.ThisS 37 configuration is known as a null-modem, since it makes the link look asN 38 though modems were in place.For this reason, the driver used with NT RAS in GENERAL IMPLEMENTATION ISSUES 45this case is called the null-modem driver, and many users refer to this configu-ration as a null-modem connection. )Although oddly nonstandard, this handshake is very simple.Windows willsend the text string CLIENT and wait for a response.The peer device shouldanswer with CLIENTSERVER and a CR/LF sequence in order to start PPPrunning on the NT side.General Implementation IssuesSpecific PPP implementation techniques vary widely, but good PPP implementa-tions each have the following common attributes." The Robustness Principle.In RFC 791 (the Internet Protocol), Jon Postelwrote:In general, an implementation must be conservative in its sending behavior, andliberal in its receiving behavior.That is, it must be careful to send well-formeddatagrams, but must accept any datagram that it can interpret (e.g., not object totechnical errors where the meaning is still clear).This has been paraphrased as, Be liberal in what you expect and conserva-tive in what you send. This is the golden rule of network software design,and good implementations follow it.In particular, it is worthwhile to studythe various obsolete versions of a particular protocol before implementingit, including the Internet Drafts and obsoleted RFCs.Products often will bereleased that conform to these obsolete versions, and interoperability occa-sionally depends on behavior that is not documented in later versions.Evenmore important, following the protocol rule will allow your implementa-tion to interoperate with flawed peers.There are, sadly, many PPP imple-mentations in the world today that have glaring bugs.It is better for yourreputation if your implementation logs the error but continues to operate ina reasonable manner, if possible, rather than giving up." Resilience.PPP negotiation protocols have a variety of different field lengthvalues and restrictions on the values of certain other fields.Good imple-mentations will carefully check that these values are consistent with thetype of data received and the overall packet length before acting on thedata.It is quite common for errant PPP packages to send incorrect fieldlengths, and it is unfortunately more common for bad implementations tocrash when presented with such data. 46 PPP COMMUNICATION BASICS1 " Renegotiation.Any layer of the PPP protocol may be separately renegoti-2 ated at any time.Good implementations handle this gracefully and do not3 treat it as an error.In particular, options that require storage, such as data4 compression, will need to free the storage and reallocate it on successful5 renegotiation, and all options must be reset to default values.6 " Loop Avoidance.The standard PPP negotiation model can easily fall into7 nonconverging patterns, also called loops.Good implementations detect8 these loops by means of timers and counters.9 " Configurability.Good implementations permit each supported protocol to10 be disabled separately and any variables to be modified.A good implemen-11 tation should not rest simply on the PPP negotiation mechanism, since it is12 occasionally true that another implementation will properly negotiate an13 option but will not properly implement that option itself
[ Pobierz całość w formacie PDF ]
