diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/rfc1172.txt | 2312 | ||||
| -rw-r--r-- | doc/rfc1332.txt | 787 | ||||
| -rw-r--r-- | doc/rfc1334.txt | 899 | ||||
| -rw-r--r-- | doc/rfc1548.txt | 2971 | ||||
| -rw-r--r-- | doc/rfc1570.txt | 1057 | ||||
| -rw-r--r-- | doc/rfc1877.txt | 339 | ||||
| -rw-r--r-- | doc/rfc1962.txt | 507 | ||||
| -rw-r--r-- | doc/rfc1979.txt | 563 | ||||
| -rw-r--r-- | doc/rfc1994.txt | 732 | ||||
| -rw-r--r-- | doc/rfc2284.txt | 843 | ||||
| -rw-r--r-- | doc/rfc2433.txt | 1123 | ||||
| -rw-r--r-- | doc/rfc2637.txt | 3195 | ||||
| -rw-r--r-- | doc/rfc2716.txt | 1347 | ||||
| -rw-r--r-- | doc/rfc2759.txt | 1123 | ||||
| -rw-r--r-- | doc/rfc3078.txt | 675 | ||||
| -rw-r--r-- | doc/rfc3544.txt | 787 |
16 files changed, 19260 insertions, 0 deletions
diff --git a/doc/rfc1172.txt b/doc/rfc1172.txt new file mode 100644 index 00000000..53076407 --- /dev/null +++ b/doc/rfc1172.txt @@ -0,0 +1,2312 @@ + + + + + + +Network Working Group D. Perkins +Request for Comments: 1172 CMU + R. Hobby + UC Davis + July 1990 + + + + The Point-to-Point Protocol (PPP) Initial Configuration Options + + + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community. + + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + + This proposal is the product of the Point-to-Point Protocol Working + Group of the Internet Engineering Task Force (IETF). Comments on + this memo should be submitted to the IETF Point-to-Point Protocol + Working Group chair. + + Distribution of this memo is unlimited. + +Abstract + + The Point-to-Point Protocol (PPP) provides a method for transmitting + datagrams over serial point-to-point links. PPP is composed of + + 1) a method for encapsulating datagrams over serial links, + 2) an extensible Link Control Protocol (LCP), and + 3) a family of Network Control Protocols (NCP) for establishing + and configuring different network-layer protocols. + + The PPP encapsulating scheme, the basic LCP, and an NCP for + controlling and establishing the Internet Protocol (IP) (called the + IP Control Protocol, IPCP) are defined in The Point-to-Point Protocol + (PPP) [1]. + + This document defines the intial options used by the LCP and IPCP. It + also defines a method of Link Quality Monitoring and a simple + authentication scheme. + + + + + + +Perkins & Hobby [Page i] + +RFC 1172 PPP Initial Options July 1990 + + + Table of Contents + + + 1. Introduction .......................................... 1 + + 2. Link Control Protocol (LCP) Configuration Options ..... 1 + 2.1 Maximum-Receive-Unit ............................ 2 + 2.2 Async-Control-Character-Map ..................... 3 + 2.3 Authentication-Type ............................. 5 + 2.4 Magic-Number .................................... 7 + 2.5 Link-Quality-Monitoring ......................... 10 + 2.6 Protocol-Field-Compression ...................... 11 + 2.7 Address-and-Control-Field-Compression ........... 13 + + 3. Link Quality Monitoring ............................... 15 + 3.1 Design Motivation ............................... 15 + 3.2 Design Overview ................................. 15 + 3.3 Processes ....................................... 16 + 3.4 Counters ........................................ 18 + 3.5 Measurements, Calculations, State Variables ..... 19 + 3.6 Link-Quality-Report Packet Format ............... 21 + 3.7 Policy Suggestions .............................. 25 + 3.8 Example ......................................... 25 + + 4. Password Authentication Protocol ...................... 27 + 4.1 Packet Format ................................... 27 + 4.2 Authenticate .................................... 29 + 4.3 Authenticate-Ack ................................ 31 + 4.4 Authenticate-Nak ................................ 32 + + 5. IP Control Protocol (IPCP) Configuration Options ...... 33 + 5.1 IP-Addresses .................................... 34 + 5.2 Compression-Type ................................ 36 + + REFERENCES ................................................... 37 + + SECURITY CONSIDERATIONS ...................................... 37 + + AUTHOR'S ADDRESS ............................................. 37 + + + + + + + + + + + + +Perkins & Hobby [Page ii] + +RFC 1172 PPP Initial Options July 1990 + + +1. Introduction + + The Point-to-Point Protocol (PPP) [1] proposes a standard method of + encapsulating IP datagrams, and other Network Layer protocol + information, over point-to-point links. PPP also proposes an + extensible Option Negotiation Protocol. [1] specifies only the + protocol itself; the initial set of Configuration Options are + described in this document. These Configuration Options allow MTUs + to be changed, IP addresses to be dynamically assigned, header + compression to be enabled, and much more. + + This memo is divided into several sections. Section 2 describes + Configuration Options for the Link Control Protocol. Section 3 + specifies the use of the Link Quality Monitoring option. Section 4 + defines a simple Password Authentication Protocol. Finally, Section 5 + specifies Configuration Options for the IP Control Protocol. + +2. Link Control Protocol (LCP) Configuration Options + + As described in [1], LCP Configuration Options allow modifications to + the standard characteristics of a point-to-point link to be + negotiated. Negotiable modifications proposed in this document + include such things as the maximum receive unit, async control + character mapping, the link authentication method, etc. + + The initial proposed values for the LCP Configuration Option Type + field (see [1]) are assigned as follows: + + 1 Maximum-Receive-Unit + 2 Async-Control-Character-Map + 3 Authentication-Type + 4 NOT ASSIGNED + 5 Magic-Number + 6 Link-Quality-Monitoring + 7 Protocol-Field-Compression + 8 Address-and-Control-Field-Compression + + + + + + + + + + + + + + + +Perkins & Hobby [Page 1] + +RFC 1172 PPP Initial Options July 1990 + + +2.1. Maximum-Receive-Unit + + Description + + This Configuration Option provides a way to negotiate the maximum + packet size used across one direction of a link. By default, all + implementations must be able to receive frames with 1500 octets of + Information. + + This Configuration Option may be sent to inform the remote end + that you can receive larger frames, or to request that the remote + end send you smaller frames. If smaller frames are requested, an + implementation MUST still be able to receive 1500 octet frames in + case link synchronization is lost. + + A summary of the Maximum-Receive-Unit Configuration Option format is + shown below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Maximum-Receive-Unit | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 1 + + Length + + 4 + + Maximum-Receive-Unit + + The Maximum-Receive-Unit field is two octets and indicates the new + maximum receive unit. The Maximum-Receive-Unit covers only the + Data Link Layer Information field but not the header, trailer or + any transparency bits or bytes. + + Default + + 1500 + + + + + + + + + +Perkins & Hobby [Page 2] + +RFC 1172 PPP Initial Options July 1990 + + +2.2. Async-Control-Character-Map + + Description + + This Configuration Option provides a way to negotiate the use of + control character mapping on asynchronous links. By default, PPP + maps all control characters into an appropriate two character + sequence. However, it is rarely necessary to map all control + characters and often times it is unnecessary to map any + characters. A PPP implementation may use this Configuration + Option to inform the remote end which control characters must + remain mapped and which control characters need not remain mapped + when the remote end sends them. The remote end may still send + these control characters in mapped format if it is necessary + because of constraints at its (the remote) end. This option does + not solve problems for communications links that can send only 7- + bit characters or that can not send all non-control characters. + + There may be some use of synchronous-to-asynchronous converters + (some built into modems) in Point-to-point links resulting in a + synchronous PPP implementation on one end of a link and an + asynchronous implemention on the other. It is the responsibility + of the converter to do all mapping conversions during operation. + To enable this functionality, synchronous PPP implementations MUST + always accept a Async-Control-Character-Map Configuration Option + (it MUST always respond to an LCP Configure-Request specifying + this Configuration Option with an LCP Configure-Ack). However, + acceptance of this Configuration Option does not imply that the + synchronous implementation will do any character mapping, since + synchronous PPP uses bit-stuffing rather than character-stuffing. + Instead, all such character mapping will be performed by the + asynchronous-to-synchronous converter. + + A summary of the Async-Control-Character-Map Configuration Option + format is shown below. The fields are transmitted from left to + right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Async-Control-Character-Map + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 2 + + + +Perkins & Hobby [Page 3] + +RFC 1172 PPP Initial Options July 1990 + + + Length + + 6 + + Async-Control-Character-Map + + The Async-Control-Character-Map field is four octets and indicates + the new async control character map. The map is encoded in big- + endian fashion where each numbered bit corresponds to the ASCII + control character of the same value. If the bit is cleared to + zero, then that ASCII control character need not be mapped. If + the bit is set to one, then that ASCII control character must + remain mapped. E.g., if bit 19 is set to zero, then the ASCII + control character 19 (DC3, Control-S) may be sent in the clear. + + Default + + All ones (0xffffffff). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 4] + +RFC 1172 PPP Initial Options July 1990 + + +2.3. Authentication-Type + + Description + + On some links it may be desirable to require a peer to + authenticate itself before allowing Network Layer protocol data to + be exchanged. This Configuration Option provides a way to + negotiate the use of a specific authentication protocol. By + default, authentication is not necessary. If an implementation + requires that the remote end authenticate with some specific + authentication protocol, then it should negotiate the use of that + authentication protocol with this Configuration Option. + + Successful negotiation of the Authentication-Type option adds an + additional Authentication phase to the Link Control Protocol. + This phase is after the Link Quality Determination phase, and + before the Network Layer Protocol Configuration Negotiation phase. + Advancement from the Authentication phase to the Network Layer + Protocol Configuration Negotiation phase may not occur until the + peer is successfully authenticated using the negotiated + authentication protocol. + + An implementation may allow the remote end to pick from more than + one authentication protocol. To achieve this, it may include + multiple Authentication-Type Configuration Options in its + Configure-Request packets. An implementation receiving a + Configure-Request specifying multiple Authentication-Types may + accept at most one of the negotiable authentication protocols and + should send a Configure-Reject specifying all of the other + specified authentication protocols. + + It is recommended that each PPP implementation support + configuration of authentication parameters at least on a per- + interface basis, if not a per peer entity basis. The parameters + should specify which authetication techniques are minimally + required as a prerequisite to establishment of a PPP connection, + either for the specified interface or for the specified peer + entity. Such configuration facilities are necessary to prevent an + attacker from negotiating a reduced security authentication + protocol, or no authentication at all, in an attempt to circumvent + this authentication facility. + + If an implementation sends a Configure-Ack with this Configuration + Option, then it is agreeing to authenticate with the specified + protocol. An implementation receiving a Configure-Ack with this + Configuration Option should expect the remote end to authenticate + with the acknowledged protocol. + + + + +Perkins & Hobby [Page 5] + +RFC 1172 PPP Initial Options July 1990 + + + There is no requirement that authentication be full duplex or that + the same authentication protocol be used in both directions. It + is perfectly acceptable for different authentication protocols to + be used in each direction. This will, of course, depend on the + specific authentication protocols negotiated. + + This document defines a simple Password Authentication Protocol in + Section 4. Development of other more secure protocols is + encouraged. + + A summary of the Authentication-Type Configuration Option format is + shown below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Authentication-Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Type + + 3 + + Length + + >= 4 + + Authentication-Type + + The Authentication-Type field is two octets and indicates the type + of authentication protocol desired. Values for the + Authentication-Type are always the same as the PPP Data Link Layer + Protocol field values for that same authentication protocol. The + most up-to-date values of the Authentication-Type field are + specified in "Assigned Numbers" [2]. Initial values are assigned + as follows: + + Value (in hex) Protocol + + c023 Password Authentication Protocol + + Data + + The Data field is zero or more octets and contains additional data + as determined by the particular authentication protocol. + + + + +Perkins & Hobby [Page 6] + +RFC 1172 PPP Initial Options July 1990 + + + Default + + No authentication protocol necessary. + + +2.4. Magic-Number + + Description + + This Configuration Option provides a way to detect looped-back + links and other Data Link Layer anomalies. This Configuration + Option may be required by some other Configuration Options such as + the Link-Quality-Monitoring Configuration Option. + + Before this Configuration Option is requested, an implementation + must choose its Magic-Number. It is recommended that the Magic- + Number be chosen in the most random manner possible in order to + guarantee with very high probability that an implementation will + arrive at a unique number. A good way to choose a unique random + number is to start with an unique seed. Suggested sources of + uniqueness include machine serial numbers, other network hardware + addresses, time-of-day clocks, etc. Particularly good random + number seeds are precise measurements of the inter-arrival time of + physical events such as packet reception on other connected + networks, server response time, or the typing rate of a human + user. It is also suggested that as many sources as possible be + used simultaneously. + + When a Configure-Request is received with a Magic-Number + Configuration Option, the received Magic-Number should be compared + with the Magic-Number of the last Configure-Request sent to the + peer. If the two Magic-Numbers are different, then the link is + not looped-back, and the Magic-Number should be acknowledged. If + the two Magic-Numbers are equal, then it is possible, but not + certain, that the link is looped-back and that this Configure- + Request is actually the one last sent. To determine this, a + Configure-Nak should be sent specifying a different Magic-Number + value. A new Configure-Request should not be sent to the peer + until normal processing would cause it to be sent (i.e., until a + Configure-Nak is received or the Restart timer runs out). + + Reception of a Configure-Nak with a Magic-Number different from + that of the last Configure-Nak sent to the peer proves that a link + is not looped-back, and indicates a unique Magic-Number. If the + Magic-Number is equal to the one sent in the last Configure-Nak, + the possibility of a loop-back is increased, and a new Magic- + Number should be chosen. In either case, a new Configure-Request + should be sent with the new Magic-Number. + + + +Perkins & Hobby [Page 7] + +RFC 1172 PPP Initial Options July 1990 + + + If the link is indeed looped-back, this sequence (transmit + Configure-Request, receive Configure-Request, transmit Configure- + Nak, receive Configure-Nak) will repeat over and over again. If + the link is not looped-back, this sequence may occur a few times, + but it is extremely unlikely to occur repeatedly. More likely, + the Magic-Numbers chosen at either end will quickly diverge, + terminating the sequence. The following table shows the + probability of collisions assuming that both ends of the link + select Magic-Numbers with a perfectly uniform distribution: + + Number of Collisions Probability + -------------------- --------------------- + 1 1/2**32 = 2.3 E-10 + 2 1/2**32**2 = 5.4 E-20 + 3 1/2**32**3 = 1.3 E-29 + + Good sources of uniqueness or randomness are required for this + divergence to occur. If a good source of uniqueness cannot be + found, it is recommended that this Configuration Option not be + enabled; Configure-Requests with the option should not be + transmitted and any Magic-Number Configuration Options which the + peer sends should be either acknowledged or rejected. In this + case, loop-backs cannot be reliably detected by the + implementation, although they may still be detectable by the peer. + + If an implementation does transmit a Configure-Request with a + Magic-Number Configuration Option, then it MUST NOT respond with a + Configure-Reject if its peer also transmits a Configure-Request + with a Magic-Number Configuration Option. That is, if an + implementation desires to use Magic Numbers, then it MUST also + allow its peer to do so. If an implementation does receive a + Configure-Reject in response to a Configure-Request, it can only + mean that the link is not looped-back, and that its peer will not + be using Magic-Numbers. In this case, an implementation may act + as if the negotiation had been successful (as if it had instead + received a Configure-Ack). + + The Magic-Number also may be used to detect looped-back links + during normal operation as well as during Configuration Option + negotiation. All Echo-Request, Echo-Reply, Discard-Request, and + Link-Quality-Report LCP packets have a Magic-Number field which + MUST normally be transmitted as zero, and MUST normally be ignored + on reception. However, once a Magic-Number has been successfully + negotiated, an LCP implementation MUST begin transmitting these + packets with the Magic-Number field set to its negotiated Magic- + Number. Additionally, the Magic-Number field of these packets may + be inspected on reception. All received Magic-Number fields should + be equal to either zero or the peer's unique Magic-Number, + + + +Perkins & Hobby [Page 8] + +RFC 1172 PPP Initial Options July 1990 + + + depending on whether or not the peer negotiated one. Reception of + a Magic-Number field equal to the negotiated local Magic-Number + indicates a looped-back link. Reception of a Magic-Number other + than the negotiated local Magic-Number or or the peer's negotiated + Magic-Number, or zero if the peer didn't negotiate one, indicates + a link which has been (mis)configured for communications with a + different peer. + + Procedures for recovery from either case are unspecified and may + vary from implementation to implementation. A somewhat + pessimistic procedure is to assume an LCP Physical-Layer-Down + event and make an immediate transition to the Closed state. A + further Active-Open event will begin the process of re- + establishing the link, which can't complete until the loop-back + condition is terminated and Magic-Numbers are successfully + negotiated. A more optimistic procedure (in the case of a loop- + back) is to begin transmitting LCP Echo-Request packets until an + appropriate Echo-Reply is received, indicating a termination of + the loop-back condition. + + A summary of the Magic-Number Configuration Option format is shown + below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Magic-Number + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Magic-Number (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 5 + + Length + + 6 + + Magic-Number + + The Magic-Number field is four octets and indicates a number which + is very likely to be unique to one end of the link. A Magic- + Number of zero is illegal and must not be sent. + + Default + + None. + + + +Perkins & Hobby [Page 9] + +RFC 1172 PPP Initial Options July 1990 + + +2.5. Link-Quality-Monitoring + + Description + + On some links it may be desirable to determine when, and how + often, the link is dropping data. This process is called Link + Quality Monitoring and is implemented by periodically transmitting + Link-Quality-Report packets as described in Section 3. The Link- + Quality-Monitoring Configuration Option provides a way to enable + the use of Link-Quality-Report packets, and also to negotiate the + rate at which they are transmitted. By default, Link Quality + Monitoring and the use of Link-Quality-Report packets is disabled. + + A summary of the Link-Quality-Monitoring Configuration Option format + is shown below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Reporting-Period + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Reporting-Period (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 6 + + Length + + 6 + + Reporting-Period + + The Reporting-Period field is four octets and indicates the + maximum time in micro-seconds that the remote end should wait + between transmission of LCP Link-Quality-Report packets. A value + of zero is illegal and should always be nak'd or rejected. An LCP + implementation is always free to transmit LCP Link-Quality-Report + packets at a faster rate than that which was requested by, and + acknowledged to, the remote end. + + Default + + None + + + + + + +Perkins & Hobby [Page 10] + +RFC 1172 PPP Initial Options July 1990 + + +2.6. Protocol-Field-Compression + + Description + + This Configuration Option provides a way to negotiate the + compression of the Data Link Layer Protocol field. By default, + all implementations must transmit standard PPP frames with two + octet Protocol fields. However, PPP Protocol field numbers are + chosen such that some values may be compressed into a single octet + form which is clearly distinguishable from the two octet form. + This Configuration Option may be sent to inform the remote end + that you can receive compressed single octet Protocol fields. + Compressed Protocol fields may not be transmitted unless this + Configuration Option has been received. + + As previously mentioned, the Protocol field uses an extension + mechanism consistent with the ISO 3309 extension mechanism for the + Address field; the Least Significant Bit (LSB) of each octet is + used to indicate extension of the Protocol field. A binary "0" as + the LSB indicates that the Protocol field continues with the + following octet. The presence of a binary "1" as the LSB marks + the last octet of the Protocol field. Notice that any number of + "0" octets may be prepended to the field, and will still indicate + the same value (consider the two representations for 3, 00000011 + and 00000000 00000011). + + In the interest of simplicity, the standard PPP frame uses this + fact and always sends Protocol fields with a two octet + representation. Protocol field values less than 256 (decimal) are + prepended with a single zero octet even though transmission of + this, the zero and most significant octet, is unnecessary. + + However, when using low speed links, it is desirable to conserve + bandwidth by sending as little redundant data as possible. The + Protocol Compression Configuration Option allows a trade-off + between implementation simplicity and bandwidth efficiency. If + successfully negotiated, the ISO 3309 extension mechanism may be + used to compress the Protocol field to one octet instead of two. + The large majority of frames are compressible since data protocols + are typically assigned with Protocol field values less than 256. + + To guarantee unambiguous recognition of LCP packets, the Protocol + field must never be compressed when sending any LCP packet. In + addition, PPP implementations must continue to be robust and MUST + accept PPP frames with double-octet, as well as single-octet, + Protocol fields, and MUST NOT distinguish between them. + + When a Protocol field is compressed, the Data Link Layer FCS field + + + +Perkins & Hobby [Page 11] + +RFC 1172 PPP Initial Options July 1990 + + + is calculated on the compressed frame, not the original + uncompressed frame. + + A summary of the Protocol-Field-Compression Configuration Option + format is shown below. The fields are transmitted from left to + right. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 7 + + Length + + 2 + + Default + + Disabled. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 12] + +RFC 1172 PPP Initial Options July 1990 + + +2.7. Address-and-Control-Field-Compression + + Description + + This Configuration Option provides a way to negotiate the + compression of the Data Link Layer Address and Control fields. By + default all implementations must transmit frames with Address and + Control fields and must use the hexadecimal values 0xff and 0x03 + respectively. Since these fields have constant values, they are + easily compressed. this Configuration Option may be used to + inform the remote end that you can receive compressed Address and + Control fields. + + Compressed Address and Control fields are formed by simply + omitting them in all non-ambiguous cases. Ambiguous frames may + not be compressed. Ambiguous cases result when the two octets + following the Address and Control fields have values that could be + interpreted as valid Address and Control fields (i.e., 0xff, + 0x03). This can happen when Protocol-Field-Compression is enabled + and the Protocol field is compressed to one octet. If the + Protocol value is 0xff, and the first octet of the Information + field is 0x03, the result is ambiguous and the Address and Control + fields must not be compressed on transmission. + + On reception, the Address and Control fields are decompressed by + examining the first two octets. If they contain the values 0xff + and 0x03, they are assumed to be the Address and Control fields. + If not, it is assumed that the fields were compressed and were not + transmitted. + + One additional case in which the Address and Control fields must + never be compressed is when sending any LCP packet. This rule + guarantees unambiguous recognition of LCP packets. + + When the Address and Control fields are compressed, the Data Link + Layer FCS field is calculated on the compressed frame, not the + original uncompressed frame. + + A summary of the Address-and-Control-Field-Compression configuration + option format is shown below. The fields are transmitted from left + to right. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Perkins & Hobby [Page 13] + +RFC 1172 PPP Initial Options July 1990 + + + Type + + 8 + + Length + + 2 + + Default + + Not compressed. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 14] + +RFC 1172 PPP Initial Options July 1990 + + +3. Link Quality Monitoring + + Data communications links are rarely perfect. Packets can be dropped + or corrupted for various reasons (line noise, equipment failure, + buffer overruns, etc.). Sometimes, it is desirable to determine + when, and how often, the link is dropping data. Routers, for + example, may want to temporarily allow another route to take + precedence. An implementation may also have the option of + disconnecting and switching to an alternate link. The process of + determining data loss is called "Link Quality Monitoring". + +3.1. Design Motivation + + There are many different ways to measure link quality, and even more + ways to react to it. Rather than specifying a single scheme, Link + Quality Monitoring is divided into a "mechanism" and a "policy". PPP + fully specifies the "mechanism" for Link Quality Monitoring by + defining the LCP Link-Quality-Report (LQR) packet and specifying a + procedure for its use. PPP does NOT specify a Link Quality + Monitoring "policy" -- how to judge link quality or what to do when + it is inadequate. That is left as an implementation decision, and + can be different at each end of the link. Implementations are + allowed, and even encouraged, to experiment with various link quality + policies. The Link Quality Monitoring mechanism specification + insures that two implementations with different policies may + communicate and interoperate. + + To allow flexible policies to be implemented, the PPP Link Quality + Monitoring mechanism measures data loss in units of packets, octets, + and Link-Quality-Reports. Each measurement is made separately for + each half of the link, both inbound and outbound. All measurements + are communicated to both ends of the link so that each end of the + link can implement its own link quality policy for both its outbound + and inbound links. + + Finally, the Link Quality Monitoring protocol is designed to be + implementable on many different kinds of systems. Although it may be + common to implement PPP (and especially Link Quality Monitoring) as a + single software process, multi-process implementations with hardware + support are also envisioned. The PPP Link Quality Monitoring + mechanism provides for this by careful definition of the Link- + Quality-Report packet format, and by specifiying reference points for + all data transmission and reception measurements. + +3.2. Design Overview + + Each Link Quality Monitoring implementation maintains counts of the + number of packets and octets transmitted and successfully received, + + + +Perkins & Hobby [Page 15] + +RFC 1172 PPP Initial Options July 1990 + + + and periodically transmits this information to its peer in a Link- + Quality-Report packet. These packets contain three sections: a + Header section, a Counters section, and a Measurements section. + + The Header section of the packet consists of the normal LCP Link + Maintenance packet header including Code, Identifier, Length and + Magic-Number fields. + + The Counters section of the packet consists of four counters, and + provides the information necessary to measure the quality of the + link. The LQR transmitter fills in two of these counters: Out-Tx- + Packets-Ctr and Out-Tx-Octets-Ctr (described later). The LQR + receiver fills in the two remaining counters: In-Rx-Packets-Ctr and + In-Rx-Octets-Ctr (described later). These counters are similar to + sequence numbers; they are constantly increasing to give a "relative" + indication of the number of packets and octets communicated across + the outbound link. By comparing the values in successive Link- + Quality-Reports, an LQR receiver can compute the "absolute" number of + packets and octets communicated across its inbound link. Comparing + these absolute numbers then gives an indication of an inbound link's + quality. Relative numbers, rather than absolute, are transmitted + because they greatly simplify link synchronization; an implementation + merely waits to receive two LQR packets. + + The Measurements section of the packet consists of six state + variables: In-Tx-LQRs, Last-In-Id, In-Tx-Packets, In-Tx-Octets, In- + Rx-Packets, and In-Rx-Octets (described later). This section allows + an implementation to report inbound link quality measurements to its + peer (for which the report will instead indicate outbound link + quality) by transmitting the absolute, rather than relative, number + of LQRs, packets, and octets communicated across the inbound link. + These values are calculated by observing the Counters section of the + Link-Quality-Report packets received on the inbound link. Absolute + numbers may be used in this section without synchronization problems + because it is necessary to receive only one LQR packet to have valid + information. + + Link Quality Monitoring is described in more detail in the following + sections. First, a description of the processes comprising the Link + Quality Monitoring mechanism is presented. This is followed by the + packet and byte counters maintained; the measurements, calculations, + and state variables used; the format of the Link-Quality-Report + packet; some policy suggestions; and, finally, an example link + quality calculation. + +3.3. Processes + + The PPP Link Quality Monitoring mechanism is described using a + + + +Perkins & Hobby [Page 16] + +RFC 1172 PPP Initial Options July 1990 + + + "logical process" model. As shown below, there are five logical + processes duplicated at each end of the duplex link. + + +---------+ +-------+ +----+ Outbound + | |-->| Mux |-->| Tx |=========> + | Link- | +-------+ +----+ + | Manager | + | | +-------+ +----+ Inbound + | |<--| Demux |<--| Rx |<========= + +---------+ +-------+ +----+ + + Link-Manager + + The Link-Manager process transmits and receives Link-Quality- + Reports, and implements the desired link quality policy. LQR + packets are transmitted at a constant rate, which is negotiated by + the LCP Link-Quality-Monitoring Configuration Option. The Link- + Manager process fills in only the Header and Measurements sections + of the packet; the Counters section of the packet is filled in by + the Tx and Rx processes. + + Mux + + The Mux process multiplexes packets from the various protocols + (e.g., LCP, IP, XNS, etc.) into a single, sequential, and + prioritized stream of packets. Link-Quality-Report packets MUST + be given the highest possible priority to insure that link quality + information is communicated in a timely manner. + + Tx + + The Tx process maintains the counters Out-Tx-Packets-Ctr and Out- + Tx-Octets-Ctr which are used to measure the amount of data which + is transmitted on the outbound link. When Tx processes a Link- + Quality-Report packet, it inserts the values of these counters + into the Counters section of the packet. Because these counters + represent relative, rather than absolute, values, the question of + when to update the counters, before or after they are inserted + into a Link-Quality-Report packet, is left as an implementation + decision. However, an implementation MUST make this decision the + same way every time. The Tx process MUST follow the Mux process + so that packets are counted in the order transmitted to the link. + + Rx + + The Rx process maintains the counters In-Rx-Packets-Ctr and In- + Rx-Octets-Ctr which are used to measure the amount of data which + is received by the inbound link. When Rx processes a Link- + + + +Perkins & Hobby [Page 17] + +RFC 1172 PPP Initial Options July 1990 + + + Quality-Report packet, it inserts the values of these counters + into the Counters section of the packet. Again, the question of + when to update the counters, before or after they are inserted + into a Link-Quality-Report packet, is left as an implementation + decision which MUST be made consistently the same way. + + Demux + + The Demux process demultiplexes packets for the various protocols. + The Demux process MUST follow the Rx process so that packets are + counted in the order received from the link. + +3.4. Counters + + In order to fill in the Counters section of a Link-Quality-Report + packet, Link Quality Monitoring requires the implementation of one + 8-bit unsigned, and four 32-bit unsigned, monotonically increasing + counters. These counters may be reset to any initial value before + the first Link-Quality-Report is transmitted, but MUST NOT be reset + again until LCP has left the Open state. Counters wrap to zero when + their maximum value is reached (for 32 bit counters: 0xffffffff + 1 = + 0). + + Out-Identifier-Ctr + + Out-Identifier-Ctr is an 8-bit counter maintained by the Link- + Manager process which increases by one for each transmitted Link- + Quality-Report packet. + + Out-Tx-Packets-Ctr + + Out-Tx-Packets-Ctr is a 32-bit counter maintained by the Tx + process which increases by one for each transmitted Data Link + Layer packet. + + Out-Tx-Octets-Ctr + + Out-Tx-Octets-Ctr is a 32-bit counter maintained by the Tx process + which increases by one for each octet in a transmitted Data Link + Layer packet. All octets which are included in the FCS + calculation MUST be counted, as should the FCS octets themselves. + All other octets MUST NOT be counted. + + In-Rx-Packets-Ctr + + In-Rx-Packets-Ctr is a 32-bit counter maintained by the Rx process + which increases by one for each successfully received Data Link + Layer packet. Packets with incorrect FCS fields or other problems + + + +Perkins & Hobby [Page 18] + +RFC 1172 PPP Initial Options July 1990 + + + MUST not be counted. + + In-Rx-Octets-Ctr + + In-Rx-Octets-Ctr is a 32-bit counter maintained by the Rx process + which increases by one for each octet in a successfully received + Data Link Layer packet. All octets which are included in an FCS + calculation MUST be counted, as should the FCS octets themselves. + All other octets MUST NOT be counted. + +3.5. Measurements, Calculations, State Variables + + In order to fill in the Measurements section of a Link-Quality-Report + packet, Link Quality Monitoring requires the Link-Manager process to + make a number of calculations and keep a number of state variables. + These calculations are made, and these state variables updated, each + time a Link-Quality-Report packet is received from the inbound link. + + In-Tx-LQRs + + In-Tx-LQRs is an 8-bit state variable which indicates the number + of Link-Quality-Report packets which the peer had to transmit in + order for the local end to receive exactly one LQR. In-Tx-LQRs + defines the length of the "period" over which In-Tx-Packets, In- + Tx-Octets, In-Rx-Packets, and In-Rx-Octets were measured. In-Tx- + LQRs is calculated by subtracting Last-In-Id from the received + Identifier. If more than 255 LQRs in a row are lost, In-Tx-LQRs + will be ambiguous since the Identifier field and all state + variables based on it are only 8 bits. It is assumed that the + Link Quality Monitoring policy will be robust enough to handle + this case (it should probably close down the link long before this + happens). + + Last-In-Id + + Last-In-Id is an 8-bit state variable which stores the value of + the last received Identifier. Last-In-Id should be updated after + In-Tx-LQRs has been calculated. + + In-Tx-Packets + + In-Tx-Packets is a 32-bit state variable which indicates the + number of packets which were transmitted on the inbound link + during the last period. In-Tx-Packets is calculated by + subtracting Last-Out-Tx-Packets-Ctr from the received Out-Tx- + Packets-Ctr. + + + + + +Perkins & Hobby [Page 19] + +RFC 1172 PPP Initial Options July 1990 + + + Last-Out-Tx-Packets-Ctr + + Last-Out-Tx-Packets-Ctr is a 32-bit state variable which stores + the value of the last received Out-Tx-Packets-Ctr. Last-Out-Tx- + Packets-Ctr should be updated after In-Tx-Packets has been + calculated. + + In-Tx-Octets + + In-Tx-Octets is a 32-bit state variable which indicates the number + of octets which were transmitted on the inbound link during the + last period. In-Tx-Octets is calculated by subtracting Last-Out- + Tx-Octets-Ctr from the received Out-Tx-Octets-Ctr. + + Last-Out-Tx-Octets-Ctr + + Last-Out-Tx-Octets-Ctr is a 32-bit state variable which stores the + value of the last received Out-Tx-Octets-Ctr. Last-Out-Tx- + Octets-Ctr should be updated after In-Tx-Octets has been + calculated. + + In-Rx-Packets + + In-Rx-Packets is a 32-bit state variable which indicates the + number of packets which were received on the inbound link during + the last period. In-Rx-Packets is calculated by subtracting + Last-In-Rx-Packets-Ctr from the received In-Rx-Packets-Ctr. + + Last-In-Rx-Packets-Ctr + + Last-In-Rx-Packets-Ctr is a 32-bit state variable which stores the + value of the last received In-Rx-Packets-Ctr. Last-In-Rx- + Packets-Ctr should be updated after In-Rx-Packets has been + calculated. + + In-Rx-Octets + + In-Rx-Octets is a 32-bit state variable which indicates the number + of octets which were received on the inbound link during the last + period. In-Rx-Octets is calculated by subtracting Last-In-Rx- + Octets-Ctr from the received In-Rx-Octets-Ctr. + + Last-In-Rx-Octets-Ctr + + Last-In-Rx-Octets-Ctr is a 32-bit state variable which stores the + value of the last received In-Rx-Octets-Ctr. Last-In-Rx-Octets- + Ctr should be updated after In-Rx-Octets has been calculated. + + + + +Perkins & Hobby [Page 20] + +RFC 1172 PPP Initial Options July 1990 + + + Measurements-Valid + + Measurements-Valid is a 1-bit boolean state variable which + indicates whether or not the In-Tx-Packets, In-Tx-Octets, In-Rx- + Packets, and In-Rx-Octets state variables contain valid + measurements. These measurements cannot be considered valid until + two or more Link-Quality-Report packets have been received on the + inbound link. This bit should be reset when LCP reaches the Open + state and should be set after the receipt of exactly two LQRs. + +3.6. Link-Quality-Report Packet Format + + A Summary of the Link-Quality-Report packet format is shown below. + The fields are transmitted from left to right. The Code, Identifier, + Length, and Magic-Number fields make up the normal LCP Link + Maintenance packet header; the In-Tx-LQRS, Last-In-Id, V, In-Tx- + Packets, In-Tx-Octets, In-Rx-Packets, In-Rx-Octets fields contain + digested absolute measurements; and the Out-Tx-Packets-Ctr, Out-Tx- + Octets-Ctr, In-Rx-Packets-Ctr, and In-Rx-Octets-Ctr fields contain + raw relative counts. Note that as transmitted over the link, this + packet format does not include the In-Rx-Packets-Ctr and In-Rx- + Octets-Ctr fields which are logically appended to the packet by the + Rx process after reception on the inbound link. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 21] + +RFC 1172 PPP Initial Options July 1990 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic-Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | In-Tx-LQRs | Last-In-Id | Reserved |V| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | In-Tx-Packets | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | In-Tx-Octets | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | In-Rx-Packets | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | In-Rx-Octets | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Out-Tx-Packets-Ctr | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Out-Tx-Octets-Ctr | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / + / + / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | In-Rx-Packets-Ctr | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | In-Rx-Octets-Ctr | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code + + 12 for Link-Quality-Report. + + Identifier + + The Identifier field is one octet and indicates the sequence + number for this Link-Quality-Report. The Identifier field is + copied from the Out-Identifier-Ctr counter on transmission. On + reception, the Identifier field is used to calculate In-Tx-LQRs + and is then stored in Last-In-Id. + + The Link-Quality-Report Identifier sequence number space MUST be + separate from that of all other LCP packets; for example, + transmission of an LCP Echo-Request must not cause the Out- + Identifier-Ctr counter to be incremented. + + + + + +Perkins & Hobby [Page 22] + +RFC 1172 PPP Initial Options July 1990 + + + Length + + The Length field is two octets and indicates the length of the LQM + packet including the Code, Identifier, Length and all defined + fields. Octets outside the range of the length field should be + treated as Data Link Layer padding and should be ignored on + reception. In order for the correct In-Tx-Octets and In-Rx-Octets + values to be calculated, Link-Quality-Reports MUST be consistently + transmitted with the same amount of padding. + + Magic-Number + + The Magic-Number field is four octets and aids in detecting + looped-back links. Unless modified by a Configuration Option, the + Magic-Number MUST always be transmitted as zero and MUST always be + ignored on reception. If Magic-Numbers have been negotiated, + incoming LQM packets should be checked to make sure that the local + end is not seeing its own Magic-Number and thus a looped-back + link. + + In-Tx-LQRs + + The In-Tx-LQRs field is one octet and indicates the number of + periods covered by the Measurements section of this Link-Quality- + Report. The In-Tx-LQRs field is copied from the In-Tx-LQRs state + variable on transmission. + + Last-In-Id + + The Prev-In-Id field is one octet and indicates the age of the + Measurements section of this Link-Quality-Report. The Last-In-Id + field is copied from the Last-In-Id field on transmission. On + reception, the Last-In-Id field may be compared with the Out- + Identifier-Ctr to determine how many, if any, outbound Link- + Quality-Reports have been lost. + + V + + The V field is 1 bit and indicates whether or not the Measurements + section of this Link-Quality-Report is valid. The V field is + copied from the Measurements-Valid state variable on transmission. + If the V field is not set to 1, then the In-Tx-LQRs, Last-In-Id, + In-Tx-Packets, In-Tx-Octets, In-Rx-Packets and In-Rx-Octets fields + should be ignored. + + Reserved + + The Reserved field is 15 bits and is intended to pad the remaining + + + +Perkins & Hobby [Page 23] + +RFC 1172 PPP Initial Options July 1990 + + + packet fields to even four-octet boundaries for the convenience of + hardware implementations. The Reserved field should always be + transmitted as zero and ignored on reception. + + In-Tx-Packets + + The In-Tx-Packets field is four octets and indicates the number of + packets transmitted on the inbound link of the Link-Quality-Report + transmitter during the last measured period. The In-Tx-Packets + field is copied from the In-Tx-Packets state variable on + transmission. + + In-Tx-Octets + + The In-Tx-Octets field is four octets and indicates the number of + octets transmitted on the inbound link of the Link-Quality-Report + transmitter during the last measured period. The In-Tx-Octets + field is copied from the In-Tx-Octets state variable on + transmission. + + In-Rx-Packets + + The In-Rx-Packets field is four octets and indicates the number of + packets received on the inbound link of the Link-Quality-Report + transmitter during the last measured period. The In-Rx-Packets + field is copied from the In-Rx-Packets state variable on + transmission. + + In-Rx-Octets + + The In-Rx-Octets field is four octets and indicates the number of + octets received on the inbound link of the Link-Quality-Report + transmitter during the last measured period. The In-Rx-Octets + field is copied from the In-Rx-Octets state variable on + transmission. + + Out-Tx-Packets + + The Out-Tx-Packets field is four octets and is used to calculate + the number of packets transmitted on the outbound link of the + Link-Quality-Report transmitter during a period. The Out-Tx- + Packets field is copied from the Out-Tx-Packets-Ctr counter on + transmission. + + Out-Tx-Octets + + The Out-Tx-Octets field is four octets and is used to calculate + the number of octets transmitted on the outbound link of the + + + +Perkins & Hobby [Page 24] + +RFC 1172 PPP Initial Options July 1990 + + + Link-Quality-Report transmitter during a period. The Out-Tx- + Octets field is copied from the Out-Tx-Octets-Ctr counter on + transmission. + + In-Rx-Packets + + The In-Rx-Packets field is four octets and is used to calculate + the number of packets received on the inbound link of the Link- + Quality-Report receiver during a period. The In-Rx-Packets field + is copied from the In-Rx-Packets-Ctr counter on reception. The + In-Rx-Packets is not shown because it is not actually transmitted + over the link. Rather, it is logically appended (in an + implementation dependent manner) to the packet by the + implementation's Rx process. + + In-Rx-Octets + + The In-Rx-Octets field is four octets and is used to calculate the + number of octets received on the inbound link of the Link- + Quality-Report receiver during a period. The In-Rx-Octets field + is copied from the In-Rx-Octets-Ctr counter on reception. The + In-Rx-Octets is not shown because it is not actually transmitted + over the link. Rather, it is logically appended (in an + implementation dependent manner) to the packet by the + implementation's Rx process. + +3.7. Policy Suggestions + + Link-Quality-Report packets provide a mechanism to determine the link + quality, but it is up to each implementation to decide when the link + is usable. It is recommended that this policy implement some amount + of hysteresis so that the link does not bounce up and down. A + particularly good policy is to use a K out of N algorithm. In such + an algorithm, there must be K successes out of the last N periods for + the link to be considered of good quality. + + Procedures for recovery from poor quality links are unspecified and + may vary from implementation to implementation. A suggested approach + is to immediately close all other Network-Layer protocols (i.e., + cause IPCP to transmit a Terminate-Req), but to continue transmitting + Link-Quality-Reports. Once the link quality again reaches an + acceptable level, Network-Layer protocols can be reconfigured. + +3.8. Example + + An example may be helpful. Assume that Link-Manager implementation A + transmits a Link-Quality-Report which is received by Link-Manager + implementation B at time t0 with the following values: + + + +Perkins & Hobby [Page 25] + +RFC 1172 PPP Initial Options July 1990 + + + Out-Tx-Packets 5 + Out-Tx-Octets 100 + In-Rx-Packets 3 + In-Rx-Octets 70 + + Assume that A then transmits 20 IP packets with 200 octets, of which + 15 packets and 150 octets are received by B. At time t1, A transmits + another LQR which is received by B as follows: + + Out-Tx-Packets 26 (5 old, plus 20 IP, plus 1 LQR) + Out-Tx-Octets 342 (42 for LQR) + In-Rx-Packets 19 + In-Rx-Octets 262 + + Implementation B can now calculate the number of packets and octets + transmitted, received and lost on its inbound link as follows: + + In-Tx-Packets = 26 - 5 = 21 + In-Tx-Octets = 342 - 100 = 242 + In-Rx-Packets = 10 - 3 = 16 + In-Rx-Octets = 262 - 70 = 192 + In-Lost-Packets = 21 - 16 = 5 + In-Lost-Octets = 242 - 192 = 50 + + After doing these calculations, B evaluates the measurements in what + ever way its implemented policy specifies. Also, the next time that + B transmits an LQR to A, it will report these values in the + Measurements section, thereby allowing A to evaluate these same + measurements. + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 26] + +RFC 1172 PPP Initial Options July 1990 + + +4. Password Authentication Protocol + + The Password Authentication Protocol (PAP) may be used to + authenticate a peer by verifying the identity of the remote end of + the link. Use of the PAP must first be negotiated using the LCP + Authentication-Type Configuration Option. Successful negotiation + adds an additional Authentication phase to the Link Control Protocol, + after the Link Quality Determination phase, and before the Network + Layer Protocol Configuration Negotiation phase. PAP packets received + before the Authentication phase is reached should be silently + discarded. The Authentication phase is exited once an Authenticate- + Ack packet is sent or received. + + PAP is intended for use primarily by hosts and routers that connect + via switched circuits or dial-up lines to a PPP network server. The + server can then use the identification of the connecting host or + router in the selection of options for network layer negotiations or + failing authentication, drop the connection. + + Note that PAP is not a strong authentication method. Passwords are + passed over the circuit in the clear and there is no protection from + repeated trial and error attacks. Work is currently underway on more + secure authentication methods for PPP and other protocols. It is + strongly recommended to switch to these methods when they become + available. + + +4.1. Packet Format + + Exactly one Password Authentication Protocol packet is encapsulated + in the Information field of PPP Data Link Layer frames where the + protocol field indicates type hex c023 (Password Authentication + Protocol). A summary of the Password Authentication Protocol packet + format is shown below. The fields are transmitted from left to + right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Code + + The Code field is one octet and identifies the type of PAP packet. + PAP Codes are assigned as follows: + + + +Perkins & Hobby [Page 27] + +RFC 1172 PPP Initial Options July 1990 + + + 1 Authenticate + 2 Authenticate-Ack + 3 Authenticate-Nak + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. + + Length + + The Length field is two octets and indicates the length of the PAP + packet including the Code, Identifier, Length and Data fields. + Octets outside the range of the Length field should be treated as + Data Link Layer padding and should be ignored on reception. + + Data + + The Data field is zero or more octets. The format of the Data + field is determined by the Code field. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 28] + +RFC 1172 PPP Initial Options July 1990 + + +4.2. Authenticate + + Description + + The Authenticate packet is used to begin the Password + Authentication Protocol. An implementation having sent a LCP + Configure-Ack packet with an Authentication-Type Configuration + Option further specifying the Password Authentication Protocol + must send an Authenticate packet during the Authentication phase. + An implementation receiving a Configure-Ack with said + Configuration Option should expect the remote end to send an + Authenticate packet during this phase. + + An Authenticate packet is sent with the Code field set to 1 + (Authenticate) and the Peer-ID and Password fields filled as + desired. + + Upon reception of an Authenticate, some type of Authenticate reply + MUST be transmitted. + + A summary of the Authenticate packet format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer-ID Length| Peer-Id ... + +-+-+-+-+-+-+-+-+-+-+-+-+ + | Passwd-Length | Password ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code + + 1 for Authenticate. + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. The Identifier field should be changed each time a + Authenticate is transmitted which is different from the preceding + request. + + Peer-ID-Length + + The Peer-ID-Length field is one octet and indicates the length of + the Peer-ID field + + + +Perkins & Hobby [Page 29] + +RFC 1172 PPP Initial Options July 1990 + + + Peer-ID + + The Peer-ID field is zero or more octets and indicates the name of + the peer to be authenticated. + + Passwd-Length + + The Passwd-Length field is one octet and indicates the length of + the Password field + + Password + + The Password field is zero or more octets and indicates the + password to be used for authentication. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 30] + +RFC 1172 PPP Initial Options July 1990 + + +4.3. Authenticate-Ack + + Description + + If the Peer-ID/Password pair received in an Authenticate is both + recognizable and acceptable, then a PAP implementation should + transmit a PAP packet with the Code field set to 2 (Authenticate- + Ack), the Identifier field copied from the received Authenticate, + and the Message field optionally filled with an ASCII message. + + A summary of the Authenticate-Ack packet format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Msg-Length | Message ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 2 for Authenticate-Ack. + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. The Identifier field MUST be copied from the + Identifier field of the Authenticate which caused this + Authenticate-Ack. + + Msg-Length + + The Msg-Length field is one octet and indicates the length of the + Message field + + Message + + The Message field is zero or more octets and indicates an ASCII + message. + + + + + + + + + + +Perkins & Hobby [Page 31] + +RFC 1172 PPP Initial Options July 1990 + + +4.4. Authenticate-Nak + + Description + + If the Peer-ID/Password pair received in a Authenticate is not + recognizable or acceptable, then a PAP implementation should + transmit a PAP packet with the Code field set to 3 (Authenticate- + Nak), the Identifier field copied from the received Authenticate, + and the Message field optionally filled with an ASCII message. + + A summary of the Authenticate-Nak packet format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Msg-Length | Message ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 3 for Authenticate-Nak. + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. The Identifier field MUST be copied from the + Identifier field of the Authenticate which caused this + Authenticate-Nak. + + Msg-Length + + The Msg-Length field is one octet and indicates the length of the + Message field + + Message + + The Message field is zero or more octets and indicates an ASCII + message. + + + + + + + + + + +Perkins & Hobby [Page 32] + +RFC 1172 PPP Initial Options July 1990 + + +5. IP Control Protocol (IPCP) Configuration Options + +IPCP Configuration Options allow negotiatiation of desirable Internet +Protocol parameters. Negotiable modifications proposed in this document +include IP addresses and compression protocols. + +The initial proposed values for the IPCP Configuration Option Type field +(see [1]) are assigned as follows: + + 1 IP-Addresses + 2 Compression-Type + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 33] + +RFC 1172 PPP Initial Options July 1990 + + +5.1. IP-Addresses + + Description + + This Configuration Option provides a way to negotiate the IP + addresses to be used on each end of the link. By default, no IP + addresses are assigned to either end. An address specified as + zero shall be interpreted as requesting the remote end to specify + the address. If an implementation allows the assignment of + multiple IP addresses, then it may include multiple IP Address + Configuration Options in its Configure-Request packets. An + implementation receiving a Configure-Request specifying multiple + IP Address Configuration Options may send a Configure-Reject + specifying one or more of the specified IP Addresses. An + implementation which desires that no IP addresses be assigned + (such as a "half-gateway") may reject all IP Address Configuration + Options. + + A summary of the IP-Addresses Configuration Option format is shown + below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Source-IP-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Source-IP-Address (cont) | Destination-IP-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Destination-IP-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 1 + + Length + + 10 + + Source-IP-Address + + The four octet Source-IP-Address is the desired local address of + the sender of a Configure-Request. In a Configure-Ack, + Configure-Nak or Configure-Reject, the Source-IP-Address is the + remote address of the sender, and is thus a local address with + respect to the Configuration Option receiver. + + + + + +Perkins & Hobby [Page 34] + +RFC 1172 PPP Initial Options July 1990 + + + Destination-IP-Address + + The four octet Destination-IP-Address is the remote address with + respect to the sender of a Configure-Request. In a Configure-Ack, + Configure-Nak or Configure-Reject, the Destination-IP-Address is + the local address of the sender, and is thus a remote address with + respect to the Configuration Option receiver. + + Default + + No IP addresses assigned. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 35] + +RFC 1172 PPP Initial Options July 1990 + + +5.2. Compression-Type + + Description + + This Configuration Option provides a way to negotiate the use of a + specific compression protocol. By default, compression is not + enabled. + + A summary of the Compression-Type Configuration Option format is + shown below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Compression-Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Type + + 2 + + Length + + >= 4 + + Compression-Type + + The Compression-Type field is two octets and indicates the type of + compression protocol desired. Values for the Compression-Type are + always the same as the PPP Data Link Layer Protocol field values + for that same compression protocol. The most up-to-date values of + the Compression-Type field are specified in "Assigned Numbers" + [2]. Initial values are assigned as follows: + + Value (in hex) Protocol + + 0037 Van Jacobson Compressed TCP/IP + + Data + + The Data field is zero or more octets and contains additional data + as determined by the compression protocol indicated in the + Compression-Type field. + + + + + + +Perkins & Hobby [Page 36] + +RFC 1172 PPP Initial Options July 1990 + + + Default + + No compression protocol enabled. + + +References + + [1] Perkins, D., "The Point-to-Point Protocol for the Transmission + of Multi-Protocol of Datagrams Over Point-to-Point Links", RFC + 1171, July, 1990. + + [2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, + USC/Information Sciences Institute, March 1990. + + +Security Considerations + + Security issues are discussed in Section 2.3. + + +Author's Address + + This proposal is the product of the Point-to-Point Protocol Working + Group of the Internet Engineering Task Force (IETF). The working + group can be contacted via the chair: + + Russ Hobby + UC Davis + Computing Services + Davis, CA 95616 + + Phone: (916) 752-0236 + + EMail: rdhobby@ucdavis.edu + + Questions about this memo can also be directed to: + + Drew D. Perkins + Carnegie Mellon University + Networking and Communications + Pittsburgh, PA 15213 + + Phone: (412) 268-8576 + + EMail: ddp@andrew.cmu.edu + + + + + + +Perkins & Hobby [Page 37] + +RFC 1172 PPP Initial Options July 1990 + + +Acknowledgments + + Many people spent significant time helping to develop the Point-to- + Point Protocol. The complete list of people is too numerous to list, + but the following people deserve special thanks: Ken Adelman (TGV), + Craig Fox (NSC), Phill Gross (NRI), Russ Hobby (UC Davis), David + Kaufman (Proteon), John LoVerso (Xylogics), Bill Melohn (Sun + Microsystems), Mike Patton (MIT), Drew Perkins (CMU), Greg Satz + (cisco systems) and Asher Waldfogel (Wellfleet). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Perkins & Hobby [Page 38] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/doc/rfc1332.txt b/doc/rfc1332.txt new file mode 100644 index 00000000..3e120425 --- /dev/null +++ b/doc/rfc1332.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group G. McGregor +Request for Comments: 1332 Merit +Obsoletes: RFC 1172 May 1992 + + + + The PPP Internet Protocol Control Protocol (IPCP) + + + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community, and requests discussion and suggestions for improvements. + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + Distribution of this memo is unlimited. + +Abstract + + The Point-to-Point Protocol (PPP) [1] provides a standard method of + encapsulating Network Layer protocol information over point-to-point + links. PPP also defines an extensible Link Control Protocol, and + proposes a family of Network Control Protocols (NCPs) for + establishing and configuring different network-layer protocols. + + This document defines the NCP for establishing and configuring the + Internet Protocol [2] over PPP, and a method to negotiate and use Van + Jacobson TCP/IP header compression [3] with PPP. + + This RFC is a product of the Point-to-Point Protocol Working Group of + the Internet Engineering Task Force (IETF). + + + + + + + + + + + + + + + + + + + +McGregor [Page i] + +RFC 1332 PPP IPCP May 1992 + + +Table of Contents + + + 1. Introduction .......................................... 1 + + 2. A PPP Network Control Protocol (NCP) for IP ........... 2 + 2.1 Sending IP Datagrams ............................ 2 + + 3. IPCP Configuration Options ............................ 4 + 3.1 IP-Addresses .................................... 5 + 3.2 IP-Compression-Protocol ......................... 6 + 3.3 IP-Address ...................................... 8 + + 4. Van Jacobson TCP/IP header compression ................ 9 + 4.1 Configuration Option Format ..................... 9 + + APPENDICES ................................................... 11 + + A. IPCP Recommended Options .............................. 11 + + SECURITY CONSIDERATIONS ...................................... 11 + + REFERENCES ................................................... 11 + + ACKNOWLEDGEMENTS ............................................. 11 + + CHAIR'S ADDRESS .............................................. 12 + + AUTHOR'S ADDRESS ............................................. 12 + + + + + + + + + + + + + + + + + + + + + + +McGregor [Page ii] + +RFC 1332 PPP IPCP May 1992 + + +1. Introduction + + PPP has three main components: + + 1. A method for encapsulating datagrams over serial links. + + 2. A Link Control Protocol (LCP) for establishing, configuring, + and testing the data-link connection. + + 3. A family of Network Control Protocols (NCPs) for establishing + and configuring different network-layer protocols. + + In order to establish communications over a point-to-point link, each + end of the PPP link must first send LCP packets to configure and test + the data link. After the link has been established and optional + facilities have been negotiated as needed by the LCP, PPP must send + NCP packets to choose and configure one or more network-layer + protocols. Once each of the chosen network-layer protocols has been + configured, datagrams from each network-layer protocol can be sent + over the link. + + The link will remain configured for communications until explicit LCP + or NCP packets close the link down, or until some external event + occurs (an inactivity timer expires or network administrator + intervention). + + + + + + + + + + + + + + + + + + + + + + + + + + +McGregor [Page 1] + +RFC 1332 PPP IPCP May 1992 + + +2. A PPP Network Control Protocol (NCP) for IP + + The IP Control Protocol (IPCP) is responsible for configuring, + enabling, and disabling the IP protocol modules on both ends of the + point-to-point link. IPCP uses the same packet exchange machanism as + the Link Control Protocol (LCP). IPCP packets may not be exchanged + until PPP has reached the Network-Layer Protocol phase. IPCP packets + received before this phase is reached should be silently discarded. + + The IP Control Protocol is exactly the same as the Link Control + Protocol [1] with the following exceptions: + + Data Link Layer Protocol Field + + Exactly one IPCP packet is encapsulated in the Information field + of PPP Data Link Layer frames where the Protocol field indicates + type hex 8021 (IP Control Protocol). + + Code field + + Only Codes 1 through 7 (Configure-Request, Configure-Ack, + Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack + and Code-Reject) are used. Other Codes should be treated as + unrecognized and should result in Code-Rejects. + + Timeouts + + IPCP packets may not be exchanged until PPP has reached the + Network-Layer Protocol phase. An implementation should be + prepared to wait for Authentication and Link Quality Determination + to finish before timing out waiting for a Configure-Ack or other + response. It is suggested that an implementation give up only + after user intervention or a configurable amount of time. + + Configuration Option Types + + IPCP has a distinct set of Configuration Options, which are + defined below. + +2.1. Sending IP Datagrams + + Before any IP packets may be communicated, PPP must reach the + Network-Layer Protocol phase, and the IP Control Protocol must reach + the Opened state. + + Exactly one IP packet is encapsulated in the Information field of PPP + Data Link Layer frames where the Protocol field indicates type hex + 0021 (Internet Protocol). + + + +McGregor [Page 2] + +RFC 1332 PPP IPCP May 1992 + + + The maximum length of an IP packet transmitted over a PPP link is the + same as the maximum length of the Information field of a PPP data + link layer frame. Larger IP datagrams must be fragmented as + necessary. If a system wishes to avoid fragmentation and reassembly, + it should use the TCP Maximum Segment Size option [4], and MTU + discovery [5]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McGregor [Page 3] + +RFC 1332 PPP IPCP May 1992 + + +3. IPCP Configuration Options + +IPCP Configuration Options allow negotiatiation of desirable Internet +Protocol parameters. IPCP uses the same Configuration Option format +defined for LCP [1], with a separate set of Options. + +The most up-to-date values of the IPCP Option Type field are specified +in the most recent "Assigned Numbers" RFC [6]. Current values are +assigned as follows: + + 1 IP-Addresses + 2 IP-Compression-Protocol + 3 IP-Address + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McGregor [Page 4] + +RFC 1332 PPP IPCP May 1992 + + +3.1. IP-Addresses + + Description + + The use of the Configuration Option IP-Addresses has been + deprecated. It has been determined through implementation + experience that it is difficult to ensure negotiation convergence + in all cases using this option. RFC 1172 [7] provides information + for implementations requiring backwards compatability. The IP- + Address Configuration Option replaces this option, and its use is + preferred. + + This option SHOULD NOT be sent in a Configure-Request if a + Configure-Request has been received which includes either an IP- + Addresses or IP-Address option. This option MAY be sent if a + Configure-Reject is received for the IP-Address option, or a + Configure-Nak is received with an IP-Addresses option as an + appended option. + + Support for this option MAY be removed after the IPCP protocol + status advances to Internet Draft Standard. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McGregor [Page 5] + +RFC 1332 PPP IPCP May 1992 + + +3.2. IP-Compression-Protocol + + Description + + This Configuration Option provides a way to negotiate the use of a + specific compression protocol. By default, compression is not + enabled. + + A summary of the IP-Compression-Protocol Configuration Option format + is shown below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | IP-Compression-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Type + + 2 + + Length + + >= 4 + + IP-Compression-Protocol + + The IP-Compression-Protocol field is two octets and indicates the + compression protocol desired. Values for this field are always + the same as the PPP Data Link Layer Protocol field values for that + same compression protocol. + + The most up-to-date values of the IP-Compression-Protocol field + are specified in the most recent "Assigned Numbers" RFC [6]. + Current values are assigned as follows: + + Value (in hex) Protocol + + 002d Van Jacobson Compressed TCP/IP + + Data + + The Data field is zero or more octets and contains additional data + as determined by the particular compression protocol. + + + + + +McGregor [Page 6] + +RFC 1332 PPP IPCP May 1992 + + + Default + + No compression protocol enabled. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +McGregor [Page 7] + +RFC 1332 PPP IPCP May 1992 + + +3.3. IP-Address + + Description + + This Configuration Option provides a way to negotiate the IP + address to be used on the local end of the link. It allows the + sender of the Configure-Request to state which IP-address is + desired, or to request that the peer provide the information. The + peer can provide this information by NAKing the option, and + returning a valid IP-address. + + If negotiation about the remote IP-address is required, and the + peer did not provide the option in its Configure-Request, the + option SHOULD be appended to a Configure-Nak. The value of the + IP-address given must be acceptable as the remote IP-address, or + indicate a request that the peer provide the information. + + By default, no IP address is assigned. + + A summary of the IP-Address Configuration Option format is shown + below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | IP-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + IP-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 3 + + Length + + 6 + + IP-Address + + The four octet IP-Address is the desired local address of the + sender of a Configure-Request. If all four octets are set to + zero, it indicates a request that the peer provide the IP-Address + information. + + Default + + No IP address is assigned. + + + +McGregor [Page 8] + +RFC 1332 PPP IPCP May 1992 + + +4. Van Jacobson TCP/IP header compression + +Van Jacobson TCP/IP header compression reduces the size of the TCP/IP +headers to as few as three bytes. This can be a significant improvement +on slow serial lines, particularly for interactive traffic. + +The IP-Compression-Protocol Configuration Option is used to indicate the +ability to receive compressed packets. Each end of the link must +separately request this option if bi-directional compression is desired. + +The PPP Protocol field is set to the following values when transmitting +IP packets: + + Value (in hex) + + 0021 Type IP. The IP protocol is not TCP, or the packet is a + fragment, or cannot be compressed. + + 002d Compressed TCP. The TCP/IP headers are replaced by the + compressed header. + + 002f Uncompressed TCP. The IP protocol field is replaced by + the slot identifier. + +4.1. Configuration Option Format + + A summary of the IP-Compression-Protocol Configuration Option format + to negotiate Van Jacobson TCP/IP header compression is shown below. + The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | IP-Compression-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Max-Slot-Id | Comp-Slot-Id | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 2 + + Length + + 6 + + + + + + +McGregor [Page 9] + +RFC 1332 PPP IPCP May 1992 + + + IP-Compression-Protocol + + 002d (hex) for Van Jacobson Compressed TCP/IP headers. + + Max-Slot-Id + + The Max-Slot-Id field is one octet and indicates the maximum slot + identifier. This is one less than the actual number of slots; the + slot identifier has values from zero to Max-Slot-Id. + + Note: There may be implementations that have problems with only + one slot (Max-Slot-Id = 0). See the discussion in reference + [3]. The example implementation in [3] will only work with 3 + through 254 slots. + + Comp-Slot-Id + + The Comp-Slot-Id field is one octet and indicates whether the slot + identifier field may be compressed. + + 0 The slot identifier must not be compressed. All compressed + TCP packets must set the C bit in every change mask, and + must include the slot identifier. + + 1 The slot identifer may be compressed. + + The slot identifier must not be compressed if there is no ability + for the PPP link level to indicate an error in reception to the + decompression module. Synchronization after errors depends on + receiving a packet with the slot identifier. See the discussion + in reference [3]. + + + + + + + + + + + + + + + + + + + + +McGregor [Page 10] + +RFC 1332 PPP IPCP May 1992 + + +A. IPCP Recommended Options + + The following Configurations Options are recommended: + + IP-Compression-Protocol -- with at least 4 slots, usually 16 + slots. + + IP-Address -- only on dial-up lines. + + +Security Considerations + + Security issues are not discussed in this memo. + + +References + + [1] Simpson, W., "The Point-to-Point Protocol", RFC 1331, May 1992. + + [2] Postel, J., "Internet Protocol", RFC 791, USC/Information + Sciences Institute, September 1981. + + [3] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, January + 1990. + + [4] Postel, J., "The TCP Maximum Segment Size Option and Related + Topics", RFC 879, USC/Information Sciences Institute, November + 1983. + + [5] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191, + November 1990. + + [6] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060, + USC/Information Sciences Institute, March 1990. + + [7] Perkins, D., and R. Hobby, "Point-to-Point Protocol (PPP) + initial configuration options", RFC 1172, August 1990. + + +Acknowledgments + + Some of the text in this document is taken from RFCs 1171 & 1172, by + Drew Perkins of Carnegie Mellon University, and by Russ Hobby of the + University of California at Davis. + + Information leading to the expanded IP-Compression option provided by + Van Jacobson at SIGCOMM '90. + + + + +McGregor [Page 11] + +RFC 1332 PPP IPCP May 1992 + + + Bill Simpson helped with the document formatting. + + +Chair's Address + + The working group can be contacted via the current chair: + + Brian Lloyd + Lloyd & Associates + 3420 Sudbury Road + Cameron Park, California 95682 + + Phone: (916) 676-1147 + + EMail: brian@ray.lloyd.com + + + +Author's Address + + Questions about this memo can also be directed to: + + Glenn McGregor + Merit Network, Inc. + 1071 Beal Avenue + Ann Arbor, MI 48109-2103 + + Phone: (313) 763-1203 + + EMail: Glenn.McGregor@Merit.edu + + + + + + + + + + + + + + + + + + + + + +McGregor [Page 12] + diff --git a/doc/rfc1334.txt b/doc/rfc1334.txt new file mode 100644 index 00000000..6051f480 --- /dev/null +++ b/doc/rfc1334.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group B. Lloyd +Request for Comments: 1334 L&A + W. Simpson + Daydreamer + October 1992 + + + PPP Authentication Protocols + +Status of this Memo + + This RFC specifies an IAB standards track protocol for the Internet + community, and requests discussion and suggestions for improvements. + Please refer to the current edition of the "IAB Official Protocol + Standards" for the standardization state and status of this protocol. + Distribution of this memo is unlimited. + +Abstract + + The Point-to-Point Protocol (PPP) [1] provides a standard method of + encapsulating Network Layer protocol information over point-to-point + links. PPP also defines an extensible Link Control Protocol, which + allows negotiation of an Authentication Protocol for authenticating + its peer before allowing Network Layer protocols to transmit over the + link. + + This document defines two protocols for Authentication: the Password + Authentication Protocol and the Challenge-Handshake Authentication + Protocol. This memo is the product of the Point-to-Point Protocol + Working Group of the Internet Engineering Task Force (IETF). + Comments on this memo should be submitted to the ietf-ppp@ucdavis.edu + mailing list. + +Table of Contents + + 1. Introduction ............................................... 2 + 1.1 Specification Requirements ................................. 2 + 1.2 Terminology ................................................ 3 + 2. Password Authentication Protocol ............................ 3 + 2.1 Configuration Option Format ................................ 4 + 2.2 Packet Format .............................................. 5 + 2.2.1 Authenticate-Request ..................................... 5 + 2.2.2 Authenticate-Ack and Authenticate-Nak .................... 7 + 3. Challenge-Handshake Authentication Protocol.................. 8 + 3.1 Configuration Option Format ................................ 9 + 3.2 Packet Format .............................................. 10 + 3.2.1 Challenge and Response ................................... 11 + 3.2.2 Success and Failure ...................................... 13 + + + +Lloyd & Simpson [Page 1] + +RFC 1334 PPP Authentication October 1992 + + + SECURITY CONSIDERATIONS ........................................ 14 + REFERENCES ..................................................... 15 + ACKNOWLEDGEMENTS ............................................... 16 + CHAIR'S ADDRESS ................................................ 16 + AUTHOR'S ADDRESS ............................................... 16 + +1. Introduction + + PPP has three main components: + + 1. A method for encapsulating datagrams over serial links. + + 2. A Link Control Protocol (LCP) for establishing, configuring, + and testing the data-link connection. + + 3. A family of Network Control Protocols (NCPs) for establishing + and configuring different network-layer protocols. + + In order to establish communications over a point-to-point link, each + end of the PPP link must first send LCP packets to configure the data + link during Link Establishment phase. After the link has been + established, PPP provides for an optional Authentication phase before + proceeding to the Network-Layer Protocol phase. + + By default, authentication is not mandatory. If authentication of + the link is desired, an implementation MUST specify the + Authentication-Protocol Configuration Option during Link + Establishment phase. + + These authentication protocols are intended for use primarily by + hosts and routers that connect to a PPP network server via switched + circuits or dial-up lines, but might be applied to dedicated links as + well. The server can use the identification of the connecting host + or router in the selection of options for network layer negotiations. + + This document defines the PPP authentication protocols. The Link + Establishment and Authentication phases, and the Authentication- + Protocol Configuration Option, are defined in The Point-to-Point + Protocol (PPP) [1]. + +1.1. Specification Requirements + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. + + MUST + This word, or the adjective "required", means that the definition + is an absolute requirement of the specification. + + + +Lloyd & Simpson [Page 2] + +RFC 1334 PPP Authentication October 1992 + + + MUST NOT + This phrase means that the definition is an absolute prohibition + of the specification. + + SHOULD + This word, or the adjective "recommended", means that there may + exist valid reasons in particular circumstances to ignore this + item, but the full implications should be understood and carefully + weighed before choosing a different course. + + MAY + This word, or the adjective "optional", means that this item is + one of an allowed set of alternatives. An implementation which + does not include this option MUST be prepared to interoperate with + another implementation which does include the option. + +1.2. Terminology + + This document frequently uses the following terms: + + authenticator + The end of the link requiring the authentication. The + authenticator specifies the authentication protocol to be used in + the Configure-Request during Link Establishment phase. + + peer + The other end of the point-to-point link; the end which is being + authenticated by the authenticator. + + silently discard + This means the implementation discards the packet without further + processing. The implementation SHOULD provide the capability of + logging the error, including the contents of the silently + discarded packet, and SHOULD record the event in a statistics + counter. + +2. Password Authentication Protocol + + The Password Authentication Protocol (PAP) provides a simple method + for the peer to establish its identity using a 2-way handshake. This + is done only upon initial link establishment. + + After the Link Establishment phase is complete, an Id/Password pair + is repeatedly sent by the peer to the authenticator until + authentication is acknowledged or the connection is terminated. + + PAP is not a strong authentication method. Passwords are sent over + the circuit "in the clear", and there is no protection from playback + + + +Lloyd & Simpson [Page 3] + +RFC 1334 PPP Authentication October 1992 + + + or repeated trial and error attacks. The peer is in control of the + frequency and timing of the attempts. + + Any implementations which include a stronger authentication method + (such as CHAP, described below) MUST offer to negotiate that method + prior to PAP. + + This authentication method is most appropriately used where a + plaintext password must be available to simulate a login at a remote + host. In such use, this method provides a similar level of security + to the usual user login at the remote host. + + Implementation Note: It is possible to limit the exposure of the + plaintext password to transmission over the PPP link, and avoid + sending the plaintext password over the entire network. When the + remote host password is kept as a one-way transformed value, and + the algorithm for the transform function is implemented in the + local server, the plaintext password SHOULD be locally transformed + before comparison with the transformed password from the remote + host. + +2.1. Configuration Option Format + + A summary of the Authentication-Protocol Configuration Option format + to negotiate the Password Authentication Protocol is shown below. + The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Authentication-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 3 + + Length + + 4 + + Authentication-Protocol + + c023 (hex) for Password Authentication Protocol. + + Data + + There is no Data field. + + + +Lloyd & Simpson [Page 4] + +RFC 1334 PPP Authentication October 1992 + + +2.2. Packet Format + + Exactly one Password Authentication Protocol packet is encapsulated + in the Information field of a PPP Data Link Layer frame where the + protocol field indicates type hex c023 (Password Authentication + Protocol). A summary of the PAP packet format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Code + + The Code field is one octet and identifies the type of PAP packet. + PAP Codes are assigned as follows: + + 1 Authenticate-Request + 2 Authenticate-Ack + 3 Authenticate-Nak + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. + + Length + + The Length field is two octets and indicates the length of the PAP + packet including the Code, Identifier, Length and Data fields. + Octets outside the range of the Length field should be treated as + Data Link Layer padding and should be ignored on reception. + + Data + + The Data field is zero or more octets. The format of the Data + field is determined by the Code field. + +2.2.1. Authenticate-Request + + Description + + The Authenticate-Request packet is used to begin the Password + Authentication Protocol. The link peer MUST transmit a PAP packet + + + +Lloyd & Simpson [Page 5] + +RFC 1334 PPP Authentication October 1992 + + + with the Code field set to 1 (Authenticate-Request) during the + Authentication phase. The Authenticate-Request packet MUST be + repeated until a valid reply packet is received, or an optional + retry counter expires. + + The authenticator SHOULD expect the peer to send an Authenticate- + Request packet. Upon reception of an Authenticate-Request packet, + some type of Authenticate reply (described below) MUST be + returned. + + Implementation Note: Because the Authenticate-Ack might be + lost, the authenticator MUST allow repeated Authenticate- + Request packets after completing the Authentication phase. + Protocol phase MUST return the same reply Code returned when + the Authentication phase completed (the message portion MAY be + different). Any Authenticate-Request packets received during + any other phase MUST be silently discarded. + + When the Authenticate-Nak is lost, and the authenticator + terminates the link, the LCP Terminate-Request and Terminate- + Ack provide an alternative indication that authentication + failed. + + A summary of the Authenticate-Request packet format is shown below. + The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer-ID Length| Peer-Id ... + +-+-+-+-+-+-+-+-+-+-+-+-+ + | Passwd-Length | Password ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code + + 1 for Authenticate-Request. + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. The Identifier field MUST be changed each time an + Authenticate-Request packet is issued. + + + + + + +Lloyd & Simpson [Page 6] + +RFC 1334 PPP Authentication October 1992 + + + Peer-ID-Length + + The Peer-ID-Length field is one octet and indicates the length of + the Peer-ID field. + + Peer-ID + + The Peer-ID field is zero or more octets and indicates the name of + the peer to be authenticated. + + Passwd-Length + + The Passwd-Length field is one octet and indicates the length of + the Password field. + + Password + + The Password field is zero or more octets and indicates the + password to be used for authentication. + +2.2.2. Authenticate-Ack and Authenticate-Nak + + Description + + If the Peer-ID/Password pair received in an Authenticate-Request + is both recognizable and acceptable, then the authenticator MUST + transmit a PAP packet with the Code field set to 2 (Authenticate- + Ack). + + If the Peer-ID/Password pair received in a Authenticate-Request is + not recognizable or acceptable, then the authenticator MUST + transmit a PAP packet with the Code field set to 3 (Authenticate- + Nak), and SHOULD take action to terminate the link. + + A summary of the Authenticate-Ack and Authenticate-Nak packet format + is shown below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Msg-Length | Message ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 2 for Authenticate-Ack; + + + +Lloyd & Simpson [Page 7] + +RFC 1334 PPP Authentication October 1992 + + + 3 for Authenticate-Nak. + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. The Identifier field MUST be copied from the + Identifier field of the Authenticate-Request which caused this + reply. + + Msg-Length + + The Msg-Length field is one octet and indicates the length of the + Message field. + + Message + + The Message field is zero or more octets, and its contents are + implementation dependent. It is intended to be human readable, + and MUST NOT affect operation of the protocol. It is recommended + that the message contain displayable ASCII characters 32 through + 126 decimal. Mechanisms for extension to other character sets are + the topic of future research. + +3. Challenge-Handshake Authentication Protocol + + The Challenge-Handshake Authentication Protocol (CHAP) is used to + periodically verify the identity of the peer using a 3-way handshake. + This is done upon initial link establishment, and MAY be repeated + anytime after the link has been established. + + After the Link Establishment phase is complete, the authenticator + sends a "challenge" message to the peer. The peer responds with a + value calculated using a "one-way hash" function. The authenticator + checks the response against its own calculation of the expected hash + value. If the values match, the authentication is acknowledged; + otherwise the connection SHOULD be terminated. + + CHAP provides protection against playback attack through the use of + an incrementally changing identifier and a variable challenge value. + The use of repeated challenges is intended to limit the time of + exposure to any single attack. The authenticator is in control of + the frequency and timing of the challenges. + + This authentication method depends upon a "secret" known only to the + authenticator and that peer. The secret is not sent over the link. + This method is most likely used where the same secret is easily + accessed from both ends of the link. + + + + +Lloyd & Simpson [Page 8] + +RFC 1334 PPP Authentication October 1992 + + + Implementation Note: CHAP requires that the secret be available in + plaintext form. To avoid sending the secret over other links in + the network, it is recommended that the challenge and response + values be examined at a central server, rather than each network + access server. Otherwise, the secret SHOULD be sent to such + servers in a reversably encrypted form. + + The CHAP algorithm requires that the length of the secret MUST be at + least 1 octet. The secret SHOULD be at least as large and + unguessable as a well-chosen password. It is preferred that the + secret be at least the length of the hash value for the hashing + algorithm chosen (16 octets for MD5). This is to ensure a + sufficiently large range for the secret to provide protection against + exhaustive search attacks. + + The one-way hash algorithm is chosen such that it is computationally + infeasible to determine the secret from the known challenge and + response values. + + The challenge value SHOULD satisfy two criteria: uniqueness and + unpredictability. Each challenge value SHOULD be unique, since + repetition of a challenge value in conjunction with the same secret + would permit an attacker to reply with a previously intercepted + response. Since it is expected that the same secret MAY be used to + authenticate with servers in disparate geographic regions, the + challenge SHOULD exhibit global and temporal uniqueness. Each + challenge value SHOULD also be unpredictable, least an attacker trick + a peer into responding to a predicted future challenge, and then use + the response to masquerade as that peer to an authenticator. + Although protocols such as CHAP are incapable of protecting against + realtime active wiretapping attacks, generation of unique + unpredictable challenges can protect against a wide range of active + attacks. + + A discussion of sources of uniqueness and probability of divergence + is included in the Magic-Number Configuration Option [1]. + +3.1. Configuration Option Format + + A summary of the Authentication-Protocol Configuration Option format + to negotiate the Challenge-Handshake Authentication Protocol is shown + below. The fields are transmitted from left to right. + + + + + + + + + +Lloyd & Simpson [Page 9] + +RFC 1334 PPP Authentication October 1992 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Authentication-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Algorithm | + +-+-+-+-+-+-+-+-+ + + Type + + 3 + + Length + + 5 + + Authentication-Protocol + + c223 (hex) for Challenge-Handshake Authentication Protocol. + + Algorithm + + The Algorithm field is one octet and indicates the one-way hash + method to be used. The most up-to-date values of the CHAP + Algorithm field are specified in the most recent "Assigned + Numbers" RFC [2]. Current values are assigned as follows: + + 0-4 unused (reserved) + 5 MD5 [3] + +3.2. Packet Format + + Exactly one Challenge-Handshake Authentication Protocol packet is + encapsulated in the Information field of a PPP Data Link Layer frame + where the protocol field indicates type hex c223 (Challenge-Handshake + Authentication Protocol). A summary of the CHAP packet format is + shown below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + + + + + +Lloyd & Simpson [Page 10] + +RFC 1334 PPP Authentication October 1992 + + + Code + + The Code field is one octet and identifies the type of CHAP + packet. CHAP Codes are assigned as follows: + + 1 Challenge + 2 Response + 3 Success + 4 Failure + + Identifier + + The Identifier field is one octet and aids in matching challenges, + responses and replies. + + Length + + The Length field is two octets and indicates the length of the + CHAP packet including the Code, Identifier, Length and Data + fields. Octets outside the range of the Length field should be + treated as Data Link Layer padding and should be ignored on + reception. + + Data + + The Data field is zero or more octets. The format of the Data + field is determined by the Code field. + +3.2.1. Challenge and Response + + Description + + The Challenge packet is used to begin the Challenge-Handshake + Authentication Protocol. The authenticator MUST transmit a CHAP + packet with the Code field set to 1 (Challenge). Additional + Challenge packets MUST be sent until a valid Response packet is + received, or an optional retry counter expires. + + A Challenge packet MAY also be transmitted at any time during the + Network-Layer Protocol phase to ensure that the connection has not + been altered. + + The peer SHOULD expect Challenge packets during the Authentication + phase and the Network-Layer Protocol phase. Whenever a Challenge + packet is received, the peer MUST transmit a CHAP packet with the + Code field set to 2 (Response). + + Whenever a Response packet is received, the authenticator compares + + + +Lloyd & Simpson [Page 11] + +RFC 1334 PPP Authentication October 1992 + + + the Response Value with its own calculation of the expected value. + Based on this comparison, the authenticator MUST send a Success or + Failure packet (described below). + + Implementation Note: Because the Success might be lost, the + authenticator MUST allow repeated Response packets after + completing the Authentication phase. To prevent discovery of + alternative Names and Secrets, any Response packets received + having the current Challenge Identifier MUST return the same + reply Code returned when the Authentication phase completed + (the message portion MAY be different). Any Response packets + received during any other phase MUST be silently discarded. + + When the Failure is lost, and the authenticator terminates the + link, the LCP Terminate-Request and Terminate-Ack provide an + alternative indication that authentication failed. + + A summary of the Challenge and Response packet format is shown below. + The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value-Size | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Name ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code + + 1 for Challenge; + + 2 for Response. + + Identifier + + The Identifier field is one octet. The Identifier field MUST be + changed each time a Challenge is sent. + + The Response Identifier MUST be copied from the Identifier field + of the Challenge which caused the Response. + + Value-Size + + This field is one octet and indicates the length of the Value + field. + + + +Lloyd & Simpson [Page 12] + +RFC 1334 PPP Authentication October 1992 + + + Value + + The Value field is one or more octets. The most significant octet + is transmitted first. + + The Challenge Value is a variable stream of octets. The + importance of the uniqueness of the Challenge Value and its + relationship to the secret is described above. The Challenge + Value MUST be changed each time a Challenge is sent. The length + of the Challenge Value depends upon the method used to generate + the octets, and is independent of the hash algorithm used. + + The Response Value is the one-way hash calculated over a stream of + octets consisting of the Identifier, followed by (concatenated + with) the "secret", followed by (concatenated with) the Challenge + Value. The length of the Response Value depends upon the hash + algorithm used (16 octets for MD5). + + Name + + The Name field is one or more octets representing the + identification of the system transmitting the packet. There are + no limitations on the content of this field. For example, it MAY + contain ASCII character strings or globally unique identifiers in + ASN.1 syntax. The Name should not be NUL or CR/LF terminated. + The size is determined from the Length field. + + Since CHAP may be used to authenticate many different systems, the + content of the name field(s) may be used as a key to locate the + proper secret in a database of secrets. This also makes it + possible to support more than one name/secret pair per system. + +3.2.2. Success and Failure + + Description + + If the Value received in a Response is equal to the expected + value, then the implementation MUST transmit a CHAP packet with + the Code field set to 3 (Success). + + If the Value received in a Response is not equal to the expected + value, then the implementation MUST transmit a CHAP packet with + the Code field set to 4 (Failure), and SHOULD take action to + terminate the link. + + A summary of the Success and Failure packet format is shown below. + The fields are transmitted from left to right. + + + + +Lloyd & Simpson [Page 13] + +RFC 1334 PPP Authentication October 1992 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 3 for Success; + + 4 for Failure. + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. The Identifier field MUST be copied from the + Identifier field of the Response which caused this reply. + + Message + + The Message field is zero or more octets, and its contents are + implementation dependent. It is intended to be human readable, + and MUST NOT affect operation of the protocol. It is recommended + that the message contain displayable ASCII characters 32 through + 126 decimal. Mechanisms for extension to other character sets are + the topic of future research. The size is determined from the + Length field. + +Security Considerations + + Security issues are the primary topic of this RFC. + + The interaction of the authentication protocols within PPP are + highly implementation dependent. This is indicated by the use of + SHOULD throughout the document. + + For example, upon failure of authentication, some implementations + do not terminate the link. Instead, the implementation limits the + kind of traffic in the Network-Layer Protocols to a filtered + subset, which in turn allows the user opportunity to update + secrets or send mail to the network administrator indicating a + problem. + + There is no provision for re-tries of failed authentication. + However, the LCP state machine can renegotiate the authentication + protocol at any time, thus allowing a new attempt. It is + + + +Lloyd & Simpson [Page 14] + +RFC 1334 PPP Authentication October 1992 + + + recommended that any counters used for authentication failure not + be reset until after successful authentication, or subsequent + termination of the failed link. + + There is no requirement that authentication be full duplex or that + the same protocol be used in both directions. It is perfectly + acceptable for different protocols to be used in each direction. + This will, of course, depend on the specific protocols negotiated. + + In practice, within or associated with each PPP server, there is a + database which associates "user" names with authentication + information ("secrets"). It is not anticipated that a particular + named user would be authenticated by multiple methods. This would + make the user vulnerable to attacks which negotiate the least + secure method from among a set (such as PAP rather than CHAP). + Instead, for each named user there should be an indication of + exactly one method used to authenticate that user name. If a user + needs to make use of different authentication method under + different circumstances, then distinct user names SHOULD be + employed, each of which identifies exactly one authentication + method. + + Passwords and other secrets should be stored at the respective + ends such that access to them is as limited as possible. Ideally, + the secrets should only be accessible to the process requiring + access in order to perform the authentication. + + The secrets should be distributed with a mechanism that limits the + number of entities that handle (and thus gain knowledge of) the + secret. Ideally, no unauthorized person should ever gain + knowledge of the secrets. It is possible to achieve this with + SNMP Security Protocols [4], but such a mechanism is outside the + scope of this specification. + + Other distribution methods are currently undergoing research and + experimentation. The SNMP Security document also has an excellent + overview of threats to network protocols. + +References + + [1] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1331, + Daydreamer, May 1992. + + [2] Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1340, + USC/Information Sciences Institute, July 1992. + + + + + + +Lloyd & Simpson [Page 15] + +RFC 1334 PPP Authentication October 1992 + + + [3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", MIT + Laboratory for Computer Science and RSA Data Security, Inc. RFC + 1321, April 1992. + + [4] Galvin, J., McCloghrie, K., and J. Davin, "SNMP Security + Protocols", Trusted Information Systems, Inc., Hughes LAN + Systems, Inc., MIT Laboratory for Computer Science, RFC 1352, + July 1992. + +Acknowledgments + + Some of the text in this document is taken from RFC 1172, by Drew + Perkins of Carnegie Mellon University, and by Russ Hobby of the + University of California at Davis. + + Special thanks to Dave Balenson, Steve Crocker, James Galvin, and + Steve Kent, for their extensive explanations and suggestions. Now, + if only we could get them to agree with each other. + +Chair's Address + + The working group can be contacted via the current chair: + + Brian Lloyd + Lloyd & Associates + 3420 Sudbury Road + Cameron Park, California 95682 + + Phone: (916) 676-1147 + + EMail: brian@lloyd.com + +Author's Address + + Questions about this memo can also be directed to: + + William Allen Simpson + Daydreamer + Computer Systems Consulting Services + P O Box 6205 + East Lansing, MI 48826-6205 + + EMail: Bill.Simpson@um.cc.umich.edu + + + + + + + + +Lloyd & Simpson [Page 16] +
\ No newline at end of file diff --git a/doc/rfc1548.txt b/doc/rfc1548.txt new file mode 100644 index 00000000..7b8a33a2 --- /dev/null +++ b/doc/rfc1548.txt @@ -0,0 +1,2971 @@ + + + + + + +Network Working Group W. Simpson +Request for Comments: 1548 Daydreamer +Obsoletes: RFC 1331 December 1993 +Category: Standards Track + + + The Point-to-Point Protocol (PPP) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + The Point-to-Point Protocol (PPP) provides a standard method for + transporting multi-protocol datagrams over point-to-point links. PPP + is comprised of three main components: + + 1. A method for encapsulating multi-protocol datagrams. + + 2. A Link Control Protocol (LCP) for establishing, configuring, + and testing the data-link connection. + + 3. A family of Network Control Protocols (NCPs) for establishing + and configuring different network-layer protocols. + + This document defines the PPP organization and methodology, and the + PPP encapsulation, together with an extensible option negotiation + mechanism which is able to negotiate a rich assortment of + configuration parameters and provides additional management + functions. The PPP Link Control Protocol (LCP) is described in terms + of this mechanism. + + This document is the product of the Point-to-Point Protocol Working + Group of the Internet Engineering Task Force (IETF). Comments should + be submitted to the ietf-ppp@ucdavis.edu mailing list. + + + + + + + + + + + +Simpson [Page 1] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +Table of Contents + + 1. Introduction ................................................3 + 1.1 Specification of Requirements ...............................4 + 1.2 Terminology .................................................5 + 2. PPP Encapsulation ...........................................5 + 3. PPP Link Operation ..........................................8 + 3.1 Overview ....................................................8 + 3.2 Phase Diagram ...............................................8 + 3.3 Link Dead (physical-layer not ready) ........................9 + 3.4 Link Establishment Phase ....................................9 + 3.5 Authentication Phase ........................................9 + 3.6 Network-Layer Protocol Phase ................................10 + 3.7 Link Termination Phase ......................................10 + 4. The Option Negotiation Automaton ............................11 + 4.1 State Diagram ...............................................12 + 4.2 State Transition Table ......................................14 + 4.3 A Day in the Life ...........................................15 + 4.4 States ......................................................16 + 4.5 Events ......................................................19 + 4.6 Actions .....................................................23 + 4.7 Loop Avoidance ..............................................26 + 4.8 Counters and Timers .........................................26 + 5. LCP Packet Formats ..........................................27 + 5.1 Configure-Request ...........................................29 + 5.2 Configure-Ack ...............................................30 + 5.3 Configure-Nak ...............................................31 + 5.4 Configure-Reject ............................................33 + 5.5 Terminate-Request and Terminate-Ack .........................34 + 5.6 Code-Reject .................................................35 + 5.7 Protocol-Reject .............................................36 + 5.8 Echo-Request and Echo-Reply .................................37 + 5.9 Discard-Request .............................................39 + 6. LCP Configuration Options ...................................40 + 6.1 Maximum-Receive-Unit ........................................41 + 6.2 Async-Control-Character-Map .................................42 + 6.3 Authentication-Protocol .....................................43 + 6.4 Quality-Protocol ............................................45 + 6.5 Magic-Number ................................................46 + 6.6 Protocol-Field-Compression ..................................49 + 6.7 Address-and-Control-Field-Compression .......................50 + APPENDIX A. LCP Recommended Options ..............................51 + SECURITY CONSIDERATIONS ..........................................51 + REFERENCES .......................................................52 + ACKNOWLEDGEMENTS .................................................52 + CHAIR'S ADDRESS ..................................................52 + EDITOR'S ADDRESS .................................................53 + + + + +Simpson [Page 2] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +1. Introduction + + Encapsulation + + The PPP encapsulation provides for multiplexing of different + network-layer protocols simultaneously over the same link. It is + intended that PPP provide a common solution for easy connection of + a wide variety of hosts, bridges and routers [1]. + + The PPP encapsulation has been carefully designed to retain + compatibility with most commonly used supporting hardware. + + Only 8 additional octets are necessary to form the encapsulation + when used with the default HDLC framing. In environments where + bandwidth is at a premium, the encapsulation and framing may be + shortened to 2 or 4 octets. + + To support high speed implementations, the default encapsulation + uses only simple fields, only one of which needs to be examined + for demultiplexing. The default header and information fields + fall on 32-bit boundaries, and the trailer may be padded to an + arbitrary boundary. + + Link Control Protocol + + In order to be sufficiently versatile to be portable to a wide + variety of environments, PPP provides a Link Control Protocol + (LCP). The LCP is used to automatically agree upon the + encapsulation format options, handle varying limits on sizes of + packets, authenticate the identity of its peer on the link, + determine when a link is functioning properly and when it is + defunct, detect a looped-back link and other common + misconfiguration errors, and terminate the link. + + Network Control Protocols + + Point-to-Point links tend to exacerbate many problems with the + current family of network protocols. For instance, assignment and + management of IP addresses, which is a problem even in LAN + environments, is especially difficult over circuit-switched + point-to-point links (such as dial-up modem servers). These + problems are handled by a family of Network Control Protocols + (NCPs), which each manage the specific needs required by their + respective network-layer protocols. These NCPs are defined in + companion documents. + + + + + + +Simpson [Page 3] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Configuration + + It is intended that PPP links be easy to configure. By design, + the standard defaults handle all common configurations. The + implementor can specify improvements to the default configuration, + which are automatically communicated to the peer without operator + intervention. Finally, the operator may explicitly configure + options for the link which enable the link to operate in + environments where it would otherwise be impossible. + + This self-configuration is implemented through an extensible + option negotiation mechanism, wherein each end of the link + describes to the other its capabilities and requirements. + Although the option negotiation mechanism described in this + document is specified in terms of the Link Control Protocol (LCP), + the same facilities are designed to be used by other control + protocols, especially the family of NCPs. + +1.1 Specification of Requirements + + In this document, several words are used to signify the + requirements of the specification. These words are often + capitalized. + + MUST + + This word, or the adjective "required", means that the definition + is an absolute requirement of the specification. + + MUST NOT + + This phrase means that the definition is an absolute prohibition + of the specification. + + SHOULD + + This word, or the adjective "recommended", means that there may + exist valid reasons in particular circumstances to ignore this + item, but the full implications must be understood and carefully + weighed before choosing a different course. + + MAY + + This word, or the adjective "optional", means that this item is + one of an allowed set of alternatives. An implementation which + does not include this option MUST be prepared to interoperate with + another implementation which does include the option. + + + + +Simpson [Page 4] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +1.2 Terminology + + This document frequently uses the following terms: + + datagram + + The unit of transmission in the network layer (such as IP). A + datagram may be encapsulated in one or more packets passed to the + data link layer. + + frame + + The unit of transmission at the data link layer. A frame may + include a header and/or a trailer, along with some number of units + of data. + + packet + + The basic unit of encapsulation, which is passed across the + interface between the network layer and the data link layer. A + packet is usually mapped to a frame; the exceptions are when data + link layer fragmentation is being performed, or when multiple + packets are incorporated into a single frame. + + peer + + The other end of the point-to-point link. + + silently discard + + This means the implementation discards the packet without further + processing. The implementation SHOULD provide the capability of + logging the error, including the contents of the silently + discarded packet, and SHOULD record the event in a statistics + counter. + +2. PPP Encapsulation + + The PPP encapsulation is used to disambiguate multiprotocol + datagrams. This encapsulation requires framing to indicate the + beginning and end of the encapsulation. Methods of providing framing + are specified in companion documents. + + + + + + + + + +Simpson [Page 5] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + A summary of the PPP encapsulation is shown below. The fields are + transmitted from left to right. + + +----------+-------------+---------+ + | Protocol | Information | Padding | + | 16 bits | * | * | + +----------+-------------+---------+ + + Protocol Field + + The Protocol field is two octets and its value identifies the + datagram encapsulated in the Information field of the packet. The + field is transmitted and received most significant octet first. + + The structure of this field is consistent with the ISO 3309 + extension mechanism for address fields. All Protocols MUST be + odd; the least significant bit of the least significant octet MUST + equal "1". Also, all Protocols MUST be assigned such that the + least significant bit of the most significant octet equals "0". + Frames received which don't comply with these rules MUST be + treated as having an unrecognized Protocol. + + Protocol field values in the "0***" to "3***" range identify the + network-layer protocol of specific packets, and values in the + "8***" to "b***" range identify packets belonging to the + associated Network Control Protocols (NCPs), if any. + + Protocol field values in the "4***" to "7***" range are used for + protocols with low volume traffic which have no associated NCP. + Protocol field values in the "c***" to "f***" range identify + packets as link-layer Control Protocols (such as LCP). + + Up-to-date values of the Protocol field are specified in the most + recent "Assigned Numbers" RFC [2]. Current values are assigned as + follows: + + Value (in hex) Protocol Name + + 0001 Padding Protocol + 0003 to 001f reserved (transparency inefficient) + 0021 Internet Protocol + 0023 OSI Network Layer + 0025 Xerox NS IDP + 0027 DECnet Phase IV + 0029 Appletalk + 002b Novell IPX + 002d Van Jacobson Compressed TCP/IP + 002f Van Jacobson Uncompressed TCP/IP + + + +Simpson [Page 6] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 0031 Bridging PDU + 0033 Stream Protocol (ST-II) + 0035 Banyan Vines + 0037 unused + 0039 AppleTalk EDDP + 003b AppleTalk SmartBuffered + 003d Multi-Link + 005d reserved (compression inefficient) + 00cf reserved (PPP NLPID) + 00fd 1st choice compression + 00ff reserved (compression inefficient) + + 0201 802.1d Hello Packets + 0203 IBM Source Routing BPDU + 0231 Luxcom + 0233 Sigma Network Systems + + 8021 Internet Protocol Control Protocol + 8023 OSI Network Layer Control Protocol + 8025 Xerox NS IDP Control Protocol + 8027 DECnet Phase IV Control Protocol + 8029 Appletalk Control Protocol + 802b Novell IPX Control Protocol + 802d Reserved + 802f Reserved + 8031 Bridging NCP + 8033 Stream Protocol Control Protocol + 8035 Banyan Vines Control Protocol + 8037 unused + 8039 Reserved + 803b Reserved + 803d Multi-Link Control Protocol + 80fd Compression Control Protocol + 80ff Reserved + + c021 Link Control Protocol + c023 Password Authentication Protocol + c025 Link Quality Report + c223 Challenge Handshake Authentication Protocol + + Developers of new protocols MUST obtain a number from the Internet + Assigned Numbers Authority (IANA), at IANA@isi.edu. + + Information Field + + The Information field is zero or more octets. The Information + field contains the datagram for the protocol specified in the + Protocol field. + + + +Simpson [Page 7] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + The maximum length for the Information field, including Padding, + is termed the Maximum Receive Unit (MRU), which defaults to 1500 + octets. By negotiation, consenting PPP implementations may use + other values for the MRU. + + Padding + + On transmission, the Information field MAY be padded with an + arbitrary number of octets up to the MRU. It is the + responsibility of each protocol to distinguish padding octets from + real information. + +3. PPP Link Operation + +3.1 Overview + + In order to establish communications over a point-to-point link, each + end of the PPP link MUST first send LCP packets to configure and test + the data link. After the link has been established, the peer MAY be + authenticated. Then, PPP MUST send NCP packets to choose and + configure one or more network-layer protocols. Once each of the + chosen network-layer protocols has been configured, datagrams from + each network-layer protocol can be sent over the link. + + The link will remain configured for communications until explicit LCP + or NCP packets close the link down, or until some external event + occurs (an inactivity timer expires or network administrator + intervention). + +3.2 Phase Diagram + + In the process of configuring, maintaining and terminating the + point-to-point link, the PPP link goes through several distinct + phases: + + +------+ +-----------+ +--------------+ + | | UP | | OPENED | | SUCCESS/NONE + | Dead |------->| Establish |---------->| Authenticate |--+ + | | | | | | | + +------+ +-----------+ +--------------+ | + ^ FAIL | FAIL | | + +<--------------+ +----------+ | + | | | + | +-----------+ | +---------+ | + | DOWN | | | CLOSING | | | + +------------| Terminate |<---+<----------| Network |<-+ + | | | | + +-----------+ +---------+ + + + +Simpson [Page 8] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +3.3 Link Dead (physical-layer not ready) + + The link necessarily begins and ends with this phase. When an + external event (such as carrier detection or network administrator + configuration) indicates that the physical-layer is ready to be used, + PPP will proceed to the Link Establishment phase. + + During this phase, the LCP automaton (described below) will be in the + Initial or Starting states. The transition to the Link Establishment + phase will signal an Up event to the automaton. + + Implementation Note: + + Typically, a link will return to this phase automatically after + the disconnection of a modem. In the case of a hard-wired line, + this phase may be extremely short -- merely long enough to detect + the presence of the device. + +3.4 Link Establishment Phase + + The Link Control Protocol (LCP) is used to establish the connection + through an exchange of Configure packets. This exchange is complete, + and the LCP Opened state entered, once a Configure-Ack packet + (described below) has been both sent and received. + + All Configuration Options are assumed to be at default values unless + altered by the configuration exchange. See the section on LCP + Configuration Options for further discussion. + + It is important to note that only Configuration Options which are + independent of particular network-layer protocols are configured by + LCP. Configuration of individual network-layer protocols is handled + by separate Network Control Protocols (NCPs) during the Network-Layer + Protocol phase. + + Any non-LCP packets received during this phase MUST be silently + discarded. + +3.5 Authentication Phase + + On some links it may be desirable to require a peer to authenticate + itself before allowing network-layer protocol packets to be + exchanged. + + By default, authentication is not mandatory. If an implementation + desires that the peer authenticate with some specific authentication + protocol, then it MUST negotiate the use of that authentication + protocol during Link Establishment phase. + + + +Simpson [Page 9] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Authentication SHOULD take place as soon as possible after link + establishment. However, link quality determination MAY occur + concurrently. An implementation MUST NOT allow the exchange of link + quality determination packets to delay authentication indefinitely. + + Advancement from the Authentication phase to the Network-Layer + Protocol phase MUST NOT occur until authentication has completed, + using the negotiated authentication protocol. If authentication + fails, PPP SHOULD proceed instead to the Link Termination phase. + + Any Network Control Protocol or network-layer protocol packets + received during this phase MUST be silently discarded. + +3.6 Network-Layer Protocol Phase + + Once PPP has finished the previous phases, each network-layer + protocol (such as IP, IPX, or AppleTalk) MUST be separately + configured by the appropriate Network Control Protocol (NCP). + + Each NCP MAY be Opened and Closed at any time. + + Implementation Note: + + Because an implementation may initially use a significant amount + of time for link quality determination, implementations SHOULD + avoid fixed timeouts when waiting for their peers to configure a + NCP. + + After a NCP has reached the Opened state, PPP will carry the + corresponding network-layer protocol packets. Any network-layer + protocol packets received when the corresponding NCP is not in the + Opened state MUST be silently discarded. + + Implementation Note: + + There is an exception to the preceding paragraphs, due to the + availability of the LCP Protocol-Reject (described below). While + LCP is in the Opened state, any protocol packet which is + unsupported by the implementation MUST be returned in a Protocol- + Reject. Only protocols which are supported are silently + discarded. + + During this phase, link traffic consists of any possible + combination of LCP, NCP, and network-layer protocol packets. + +3.7 Link Termination Phase + + PPP can terminate the link at any time. This might happen because of + + + +Simpson [Page 10] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + the loss of carrier, authentication failure, link quality failure, + the expiration of an idle-period timer, or the administrative closing + of the link. LCP is used to close the link through an exchange of + Terminate packets. When the link is closing, PPP informs the + network-layer protocols so that they may take appropriate action. + + After the exchange of Terminate packets, the implementation SHOULD + signal the physical-layer to disconnect in order to enforce the + termination of the link, particularly in the case of an + authentication failure. The sender of the Terminate-Request SHOULD + disconnect after receiving a Terminate-Ack, or after the Restart + counter expires. The receiver of a Terminate-Request SHOULD wait for + the peer to disconnect, and MUST NOT disconnect until at least one + Restart time has passed after sending a Terminate-Ack. PPP SHOULD + proceed to the Link Dead phase. + + Any non-LCP packets received during this phase MUST be silently + discarded. + + Implementation Note: + + The closing of the link by LCP is sufficient. There is no need + for each NCP to send a flurry of Terminate packets. Conversely, + the fact that one NCP has Closed is not sufficient reason to cause + the termination of the PPP link, even if that NCP was the only NCP + currently in the Opened state. + +4. The Option Negotiation Automaton + + The finite-state automaton is defined by events, actions and state + transitions. Events include reception of external commands such as + Open and Close, expiration of the Restart timer, and reception of + packets from a peer. Actions include the starting of the Restart + timer and transmission of packets to the peer. + + Some types of packets -- Configure-Naks and Configure-Rejects, or + Code-Rejects and Protocol-Rejects, or Echo-Requests, Echo-Replies and + Discard-Requests -- are not differentiated in the automaton + descriptions. As will be described later, these packets do indeed + serve different functions. However, they always cause the same + transitions. + +Events Actions + +Up = lower layer is Up tlu = This-Layer-Up +Down = lower layer is Down tld = This-Layer-Down +Open = administrative Open tls = This-Layer-Started +Close= administrative Close tlf = This-Layer-Finished + + + +Simpson [Page 11] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +TO+ = Timeout with counter > 0 irc = Initialize-Restart-Counter +TO- = Timeout with counter expired zrc = Zero-Restart-Counter + +RCR+ = Receive-Configure-Request (Good) scr = Send-Configure-Request +RCR- = Receive-Configure-Request (Bad) +RCA = Receive-Configure-Ack sca = Send-Configure-Ack +RCN = Receive-Configure-Nak/Rej scn = Send-Configure-Nak/Rej + +RTR = Receive-Terminate-Request str = Send-Terminate-Request +RTA = Receive-Terminate-Ack sta = Send-Terminate-Ack + +RUC = Receive-Unknown-Code scj = Send-Code-Reject +RXJ+ = Receive-Code-Reject (permitted) + or Receive-Protocol-Reject +RXJ- = Receive-Code-Reject (catastrophic) + or Receive-Protocol-Reject +RXR = Receive-Echo-Request ser = Send-Echo-Reply + or Receive-Echo-Reply + or Receive-Discard-Request + +4.1 State Diagram + + The simplified state diagram which follows describes the sequence of + events for reaching agreement on Configuration Options (opening the + PPP link) and for later termination of the link. + + This diagram is not a complete representation of the automaton. + Implementation MUST be done by consulting the actual state transition + table. + + Events are in upper case. Actions are in lower case. For these + purposes, the state machine is initially in the Closed state. Once + the Opened state has been reached, both ends of the link have met the + requirement of having both sent and received a Configure-Ack packet. + + + + + + + + + + + + + + + + + +Simpson [Page 12] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + RCR TO+ + +--sta-->+ +------->+ + | | | | + +-------+ | RTA +-------+ | Close +-------+ + | |<-----+<------| |<-str-+<------| | + |Closed | |Closing| |Opened | + | | Open | | | | + | |------+ | | | | + +-------+ | +-------+ +-------+ + | ^ + | | + | +-sca----------------->+ + | | ^ + RCN,TO+ V RCR+ | RCR- RCA | RCN,TO+ + +------->+ | +------->+ | +--scr-->+ + | | | | | | | | + +-------+ | TO+ +-------+ | +-------+ | + | |<-scr-+<------| |<-scn-+ | |<-----+ + | Req- | | Ack- | | Ack- | + | Sent | RCA | Rcvd | | Sent | + +-scn->| |------------->| | +-sca->| | + | +-------+ +-------+ | +-------+ + | RCR- | | RCR+ | RCR+ | | RCR- + | | +------------------------------->+<-------+ | + | | | + +<-------+<------------------------------------------------+ + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 13] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +4.2 State Transition Table + + The complete state transition table follows. States are indicated + horizontally, and events are read vertically. State transitions and + actions are represented in the form action/new-state. Multiple + actions are separated by commas, and may continue on succeeding lines + as space requires; multiple actions may be implemented in any + convenient order. The state may be followed by a letter, which + indicates an explanatory footnote. The dash ('-') indicates an + illegal transition. + + + | State + | 0 1 2 3 4 5 + Events| Initial Starting Closed Stopped Closing Stopping + ------+----------------------------------------------------------- + Up | 2 irc,scr/6 - - - - + Down | - - 0 tls/1 0 1 + Open | tls/1 1 irc,scr/6 3r 5r 5r + Close| 0 0 2 2 4 4 + | + TO+ | - - - - str/4 str/5 + TO- | - - - - tlf/2 tlf/3 + | + RCR+ | - - sta/2 irc,scr,sca/8 4 5 + RCR- | - - sta/2 irc,scr,scn/6 4 5 + RCA | - - sta/2 sta/3 4 5 + RCN | - - sta/2 sta/3 4 5 + | + RTR | - - sta/2 sta/3 sta/4 sta/5 + RTA | - - 2 3 tlf/2 tlf/3 + | + RUC | - - scj/2 scj/3 scj/4 scj/5 + RXJ+ | - - 2 3 4 5 + RXJ- | - - tlf/2 tlf/3 tlf/2 tlf/3 + | + RXR | - - 2 3 4 5 + + + + + + + + + + + + + + +Simpson [Page 14] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + | State + | 6 7 8 9 + Events| Req-Sent Ack-Rcvd Ack-Sent Opened + ------+----------------------------------------- + Up | - - - - + Down | 1 1 1 tld/1 + Open | 6 7 8 9r + Close|irc,str/4 irc,str/4 irc,str/4 tld,irc,str/4 + | + TO+ | scr/6 scr/6 scr/8 - + TO- | tlf/3p tlf/3p tlf/3p - + | + RCR+ | sca/8 sca,tlu/9 sca/8 tld,scr,sca/8 + RCR- | scn/6 scn/7 scn/6 tld,scr,scn/6 + RCA | irc/7 scr/6x irc,tlu/9 tld,scr/6x + RCN |irc,scr/6 scr/6x irc,scr/8 tld,scr/6x + | + RTR | sta/6 sta/6 sta/6 tld,zrc,sta/5 + RTA | 6 6 8 tld,scr/6 + | + RUC | scj/6 scj/7 scj/8 scj/9 + RXJ+ | 6 6 8 9 + RXJ- | tlf/3 tlf/3 tlf/3 tld,irc,str/5 + | + RXR | 6 7 8 ser/9 + + The states in which the Restart timer is running are identifiable by + the presence of TO events. Only the Send-Configure-Request, Send- + Terminate-Request and Zero-Restart-Counter actions start or re-start + the Restart timer. The Restart timer is stopped when transitioning + from any state where the timer is running to a state where the timer + is not running. + + [p] Passive option; see Stopped state discussion. + + [r] Restart option; see Open event discussion. + + [x] Crossed connection; see RCA event discussion. + +4.3 A Day in the Life + + Here is an example of how a typical implementation might use the + automaton to implement LCP in a dial-up environment: + + - The Network Access Server is powered on (Initial state, Link Dead + phase). + + - A configuration file indicates that a particular link is to be + + + +Simpson [Page 15] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + used for PPP access (Open: tls/Starting). The This-Layer-Started + event turns on DTR to a modem, readying it for accepting calls. + + - An incoming call is answered. The modem CD triggers configuration + negotiation (Up: irc,scr/Req-Sent, Link Establishment phase). + + - A Configure-Request is received, which is acknowleged (RCR+: + sca/Ack-Sent). + + - The Request is acknowleged (RCA: irc,tlu/Opened). The This- + Layer-Up event starts authentication and quality monitoring + protocols (Authentication phase). + + - When authentication and quality monitoring are satisfied, they + send an Up event to start the available NCPs (Network-Layer + Protocol phase). + + - Later, the peer is finished, and closes the link. A Terminate- + Request arrives (RTR: tld,zrc,sta/Stopping, Termination phase). + The This-Layer-Down action sends the Down event to any NCPs, while + the Terminate-Ack is sent. The Zero-Restart-Counter action causes + the link to wait for the peer to process the Terminate-Ack, with + no retries. + + - When the Restart Timer times out (TO-: tlf/Stopped), the This- + Layer-Finished action signals the modem to hang up by dropping + DTR. + + - When the CD from the modem drops (Down: tls/Starting), the This- + Layer-Started action raises DTR again, readying it for the next + call (returning to the Link Dead phase). + +4.4 States + + Following is a more detailed description of each automaton state. + + Initial + + In the Initial state, the lower layer is unavailable (Down), and + no Open has occurred. The Restart timer is not running in the + Initial state. + + Starting + + The Starting state is the Open counterpart to the Initial state. + An administrative Open has been initiated, but the lower layer is + still unavailable (Down). The Restart timer is not running in the + Starting state. + + + +Simpson [Page 16] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + When the lower layer becomes available (Up), a Configure-Request + is sent. + + Closed + + In the Closed state, the link is available (Up), but no Open has + occurred. The Restart timer is not running in the Closed state. + + Upon reception of Configure-Request packets, a Terminate-Ack is + sent. Terminate-Acks are silently discarded to avoid creating a + loop. + + Stopped + + The Stopped state is the Open counterpart to the Closed state. It + is entered when the automaton is waiting for a Down event after + the This-Layer-Finished action, or after sending a Terminate-Ack. + The Restart timer is not running in the Stopped state. + + Upon reception of Configure-Request packets, an appropriate + response is sent. Upon reception of other packets, a Terminate- + Ack is sent. Terminate-Acks are silently discarded to avoid + creating a loop. + + Rationale: + + The Stopped state is a junction state for link termination, link + configuration failure, and other automaton failure modes. These + potentially separate states have been combined. + + There is a race condition between the Down event response (from + the This-Layer-Finished action) and the Receive-Configure- Request + event. When a Configure-Request arrives before the Down event, + the Down event will supercede by returning the automaton to the + Starting state. This prevents attack by repetition. + + Implementation Option: + + After the peer fails to respond to Configure-Requests, an + implementation MAY wait passively for the peer to send Configure- + Requests. In this case, the This-Layer-Finished action is not + used for the TO- event in states Req-Sent, Ack- Rcvd and Ack-Sent. + + This option is useful for dedicated circuits, or circuits which + have no status signals available, but SHOULD NOT be used for + switched circuits. + + + + + +Simpson [Page 17] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Closing + + In the Closing state, an attempt is made to terminate the + connection. A Terminate-Request has been sent and the Restart + timer is running, but a Terminate-Ack has not yet been received. + + Upon reception of a Terminate-Ack, the Closed state is entered. + Upon the expiration of the Restart timer, a new Terminate-Request + is transmitted and the Restart timer is restarted. After the + Restart timer has expired Max-Terminate times, this action may be + skipped, and the Closed state may be entered. + + Stopping + + The Stopping state is the Open counterpart to the Closing state. + A Terminate-Request has been sent and the Restart timer is + running, but a Terminate-Ack has not yet been received. + + Rationale: + + The Stopping state provides a well defined opportunity to + terminate a link before allowing new traffic. After the link has + terminated, a new configuration may occur via the Stopped or + Starting states. + + Request-Sent + + In the Request-Sent state an attempt is made to configure the + connection. A Configure-Request has been sent and the Restart + timer is running, but a Configure-Ack has not yet been received + nor has one been sent. + + Ack-Received + + In the Ack-Received state, a Configure-Request has been sent and a + Configure-Ack has been received. The Restart timer is still + running since a Configure-Ack has not yet been sent. + + Ack-Sent + + In the Ack-Sent state, a Configure-Request and a Configure-Ack + have both been sent but a Configure-Ack has not yet been received. + The Restart timer is always running in the Ack-Sent state. + + Opened + + In the Opened state, a Configure-Ack has been both sent and + received. The Restart timer is not running in the Opened state. + + + +Simpson [Page 18] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + When entering the Opened state, the implementation SHOULD signal + the upper layers that it is now Up. Conversely, when leaving the + Opened state, the implementation SHOULD signal the upper layers + that it is now Down. + +4.5 Events + + Transitions and actions in the automaton are caused by events. + + Up + + The Up event occurs when a lower layer indicates that it is ready + to carry packets. + + Typically, this event is used by a modem handling or calling + process, or by some other coupling of the PPP link to the physical + media, to signal LCP that the link is entering Link Establishment + phase. + + It also can be used by LCP to signal each NCP that the link is + entering Network-Layer Protocol phase. That is, the This-Layer-Up + action from LCP triggers the Up event in the NCP. + + Down + + The Down event occurs when a lower layer indicates that it is no + longer ready to carry packets. + + Typically, this event is used by a modem handling or calling + process, or by some other coupling of the PPP link to the physical + media, to signal LCP that the link is entering Link Dead phase. + + It also can be used by LCP to signal each NCP that the link is + leaving Network-Layer Protocol phase. That is, the This-Layer- + Down action from LCP triggers the Down event in the NCP. + + Open + + The Open event indicates that the link is administratively + available for traffic; that is, the network administrator (human + or program) has indicated that the link is allowed to be Opened. + When this event occurs, and the link is not in the Opened state, + the automaton attempts to send configuration packets to the peer. + + If the automaton is not able to begin configuration (the lower + layer is Down, or a previous Close event has not completed), the + establishment of the link is automatically delayed. + + + + +Simpson [Page 19] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + When a Terminate-Request is received, or other events occur which + cause the link to become unavailable, the automaton will progress + to a state where the link is ready to re-open. No additional + administrative intervention is necessary. + + Implementation Option: + + Experience has shown that users will execute an additional Open + command when they want to renegotiate the link. This might + indicate that new values are to be negotiated. + + Since this is not the meaning of the Open event, it is suggested + that when an Open user command is executed in the Opened, Closing, + Stopping, or Stopped states, the implementation issue a Down + event, immediately followed by an Up event. This will cause the + renegotiation of the link, without any harmful side effects. + + Close + + The Close event indicates that the link is not available for + traffic; that is, the network administrator (human or program) has + indicated that the link is not allowed to be Opened. When this + event occurs, and the link is not in the Closed state, the + automaton attempts to terminate the connection. Futher attempts + to re-configure the link are denied until a new Open event occurs. + + Implementation Note: + + When authentication fails, the link SHOULD be terminated, to + prevent attack by repetition and denial of service to other users. + Since the link is administratively available (by definition), this + can be accomplished by simulating a Close event to the LCP, + immediately followed by an Open event. + + The Close followed by an Open will cause an orderly termination of + the link, by progressing from the Closing to the Stopping state, + and the This-Layer-Finished action can disconnect the link. The + automaton waits in the Stopped or Starting states for the next + connection attempt. + + Timeout (TO+,TO-) + + This event indicates the expiration of the Restart timer. The + Restart timer is used to time responses to Configure-Request and + Terminate-Request packets. + + The TO+ event indicates that the Restart counter continues to be + greater than zero, which triggers the corresponding Configure- + + + +Simpson [Page 20] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Request or Terminate-Request packet to be retransmitted. + + The TO- event indicates that the Restart counter is not greater + than zero, and no more packets need to be retransmitted. + + Receive-Configure-Request (RCR+,RCR-) + + This event occurs when a Configure-Request packet is received from + the peer. The Configure-Request packet indicates the desire to + open a connection and may specify Configuration Options. The + Configure-Request packet is more fully described in a later + section. + + The RCR+ event indicates that the Configure-Request was + acceptable, and triggers the transmission of a corresponding + Configure-Ack. + + The RCR- event indicates that the Configure-Request was + unacceptable, and triggers the transmission of a corresponding + Configure-Nak or Configure-Reject. + + Implementation Note: + + These events may occur on a connection which is already in the + Opened state. The implementation MUST be prepared to immediately + renegotiate the Configuration Options. + + Receive-Configure-Ack (RCA) + + The Receive-Configure-Ack event occurs when a valid Configure-Ack + packet is received from the peer. The Configure-Ack packet is a + positive response to a Configure-Request packet. An out of + sequence or otherwise invalid packet is silently discarded. + + Implementation Note: + + Since the correct packet has already been received before reaching + the Ack-Rcvd or Opened states, it is extremely unlikely that + another such packet will arrive. As specified, all invalid + Ack/Nak/Rej packets are silently discarded, and do not affect the + transitions of the automaton. + + However, it is not impossible that a correctly formed packet will + arrive through a coincidentally-timed cross-connection. It is + more likely to be the result of an implementation error. At the + very least, this occurance SHOULD be logged. + + + + + +Simpson [Page 21] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Receive-Configure-Nak/Rej (RCN) + + This event occurs when a valid Configure-Nak or Configure-Reject + packet is received from the peer. The Configure-Nak and + Configure-Reject packets are negative responses to a Configure- + Request packet. An out of sequence or otherwise invalid packet is + silently discarded. + + Implementation Note: + + Although the Configure-Nak and Configure-Reject cause the same + state transition in the automaton, these packets have + significantly different effects on the Configuration Options sent + in the resulting Configure-Request packet. + + Receive-Terminate-Request (RTR) + + The Receive-Terminate-Request event occurs when a Terminate- + Request packet is received. The Terminate-Request packet + indicates the desire of the peer to close the connection. + + Implementation Note: + + This event is not identical to the Close event (see above), and + does not override the Open commands of the local network + administrator. The implementation MUST be prepared to receive a + new Configure-Request without network administrator intervention. + + Receive-Terminate-Ack (RTA) + + The Receive-Terminate-Ack event occurs when a Terminate-Ack packet + is received from the peer. The Terminate-Ack packet is usually a + response to a Terminate-Request packet. The Terminate-Ack packet + may also indicate that the peer is in Closed or Stopped states, + and serves to re-synchronize the link configuration. + + Receive-Unknown-Code (RUC) + + The Receive-Unknown-Code event occurs when an un-interpretable + packet is received from the peer. A Code-Reject packet is sent in + response. + + Receive-Code-Reject, Receive-Protocol-Reject (RXJ+,RXJ-) + + This event occurs when a Code-Reject or a Protocol-Reject packet + is received from the peer. + + The RXJ+ event arises when the rejected value is acceptable, such + + + +Simpson [Page 22] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + as a Code-Reject of an extended code, or a Protocol-Reject of a + NCP. These are within the scope of normal operation. The + implementation MUST stop sending the offending packet type. + + The RXJ- event arises when the rejected value is catastrophic, + such as a Code-Reject of Configure-Request, or a Protocol-Reject + of LCP! This event communicates an unrecoverable error that + terminates the connection. + + Receive-Echo-Request, Receive-Echo-Reply, Receive-Discard-Request + (RXR) + + This event occurs when an Echo-Request, Echo-Reply or Discard- + Request packet is received from the peer. The Echo-Reply packet is + a response to a Echo-Request packet. There is no reply to an Echo- + Reply or Discard-Request packet. + +4.6 Actions + + Actions in the automaton are caused by events and typically indicate + the transmission of packets and/or the starting or stopping of the + Restart timer. + + Illegal-Event (-) + + This indicates an event that cannot occur in a properly + implemented automaton. The implementation has an internal error, + which should be reported and logged. No transition is taken, and + the implementation SHOULD NOT reset or freeze. + + This-Layer-Up (tlu) + + This action indicates to the upper layers that the automaton is + entering the Opened state. + + Typically, this action is used by the LCP to signal the Up event + to a NCP, Authentication Protocol, or Link Quality Protocol, or + MAY be used by a NCP to indicate that the link is available for + its network layer traffic. + + This-Layer-Down (tld) + + This action indicates to the upper layers that the automaton is + leaving the Opened state. + + Typically, this action is used by the LCP to signal the Down event + to a NCP, Authentication Protocol, or Link Quality Protocol, or + MAY be used by a NCP to indicate that the link is no longer + + + +Simpson [Page 23] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + available for its network layer traffic. + + This-Layer-Started (tls) + + This action indicates to the lower layers that the automaton is + entering the Starting state, and the lower layer is needed for the + link. The lower layer SHOULD respond with an Up event when the + lower layer is available. + + Implementation Note: + + This results of this action are highly implementation dependent. + + The transitions where this event is indicated are defined + according to a message passing architecture, rather than a + signalling architecture. If the action is desired to control + specific signals (such as DTR), other transitions for the action + are likely to be required (Open in Closed, RCR in Stopped). + + This-Layer-Finished (tlf) + + This action indicates to the lower layers that the automaton is + entering the Stopped or Closed states, and the lower layer is no + longer needed for the link. The lower layer SHOULD respond with a + Down event when the lower layer has terminated. + + Typically, this action MAY be used by the LCP to advance to the + Link Dead phase, or MAY be used by a NCP to indicate to the LCP + that the link may terminate when there are no other NCPs open. + + Implementation Note: + + This results of this action are highly implementation dependent. + + The transitions where this event is indicated are defined + according to a message passing architecture, rather than a + signalling architecture. If the action is desired to control + specific signals (such as DTR), other transitions for the action + are likely to be required (Close in Starting, Down in Closing). + + Initialize-Restart-Counter (irc) + + This action sets the Restart counter to the appropriate value + (Max-Terminate or Max-Configure). The counter is decremented for + each transmission, including the first. + + + + + + +Simpson [Page 24] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Implementation Note: + + In addition to setting the Restart counter, the implementation + MUST set the timeout period to the initial value when Restart + timer backoff is used. + + Zero-Restart-Counter (zrc) + + This action sets the Restart counter to zero. + + Implementation Note: + + This action enables the FSA to pause before proceeding to the + desired final state, allowing traffic to be processed by the peer. + In addition to zeroing the Restart counter, the implementation + MUST set the timeout period to an appropriate value. + + Send-Configure-Request (scr) + + The Send-Configure-Request action transmits a Configure-Request + packet. This indicates the desire to open a connection with a + specified set of Configuration Options. The Restart timer is + started when the Configure-Request packet is transmitted, to guard + against packet loss. The Restart counter is decremented each time + a Configure-Request is sent. + + Send-Configure-Ack (sca) + + The Send-Configure-Ack action transmits a Configure-Ack packet. + This acknowledges the reception of a Configure-Request packet with + an acceptable set of Configuration Options. + + Send-Configure-Nak (scn) + + The Send-Configure-Nak action transmits a Configure-Nak or + Configure-Reject packet, as appropriate. This negative response + reports the reception of a Configure-Request packet with an + unacceptable set of Configuration Options. Configure-Nak packets + are used to refuse a Configuration Option value, and to suggest a + new, acceptable value. Configure-Reject packets are used to + refuse all negotiation about a Configuration Option, typically + because it is not recognized or implemented. The use of + Configure-Nak versus Configure-Reject is more fully described in + the section on LCP Packet Formats. + + Send-Terminate-Request (str) + + The Send-Terminate-Request action transmits a Terminate-Request + + + +Simpson [Page 25] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + packet. This indicates the desire to close a connection. The + Restart timer is started when the Terminate-Request packet is + transmitted, to guard against packet loss. The Restart counter is + decremented each time a Terminate-Request is sent. + + Send-Terminate-Ack (sta) + + The Send-Terminate-Ack action transmits a Terminate-Ack packet. + This acknowledges the reception of a Terminate-Request packet or + otherwise serves to synchronize the state machines. + + Send-Code-Reject (scj) + + The Send-Code-Reject action transmits a Code-Reject packet. This + indicates the reception of an unknown type of packet. + + Send-Echo-Reply (ser) + + The Send-Echo-Reply action transmits an Echo-Reply packet. This + acknowledges the reception of an Echo-Request packet. + +4.7 Loop Avoidance + + The protocol makes a reasonable attempt at avoiding Configuration + Option negotiation loops. However, the protocol does NOT guarantee + that loops will not happen. As with any negotiation, it is possible + to configure two PPP implementations with conflicting policies that + will never converge. It is also possible to configure policies which + do converge, but which take significant time to do so. Implementors + should keep this in mind and SHOULD implement loop detection + mechanisms or higher level timeouts. + + +4.8 Counters and Timers + + Restart Timer + + There is one special timer used by the automaton. The Restart + timer is used to time transmissions of Configure-Request and + Terminate- Request packets. Expiration of the Restart timer + causes a Timeout event, and retransmission of the corresponding + Configure-Request or Terminate-Request packet. The Restart timer + MUST be configurable, but SHOULD default to three (3) seconds. + + Implementation Note: + + The Restart timer SHOULD be based on the speed of the link. The + default value is designed for low speed (2,400 to 9,600 bps), high + + + +Simpson [Page 26] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + switching latency links (typical telephone lines). Higher speed + links, or links with low switching latency, SHOULD have + correspondingly faster retransmission times. + + Instead of a constant value, the Restart timer MAY begin at an + initial small value and increase to the configured final value. + Each successive value less than the final value SHOULD be at least + twice the previous value. The initial value SHOULD be large + enough to account for the size of the packets, twice the round + trip time for transmission at the link speed, and at least an + additional 100 milliseconds to allow the peer to process the + packets before responding. Some circuits add another 200 + milliseconds of satellite delay. Round trip times for modems + operating at 14,400 bps have been measured in the range of 160 to + more than 600 milliseconds. + + Max-Terminate + + There is one required restart counter for Terminate-Requests. + Max- Terminate indicates the number of Terminate-Request packets + sent without receiving a Terminate-Ack before assuming that the + peer is unable to respond. Max-Terminate MUST be configurable, + but SHOULD default to two (2) transmissions. + + Max-Configure + + A similar counter is recommended for Configure-Requests. Max- + Configure indicates the number of Configure-Request packets sent + without receiving a valid Configure-Ack, Configure-Nak or + Configure- Reject before assuming that the peer is unable to + respond. Max- Configure MUST be configurable, but SHOULD default + to ten (10) transmissions. + + Max-Failure + + A related counter is recommended for Configure-Nak. Max-Failure + indicates the number of Configure-Nak packets sent without sending + a Configure-Ack before assuming that configuration is not + converging. Any further Configure-Nak packets are converted to + Configure-Reject packets. Max-Failure MUST be configurable, but + SHOULD default to ten (10) transmissions. + +5. LCP Packet Formats + + There are three classes of LCP packets: + + 1. Link Configuration packets used to establish and configure a + link (Configure-Request, Configure-Ack, Configure-Nak and + + + +Simpson [Page 27] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Configure-Reject). + + 2. Link Termination packets used to terminate a link (Terminate- + Request and Terminate-Ack). + + 3. Link Maintenance packets used to manage and debug a link + (Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply, and + Discard-Request). + + This document describes Version 1 of the Link Control Protocol. In + the interest of simplicity, there is no version field in the LCP + packet. If a new version of LCP is necessary in the future, the + intention is that a new PPP Protocol field value will be used to + differentiate Version 1 LCP from all other versions. A correctly + functioning Version 1 LCP implementation will always respond to + unknown Protocols (including other versions) with an easily + recognizable Version 1 packet, thus providing a deterministic + fallback mechanism for implementations of other versions. + + Regardless of which Configuration Options are enabled, all LCP Link + Configuration, Link Termination, and Code-Reject packets (codes 1 + through 7) are always sent as if no Configuration Options were + enabled. This ensures that such LCP packets are always recognizable + even when one end of the link mistakenly believes the link to be + open. + + Implementation Note: + + In particular, the Async-Control-Character-Map (ACCM) default for + the type of link is used, and no address, control, or protocol + field compression is allowed. + + Exactly one LCP packet is encapsulated in the PPP Information + field, where the PPP Protocol field indicates type hex c021 (Link + Control Protocol). + + A summary of the Link Control Protocol packet format is shown below. + The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + + + + +Simpson [Page 28] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Code + + The Code field is one octet and identifies the kind of LCP packet. + When a packet is received with an invalid Code field, a Code- + Reject packet is transmitted. + + Up-to-date values of the LCP Code field are specified in the most + recent "Assigned Numbers" RFC [2]. This specification concerns + the following values: + + 1 Configure-Request + 2 Configure-Ack + 3 Configure-Nak + 4 Configure-Reject + 5 Terminate-Request + 6 Terminate-Ack + 7 Code-Reject + 8 Protocol-Reject + 9 Echo-Request + 10 Echo-Reply + 11 Discard-Request + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. When a packet is received with an invalid Identifier + field, the packet is silently discarded. + + Length + + The Length field is two octets and indicates the length of the LCP + packet including the Code, Identifier, Length and Data fields. + Octets outside the range of the Length field are treated as + padding and are ignored on reception. When a packet is received + with an invalid Length field, the packet is silently discarded. + + Data + + The Data field is zero or more octets as indicated by the Length + field. The format of the Data field is determined by the Code + field. + +5.1 Configure-Request + + Description + + An implementation wishing to open a connection MUST transmit a LCP + packet with the Code field set to 1 (Configure-Request), and the + + + +Simpson [Page 29] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Options field filled with any desired changes to the link + defaults. Configuration Options SHOULD NOT be included with + default values. + + Upon reception of a Configure-Request, an appropriate reply MUST + be transmitted. + + A summary of the Configure-Request packet format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+ + + Code + + 1 for Configure-Request. + + Identifier + + The Identifier field MUST be changed whenever the content of the + Options field changes, and whenever a valid reply has been + received for a previous request. For retransmissions, the + Identifier MAY remain unchanged. + + Options + + The options field is variable in length and contains the list of + zero or more Configuration Options that the sender desires to + negotiate. All Configuration Options are always negotiated + simultaneously. The format of Configuration Options is further + described in a later section. + +5.2 Configure-Ack + + Description + + If every Configuration Option received in a Configure-Request is + recognizable and all values are acceptable, then the + implementation MUST transmit a LCP packet with the Code field set + to 2 (Configure-Ack), the Identifier field copied from the + received Configure-Request, and the Options field copied from the + received Configure-Request. The acknowledged Configuration + Options MUST NOT be reordered or modified in any way. + + + +Simpson [Page 30] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + On reception of a Configure-Ack, the Identifier field MUST match + that of the last transmitted Configure-Request. Additionally, the + Configuration Options in a Configure-Ack MUST exactly match those + of the last transmitted Configure-Request. Invalid packets are + silently discarded. + + A summary of the Configure-Ack packet format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+ + + Code + + 2 for Configure-Ack. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Configure-Request which caused this Configure-Ack. + + Options + + The Options field is variable in length and contains the list of + zero or more Configuration Options that the sender is + acknowledging. All Configuration Options are always acknowledged + simultaneously. + +5.3 Configure-Nak + + Description + + If every element of the received Configuration Options is + recognizable but some values are not acceptable, then the + implementation MUST transmit a LCP packet with the Code field set + to 3 (Configure-Nak), the Identifier field copied from the + received Configure-Request, and the Options field filled with only + the unacceptable Configuration Options from the Configure-Request. + All acceptable Configuration Options are filtered out of the + Configure-Nak, but otherwise the Configuration Options from the + Configure-Request MUST NOT be reordered. + + Options which have no value fields (boolean options) MUST use the + + + +Simpson [Page 31] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Configure-Reject reply instead. + + Each Configuration Option which is allowed only a single instance + MUST be modified to a value acceptable to the Configure-Nak + sender. The default value MAY be used, when this differs from the + requested value. + + When a particular type of Configuration Option can be listed more + than once with different values, the Configure-Nak MUST include a + list of all values for that option which are acceptable to the + Configure-Nak sender. This includes acceptable values that were + present in the Configure-Request. + + Finally, an implementation may be configured to request the + negotiation of a specific Configuration Option. If that option is + not listed, then that option MAY be appended to the list of Nak'd + Configuration Options in order to prompt the peer to include that + option in its next Configure-Request packet. Any value fields for + the option MUST indicate values acceptable to the Configure-Nak + sender. + + On reception of a Configure-Nak, the Identifier field MUST match + that of the last transmitted Configure-Request. Invalid packets + are silently discarded. + + Reception of a valid Configure-Nak indicates that a new + Configure-Request MAY be sent with the Configuration Options + modified as specified in the Configure-Nak. When multiple + instances of a Configuration Option are present, the peer SHOULD + select a single value to include in its next Configure-Request + packet. + + Some Configuration Options have a variable length. Since the + Nak'd Option has been modified by the peer, the implementation + MUST be able to handle an Option length which is different from + the original Configure-Request. + + A summary of the Configure-Nak packet format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+ + + + + +Simpson [Page 32] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Code + + 3 for Configure-Nak. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Configure-Request which caused this Configure-Nak. + + Options + + The Options field is variable in length and contains the list of + zero or more Configuration Options that the sender is Nak'ing. + All Configuration Options are always Nak'd simultaneously. + +5.4 Configure-Reject + + Description + + If some Configuration Options received in a Configure-Request are + not recognizable or are not acceptable for negotiation (as + configured by a network administrator), then the implementation + MUST transmit a LCP packet with the Code field set to 4 + (Configure-Reject), the Identifier field copied from the received + Configure-Request, and the Options field filled with only the + unacceptable Configuration Options from the Configure-Request. + All recognizable and negotiable Configuration Options are filtered + out of the Configure-Reject, but otherwise the Configuration + Options MUST NOT be reordered or modified in any way. + + On reception of a Configure-Reject, the Identifier field MUST + match that of the last transmitted Configure-Request. + Additionally, the Configuration Options in a Configure-Reject MUST + be a proper subset of those in the last transmitted Configure- + Request. Invalid packets are silently discarded. + + Reception of a valid Configure-Reject indicates that a new + Configure-Request SHOULD be sent which does not include any of the + Configuration Options listed in the Configure-Reject. + + A summary of the Configure-Reject packet format is shown below. The + fields are transmitted from left to right. + + + + + + + + + +Simpson [Page 33] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+ + + Code + + 4 for Configure-Reject. + + Identifier + + The Identifier field is a copy of the Identifier field of the + Configure-Request which caused this Configure-Reject. + + Options + + The Options field is variable in length and contains the list of + zero or more Configuration Options that the sender is rejecting. + All Configuration Options are always rejected simultaneously. + +5.5 Terminate-Request and Terminate-Ack + + Description + + LCP includes Terminate-Request and Terminate-Ack Codes in order to + provide a mechanism for closing a connection. + + A LCP implementation wishing to close a connection SHOULD transmit + a LCP packet with the Code field set to 5 (Terminate-Request), and + the Data field filled with any desired data. Terminate-Request + packets SHOULD continue to be sent until Terminate-Ack is + received, the lower layer indicates that it has gone down, or a + sufficiently large number have been transmitted such that the peer + is down with reasonable certainty. + + Upon reception of a Terminate-Request, a LCP packet MUST be + transmitted with the Code field set to 6 (Terminate-Ack), the + Identifier field copied from the Terminate-Request packet, and the + Data field filled with any desired data. + + Reception of an unelicited Terminate-Ack indicates that the peer + is in the Closed or Stopped states, or is otherwise in need of + re-negotiation. + + A summary of the Terminate-Request and Terminate-Ack packet formats + + + +Simpson [Page 34] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + is shown below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Code + + 5 for Terminate-Request; + + 6 for Terminate-Ack. + + Identifier + + On transmission, the Identifier field MUST be changed whenever the + content of the Data field changes, and whenever a valid reply has + been received for a previous request. For retransmissions, the + Identifier MAY remain unchanged. On reception, the Identifier + field of the Terminate-Request is copied into the Identifier field + of the Terminate-Ack packet. + + Data + + The Data field is zero or more octets and contains uninterpreted + data for use by the sender. The data may consist of any binary + value and may be of any length from zero to the peer's established + MRU minus four. + + +5.6 Code-Reject + + Description + + Reception of a LCP packet with an unknown Code indicates that one + of the communicating LCP implementations is faulty or incomplete. + This error MUST be reported back to the sender of the unknown Code + by transmitting a LCP packet with the Code field set to 7 (Code- + Reject), and the inducing packet copied to the Rejected- + Information field. + + Upon reception of a Code-Reject, the implementation SHOULD report + the error, since it is unlikely that the situation can be + rectified automatically. + + + + +Simpson [Page 35] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + A summary of the Code-Reject packet format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Rejected-Packet ... + +-+-+-+-+-+-+-+-+ + + Code + + 7 for Code-Reject. + + Identifier + + The Identifier field MUST be changed for each Code-Reject sent. + + Rejected-Information + + The Rejected-Information field contains a copy of the LCP packet + which is being rejected. It begins with the Information field, + and does not include any Data Link Layer headers nor an FCS. The + Rejected-Information MUST be truncated to comply with the peer's + established MRU. + + +5.7 Protocol-Reject + + Description + + Reception of a PPP packet with an unknown Protocol field indicates + that the peer is attempting to use a protocol which is + unsupported. This usually occurs when the peer attempts to + configure a new protocol. If the LCP state machine is in the + Opened state, then this error MUST be reported back to the peer by + transmitting a LCP packet with the Code field set to 8 (Protocol- + Reject), the Rejected-Protocol field set to the received Protocol, + and the inducing packet copied to the Rejected-Information field. + + Upon reception of a Protocol-Reject, the implementation MUST stop + sending packets of the indicated protocol at the earliest + opportunity. + + Protocol-Reject packets can only be sent in the LCP Opened state. + Protocol-Reject packets received in any state other than the LCP + Opened state SHOULD be silently discarded. + + + +Simpson [Page 36] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + A summary of the Protocol-Reject packet format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Rejected-Protocol | Rejected-Information ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code + + 8 for Protocol-Reject. + + Identifier + + The Identifier field MUST be changed for each Protocol-Reject + sent. + + Rejected-Protocol + + The Rejected-Protocol field is two octets and contains the PPP + Protocol field of the packet which is being rejected. + + Rejected-Information + + The Rejected-Information field contains a copy of the packet which + is being rejected. It begins with the Information field, and does + not include any Data Link Layer headers nor an FCS. The + Rejected-Information MUST be truncated to comply with the peer's + established MRU. + +5.8 Echo-Request and Echo-Reply + + Description + + LCP includes Echo-Request and Echo-Reply Codes in order to provide + a Data Link Layer loopback mechanism for use in exercising both + directions of the link. This is useful as an aid in debugging, + link quality determination, performance testing, and for numerous + other functions. + + An Echo-Request sender transmits a LCP packet with the Code field + set to 9 (Echo-Request), the Identifier field set, the local + Magic-Number (if any) inserted, and the Data field filled with any + desired data, but not exceeding the peer's established MRU minus + eight. + + + +Simpson [Page 37] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Upon reception of an Echo-Request, a LCP packet MUST be + transmitted with the Code field set to 10 (Echo-Reply), the + Identifier field copied from the received Echo-Request, the local + Magic-Number (if any) inserted, and the Data field copied from the + Echo-Request, truncating as necessary to avoid exceeding the + peer's established MRU. + + Echo-Request and Echo-Reply packets may only be sent in the LCP + Opened state. Echo-Request and Echo-Reply packets received in any + state other than the LCP Opened state SHOULD be silently + discarded. + + A summary of the Echo-Request and Echo-Reply packet formats is shown + below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic-Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Code + + 9 for Echo-Request; + + 10 for Echo-Reply. + + Identifier + + On transmission, the Identifier field MUST be changed whenever the + content of the Data field changes, and whenever a valid reply has + been received for a previous request. For retransmissions, the + Identifier MAY remain unchanged. + + On reception, the Identifier field of the Echo-Request is copied + into the Identifier field of the Echo-Reply packet. + + Magic-Number + + The Magic-Number field is four octets and aids in detecting links + which are in the looped-back condition. Until the Magic-Number + Configuration Option has been successfully negotiated, the Magic- + Number MUST be transmitted as zero. See the Magic-Number + Configuration Option for further explanation. + + + +Simpson [Page 38] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Data + + The Data field is zero or more octets and contains uninterpreted + data for use by the sender. The data may consist of any binary + value and may be of any length from zero to the peer's established + MRU minus eight. + +5.9 Discard-Request + + Description + + LCP includes a Discard-Request Code in order to provide a Data + Link Layer sink mechanism for use in exercising the local to + remote direction of the link. This is useful as an aid in + debugging, performance testing, and for numerous other functions. + + The sender transmits a LCP packet with the Code field set to 11 + (Discard-Request), the Identifier field set, the local Magic- + Number (if any) inserted, and the Data field filled with any + desired data, but not exceeding the peer's established MRU minus + eight. + + Discard-Request packets may only be sent in the LCP Opened state. + On reception, the receiver MUST simply throw away any Discard- + Request that it receives. + + A summary of the Discard-Request packet format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic-Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + + Code + + 11 for Discard-Request. + + Identifier + + The Identifier field MUST be changed for each Discard-Request + sent. + + + +Simpson [Page 39] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Magic-Number + + The Magic-Number field is four octets and aids in detecting links + which are in the looped-back condition. Until the Magic-Number + Configuration Option has been successfully negotiated, the Magic- + Number MUST be transmitted as zero. See the Magic-Number + Configuration Option for further explanation. + + Data + + The Data field is zero or more octets and contains uninterpreted + data for use by the sender. The data may consist of any binary + value and may be of any length from zero to the peer's established + MRU minus four. + +6. LCP Configuration Options + + LCP Configuration Options allow negotiation of modifications to the + default characteristics of a point-to-point link. If a Configuration + Option is not included in a Configure-Request packet, the default + value for that Configuration Option is assumed. + + Some Configuration Options MAY be listed more than once. The effect + of this is Configuration Option specific, and is specified by each + such Configuration Option description. (None of the Configuration + Options in this specification can be listed more than once.) + + The end of the list of Configuration Options is indicated by the + length of the LCP packet. + + Unless otherwise specified, all Configuration Options apply in a + half-duplex fashion; typically, in the receive direction of the link + from the point of view of the Configure-Request sender. + + A summary of the Configuration Option format is shown below. The + fields are transmitted from left to right. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Data ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + The Type field is one octet and indicates the type of + Configuration Option. Up-to-date values of the LCP Option Type + field are specified in the most recent "Assigned Numbers" RFC [2]. + + + +Simpson [Page 40] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + This specification concerns the following values: + + 1 Maximum-Receive-Unit + 2 Async-Control-Character-Map + 3 Authentication-Protocol + 4 Quality-Protocol + 5 Magic-Number + 6 RESERVED + 7 Protocol-Field-Compression + 8 Address-and-Control-Field-Compression + + Length + + The Length field is one octet and indicates the length of this + Configuration Option including the Type, Length and Data fields. + If a negotiable Configuration Option is received in a Configure- + Request but with an invalid Length, a Configure-Nak SHOULD be + transmitted which includes the desired Configuration Option with + an appropriate Length and Data. + + Data + + The Data field is zero or more octets and information specific to + the Configuration Option. The format and length of the Data field + is determined by the Type and Length fields. + +6.1 Maximum-Receive-Unit + + Description + + This Configuration Option may be sent to inform the peer that the + implementation can receive larger packets, or to request that the + peer send smaller packets. + + The default value is 1500 octets. If smaller packets are + requested, an implementation MUST still be able to receive the + full 1500 octet information field in case link synchronization is + lost. + + Implementation Note: + + This option is used to indicate an implementation capability. The + peer is not required to maximize the use of the capacity. For + example, when a MRU is indicated which is 2048 octets, the peer is + not required to send any packet with 2048 octets. The peer need + not Configure-Nak to indicate that it will only send smaller + packets, since the implementation will always require support for + at least 1500 octets. + + + +Simpson [Page 41] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + A summary of the Maximum-Receive-Unit Configuration Option format is + shown below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Maximum-Receive-Unit | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 1 + + Length + + 4 + + Maximum-Receive-Unit + + The Maximum-Receive-Unit field is two octets, and specifies the + maximum number of octets in the Information and Padding fields. + It does not include the framing, Protocol field, FCS, nor any + transparency bits or bytes. + +6.2 Async-Control-Character-Map + + Description + + This Configuration Option provides a method to negotiate the use + of control character transparency on asynchronous links. + + For asynchronous links, the default value is 0xffffffff, which + causes all octets less than 0x20 to be mapped into an appropriate + two octet sequence. For most other links, the default value is 0, + since there is no need for mapping. + + However, it is rarely necessary to map all control characters, and + often it is unnecessary to map any control characters. The + Configuration Option is used to inform the peer which control + characters MUST remain mapped when the peer sends them. + + The peer MAY still send any other octets in mapped format, if it + is necessary because of constraints known to the peer. The peer + SHOULD Configure-Nak with the logical union of the sets of mapped + octets, so that when such octets are spuriously introduced they + can be ignored on receipt. + + + + +Simpson [Page 42] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + A summary of the Async-Control-Character-Map Configuration Option + format is shown below. The fields are transmitted from left to + right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Async-Control-Character-Map + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ACCM (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 2 + + Length + + 6 + + Async-Control-Character-Map + + The Async-Control-Character-Map field is four octets and indicates + the set of control characters to be mapped. The map is sent most + significant octet first. + + Each numbered bit corresponds to the octet of the same value. If + the bit is cleared to zero, then that octet need not be mapped. + If the bit is set to one, then that octet MUST remain mapped. For + example, if bit 19 is set to zero, then the ASCII control + character 19 (DC3, Control-S) MAY be sent in the clear. + + Note: The least significant bit of the least significant octet + (the final octet transmitted) is numbered bit 0, and would map + to the ASCII control character NUL. + +6.3 Authentication-Protocol + + Description + + On some links it may be desirable to require a peer to + authenticate itself before allowing network-layer protocol packets + to be exchanged. + + This Configuration Option provides a method to negotiate the use + of a specific authentication protocol. By default, authentication + is not required. + + + + +Simpson [Page 43] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + An implementation MUST NOT include multiple Authentication- + Protocol Configuration Options in its Configure-Request packets. + Instead, it SHOULD attempt to configure the most desirable + protocol first. If that protocol is Configure-Nak'd, then the + implementation SHOULD attempt the next most desirable protocol in + the next Configure-Request. + + If an implementation sends a Configure-Ack with this Configuration + Option, then it is agreeing to authenticate with the specified + protocol. An implementation receiving a Configure-Ack with this + Configuration Option SHOULD expect the peer to authenticate with + the acknowledged protocol. + + There is no requirement that authentication be full duplex or that + the same protocol be used in both directions. It is perfectly + acceptable for different protocols to be used in each direction. + This will, of course, depend on the specific protocols negotiated. + + A summary of the Authentication-Protocol Configuration Option format + is shown below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Authentication-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Type + + 3 + + Length + + >= 4 + + Authentication-Protocol + + The Authentication-Protocol field is two octets and indicates the + authentication protocol desired. Values for this field are always + the same as the PPP Protocol field values for that same + authentication protocol. + + Up-to-date values of the Authentication-Protocol field are + specified in the most recent "Assigned Numbers" RFC [2]. Current + values are assigned as follows: + + + + +Simpson [Page 44] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Value (in hex) Protocol + + c023 Password Authentication Protocol + c223 Challenge Handshake Authentication Protocol + + Data + + The Data field is zero or more octets and contains additional data + as determined by the particular protocol. + +6.4 Quality-Protocol + + Description + + On some links it may be desirable to determine when, and how + often, the link is dropping data. This process is called link + quality monitoring. + + This Configuration Option provides a method to negotiate the use + of a specific protocol for link quality monitoring. By default, + link quality monitoring is disabled. + + There is no requirement that quality monitoring be full duplex or + that the same protocol be used in both directions. It is + perfectly acceptable for different protocols to be used in each + direction. This will, of course, depend on the specific protocols + negotiated. + + A summary of the Quality-Protocol Configuration Option format is + shown below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Quality-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Type + + 4 + + Length + + >= 4 + + + + + +Simpson [Page 45] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Quality-Protocol + + The Quality-Protocol field is two octets and indicates the link + quality monitoring protocol desired. Values for this field are + always the same as the PPP Protocol field values for that same + monitoring protocol. + + Up-to-date values of the Quality-Protocol field are specified in + the most recent "Assigned Numbers" RFC [2]. Current values are + assigned as follows: + + Value (in hex) Protocol + + c025 Link Quality Report + + Data + + The Data field is zero or more octets and contains additional data + as determined by the particular protocol. + +6.5 Magic-Number + + Description + + This Configuration Option provides a method to detect looped-back + links and other Data Link Layer anomalies. This Configuration + Option MAY be required by some other Configuration Options such as + the Quality-Protocol Configuration Option. By default, the + Magic-Number is not negotiated, and zero is inserted where a + Magic-Number might otherwise be used. + + Before this Configuration Option is requested, an implementation + MUST choose its Magic-Number. It is recommended that the Magic- + Number be chosen in the most random manner possible in order to + guarantee with very high probability that an implementation will + arrive at a unique number. A good way to choose a unique random + number is to start with an unique seed. Suggested sources of + uniqueness include machine serial numbers, other network hardware + addresses, time-of-day clocks, etc. Particularly good random + number seeds are precise measurements of the inter-arrival time of + physical events such as packet reception on other connected + networks, server response time, or the typing rate of a human + user. It is also suggested that as many sources as possible be + used simultaneously. + + When a Configure-Request is received with a Magic-Number + Configuration Option, the received Magic-Number is compared with + the Magic-Number of the last Configure-Request sent to the peer. + + + +Simpson [Page 46] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + If the two Magic-Numbers are different, then the link is not + looped-back, and the Magic-Number SHOULD be acknowledged. If the + two Magic-Numbers are equal, then it is possible, but not certain, + that the link is looped-back and that this Configure-Request is + actually the one last sent. To determine this, a Configure-Nak + MUST be sent specifying a different Magic-Number value. A new + Configure-Request SHOULD NOT be sent to the peer until normal + processing would cause it to be sent (that is, until a Configure- + Nak is received or the Restart timer runs out). + + Reception of a Configure-Nak with a Magic-Number different from + that of the last Configure-Nak sent to the peer proves that a link + is not looped-back, and indicates a unique Magic-Number. If the + Magic-Number is equal to the one sent in the last Configure-Nak, + the possibility of a looped-back link is increased, and a new + Magic-Number MUST be chosen. In either case, a new Configure- + Request SHOULD be sent with the new Magic-Number. + + If the link is indeed looped-back, this sequence (transmit + Configure-Request, receive Configure-Request, transmit Configure- + Nak, receive Configure-Nak) will repeat over and over again. If + the link is not looped-back, this sequence might occur a few + times, but it is extremely unlikely to occur repeatedly. More + likely, the Magic-Numbers chosen at either end will quickly + diverge, terminating the sequence. The following table shows the + probability of collisions assuming that both ends of the link + select Magic-Numbers with a perfectly uniform distribution: + + Number of Collisions Probability + -------------------- --------------------- + 1 1/2**32 = 2.3 E-10 + 2 1/2**32**2 = 5.4 E-20 + 3 1/2**32**3 = 1.3 E-29 + + Good sources of uniqueness or randomness are required for this + divergence to occur. If a good source of uniqueness cannot be + found, it is recommended that this Configuration Option not be + enabled; Configure-Requests with the option SHOULD NOT be + transmitted and any Magic-Number Configuration Options which the + peer sends SHOULD be either acknowledged or rejected. In this + case, loop-backs cannot be reliably detected by the + implementation, although they may still be detectable by the peer. + + If an implementation does transmit a Configure-Request with a + Magic-Number Configuration Option, then it MUST NOT respond with a + Configure-Reject if it receives a Configure-Request with a Magic- + Number Configuration Option. That is, if an implementation + desires to use Magic Numbers, then it MUST also allow its peer to + + + +Simpson [Page 47] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + do so. If an implementation does receive a Configure-Reject in + response to a Configure-Request, it can only mean that the link is + not looped-back, and that its peer will not be using Magic- + Numbers. In this case, an implementation SHOULD act as if the + negotiation had been successful (as if it had instead received a + Configure-Ack). + + The Magic-Number also may be used to detect looped-back links + during normal operation as well as during Configuration Option + negotiation. All LCP Echo-Request, Echo-Reply, and Discard- + Request packets have a Magic-Number field. If Magic-Number has + been successfully negotiated, an implementation MUST transmit + these packets with the Magic-Number field set to its negotiated + Magic-Number. + + The Magic-Number field of these packets SHOULD be inspected on + reception. All received Magic-Number fields MUST be equal to + either zero or the peer's unique Magic-Number, depending on + whether or not the peer negotiated a Magic-Number. Reception of a + Magic-Number field equal to the negotiated local Magic-Number + indicates a looped-back link. Reception of a Magic- Number other + than the negotiated local Magic-Number or the peer's negotiated + Magic-Number, or zero if the peer didn't negotiate one, indicates + a link which has been (mis)configured for communications with a + different peer. + + Procedures for recovery from either case are unspecified and may + vary from implementation to implementation. A somewhat + pessimistic procedure is to assume a LCP Down event. A further + Open event will begin the process of re-establishing the link, + which can't complete until the loop-back condition is terminated + and Magic-Numbers are successfully negotiated. A more optimistic + procedure (in the case of a loop-back) is to begin transmitting + LCP Echo-Request packets until an appropriate Echo-Reply is + received, indicating a termination of the loop-back condition. + + A summary of the Magic-Number Configuration Option format is shown + below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Magic-Number + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic-Number (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + +Simpson [Page 48] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Type + + 5 + + Length + + 6 + + Magic-Number + + The Magic-Number field is four octets and indicates a number which + is very likely to be unique to one end of the link. A Magic- + Number of zero is illegal and MUST always be Nak'd, if it is not + Rejected outright. + +6.6 Protocol-Field-Compression + + Description + + This Configuration Option provides a method to negotiate the + compression of the PPP Protocol field. By default, all + implementations MUST transmit packets with two octet PPP Protocol + fields. + + PPP Protocol field numbers are chosen such that some values may be + compressed into a single octet form which is clearly + distinguishable from the two octet form. This Configuration + Option is sent to inform the peer that the implementation can + receive such single octet Protocol fields. + + As previously mentioned, the Protocol field uses an extension + mechanism consistent with the ISO 3309 extension mechanism for the + Address field; the Least Significant Bit (LSB) of each octet is + used to indicate extension of the Protocol field. A binary "0" as + the LSB indicates that the Protocol field continues with the + following octet. The presence of a binary "1" as the LSB marks + the last octet of the Protocol field. Notice that any number of + "0" octets may be prepended to the field, and will still indicate + the same value (consider the two binary representations for 3, + 00000011 and 00000000 00000011). + + When using low speed links, it is desirable to conserve bandwidth + by sending as little redundant data as possible. The Protocol- + Field-Compression Configuration Option allows a trade-off between + implementation simplicity and bandwidth efficiency. If + successfully negotiated, the ISO 3309 extension mechanism may be + used to compress the Protocol field to one octet instead of two. + The large majority of packets are compressible since data + + + +Simpson [Page 49] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + protocols are typically assigned with Protocol field values less + than 256. + + Compressed Protocol fields MUST NOT be transmitted unless this + Configuration Option has been negotiated. When negotiated, PPP + implementations MUST accept PPP packets with either double-octet + or single-octet Protocol fields, and MUST NOT distinguish between + them. + + The Protocol field is never compressed when sending any LCP + packet. This rule guarantees unambiguous recognition of LCP + packets. + + When a Protocol field is compressed, the Data Link Layer FCS field + is calculated on the compressed frame, not the original + uncompressed frame. + + A summary of the Protocol-Field-Compression Configuration Option + format is shown below. The fields are transmitted from left to + right. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 7 + + Length + + 2 + +6.7 Address-and-Control-Field-Compression + + Description + + This Configuration Option provides a method to negotiate the + compression of the Data Link Layer Address and Control fields. By + default, all implementations MUST transmit frames with Address and + Control fields appropriate to the link framing. + + Since these fields usually have constant values for point-to-point + links, they are easily compressed. This Configuration Option is + sent to inform the peer that the implementation can receive + compressed Address and Control fields. + + + +Simpson [Page 50] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + If a compressed frame is received when Address-and-Control-Field- + Compression has not been negotiated, the implementation MAY + silently discard the frame. + + The Address and Control fields MUST NOT be compressed when sending + any LCP packet. This rule guarantees unambiguous recognition of + LCP packets. + + When the Address and Control fields are compressed, the Data Link + Layer FCS field is calculated on the compressed frame, not the + original uncompressed frame. + + A summary of the Address-and-Control-Field-Compression configuration + option format is shown below. The fields are transmitted from left + to right. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 8 + + Length + + 2 + +A. LCP Recommended Options + + The following Configurations Options are recommended: + + SYNC LINES + + Magic Number Link Quality Monitoring No Address and Control Field + Compression No Protocol Field Compression + + ASYNC LINES + + Async Control Character Map Magic Number Address and Control Field + Compression Protocol Field Compression + +Security Considerations + + Security issues are briefly discussed in sections concerning the + Authentication Phase, the Close event, and the Authentication- + + + +Simpson [Page 51] + +RFC 1548 The Point-to-Point Protocol December 1993 + + + Protocol Configuration Option. Further discussion is in a companion + document entitled PPP Authentication Protocols. + + +References + + [1] Perkins, D., "Requirements for an Internet Standard + Point-to-Point Protocol", RFC 1547, December 1993. + + [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, + USC/Information Sciences Institute, July 1992. + +Acknowledgments + + Much of the text in this document is taken from the WG Requirements, + and RFCs 1171 & 1172, by Drew Perkins of Carnegie Mellon University, + and by Russ Hobby of the University of California at Davis. + + Many people spent significant time helping to develop the Point-to- + Point Protocol. The complete list of people is too numerous to list, + but the following people deserve special thanks: Rick Adams (UUNET), + Ken Adelman (TGV), Fred Baker (ACC), Mike Ballard (Telebit), Craig + Fox (Network Systems), Karl Fox (Morning Star Technologies), Phill + Gross (AN&S), former WG chair Russ Hobby (UC Davis), David Kaufman + (Proteon), former WG chair Steve Knowles (FTP Software), former WG + chair Brian Lloyd (L&A), John LoVerso (Xylogics), Bill Melohn (Sun + Microsystems), Mike Patton (MIT), former WG chair Drew Perkins + (Fore), Greg Satz (cisco systems), John Shriver (Proteon), Vernon + Schryver (Silicon Graphics), and Asher Waldfogel (Wellfleet). + + The "Day in the Life" example was instigated by Kory Hamzeh (Avatar). + In this version, improvements in wording were also provided by Scott + Ginsburg, Mark Moraes, and Timon Sloan, as they worked on + implementations. + + Special thanks to Morning Star Technologies for providing computing + resources and network access support for writing this specification. + +Chair's Address + + The working group can be contacted via the current chair: + + Fred Baker + Advanced Computer Communications + 315 Bollay Drive + Santa Barbara, California, 93111 + + EMail: fbaker@acc.com + + + +Simpson [Page 52] + +RFC 1548 The Point-to-Point Protocol December 1993 + + +Editor's Address + + Questions about this memo can also be directed to: + + William Allen Simpson + Daydreamer + Computer Systems Consulting Services + 1384 Fontaine + Madison Heights, Michigan 48071 + + EMail: Bill.Simpson@um.cc.umich.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 53] + diff --git a/doc/rfc1570.txt b/doc/rfc1570.txt new file mode 100644 index 00000000..edda5d99 --- /dev/null +++ b/doc/rfc1570.txt @@ -0,0 +1,1057 @@ + + + + + + +Network Working Group W. Simpson, Editor +Request for Comments: 1570 Daydreamer +Updates: 1548 January 1994 +Category: Standards Track + + + PPP LCP Extensions + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + The Point-to-Point Protocol (PPP) [1] provides a standard method for + transporting multi-protocol datagrams over point-to-point links. PPP + defines an extensible Link Control Protocol (LCP) for establishing, + configuring, and testing the data-link connection. This document + defines several additional LCP features which have been suggested + over the past few years. + + This document is the product of the Point-to-Point Protocol Working + Group of the Internet Engineering Task Force (IETF). Comments should + be submitted to the ietf-ppp@ucdavis.edu mailing list. + +Table of Contents + + 1. Additional LCP Packets ................................ 1 + 1.1 Identification .................................. 1 + 1.2 Time-Remaining .................................. 3 + 2. Additional LCP Configuration Options .................. 6 + 2.1 FCS-Alternatives ................................ 6 + 2.1.1 LCP considerations .............................. 7 + 2.1.2 Null FCS ........................................ 8 + 2.2 Self-Describing-Padding ......................... 9 + 2.3 Callback ........................................ 11 + 2.4 Compound-Frames ................................. 12 + 2.4.1 LCP considerations .............................. 14 + APPENDICES ................................................... 15 + A. Fast Frame Check Sequence (FCS) Implementation ........ 15 + A.1 32-bit FCS Computation Method ................... 15 + SECURITY CONSIDERATIONS ...................................... 17 + REFERENCES ................................................... 17 + ACKNOWLEDGEMENTS ............................................. 18 + CHAIR'S ADDRESS .............................................. 18 + EDITOR'S ADDRESS ............................................. 18 + + + + + + + + +Simpson [Page i] + RFC 1570 PPP LCP extensions January 1994 + + +1. Additional LCP Packets + + The Packet format and basic facilities are already defined for LCP + [1]. + + Up-to-date values of the LCP Code field are specified in the most + recent "Assigned Numbers" RFC [2]. This specification concerns the + following values: + + 12 Identification + 13 Time-Remaining + + + + +1.1. Identification + + Description + + This Code provides a method for an implementation to identify + itself to its peer. This Code might be used for many diverse + purposes, such as link troubleshooting, license enforcement, etc. + + Identification is a Link Maintenance packet. Identification + packets MAY be sent at any time, including before LCP has reached + the Opened state. + + The sender transmits a LCP packet with the Code field set to 12 + (Identification), the Identifier field set, the local Magic-Number + (if any) inserted, and the Message field filled with any desired + data, but not exceeding the default MRU minus eight. + + Receipt of an Identification packet causes the RXR or RUC event. + There is no response to the Identification packet. + + Receipt of a Code-Reject for the Identification packet SHOULD + generate the RXJ+ (permitted) event. + + Rationale: + + This feature is defined as part of LCP, rather than as a + separate PPP Protocol, in order that its benefits may be + available during the earliest possible stage of the Link + Establishment phase. It allows an operator to learn the + identification of the peer even when negotiation is not + converging. Non-LCP packets cannot be sent during the Link + Establishment phase. + + + + +Simpson [Page 1] + RFC 1570 PPP LCP extensions January 1994 + + + This feature is defined as a separate LCP Code, rather than a + Configuration-Option, so that the peer need not include it with + other items in configuration packet exchanges, and handle + "corrected" values or "rejection", since its generation is both + rare and in one direction. It is recommended that + Identification packets be sent whenever a Configure-Reject is + sent or received, as a final message when negotiation fails to + converge, and when LCP reaches the Opened state. + + A summary of the Identification packet format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic-Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message ... + +-+-+-+-+-+-+-+-+ + + + Code + + 12 for Identification + + Identifier + + The Identifier field MUST be changed for each Identification sent. + + Length + + >= 8 + + Magic-Number + + The Magic-Number field is four octets and aids in detecting links + which are in the looped-back condition. Until the Magic-Number + Configuration Option has been successfully negotiated, the Magic- + Number MUST be transmitted as zero. See the Magic-Number + Configuration Option for further explanation. + + Message + + The Message field is zero or more octets, and its contents are + implementation dependent. It is intended to be human readable, + and MUST NOT affect operation of the protocol. It is recommended + + + +Simpson [Page 2] + RFC 1570 PPP LCP extensions January 1994 + + + that the message contain displayable ASCII characters 32 through + 126 decimal. Mechanisms for extension to other character sets are + the topic of future research. The size is determined from the + Length field. + + Implementation Note: + + The Message will usually contain such things as the sender's + hardware type, PPP software revision level, and PPP product + serial number, MIB information such as link speed and interface + name, and any other information that the sender thinks might be + useful in debugging connections. The format is likely to be + different for each implementor, so that those doing serial + number tracking can validate their numbers. A robust + implementation SHOULD treat the Message as displayable text, + and SHOULD be able to receive and display a very long Message. + + + +1.2. Time-Remaining + + Description + + This Code provides a mechanism for notifying the peer of the time + remaining in this session. + + The nature of this information is advisory only. It is intended + that only one side of the connection will send this packet + (generally a "network access server"). The session is actually + concluded by the Terminate-Request packet. + + Time-Remaining is a Link Maintenance packet. Time-Remaining + packets may only be sent in the LCP Opened state. + + The sender transmits a LCP packet with the Code field set to 13 + (Time-Remaining), the Identifier field set, the local Magic-Number + (if any) inserted, and the Message field filled with any desired + data, but not exceeding the peer's established MRU minus twelve. + + Receipt of an Time-Remaining packet causes the RXR or RUC event. + There is no response to the Time-Remaining packet. + + Receipt of a Code-Reject for the Time-Remaining packet SHOULD + generate the RXJ+ (permitted) event. + + Rationale: + + This notification is defined as a separate LCP Code, rather + + + +Simpson [Page 3] + RFC 1570 PPP LCP extensions January 1994 + + + than a Configuration-Option, in order that changes and warning + messages may occur dynamically during the session, and that the + information might be determined after Authentication has + occurred. Typically, this packet is sent when the link enters + Network-Layer Protocol phase, and at regular intervals + throughout the session, particularly near the end of the + session. + + A summary of the Time-Remaining packet format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic-Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Seconds-Remaining | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message ... + +-+-+-+-+-+-+-+-+ + + + Code + + 13 for Time-Remaining + + Identifier + + The Identifier field MUST be changed for each Time-Remaining sent. + + Length + + >= 12 + + Magic-Number + + The Magic-Number field is four octets and aids in detecting links + which are in the looped-back condition. Until the Magic-Number + Configuration Option has been successfully negotiated, the Magic- + Number MUST be transmitted as zero. See the Magic-Number + Configuration Option for further explanation. + + Seconds-Remaining + + The Seconds-Remaining field is four octets and indicates the + number of integral seconds remaining in this session. This 32 bit + + + +Simpson [Page 4] + RFC 1570 PPP LCP extensions January 1994 + + + unsigned value is sent most significant octet first. A value of + 0xffffffff (all ones) represents no timeout, or "forever". + + Message + + The Message field is zero or more octets, and its contents are + implementation dependent. It is intended to be human readable, + and MUST NOT affect operation of the protocol. It is recommended + that the message contain displayable ASCII characters 32 through + 126 decimal. Mechanisms for extension to other character sets are + the topic of future research. The size is determined from the + Length field. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 5] + RFC 1570 PPP LCP extensions January 1994 + + +2. Additional LCP Configuration Options + + The Configuration Option format and basic options are already defined + for LCP [1]. + + Up-to-date values of the LCP Option Type field are specified in the + most recent "Assigned Numbers" RFC [2]. This document concerns the + following values: + + 9 FCS-Alternatives + 10 Self-Describing-Padding + 13 Callback + 15 Compound-Frames + + + + +2.1. FCS-Alternatives + + Description + + This Configuration Option provides a method for an implementation + to specify another FCS format to be sent by the peer, or to + negotiate away the FCS altogether. + + This option is negotiated separately in each direction. However, + it is not required that an implementation be capable of + concurrently generating a different FCS on each side of the link. + + The negotiated FCS values take effect only during Authentication + and Network-Layer Protocol phases. Frames sent during any other + phase MUST contain the default FCS. + + A summary of the FCS-Alternatives Configuration Option format is + shown below. The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Options | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 9 + + + + + +Simpson [Page 6] + RFC 1570 PPP LCP extensions January 1994 + + + Length + + 3 + + Options + + This field is one octet, and is comprised of the "logical or" of + the following values: + + 1 Null FCS + 2 CCITT 16-bit FCS + 4 CCITT 32-bit FCS + + + Implementation Note: + + For most PPP HDLC framed links, the default FCS is the CCITT 16- + bit FCS. Some framing techniques and high speed links may use + another format as the default FCS. + + +2.1.1. LCP considerations + + The link can be subject to loss of state, and the LCP can re- + negotiate at any time. When the LCP begins renegotiation or + termination, it is recommended that the LCP Configure-Request or + Terminate-Request packet be sent with the last negotiated FCS, then + change to the default FCS, and a duplicate LCP packet is sent with + the default FCS. The Identifier field SHOULD NOT be incremented for + each such duplicate packet. + + On receipt of a LCP Configure-Request or Terminate-Request packet, + the implementation MUST change to the default FCS for both + transmission and reception. If a Request packet is received which + contains a duplicate Identifier field, a new reply MUST be generated. + + Implementation Notes: + + The need to send two packets is only necessary after the + Alternative-FCS has already been negotiated. It need not occur + during state transitions when there is a natural indication that + the default FCS is in effect, such as the Down and Up events. It + is necessary to send two packets in the Ack-Sent and Opened + states, since the peer could mistakenly believe that the link has + Opened. + + It is possible to send a single 48-bit FCS which is a combination + of the 16-bit and 32-bit FCS. This may be sent instead of sending + + + +Simpson [Page 7] + RFC 1570 PPP LCP extensions January 1994 + + + the two packets described above. We have not standardized this + procedure because of intellectual property concerns. If such a + 48-bit FCS is used, it MUST only be used for LCP packets. + + +2.1.2. Null FCS + + The Null FCS SHOULD only be used for those network-layer and + transport protocols which have an end-to-end checksum available, such + as TCP/IP, or UDP/IP with the checksum enabled. That is, the Null + FCS option SHOULD be negotiated together with another non-null FCS + option in a heterogeneous environment. + + When a configuration (LCP or NCP) or authentication packet is sent, + the FCS MUST be included. When a configuration (LCP or NCP) or + authentication packet is received, the FCS MUST be verified. + + There are several cases to be considered: + + Null FCS alone + + The sender generates the FCS for those frames which require the + FCS before sending the frame. + + When a frame is received, it is not necessary to check the FCS + before demultiplexing. Any FCS is treated as padding. + + Receipt of an Authentication or Control packet would be discovered + after passing the frame to the demultiplexer. Verification of the + FCS can easily be accomplished using one of the software + algorithms defined in "PPP in HDLC Framing" [3] (16-bit FCS) and + Appendix A (32-bit FCS). + + Null FCS with another FCS, using software + + This is similar to the above case. + + Those packets which are required to have the FCS (Authentication, + Control, or Network-Protocols lacking a checksum) are checked + using software after demultiplexing. Packets which fail the FCS + test are discarded as usual. + + Null FCS with another FCS, using hardware + + A flag is passed with the frame, indicating whether or not it has + passed the hardware FCS check. The incorrect FCS MUST be passed + with the rest of the data. The frame MUST NOT be discarded until + after demultiplexing, and only those frames that require the FCS + + + +Simpson [Page 8] + RFC 1570 PPP LCP extensions January 1994 + + + are discarded. + + All three FCS forms (Null, 16 and 32) may be used concurrently on + different frames when using software. That is probably not possible + with most current hardware. + + + +2.2. Self-Describing-Padding + + Description + + This Configuration Option provides a method for an implementation + to indicate to the peer that it understands self-describing pads + when padding is added at the end of the PPP Information field. + + This option is most likely to be used when some protocols, such as + network-layer or compression protocols, are configured which + require detection and removal of any trailing padding. Such + special protocols are identified in their respective documents. + + If the option is Rejected, the peer MUST NOT add any padding to + the identified special protocols, but MAY add padding to other + protocols. + + If the option is Ack'd, the peer MUST follow the procedures for + adding self-describing pads, but only to the specifically + identified protocols. The peer is not required to add any padding + to other protocols. + + Implementation Notes: + + This is defined so that the Reject handles either case where + the peer does not generate self-describing pads. When the peer + never generates padding, it may safely Reject the option. When + the peer does not understand the option, it also will not + successfully configure a special protocol which requires + elimination of pads. + + While some senders might only be capable of adding padding to + every protocol or not adding padding to any protocol, by design + the receiver need not examine those protocols which do not need + the padding stripped. + + To avoid unnecessary configuration handshakes, an + implementation which generates padding, and has a protocol + configured which requires the padding to be known, SHOULD + include this Option in its Configure-Request, and SHOULD + + + +Simpson [Page 9] + RFC 1570 PPP LCP extensions January 1994 + + + Configure-Nak with this Option when it is not present in the + peer's Request. + + Each octet of self-describing pad contains the index of that + octet. The first pad octet MUST contain the value one (1), which + indicates the Padding Protocol to the Compound-Frames option. + After removing the FCS, the final pad octet indicates the number + of pad octets to remove. For example, three pad octets would + contain the values 1, 2, 3. + + The Maximum-Pad-Value (MPV) is also negotiated. Only the values 1 + through MPV are used. When no padding would otherwise be + required, but the final octet of the PPP Information field + contains the value 1 through MPV, at least one self-describing pad + octet MUST be added to the frame. If the final octet is greater + than MPV, no additional padding is required. + + Implementation Notes: + + If any of the pad octets contain an incorrect index value, the + entire frame SHOULD be silently discarded. This is intended to + prevent confusion with the FCS-Alternatives option, but might + not be necessary in robust implementations. + + Since this option is intended to support compression protocols, + the Maximum-Pad-Value is specified to limit the likelihood that + a frame may actually become longer. + + A summary of the Self-Describing-Padding Configuration Option format + is shown below. The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Maximum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 10 + + Length + + 3 + + + + + + +Simpson [Page 10] + RFC 1570 PPP LCP extensions January 1994 + + + Maximum + + This field specifies the largest number of padding octets which + may be added to the frame. The value may range from 1 to 255, but + values of 2, 4, or 8 are most likely. + + + +2.3. Callback + + Description + + This Configuration Option provides a method for an implementation + to request a dial-up peer to call back. This option might be used + for many diverse purposes, such as savings on toll charges. + + When Callback is successfully negotiated, and authentication is + complete, the Authentication phase proceeds directly to the + Termination phase, and the link is disconnected. + + Then, the peer re-establishes the link, without negotiating + Callback. + + Implementation Notes: + + A peer which agrees to this option SHOULD request the + Authentication-Protocol Configuration Option. The user + information learned during authentication can be used to + determine the user location, or to limit a user to certain + locations, or merely to determine whom to bill for the service. + + Authentication SHOULD be requested in turn by the + implementation when it is called back, if mutual authentication + is desired. + + A summary of the Callback Option format is shown below. The fields + are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Operation | Message ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 13 + + + +Simpson [Page 11] + RFC 1570 PPP LCP extensions January 1994 + + + Length + + >= 3 + + Operation + + The Operation field is one octet and indicates the contents of the + Message field. + + 0 location is determined by user authentication + + 1 Dialing string, the format and contents of which assumes + configuration knowledge of the specific device which is + making the callback. + + 2 Location identifier, which may or may not be human + readable, to be used together with the authentication + information for a database lookup to determine the + callback location. + + 3 E.164 number. + + 4 Distinguished name. + + Message + + The Message field is zero or more octets, and its general contents + are determined by the Operation field. The actual format of the + information is site or application specific, and a robust + implementation SHOULD support the field as undistinguished octets. + The size is determined from the Length field. + + It is intended that only an authorized user will have correct site + specific information to make use of the Callback. The + codification of the range of allowed usage of this field is + outside the scope of this specification. + + + +2.4. Compound-Frames + + Description + + This Configuration Option provides a method for an implementation + to send multiple PPP encapsulated packets within the same frame. + This option might be used for many diverse purposes, such as + savings on toll charges. + + + + +Simpson [Page 12] + RFC 1570 PPP LCP extensions January 1994 + + + Only those PPP Protocols which have determinate lengths or + integral length fields may be aggregated into a compound frame. + + When Compound-Frames is successfully negotiated, the sender MAY + add additional packets to the same frame. Each packet is + immediately followed by another Protocol field, with its attendant + datagram. + + When padding is added to the end of the Information field, the + procedure described in Self-Describing-Padding is used. + Therefore, this option MUST be negotiated together with the Self- + Describing-Padding option. + + If the FCS-Alternatives option has been negotiated, self + describing padding MUST always be added. That is, the final + packet MUST be followed by a series of octets, the first of which + contains the value one (1). + + On receipt, the first Protocol field is examined, and the packet + is processed as usual. For those datagrams which have a + determinate length, the remainder of the frame is returned to the + demultiplexor. Each succeeding Protocol field is processed as a + separate packet. This processing is complete when a packet is + processed which does not have a determinate length, when the + remainder of the frame is empty, or when the Protocol field is + determined to have a value of one (1). + + The PPP Protocol value of one (1) is reserved as the Padding + Protocol. Any following octets are removed as padding. + + A summary of the Compound-Frames Option format is shown below. The + fields are transmitted from left to right. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 15 + + Length + + 2 + + + + +Simpson [Page 13] + RFC 1570 PPP LCP extensions January 1994 + + +2.4.1. LCP considerations + + During initial negotiation, the Compound-Frames option can be used to + minimize the negotiation latency, by reducing the number of frames + exchanged. + + The first LCP Configure-Request packet is sent as usual in a single + frame, including the Self-Describing-Padding and Compound-Frames + options. + + The peer SHOULD respond with a Configure-Ack, followed in a compound + frame by its LCP Configure-Request, and any NCP Configure-Requests + desired. + + Upon receipt, the local implementation SHOULD process the Configure- + Ack as usual. Since the peer has agreed to send compound frames, the + implementation MUST examine the remainder of the frame for additional + packets. If the peer also specified the Self-Describing-Padding and + Compound-Frames options in its Configure-Request, the local + implementation SHOULD retain its Configure-Ack, and further NCP + configuration packets SHOULD be added to the return frame. + + Together with the peer's final return frame, the minimum number of + frames to complete configuration is 4. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Simpson [Page 14] + RFC 1570 PPP LCP extensions January 1994 + + +A. Fast Frame Check Sequence (FCS) Implementation + +A.1. 32-bit FCS Computation Method + + The following code provides a table lookup computation for + calculating the 32-bit Frame Check Sequence as data arrives at the + interface. + + /* + * u32 represents an unsigned 32-bit number. Adjust the typedef for + * your hardware. + */ + typedef unsigned long u32; + + static u32 fcstab_32[256] = + { + 0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, + 0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3, + 0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988, + 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91, + 0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de, + 0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7, + 0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, + 0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5, + 0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172, + 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b, + 0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940, + 0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59, + 0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116, + 0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f, + 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924, + 0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, + 0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a, + 0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433, + 0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818, + 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01, + 0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e, + 0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457, + 0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c, + 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65, + 0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2, + 0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb, + 0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0, + 0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9, + 0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086, + 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f, + 0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4, + 0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad, + + + +Simpson [Page 15] + RFC 1570 PPP LCP extensions January 1994 + + + 0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a, + 0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683, + 0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8, + 0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1, + 0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe, + 0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7, + 0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc, + 0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5, + 0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252, + 0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b, + 0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60, + 0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79, + 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236, + 0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f, + 0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04, + 0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d, + 0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a, + 0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713, + 0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38, + 0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21, + 0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e, + 0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777, + 0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c, + 0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45, + 0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2, + 0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db, + 0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0, + 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9, + 0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6, + 0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf, + 0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94, + 0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d + }; + + #define PPPINITFCS32 0xffffffff /* Initial FCS value */ + #define PPPGOODFCS32 0xdebb20e3 /* Good final FCS value */ + + /* + * Calculate a new FCS given the current FCS and the new data. + */ + u32 pppfcs32(fcs, cp, len) + register u32 fcs; + register unsigned char *cp; + register int len; + { + ASSERT(sizeof (u32) == 4); + ASSERT(((u32) -1) > 0); + while (len--) + + + +Simpson [Page 16] + RFC 1570 PPP LCP extensions January 1994 + + + fcs = (((fcs) >> 8) ^ fcstab_32[((fcs) ^ (*cp++)) & 0xff]); + + return (fcs); + } + + /* + * How to use the fcs + */ + tryfcs32(cp, len) + register unsigned char *cp; + register int len; + { + u32 trialfcs; + + /* add on output */ + trialfcs = pppfcs32( PPPINITFCS32, cp, len ); + trialfcs ^= 0xffffffff; /* complement */ + cp[len] = (trialfcs & 0x00ff); /* Least significant byte first */ + cp[len+1] = ((trialfcs >>= 8) & 0x00ff); + cp[len+2] = ((trialfcs >>= 8) & 0x00ff); + cp[len+3] = ((trialfcs >> 8) & 0x00ff); + + /* check on input */ + trialfcs = pppfcs32( PPPINITFCS32, cp, len + 4 ); + if ( trialfcs == PPPGOODFCS32 ) + printf("Good FCS\n"); + } + + +Security Considerations + + Security issues are briefly discussed in sections concerning the + Callback Configuration Option. + + +References + + [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC + 1548, Daydreamer, December 1993. + + [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, + RFC 1340, USC/Information Sciences Institute, July 1992. + + [3] Simpson, W., Editor, "PPP in HDLC Framing", RFC 1549, + Daydreamer, December 1993. + + + + + + +Simpson [Page 17] + RFC 1570 PPP LCP extensions January 1994 + + +Acknowledgments + + The Identification feature was suggested by Bob Sutterfield (Morning + Star Technologies). + + The Time-Remaining feature was suggested by Brad Parker (FCR). + + Some of the original text for FCS-Alternatives was provided by Arthur + Harvey (then of DEC). The Null FCS was requested by Peter Honeyman + (UMich). The 32-bit FCS example code was provided by Karl Fox + (Morning Star Technologies). + + Self-Describing-Padding was suggested and named by Fred Baker (ACC). + + Compound-Frames was suggested by Keith Sklower (Berkeley). + + Special thanks to Morning Star Technologies for providing computing + resources and network access support for writing this specification. + + +Chair's Address + + The working group can be contacted via the current chair: + + Fred Baker + Advanced Computer Communications + 315 Bollay Drive + Santa Barbara, California 93117 + + EMail: fbaker@acc.com + + +Editor's Address + + Questions about this memo can also be directed to: + + William Allen Simpson + Daydreamer + Computer Systems Consulting Services + 1384 Fontaine + Madison Heights, Michigan 48071 + + EMail: Bill.Simpson@um.cc.umich.edu + bsimpson@MorningStar.com + + + + + + + +Simpson [Page 18] + + diff --git a/doc/rfc1877.txt b/doc/rfc1877.txt new file mode 100644 index 00000000..843c15c4 --- /dev/null +++ b/doc/rfc1877.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group S. Cobb +Request for Comments: 1877 Microsoft +Category: Informational December 1995 + + + PPP Internet Protocol Control Protocol Extensions for + Name Server Addresses + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + The Point-to-Point Protocol (PPP) [1] provides a standard method for + transporting multi-protocol datagrams over point-to-point links. PPP + defines an extensible Link Control Protocol and a family of Network + Control Protocols (NCPs) for establishing and configuring different + network-layer protocols. + + This document extends the NCP for establishing and configuring the + Internet Protocol over PPP [2], defining the negotiation of primary + and secondary Domain Name System (DNS) [3] and NetBIOS Name Server + (NBNS) [4] addresses. + +Table of Contents + + 1. Additional IPCP Configuration options ................. 1 + 1.1 Primary DNS Server Address .................... 2 + 1.2 Primary NBNS Server Address ................... 3 + 1.3 Secondary DNS Server Address .................. 4 + 1.4 Secondary NBNS Server Address ................. 5 + REFRENCES .................................................... 6 + SECURITY CONSIDERATIONS ...................................... 6 + CHAIR'S ADDRESS .............................................. 6 + AUTHOR'S ADDRESS ............................................. 6 + +1. Additional IPCP Configuration Options + + The four name server address configuration options, 129 to 132, + provide a method of obtaining the addresses of Domain Name System + (DNS) servers and (NetBIOS Name Server (NBNS) nodes on the remote + network. + + + + + + +Cobb Informational [Page 1] + +RFC 1877 PPP IPCP Extensions December 1995 + + + Primary and secondary addresses are negotiated independently. They + serve identical purposes, except that when both are present an + attempt SHOULD be made to resolve names using the primary address + before using the secondary address. + + For implementational convenience, these options are designed to be + identical in format and behavior to option 3 (IP-Address) which is + already present in most IPCP implementations. + + Since the usefulness of name server address information is dependent + on the topology of the remote network and local peer's application, + it is suggested that these options not be included in the list of + "IPCP Recommended Options". + +1.1. Primary DNS Server Address + + Description + + This Configuration Option defines a method for negotiating with + the remote peer the address of the primary DNS server to be used + on the local end of the link. If local peer requests an invalid + server address (which it will typically do intentionally) the + remote peer specifies the address by NAKing this option, and + returning the IP address of a valid DNS server. + + By default, no primary DNS address is provided. + + A summary of the Primary DNS Address Configuration Option format is + shown below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Primary-DNS-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Primary-DNS-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 129 + + Length + + 6 + + + + + + +Cobb Informational [Page 2] + +RFC 1877 PPP IPCP Extensions December 1995 + + + Primary-DNS-Address + + The four octet Primary-DNS-Address is the address of the primary + DNS server to be used by the local peer. If all four octets are + set to zero, it indicates an explicit request that the peer + provide the address information in a Config-Nak packet. + + Default + + No address is provided. + +1.2. Primary NBNS Server Address + + Description + + This Configuration Option defines a method for negotiating with + the remote peer the address of the primary NBNS server to be used + on the local end of the link. If local peer requests an invalid + server address (which it will typically do intentionally) the + remote peer specifies the address by NAKing this option, and + returning the IP address of a valid NBNS server. + + By default, no primary NBNS address is provided. + + A summary of the Primary NBNS Address Configuration Option format is + shown below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Primary-NBNS-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Primary-NBNS-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 130 + + Length + + 6 + + Primary-NBNS-Address + + The four octet Primary-NBNS-Address is the address of the primary + NBNS server to be used by the local peer. If all four octets are + set to zero, it indicates an explicit request that the peer + + + +Cobb Informational [Page 3] + +RFC 1877 PPP IPCP Extensions December 1995 + + + provide the address information in a Config-Nak packet. + + Default + + No address is provided. + +1.3. Secondary DNS Server Address + + Description + + This Configuration Option defines a method for negotiating with + the remote peer the address of the secondary DNS server to be used + on the local end of the link. If local peer requests an invalid + server address (which it will typically do intentionally) the + remote peer specifies the address by NAKing this option, and + returning the IP address of a valid DNS server. + + By default, no secondary DNS address is provided. + + A summary of the Secondary DNS Address Configuration Option format is + shown below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Secondary-DNS-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Secondary-DNS-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 131 + + Length + + 6 + + Secondary-DNS-Address + + The four octet Secondary-DNS-Address is the address of the primary + NBNS server to be used by the local peer. If all four octets are + set to zero, it indicates an explicit request that the peer + provide the address information in a Config-Nak packet. + + Default + + No address is provided. + + + +Cobb Informational [Page 4] + +RFC 1877 PPP IPCP Extensions December 1995 + + +1.4. Secondary NBNS Server Address + + Description + + This Configuration Option defines a method for negotiating with + the remote peer the address of the secondary NBNS server to be + used on the local end of the link. If local peer requests an + invalid server address (which it will typically do intentionally) + the remote peer specifies the address by NAKing this option, and + returning the IP address of a valid NBNS server. + + By default, no secondary NBNS address is provided. + + A summary of the Secondary NBNS Address Configuration Option format + is shown below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Secondary-NBNS-Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Secondary-NBNS-Address (cont) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 132 + + Length + + 6 + + Secondary-NBNS-Address + + The four octet Secondary-NBNS-Address is the address of the + secondary NBNS server to be used by the local peer. If all + four octets are set to zero, it indicates an explicit request + that the peer provide the address information in a Config-Nak + packet. + + Default + + No address is provided. + + + + + + + + +Cobb Informational [Page 5] + +RFC 1877 PPP IPCP Extensions December 1995 + + +References + + [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, + RFC 1661, Daydreamer, July 1994. + + [2] McGregor, G., "PPP Internet Control Protocol", RFC 1332, Merit, + May 1992. + + [3] Auerbach, K., and A. Aggarwal, "Protocol Standard for a NetBIOS + Service on a TCP/UDP Transport", STD 19, RFCs 1001 and 1002, + March 1987. + + [4] Mockapetris, P., "Domain Names - Concepts and Facilities", STD + 13, RFC 1034, USC/Information Sciences Institute, November 1987. + + [5] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, USC/Information Sciences + Institute, November 1987. + +Security Considerations + + Security issues are not discussed in this memo. + +Chair's Address + + The working group can be contacted via the current chair: + + Fred Baker + Cisco Systems + 519 Lado Drive + Santa Barbara, California 93111 + + EMail: fred@cisco.com + +Author's Address + + Questions about this memo can also be directed to: + + Steve Cobb + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052-6399 + + Phone: (206) 882-8080 + + EMail: stevec@microsoft.com + + + + + +Cobb Informational [Page 6] + diff --git a/doc/rfc1962.txt b/doc/rfc1962.txt new file mode 100644 index 00000000..fc9b47d3 --- /dev/null +++ b/doc/rfc1962.txt @@ -0,0 +1,507 @@ + + + + + + +Network Working Group D. Rand +Request for Comments: 1962 Novell +Category: Standards Track June 1996 + + + The PPP Compression Control Protocol (CCP) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + The Point-to-Point Protocol (PPP) [1] provides a standard method for + transporting multi-protocol datagrams over point-to-point links. PPP + also defines an extensible Link Control Protocol. + + This document defines a method for negotiating data compression over + PPP links. + +Table of Contents + + 1. Introduction .......................................... 1 + 2. Compression Control Protocol (CCP) .................... 2 + 2.1 Sending Compressed Datagrams .................... 3 + 3. Additional Packets .................................... 4 + 3.1 Reset-Request and Reset-Ack ..................... 4 + 4. CCP Configuration Options ............................. 5 + 4.1 Proprietary Compression OUI ..................... 7 + 4.2 Other Compression Types ......................... 8 + SECURITY CONSIDERATIONS ...................................... 9 + REFERENCES ................................................... 9 + ACKNOWLEDGEMENTS ............................................. 9 + CHAIR'S ADDRESS .............................................. 9 + AUTHOR'S ADDRESS ............................................. 9 + +1. Introduction + + In order to establish communications over a PPP link, each end of the + link must first send LCP packets to configure and test the data link + during Link Establishment phase. After the link has been + established, optional facilities may be negotiated as needed. + + + + + +Rand Standards Track [Page 1] + +RFC 1962 PPP Compression June 1996 + + + One such facility is data compression. A wide variety of compression + methods may be negotiated, although typically only one method is used + in each direction of the link. + + A different compression algorithm may be negotiated in each + direction, for speed, cost, memory or other considerations, or only + one direction may be compressed. + +2. Compression Control Protocol (CCP) + + The Compression Control Protocol (CCP) is responsible for + configuring, enabling, and disabling data compression algorithms on + both ends of the point-to-point link. It is also used to signal a + failure of the compression/decompression mechanism in a reliable + manner. + + CCP uses the same packet exchange mechanism as the Link Control + Protocol (LCP). CCP packets may not be exchanged until PPP has + reached the Network-Layer Protocol phase. CCP packets received + before this phase is reached should be silently discarded. + + The Compression Control Protocol is exactly the same as the Link + Control Protocol [1] with the following exceptions: + + Frame Modifications + + The packet may utilize any modifications to the basic frame format + which have been negotiated during the Link Establishment phase. + + Data Link Layer Protocol Field + + Exactly one CCP packet is encapsulated in the PPP Information + field, where the PPP Protocol field indicates type hex 80FD + (Compression Control Protocol). + + When individual link data compression is used in a multiple link + connection to a single destination, the PPP Protocol field + indicates type hex 80FB (Individual link Compression Control + Protocol). + + Code field + + In addition to Codes 1 through 7 (Configure-Request, Configure- + Ack, Configure-Nak, Configure-Reject, Terminate-Request, + Terminate-Ack and Code-Reject), two additional Codes 14 and 15 + (Reset-Request and Reset-Ack) are defined for this protocol. + Other Codes should be treated as unrecognized and should result in + Code-Rejects. + + + +Rand Standards Track [Page 2] + +RFC 1962 PPP Compression June 1996 + + + Timeouts + + CCP packets may not be exchanged until PPP has reached the + Network-Layer Protocol phase. An implementation should be + prepared to wait for Authentication and Link Quality Determination + to finish before timing out waiting for a Configure-Ack or other + response. It is suggested that an implementation give up only + after user intervention or a configurable amount of time. + + Configuration Option Types + + CCP has a distinct set of Configuration Options. + +2.1. Sending Compressed Datagrams + + Before any compressed packets may be communicated, PPP must reach the + Network-Layer Protocol phase, and the Compression Control Protocol + must reach the Opened state. + + One or more compressed packets are encapsulated in the PPP + Information field, where the PPP Protocol field indicates type hex + 00FD (Compressed datagram). Each of the compression algorithms may + use a different mechanism to indicate the inclusion of more than one + uncompressed packet in a single Data Link Layer frame. + + When using multiple PPP links to a single destination, there are two + methods of employing data compression. The first method is to + compress the data prior to sending it out through the multiple links. + The second is to treat each link as a separate connection, that may + or may not have compression enabled. In the second case, the PPP + Protocol field MUST be type hex 00FB (Individual link compressed + datagram). + + Only one primary algorithm in each direction is in use at a time, and + that is negotiated prior to sending the first compressed frame. The + PPP Protocol field of the compressed datagram indicates that the + frame is compressed, but not the algorithm with which it was + compressed. + + The maximum length of a compressed packet transmitted over a PPP link + is the same as the maximum length of the Information field of a PPP + encapsulated packet. Larger datagrams (presumably the result of the + compression algorithm increasing the size of the message in some + cases) may be sent uncompressed, using its standard form, or may be + sent in multiple datagrams, if the compression algorithm supports it. + + Each of the compression algorithms must supply a way of determining + if they are passing data reliably, or they must require the use of a + + + +Rand Standards Track [Page 3] + +RFC 1962 PPP Compression June 1996 + + + reliable transport such as LAPB [3]. Vendors are strongly encouraged + to employ a method of validating the compressed data, or recognizing + out-of-sync compressor/decompressor pairs. + +3. Additional Packets + + The Packet format and basic facilities are already defined for LCP + [1]. + + Up-to-date values of the CCP Code field are specified in the most + recent "Assigned Numbers" RFC [2]. This specification concerns the + following values: + + 14 Reset-Request + 15 Reset-Ack + +3.1. Reset-Request and Reset-Ack + + Description + + CCP includes Reset-Request and Reset-Ack Codes in order to provide + a mechanism for indicating a decompression failure in one + direction of a compressed link without affecting traffic in the + other direction. A decompression failure may be determined by + periodically passing a hash value, performing a CRC check on the + decompressed data, or other mechanism. It is strongly suggested + that some mechanism be available in all compression algorithms to + validate the decompressed data before passing the data on to the + rest of the system. + + A CCP implementation wishing to indicate a decompression failure + SHOULD transmit a CCP packet with the Code field set to 14 + (Reset-Request), and the Data field filled with any desired data. + Once a Reset-Request has been sent, any Compressed packets + received are discarded, and another Reset-Request is sent with the + same Identifier, until a valid Reset-Ack is received. + + Upon reception of a Reset-Request, the transmitting compressor is + reset to an initial state. This may include clearing a + dictionary, resetting hash codes, or other mechanisms. A CCP + packet MUST be transmitted with the Code field set to 15 (Reset- + Ack), the Identifier field copied from the Reset-Request packet, + and the Data field filled with any desired data. + + On receipt of a Reset-Ack, the receiving decompressor is reset to + an initial state. This may include clearing a dictionary, + resetting hash codes, or other mechanisms. Since there may be + several Reset-Acks in the pipe, the decompressor MUST be reset for + + + +Rand Standards Track [Page 4] + +RFC 1962 PPP Compression June 1996 + + + each Reset-Ack which matches the currently expected identifier. + + A summary of the Reset-Request and Reset-Ack packet formats is shown + below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + + Code + + 14 for Reset-Request; + + 15 for Reset-Ack. + + Identifier + + On transmission, the Identifier field MUST be changed whenever the + content of the Data field changes, and whenever a valid reply has + been received for a previous request. For retransmissions, the + Identifier MAY remain unchanged. + + On reception, the Identifier field of the Reset-Request is copied + into the Identifier field of the Reset-Ack packet. + + Data + + The Data field is zero or more octets and contains uninterpreted + data for use by the sender. The data may consist of any binary + value and may be of any length from zero to the peer's established + MRU minus four. + +4. CCP Configuration Options + + CCP Configuration Options allow negotiation of compression algorithms + and their parameters. CCP uses the same Configuration Option format + defined for LCP [1], with a separate set of Options. + + Configuration Options, in this protocol, indicate algorithms that the + receiver is willing or able to use to decompress data sent by the + sender. As a result, it is to be expected that systems will offer to + accept several algorithms, and negotiate a single one that will be + used. + + + +Rand Standards Track [Page 5] + +RFC 1962 PPP Compression June 1996 + + + There is the possibility of not being able to agree on a compression + algorithm. In that case, no compression will be used, and the link + will continue to operate without compression. If link reliability + has been separately negotiated, then it will continue to be used, + until the LCP is re-negotiated. + + We expect that many vendors will want to use proprietary compression + algorithms, and have made a mechanism available to negotiate these + without encumbering the Internet Assigned Number Authority with + proprietary number requests. + + The LCP option negotiation techniques are used. If an option is + unrecognized, a Configure-Reject MUST be sent. If all protocols the + sender implements are Configure-Rejected by the receiver, then no + compression is enabled in that direction of the link. + + If an option is recognized, but not acceptable due to values in the + request (or optional parameters not in the request), a Configure-NAK + MUST be sent with the option modified appropriately. The Configure- + NAK MUST contain only those options that will be acceptable. A new + Configure-Request SHOULD be sent with only the single preferred + option, adjusted as specified in the Configure-Nak. + + Up-to-date values of the CCP Option Type field are specified in the + most recent "Assigned Numbers" RFC [2]. Current values are assigned + as follows: + + CCP Option Compression type + 0 OUI + 1 Predictor type 1 + 2 Predictor type 2 + 3 Puddle Jumper + 4-15 unassigned + 16 Hewlett-Packard PPC + 17 Stac Electronics LZS + 18 Microsoft PPC + 19 Gandalf FZA + 20 V.42bis compression + 21 BSD LZW Compress + 255 Reserved + + The unassigned values 4-15 are intended to be assigned to other + freely available compression algorithms that have no license fees. + + + + + + + + +Rand Standards Track [Page 6] + +RFC 1962 PPP Compression June 1996 + + +4.1. Proprietary Compression OUI + + Description + + This Configuration Option provides a way to negotiate the use of a + proprietary compression protocol. + + Since the first matching compression will be used, it is + recommended that any known OUI compression options be transmitted + first, before the common options are used. + + Before accepting this option, the implementation must verify that + the Organization Unique Identifier identifies a proprietary + algorithm that the implementation can decompress, and that any + vendor specific negotiation values are fully understood. + + A summary of the Proprietary Compression OUI Configuration Option + format is shown below. The fields are transmitted from left to + right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | OUI ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + OUI | Subtype | Values... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + Type + + 0 + + Length + + >= 6 + + IEEE OUI + + The vendor's IEEE Organization Unique Identifier (OUI), which is + the most significant three octets of an Ethernet Physical Address, + assigned to the vendor by IEEE 802. This identifies the option as + being proprietary to the indicated vendor. The bits within the + octet are in canonical order, and the most significant octet is + transmitted first. + + + + + + +Rand Standards Track [Page 7] + +RFC 1962 PPP Compression June 1996 + + + Subtype + + This field is specific to each OUI, and indicates a compression + type for that OUI. There is no standardization for this field. + Each OUI implements its own values. + + Values + + This field is zero or more octets, and contains additional data as + determined by the vendor's compression protocol. + +4.2. Other Compression Types + + Description + + These Configuration Options provide a way to negotiate the use of + a publicly defined compression algorithm. Many compression + algorithms are specified. No particular compression technique has + arisen as an Internet Standard. + + These protocols will be made available to all interested parties, + but may have certain licensing restrictions associated with them. + For additional information, refer to the compression protocol + documents that define each of the compression types. + + A summary of the Compression Type Configuration Option format is + shown below. The fields are transmitted from left to right. + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Values... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + Type + + 1 to 254 + + Length + + >= 2 + + Values + + This field is zero or more octets, and contains additional data as + determined by the compression protocol. + + + +Rand Standards Track [Page 8] + +RFC 1962 PPP Compression June 1996 + + +Security Considerations + + Security issues are not discussed in this memo. + +References + + [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD + 51, RFC 1661, July 1994. + + [2] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC + 1700, USC/Information Sciences Institute, October 1994. + + [3] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994. + +Acknowledgments + + Bill Simpson helped with the document formatting. + +Chair's Address + + The working group can be contacted via the current chair: + + Karl Fox + Ascend Communications + 3518 Riverside Drive, Suite 101 + Columbus, Ohio 43221 + + EMail: karl@ascend.com + +Author's Address + + Questions about this memo can also be directed to: + + Dave Rand + Novell, Inc. + 2180 Fortune Drive + San Jose, CA 95131 + + +1 408 321-1259 + + EMail: dlr@daver.bungi.com + + + + + + + + + + +Rand Standards Track [Page 9] + diff --git a/doc/rfc1979.txt b/doc/rfc1979.txt new file mode 100644 index 00000000..7a95cd3b --- /dev/null +++ b/doc/rfc1979.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group J. Woods +Request for Comments: 1979 Proteon, Inc. +Category: Informational August 1996 + + + PPP Deflate Protocol + +Status of This Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Abstract + + The Point-to-Point Protocol (PPP) [1] provides a standard method for + transporting multi-protocol datagrams over point-to-point links. + + The PPP Compression Control Protocol [2] provides a method to + negotiate and utilize compression protocols over PPP encapsulated + links. + + This document describes the use of the PPP Deflate compression + protocol for compressing PPP encapsulated packets. + +Table of Contents + + 1. Introduction ...................................... 2 + 1.1 Licensing ................................... 2 + 2. PPP Deflate Packets ............................... 3 + 2.1 Packet Format ............................... 6 + 3. Configuration Option Format ....................... 8 + SECURITY CONSIDERATIONS .................................. 9 + REFERENCES ............................................... 9 + ACKNOWLEDGEMENTS ......................................... 9 + CHAIR'S ADDRESS .......................................... 10 + AUTHOR'S ADDRESS ......................................... 10 + + + + + + + + + + + + + + +Woods Informational [Page 1] + +RFC 1979 PPP Deflate August 1996 + + +1. Introduction + +The 'deflate' compression format[3], as used by the PKZIP and gzip +compressors and as embodied in the freely and widely distributed +zlib[4] library source code, has the following features: + + - an apparently unencumbered encoding and compression + algorithm, with an open and publically-available + specification. + + - low-overhead escape mechanism for incompressible data. The + PPP Deflate specification offers options to reduce that + overhead further. + + - heavily used for many years in networks, on modem and other + point-to-point links to transfer files for personal computers + and workstations. + + - easily achieves 2:1 compression on the Calgary corpus[5] + using less than 64KBytes of memory on both sender and + receive. + +1.1. Licensing + + The zlib source is widely and freely available, subject to the + following copyright: + + (C) 1995 Jean-Loup Gailly and Mark Adler + + This software is provided 'as-is', without any express or implied + warranty. In no event will the authors be held liable for any + damages arising from the use of this software. + + Permission is granted to anyone to use this software for any + purpose, including commercial applications, and to alter it and + redistribute it freely, subject to the following restrictions: + + 1. The origin of this software must not be misrepresented; you + must not claim that you wrote the original software. If you + use this software in a product, an acknowledgment in the + product documentation would be appreciated but is not + required. + + 2. Altered source versions must be plainly marked as such, and + must not be misrepresented as being the original software. + + + + + + +Woods Informational [Page 2] + +RFC 1979 PPP Deflate August 1996 + + + 3. This notice may not be removed or altered from any source + distribution. + + Jean-Loup Gailly Mark Adler + gzip@prep.ai.mit.edu madler@alumni.caltech.edu + + If you use the zlib library in a product, we would appreciate + *not* receiving lengthy legal documents to sign. The sources are + provided for free but without warranty of any kind. The library + has been entirely written by Jean-Loup Gailly and Mark Adler; it + does not include third-party code. + + The deflate format and compression algorithm are based on Lempel-Ziv + LZ77 compression; extensive research has been done by the GNU Project + and the Portable Network Graphics working group supporting its patent + free status. + +2. PPP Deflate Packets + + Before any PPP Deflate packets may be communicated, PPP must reach + the Network-Layer Protocol phase, and the CCP Control Protocol must + reach the Opened state. + + Exactly one PPP Deflate datagram is encapsulated in the PPP + Information field, where the PPP Protocol field contains 0xFD or + 0xFB. 0xFD is used when the PPP multilink protocol is not used or + "above" multilink. 0xFB is used "below" multilink, to compress + independently on individual links of a multilink bundle. + + The maximum length of the PPP Deflate datagram transmitted over a PPP + link is the same as the maximum length of the Information field of a + PPP encapsulated packet. + + Only packets with PPP Protocol numbers in the range 0x0000 to 0x3FFF + and neither 0xFD nor 0xFB are compressed. Other PPP packets are + always sent uncompressed. Control packets are infrequent and should + not be compressed for robustness. + + Padding + + PPP Deflate packets require the previous negotiation of the Self- + Describing-Padding Configuration Option [6] if padding is added to + packets. If no padding is added, than Self-Describing-Padding is + not required. + + + + + + + +Woods Informational [Page 3] + +RFC 1979 PPP Deflate August 1996 + + + Reliability and Sequencing + + PPP Deflate requires the packets to be delivered in sequence. It + relies on Reset-Request and Reset-Ack LCP packets or on + renegotiation of the Compression Control Protocol [2] to indicate + loss of synchronization between the transmitter and receiver. The + LCP FCS detects corrupted packets and the normal mechanisms + discard them. Missing or out of order packets are detected by the + sequence number in each packet. The packet sequence number ought + to be checked before decoding the packet. + + Instead of transmitting a Reset-Request packet when detecting a + sequence error, the receiver MAY momentarily force CCP to drop out + of the Opened state by transmitting a new CCP Configure-Request. + This method is more expensive than using Reset-Requests. + + When the receiver first encounters an unexpected sequence number + it SHOULD send a Reset-Request LCP packet as defined in the + Compression Control Protocol. When the transmitter sends the + Reset-Ack or when the receiver receives a Reset-ACK, they must + reset the sequence number to zero, clear the compression + dictionary, and resume sending and receiving compressed packets. + The receiver MUST discard all compressed packets after detecting + an error and until it receives a Reset-Ack. This strategy can be + thought of as abandoning the transmission of one "file" and + starting the transmission of a new "file." + + The transmitter must clear its compression history and respond + with a Reset-Ack each time it receives a Reset-Request, because it + cannot know if previous Reset-Acks reached the receiver. The + receiver need not do anything to its history when it receives a + Reset-Ack, because the transmitter will simply not refer to any + prior history ('deflate' is a sliding-window compressor). + + When the link is busy, one decompression error is usually followed + by several more before the Reset-Ack can be received. It is + undesirable to transmit Reset-Requests more frequently than the + round-trip-time of the link, because redundant Reset-Requests + cause unnecessary compression dictionary clearing. The receiver + MAY transmit an additional Reset-Request each time it receives a + compressed or uncompressed packet until it finally receives a + Reset-Ack, but the receiver ought not transmit another Reset- + Request until the Reset-Ack for the previous one is late. The + receiver MUST transmit enough Reset-Request packets to ensure that + the transmitter receives at least one. For example, the receiver + might choose to not transmit another Reset-Request until after one + second (or, of course, a Reset-Ack has been received and + decompression resumed). + + + +Woods Informational [Page 4] + +RFC 1979 PPP Deflate August 1996 + + + Data Expansion + + 'Deflate', as used in this standard, expands incompressible data + by approximately 14-18 bytes (8 bytes worst-case at the 'deflate' + level, two further bytes for the 'deflate' end-of-block and the + zero-length synchronization block header, two bytes of sequence + number, and two bytes to account for adding the PPP Protocol Field + to the transmitted data unit). + + The BSD Compress draft proposal[7] describes an escape mechanism + for incompressible data that trades off a layering violation for + the irritating complications of variable and potentially + unpredictable effective MRU lengths. That direct escape mechanism + (and much of the text of its description) is used here as well. + + If an incompressible data packet does not fit within the MRU of + the link, the packet MUST be sent in its original form without CCP + encapsulation; PPP packets with significant data expansion that do + not exceed the MRU of the link SHOULD be sent in their original + form without CCP encapsulation. In both of these cases, the + transmitter must increment the sequence number, as future + encapsulated packets will depend on the correct reception of some + number of unencapsulated packets. + + When a PPP packet is received with PPP Protocol numbers in the + range 0x0000 to 0x3FFF, (except, of course, 0xFD and 0xFB) it is + assumed that the packet would have caused expansion. The packet + is locally added to the compression history. (Given the + definition of the 'deflate' format, a convenient method of doing + this is to locally "decompress" a stored-block header of the + appropriate length, followed by the actual data block; or the data + can simply be appended to the receiver's history, depending on + implementation details.) + + Sending incompressible packets in their native encapsulation + avoids maximum transmission unit complications. If uncompressed + packets could be larger than their native form, then it would be + necessary for the upper layers of an implementation to treat the + PPP link as if it had a smaller MTU, to ensure that compressed + incompressible packets are never larger than the negotiated PPP + MTU. + + Using native encapsulation for incompressible packets complicates + the implementation. The transmitter and the receiver must start + putting information into the compression dictionary starting with + the same packets, without relying upon seeing a compressed packet + for synchronization. The first few packets after clearing the + dictionary are usually incompressible, and so are likely to sent + + + +Woods Informational [Page 5] + +RFC 1979 PPP Deflate August 1996 + + + in their native encapsulation, just like packets before + compression is turned on. If CCP or LCP packets are handled + separately from Network-Layer packets (e.g. a "daemon" for control + packets and "kernel code" for data packets), care must be taken to + ensure that the transmitter synchronizes clearing the dictionary + with the transmission of the configure-ACK or Reset-Ack that + starts compression, and the receiver must similarly ensure that + its dictionary is cleared before it processes the next packet. + +2.1. Packet Format + + A summary of the PPP Deflate packet format is shown below. + + The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PPP Protocol | Sequence | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+-+-+-+-+ + + + PPP Protocol + + The PPP Protocol field is described in the Point-to-Point Protocol + Encapsulation [1]. + + When the PPP Deflate compression protocol is successfully + negotiated by the PPP Compression Control Protocol [2], the value + of the protocol field is 0xFD or 0xFB. This value MAY be + compressed when Protocol-Field-Compression is negotiated. + + Sequence + + The sequence number is sent most significant octet first. It + starts at 0 when the dictionary is cleared, and is incremented by + 1 for each packet, including uncompressed packets. The sequence + number after 65535 is zero. In other words, the sequence number + "wraps" in the usual way. + + The sequence number ensures that lost or out of order packets do + not cause the compression databases of the peers to become + unsynchronized. When an unexpected sequence number is + encountered, the dictionaries must be resynchronized with a CCP + Reset-Request or Configure-Request. The packet sequence number + can be checked before a compressed packet is decoded. + + + +Woods Informational [Page 6] + +RFC 1979 PPP Deflate August 1996 + + + Data + + The compressed PPP encapsulated packet, consisting of the Protocol + and Data fields of the original, uncompressed packet follows. + + The Protocol field compression MUST be applied to the protocol + field in the original packet before the sequence number is + computed or the entire packet is compressed, regardless of whether + the PPP protocol field compression has been negotiated. Thus, if + the original protocol number was less than 0x100, it must be + compressed to a single byte. + + The basic format of the compressed data is precisely described by + the 'Deflate' Compressed Data Format Specification[3]. Each + transmitted packet must begin at a 'deflate' block boundary, to + ensure synchronization when incompressible data resets the + transmitter's state; to ensure this, each transmitted packet must + be terminated with a zero-length 'deflate' non-compressed block + (BTYPE of 00). This means that the last four bytes of the + compressed format must be 0x00 0x00 0xFF 0xFF. These bytes MUST + be removed before transmission; the receiver can reinsert them if + required by the implementation. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woods Informational [Page 7] + +RFC 1979 PPP Deflate August 1996 + + +3. Configuration Option Format + + + Description + + The CCP PPP Deflate Configuration Option negotiates the use of PPP + Deflate on the link. By default or ultimate disagreement, no + compression is used. + + A summary of the PPP Deflate Configuration Option format is shown + below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length |Window | Method| MBZ |Chk| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 26 for PPP Deflate. + + Length + + 3 + + Window + + Represents the maximum window size the decompressor is willing to + allocate; expressed as the base-2 logarithm of the LZ77 window + size, minus 8. 'Deflate' compliant decompressors must be willing + to accept the maximum 32KB window size, represented by a value of + 7. A 'deflate' compliant compressor is at liberty to use a + reduced window size, so a PPP Deflate compressor MUST either honor + the restriction requested or reject the option. + + Method + + Must be the binary number 1000. Represents the 'zlib' Compression + Method identifier of '8' for 'deflate' compression with up to 32K + window size. + + MBZ + + Must be all 0 bits. + + + + + +Woods Informational [Page 8] + +RFC 1979 PPP Deflate August 1996 + + + Chk + + Must be 00 to specify sequence number check method. + +Security Considerations + + Security issues are not discussed in this memo. + +References + + [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, + RFC 1661, July 1994. + + [2] Rand, D., "The PPP Compression Control Protocol (CCP)", + RFC 1962, June 1996. + + [3] Deutsch, L.P., "'Deflate' Compressed Data Format + Specification", draft available in + ftp.uu.net:/pub/archiving/zip/doc/deflate-1.1.doc. + + [4] Gailly, J.-L., "Zlib 0.95 beta". + + [5] Bell, T.C., Cleary, G. G. and Witten, I.H., "Text Compression", + Prentice_Hall, Englewood Cliffs NJ, 1990. The compression + corpus itself can be found in ftp.uu.net:/pub/archiving/zip/. + + [6] Simpson, W., "PPP LCP Extensions", RFC 1570, January 1994. + + [7] Schryver, V., "PPP BSD Compression Protocol", RFC 1977, + August 1996. + +Acknowledgments + + William Simpson provided the very valuable idea of not using any + additional header bytes for incompressible packets. + + + + + + + + + + + + + + + + +Woods Informational [Page 9] + +RFC 1979 PPP Deflate August 1996 + + +Chair's Address + + The working group can be contacted via the current chair: + + Karl Fox + Ascend Communications + 3518 Riverside Drive, Suite 101 + Columbus, Ohio 43221 + + EMail: karl@ascend.com + +Author's Address + + Questions about this memo can also be directed to: + + John Woods + Proteon, Inc. + 9 Technology Drive + Westborough MA 01581-1799 + + (508) 898-2800 ext. 2651 + EMail: jfw@funhouse.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Woods Informational [Page 10] + diff --git a/doc/rfc1994.txt b/doc/rfc1994.txt new file mode 100644 index 00000000..e4a553e5 --- /dev/null +++ b/doc/rfc1994.txt @@ -0,0 +1,732 @@ + + + + + + +Network Working Group W. Simpson +Request for Comments: 1994 DayDreamer +Obsoletes: 1334 August 1996 +Category: Standards Track + + + PPP Challenge Handshake Authentication Protocol (CHAP) + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + The Point-to-Point Protocol (PPP) [1] provides a standard method for + transporting multi-protocol datagrams over point-to-point links. + + PPP also defines an extensible Link Control Protocol, which allows + negotiation of an Authentication Protocol for authenticating its peer + before allowing Network Layer protocols to transmit over the link. + + This document defines a method for Authentication using PPP, which + uses a random Challenge, with a cryptographically hashed Response + which depends upon the Challenge and a secret key. + +Table of Contents + + 1. Introduction .......................................... 1 + 1.1 Specification of Requirements ................... 1 + 1.2 Terminology ..................................... 2 + 2. Challenge-Handshake Authentication Protocol ........... 2 + 2.1 Advantages ...................................... 3 + 2.2 Disadvantages ................................... 3 + 2.3 Design Requirements ............................. 4 + 3. Configuration Option Format ........................... 5 + 4. Packet Format ......................................... 6 + 4.1 Challenge and Response .......................... 7 + 4.2 Success and Failure ............................. 9 + SECURITY CONSIDERATIONS ...................................... 10 + ACKNOWLEDGEMENTS ............................................. 11 + REFERENCES ................................................... 12 + CONTACTS ..................................................... 12 + + + + +Simpson [Page i] + +RFC 1994 PPP CHAP August 1996 + + +1. Introduction + + In order to establish communications over a point-to-point link, each + end of the PPP link must first send LCP packets to configure the data + link during Link Establishment phase. After the link has been + established, PPP provides for an optional Authentication phase before + proceeding to the Network-Layer Protocol phase. + + By default, authentication is not mandatory. If authentication of + the link is desired, an implementation MUST specify the + Authentication-Protocol Configuration Option during Link + Establishment phase. + + These authentication protocols are intended for use primarily by + hosts and routers that connect to a PPP network server via switched + circuits or dial-up lines, but might be applied to dedicated links as + well. The server can use the identification of the connecting host + or router in the selection of options for network layer negotiations. + + This document defines a PPP authentication protocol. The Link + Establishment and Authentication phases, and the Authentication- + Protocol Configuration Option, are defined in The Point-to-Point + Protocol (PPP) [1]. + + +1.1. Specification of Requirements + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. + + MUST This word, or the adjective "required", means that the + definition is an absolute requirement of the specification. + + MUST NOT This phrase means that the definition is an absolute + prohibition of the specification. + + SHOULD This word, or the adjective "recommended", means that there + may exist valid reasons in particular circumstances to + ignore this item, but the full implications must be + understood and carefully weighed before choosing a + different course. + + MAY This word, or the adjective "optional", means that this + item is one of an allowed set of alternatives. An + implementation which does not include this option MUST be + prepared to interoperate with another implementation which + does include the option. + + + + +Simpson [Page 1] + +RFC 1994 PPP CHAP August 1996 + + +1.2. Terminology + + This document frequently uses the following terms: + + authenticator + The end of the link requiring the authentication. The + authenticator specifies the authentication protocol to be + used in the Configure-Request during Link Establishment + phase. + + peer The other end of the point-to-point link; the end which is + being authenticated by the authenticator. + + silently discard + This means the implementation discards the packet without + further processing. The implementation SHOULD provide the + capability of logging the error, including the contents of + the silently discarded packet, and SHOULD record the event + in a statistics counter. + + + + +2. Challenge-Handshake Authentication Protocol + + The Challenge-Handshake Authentication Protocol (CHAP) is used to + periodically verify the identity of the peer using a 3-way handshake. + This is done upon initial link establishment, and MAY be repeated + anytime after the link has been established. + + 1. After the Link Establishment phase is complete, the + authenticator sends a "challenge" message to the peer. + + 2. The peer responds with a value calculated using a "one-way + hash" function. + + 3. The authenticator checks the response against its own + calculation of the expected hash value. If the values match, + the authentication is acknowledged; otherwise the connection + SHOULD be terminated. + + 4. At random intervals, the authenticator sends a new challenge to + the peer, and repeats steps 1 to 3. + + + + + + + + +Simpson [Page 2] + +RFC 1994 PPP CHAP August 1996 + + +2.1. Advantages + + CHAP provides protection against playback attack by the peer through + the use of an incrementally changing identifier and a variable + challenge value. The use of repeated challenges is intended to limit + the time of exposure to any single attack. The authenticator is in + control of the frequency and timing of the challenges. + + This authentication method depends upon a "secret" known only to the + authenticator and that peer. The secret is not sent over the link. + + Although the authentication is only one-way, by negotiating CHAP in + both directions the same secret set may easily be used for mutual + authentication. + + Since CHAP may be used to authenticate many different systems, name + fields may be used as an index to locate the proper secret in a large + table of secrets. This also makes it possible to support more than + one name/secret pair per system, and to change the secret in use at + any time during the session. + + +2.2. Disadvantages + + CHAP requires that the secret be available in plaintext form. + Irreversably encrypted password databases commonly available cannot + be used. + + It is not as useful for large installations, since every possible + secret is maintained at both ends of the link. + + Implementation Note: To avoid sending the secret over other links + in the network, it is recommended that the challenge and response + values be examined at a central server, rather than each network + access server. Otherwise, the secret SHOULD be sent to such + servers in a reversably encrypted form. Either case requires a + trusted relationship, which is outside the scope of this + specification. + + + + + + + + + + + + + +Simpson [Page 3] + +RFC 1994 PPP CHAP August 1996 + + +2.3. Design Requirements + + The CHAP algorithm requires that the length of the secret MUST be at + least 1 octet. The secret SHOULD be at least as large and + unguessable as a well-chosen password. It is preferred that the + secret be at least the length of the hash value for the hashing + algorithm chosen (16 octets for MD5). This is to ensure a + sufficiently large range for the secret to provide protection against + exhaustive search attacks. + + The one-way hash algorithm is chosen such that it is computationally + infeasible to determine the secret from the known challenge and + response values. + + Each challenge value SHOULD be unique, since repetition of a + challenge value in conjunction with the same secret would permit an + attacker to reply with a previously intercepted response. Since it + is expected that the same secret MAY be used to authenticate with + servers in disparate geographic regions, the challenge SHOULD exhibit + global and temporal uniqueness. + + Each challenge value SHOULD also be unpredictable, least an attacker + trick a peer into responding to a predicted future challenge, and + then use the response to masquerade as that peer to an authenticator. + + Although protocols such as CHAP are incapable of protecting against + realtime active wiretapping attacks, generation of unique + unpredictable challenges can protect against a wide range of active + attacks. + + A discussion of sources of uniqueness and probability of divergence + is included in the Magic-Number Configuration Option [1]. + + + + + + + + + + + + + + + + + + + +Simpson [Page 4] + +RFC 1994 PPP CHAP August 1996 + + +3. Configuration Option Format + + A summary of the Authentication-Protocol Configuration Option format + to negotiate the Challenge-Handshake Authentication Protocol is shown + below. The fields are transmitted from left to right. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Authentication-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Algorithm | + +-+-+-+-+-+-+-+-+ + + Type + + 3 + + Length + + 5 + + Authentication-Protocol + + c223 (hex) for Challenge-Handshake Authentication Protocol. + + Algorithm + + The Algorithm field is one octet and indicates the authentication + method to be used. Up-to-date values are specified in the most + recent "Assigned Numbers" [2]. One value is required to be + implemented: + + 5 CHAP with MD5 [3] + + + + + + + + + + + + + + + + + + + +Simpson [Page 5] + +RFC 1994 PPP CHAP August 1996 + + +4. Packet Format + + Exactly one Challenge-Handshake Authentication Protocol packet is + encapsulated in the Information field of a PPP Data Link Layer frame + where the protocol field indicates type hex c223 (Challenge-Handshake + Authentication Protocol). A summary of the CHAP packet format is + shown below. The fields are transmitted from left to right. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + Code + + The Code field is one octet and identifies the type of CHAP + packet. CHAP Codes are assigned as follows: + + 1 Challenge + 2 Response + 3 Success + 4 Failure + + Identifier + + The Identifier field is one octet and aids in matching challenges, + responses and replies. + + Length + + The Length field is two octets and indicates the length of the + CHAP packet including the Code, Identifier, Length and Data + fields. Octets outside the range of the Length field should be + treated as Data Link Layer padding and should be ignored on + reception. + + Data + + The Data field is zero or more octets. The format of the Data + field is determined by the Code field. + + + + + + + + + + +Simpson [Page 6] + +RFC 1994 PPP CHAP August 1996 + + +4.1. Challenge and Response + + Description + + The Challenge packet is used to begin the Challenge-Handshake + Authentication Protocol. The authenticator MUST transmit a CHAP + packet with the Code field set to 1 (Challenge). Additional + Challenge packets MUST be sent until a valid Response packet is + received, or an optional retry counter expires. + + A Challenge packet MAY also be transmitted at any time during the + Network-Layer Protocol phase to ensure that the connection has not + been altered. + + The peer SHOULD expect Challenge packets during the Authentication + phase and the Network-Layer Protocol phase. Whenever a Challenge + packet is received, the peer MUST transmit a CHAP packet with the + Code field set to 2 (Response). + + Whenever a Response packet is received, the authenticator compares + the Response Value with its own calculation of the expected value. + Based on this comparison, the authenticator MUST send a Success or + Failure packet (described below). + + Implementation Notes: Because the Success might be lost, the + authenticator MUST allow repeated Response packets during the + Network-Layer Protocol phase after completing the + Authentication phase. To prevent discovery of alternative + Names and Secrets, any Response packets received having the + current Challenge Identifier MUST return the same reply Code + previously returned for that specific Challenge (the message + portion MAY be different). Any Response packets received + during any other phase MUST be silently discarded. + + When the Failure is lost, and the authenticator terminates the + link, the LCP Terminate-Request and Terminate-Ack provide an + alternative indication that authentication failed. + + + + + + + + + + + + + + +Simpson [Page 7] + +RFC 1994 PPP CHAP August 1996 + + + A summary of the Challenge and Response packet format is shown below. + The fields are transmitted from left to right. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value-Size | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Name ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code + + 1 for Challenge; + + 2 for Response. + + Identifier + + The Identifier field is one octet. The Identifier field MUST be + changed each time a Challenge is sent. + + The Response Identifier MUST be copied from the Identifier field + of the Challenge which caused the Response. + + Value-Size + + This field is one octet and indicates the length of the Value + field. + + Value + + The Value field is one or more octets. The most significant octet + is transmitted first. + + The Challenge Value is a variable stream of octets. The + importance of the uniqueness of the Challenge Value and its + relationship to the secret is described above. The Challenge + Value MUST be changed each time a Challenge is sent. The length + of the Challenge Value depends upon the method used to generate + the octets, and is independent of the hash algorithm used. + + The Response Value is the one-way hash calculated over a stream of + octets consisting of the Identifier, followed by (concatenated + with) the "secret", followed by (concatenated with) the Challenge + Value. The length of the Response Value depends upon the hash + algorithm used (16 octets for MD5). + + + + +Simpson [Page 8] + +RFC 1994 PPP CHAP August 1996 + + + Name + + The Name field is one or more octets representing the + identification of the system transmitting the packet. There are + no limitations on the content of this field. For example, it MAY + contain ASCII character strings or globally unique identifiers in + ASN.1 syntax. The Name should not be NUL or CR/LF terminated. + The size is determined from the Length field. + + +4.2. Success and Failure + + Description + + If the Value received in a Response is equal to the expected + value, then the implementation MUST transmit a CHAP packet with + the Code field set to 3 (Success). + + If the Value received in a Response is not equal to the expected + value, then the implementation MUST transmit a CHAP packet with + the Code field set to 4 (Failure), and SHOULD take action to + terminate the link. + + A summary of the Success and Failure packet format is shown below. + The fields are transmitted from left to right. + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Message ... + +-+-+-+-+-+-+-+-+-+-+-+-+- + + Code + + 3 for Success; + + 4 for Failure. + + Identifier + + The Identifier field is one octet and aids in matching requests + and replies. The Identifier field MUST be copied from the + Identifier field of the Response which caused this reply. + + + + + + + + +Simpson [Page 9] + +RFC 1994 PPP CHAP August 1996 + + + Message + + The Message field is zero or more octets, and its contents are + implementation dependent. It is intended to be human readable, + and MUST NOT affect operation of the protocol. It is recommended + that the message contain displayable ASCII characters 32 through + 126 decimal. Mechanisms for extension to other character sets are + the topic of future research. The size is determined from the + Length field. + + + +Security Considerations + + Security issues are the primary topic of this RFC. + + The interaction of the authentication protocols within PPP are highly + implementation dependent. This is indicated by the use of SHOULD + throughout the document. + + For example, upon failure of authentication, some implementations do + not terminate the link. Instead, the implementation limits the kind + of traffic in the Network-Layer Protocols to a filtered subset, which + in turn allows the user opportunity to update secrets or send mail to + the network administrator indicating a problem. + + There is no provision for re-tries of failed authentication. + However, the LCP state machine can renegotiate the authentication + protocol at any time, thus allowing a new attempt. It is recommended + that any counters used for authentication failure not be reset until + after successful authentication, or subsequent termination of the + failed link. + + There is no requirement that authentication be full duplex or that + the same protocol be used in both directions. It is perfectly + acceptable for different protocols to be used in each direction. + This will, of course, depend on the specific protocols negotiated. + + The secret SHOULD NOT be the same in both directions. This allows an + attacker to replay the peer's challenge, accept the computed + response, and use that response to authenticate. + + In practice, within or associated with each PPP server, there is a + database which associates "user" names with authentication + information ("secrets"). It is not anticipated that a particular + named user would be authenticated by multiple methods. This would + make the user vulnerable to attacks which negotiate the least secure + method from among a set (such as PAP rather than CHAP). If the same + + + +Simpson [Page 10] + +RFC 1994 PPP CHAP August 1996 + + + secret was used, PAP would reveal the secret to be used later with + CHAP. + + Instead, for each user name there should be an indication of exactly + one method used to authenticate that user name. If a user needs to + make use of different authentication methods under different + circumstances, then distinct user names SHOULD be employed, each of + which identifies exactly one authentication method. + + Passwords and other secrets should be stored at the respective ends + such that access to them is as limited as possible. Ideally, the + secrets should only be accessible to the process requiring access in + order to perform the authentication. + + The secrets should be distributed with a mechanism that limits the + number of entities that handle (and thus gain knowledge of) the + secret. Ideally, no unauthorized person should ever gain knowledge + of the secrets. Such a mechanism is outside the scope of this + specification. + + +Acknowledgements + + David Kaufman, Frank Heinrich, and Karl Auerbach used a challenge + handshake at SDC when designing one of the protocols for a "secure" + network in the mid-1970s. Tom Bearson built a prototype Sytek + product ("Poloneous"?) on the challenge-response notion in the 1982- + 83 timeframe. Another variant is documented in the various IBM SNA + manuals. Yet another variant was implemented by Karl Auerbach in the + Telebit NetBlazer circa 1991. + + Kim Toms and Barney Wolff provided useful critiques of earlier + versions of this document. + + Special thanks to Dave Balenson, Steve Crocker, James Galvin, and + Steve Kent, for their extensive explanations and suggestions. Now, + if only we could get them to agree with each other. + + + + + + + + + + + + + + +Simpson [Page 11] + +RFC 1994 PPP CHAP August 1996 + + +References + + [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD + 51, RFC 1661, DayDreamer, July 1994. + + [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC + 1700, USC/Information Sciences Institute, October 1994. + + [3] Rivest, R., and S. Dusse, "The MD5 Message-Digest Algorithm", + MIT Laboratory for Computer Science and RSA Data Security, + Inc., RFC 1321, April 1992. + + + +Contacts + + Comments should be submitted to the ietf-ppp@merit.edu mailing list. + + This document was reviewed by the Point-to-Point Protocol Working + Group of the Internet Engineering Task Force (IETF). The working + group can be contacted via the current chair: + + Karl Fox + Ascend Communications + 3518 Riverside Drive, Suite 101 + Columbus, Ohio 43221 + + karl@MorningStar.com + karl@Ascend.com + + + Questions about this memo can also be directed to: + + William Allen Simpson + DayDreamer + Computer Systems Consulting Services + 1384 Fontaine + Madison Heights, Michigan 48071 + + wsimpson@UMich.edu + wsimpson@GreenDragon.com (preferred) + + + + + + + + + + +Simpson [Page 12] + + diff --git a/doc/rfc2284.txt b/doc/rfc2284.txt new file mode 100644 index 00000000..99405629 --- /dev/null +++ b/doc/rfc2284.txt @@ -0,0 +1,843 @@ + + + + + + +Network Working Group L. Blunk +Request for Comments: 2284 J. Vollbrecht +Category: Standards Track Merit Network, Inc. + March 1998 + + + + + PPP Extensible Authentication Protocol (EAP) + + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Abstract + + The Point-to-Point Protocol (PPP) [1] provides a standard method for + transporting multi-protocol datagrams over point-to-point links. + + PPP also defines an extensible Link Control Protocol, which allows + negotiation of an Authentication Protocol for authenticating its peer + before allowing Network Layer protocols to transmit over the link. + + This document defines the PPP Extensible Authentication Protocol. + +Table of Contents + + 1. Introduction .......................................... 2 + 1.1 Specification of Requirements ................... 2 + 1.2 Terminology ..................................... 2 + 2. PPP Extensible Authentication Protocol (EAP) .......... 3 + 2.1 Configuration Option Format ..................... 4 + 2.2 Packet Format ................................... 6 + 2.2.1 Request and Response ............................ 6 + 2.2.2 Success and Failure ............................. 7 + 3. Initial EAP Request/Response Types .................... 8 + 3.1 Identity ........................................ 9 + 3.2 Notification .................................... 10 + 3.3 Nak ............................................. 10 + + + +Blunk & Vollbrecht Standards Track [Page 1] + +RFC 2284 EAP March 1998 + + + 3.4 MD5-Challenge ................................... 11 + 3.5 One-Time Password (OTP) ......................... 11 + 3.6 Generic Token Card .............................. 12 + REFERENCES ................................................... 13 + ACKNOWLEDGEMENTS ............................................. 14 + CHAIR'S ADDRESS .............................................. 14 + AUTHORS' ADDRESSES ........................................... 14 + Full Copyright Statement ..................................... 15 + +1. Introduction + + In order to establish communications over a point-to-point link, each + end of the PPP link must first send LCP packets to configure the data + link during Link Establishment phase. After the link has been + established, PPP provides for an optional Authentication phase before + proceeding to the Network-Layer Protocol phase. + + By default, authentication is not mandatory. If authentication of + the link is desired, an implementation MUST specify the + Authentication-Protocol Configuration Option during Link + Establishment phase. + + These authentication protocols are intended for use primarily by + hosts and routers that connect to a PPP network server via switched + circuits or dial-up lines, but might be applied to dedicated links as + well. The server can use the identification of the connecting host + or router in the selection of options for network layer negotiations. + + This document defines the PPP Extensible Authentication Protocol + (EAP). The Link Establishment and Authentication phases, and the + Authentication-Protocol Configuration Option, are defined in The + Point-to-Point Protocol (PPP) [1]. + +1.1. Specification of Requirements + + In this document, several words are used to signify the requirements + of the specification. These words are often capitalized. The key + words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", + "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document + are to be interpreted as described in RFC 2119 [6]. + +1.2. Terminology + + This document frequently uses the following terms: + + + + + + + +Blunk & Vollbrecht Standards Track [Page 2] + +RFC 2284 EAP March 1998 + + + authenticator + The end of the link requiring the authentication. The + authenticator specifies the authentication protocol to be + used in the Configure-Request during Link Establishment + phase. + + peer + The other end of the point-to-point link; the end which is + being authenticated by the authenticator. + + silently discard + This means the implementation discards the packet without + further processing. The implementation SHOULD provide the + capability of logging the error, including the contents of + the silently discarded packet, and SHOULD record the event + in a statistics counter. + + displayable message + This is interpreted to be a human readable string of + characters, and MUST NOT affect operation of the protocol. + The message encoding MUST follow the UTF-8 transformation + format [5]. + +2. PPP Extensible Authentication Protocol (EAP) + + The PPP Extensible Authentication Protocol (EAP) is a general + protocol for PPP authentication which supports multiple + authentication mechanisms. EAP does not select a specific + authentication mechanism at Link Control Phase, but rather postpones + this until the Authentication Phase. This allows the authenticator + to request more information before determining the specific + authentication mechanism. This also permits the use of a "back-end" + server which actually implements the various mechanisms while the PPP + authenticator merely passes through the authentication exchange. + + 1. After the Link Establishment phase is complete, the authenticator + sends one or more Requests to authenticate the peer. The Request + has a type field to indicate what is being requested. Examples of + Request types include Identity, MD5-challenge, One-Time + Passwords, Generic Token Card, etc. The MD5-challenge type + corresponds closely to the CHAP authentication protocol. + Typically, the authenticator will send an initial Identity Request + followed by one or more Requests for authentication information. + However, an initial Identity Request is not required, and MAY be + bypassed in cases where the identity is presumed (leased lines, + dedicated dial-ups, etc.). + + + + + +Blunk & Vollbrecht Standards Track [Page 3] + +RFC 2284 EAP March 1998 + + + 2. The peer sends a Response packet in reply to each Request. As + with the Request packet, the Response packet contains a type field + which corresponds to the type field of the Request. + + 3. The authenticator ends the authentication phase with a Success or + Failure packet. + +Advantages + + The EAP protocol can support multiple authentication mechanisms + without having to pre-negotiate a particular one during LCP Phase. + + Certain devices (e.g. a NAS) do not necessarily have to understand + each request type and may be able to simply act as a passthrough + agent for a "back-end" server on a host. The device only need look + for the success/failure code to terminate the authentication phase. + +Disadvantages + + EAP does require the addition of a new authentication type to LCP and + thus PPP implementations will need to be modified to use it. It also + strays from the previous PPP authentication model of negotiating a + specific authentication mechanism during LCP. + +2.1. Configuration Option Format + + A summary of the Authentication-Protocol Configuration Option format + to negotiate the EAP Authentication Protocol is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Authentication-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Type + + 3 + + Length + + 4 + + Authentication-Protocol + + C227 (Hex) for PPP Extensible Authentication Protocol (EAP) + + + +Blunk & Vollbrecht Standards Track [Page 4] + +RFC 2284 EAP March 1998 + + +2.2. Packet Format + + Exactly one PPP EAP packet is encapsulated in the Information field + of a PPP Data Link Layer frame where the protocol field indicates + type hex C227 (PPP EAP). A summary of the EAP packet format is shown + below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Data ... + +-+-+-+-+ + + + Code + + The Code field is one octet and identifies the type of EAP packet. + EAP Codes are assigned as follows: + + 1 Request + 2 Response + 3 Success + 4 Failure + + Identifier + + The Identifier field is one octet and aids in matching + responses with requests. + + Length + + The Length field is two octets and indicates the length of the + EAP packet including the Code, Identifier, Length and Data + fields. Octets outside the range of the Length field should + be treated as Data Link Layer padding and should be ignored on + reception. + + Data + + The Data field is zero or more octets. The format of the Data + field is determined by the Code field. + + + + + + + + +Blunk & Vollbrecht Standards Track [Page 5] + +RFC 2284 EAP March 1998 + + +2.2.1. Request and Response + + Description + + The Request packet is sent by the authenticator to the peer. Each + Request has a type field which serves to indicate what is being + requested. The authenticator MUST transmit an EAP packet with the + Code field set to 1 (Request). Additional Request packets MUST be + sent until a valid Response packet is received, or an optional + retry counter expires. Retransmitted Requests MUST be sent with + the same Identifier value in order to distinguish them from new + Requests. The contents of the data field is dependent on the + Request type. The peer MUST send a Response packet in reply to a + Request packet. Responses MUST only be sent in reply to a + received Request and never retransmitted on a timer. The + Identifier field of the Response MUST match that of the Request. + + Implementation Note: Because the authentication process will + often involve user input, some care must be taken when deciding + upon retransmission strategies and authentication timeouts. It + is suggested a retransmission timer of 6 seconds with a maximum + of 10 retransmissions be used as default. One may wish to make + these timeouts longer in certain cases (e.g. where Token Cards + are involved). Additionally, the peer must be prepared to + silently discard received retransmissions while waiting for + user input. + + A summary of the Request and Response packet format is shown below. + The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Type-Data ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + + Code + + 1 for Request; + + 2 for Response. + + + + + + + +Blunk & Vollbrecht Standards Track [Page 6] + +RFC 2284 EAP March 1998 + + + Identifier + + The Identifier field is one octet. The Identifier field MUST be + the same if a Request packet is retransmitted due to a timeout + while waiting for a Response. Any new (non-retransmission) + Requests MUST modify the Identifier field. If a peer recieves a + duplicate Request for which it has already sent a Response, it + MUST resend it's Response. If a peer receives a duplicate Request + before it has sent a Response to the initial Request (i.e. it's + waiting for user input), it MUST silently discard the duplicate + Request. + + Length + + The Length field is two octets and indicates the length of the EAP + packet including the Code, Identifier, Length, Type, and Type-Data + fields. Octets outside the range of the Length field should be + treated as Data Link Layer padding and should be ignored on + reception. + + Type + + The Type field is one octet. This field indicates the Type of + Request or Response. Only one Type MUST be specified per EAP + Request or Response. Normally, the Type field of the Response + will be the same as the Type of the Request. However, there is + also a Nak Response Type for indicating that a Request type is + unacceptable to the peer. When sending a Nak in response to a + Request, the peer MAY indicate an alternative desired + authentication Type which it supports. An initial specification of + Types follows in a later section of this document. + + Type-Data + + The Type-Data field varies with the Type of Request and the + associated Response. + +2.2.2. Success and Failure + + Description + + The Success packet is sent by the authenticator to the peer to + acknowledge successful authentication. The authenticator MUST + transmit an EAP packet with the Code field set to 3 (Success). + + If the authenticator cannot authenticate the peer (unacceptable + Responses to one or more Requests) then the implementation MUST + transmit an EAP packet with the Code field set to 4 (Failure). An + + + +Blunk & Vollbrecht Standards Track [Page 7] + +RFC 2284 EAP March 1998 + + + authenticator MAY wish to issue multiple Requests before sending a + Failure response in order to allow for human typing mistakes. + + Implementation Note: Because the Success and Failure packets + are not acknowledged, they may be potentially lost. A peer + MUST allow for this circumstance. The peer can use a Network + Protocol packet as an alternative indication of Success. + Likewise, the receipt of a LCP Terminate-Request can be taken + as a Failure. + + A summary of the Success and Failure packet format is shown below. + The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + Code + + 3 for Success; + + 4 for Failure. + + Identifier + + The Identifier field is one octet and aids in matching replies to + Responses. The Identifier field MUST match the Indentifier field + of the Response packet that it is sent in response to. + + Length + + 4 + +3. Initial EAP Request/Response Types + + This section defines the initial set of EAP Types used in + Request/Response exchanges. More Types may be defined in follow-on + documents. The Type field is one octet and identifies the structure + of an EAP Request or Response packet. The first 3 Types are + considered special case Types. The remaining Types define + authentication exchanges. The Nak Type is valid only for Response + packets, it MUST NOT be sent in a Request. The Nak Type MUST only be + + + + + + +Blunk & Vollbrecht Standards Track [Page 8] + +RFC 2284 EAP March 1998 + + + sent in repsonse to a Request which uses an authentication Type code. + All EAP implementatins MUST support Types 1-4. These Types, as well + as types 5 and 6, are defined in this document. Follow-on RFCs will + define additional EAP Types. + + 1 Identity + 2 Notification + 3 Nak (Response only) + 4 MD5-Challenge + 5 One-Time Password (OTP) (RFC 1938) + 6 Generic Token Card + +3.1. Identity + + Description + + The Identity Type is used to query the identity of the peer. + Generally, the authenticator will issue this as the initial + Request. An optional displayable message MAY be included to + prompt the peer in the case where there expectation of interaction + with a user. A Response MUST be sent to this Request with a Type + of 1 (Identity). + + Implementation Note: The peer MAY obtain the Identity via user + input. It is suggested that the authenticator retry the + Indentity Request in the case of an invalid Identity or + authentication failure to allow for potential typos on the part + of the user. It is suggested that the Identity Request be + retried a minimum of 3 times before terminating the + authentication phase with a Failure reply. The Notification + Request MAY be used to indicate an invalid authentication + attempt prior to transmitting a new Identity Request + (optionally, the failure MAY be indicated within the message of + the new Identity Request itself). + + Type + + 1 + + Type-Data + + This field MAY contain a displayable message in the Request. The + Response uses this field to return the Identity. If the Identity + is unknown, this field should be zero bytes in length. The field + MUST NOT be null terminated. The length of this field is derived + from the Length field of the Request/Response packet and hence a + null is not required. + + + + +Blunk & Vollbrecht Standards Track [Page 9] + +RFC 2284 EAP March 1998 + + +3.2. Notification + + Description + + The Notification Type is optionally used to convey a displayable + message from the authenticator to the peer. The peer SHOULD + display this message to the user or log it if it cannot be + displayed. It is intended to provide an acknowledged notification + of some imperative nature. Examples include a password with an + expiration time that is about to expire, an OTP sequence integer + which is nearing 0, an authentication failure warning, etc. In + most circumstances, notification should not be required. + + Type + + 2 + + Type-Data + + The Type-Data field in the Request contains a displayable message + greater than zero octets in length. The length of the message is + determined by Length field of the Request packet. The message + MUST not be null terminated. A Response MUST be sent in reply to + the Request with a Type field of 2 (Notification). The Type-Data + field of the Response is zero octets in length. The Response + should be sent immediately (independent of how the message is + displayed or logged). + +3.3. Nak + + Description + + The Nak Type is valid only in Response messages. It is sent in + reply to a Request where the desired authentication Type is + unacceptable. Authentication Types are numbered 4 and above. + The Response contains the authentication Type desired by the peer. + + Type + + 3 + + Type-Data + + This field MUST contain a single octet indicating the desired + authentication type. + + + + + + +Blunk & Vollbrecht Standards Track [Page 10] + +RFC 2284 EAP March 1998 + + +3.4. MD5-Challenge + + Description + + The MD5-Challenge Type is analagous to the PPP CHAP protocol [3] + (with MD5 as the specified algorithm). The PPP Challenge + Handshake Authentication Protocol RFC [3] should be referred to + for further implementation specifics. The Request contains a + "challenge" message to the peer. A Repsonse MUST be sent in reply + to the Request. The Response MAY be either of Type 4 (MD5- + Challenge) or Type 3 (Nak). The Nak reply indicates the peer's + desired authentication mechanism Type. All EAP implementations + MUST support the MD5-Challenge mechanism. + + Type + + 4 + + Type-Data + + The contents of the Type-Data field is summarized below. For + reference on the use of this fields see the PPP Challenge + Handshake Authentication Protocol [3]. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value-Size | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Name ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +3.5. One-Time Password (OTP) + + Description + + The One-Time Password system is defined in "A One-Time Password + System" [4]. The Request contains a displayable message + containing an OTP challenge. A Repsonse MUST be sent in reply to + the Request. The Response MUST be of Type 5 (OTP) or Type 3 + (Nak). The Nak reply indicates the peer's desired authentication + mechanism Type. + + Type + + 5 + + + + + +Blunk & Vollbrecht Standards Track [Page 11] + +RFC 2284 EAP March 1998 + + + Type-Data + + The Type-Data field contains the OTP "challenge" as a displayable + message in the Request. In the Response, this field is used for + the 6 words from the OTP dictionary [4]. The messages MUST not be + null terminated. The length of the field is derived from the + Length field of the Request/Reply packet. + +3.6. Generic Token Card + + Description + + The Generic Token Card Type is defined for use with various Token + Card implementations which require user input. The Request + contains an ASCII text message and the Reply contains the Token + Card information necessary for authentication. Typically, this + would be information read by a user from the Token card device and + entered as ASCII text. + + Type + + 6 + + Type-Data + + The Type-Data field in the Request contains a displayable message + greater than zero octets in length. The length of the message is + determined by Length field of the Request packet. The message + MUST not be null terminated. A Response MUST be sent in reply to + the Request with a Type field of 6 (Generic Token Card). The + Response contains data from the Token Card required for + authentication. The length is of the data is determined by the + Length field of the Response packet. + +Security Considerations + + Security issues are the primary topic of this RFC. + + The interaction of the authentication protocols within PPP are highly + implementation dependent. + + For example, upon failure of authentication, some implementations do + not terminate the link. Instead, the implementation limits the kind + of traffic in the Network-Layer Protocols to a filtered subset, which + in turn allows the user opportunity to update secrets or send mail to + the network administrator indicating a problem. + + + + + +Blunk & Vollbrecht Standards Track [Page 12] + +RFC 2284 EAP March 1998 + + + There is no provision for retries of failed authentication. However, + the LCP state machine can renegotiate the authentication protocol at + any time, thus allowing a new attempt. It is recommended that any + counters used for authentication failure not be reset until after + successful authentication, or subsequent termination of the failed + link. + + There is no requirement that authentication be full duplex or that + the same protocol be used in both directions. It is perfectly + acceptable for different protocols to be used in each direction. + This will, of course, depend on the specific protocols negotiated. + + In practice, within or associated with each PPP server, it is not + anticipated that a particular named user would be authenticated by + multiple methods. This would make the user vulnerable to attacks + which negotiate the least secure method from among a set (such as PAP + rather than EAP). Instead, for each named user there should be an + indication of exactly one method used to authenticate that user name. + If a user needs to make use of different authentication methods under + different circumstances, then distinct identities SHOULD be employed, + each of which identifies exactly one authentication method. + +References + + [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, + RFC 1661, July 1994. + + [2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, + RFC 1700, October 1994. + + [3] Simpson, W., "PPP Challenge Handshake Authentication Protocol + (CHAP)", RFC 1994, August 1996. + + [4] Haller, N. and C. Metz, "A One-Time Password System", RFC 1938, + May 1996. + + [5] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO + 10646", RFC 2044, October 1996. + + [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", RFC 2119, March 1997. + + + + + + + + + + +Blunk & Vollbrecht Standards Track [Page 13] + +RFC 2284 EAP March 1998 + + +Acknowledgments + + This protocol derives much of its inspiration from Dave Carrel's AHA + draft as well as the PPP CHAP protocol [3]. Bill Simpson provided + much of the boilerplate used throughout this document. Al Rubens + (Merit) also provided valuable feedback. + +Chair's Address + + The working group can be contacted via the current chair: + + Karl F. Fox + Ascend Communications, Inc. + 655 Metro Place South, Suite 370 + Dublin, Ohio 43017 + + EMail: karl@ascend.com + Phone: +1 614 760 4041 + Fax: +1 614 760 4050 + +Authors' Addresses + + Larry J. Blunk + Merit Network, Inc. + 4251 Plymouth Rd., Suite C + Ann Arbor, MI 48105 + + EMail: ljb@merit.edu + Phone: 734-763-6056 + FAX: 734-647-3185 + + + John R. Vollbrecht + Merit Network, Inc. + 4251 Plymouth Rd., Suite C + Ann Arbor, MI 48105 + + EMail: jrv@merit.edu + Phone: +1-313-763-1206 + FAX: +1-734-647-3185 + + + + + + + + + + + +Blunk & Vollbrecht Standards Track [Page 14] + +RFC 2284 EAP March 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Blunk & Vollbrecht Standards Track [Page 15] + diff --git a/doc/rfc2433.txt b/doc/rfc2433.txt new file mode 100644 index 00000000..3536e72a --- /dev/null +++ b/doc/rfc2433.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group G. Zorn +Request for Comments: 2433 S. Cobb +Category: Informational Microsoft Corporation + October 1998 + + + Microsoft PPP CHAP Extensions + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +IESG Note + + The protocol described here has significant vulnerabilities. People + planning on implementing or using this protocol should read section + 12, "Security Considerations". + +1. Abstract + + The Point-to-Point Protocol (PPP) [1] provides a standard method for + transporting multi-protocol datagrams over point-to-point links. PPP + defines an extensible Link Control Protocol and a family of Network + Control Protocols (NCPs) for establishing and configuring different + network-layer protocols. + + This document describes Microsoft's PPP CHAP dialect (MS-CHAP), which + extends the user authentication functionality provided on Windows + networks to remote workstations. MS-CHAP is closely derived from the + PPP Challenge Handshake Authentication Protocol described in RFC 1994 + [2], which the reader should have at hand. + + The algorithms used in the generation of various MS-CHAP protocol + fields are described in an appendix. + +2. Introduction + + Microsoft created MS-CHAP to authenticate remote Windows + workstations, providing the functionality to which LAN-based users + are accustomed while integrating the encryption and hashing + algorithms used on Windows networks. + + + + +Zorn & Cobb Informational [Page 1] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + Where possible, MS-CHAP is consistent with standard CHAP. Briefly, + the differences between MS-CHAP and standard CHAP are: + + * MS-CHAP is enabled by negotiating CHAP Algorithm 0x80 in LCP + option 3, Authentication Protocol. + + * The MS-CHAP Response packet is in a format designed for + compatibility with Microsoft's Windows NT 3.5, 3.51 and 4.0, and + Windows95 networking products. The MS-CHAP format does not + require the authenticator to store a clear-text or reversibly + encrypted password. + + * MS-CHAP provides authenticator-controlled authentication retry + and password changing mechanisms. + + * MS-CHAP defines a set of reason-for-failure codes returned in + the Failure packet Message field. + +3. Specification of Requirements + + In this document, the key words "MAY", "MUST, "MUST NOT", "optional", + "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as + described in [2]. + +4. LCP Configuration + + The LCP configuration for MS-CHAP is identical to that for standard + CHAP, except that the Algorithm field has value 0x80, rather than the + MD5 value 0x05. PPP implementations which do not support MS-CHAP, + but correctly implement LCP Config-Rej, should have no problem + dealing with this non-standard option. + +5. Challenge Packet + + The MS-CHAP Challenge packet is identical in format to the standard + CHAP Challenge packet. + + MS-CHAP authenticators send an 8-octet challenge Value field. Peers + need not duplicate Microsoft's algorithm for selecting the 8-octet + value, but the standard guidelines on randomness [1,2,7] SHOULD be + observed. + + Microsoft authenticators do not currently provide information in the + Name field. This may change in the future. + + + + + + + +Zorn & Cobb Informational [Page 2] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + +6. Response Packet + + The MS-CHAP Response packet is identical in format to the standard + CHAP Response packet. However, the Value field is sub-formatted + differently as follows: + + 24 octets: LAN Manager compatible challenge response + 24 octets: Windows NT compatible challenge response + 1 octet : "Use Windows NT compatible challenge response" flag + + The LAN Manager compatible challenge response is an encoded function + of the password and the received challenge as output by the routine + LmChallengeResponse() (see section A.1, below). LAN Manager + passwords are limited to 14 case-insensitive OEM characters. Note + that use of the LAN Manager compatible challenge response has been + deprecated; peers SHOULD NOT generate it, and the sub-field SHOULD be + zero-filled. The algorithm used in the generation of the LAN Manager + compatible challenge response is described here for informational + purposes only. + + The Windows NT compatible challenge response is an encoded function + of the password and the received challenge as output by the routine + NTChallengeResponse() (see section A.5, below). The Windows NT + password is a string of 0 to (theoretically) 256 case-sensitive + Unicode [8] characters. Current versions of Windows NT limit + passwords to 14 characters, mainly for compatibility reasons; this + may change in the future. + + The "use Windows NT compatible challenge response" flag, if 1, + indicates that the Windows NT response is provided and should be used + in preference to the LAN Manager response. The LAN Manager response + will still be used if the account does not have a Windows NT password + hash, e.g. if the password has not been changed since the account + was uploaded from a LAN Manager 2.x account database. If the flag is + 0, the Windows NT response is ignored and the LAN Manager response is + used. Since the use of LAN Manager authentication has been + deprecated, this flag SHOULD always be set (1) and the LAN Manager + compatible challenge response field SHOULD be zero-filled. + + The Name field identifies the peer's user account name. The Windows + NT domain name may prefix the user's account name (e.g. + "BIGCO\johndoe" where "BIGCO" is a Windows NT domain containing the + user account "john-doe"). If a domain is not provided, the backslash + should also be omitted, (e.g. "johndoe"). + + + + + + + +Zorn & Cobb Informational [Page 3] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + +7. Success Packet + + The Success packet is identical in format to the standard CHAP + Success packet. + +8. Failure Packet + + The Failure packet is identical in format to the standard CHAP + Failure packet. There is, however, formatted text stored in the + Message field which, contrary to the standard CHAP rules, affects the + protocol. The Message field format is: + + "E=eeeeeeeeee R=r C=cccccccccccccccc V=vvvvvvvvvv" + + where + + The "eeeeeeeeee" is the decimal error code (need not be 10 + digits) corresponding to one of those listed below, though + implementations should deal with codes not on this list + gracefully. + + 646 ERROR_RESTRICTED_LOGON_HOURS + 647 ERROR_ACCT_DISABLED + 648 ERROR_PASSWD_EXPIRED + 649 ERROR_NO_DIALIN_PERMISSION + 691 ERROR_AUTHENTICATION_FAILURE + 709 ERROR_CHANGING_PASSWORD + + The "r" is a flag set to "1" if a retry is allowed, and "0" if + not. When the authenticator sets this flag to "1" it disables + short timeouts, expecting the peer to prompt the user for new + credentials and resubmit the response. + + The "cccccccccccccccc" is 16 hexadecimal digits representing an + ASCII representation of a new challenge value. This field is + optional. If it is not sent, the authenticator expects the + resubmitted response to be calculated based on the previous + challenge value plus decimal 23 in the first octet, i.e. the + one immediately following the Value Size field. Windows 95 + authenticators may send this field. Windows NT authenticators + do not, but may in the future. Both systems implement peer + support of this field. + + The "vvvvvvvvvv" is the decimal version code (need not be 10 + digits) indicating the MS-CHAP protocol version supported on + the server. Currently, this is interesting only in selecting a + Change Password packet type. If the field is not present the + version should be assumed to be 1; since use of the version 1 + + + +Zorn & Cobb Informational [Page 4] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + Change Password packet has been deprecated, this field SHOULD + always contain a value greater than or equal to 2. + + Implementations should accept but ignore additional text they do not + recognize. + +9. Change Password Packet (version 1) + + The version 1 Change Password packet does not appear in standard + CHAP. It allows the peer to change the password on the account + specified in the previous Response packet. The version 1 Change + Password packet should be sent only if the authenticator reports + ERROR_PASSWD_EXPIRED (E=648) and V is either missing or equal to one + in the Message field of the Failure packet. + + The use of the Change Password Packet (version 1) has been + deprecated; the format of the packet is described here for + informational purposes, but peers SHOULD NOT transmit it. + + The format of this packet is as follows: + + 1 octet : Code (=5) + 1 octet : Identifier + 2 octets: Length (=72) + 16 octets: Encrypted LAN Manager Old password Hash + 16 octets: Encrypted LAN Manager New Password Hash + 16 octets: Encrypted Windows NT Old Password Hash + 16 octets: Encrypted Windows NT New Password Hash + 2 octets: Password Length + 2 octets: Flags + + Code + 5 + + Identifier + The Identifier field is one octet and aids in matching requests + and replies. The value is the Identifier of the received + Failure packet to which this packet responds plus 1. + + Length + 72 + + Encrypted LAN Manager New Password Hash + Encrypted LAN Manager Old Password Hash + These fields contain the LAN Manager password hash of the new + and old passwords encrypted with the last received challenge + value, as output by the routine LmEncryptedPasswordHash() (see + section A.8, below). + + + +Zorn & Cobb Informational [Page 5] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + Encrypted Windows NT New Password Hash + Encrypted Windows NT Old Password Hash + These fields contain the Windows NT password hash of the new + and old passwords encrypted with the last received challenge + value, as output by the pseudo-code routine + NtEncryptedPasswordHash() (see section A.10, below). + + Password Length + The length in octets of the LAN Manager compatible form of the + new password. If this value is greater than or equal to zero + and less than or equal to 14 it is assumed that the encrypted + LAN Manager password hash fields are valid. Otherwise, it is + assumed these fields are not valid, in which case the Windows + NT compatible passwords MUST be provided. + + Flags + This field is two octets in length. It is a bit field of + option flags where 0 is the least significant bit of the 16-bit + quantity: + + Bit 0 + If this bit is set (1), it indicates that the encrypted + Windows NT hashed passwords are valid and should be used. + If this bit is cleared (0), the Windows NT fields are not + used and the LAN Manager fields must be provided. + + Bits 1-15 + Reserved, always clear (0). + +10. Change Password Packet (version 2) + + The version 2 Change Password packet does not appear in standard + CHAP. It allows the peer to change the password on the account + specified in the preceding Response packet. The version 2 Change + Password packet should be sent only if the authenticator reports + ERROR_PASSWD_EXPIRED (E=648) and a version of 2 or greater in the + Message field of the Failure packet. + + This packet type is supported by Windows NT 3.51, 4.0 and recent + versions of Windows 95. It is not supported by Windows NT 3.5 or + early versions of Windows 95. + + The format of this packet is as follows: + + 1 octet : Code + 1 octet : Identifier + 2 octets : Length + 516 octets : Password Encrypted with Old NT Hash + + + +Zorn & Cobb Informational [Page 6] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + 16 octets : Old NT Hash Encrypted with New NT Hash + 516 octets : Password Encrypted with Old LM Hash + 16 octets : Old LM Hash Encrypted With New NT Hash + 24 octets : LAN Manager compatible challenge response + 24 octets : Windows NT compatible challenge response + 2-octet : Flags + + Code + 6 + + Identifier + The Identifier field is one octet and aids in matching requests + and replies. The value is the Identifier of the received + Failure packet to which this packet responds plus 1. + + Length + 1118 + + Password Encrypted with Old NT Hash + This field contains the PWBLOCK form of the new Windows NT + password encrypted with the old Windows NT password hash, as + output by the NewPasswordEncryptedWithOldNtPasswordHash() + routine (see section A.11, below). + + Old NT Hash Encrypted with New NT Hash + This field contains the old Windows NT password hash encrypted + with the new Windows NT password hash, as output by the + OldNtPasswordHashEncryptedWithNewNtPasswordHash() routine (see + section A.14, below). + + Password Encrypted with Old LM Hash + This field contains the PWBLOCK form of the new Windows NT + password encrypted with the old LAN Manager password hash, as + output by the NewPasswordEncryptedWithOldLmPasswordHash() + routine described in section A.15, below. Note, however, that + the use of this field has been deprecated: peers SHOULD NOT + generate it, and this field SHOULD be zero-filled. + + Old LM Hash Encrypted With New NT Hash + This field contains the old LAN Manager password hash encrypted + with the new Windows NT password hash, as output by the + OldLmPasswordHashEncryptedWithNewNtPasswordHash() routine (see + section A.16, below). Note, however, that the use of this + field has been deprecated: peers SHOULD NOT generate it, and + this field SHOULD be zero-filled. + + + + + + +Zorn & Cobb Informational [Page 7] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + LAN Manager compatible challenge response + Windows NT compatible challenge response + The challenge response field (as described in the Response + packet description), but calculated on the new password and the + same challenge used in the last response. Note that use of the + LAN Manager compatible challenge response has been deprecated; + peers SHOULD NOT generate it, and the field SHOULD be zero- + filled. + + Flags + This field is two octets in length. It is a bit field of + option flags where 0 is the least significant bit of the 16-bit + quantity. The format of this field is illustrated in the + following diagram: + + 1 + 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Bit 0 + The "use Windows NT compatible challenge response" flag + as described in the Response packet. + + Bit 1 + Set (1) indicates that the "Password Encrypted with Old + LM Hash" and "Old LM Hash Encrypted With New NT Hash" + fields are valid and should be used. Clear (0) indicates + these fields are not valid. This bit SHOULD always be + clear (0). + + Bits 2-15 + Reserved, always clear (0). + +11. Security Considerations + + As an implementation detail, the authenticator SHOULD limit the + number of password retries allowed to make brute-force password + guessing attacks more difficult. + + Because the challenge value is encrypted using the password hash to + form the response and the challenge is transmitted in clear-text + form, both passive known-plaintext and active chosen-plaintext + attacks against the password hash are possible. Suitable precautions + (i.e., frequent password changes) SHOULD be taken in environments + where eavesdropping is likely. + + + + +Zorn & Cobb Informational [Page 8] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + The Change Password (version 1) packet is vulnerable to a passive + eavesdropping attack which can easily reveal the new password hash. + For this reason, it MUST NOT be sent if eavesdropping is possible. + +12. References + + [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC + 1661, July 1994. + + [2] Simpson, W., "PPP Challenge Handshake Authentication Protocol + (CHAP)", RFC 1994, August 1996. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] "Data Encryption Standard (DES)", Federal Information Processing + Standard Publication 46-2, National Institute of Standards and + Technology, December 1993. + + [5] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, April 1992. + + [6] RC4 is a proprietary encryption algorithm available under license + from RSA Data Security Inc. For licensing information, contact: + RSA Data Security, Inc. + 100 Marine Parkway + Redwood City, CA 94065-1031 + + [7] Eastlake, D., Crocker, S., and J. Schiller, "Randomness + Recomnendations for Security", RFC 1750, December 1994. + + [8] "The Unicode Standard, Version 2.0", The Unicode Consortium, + Addison-Wesley, 1996. ISBN 0-201-48345-9. + + [9] "DES Modes of Operation", Federal Information Processing + Standards Publication 81, National Institute of Standards and + Technology, December 1980 + +13. Acknowledgements + + Thanks (in no particular order) to Jeff Haag (Jeff_Haag@3com.com), + Bill Palter (palter@network-alchemy.com), Bruce Johnson + (bjohnson@microsoft.com), Tony Bell (tonybe@microsoft.com), Benoit + Martin (ehlija@vircom.com), and Joe Davies (josephd@microsoft.com) + for useful suggestions and feedback. + + + + + + + +Zorn & Cobb Informational [Page 9] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + +14. Chair's Address + + The PPP Extensions Working Group can be contacted via the current + chair: + + Karl Fox + Ascend Communications + 3518 Riverside Drive + Suite 101 + Columbus, OH 43221 + + Phone: +1 614 326 6841 + EMail: karl@ascend.com + +15. Authors' Addresses + + Questions about this memo can also be directed to: + + Glen Zorn + Microsoft Corporation + One Microsoft Way + Redmond, Washington 98052 + + Phone: +1 425 703 1559 + Fax: +1 425 936 7329 + EMail: glennz@microsoft.com + + + Steve Cobb + Microsoft Corporation + One Microsoft Way + Redmond, Washington 98052 + + EMail: stevec@microsoft.com + + + + + + + + + + + + + + + + + +Zorn & Cobb Informational [Page 10] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + +Appendix A - Pseudocode + + The routines mentioned in the text are described in pseudocode below. + +A.1 LmChallengeResponse() + + LmChallengeResponse( + IN 8-octet Challenge, + IN 0-to-14-oem-char Password, + OUT 24-octet Response ) + { + LmPasswordHash( Password, giving PasswordHash ) + ChallengeResponse( Challenge, PasswordHash, giving Response ) + } + + +A.2 LmPasswordHash() + + LmPasswordHash( + IN 0-to-14-oem-char Password, + OUT 16-octet PasswordHash ) + { + Set UcasePassword to the uppercased Password + Zero pad UcasePassword to 14 characters + + DesHash( 1st 7-octets of UcasePassword, + giving 1st 8-octets of PasswordHash ) + + DesHash( 2nd 7-octets of UcasePassword, + giving 2nd 8-octets of PasswordHash ) + } + + +A.3 DesHash() + + DesHash( + IN 7-octet Clear, + OUT 8-octet Cypher ) + { + /* + * Make Cypher an irreversibly encrypted form of Clear by + * encrypting known text using Clear as the secret key. + * The known text consists of the string + * + * KGS!@#$% + */ + + Set StdText to "KGS!@#$%" + + + +Zorn & Cobb Informational [Page 11] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + DesEncrypt( StdText, Clear, giving Cypher ) + } + + +A.4 DesEncrypt() + + DesEncrypt( + IN 8-octet Clear, + IN 7-octet Key, + OUT 8-octet Cypher ) + { + /* + * Use the DES encryption algorithm [4] in ECB mode [9] + * to encrypt Clear into Cypher such that Cypher can + * only be decrypted back to Clear by providing Key. + * Note that the DES algorithm takes as input a 64-bit + * stream where the 8th, 16th, 24th, etc. bits are + * parity bits ignored by the encrypting algorithm. + * Unless you write your own DES to accept 56-bit input + * without parity, you will need to insert the parity bits + * yourself. + */ + } + + +A.5 NtChallengeResponse() + + NtChallengeResponse( + IN 8-octet Challenge, + IN 0-to-256-unicode-char Password, + OUT 24-octet Response ) + { + NtPasswordHash( Password, giving PasswordHash ) + ChallengeResponse( Challenge, PasswordHash, giving Response ) + } + + +A.6 NtPasswordHash() + + NtPasswordHash( + IN 0-to-256-unicode-char Password, + OUT 16-octet PasswordHash ) + { + /* + * Use the MD4 algorithm [5] to irreversibly hash Password + * into PasswordHash. Only the password is hashed without + * including any terminating 0. + */ + + + +Zorn & Cobb Informational [Page 12] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + } + + +A.7 ChallengeResponse() + + ChallengeResponse( + IN 8-octet Challenge, + IN 16-octet PasswordHash, + OUT 24-octet Response ) + { + Set ZPasswordHash to PasswordHash zero-padded to 21 octets + + DesEncrypt( Challenge, + 1st 7-octets of ZPasswordHash, + giving 1st 8-octets of Response ) + + DesEncrypt( Challenge, + 2nd 7-octets of ZPasswordHash, + giving 2nd 8-octets of Response ) + + DesEncrypt( Challenge, + 3rd 7-octets of ZPasswordHash, + giving 3rd 8-octets of Response ) + } + + +A.8 LmEncryptedPasswordHash() + + LmEncryptedPasswordHash( + IN 0-to-14-oem-char Password, + IN 8-octet KeyValue, + OUT 16-octet Cypher ) + { + LmPasswordHash( Password, giving PasswordHash ) + + PasswordHashEncryptedWithBlock( PasswordHash, + KeyValue, + giving Cypher ) + } + + +A.9 PasswordHashEncryptedWithBlock() + + PasswordHashEncryptedWithBlock( + IN 16-octet PasswordHash, + IN 8-octet Block, + OUT 16-octet Cypher ) + { + + + +Zorn & Cobb Informational [Page 13] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + DesEncrypt( 1st 8-octets PasswordHash, + 1st 7-octets Block, + giving 1st 8-octets Cypher ) + + DesEncrypt( 2nd 8-octets PasswordHash, + 1st 7-octets Block, + giving 2nd 8-octets Cypher ) + } + + +A.10 NtEncryptedPasswordHash() + + NtEncryptedPasswordHash( IN 0-to-14-oem-char Password IN 8-octet + Challenge OUT 16-octet Cypher ) { + NtPasswordHash( Password, giving PasswordHash ) + + PasswordHashEncryptedWithBlock( PasswordHash, + Challenge, + giving Cypher ) + } + + +A.11 NewPasswordEncryptedWithOldNtPasswordHash() + + datatype-PWBLOCK + { + 256-unicode-char Password + 4-octets PasswordLength + } + + NewPasswordEncryptedWithOldNtPasswordHash( + IN 0-to-256-unicode-char NewPassword, + IN 0-to-256-unicode-char OldPassword, + OUT datatype-PWBLOCK EncryptedPwBlock ) + { + NtPasswordHash( OldPassword, giving PasswordHash ) + + EncryptPwBlockWithPasswordHash( NewPassword, + PasswordHash, + giving EncryptedPwBlock ) + } + + +A.12 EncryptPwBlockWithPasswordHash() + + EncryptPwBlockWithPasswordHash( + IN 0-to-256-unicode-char Password, + IN 16-octet PasswordHash, + + + +Zorn & Cobb Informational [Page 14] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + OUT datatype-PWBLOCK PwBlock ) + { + + Fill ClearPwBlock with random octet values + PwSize = lstrlenW( Password ) * sizeof( unicode-char ) + PwOffset = sizeof( ClearPwBlock.Password ) - PwSize + Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from Password + ClearPwBlock.PasswordLength = PwSize + Rc4Encrypt( ClearPwBlock, + sizeof( ClearPwBlock ), + PasswordHash, + sizeof( PasswordHash ), + giving PwBlock ) + } + + +A.13 Rc4Encrypt() + + Rc4Encrypt( + IN x-octet Clear, + IN integer ClearLength, + IN y-octet Key, + IN integer KeyLength, + OUT x-octet Cypher ) + { + /* + * Use the RC4 encryption algorithm [6] to encrypt Clear of + * length ClearLength octets into a Cypher of the same length + * such that the Cypher can only be decrypted back to Clear + * by providing a Key of length KeyLength octets. + */ + } + + +A.14 OldNtPasswordHashEncryptedWithNewNtPasswordHash() + + OldNtPasswordHashEncryptedWithNewNtPasswordHash( + IN 0-to-256-unicode-char NewPassword, + IN 0-to-256-unicode-char OldPassword, + OUT 16-octet EncryptedPasswordHash ) + { + NtPasswordHash( OldPassword, giving OldPasswordHash ) + NtPasswordHash( NewPassword, giving NewPasswordHash ) + NtPasswordHashEncryptedWithBlock( OldPasswordHash, + NewPasswordHash, + giving EncryptedPasswordHash ) + } + + + + +Zorn & Cobb Informational [Page 15] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + +A.15 NewPasswordEncryptedWithOldLmPasswordHash() + + NewPasswordEncryptedWithOldLmPasswordHash( + IN 0-to-256-unicode-char NewPassword, + IN 0-to-256-unicode-char OldPassword, + OUT datatype-PWBLOCK EncryptedPwBlock ) + { + LmPasswordHash( OldPassword, giving PasswordHash ) + + EncryptPwBlockWithPasswordHash( NewPassword, PasswordHash, + giving EncryptedPwBlock ) + } + + +A.16 OldLmPasswordHashEncryptedWithNewNtPasswordHash() + + OldLmPasswordHashEncryptedWithNewNtPasswordHash( + IN 0-to-256-unicode-char NewPassword, + IN 0-to-256-unicode-char OldPassword, + OUT 16-octet EncryptedPasswordHash ) + { + LmPasswordHash( OldPassword, giving OldPasswordHash ) + + NtPasswordHash( NewPassword, giving NewPasswordHash ) + + NtPasswordHashEncryptedWithBlock( OldPasswordHash, NewPasswordHash, + giving EncrytptedPasswordHash ) + } + + +A.17 NtPasswordHashEncryptedWithBlock() + + NtPasswordHashEncryptedWithBlock( + IN 16-octet PasswordHash, + IN 16-octet Block, + OUT 16-octet Cypher ) + { + DesEncrypt( 1st 8-octets PasswordHash, + 1st 7-octets Block, + giving 1st 8-octets Cypher ) + + DesEncrypt( 2nd 8-octets PasswordHash, + 2nd 7-octets Block, + giving 2nd 8-octets Cypher ) + } + + + + + + +Zorn & Cobb Informational [Page 16] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + +Appendix B - Examples + +B.1 Negotiation Examples + + Here are some examples of typical negotiations. The peer is on the + left and the authenticator is on the right. + + The packet sequence ID is incremented on each authentication retry + Response and on the change password response. All cases where the + packet sequence ID is updated are noted below. + + Response retry is never allowed after Change Password. Change + Password may occur after Response retry. The implied challenge form + is shown in the examples, though all cases of "first challenge+23" + should be replaced by the "C=cccccccccccccccc" challenge if + authenticator supplies it in the Failure packet. + +B.1.1 Successful authentication + + <- Challenge + Response -> + <- Success + + +B.1.2 Failed authentication with no retry allowed + + <- Challenge + Response -> + <- Failure (E=691 R=0) + + +B.1.3 Successful authentication after retry + + <- Challenge + Response -> + <- Failure (E=691 R=1), disable short timeout + Response (++ID) to first challenge+23 -> + <- Success + + +B.1.4 Failed hack attack with 3 attempts allowed + + <- Challenge + Response -> + <- Failure (E=691 R=1), disable short timeout + Response (++ID) to first challenge+23 -> + <- Failure (E=691 R=1), disable short timeout + Response (++ID) to first challenge+23+23 -> + + + +Zorn & Cobb Informational [Page 17] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + + <- Failure (E=691 R=0) + + +B.1.5 Successful authentication with password change + + <- Challenge + Response -> + <- Failure (E=648 R=0 V=2), disable short timeout + ChangePassword (++ID) to first challenge -> + <- Success + + +B.1.6 Successful authentication with retry and password change + + <- Challenge + Response -> + <- Failure (E=691 R=1), disable short timeout + Response (++ID) to first challenge+23 -> + <- Failure (E=648 R=0 V=2), disable short timeout + ChangePassword (++ID) to first challenge+23 -> + <- Success + +B.2 Hash Example + +Intermediate values for password "MyPw". + + 8-octet Challenge: + 10 2D B5 DF 08 5D 30 41 + + 0-to-256-unicode-char NtPassword: + 4D 00 79 00 50 00 77 00 + + 16-octet NtPasswordHash: + FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC + + 24-octet NtChallengeResponse: + 4E 9D 3C 8F 9C FD 38 5D 5B F4 D3 24 67 91 95 6C + A4 C3 51 AB 40 9A 3D 61 + +B.3 Example of DES Key Generation + +DES uses 56-bit keys, expanded to 64 bits by the insertion of parity +bits. After the parity of the key has been fixed, every eighth bit is a +parity bit and the number of bits that are set (1) in each octet is odd; +i.e., odd parity. Note that many DES engines do not check parity, +however, simply stripping the parity bits. The following example +illustrates the values resulting from the use of the 16-octet +NTPasswordHash shown in Appendix B.2 to generate a pair of DES keys + + + +Zorn & Cobb Informational [Page 18] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + +(e.g., for use in the NtPasswordHashEncryptedWithBlock() described in +Appendix A.17). + + 16-octet NtPasswordHash: + FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC + + First "raw" DES key (initial 7 octets of password hash): + FC 15 6A F7 ED CD 6C + + First parity-corrected DES key (eight octets): + FD 0B 5B 5E 7F 6E 34 D9 + + Second "raw" DES key (second 7 octets of password hash) + 0E DD E3 33 7D 42 7F + + Second parity-corrected DES key (eight octets): + 0E 6E 79 67 37 EA 08 FE + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zorn & Cobb Informational [Page 19] + +RFC 2433 Microsoft PPP CHAP Extensions Ocotober 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Zorn & Cobb Informational [Page 20] + diff --git a/doc/rfc2637.txt b/doc/rfc2637.txt new file mode 100644 index 00000000..56e9e0f5 --- /dev/null +++ b/doc/rfc2637.txt @@ -0,0 +1,3195 @@ + + + + + + +Network Working Group K. Hamzeh +Request for Comments: 2637 Ascend Communications +Category: Informational G. Pall + Microsoft Corporation + W. Verthein + 3Com + J. Taarud + Copper Mountain Networks + W. Little + ECI Telematics + G. Zorn + Microsoft Corporation + July 1999 + + + Point-to-Point Tunneling Protocol (PPTP) + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +IESG Note + + The PPTP protocol was developed by a vendor consortium. The + documentation of PPTP is provided as information to the Internet + community. The PPP WG is currently defining a Standards Track + protocol (L2TP) for tunneling PPP across packet-switched networks. + +Abstract + + This document specifies a protocol which allows the Point to Point + Protocol (PPP) to be tunneled through an IP network. PPTP does not + specify any changes to the PPP protocol but rather describes a new + vehicle for carrying PPP. A client-server architecture is defined in + order to decouple functions which exist in current Network Access + Servers (NAS) and support Virtual Private Networks (VPNs). The PPTP + Network Server (PNS) is envisioned to run on a general purpose + operating system while the client, referred to as a PPTP Access + Concentrator (PAC) operates on a dial access platform. PPTP + specifies a call-control and management protocol which allows the + server to control access for dial-in circuit switched calls + originating from a PSTN or ISDN or to initiate outbound circuit- + + + +Hamzeh, et al. Informational [Page 1] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + switched connections. PPTP uses an enhanced GRE (Generic Routing + Encapsulation) mechanism to provide a flow- and congestion-controlled + encapsulated datagram service for carrying PPP packets. + +Specification of Requirements + + In this document, the key words "MAY", "MUST, "MUST NOT", "optional", + "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as + described in [12]. + + The words "silently discard", when used in reference to the behavior + of an implementation upon receipt of an incoming packet, are to be + interpreted as follows: the implementation discards the datagram + without further processing, and without indicating an error to the + sender. The implementation SHOULD provide the capability of logging + the error, including the contents of the discarded datagram, and + SHOULD record the event in a statistics counter. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Protocol Goals and Assumptions . . . . . . . . . . . . . . 4 + 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 + 1.3. Protocol Overview . . . . . . . . . . . . . . . . . . . . 6 + 1.3.1. Control Connection Overview . . . . . . . . . . . . . . 7 + 1.3.2. Tunnel Protocol Overview . . . . . . . . . . . . . . . . 7 + 1.4. Message Format and Protocol Extensibility . . . . . . . . 8 + 2. Control Connection Protocol Specification . . . . . . . . . 10 + 2.1. Start-Control-Connection-Request . . . . . . . . . . . . . 10 + 2.2. Start-Control-Connection-Reply . . . . . . . . . . . . . . 12 + 2.3. Stop-Control-Connection-Request . . . . . . . . . . . . . 15 + 2.4. Stop-Control-Connection-Reply . . . . . . . . . . . . . . 16 + 2.5. Echo-Request . . . . . . . . . . . . . . . . . . . . . . . 17 + 2.6. Echo-Reply . . . . . . . . . . . . . . . . . . . . . . . . 18 + 2.7. Outgoing-Call-Request . . . . . . . . . . . . . . . . . . 19 + 2.8. Outgoing-Call-Reply . . . . . . . . . . . . . . . . . . . 22 + 2.9. Incoming-Call-Request . . . . . . . . . . . . . . . . . . 25 + 2.10. Incoming-Call-Reply . . . . . . . . . . . . . . . . . . . 28 + 2.11. Incoming-Call-Connected . . . . . . . . . . . . . . . . . 29 + 2.12. Call-Clear-Request . . . . . . . . . . . . . . . . . . . 31 + 2.13. Call-Disconnect-Notify . . . . . . . . . . . . . . . . . 32 + 2.14. WAN-Error-Notify . . . . . . . . . . . . . . . . . . . . 33 + 2.15. Set-Link-Info . . . . . . . . . . . . . . . . . . . . . . 35 + 2.16. General Error Codes . . . . . . . . . . . . . . . . . . . 36 + 3. Control Connection Protocol Operation . . . . . . . . . . . 36 + 3.1. Control Connection States . . . . . . . . . . . . . . . . 37 + 3.1.1. Control Connection Originator (may be PAC or PNS) . . . 37 + 3.1.2. Control connection Receiver (may be PAC or PNS) . . . . 39 + + + +Hamzeh, et al. Informational [Page 2] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 3.1.3. Start Control Connection Initiation Request Collision . 40 + 3.1.4. Keep Alives and Timers . . . . . . . . . . . . . . . . . 40 + 3.2. Call States . . . . . . . . . . . . . . . . . . . . . . . 41 + 3.2.1. Timing considerations . . . . . . . . . . . . . . . . . 41 + 3.2.2. Call ID Values . . . . . . . . . . . . . . . . . . . . . 41 + 3.2.3. Incoming Calls . . . . . . . . . . . . . . . . . . . . . 41 + 3.2.3.1. PAC Incoming Call States . . . . . . . . . . . . . . . 42 + 3.2.3.2. PNS Incoming Call States . . . . . . . . . . . . . . . 43 + 3.2.4. Outgoing Calls . . . . . . . . . . . . . . . . . . . . . 44 + 3.2.4.1. PAC Outgoing Call States . . . . . . . . . . . . . . . 45 + 3.2.4.2. PNS Outgoing Call States . . . . . . . . . . . . . . . 46 + 4. Tunnel Protocol Operation . . . . . . . . . . . . . . . . . 47 + 4.1. Enhanced GRE header . . . . . . . . . . . . . . . . . . . 47 + 4.2. Sliding Window Protocol . . . . . . . . . . . . . . . . . 49 + 4.2.1. Initial Window Size . . . . . . . . . . . . . . . . . . 49 + 4.2.2. Closing the Window . . . . . . . . . . . . . . . . . . . 49 + 4.2.3. Opening the Window . . . . . . . . . . . . . . . . . . . 50 + 4.2.4. Window Overflow . . . . . . . . . . . . . . . . . . . . 50 + 4.2.5. Multi-packet Acknowledgment . . . . . . . . . . . . . . 50 + 4.3. Out-of-sequence Packets . . . . . . . . . . . . . . . . . 50 + 4.4. Acknowledgment Time-Outs . . . . . . . . . . . . . . . . . 51 + 4.4.1. Calculating Adaptive Acknowledgment Time-Out . . . . . . 53 + 4.4.2. Congestion Control: Adjusting for Time-Out . . . . . . . 54 + 5. Security Considerations . . . . . . . . . . . . . . . . . . 54 + 6. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 56 + 8. Full Copyright Statement . . . . . . . . . . . . . . . . . . 57 + +1. Introduction + + PPTP allows existing Network Access Server (NAS) functions to be + separated using a client-server architecture. Traditionally, the + following functions are implemented by a NAS: + + 1) Physical native interfacing to PSTN or ISDN and control of + external modems or terminal adapters. + + A NAS may interface directly to a telco analog or digital + circuit or attach via an external modem or terminal adapter. + Control of a circuit-switched connection is accomplished with + either modem control or DSS1 ISDN call control protocols. + + The NAS, in conjunction with the modem or terminal adapters, + may perform rate adaption, analog to digital conversion, sync + to async conversion or a number of other alterations of data + streams. + + + + + +Hamzeh, et al. Informational [Page 3] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 2) Logical termination of a Point-to-Point-Protocol (PPP) Link + Control Protocol (LCP) session. + + 3) Participation in PPP authentication protocols [3,9,10]. + + 4) Channel aggregation and bundle management for PPP Multilink + Protocol. + + 5) Logical termination of various PPP network control protocols + (NCP). + + 6) Multiprotocol routing and bridging between NAS interfaces. + + PPTP divides these functions between the PAC and PNS. The PAC is + responsible for functions 1, 2, and possibly 3. The PNS may be + responsible for function 3 and is responsible for functions 4, 5, and + 6. The protocol used to carry PPP protocol data units (PDUs) between + the PAC and PNS, as well as call control and management is addressed + by PPTP. + + The decoupling of NAS functions offers these benefits: + + Flexible IP address management. Dial-in users may maintain a + single IP address as they dial into different PACs as long as they + are served from a common PNS. If an enterprise network uses + unregistered addresses, a PNS associated with the enterprise + assigns addresses meaningful to the private network. + + Support of non-IP protocols for dial networks behind IP networks. + This allows Appletalk and IPX, for example to be tunneled through + an IP-only provider. The PAC need not be capable of processing + these protocols. + + A solution to the "multilink hunt-group splitting" problem. + Multilink PPP, typically used to aggregate ISDN B channels, + requires that all of the channels composing a multilink bundle be + grouped at a single NAS. Since a multilink PPP bundle can be + handled by a single PNS, the channels comprising the bundle may be + spread across multiple PACs. + +1.1. Protocol Goals and Assumptions + + The PPTP protocol is implemented only by the PAC and PNS. No other + systems need to be aware of PPTP. Dial networks may be connected to a + PAC without being aware of PPTP. Standard PPP client software should + continue to operate on tunneled PPP links. + + + + + +Hamzeh, et al. Informational [Page 4] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + PPTP can also be used to tunnel a PPP session over an IP network. In + this configuration the PPTP tunnel and the PPP session runs between + the same two machines with the caller acting as a PNS. + + It is envisioned that there will be a many-to-many relationship + between PACs and PNSs. A PAC may provide service to many PNSs. For + example, an Internet service provider may choose to support PPTP for + a number of private network clients and create VPNs for them. Each + private network may operate one or more PNSs. A single PNS may + associate with many PACs to concentrate traffic from a large number + of geographically diverse sites. + + PPTP uses an extended version of GRE to carry user PPP packets. These + enhancements allow for low-level congestion and flow control to be + provided on the tunnels used to carry user data between PAC and PNS. + This mechanism allows for efficient use of the bandwidth available + for the tunnels and avoids unnecessary retransmisions and buffer + overruns. PPTP does not dictate the particular algorithms to be used + for this low level control but it does define the parameters that + must be communicated in order to allow such algorithms to work. + Suggested algorithms are included in section 4. + +1.2. Terminology + + Analog Channel + + A circuit-switched communication path which is intended to carry + 3.1 Khz audio in each direction. + + Digital Channel + + A circuit-switched communication path which is intended to carry + digital information in each direction. + + Call + + A connection or attempted connection between two terminal + endpoints on a PSTN or ISDN -- for example, a telephone call + between two modems. + + Control Connection + + A control connection is created for each PAC, PNS pair and + operates over TCP [4]. The control connection governs aspects of + the tunnel and of sessions assigned to the tunnel. + + + + + + +Hamzeh, et al. Informational [Page 5] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Dial User + + An end-system or router attached to an on-demand PSTN or ISDN + which is either the initiator or recipient of a call. + + Network Access Server (NAS) + + A device providing temporary, on-demand network access to users. + This access is point-to-point using PSTN or ISDN lines. + + PPTP Access Concentrator (PAC) + + A device attached to one or more PSTN or ISDN lines capable of PPP + operation and of handling the PPTP protocol. The PAC need only + implement TCP/IP to pass traffic to one or more PNSs. It may also + tunnel non-IP protocols. + + PPTP Network Server (PNS) + + A PNS is envisioned to operate on general-purpose computing/server + platforms. The PNS handles the server side of the PPTP protocol. + Since PPTP relies completely on TCP/IP and is independent of the + interface hardware, the PNS may use any combination of IP + interface hardware including LAN and WAN devices. + + Session + + PPTP is connection-oriented. The PNS and PAC maintain state for + each user that is attached to a PAC. A session is created when + end-to-end PPP connection is attempted between a dial user and the + PNS. The datagrams related to a session are sent over the tunnel + between the PAC and PNS. + + Tunnel + + A tunnel is defined by a PNS-PAC pair. The tunnel protocol is + defined by a modified version of GRE [1,2]. The tunnel carries + PPP datagrams between the PAC and the PNS. Many sessions are + multiplexed on a single tunnel. A control connection operating + over TCP controls the establishment, release, and maintenance of + sessions and of the tunnel itself. + +1.3. Protocol Overview + + There are two parallel components of PPTP: 1) a Control Connection + between each PAC-PNS pair operating over TCP and 2) an IP tunnel + operating between the same PAC-PNS pair which is used to transport + GRE encapsulated PPP packets for user sessions between the pair. + + + +Hamzeh, et al. Informational [Page 6] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +1.3.1. Control Connection Overview + + Before PPP tunneling can occur between a PAC and PNS, a control + connection must be established between them. The control connection + is a standard TCP session over which PPTP call control and management + information is passed. The control session is logically associated + with, but separate from, the sessions being tunneled through a PPTP + tunnel. For each PAC-PNS pair both a tunnel and a control connection + exist. The control connection is responsible for establishment, + management, and release of sessions carried through the tunnel. It is + the means by which a PNS is notified of an incoming call at an + associated PAC, as well as the means by which a PAC is instructed to + place an outgoing dial call. + + A control connection can be established by either the PNS or the PAC. + Following the establishment of the required TCP connection, the PNS + and PAC establish the control connection using the Start-Control- + Connection-Request and -Reply messages. These messages are also used + to exchange information about basic operating capabilities of the PAC + and PNS. Once the control connection is established, the PAC or PNS + may initiate sessions by requesting outbound calls or responding to + inbound requests. The control connection may communicate changes in + operating characteristics of an individual user session with a Set- + Link-Info message. Individual sessions may be released by either the + PAC or PNS, also through Control Connection messages. + + The control connection itself is maintained by keep-alive echo + messages. This ensures that a connectivity failure between the PNS + and the PAC can be detected in a timely manner. Other failures can be + reported via the + + Wan-Error-Notify message, also on the control connection. + + It is intended that the control connection will also carry management + related messages in the future, such as a message allowing the PNS to + request the status of a given PAC; these message types have not yet + been defined. + +1.3.2. Tunnel Protocol Overview + + PPTP requires the establishment of a tunnel for each communicating + PNS-PAC pair. This tunnel is used to carry all user session PPP + packets for sessions involving a given PNS-PAC pair. A key which is + present in the GRE header indicates which session a particular PPP + packet belongs to. + + + + + + +Hamzeh, et al. Informational [Page 7] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + In this manner, PPP packets are multiplexed and demultiplexed over a + single tunnel between a given PNS-PAC pair. The value to use in the + key field is established by the call establishment procedure which + takes place on the control connection. + + The GRE header also contains acknowledgment and sequencing + information that is used to perform some level of congestion-control + and error detection over the tunnel. Again the control connection is + used to determine rate and buffering parameters that are used to + regulate the flow of PPP packets for a particular session over the + tunnel. PPTP does not specify the particular algorithms to use for + congestion-control and flow-control. Suggested algorithms for the + determination of adaptive time-outs to recover from dropped data or + acknowledgments on the tunnel are included in section 4.4 of this + document. + +1.4. Message Format and Protocol Extensibility + + PPTP defines a set of messages sent as TCP data on the control + connection between a PNS and a given PAC. The TCP session for the + control connection is established by initiating a TCP connection to + port 1723 [6]. The source port is assigned to any unused port number. + + Each PPTP Control Connection message begins with an 8 octet fixed + header portion. This fixed header contains the following: the total + length of the message, the PPTP Message Type indicator, and a "Magic + Cookie". + + Two Control Connection message types are indicated by the PPTP + Message Type field: + + 1 - Control Message + 2 - Management Message + + Management messages are currently not defined. + + The Magic Cookie is always sent as the constant 0x1A2B3C4D. Its + basic purpose is to allow the receiver to ensure that it is properly + synchronized with the TCP data stream. It should not be used as a + means for resynchronizing the TCP data stream in the event that a + transmitter issues an improperly formatted message. Loss of + synchronization must result in immediate closing of the control + connection's TCP session. + + For clarity, all Control Connection message templates in the next + section include the entire PPTP Control Connection message header. + Numbers preceded by 0x are hexadecimal values. + + + + +Hamzeh, et al. Informational [Page 8] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +The currently defined Control Messages, grouped by function, are: + + Control Message Message Code + + (Control Connection Management) + + Start-Control-Connection-Request 1 + Start-Control-Connection-Reply 2 + Stop-Control-Connection-Request 3 + Stop-Control-Connection-Reply 4 + Echo-Request 5 + Echo-Reply 6 + + (Call Management) + + Outgoing-Call-Request 7 + Outgoing-Call-Reply 8 + Incoming-Call-Request 9 + Incoming-Call-Reply 10 + Incoming-Call-Connected 11 + Call-Clear-Request 12 + Call-Disconnect-Notify 13 + + (Error Reporting) + + WAN-Error-Notify 14 + + (PPP Session Control) + + Set-Link-Info 15 + + The Start-Control-Connection-Request and -Reply messages determine + which version of the Control Connection protocol will be used. The + version number field carried in these messages consists of a version + number in the high octet and a revision number in the low octet. + Version handling is described in section 2. The current value of the + version number field is 0x0100 for version 1, revision 0. + + The use of the GRE-like header for the encapsulation of PPP user + packets is specified in section 4.1. + + The MTU for the user data packets encapsulated in GRE is 1532 octets, + not including the IP and GRE headers. + + + + + + + + +Hamzeh, et al. Informational [Page 9] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +2. Control Connection Protocol Specification + + Control Connection messages are used to establish and clear user + sessions. The first set of Control Connection messages are used to + maintain the control connection itself. The control connection is + initiated by either the PNS or PAC after they establish the + underlying TCP connection. The procedure and configuration + information required to determine which TCP connections are + established is not covered by this protocol. + + The following Control Connection messages are all sent as user data + on the established TCP connection between a given PNS-PAC pair. Note + that care has been taken to ensure that all word (2 octet) and + longword (4 octet) values begin on appropriate boundaries. All data + is sent in network order (high order octets first). Any "reserved" + fields MUST be sent as 0 values to allow for protocol extensibility. + +2.1. Start-Control-Connection-Request + + The Start-Control-Connection-Request is a PPTP control message used + to establish the control connection between a PNS and a PAC. Each + PNS-PAC pair requires a dedicated control connection to be + established. A control connection must be established before any + other PPTP messages can be issued. The establishment of the control + connection can be initiated by either the PNS or PAC. A procedure + which handles the occurrence of a collision between PNS and PAC + Start-Control-Connection-Requests is described in section 3.1.3. + + + + + + + + + + + + + + + + + + + + + + + + +Hamzeh, et al. Informational [Page 10] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Protocol Version | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Framing Capabilities | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Bearer Capabilities | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Maximum Channels | Firmware Revision | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Host Name (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Vendor String (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP + message, including the entire PPTP + header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. This constant value is used + as a sanity check on received messages + (see section 1.4). + + Control Message Type 1 for Start-Control-Connection-Request. + + Reserved0 This field MUST be 0. + + Protocol Version The version of the PPTP protocol that the + sender wishes to use. + + Reserved1 This field MUST be 0. + + + + + + + +Hamzeh, et al. Informational [Page 11] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Framing Capabilities A set of bits indicating the type of framing + that the sender of this message can provide. + The currently defined bit settings are: + + 1 - Asynchronous Framing supported + + 2 - Synchronous Framing supported + + Bearer Capabilities A set of bits indicating the bearer + capabilities that the sender of this message + can provide. The currently defined bit + settings are: + + 1 - Analog access supported + + 2 - Digital access supported + + Maximum Channels The total number of individual PPP sessions + this PAC can support. In Start-Control- + Connection-Requests issued by the PNS, this + value SHOULD be set to 0. It MUST be + ignored by the PAC. + + Firmware Revision This field contains the firmware revision + number of the issuing PAC, when issued by + the PAC, or the version of the PNS PPTP + driver if issued by the PNS. + + Host Name A 64 octet field containing the DNS name of + the issuing PAC or PNS. If less than 64 + octets in length, the remainder of this + field SHOULD be filled with octets of value + 0. + + Vendor Name A 64 octet field containing a vendor + specific string describing the type of PAC + being used, or the type of PNS software + being used if this request is issued by the + PNS. If less than 64 octets in length, the + remainder of this field SHOULD be filled + with octets of value 0. + +2.2. Start-Control-Connection-Reply + + The Start-Control-Connection-Reply is a PPTP control message sent in + reply to a received Start-Control-Connection-Request message. This + message contains a result code indicating the result of the control + connection establishment attempt. + + + +Hamzeh, et al. Informational [Page 12] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Protocol Version | Result Code | Error Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Framing Capability | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Bearer Capability | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Maximum Channels | Firmware Revision | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Host Name (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Vendor String (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 2 for Start-Control-Connection-Reply. + + Reserved0 This field MUST be 0. + + Protocol Version The version of the PPTP protocol that the + sender wishes to use. + + Result Code Indicates the result of the command channel + establishment attempt. Current valid Result + Code values are: + + 1 - Successful channel establishment + + 2 - General error -- Error Code + indicates the problem + + + +Hamzeh, et al. Informational [Page 13] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 3 - Command channel already exists; + + 4 - Requester is not authorized to + establish a command channel + + 5 - The protocol version of the + requester is not supported + + Error Code This field is set to 0 unless a "General + Error" exists, in which case Result Code is + set to 2 and this field is set to the value + corresponding to the general error condition + as specified in section 2.2. + + Framing Capabilities A set of bits indicating the type of framing + that the sender of this message can provide. + The currently defined bit settings are: + + 1 - Asynchronous Framing supported + + 2 - Synchronous Framing supported. + + Bearer Capabilities A set of bits indicating the bearer + capabilities that the sender of this message + can provide. The currently defined bit + settings are: + + 1 - Analog access supported + + 2 - Digital access supported + + Maximum Channels The total number of individual PPP sessions + this PAC can support. In a Start-Control- + Connection-Reply issued by the PNS, this + value SHOULD be set to 0 and it must be + ignored by the PAC. The PNS MUST NOT use + this value to try to track the remaining + number of PPP sessions that the PAC will + allow. + + Firmware Revision This field contains the firmware revision + number of the issuing PAC, or the version of + the PNS PPTP driver if issued by the PNS. + + + + + + + + +Hamzeh, et al. Informational [Page 14] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Host Name A 64 octet field containing the DNS name of + the issuing PAC or PNS. If less than 64 + octets in length, the remainder of this + field SHOULD be filled with octets of value + 0. + + Vendor Name A 64 octet field containing a vendor + specific string describing the type of PAC + being used, or the type of PNS software + being used if this request is issued by the + PNS. If less than 64 octets in length, the + remainder of this field SHOULD be filled + with octets of value 0. + +2.3. Stop-Control-Connection-Request + + The Stop-Control-Connection-Request is a PPTP control message sent by + one peer of a PAC-PNS control connection to inform the other peer + that the control connection should be closed. In addition to closing + the control connection, all active user calls are implicitly cleared. + The reason for issuing this request is indicated in the Reason field. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reason | Reserved1 | Reserved2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 3 for Stop-Control-Connection-Request. + + Reserved0 This field MUST be 0. + + Reason Indicates the reason for the control + connection being closed. Current valid + Reason values are: + + + +Hamzeh, et al. Informational [Page 15] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 1 (None) - General request to clear + control connection + + 2 (Stop-Protocol) - Can't support + peer's version of the protocol + + 3 (Stop-Local-Shutdown) - Requester is + being shut down + + Reserved1, Reserved2 These fields MUST be 0. + +2.4. Stop-Control-Connection-Reply + + The Stop-Control-Connection-Reply is a PPTP control message sent by + one peer of a PAC-PNS control connection upon receipt of a Stop- + Control-Connection-Request from the other peer. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Result Code | Error Code | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 4 for Stop-Control-Connection-Reply. + + Reserved0 This field MUST be 0. + + Result Code Indicates the result of the attempt to close + the control connection. Current valid Result + Code values are: + + + + + + + + +Hamzeh, et al. Informational [Page 16] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 1 (OK) - Control connection closed + + 2 (General Error) - Control connection + not closed for reason indicated in + Error Code + + Error Code This field is set to 0 unless a "General + Error" exists, in which case Result Code is + set to 2 and this field is set to the value + corresponding to the general error condition + as specified in section 2.2. + + Reserved1 This field MUST be 0. + +2.5. Echo-Request + + The Echo-Request is a PPTP control message sent by either peer of a + PAC-PNS control connection. This control message is used as a "keep- + alive" for the control connection. The receiving peer issues an + Echo-Reply to each Echo-Request received. As specified in section + 3.1.4, if the sender does not receive an Echo-Reply in response to an + Echo-Request, it will eventually clear the control connection. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 5 for Echo-Request. + + Reserved0 This field MUST be 0. + + + + + + +Hamzeh, et al. Informational [Page 17] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Identifier A value set by the sender of the Echo- + Request that is used to match the reply with + the corresponding request. + +2.6. Echo-Reply + + The Echo-Reply is a PPTP control message sent by either peer of a + PAC-PNS control connection in response to the receipt of an Echo- + Request. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Identifier | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Result Code | Error Code | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 6 for Echo-Reply. + + Reserved0 This field MUST be 0. + + Identifier The contents of the identify field from the + received Echo-Request is copied to this + field. + + Result Code Indicates the result of the receipt of the + Echo-Request. Current valid Result Code + values are: + + 1 (OK) - The Echo-Reply is valid + + 2 (General Error) - Echo-Request not + accepted for the reason indicated in + Error Code + + + +Hamzeh, et al. Informational [Page 18] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Error Code This field is set to 0 unless a "General + Error" condition exists, in which case + Result Code is set to 2 and this field is + set to the value corresponding to the + general error condition as specified in + section 2.2. + + Reserved1 This field MUST be 0. + +2.7. Outgoing-Call-Request + + The Outgoing-Call-Request is a PPTP control message sent by the PNS + to the PAC to indicate that an outbound call from the PAC is to be + established. This request provides the PAC with information required + to make the call. It also provides information to the PAC that is + used to regulate the transmission of data to the PNS for this session + once it is established. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hamzeh, et al. Informational [Page 19] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID | Call Serial Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Minimum BPS | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Maximum BPS | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Bearer Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Framing Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packet Recv. Window Size | Packet Processing Delay | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Phone Number Length | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Phone Number (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Subaddress (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 7 for Outgoing-Call-Request. + + Reserved0 This field MUST be 0. + + + + + + + + + +Hamzeh, et al. Informational [Page 20] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Call ID A unique identifier, unique to a particular + PAC-PNS pair assigned by the PNS to this + session. It is used to multiplex and + demultiplex data sent over the tunnel + between the PNS and PAC involved in this + session. + + Call Serial Number An identifier assigned by the PNS to this + session for the purpose of identifying this + particular session in logged session + information. Unlike the Call ID, both the + PNS and PAC associate the same Call Serial + Number with a given session. The combination + of IP address and call serial number SHOULD + be unique. + + Minimum BPS The lowest acceptable line speed (in + bits/second) for this session. + + Maximum BPS The highest acceptable line speed (in + bits/second) for this session. + + Bearer Type A value indicating the bearer capability + required for this outgoing call. The + currently defined values are: + + 1 - Call to be placed on an analog + channel + + 2 - Call to be placed on a digital + channel + + 3 - Call can be placed on any type of + channel + + Framing Type A value indicating the type of PPP framing + to be used for this outgoing call. + + 1 - Call to use Asynchronous framing + + 2 - Call to use Synchronous framing + + 3 - Call can use either type of + framing + + Packet Recv. Window Size The number of received data packets the PNS + will buffer for this session. + + + + +Hamzeh, et al. Informational [Page 21] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Packet Processing Delay A measure of the packet processing delay + that might be imposed on data sent to the + PNS from the PAC. This value is specified + in units of 1/10 seconds. For the PNS this + number should be very small. See section + 4.4 for a description of how this value is + determined and used. + + Phone Number Length The actual number of valid digits in the + Phone Number field. + + Reserved1 This field MUST be 0. + + Phone Number The number to be dialed to establish the + outgoing session. For ISDN and analog calls + this field is an ASCII string. If the Phone + Number is less than 64 octets in length, the + remainder of this field is filled with + octets of value 0. + + Subaddress A 64 octet field used to specify additional + dialing information. If the subaddress is + less than 64 octets long, the remainder of + this field is filled with octets of value 0. + +2.8. Outgoing-Call-Reply + + The Outgoing-Call-Reply is a PPTP control message sent by the PAC to + the PNS in response to a received Outgoing-Call-Request message. The + reply indicates the result of the outgoing call attempt. It also + provides information to the PNS about particular parameters used for + the call. It provides information to allow the PNS to regulate the + transmission of data to the PAC for this session. + + + + + + + + + + + + + + + + + + +Hamzeh, et al. Informational [Page 22] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID | Peer's Call ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Result Code | Error Code | Cause Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Connect Speed | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packet Recv. Window Size | Packet Processing Delay | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Physical Channel ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 8 for Outgoing-Call-Reply. + + Reserved0 This field MUST be 0. + + Call ID A unique identifier for the tunnel, assigned + by the PAC to this session. It is used to + multiplex and demultiplex data sent over the + tunnel between the PNS and PAC involved in + this session. + + Peer's Call ID This field is set to the value received in + the Call ID field of the corresponding + Outgoing-Call-Request message. It is used + by the PNS to match the Outgoing-Call-Reply + with the Outgoing-Call-Request it issued. It + also is used as the value sent in the GRE + header for mux/demuxing. + + + + + + + +Hamzeh, et al. Informational [Page 23] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Result Code This value indicates the result of the + Outgoing-Call-Request attempt. Currently + valid values are: + + 1 (Connected) - Call established with + no errors + + 2 (General Error) - Outgoing Call not + established for the reason indicated + in Error Code + + 3 (No Carrier) - Outgoing Call failed + due to no carrier detected + + 4 (Busy) - Outgoing Call failed due to + detection of a busy signal + + 5 (No Dial Tone) - Outgoing Call + failed due to lack of a dial tone + + 6 (Time-out) - Outgoing Call was not + established within time allotted by + PAC + + 7 (Do Not Accept) - Outgoing Call + administratively prohibited + + Error Code This field is set to 0 unless a "General + Error" condition exists, in which case + Result Code is set to 2 and this field is + set to the value corresponding to the + general error condition as specified in + section 2.2. + + Cause Code This field gives additional failure + information. Its value can vary depending + upon the type of call attempted. For ISDN + call attempts it is the Q.931 cause code. + + Connect Speed The actual connection speed used, in + bits/second. + + Packet Recv. Window Size The number of received data packets the PAC + will buffer for this session. + + + + + + + +Hamzeh, et al. Informational [Page 24] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Packet Processing Delay A measure of the packet processing delay + that might be imposed on data sent to the + PAC from the PNS. This value is specified + in units of 1/10 seconds. For the PAC, this + number is related to the size of the buffer + used to hold packets to be sent to the + client and to the speed of the link to the + client. This value should be set to the + maximum delay that can normally occur + between the time a packet arrives at the PAC + and is delivered to the client. See section + 4.4 for an example of how this value is + determined and used. + + Physical Channel ID This field is set by the PAC in a vendor- + specific manner to the physical channel + number used to place this call. It is used + for logging purposes only. + +2.9. Incoming-Call-Request + + The Incoming-Call-Request is a PPTP control message sent by the PAC + to the PNS to indicate that an inbound call is to be established from + the PAC. This request provides the PNS with parameter information + for the incoming call. + + This message is the first in the "three-way handshake" used by PPTP + for establishing incoming calls. The PAC may defer answering the + call until it has received an Incoming-Call-Reply from the PNS + indicating that the call should be established. This mechanism allows + the PNS to obtain sufficient information about the call before it is + answered to determine whether the call should be answered or not. + + + + + + + + + + + + + + + + + + + +Hamzeh, et al. Informational [Page 25] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID | Call Serial Number | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call Bearer Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Physical Channel ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Dialed Number Length | Dialing Number Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Dialed Number (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Dialing Number (64 octets) + + | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Subaddress (64 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 9 for Incoming-Call-Request. + + Reserved0 This field MUST be 0. + + Call ID A unique identifier for this tunnel, + assigned by the PAC to this session. It is + used to multiplex and demultiplex data sent + over the tunnel between the PNS and PAC + involved in this session. + + + + + +Hamzeh, et al. Informational [Page 26] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Call Serial Number An identifier assigned by the PAC to this + session for the purpose of identifying this + particular session in logged session + information. Unlike the Call ID, both the + PNS and PAC associate the same Call Serial + Number to a given session. The combination + of IP address and call serial number should + be unique. + + Bearer Type A value indicating the bearer capability + used for this incoming call. Currently + defined values are: + + 1 - Call is on an analog channel + + 2 - Call is on a digital channel + + Physical Channel ID This field is set by the PAC in a vendor- + specific manner to the number of the + physical channel this call arrived on. + + Dialed Number Length The actual number of valid digits in the + Dialed Number field. + + Dialing Number Length The actual number of valid digits in the + Dialing Number field. + + Dialed Number The number that was dialed by the caller. + For ISDN and analog calls this field is an + ASCII string. If the Dialed Number is less + than 64 octets in length, the remainder of + this field is filled with octets of value 0. + + Dialing Number The number from which the call was placed. + For ISDN and analog calls this field is an + ASCII string. If the Dialing Number is less + than 64 octets in length, the remainder of + this field is filled with octets of value 0. + + Subaddress A 64 octet field used to specify additional + dialing information. If the subaddress is + less than 64 octets long, the remainder of + this field is filled with octets of value 0. + + + + + + + + +Hamzeh, et al. Informational [Page 27] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +2.10. Incoming-Call-Reply + + The Incoming-Call-Reply is a PPTP control message sent by the PNS to + the PAC in response to a received Incoming-Call-Request message. The + reply indicates the result of the incoming call attempt. It also + provides information to allow the PAC to regulate the transmission of + data to the PNS for this session. + + This message is the second in the three-way handshake used by PPTP + for establishing incoming calls. It indicates to the PAC whether the + call should be answered or not. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID | Peer's Call ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Result Code | Error Code | Packet Recv. Window Size | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packet Transmit Delay | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 10 for Incoming-Call-Reply. + + Reserved0 This field MUST be 0. + + Call ID A unique identifier for this tunnel assigned + by the PNS to this session. It is used to + multiplex and demultiplex data sent over the + tunnel between the PNS and PAC involved in + this session. + + Peer's Call ID This field is set to the value received in + the Call ID field of the corresponding + Incoming-Call-Request message. It is used by + + + +Hamzeh, et al. Informational [Page 28] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + the PAC to match the Incoming-Call-Reply + with the Incoming-Call-Request it issued. + This value is included in the GRE header of + transmitted data packets for this session. + + Result Code This value indicates the result of the + Incoming-Call-Request attempt. Current + valid Result Code values are: + + 1 (Connect) - The PAC should answer + the incoming call + + 2 (General Error) - The Incoming Call + should not be established due to the + reason indicated in Error Code + + 3 (Do Not Accept) - The PAC should not + accept the incoming call. It should + hang up or issue a busy indication + + Error Code This field is set to 0 unless a "General + Error" condition exists, in which case + Result Code is set to 2 and this field is + set to the value corresponding to the + general error condition as specified in + section 2.2. + + Packet Recv. Window Size The number of received data packets the PAC + will buffer for this session. + + Packet Transmit Delay A measure of the packet processing delay + that might be imposed on data sent to the + PAC from the PNS. This value is specified + in units of 1/10 seconds. + + Reserved1 This field MUST be 0. + +2.11. Incoming-Call-Connected + + The Incoming-Call-Connected message is a PPTP control message sent by + the PAC to the PNS in response to a received Incoming-Call-Reply. It + provides information to the PNS about particular parameters used for + the call. It also provides information to allow the PNS to regulate + the transmission of data to the PAC for this session. + + This message is the third in the three-way handshake used by PPTP for + establishing incoming calls. It provides a mechanism for providing + the PNS with additional information about the call that cannot, in + + + +Hamzeh, et al. Informational [Page 29] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + general, be obtained at the time the Incoming-Call-Request is issued + by the PAC. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer's Call ID | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Connect Speed | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Packet Recv. Window Size | Packet Transmit Delay | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Framing Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 11 for Incoming-Call-Connected. + + Reserved0 This field MUST be 0. + + Peer's Call ID This field is set to the value received in + the Call ID field of the corresponding + Incoming-Call-Reply message. It is used by + the PNS to match the Incoming-Call-Connected + with the Incoming-Call-Reply it issued. + + Connect Speed The actual connection speed used, in + bits/second. + + Packet Recv. Window Size The number of received data packets the PAC + will buffer for this session. + + Packet Transmit Delay A measure of the packet processing delay + that might be imposed on data sent to the + PAC from the PNS. This value is specified + in units of 1/10 seconds. + + + +Hamzeh, et al. Informational [Page 30] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Framing Type A value indicating the type of PPP framing + being used by this incoming call. + + 1 - Call uses asynchronous framing + + 2 - Call uses synchronous framing + +2.12. Call-Clear-Request + + The Call-Clear-Request is a PPTP control message sent by the PNS to + the PAC indicating that a particular call is to be disconnected. The + call being cleared can be either an incoming or outgoing call, in any + state. The PAC responds to this message with a Call-Disconnect- + Notify message. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 12 for Call-Clear-Request. + + Reserved0 This field MUST be 0. + + Call ID The Call ID assigned by the PNS to this + call. This value is used instead of the + Peer's Call ID because the latter may not be + known to the PNS if the call must be aborted + during call establishment. + + Reserved1 This field MUST be 0. + + + + + + +Hamzeh, et al. Informational [Page 31] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +2.13. Call-Disconnect-Notify + + The Call-Disconnect-Notify message is a PPTP control message sent by + the PAC to the PNS. It is issued whenever a call is disconnected, + due to the receipt by the PAC of a Call-Clear-Request or for any + other reason. Its purpose is to inform the PNS of both the + disconnection and the reason for it. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message Type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Call ID | Result Code | Error Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cause Code | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + Call Statistics (128 octets) + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 13 for Call-Disconnect-Notify. + + Reserved0 This field MUST be 0. + + Call ID The value of the Call ID assigned by the PAC + to this call. This value is used instead of + the Peer's Call ID because the latter may + not be known to the PNS if the call must be + aborted during call establishment. + + + + + + + + + +Hamzeh, et al. Informational [Page 32] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Result Code This value indicates the reason for the + disconnect. Current valid Result Code values + are: + + 1 (Lost Carrier) - Call disconnected + due to loss of carrier + + 2 (General Error) - Call disconnected + for the reason indicated in Error + Code + + 3 (Admin Shutdown) - Call disconnected + for administrative reasons + + 4 (Request) - Call disconnected due to + received Call-Clear-Request + + Error Code This field is set to 0 unless a "General + Error" condition exists, in which case the + Result Code is set to 2 and this field is + set to the value corresponding to the + general error condition as specified in + section 2.2. + + Cause Code This field gives additional disconnect + information. Its value varies depending on + the type of call being disconnected. For + ISDN calls it is the Q.931 cause code. + + Call Statistics This field is an ASCII string containing + vendor-specific call statistics that can be + logged for diagnostic purposes. If the + length of the string is less than 128, the + remainder of the field is filled with octets + of value 0. + +2.14. WAN-Error-Notify + + The WAN-Error-Notify message is a PPTP control message sent by the + PAC to the PNS to indicate WAN error conditions (conditions that + occur on the interface supporting PPP). The counters in this message + are cumulative. This message should only be sent when an error + occurs, and not more than once every 60 seconds. The counters are + reset when a new call is established. + + + + + + + +Hamzeh, et al. Informational [Page 33] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer's Call ID | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | CRC Errors | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Framing Errors | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Hardware Overruns | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Buffer Overruns | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Time-out Errors | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Alignment Errors | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 14 for WAN-Error-Notify. + + Reserved0 This field MUST be 0. + + Peer's Call ID Th Call ID assigned by the PNS to this call. + + CRC Errors Number of PPP frames received with CRC + errors since session was established. + + Framing Errors Number of improperly framed PPP packets + received. + + Hardware Overruns Number of receive buffer over-runs since + session was established. + + Buffer Overruns Number of buffer over-runs detected since + session was established. + + + +Hamzeh, et al. Informational [Page 34] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Time-out Errors Number of time-outs since call was + established. + + Alignment Errors Number of alignment errors since call was + established. + +2.15. Set-Link-Info + + The Set-Link-Info message is a PPTP control message sent by the PNS + to the PAC to set PPP-negotiated options. Because these options can + change at any time during the life of the call, the PAC must be able + to update its internal call information dynamically and perform PPP + negotiation on an active PPP session. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Length | PPTP Message Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Magic Cookie | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Control Message type | Reserved0 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Peer's Call ID | Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Send ACCM | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Receive ACCM | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Length Total length in octets of this PPTP message, + including the entire PPTP header. + + PPTP Message Type 1 for Control Message. + + Magic Cookie 0x1A2B3C4D. + + Control Message Type 15 for Set-Link-Info. + + Reserved0 This field MUST be 0. + + Peer's Call ID The value of the Call ID assigned by the PAC + to this call. + + Reserved1 This field MUST be 0. + + + + + + +Hamzeh, et al. Informational [Page 35] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Send ACCM The send ACCM value the client should use to + process outgoing PPP packets. The default + value used by the client until this message + is received is 0XFFFFFFFF. See [7]. + + Receive ACCM The receive ACCM value the client should use + to process incoming PPP packets. The default + value used by the client until this message + is received is 0XFFFFFFFF. See [7]. + +2.16. General Error Codes + + General error codes pertain to types of errors which are not specific + to any particular PPTP request, but rather to protocol or message + format errors. If a PPTP reply indicates in its Result Code that a + general error occurred, the General Error value should be examined to + determined what the error was. The currently defined General Error + codes and their meanings are: + + 0 (None) - No general error + + 1 (Not-Connected) - No control connection exists yet for this + PAC-PNS pair + + 2 (Bad-Format) - Length is wrong or Magic Cookie value is + incorrect + + 3 (Bad-Value) - One of the field values was out of range or + reserved field was non-zero + + 4 (No-Resource) - Insufficient resources to handle this command + now + + 5 (Bad-Call ID) - The Call ID is invalid in this context + + 6 (PAC-Error) - A generic vendor-specific error occurred in + the PAC + +3. Control Connection Protocol Operation + + This section describes the operation of various PPTP control + connection functions and the Control Connection messages which are + used to support them. The protocol operation of the control + connection is simplified because TCP is used to provide a reliable + transport mechanism. Ordering and retransmission of messages is not + a concern at this level. The TCP connection itself, however, can + close at any time and an appropriate error recovery mechanism must be + provided to handle this case. + + + +Hamzeh, et al. Informational [Page 36] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Some error recovery procedures are common to all states of the + control connection. If an expected reply does not arrive within 60 + seconds, the control connection is closed, unless otherwise + specified. Appropriate logging should be implemented for easy + determination of the problems and the reasons for closing the control + connection. + + Receipt of an invalid or malformed Control Connection message should + be logged appropriately, and the control connection should be closed + and restarted to ensure recovery into a known state. + +3.1. Control Connection States + + The control connection relies on a standard TCP connection for its + service. The PPTP control connection protocol is not distinguishable + between the PNS and PAC, but is distinguishable between the + originator and receiver. The originating peer is the one which first + attempts the TCP open. Since either PAC or PNS may originate a + connection, it is possible for a TCP collision to occur. See section + 3.1.3 for a description of this situation. + +3.1.1. Control Connection Originator (may be PAC or PNS) + + TCP Open Indication + /Send Start Control + Connection Request +-----------------+ + +------------------------------------>| wait_ctl_reply | + | +-----------------+ + | Collision/See (4.1.3) Close TCP V V V Receive Start Ctl + | +-------------------------------+ | | Connection Reply + | | | | Version OK + ^ V | V ++-----------------+ Receive Start Ctl | +-----------------+ +| idle | Connection Reply | | established | ++-----------------+ Version Not OK | +-----------------+ + ^ | V Local Terminate + | Receive Stop Control | | /Send Stop + | Connection Request | | Control Request + | /Send Stop Control Reply V V + | Close TCP +-----------------+ + +-------------------------------------| wait_stop_reply | + +-----------------+ + + + + + + + + + +Hamzeh, et al. Informational [Page 37] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + idle + The control connection originator attempts to open a TCP + connection to the peer during idle state. When the TCP connection + is open, the originator transmits a send Start-Control- + Connection-Request and then enters the wait_ctl_reply state. + + wait_ctl_reply + The originator checks to see if another TCP connection has been + requested from the same peer, and if so, handles the collision + situation described in section 3.1.3. + + When a Start-Control-Connection-Reply is received, it is examined + for a compatible version. If the version of the reply is lower + than the version sent in the request, the older (lower) version + should be used provided it is supported. If the version in the + reply is earlier and supported, the originator moves to the + established state. If the version is earlier and not supported, a + Stop-Control-Connection-Request SHOULD be sent to the peer and the + originator moves into the wait_stop_reply state. + + established + An established connection may be terminated by either a local + condition or the receipt of a Stop-Control-Connection-Request. In + the event of a local termination, the originator MUST send a + Stop-Control-Connection-Request and enter the wait_stop_reply + state. + + If the originator receives a Stop-Control-Connection-Request it + SHOULD send a Stop-Control-Connection-Reply and close the TCP + connection making sure that the final TCP information has been + "pushed" properly. + + wait_stop_reply + If a Stop-Control-Connection-Reply is received, the TCP connection + SHOULD be closed and the control connection becomes idle. + + + + + + + + + + + + + + + + +Hamzeh, et al. Informational [Page 38] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +3.1.2. Control connection Receiver (may be PAC or PNS) + +Receive Start Control Connection Request +Version Not OK/Send Start Control Connection +Reply with Error + +--------+ + | | Receive Control Connection Request Version OK + | | /Send Start Control Connection Reply + | | +----------------------------------------+ + ^ V ^ V ++-----------------+ Receive Start Ctl +-----------------+ +| Idle | Connection Request | Established | ++-----------------+ /Send Stop Reply +-----------------+ + ^ ^ Close TCP V V Local Terminate + | +-------------------------------------+ | /Send Stop + | | Control Conn. + | V Request + | +-----------------+ + +-------------------------------------| Wait-Stop-Reply | + Receive Stop Control +-----------------+ + Connection Reply + /Close TCP + + idle + The control connection receiver waits for a TCP open attempt on + port 1723. When notified of an open TCP connection, it should + prepare to receive PPTP messages. When a Start-Control- + Connection-Request is received its version field should be + examined. If the version is earlier than the receiver's version + and the earlier version can be supported by the receiver, the + receiver SHOULD send a Start-Control-Connection-Reply. If the + version is earlier than the receiver's version and the version + cannot be supported, the receiver SHOULD send a Start-Connection- + Reply message, close the TCP connection and remain in the idle + state. If the receiver's version is the same as earlier than the + peer's, the receiver SHOULD send a Start-Control-Connection-Reply + with the receiver's version and enter the established state. + + established + An established connection may be terminated by either a local + condition or the reception of a Stop-Control-Connection-Request. + In the event of a local termination, the originator MUST send a + Stop-Control-Connection-Request and enter the wait_stop_reply + state. + + + + + + + +Hamzeh, et al. Informational [Page 39] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + If the originator receives a Stop-Control-Connection-Request it + SHOULD send a Stop-Control-Connection-Reply and close the TCP + connection, making sure that the final TCP information has been + "pushed" properly. + + wait_stop_reply + If a Stop-Control-Connection-Reply is received, the TCP connection + SHOULD be closed and the control connection becomes idle. + +3.1.3. Start Control Connection Initiation Request Collision + + A PAC and PNS must have only one control connection between them. It + is possible, however, for a PNS and a PAC to simultaneously attempt + to establish a control connection to each other. When a Start- + Control-Connection-Request is received on one TCP connection and + another Start-Control-Connection-Request has already been sent on + another TCP connection to the same peer, a collision has occurred. + + The "winner" of the initiation race is the peer with the higher IP + address (compared as 32 bit unsigned values, network number more + significant). For example, if the peers 192.33.45.17 and 192.33.45.89 + collide, the latter will be declared the winner. The loser will + immediately close the TCP connection it initiated, without sending + any further PPTP control messages on it and will respond to the + winner's request with a Start-Control-Connection-Reply message. The + winner will wait for the Start-Control-Connection-Reply on the + connection it initiated and also wait for a TCP termination + indication on the connection the loser opened. The winner MUST NOT + send any messages on the connection the loser initiated. + +3.1.4. Keep Alives and Timers + + A control connection SHOULD be closed by closing the underlying TCP + connection under the following circumstances: + + 1. If a control connection is not in the established state (i.e., + Start-Control-Connection-Request and Start-Control-Connection- + Reply have not been exchanged), a control connection SHOULD be + closed after 60 seconds by a peer waiting for a Start-Control- + Connection-Request or Start-Control-Connection-Reply message. + + 2. If a peer's control connection is in the established state and has + not received a control message for 60 seconds, it SHOULD send a + Echo-Request message. If an Echo-Reply is not received 60 seconds + after the Echo-Request message transmission, the control + connection SHOULD be closed. + + + + + +Hamzeh, et al. Informational [Page 40] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +3.2. Call States + +3.2.1. Timing considerations + + Because of the real-time nature of telephone signaling, both the PNS + and PAC should be implemented with multi-threaded architectures such + that messages related to multiple calls are not serialized and + blocked. The transit delay between the PAC and PNS should not exceed + one second. The call and connection state figures do not specify + exceptions caused by timers. The implicit assumption is that since + the TCP-based control connection is being verified with keep-alives, + there is less need to maintain strict timers for call control + messages. + + Establishing outbound international calls, including the modem + training and negotiation sequences, may take in excess of 1 minute so + the use of short timers is discouraged. + + If a state transition does not occur within 1 minute (except for + connections in the idle or established states), the integrity of the + protocol processing between the peers is suspect and the ENTIRE + CONTROL CONNECTION should be closed and restarted. All Call IDs are + logically released whenever a control connection is started. This + presumably also helps in preventing toll calls from being "lost" and + never cleared. + +3.2.2. Call ID Values + + Each peer assigns a Call ID value to each user session it requests or + accepts. This Call ID value MUST be unique for the tunnel between the + PNS and PAC to which it belongs. Tunnels to other peers can use the + same Call ID number so the receiver of a packet on a tunnel needs to + associate a user session with a particular tunnel and Call ID. It is + suggested that the number of potential Call ID values for each tunnel + be at least twice as large as the maximum number of calls expected on + a given tunnel. + + A session is defined by the triple (PAC, PNS, Call ID). + +3.2.3. Incoming Calls + + An Incoming-Call-Request message is generated by the PAC when an + associated telephone line rings. The PAC selects a Call ID and serial + number and indicates the call bearer type. Modems should always + indicate analog call type. ISDN calls should indicate digital when + unrestricted digital service or rate adaption is used and analog if + + + + + +Hamzeh, et al. Informational [Page 41] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + digital modems are involved. Dialing number, dialed number, and + subaddress may be included in the message if they are available from + the telephone network. + + Once the PAC sends the Incoming-Call-Request, it waits for a response + from the PNS but does not answer the call from the telephone network. + The PNS may choose not to accept the call if: + + - No resources are available to handle more sessions + + - The dialed, dialing, or subaddress fields are not indicative of + an authorized user + + - The bearer service is not authorized or supported + + If the PNS chooses to accept the call, it responds with an Incoming- + Call-Reply which also indicates window sizes (see section 4.2). When + the PAC receives the Outgoing-Call-Reply, it attempts to connect the + call, assuming the calling party has not hung up. A final call + connected message from the PAC to the PNS indicates that the call + states for both the PAC and the PNS should enter the established + state. + + When the dialed-in client hangs up, the call is cleared normally and + the PAC sends a Call-Disconnect-Notify message. If the PNS wishes to + clear a call, it sends a Call-Clear-Request message and then waits + for a Call-Disconnect-Notify. + +3.2.3.1. PAC Incoming Call States + + Ring/Send Incoming Call Request +-----------------+ + +----------------------------------------->| wait_reply | + | +-----------------+ + | Receive Incoming Call Reply V V V + | Not Accepting | | | Receive Incoming + | +--------------------------------+ | | Call Reply Accept- + | | +------------------------------+ | ing/Answer call; + | | | Abort/Send Call | Send Call + ^ V V Disconnect Notify V Connected ++-----------------+ +-----------------+ +| idle |<-----------------------------| established | ++-----------------+ Receive Clear Call Request +-----------------+ + or telco call dropped + or local disconnect + /Send Call Disconnect Notify + + + + + + +Hamzeh, et al. Informational [Page 42] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +The states associated with the PAC for incoming calls are: + + idle + The PAC detects an incoming call on one of its telco interfaces. + Typically this means an analog line is ringing or an ISDN TE has + detected an incoming Q.931 SETUP message. The PAC sends an + Incoming-Call-Request message and moves to the wait_reply state. + + wait_reply + The PAC receives an Incoming-Call-Reply message indicating non- + willingness to accept the call (general error or don't accept) and + moves back into the idle state. If the reply message indicates + that the call is accepted, the PAC sends an Incoming-Call- + Connected message and enters the established state. + + established + Data is exchanged over the tunnel. The call may be cleared + following: + + An event on the telco connection. The PAC sends a + Call-Disconnect-Notify message + + Receipt of a Call-Clear-Request. The PAC sends a + Call-Disconnect-Notify message + + A local reason. The PAC sends a Call-Disconnect-Notify message. + +3.2.3.2. PNS Incoming Call States + + Receive Incoming Call Request + /Send Incoming Call Reply +-----------------+ + Not Accepting if Error | Wait-Connect | + +-----+ +-----------------+ + | | Receive Incoming Call Req. ^ V V + | | /Send Incoming Call Reply OK | | | Receive Incoming + | | +--------------------------------+ | | Call Connect + ^ V ^ V------------------------------+ V ++-----------------+ Receive Call Disconnect +-----------------+ +| Idle | Notify +- | Established | ++-----------------+ | +-----------------+ + ^ ^ | V Local Terminate + | +----------------------------+ | /Send Call Clear + | Receive Call Disconnect | Request + | Notify V + | +-----------------+ + +--------------------------------------| Wait-Disconnect | + Receive Call Disconnect +-----------------+ + Notify + + + +Hamzeh, et al. Informational [Page 43] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +The states associated with the PNS for incoming calls are: + + idle + An Incoming-Call-Request message is received. If the request is + not acceptable, an Incoming-Call-Reply is sent back to the PAC and + the PNS remains in the idle state. If the Incoming-Call-Request + message is acceptable, an Incoming-Call-Reply is sent indicating + accept in the result code. The session moves to the wait_connect + state. + + wait_connect + If the session is connected on the PAC, the PAC sends an incoming + call connect message to the PNS which then moves into established + state. The PAC may send a Call-Disconnect-Notify to indicate that + the incoming caller could not be connected. This could happen, + for example, if a telephone user accidently places a standard + voice call to a PAC resulting in a handshake failure on the called + modem. + + established + The session is terminated either by receipt of a Call-Disconnect- + Notify message from the PAC or by sending a Call-Clear-Request. + Once a Call-Clear-Request has been sent, the session enters the + wait_disconnect state. + + wait_disconnect + Once a Call-Disconnect-Notify is received the session moves back + to the idle state. + +3.2.4. Outgoing Calls + + Outgoing messages are initiated by a PNS and instruct a PAC to place + a call on a telco interface. There are only two messages for outgoing + calls: Outgoing-Call-Request and Outgoing-Call-Reply. The PNS sends + an Outgoing-Call-Request specifying the dialed party phone number and + subaddress as well as speed and window parameters. The PAC MUST + respond to the Outgoing-Call-Request message with an Outgoing-Call- + Reply message once the PAC determines that: + + The call has been successfully connected + + A call failure has occurred for reasons such as: no interfaces are + available for dial-out, the called party is busy or does not + answer, or no dial tone is detected on the interface chosen for + dialing + + + + + + +Hamzeh, et al. Informational [Page 44] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +3.2.4.1. PAC Outgoing Call States + +Receive Outgoing Call Request in Error +/Send Outgoing Call Reply with Error + |--------+ + | | Receive Outgoing Call Request No Error + | | /Off Hook; Dial + | | +----------------------------------------- + ^ V ^ V ++-----------------+ Incomplete Call +-----------------+ +| idle | /Send Outgoing Call | wait_cs_ans | ++-----------------+ Reply with Error +-----------------+ + ^ ^ or Recv. Call Clear Req. V V Telco Answer + | | /Send Disconnect Notify| | /Send Outgoing + | +-------------------------------------+ | Call Reply. + | V + | +-----------------+ + +-------------------------------------| established | + Receive Call Clear Request +-----------------+ + or local terminate + or telco disconnect + /Hangup call and send + Call Disconnect Notify + + The states associated with the PAC for outgoing calls are: + + idle + Received Outgoing-Call-Request. If this is received in error, + respond with an Outgoing-Call-Reply with error condition set. + Otherwise, allocate physical channel to dial on. Place the + outbound call, wait for a connection, and move to the wait_cs_ans + state. + + wait_cs_ans + If the call is incomplete, send an Outgoing-Call-Reply with a + non-zero Error Code. If a timer expires on an outbound call, send + back an Outgoing-Call-Reply with a non-zero Error Code. If a + circuit switched connection is established, send an Outgoing- + Call-Reply indicating success. + + established + If a Call-Clear-Request is received, the telco call SHOULD be + released via appropriate mechanisms and a Call-Disconnect-Notify + message SHOULD BE sent to the PNS. If the call is disconnected by + the client or by the telco interface, a Call-Disconnect-Notify + message SHOULD be sent to the PNS. + + + + + +Hamzeh, et al. Informational [Page 45] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +3.2.4.2. PNS Outgoing Call States + + Open Indication Abort/Send + /Send Outgoing Call Call Clear + Request +-----------------+Request + +-------------------------------->| Wait-Reply |----------+ + | +-----------------+ | + | Receive Outgoing Call Reply V V Receive Outgoing | + | with Error | | Call Reply | + | +-------------------------------+ | No Error | + ^ V V | ++-----------------+ +-----------------+ | +| Idle |<-----------------------------| Established | | ++-----------------+ Receive Call Disconnect +-----------------+ | + ^ Notify V Local Terminate | + | | /Send Call Clear | + | | Request | + | Receive Call Disconnect V | + | Notify +-----------------+ | + +---------------------------------| Wait-Disconnect |<---------+ + +-----------------+ + +The states associated with the PNS for outgoing calls are: + + idle + An Outgoing-Call-Request message is sent to the PAC and the + session moves into the wait_reply state. + + wait_reply + An Outgoing-Call-Reply is received which indicates an error. The + session returns to idle state. No telco call is active. If the + Outgoing-Call-Reply does not indicate an error, the telco call is + connected and the session moves to the established state. + + established + If a Call-Disconnect-Notify is received, the telco call has been + terminated for the reason indicated in the Result and Cause Codes. + The session moves back to the idle state. If the PNS chooses to + terminate the session, it sends a Call-Clear-Request to the PAC + and then enters the wait_disconnect state. + + wait_disconnect + A session disconnection is waiting to be confirmed by the PAC. + Once the PNS receives the Call-Disconnect-Notify message, the + session enters idle state. + + + + + + +Hamzeh, et al. Informational [Page 46] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +4. Tunnel Protocol Operation + + The user data carried by the PPTP protocol are PPP data packets. PPP + packets are carried between the PAC and PNS, encapsulated in GRE + packets which in turn are carried over IP. The encapsulated PPP + packets are essentially PPP data packets less any media specific + framing elements. No HDLC flags, bit insertion, control characters, + or control character escapes are included. No CRCs are sent through + the tunnel. The IP packets transmitted over the tunnels between a PAC + and PNS has the following general structure: + + +--------------------------------+ + | Media Header | + +--------------------------------+ + | IP Header | + +--------------------------------+ + | GRE Header | + +--------------------------------+ + | PPP Packet | + +--------------------------------+ + +4.1. Enhanced GRE header + + The GRE header used in PPTP is enhanced slightly from that specified + in the current GRE protocol specification [1,2]. The main difference + involves the definition of a new Acknowledgment Number field, used to + determine if a particular GRE packet or set of packets has arrived at + the remote end of the tunnel. This Acknowledgment capability is not + used in conjunction with any retransmission of user data packets. It + is used instead to determine the rate at which user data packets are + to be transmitted over the tunnel for a given user session. The + format of the enhanced GRE header is as follows: + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |C|R|K|S|s|Recur|A| Flags | Ver | Protocol Type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Key (HW) Payload Length | Key (LW) Call ID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sequence Number (Optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Acknowledgment Number (Optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Hamzeh, et al. Informational [Page 47] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + C + (Bit 0) Checksum Present. Set to zero (0). + + R + (Bit 1) Routing Present. Set to zero (0). + + K + (Bit 2) Key Present. Set to one (1). + S + (Bit 3) Sequence Number Present. Set to one (1) if a payload + (data) packet is present. Set to zero (0) if payload is not + present (GRE packet is an Acknowledgment only). + + s + (Bit 4) Strict source route present. Set to zero (0). + + Recur + (Bits 5-7) Recursion control. Set to zero (0). + + A + (Bit 8) Acknowledgment sequence number present. Set to one (1) if + packet contains Acknowledgment Number to be used for acknowledging + previously transmitted data. + + Flags + (Bits 9-12) Must be set to zero (0). + + Ver + (Bits 13-15) Must contain 1 (enhanced GRE). + + Protocol Type + Set to hex 880B [8]. + + Key + Use of the Key field is up to the implementation. PPTP uses it as + follows: + Payload Length + (High 2 octets of Key) Size of the payload, not including + the GRE header + + Call ID + (Low 2 octets) Contains the Peer's Call ID for the session + to which this packet belongs. + + Sequence Number + Contains the sequence number of the payload. Present if S + bit (Bit 3) is one (1). + + + + +Hamzeh, et al. Informational [Page 48] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Acknowledgment Number + Contains the sequence number of the highest numbered GRE + packet received by the sending peer for this user session. + Present if A bit (Bit 8) is one (1). + + The payload section contains a PPP data packet without any + media specific framing elements. + + The sequence numbers involved are per packet sequence numbers. + The sequence number for each user session is set to zero at + session startup. Each packet sent for a given user session + which contains a payload (and has the S bit (Bit 3) set to one) + is assigned the next consecutive sequence number for that + session. + + This protocol allows acknowledgments to be carried with the + data and makes the overall protocol more efficient, which in + turn requires less buffering of packets. + +4.2. Sliding Window Protocol + + The sliding window protocol used on the PPTP data path is used for + flow control by each side of the data exchange. The enhanced GRE + protocol allows packet acknowledgments to be piggybacked on data + packets. Acknowledgments can also be sent separately from data + packets. Again, the main purpose of the sliding window protocol is + for flow control--retransmissions are not performed by the tunnel + peers. + +4.2.1. Initial Window Size + + Although each side has indicated the maximum size of its receive + window, it is recommended that a conservative approach be taken when + beginning to transmit data. The initial window size on the + transmitter is set to half the maximum size the receiver requested, + with a minimum size of one packet. The transmitter stops sending + packets when the number of packets awaiting acknowledgment is equal + to the current window size. As the receiver successfully digests + each window, the window size on the transmitter is bumped up by one + packet until the maximum is reached. This method prevents a system + from flooding an already congested network because no history has + been established. + +4.2.2. Closing the Window + + When a time-out does occur on a packet, the sender adjusts the size + of the transmit window down to one half its value when it failed. + Fractions are rounded up, and the minimum window size is one. + + + +Hamzeh, et al. Informational [Page 49] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +4.2.3. Opening the Window + + With every successful transmission of a window's worth of packets + without a time-out, the transmit window size is increased by one + packet until it reaches the maximum window size that was sent by the + other side when the call was connected. As stated earlier, no + retransmission is done on a time-out. After a time-out, the + transmission resumes with the window starting at one half the size of + the transmit window when the time-out occurred and adjusting upward + by one each time the transmit window is filled with packets that are + all acknowledged without time-outs. + +4.2.4. Window Overflow + + When a receiver's window overflows with too many incoming packets, + excess packets are thrown away. This situation should not arise if + the sliding window procedures are being properly followed by the + transmitter and receiver. It is assumed that, on the transmit side, + packets are buffered for transmission and are no longer accepted from + the packet source when the transmit buffer fills. + +4.2.5. Multi-packet Acknowledgment + + One feature of the PPTP sliding window protocol is that it allows the + acknowledgment of multiple packets with a single acknowledgment. All + outstanding packets with a sequence number lower or equal to the + acknowledgment number are considered acknowledged. Time-out + calculations are performed using the time the packet corresponding to + the highest sequence number being acknowledged was transmitted. + + Adaptive time-out calculations are only performed when an + Acknowledgment is received. When multi-packet acknowledgments are + used, the overhead of the adaptive time-out algorithm is reduced. The + PAC is not required to transmit multi-packet acknowledgments; it can + instead acknowledge each packet individually as it is delivered to + the PPP client. + +4.3. Out-of-sequence Packets + + Occasionally packets lose their sequencing across a complicated + internetwork. Say, for example that a PNS sends packets 0 to 5 to a + PAC. Because of rerouting in the internetwork, packet 4 arrives at + the PAC before packet 3. The PAC acknowledges packet 4, and may + assume packet 3 is lost. This acknowledgment grants window credit + beyond packet 4. + + + + + + +Hamzeh, et al. Informational [Page 50] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + When the PAC does receive packet 3, it MUST not attempt to transmit + it to the corresponding PPP client. To do so could cause problems, + as proper PPP protocol operation is premised upon receiving packets + in sequence. PPP does properly deal with the loss of packets, but + not with reordering so out of sequence packets between the PNS and + PAC MUST be silently discarded, or they may be reordered by the + receiver. When packet 5 comes in, it is acknowledged by the PAC + since it has a higher sequence number than 4, which was the last + highest packet acknowledged by the PAC. Packets with duplicate + sequence numbers should never occur since the PAC and PNS never + retransmit GRE packets. A robust implementation will silently + discard duplicate GRE packets, should it receive any. + +4.4. Acknowledgment Time-Outs + + PPTP uses sliding windows and time-outs to provide both user session + flow-control across the internetwork and to perform efficient data + buffering to keep the PAC-PNS data channels full without causing + receive buffer overflow. PPTP requires that a time-out be used to + recover from dropped data or acknowledgment packets. The exact + implementation of the time-out is vendor-specific. It is suggested + that an adaptive time-out be implemented with backoff for congestion + control. The time-out mechanism proposed here has the following + properties: + + Independent time-outs for each session. A device (PAC or PNS) will + have to maintain and calculate time-outs for every active session. + + An administrator-adjustable maximum time-out, MaxTimeOut, unique + to each device. + + An adaptive time-out mechanism that compensates for changing + throughput. To reduce packet processing overhead, vendors may + choose not to recompute the adaptive time-out for every received + acknowledgment. The result of this overhead reduction is that the + time-out will not respond as quickly to rapid network changes. + + Timer backoff on time-out to reduce congestion. The backed-off + timer value is limited by the configurable maximum time-out value. + Timer backoff is done every time an acknowledgment time-out + occurs. + + In general, this mechanism has the desirable behavior of quickly + backing off upon a time-out and of slowly decreasing the time-out + value as packets are delivered without time-outs. + + + + + + +Hamzeh, et al. Informational [Page 51] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Some definitions: + + Packet Processing Delay (PPD) is the amount of time required for + each side to process the maximum amount of data buffered in their + receive packet sliding window. The PPD is the value exchanged + between the PAC and PNS when a call is established. For the PNS, + this number should be small. For a PAC making modem connections, + this number could be significant. + + Sample is the actual amount of time incurred receiving an + acknowledgment for a packet. The Sample is measured, not + calculated. + + Round-Trip Time (RTT) is the estimated round-trip time for an + Acknowledgment to be received for a given transmitted packet. When + the network link is a local network, this delay will be minimal + (if not zero). When the network link is the Internet, this delay + could be substantial and vary widely. RTT is adaptive: it will + adjust to include the PPD and whatever shifting network delays + contribute to the time between a packet being transmitted and + receiving its acknowledgment. + + Adaptive Time-Out (ATO) is the time that must elapse before an + acknowledgment is considered lost. After a time-out, the sliding + window is partially closed and the ATO is backed off. + + The Packet Processing Delay (PPD) parameter is a 16-bit word + exchanged during the Call Control phase that represents tenths of a + second (64 means 6.4 seconds). The protocol only specifies that the + parameter is exchanged, it does not specify how it is calculated. The + way values for PPD are calculated is implementation-dependent and + need not be variable (static time-outs are allowed). The PPD must be + exchanged in the call connect sequences, even if it remains constant + in an implementation. One possible way to calculate the PPD is: + + PPD' = ((PPP_MAX_DATA_MTU - Header) * WindowSize * 8) / ConnectRate + PPD = PPD' + PACFudge + + Header is the total size of the IP and GRE headers, which is 36. The + MTU is the overall MTU for the internetwork link between the PAC and + PNS. WindowSize represents the number of packets in the sliding + window, and is implementation-dependent. The latency of the + internetwork could be used to pick a window size sufficient to keep + the current session's pipe full. The constant 8 converts octets to + bits (assuming ConnectRate is in bits per second). If ConnectRate is + in bytes per second, omit the 8. PACFudge is not required but can be + used to take overall processing overhead of the PAC into account. + + + + +Hamzeh, et al. Informational [Page 52] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + The value of PPD is used to seed the adaptive algorithm with the + initial RTT[n-1] value. + +4.4.1. Calculating Adaptive Acknowledgment Time-Out + + We still must decide how much time to allow for acknowledgments to + return. If the time-out is set too high, we may wait an unnecessarily + long time for dropped packets. If the time-out is too short, we may + time out just before the acknowledgment arrives. The acknowledgment + time-out should also be reasonable and responsive to changing network + conditions. + + The suggested adaptive algorithm detailed below is based on the TCP + 1989 implementation and is explained in [11]. 'n' means this + iteration of the calculation, and 'n-1' refers to values from the + last calculation. + + DIFF[n] = SAMPLE[n] - RTT[n-1] + DEV[n] = DEV[n-1] + (beta * (|DIFF[n]| - DEV[n-1])) + RTT[n] = RTT[n-1] + (alpha * DIFF[n]) + ATO[n] = MAX (MinTimeOut, MIN (RTT[n] + + (chi * DEV[n]), MaxTimeOut)) + + DIFF represents the error between the last estimated round-trip + time and the measured time. DIFF is calculated on each iteration. + + DEV is the estimated mean deviation. This approximates the + standard deviation. DEV is calculated on each iteration and + stored for use in the next iteration. Initially, it is set to 0. + + RTT is the estimated round-trip time of an average packet. RTT is + ycalculated on each iteration and stored for use in the next + iteration. Initially, it is set to PPD. + + ATO is the adaptive time-out for the next transmitted packet. ATO + is calculated on each iteration. Its value is limited, by the MIN + function, to be a maximum of the configured MaxTimeOut value. + + Alpha is the gain for the average and is typically 1/8 (0.125). + + Beta is the gain for the deviation and is typically 1/4 (0.250). + + Chi is the gain for the time-out and is typically set to 4. + + + + + + + + +Hamzeh, et al. Informational [Page 53] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + To eliminate division operations for fractional gain elements, the + entire set of equations can be scaled. With the suggested gain + constants, they should be scaled by 8 to eliminate all division. To + simplify calculations, all gain values are kept to powers of two so + that shift operations can be used in place of multiplication or + division. + +4.4.2. Congestion Control: Adjusting for Time-Out + + This section describes how the calculation of ATO is modified in the + case where a time-out does occur. When a time-out occurs, the time- + out value should be adjusted rapidly upward. Although the GRE + packets are not retransmitted when a time-out occurs, the time-out + should be adjusted up toward a maximum limit. To compensate for + shifting internetwork time delays, a strategy must be employed to + increase the time-out when it expires (notice that in addition to + increasing the time-out, we are also shrinking the size of the window + as described in the next section). For an interval in which a time- + out occurs, the new + ATO is calculated as: + + RTT[n] = delta * RTT[n-1] + DEV[n] = DEV[n-1] + ATO[n] = MAX (MinTimeOut, MIN (RTT[n] + + (chi * DEV[n]), MaxTimeOut)) + + In this calculation of ATO, only the two values that both contribute + to ATO and are stored for the next iteration are calculated. RTT is + scaled by delta, and DEV is unmodified. DIFF is not carried forward + and is not used in this scenario. A value of 2 for Delta, the time- + out gain factor for RTT, is suggested. + +5. Security Considerations + + The security of user data passed over the tunneled PPP connection is + addressed by PPP, as is authentication of the PPP peers. + + Because the PPTP control channel messages are neither authenticated + nor integrity protected, it might be possible for an attacker to + hijack the underlying TCP connection. It is also possible to + manufacture false control channel messages and alter genuine messages + in transit without detection. + + The GRE packets forming the tunnel itself are not cryptographically + protected. Because the PPP negotiations are carried out over the + tunnel, it may be possible for an attacker to eavesdrop on and modify + those negotiations. + + + + +Hamzeh, et al. Informational [Page 54] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + + Unless the PPP payload data is cryptographically protected, it can be + captured and read or modified. + +6. Authors' Addresses + + Kory Hamzeh + Ascend Communications + 1275 Harbor Bay Parkway + Alameda, CA 94502 + + EMail: kory@ascend.com + + + Gurdeep Singh Pall + Microsoft Corporation + Redmond, WA + + EMail: gurdeep@microsoft.com + + + William Verthein + U.S. Robotics/3Com + + + Jeff Taarud + Copper Mountain Networks + + + W. Andrew Little + ECI Telematics + + + Glen Zorn + Microsoft Corporation + Redmond, WA + + EMail: glennz@microsoft.com + + + + + + + + + + + + + + +Hamzeh, et al. Informational [Page 55] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +7. References + + [1] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing + Encapsulation (GRE)", RFC 1701, October 1994. + + [2] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic Routing + Encapsulation (GRE) over IPv4 Networks", RFC 1702, October 1994. + + [3] Lloyd, B. and W. Simpson, "PPP Authentication Protocols", RFC + 1334, October 1992. + + [4] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, + September 1981. + + [5] Postel, J., "User Data Protocol", STD 6, RFC 768, August 1980. + + [6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, + October 1994. See also: http://www.iana.org/numbers.html + + [7] Simpson, W., editor, "The Point-to-Point Protocol (PPP)", STD + 51, RFC 1661, July 1994. + + [8] Ethertype for PPP, Reserved with Xerox Corporation. + + [9] Simpson, W., "PPP Challenge Handshake Authentication Protocol + (CHAP)", RFC 1994, August 1996. + + [10] Blunk, L. and J Vollbrecht, "PPP Extensible Authentication + Protocol (EAP)", RFC 2284, March 1998. + + [11] Stevens, R., "TCP/IP Illustrated, Volume 1", p. 300, Addison- + Wesley, 1994. + + [12] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + + + + + + + + + + + + + + + +Hamzeh, et al. Informational [Page 56] + +RFC 2637 Point-to-Point Tunneling Protocol (PPTP) July 1999 + + +8. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Hamzeh, et al. Informational [Page 57] + diff --git a/doc/rfc2716.txt b/doc/rfc2716.txt new file mode 100644 index 00000000..71b4a84b --- /dev/null +++ b/doc/rfc2716.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group B. Aboba +Requests for Commments: 2716 D. Simon +Category: Experimental Microsoft + October 1999 + + + PPP EAP TLS Authentication Protocol + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1999). All Rights Reserved. + +1. Abstract + + The Point-to-Point Protocol (PPP) provides a standard method for + transporting multi-protocol datagrams over point-to-point links. PPP + also defines an extensible Link Control Protocol (LCP), which can be + used to negotiate authentication methods, as well as an Encryption + Control Protocol (ECP), used to negotiate data encryption over PPP + links, and a Compression Control Protocol (CCP), used to negotiate + compression methods. The Extensible Authentication Protocol (EAP) is + a PPP extension that provides support for additional authentication + methods within PPP. + + Transport Level Security (TLS) provides for mutual authentication, + integrity-protected ciphersuite negotiation and key exchange between + two endpoints. This document describes how EAP-TLS, which includes + support for fragmentation and reassembly, provides for these TLS + mechanisms within EAP. + +2. Introduction + + The Extensible Authentication Protocol (EAP), described in [5], + provides a standard mechanism for support of additional + authentication methods within PPP. Through the use of EAP, support + for a number of authentication schemes may be added, including smart + cards, Kerberos, Public Key, One Time Passwords, and others. To date + however, EAP methods such as [6] have focussed on authenticating a + client to a server. + + + + + +Aboba & Simon Experimental [Page 1] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + However, it may be desirable to support mutual authentication, and + since PPP encryption protocols such as [9] and [10] assume existence + of a session key, it is useful to have a mechanism for session key + establishment. Since design of secure key management protocols is + non-trivial, it is desirable to avoid creating new mechanisms for + this. The EAP protocol described in this document allows a PPP peer + to take advantage of the protected ciphersuite negotiation, mutual + authentication and key management capabilities of the TLS protocol, + described in [12]. + +2.1. Requirements language + + In this document, the key words "MAY", "MUST, "MUST NOT", "optional", + "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as + described in [11]. + +3. Protocol overview + +3.1. Overview of the EAP-TLS conversation + + As described in [5], the EAP-TLS conversation will typically begin + with the authenticator and the peer negotiating EAP. The + authenticator will then typically send an EAP-Request/Identity packet + to the peer, and the peer will respond with an EAP-Response/Identity + packet to the authenticator, containing the peer's userId. + + From this point forward, while nominally the EAP conversation occurs + between the PPP authenticator and the peer, the authenticator MAY act + as a passthrough device, with the EAP packets received from the peer + being encapsulated for transmission to a RADIUS server or backend + security server. In the discussion that follows, we will use the term + "EAP server" to denote the ultimate endpoint conversing with the + peer. + + Once having received the peer's Identity, the EAP server MUST respond + with an EAP-TLS/Start packet, which is an EAP-Request packet with + EAP-Type=EAP-TLS, the Start (S) bit set, and no data. The EAP-TLS + conversation will then begin, with the peer sending an EAP-Response + packet with EAP-Type=EAP-TLS. The data field of that packet will + encapsulate one or more TLS records in TLS record layer format, + containing a TLS client_hello handshake message. The current cipher + spec for the TLS records will be TLS_NULL_WITH_NULL_NULL and null + compression. This current cipher spec remains the same until the + change_cipher_spec message signals that subsequent records will have + the negotiated attributes for the remainder of the handshake. + + + + + + +Aboba & Simon Experimental [Page 2] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + The client_hello message contains the client's TLS version number, a + sessionId, a random number, and a set of ciphersuites supported by + the client. The version offered by the client MUST correspond to TLS + v1.0 or later. + + The EAP server will then respond with an EAP-Request packet with + EAP-Type=EAP-TLS. The data field of this packet will encapsulate one + or more TLS records. These will contain a TLS server_hello handshake + message, possibly followed by TLS certificate, server_key_exchange, + certificate_request, server_hello_done and/or finished handshake + messages, and/or a TLS change_cipher_spec message. The server_hello + handshake message contains a TLS version number, another random + number, a sessionId, and a ciphersuite. The version offered by the + server MUST correspond to TLS v1.0 or later. + + If the client's sessionId is null or unrecognized by the server, the + server MUST choose the sessionId to establish a new session; + otherwise, the sessionId will match that offered by the client, + indicating a resumption of the previously established session with + that sessionID. The server will also choose a ciphersuite from those + offered by the client; if the session matches the client's, then the + ciphersuite MUST match the one negotiated during the handshake + protocol execution that established the session. + + The purpose of the sessionId within the TLS protocol is to allow for + improved efficiency in the case where a client repeatedly attempts to + authenticate to an EAP server within a short period of time. While + this model was developed for use with HTTP authentication, it may + also have application to PPP authentication (e.g. multilink). + + As a result, it is left up to the peer whether to attempt to continue + a previous session, thus shortening the TLS conversation. Typically + the peer's decision will be made based on the time elapsed since the + previous authentication attempt to that EAP server. Based on the + sessionId chosen by the peer, and the time elapsed since the previous + authentication, the EAP server will decide whether to allow the + continuation, or whether to choose a new session. + + In the case where the EAP server and authenticator reside on the same + device, then client will only be able to continue sessions when + connecting to the same NAS or tunnel server. Should these devices be + set up in a rotary or round-robin then it may not be possible for the + peer to know in advance the authenticator it will be connecting to, + and therefore which sessionId to attempt to reuse. As a result, it is + likely that the continuation attempt will fail. In the case where the + EAP authentication is remoted then continuation is much more likely + to be successful, since multiple NAS devices and tunnel servers will + remote their EAP authentications to the same RADIUS server. + + + +Aboba & Simon Experimental [Page 3] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + If the EAP server is resuming a previously established session, then + it MUST include only a TLS change_cipher_spec message and a TLS + finished handshake message after the server_hello message. The + finished message contains the EAP server's authentication response to + the peer. If the EAP server is not resuming a previously established + session, then it MUST include a TLS server_certificate handshake + message, and a server_hello_done handshake message MUST be the last + handshake message encapsulated in this EAP-Request packet. + + The certificate message contains a public key certificate chain for + either a key exchange public key (such as an RSA or Diffie-Hellman + key exchange public key) or a signature public key (such as an RSA or + DSS signature public key). In the latter case, a TLS + server_key_exchange handshake message MUST also be included to allow + the key exchange to take place. + + The certificate_request message is included when the server desires + the client to authenticate itself via public key. While the EAP + server SHOULD require client authentication, this is not a + requirement, since it may be possible that the server will require + that the peer authenticate via some other means. + + The peer MUST respond to the EAP-Request with an EAP-Response packet + of EAP-Type=EAP-TLS. The data field of this packet will encapsulate + one or more TLS records containing a TLS change_cipher_spec message + and finished handshake message, and possibly certificate, + certificate_verify and/or client_key_exchange handshake messages. If + the preceding server_hello message sent by the EAP server in the + preceding EAP-Request packet indicated the resumption of a previous + session, then the peer MUST send only the change_cipher_spec and + finished handshake messages. The finished message contains the + peer's authentication response to the EAP server. + + If the preceding server_hello message sent by the EAP server in the + preceeding EAP-Request packet did not indicate the resumption of a + previous session, then the peer MUST send, in addition to the + change_cipher_spec and finished messages, a client_key_exchange + message, which completes the exchange of a shared master secret + between the peer and the EAP server. If the EAP server sent a + certificate_request message in the preceding EAP-Request packet, then + the peer MUST send, in addition, certificate and certificate_verify + handshake messages. The former contains a certificate for the peer's + signature public key, while the latter contains the peer's signed + authentication response to the EAP server. After receiving this + packet, the EAP server will verify the peer's certificate and digital + signature, if requested. + + + + + +Aboba & Simon Experimental [Page 4] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + If the peer's authentication is unsuccessful, the EAP server SHOULD + send an EAP-Request packet with EAP-Type=EAP-TLS, encapsulating a TLS + record containing the appropriate TLS alert message. The EAP server + SHOULD send a TLS alert message rather immediately terminating the + conversation so as to allow the peer to inform the user of the cause + of the failure and possibly allow for a restart of the conversation. + + To ensure that the peer receives the TLS alert message, the EAP + server MUST wait for the peer to reply with an EAP-Response packet. + The EAP-Response packet sent by the peer MAY encapsulate a TLS + client_hello handshake message, in which case the EAP server MAY + allow the EAP-TLS conversation to be restarted, or it MAY contain an + EAP-Response packet with EAP-Type=EAP-TLS and no data, in which case + the EAP-Server MUST send an EAP-Failure packet, and terminate the + conversation. It is up to the EAP server whether to allow restarts, + and if so, how many times the conversation can be restarted. An EAP + Server implementing restart capability SHOULD impose a limit on the + number of restarts, so as to protect against denial of service + attacks. + + If the peers authenticates successfully, the EAP server MUST respond + with an EAP-Request packet with EAP-Type=EAP-TLS, which includes, in + the case of a new TLS session, one or more TLS records containing TLS + change_cipher_spec and finished handshke messages. The latter + contains the EAP server's authentication response to the peer. The + peer will then verify the hash in order to authenticate the EAP + server. + + If the EAP server authenticates unsuccessfully, the peer MAY send an + EAP-Response packet of EAP-Type=EAP-TLS containing a TLS Alert + message identifying the reason for the failed authentication. The + peer MAY send a TLS alert message rather than immediately terminating + the conversation so as to allow the EAP server to log the cause of + the error for examination by the system administrator. + + To ensure that the EAP Server receives the TLS alert message, the + peer MUST wait for the EAP-Server to reply before terminating the + conversation. The EAP Server MUST reply with an EAP-Failure packet + since server authentication failure is a terminal condition. + + If the EAP server authenticates successfully, the peer MUST send an + EAP-Response packet of EAP-Type=EAP-TLS, and no data. The EAP-Server + then MUST respond with an EAP-Success message. + + + + + + + + +Aboba & Simon Experimental [Page 5] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + +3.2. Retry behavior + + As with other EAP protocols, the EAP server is responsible for retry + behavior. This means that if the EAP server does not receive a reply + from the peer, it MUST resend the EAP-Request for which it has not + yet received an EAP-Response. However, the peer MUST NOT resend EAP- + Response packets without first being prompted by the EAP server. + + For example, if the initial EAP-TLS start packet sent by the EAP + server were to be lost, then the peer would not receive this packet, + and would not respond to it. As a result, the EAP-TLS start packet + would be resent by the EAP server. Once the peer received the EAP-TLS + start packet, it would send an EAP-Response encapsulating the + client_hello message. If the EAP-Response were to be lost, then the + EAP server would resend the initial EAP-TLS start, and the peer would + resend the EAP-Response. + + As a result, it is possible that a peer will receive duplicate EAP- + Request messages, and may send duplicate EAP-Responses. Both the + peer and the EAP-Server should be engineered to handle this + possibility. + +3.3. Fragmentation + + A single TLS record may be up to 16384 octets in length, but a TLS + message may span multiple TLS records, and a TLS certificate message + may in principle be as long as 16MB. The group of EAP-TLS messages + sent in a single round may thus be larger than the PPP MTU size, the + maximum RADIUS packet size of 4096 octets, or even the Multilink + Maximum Received Reconstructed Unit (MRRU). As described in [2], the + multilink MRRU is negotiated via the Multilink MRRU LCP option, which + includes an MRRU length field of two octets, and thus can support + MRRUs as large as 64 KB. + + However, note that in order to protect against reassembly lockup and + denial of service attacks, it may be desirable for an implementation + to set a maximum size for one such group of TLS messages. Since a + typical certificate chain is rarely longer than a few thousand + octets, and no other field is likely to be anwhere near as long, a + reasonable choice of maximum acceptable message length might be 64 + KB. + + If this value is chosen, then fragmentation can be handled via the + multilink PPP fragmentation mechanisms described in [2]. While this + is desirable, there may be cases in which multilink or the MRRU LCP + option cannot be negotiated. As a result, an EAP-TLS implementation + MUST provide its own support for fragmentation and reassembly. + + + + +Aboba & Simon Experimental [Page 6] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + Since EAP is a simple ACK-NAK protocol, fragmentation support can be + added in a simple manner. In EAP, fragments that are lost or damaged + in transit will be retransmitted, and since sequencing information is + provided by the Identifier field in EAP, there is no need for a + fragment offset field as is provided in IPv4. + + EAP-TLS fragmentation support is provided through addition of a flags + octet within the EAP-Response and EAP-Request packets, as well as a + TLS Message Length field of four octets. Flags include the Length + included (L), More fragments (M), and EAP-TLS Start (S) bits. The L + flag is set to indicate the presence of the four octet TLS Message + Length field, and MUST be set for the first fragment of a fragmented + TLS message or set of messages. The M flag is set on all but the last + fragment. The S flag is set only within the EAP-TLS start message + sent from the EAP server to the peer. The TLS Message Length field is + four octets, and provides the total length of the TLS message or set + of messages that is being fragmented; this simplifies buffer + allocation. + + When an EAP-TLS peer receives an EAP-Request packet with the M bit + set, it MUST respond with an EAP-Response with EAP-Type=EAP-TLS and + no data. This serves as a fragment ACK. The EAP server MUST wait + until it receives the EAP-Response before sending another fragment. + In order to prevent errors in processing of fragments, the EAP server + MUST increment the Identifier field for each fragment contained + within an EAP-Request, and the peer MUST include this Identifier + value in the fragment ACK contained within the EAP-Reponse. + Retransmitted fragments will contain the same Identifier value. + + Similarly, when the EAP server receives an EAP-Response with the M + bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-TLS + and no data. This serves as a fragment ACK. The EAP peer MUST wait + until it receives the EAP-Request before sending another fragment. + In order to prevent errors in the processing of fragments, the EAP + server MUST use increment the Identifier value for each fragment ACK + contained within an EAP-Request, and the peer MUST include this + Identifier value in the subsequent fragment contained within an EAP- + Reponse. + +3.4. Identity verification + + As part of the TLS negotiation, the server presents a certificate to + the peer, and if mutual authentication is requested, the peer + presents a certificate to the server. + + Note that since the peer has made a claim of identity in the EAP- + Response/Identity (MyID) packet, the EAP server SHOULD verify that + the claimed identity corresponds to the certificate presented by the + + + +Aboba & Simon Experimental [Page 7] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + peer. Typically this will be accomplished either by placing the + userId within the peer certificate, or by providing a mapping between + the peer certificate and the userId using a directory service. + + Similarly, the peer MUST verify the validity of the EAP server + certificate, and SHOULD also examine the EAP server name presented in + the certificate, in order to determine whether the EAP server can be + trusted. Please note that in the case where the EAP authentication is + remoted that the EAP server will not reside on the same machine as + the authenticator, and therefore the name in the EAP server's + certificate cannot be expected to match that of the intended + destination. In this case, a more appropriate test might be whether + the EAP server's certificate is signed by a CA controlling the + intended destination and whether the EAP server exists within a + target sub-domain. + +3.5. Key derivation + + Since the normal TLS keys are used in the handshake, and therefore + should not be used in a different context, new encryption keys must + be derived from the TLS master secret for use with PPP encryption. + For both peer and EAP server, the derivation proceeds as follows: + given the master secret negotiated by the TLS handshake, the + pseudorandom function (PRF) defined in the specification for the + version of TLS in use, and the value random defined as the + concatenation of the handshake message fields client_hello.random and + server_hello.random (in that order), the value PRF(master secret, + "client EAP encryption", random) is computed up to 128 bytes, and the + value PRF("", "client EAP encryption", random) is computed up to 64 + bytes (where "" is an empty string). The peer encryption key (the + one used for encrypting data from peer to EAP server) is obtained by + truncating to the correct length the first 32 bytes of the first PRF + of these two output strings. TheEAP server encryption key (the one + used for encrypting data from EAP server to peer), if different from + the client encryption key, is obtained by truncating to the correct + length the second 32 bytes of this same PRF output string. The + client authentication key (the one used for computing MACs for + messages from peer to EAP server), if used, is obtained by truncating + to the correct length the third 32 bytes of this same PRF output + string. The EAP server authentication key (the one used for + computing MACs for messages from EAP server to peer), if used, and if + different from the peer authentication key, is obtained by truncating + to the correct length the fourth 32 bytes of this same PRF output + string. The peer initialization vector (IV), used for messages from + peer to EAP server if a block cipher has been specified, is obtained + by truncating to the cipher's block size the first 32 bytes of the + second PRF output string mentioned above. Finally, the server + initialization vector (IV), used for messages from peer to EAP server + + + +Aboba & Simon Experimental [Page 8] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + if a block cipher has been specified, is obtained by truncating to + the cipher's block size the second 32 bytes of this second PRF + output. + + The use of these encryption and authentication keys is specific to + the PPP encryption mechanism used, such as those defined in [9] and + [10]. Additional keys or other non-secret values (such as IVs) can + be obtained as needed for future PPP encryption methods by extending + the outputs of the PRF beyond 128 bytes and 64 bytes, respectively. + +3.6. ECP negotiation + + Since TLS supports ciphersuite negotiation, peers completing the TLS + negotiation will also have selected a ciphersuite, which includes key + strength, encryption and hashing methods. As a result, a subsequent + Encryption Control Protocol (ECP) conversation, if it occurs, has a + predetermined result. + + In order to ensure agreement between the EAP-TLS ciphersuite + negotiation and the subsequent ECP negotiation (described in [6]), + during ECP negotiation the PPP peer MUST offer only the ciphersuite + negotiated inEAP-TLS. This ensures that the PPP authenticator MUST + accept the EAP-TLS negotiated ciphersuite in order for the + onversation to proceed. Should the authenticator not accept the + EAP-TLS negotiated ciphersuite, then the peer MUST send an LCP + terminate and disconnect. + + Please note that it cannot be assumed that the PPP authenticator and + EAP server are located on the same machine or that the authenticator + understands the EAP-TLS conversation that has passed through it. Thus + if the peer offers a ciphersuite other than the one negotiated in + EAP-TLS there is no way for the authenticator to know how to respond + correctly. + +3.7. CCP negotiation + + TLS as described in [12] supports compression as well as ciphersuite + negotiation. However, TLS only provides support for a limited number + of compression types which do not overlap with the compression types + used in PPP. As a result, during the EAP-TLS conversation the EAP + endpoints MUST NOT request or negotiate compression. Instead, the PPP + Compression Control Protocol (CCP), described in [13] should be used + to negotiate the desired compression scheme. + + + + + + + + +Aboba & Simon Experimental [Page 9] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + +3.8. Examples + + In the case where the EAP-TLS mutual authentication is successful, + the conversation will appear as follows: + + Authenticating Peer Authenticator + ------------------- ------------- + <- PPP LCP Request-EAP + auth + PPP LCP ACK-EAP + auth -> + <- PPP EAP-Request/ + Identity + PPP EAP-Response/ + Identity (MyID) -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS Start) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS client_hello)-> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS server_hello, + TLS certificate, + [TLS server_key_exchange,] + [TLS certificate_request,] + TLS server_hello_done) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS certificate, + TLS client_key_exchange, + [TLS certificate_verify,] + TLS change_cipher_spec, + TLS finished) -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS change_cipher_spec, + TLS finished) + PPP EAP-Response/ + EAP-Type=EAP-TLS -> + <- PPP EAP-Success + PPP Authentication + Phase complete, + NCP Phase starts + + ECP negotiation + CCP negotiation + + + +Aboba & Simon Experimental [Page 10] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + In the case where the EAP-TLS mutual authentication is successful, + and fragmentation is required, the conversation will appear as + follows: + + Authenticating Peer Authenticator + ------------------- ------------- + <- PPP LCP Request-EAP + auth + PPP LCP ACK-EAP + auth -> + <- PPP EAP-Request/ + Identity + PPP EAP-Response/ + Identity (MyID) -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS Start, S bit set) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS client_hello)-> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS server_hello, + TLS certificate, + [TLS server_key_exchange,] + [TLS certificate_request,] + TLS server_hello_done) + (Fragment 1: L, M bits set) + PPP EAP-Response/ + EAP-Type=EAP-TLS -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (Fragment 2: M bit set) + PPP EAP-Response/ + EAP-Type=EAP-TLS -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (Fragment 3) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS certificate, + TLS client_key_exchange, + [TLS certificate_verify,] + TLS change_cipher_spec, + TLS inished)(Fragment 1: + L, M bits set)-> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + + + +Aboba & Simon Experimental [Page 11] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + PPP EAP-Response/ + EAP-Type=EAP-TLS + (Fragment 2)-> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS change_cipher_spec, + TLS finished) + PPP EAP-Response/ + EAP-Type=EAP-TLS -> + <- PPP EAP-Success + PPP Authentication + Phase complete, + NCP Phase starts + + ECP negotiation + CCP negotiation + + In the case where the server authenticates to the client + successfully, but the client fails to authenticate to the server, the + conversation will appear as follows: + + Authenticating Peer Authenticator + ------------------- ------------- + <- PPP LCP Request-EAP + auth + PPP LCP ACK-EAP + auth -> + <- PPP EAP-Request/ + Identity + PPP EAP-Response/ + Identity (MyID) -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS Start) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS client_hello)-> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS server_hello, + TLS certificate, + [TLS server_key_exchange,] + TLS certificate_request, + TLS server_hello_done) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS certificate, + TLS client_key_exchange, + + + +Aboba & Simon Experimental [Page 12] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + TLS certificate_verify, + TLS change_cipher_spec, + TLS finished) -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS change_cipher_spec, + TLS finished) + PPP EAP-Response/ + EAP-Type=EAP-TLS -> + <- PPP EAP-Request + EAP-Type=EAP-TLS + (TLS Alert message) + PPP EAP-Response/ + EAP-Type=EAP-TLS -> + <- PPP EAP-Failure + (User Disconnected) + + In the case where server authentication is unsuccessful, the + conversation will appear as follows: + + Authenticating Peer Authenticator + ------------------- ------------- + <- PPP LCP Request-EAP + auth + PPP LCP ACK-EAP + auth -> + <- PPP EAP-Request/ + Identity + PPP EAP-Response/ + Identity (MyID) -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS Start) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS client_hello)-> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS server_hello, + TLS certificate, + [TLS server_key_exchange,] + [TLS certificate_request,] + TLS server_hello_done) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS certificate, + TLS client_key_exchange, + [TLS certificate_verify,] + + + +Aboba & Simon Experimental [Page 13] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + TLS change_cipher_spec, + TLS finished) -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS change_cipher_spec, + TLS finished) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS change_cipher_spec, + TLS finished) + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS Alert message) -> + <- PPP EAP-Failure + (User Disconnected) + + In the case where a previously established session is being resumed, + and both sides authenticate successfully, the conversation will + appear as follows: + + Authenticating Peer Authenticator + ------------------- ------------- + <- PPP LCP Request-EAP + auth + PPP LCP ACK-EAP + auth -> + <- PPP EAP-Request/ + Identity + PPP EAP-Response/ + Identity (MyID) -> + <- PPP EAP-Request/ + EAP-Request/ + EAP-Type=EAP-TLS + (TLS Start) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS client_hello)-> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS server_hello, + TLS change_cipher_spec + TLS finished) + + + + + + + +Aboba & Simon Experimental [Page 14] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS change_cipher_spec, + TLS finished) -> + <- PPP EAP-Success + PPP Authentication + Phase complete, + NCP Phase starts + + ECP negotiation + + CCP negotiation + + In the case where a previously established session is being resumed, + and the server authenticates to the client successfully but the + client fails to authenticate to the server, the conversation will + appear as follows: + + Authenticating Peer Authenticator + ------------------- ------------- + <- PPP LCP Request-EAP + auth + PPP LCP ACK-EAP + auth -> + <- PPP EAP-Request/ + Identity + PPP EAP-Response/ + Identity (MyID) -> + <- PPP EAP-Request/ + EAP-Request/ + EAP-Type=EAP-TLS + (TLS Start) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS client_hello) -> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS server_hello, + TLS change_cipher_spec, + TLS finished) + PPP EA-Response/ + EAP-Type=EAP-TLS + (TLS change_cipher_spec, + TLS finished) -> + <- PPP EAP-Request + EAP-Type=EAP-TLS + (TLS Alert message) + + + + +Aboba & Simon Experimental [Page 15] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + PPP EAP-Response + EAP-Type=EAP-TLS -> + <- PPP EAP-Failure + (User Disconnected) + + In the case where a previously established session is being resumed, + and the server authentication is unsuccessful, the conversation will + appear as follows: + + Authenticating Peer Authenticator + ------------------- ------------- + <- PPP LCP Request-EAP + auth + PPP LCP ACK-EAP + auth -> + <- PPP EAP-Request/ + Identity + PPP EAP-Response/ + Identity (MyID) -> + <- PPP EAP-Request/ + EAP-Request/ + EAP-Type=EAP-TLS + (TLS Start) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS client_hello)-> + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + (TLS server_hello, + TLS change_cipher_spec, + TLS finished) + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS change_cipher_spec, + TLS finished) + <- PPP EAP-Request/ + EAP-Type=EAP-TLS + PPP EAP-Response/ + EAP-Type=EAP-TLS + (TLS Alert message) -> + <- PPP EAP-Failure + (User Disconnected) + + + + + + + + + +Aboba & Simon Experimental [Page 16] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + +4. Detailed description of the EAP-TLS protocol + +4.1. PPP EAP TLS Packet Format + + A summary of the PPP EAP TLS Request/Response packet format is shown + below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Data... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code + + 1 - Request + 2 - Response + + Identifier + + The identifier field is one octet and aids in matching responses + with requests. + + Length + + The Length field is two octets and indicates the length of the EAP + packet including the Code, Identifier, Length, Type, and Data + fields. Octets outside the range of the Length field should be + treated as Data Link Layer padding and should be ignored on + reception. + + Type + + 13 - EAP TLS + + Data + + The format of the Data field is determined by the Code field. + + + + + + + + + + + +Aboba & Simon Experimental [Page 17] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + +4.2. PPP EAP TLS Request Packet + + A summary of the PPP EAP TLS Request packet format is shown below. + The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Flags | TLS Message Length + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TLS Message Length | TLS Data... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code + + 1 + + Identifier + + The Identifier field is one octet and aids in matching responses + with requests. The Identifier field MUST be changed on each + Request packet. + + Length + + The Length field is two octets and indicates the length of the EAP + packet including the Code, Identifier, Length, Type, and TLS + Response fields. + + Type + + 13 - EAP TLS + + Flags + + 0 1 2 3 4 5 6 7 8 + +-+-+-+-+-+-+-+-+ + |L M S R R R R R| + +-+-+-+-+-+-+-+-+ + + L = Length included + M = More fragments + S = EAP-TLS start + R = Reserved + + + + + +Aboba & Simon Experimental [Page 18] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + The L bit (length included) is set to indicate the presence of the + four octet TLS Message Length field, and MUST be set for the first + fragment of a fragmented TLS message or set of messages. The M bit + (more fragments) is set on all but the last fragment. The S bit + (EAP-TLS start) is set in an EAP-TLS Start message. This + differentiates the EAP-TLS Start message from a fragment + acknowledgement. + + TLS Message Length + + The TLS Message Length field is four octets, and is present only + if the L bit is set. This field provides the total length of the + TLS message or set of messages that is being fragmented. + + TLS data + + The TLS data consists of the encapsulated TLS packet in TLS record + format. + +4.3. PPP EAP TLS Response Packet + + A summary of the PPP EAP TLS Response packet format is shown below. + The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Flags | TLS Message Length + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TLS Message Length | TLS Data... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Code + + 2 + + Identifier + + The Identifier field is one octet and MUST match the Identifier + field from the corresponding request. + + Length + + The Length field is two octets and indicates the length of the EAP + packet including the Code, Identifir, Length, Type, and TLS data + fields. + + + +Aboba & Simon Experimental [Page 19] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + Type + + 13 - EAP TLS + + Flags + + 0 1 2 3 4 5 6 7 8 + +-+-+-+-+-+-+-+-+ + |L M S R R R R R| + +-+-+-+-+-+-+-+-+ + + L = Length included + M = More fragments + S = EAP-TLS start + R = Reserved + + The L bit (length included) is set to indicate the presence of the + four octet TLS Message Length field, and MUST be set for the first + fragment of a fragmented TLS message or set of messages. The M bit + (more fragments) is set on all but the last fragment. The S bit + (EAP-TLS start) is set in an EAP-TLS Start message. This + differentiates the EAP-TLS Start message from a fragment + acknowledgement. + + TLS Message Length + + The TLS Message Length field is four octets, and is present only + if the L bit is set. This field provides the total length of the + TLS message or set of messages that is being fragmented. + + TLS data + + The TLS data consists of the encapsulated TLS packet in TLS record + format. + + + + + + + + + + + + + + + + + +Aboba & Simon Experimental [Page 20] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + +5. References + + [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD + 51, RFC 1661, July 1994. + + [2] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti, + "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. + + [3] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January + 1994. + + [4] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm", RFC + 1321, April 1992. + + [5] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication + Protocol (EAP)", RFC 2284, March 1998. + + [6] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June + 1996. + + [7] National Bureau of Standards, "Data Encryption Standard", FIPS + PUB 46 (January 1977). + + [8] National Bureau of Standards, "DES Modes of Operation", FIPS PUB + 81 (December 1980). + + [9] Sklower, K. amd G. Meyer, "The PPP DES Encryption Protocol, + Version 2 (DESE-bis)", RFC 2419, September 1998. + + [10] Hummert, K., "The PPP Triple-DES Encryption Protocol (3DESE)", + RFC 2420, September 1998. + + [11] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [12] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC + 2246, November 1998. + + [13] Rand, D., "The PPP Compression Control Protocol", RFC 1962, June + 1996. + + + + + + + + + + + +Aboba & Simon Experimental [Page 21] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + +6. Security Considerations + +6.1. Certificate revocation + + Since the EAP server is on the Internet during the EAP conversation, + the server is capable of following a certificate chain or verifying + whether the peer's certificate has been revoked. In contrast, the + peer may or may not have Internet connectivity, and thus while it can + validate the EAP server's certificate based on a pre-configured set + of CAs, it may not be able to follow a certificate chain or verify + whether the EAP server's certificate has been revoked. + + In the case where the peer is initiating a voluntary Layer 2 tunnel + using PPTP or L2TP, the peer will typically already have a PPP + interface and Internet connectivity established at the time of tunnel + initiation. As a result, during the EAP conversation it is capable + of checking for certificate revocation. + + However, in the case where the peer is initiating an intial PPP + conversation, it will not have Internet connectivity and is therefore + not capable of checking for certificate revocation until after NCP + negotiation completes and the peer has access to the Internet. In + this case, the peer SHOULD check for certificate revocation after + connecting to the Internet. + +6.2. Separation of the EAP server and PPP authenticator + + As a result of the EAP-TLS conversation, the EAP endpoints will + mutually authenticate, negotiate a ciphersuite, and derive a session + key for subsequent use in PPP encryption. Since the peer and EAP + client reside on the same machine, it is necessary for the EAP client + module to pass the session key to the PPP encryption module. + + The situation may be more complex on the PPP authenticator, which may + or may not reside on the same machine as the EAP server. In the case + where the EAP server and PPP authenticator reside on different + machines, there are several implications for security. Firstly, the + mutual authentication defined in EAP-TLS will occur between the peer + and the EAP server, not between the peer and the authenticator. This + means that as a result of the EAP-TLS conversation, it is not + possible for the peer to validate the identity of the NAS or tunnel + server that it is speaking to. + + The second issue is that the session key negotiated between the peer + and EAP server will need to be transmitted to the authenticator. + Therefore a mechanism needs to be provided to transmit the session + key from the EAP server to the authenticator or tunnel server that + needs to use the key. The specification of this transit mechanism is + + + +Aboba & Simon Experimental [Page 22] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + + outside the scope of this document. + +6.3. Relationship of PPP encryption to other security mechanisms + + It is envisaged that EAP-TLS will be used primarily with dialup PPP + connections. However, there are also circumstances in which PPP + encryption may be used along with Layer 2 tunneling protocols such as + PPTP and L2TP. + + In compulsory layer 2 tunneling, a PPP peer makes a connection to a + NAS or router which tunnels the PPP packets to a tunnel server. + Since with compulsory tunneling a PPP peer cannot tell whether its + packets are being tunneled, let alone whether the network device is + securing the tunnel, if security is required then the client must + make its own arrangements. In the case where all endpoints cannot be + relied upon to implement IPSEC, TLS, or another suitable security + protocol, PPP encryption provides a convenient means to ensure the + privacy of packets transiting between the client and the tunnel + server. + +7. Acknowledgments + + Thanks to Terence Spies, Glen Zorn and Narendra Gidwani of Microsoft + for useful discussions of this problem space. + +8. Authors' Addresses + + Bernard Aboba + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: 425-936-6605 + EMail: bernarda@microsoft.com + + + Dan Simon + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: 425-936-6711 + EMail: dansimon@microsoft.com + + + + + + + + +Aboba & Simon Experimental [Page 23] + +RFC 2716 PPP EAP TLS Authentication Protocol October 1999 + + +9. Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Aboba & Simon Experimental [Page 24] + diff --git a/doc/rfc2759.txt b/doc/rfc2759.txt new file mode 100644 index 00000000..60371c42 --- /dev/null +++ b/doc/rfc2759.txt @@ -0,0 +1,1123 @@ + + + + + + +Network Working Group G. Zorn +Request for Comments: 2759 Microsoft Corporation +Category: Informational January 2000 + + + Microsoft PPP CHAP Extensions, Version 2 + + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + The Point-to-Point Protocol (PPP) [1] provides a standard method for + transporting multi-protocol datagrams over point-to-point links. PPP + defines an extensible Link Control Protocol and a family of Network + Control Protocols (NCPs) for establishing and configuring different + network-layer protocols. + + This document describes version two of Microsoft's PPP CHAP dialect + (MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS- + CHAP version one (MS-CHAP-V1, described in [9]). In particular, + certain protocol fields have been deleted or reused but with + different semantics. In addition, MS-CHAP-V2 features mutual + authentication. + + The algorithms used in the generation of various MS-CHAP-V2 protocol + fields are described in section 8. Negotiation and hash generation + examples are provided in section 9. + +Specification of Requirements + + In this document, the key words "MAY", "MUST, "MUST NOT", "optional", + "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as + described in [3]. + + + + + + + + + +Zorn Informational [Page 1] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. LCP Configuration . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Challenge Packet . . . . . . . . . . . . . . . . . . . . . . . 3 + 4. Response Packet . . . . . . . . . . . . . . . . . . . . . . . . 4 + 5. Success Packet . . . . . . . . . . . . . . . . . . . . . . . . 4 + 6. Failure Packet . . . . . . . . . . . . . . . . . . . . . . . . 5 + 7. Change-Password Packet . . . . . . . . . . . . . . . . . . . . 6 + 8. Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 8.1. GenerateNTResponse() . . . . . . . . . . . . . . . . . . . . 7 + 8.2. ChallengeHash() . . . . . . . . . . . . . . . . . . . . . . . 8 + 8.3. NtPasswordHash() . . . . . . . . . . . . . . . . . . . . . . 9 + 8.4. HashNtPasswordHash() . . . . . . . . . . . . . . . . . . . . 9 + 8.5. ChallengeResponse() . . . . . . . . . . . . . . . . . . . . . 9 + 8.6. DesEncrypt() . . . . . . . . . . . . . . . . . . . . . . . . 10 + 8.7. GenerateAuthenticatorResponse() . . . . . . . . . . . . . . . 10 + 8.8. CheckAuthenticatorResponse() . . . . . . . . . . . . . . . . 12 + 8.9. NewPasswordEncryptedWithOldNtPasswordHash() . . . . . . . . . 12 + 8.10. EncryptPwBlockWithPasswordHash() . . . . . . . . . . . . . . 13 + 8.11. Rc4Encrypt() . . . . . . . . . . . . . . . . . . . . . . . . 13 + 8.12. OldNtPasswordHashEncryptedWithNewNtPasswordHash() . . . . . 14 + 8.13. NtPasswordHashEncryptedWithBlock() . . . . . . . . . . . . . 14 + 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 9.1. Negotiation Examples . . . . . . . . . . . . . . . . . . . . 14 + 9.1.1. Successful authentication . . . . . . . . . . . . . . . . . 15 + 9.1.2. Authenticator authentication failure . . . . . . . . . . . 15 + 9.1.3. Failed authentication with no retry allowed . . . . . . . . 15 + 9.1.4. Successful authentication after retry . . . . . . . . . . . 15 + 9.1.5. Failed hack attack with 3 attempts allowed . . . . . . . . 15 + 9.1.6. Successful authentication with password change . . . . . . 16 + 9.1.7. Successful authentication with retry and password change. . 16 + 9.2. Hash Example . . . . . . . . . . . . . . . . . . . . . . . . 16 + 9.3. Example of DES Key Generation . . . . . . . . . . . . . . . . 17 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 + 13. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19 + 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20 + + + + + + + + + + + + +Zorn Informational [Page 2] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +1. Introduction + + Where possible, MS-CHAP-V2 is consistent with both MS-CHAP-V1 and + standard CHAP. Briefly, the differences between MS-CHAP-V2 and MS- + CHAP-V1 are: + + * MS-CHAP-V2 is enabled by negotiating CHAP Algorithm 0x81 in LCP + option 3, Authentication Protocol. + + * MS-CHAP-V2 provides mutual authentication between peers by + piggybacking a peer challenge on the Response packet and an + authenticator response on the Success packet. + + * The calculation of the "Windows NT compatible challenge response" + sub-field in the Response packet has been changed to include the + peer challenge and the user name. + + * In MS-CHAP-V1, the "LAN Manager compatible challenge response" + sub-field was always sent in the Response packet. This field has + been replaced in MS-CHAP-V2 by the Peer-Challenge field. + + * The format of the Message field in the Failure packet has been + changed. + + * The Change Password (version 1) and Change Password (version 2) + packets are no longer supported. They have been replaced with a + single Change-Password packet. + +2. LCP Configuration + + The LCP configuration for MS-CHAP-V2 is identical to that for + standard CHAP, except that the Algorithm field has value 0x81, rather + than the MD5 value 0x05. PPP implementations which do not support + MS-CHAP-V2, but correctly implement LCP Config-Rej, should have no + problem dealing with this non-standard option. + +3. Challenge Packet + + The MS-CHAP-V2 Challenge packet is identical in format to the + standard CHAP Challenge packet. + + MS-CHAP-V2 authenticators send an 16-octet challenge Value field. + Peers need not duplicate Microsoft's algorithm for selecting the 16- + octet value, but the standard guidelines on randomness [1,2,7] SHOULD + be observed. + + Microsoft authenticators do not currently provide information in the + Name field. This may change in the future. + + + +Zorn Informational [Page 3] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +4. Response Packet + + The MS-CHAP-V2 Response packet is identical in format to the standard + CHAP Response packet. However, the Value field is sub-formatted + differently as follows: + + 16 octets: Peer-Challenge + 8 octets: Reserved, must be zero + 24 octets: NT-Response + 1 octet : Flags + + The Peer-Challenge field is a 16-octet random number. As the name + implies, it is generated by the peer and is used in the calculation + of the NT-Response field, below. Peers need not duplicate + Microsoft's algorithm for selecting the 16-octet value, but the + standard guidelines on randomness [1,2,7] SHOULD be observed. + + The NT-Response field is an encoded function of the password, the + user name, the contents of the Peer-Challenge field and the received + challenge as output by the routine GenerateNTResponse() (see section + 8.1, below). The Windows NT password is a string of 0 to + (theoretically) 256 case-sensitive Unicode [8] characters. Current + versions of Windows NT limit passwords to 14 characters, mainly for + compatibility reasons; this may change in the future. When computing + the NT-Response field contents, only the user name is used, without + any associated Windows NT domain name. This is true regardless of + whether a Windows NT domain name is present in the Name field (see + below). + + The Flag field is reserved for future use and MUST be zero. + + The Name field is a string of 0 to (theoretically) 256 case-sensitive + ASCII characters which identifies the peer's user account name. The + Windows NT domain name may prefix the user's account name (e.g. + "BIGCO\johndoe" where "BIGCO" is a Windows NT domain containing the + user account "johndoe"). If a domain is not provided, the backslash + should also be omitted, (e.g. "johndoe"). + +5. Success Packet + + The Success packet is identical in format to the standard CHAP + Success packet. However, the Message field contains a 42-octet + authenticator response string and a printable message. The format of + the message field is illustrated below. + + "S=<auth_string> M=<message>" + + + + + +Zorn Informational [Page 4] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + + The <auth_string> quantity is a 20 octet number encoded in ASCII as + 40 hexadecimal digits. The hexadecimal digits A-F (if present) MUST + be uppercase. This number is derived from the challenge from the + Challenge packet, the Peer-Challenge and NT-Response fields from the + Response packet, and the peer password as output by the routine + GenerateAuthenticatorResponse() (see section 8.7, below). The + authenticating peer MUST verify the authenticator response when a + Success packet is received. The method for verifying the + authenticator is described in section 8.8, below. If the + authenticator response is either missing or incorrect, the peer MUST + end the session. + + The <message> quantity is human-readable text in the appropriate + charset and language [12]. + +6. Failure Packet + + The Failure packet is identical in format to the standard CHAP + Failure packet. There is, however, formatted text stored in the + Message field which, contrary to the standard CHAP rules, does affect + the operation of the protocol. The Message field format is: + + "E=eeeeeeeeee R=r C=cccccccccccccccccccccccccccccccc V=vvvvvvvvvv +M=<msg>" + + where + + The "eeeeeeeeee" is the ASCII representation of a decimal error + code (need not be 10 digits) corresponding to one of those listed + below, though implementations should deal with codes not on this + list gracefully. + + 646 ERROR_RESTRICTED_LOGON_HOURS + 647 ERROR_ACCT_DISABLED + 648 ERROR_PASSWD_EXPIRED + 649 ERROR_NO_DIALIN_PERMISSION + 691 ERROR_AUTHENTICATION_FAILURE + 709 ERROR_CHANGING_PASSWORD + + The "r" is an ASCII flag set to '1' if a retry is allowed, and '0' + if not. When the authenticator sets this flag to '1' it disables + short timeouts, expecting the peer to prompt the user for new + credentials and resubmit the response. + + The "cccccccccccccccccccccccccccccccc" is the ASCII representation + of a hexadecimal challenge value. This field MUST be exactly 32 + octets long and MUST be present. + + + + +Zorn Informational [Page 5] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + + The "vvvvvvvvvv" is the ASCII representation of a decimal version + code (need not be 10 digits) indicating the password changing + protocol version supported on the server. For MS-CHAP-V2, this + value SHOULD always be 3. + + <msg> is human-readable text in the appropriate charset and + language [12]. + +7. Change-Password Packet + + The Change-Password packet does not appear in either standard CHAP or + MS-CHAP-V1. It allows the peer to change the password on the account + specified in the preceding Response packet. The Change-Password + packet should be sent only if the authenticator reports + ERROR_PASSWD_EXPIRED (E=648) in the Message field of the Failure + packet. + + This packet type is supported by recent versions of Windows NT 4.0, + Windows 95 and Windows 98. It is not supported by Windows NT 3.5, + Windows NT 3.51, or early versions of Windows NT 4.0, Windows 95 and + Windows 98. + + The format of this packet is as follows: + + 1 octet : Code + 1 octet : Identifier + 2 octets : Length + 516 octets : Encrypted-Password + 16 octets : Encrypted-Hash + 16 octets : Peer-Challenge + 8 octets : Reserved + 24 octets : NT-Response + 2-octet : Flags + + Code + 7 + + Identifier + The Identifier field is one octet and aids in matching requests + and replies. The value is the Identifier of the received Failure + packet to which this packet responds plus 1. + + Length + 586 + + + + + + + +Zorn Informational [Page 6] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + + Encrypted-Password + This field contains the PWBLOCK form of the new Windows NT + password encrypted with the old Windows NT password hash, as + output by the NewPasswordEncryptedWithOldNtPasswordHash() routine + (see section 8.9, below). + + Encrypted-Hash + This field contains the old Windows NT password hash encrypted + with the new Windows NT password hash, as output by the + OldNtPasswordHashEncryptedWithNewNtPasswordHash() routine (see + section 8.12, below). + + Peer-Challenge + A 16-octet random quantity, as described in the Response packet + description. + + Reserved + 8 octets, must be zero. + + NT-Response + The NT-Response field (as described in the Response packet + description), but calculated on the new password and the challenge + received in the Failure packet. + + Flags + This field is two octets in length. It is a bit field of option + flags where 0 is the least significant bit of the 16-bit quantity. + The format of this field is illustrated in the following diagram: + + 1 + 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Bits 0-15 + Reserved, always clear (0). + +8. Pseudocode + + The routines mentioned in the text above are described in pseudocode + in the following sections. + +8.1. GenerateNTResponse() + + GenerateNTResponse( + IN 16-octet AuthenticatorChallenge, + IN 16-octet PeerChallenge, + + + +Zorn Informational [Page 7] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + + IN 0-to-256-char UserName, + + IN 0-to-256-unicode-char Password, + OUT 24-octet Response ) + { + 8-octet Challenge + 16-octet PasswordHash + + ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName, + giving Challenge) + + NtPasswordHash( Password, giving PasswordHash ) + ChallengeResponse( Challenge, PasswordHash, giving Response ) + } + +8.2. ChallengeHash() + + ChallengeHash( + IN 16-octet PeerChallenge, + IN 16-octet AuthenticatorChallenge, + IN 0-to-256-char UserName, + OUT 8-octet Challenge + { + + /* + * SHAInit(), SHAUpdate() and SHAFinal() functions are an + * implementation of Secure Hash Algorithm (SHA-1) [11]. These are + * available in public domain or can be licensed from + * RSA Data Security, Inc. + */ + + SHAInit(Context) + SHAUpdate(Context, PeerChallenge, 16) + SHAUpdate(Context, AuthenticatorChallenge, 16) + + /* + * Only the user name (as presented by the peer and + * excluding any prepended domain name) + * is used as input to SHAUpdate(). + */ + + SHAUpdate(Context, UserName, strlen(Username)) + SHAFinal(Context, Digest) + memcpy(Challenge, Digest, 8) + } + + + + + + +Zorn Informational [Page 8] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +8.3. NtPasswordHash() + + NtPasswordHash( + IN 0-to-256-unicode-char Password, + OUT 16-octet PasswordHash ) + { + /* + * Use the MD4 algorithm [5] to irreversibly hash Password + * into PasswordHash. Only the password is hashed without + * including any terminating 0. + */ + } + +8.4. HashNtPasswordHash() + + HashNtPasswordHash( + IN 16-octet PasswordHash, + OUT 16-octet PasswordHashHash ) + { + /* + * Use the MD4 algorithm [5] to irreversibly hash + * PasswordHash into PasswordHashHash. + */ + } + +8.5. ChallengeResponse() + + ChallengeResponse( + IN 8-octet Challenge, + IN 16-octet PasswordHash, + OUT 24-octet Response ) + { + Set ZPasswordHash to PasswordHash zero-padded to 21 octets + + DesEncrypt( Challenge, + 1st 7-octets of ZPasswordHash, + giving 1st 8-octets of Response ) + + DesEncrypt( Challenge, + 2nd 7-octets of ZPasswordHash, + giving 2nd 8-octets of Response ) + + DesEncrypt( Challenge, + 3rd 7-octets of ZPasswordHash, + giving 3rd 8-octets of Response ) + } + + + + + +Zorn Informational [Page 9] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +8.6. DesEncrypt() + + DesEncrypt( + IN 8-octet Clear, + IN 7-octet Key, + OUT 8-octet Cypher ) + { + /* + * Use the DES encryption algorithm [4] in ECB mode [10] + * to encrypt Clear into Cypher such that Cypher can + * only be decrypted back to Clear by providing Key. + * Note that the DES algorithm takes as input a 64-bit + * stream where the 8th, 16th, 24th, etc. bits are + * parity bits ignored by the encrypting algorithm. + * Unless you write your own DES to accept 56-bit input + * without parity, you will need to insert the parity bits + * yourself. + */ + } + +8.7. GenerateAuthenticatorResponse() + + GenerateAuthenticatorResponse( + IN 0-to-256-unicode-char Password, + IN 24-octet NT-Response, + IN 16-octet PeerChallenge, + IN 16-octet AuthenticatorChallenge, + IN 0-to-256-char UserName, + OUT 42-octet AuthenticatorResponse ) + { + 16-octet PasswordHash + 16-octet PasswordHashHash + 8-octet Challenge + + /* + * "Magic" constants used in response generation + */ + + Magic1[39] = + {0x4D, 0x61, 0x67, 0x69, 0x63, 0x20, 0x73, 0x65, 0x72, 0x76, + 0x65, 0x72, 0x20, 0x74, 0x6F, 0x20, 0x63, 0x6C, 0x69, 0x65, + 0x6E, 0x74, 0x20, 0x73, 0x69, 0x67, 0x6E, 0x69, 0x6E, 0x67, + 0x20, 0x63, 0x6F, 0x6E, 0x73, 0x74, 0x61, 0x6E, 0x74}; + + + + + + + + +Zorn Informational [Page 10] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + + Magic2[41] = + {0x50, 0x61, 0x64, 0x20, 0x74, 0x6F, 0x20, 0x6D, 0x61, 0x6B, + 0x65, 0x20, 0x69, 0x74, 0x20, 0x64, 0x6F, 0x20, 0x6D, 0x6F, + 0x72, 0x65, 0x20, 0x74, 0x68, 0x61, 0x6E, 0x20, 0x6F, 0x6E, + 0x65, 0x20, 0x69, 0x74, 0x65, 0x72, 0x61, 0x74, 0x69, 0x6F, + 0x6E}; + + /* + * Hash the password with MD4 + */ + + NtPasswordHash( Password, giving PasswordHash ) + + /* + * Now hash the hash + */ + + HashNtPasswordHash( PasswordHash, giving PasswordHashHash) + + SHAInit(Context) + SHAUpdate(Context, PasswordHashHash, 16) + SHAUpdate(Context, NTResponse, 24) + SHAUpdate(Context, Magic1, 39) + SHAFinal(Context, Digest) + + ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName, + giving Challenge) + + SHAInit(Context) + SHAUpdate(Context, Digest, 20) + SHAUpdate(Context, Challenge, 8) + SHAUpdate(Context, Magic2, 41) + SHAFinal(Context, Digest) + + /* + * Encode the value of 'Digest' as "S=" followed by + * 40 ASCII hexadecimal digits and return it in + * AuthenticatorResponse. + * For example, + * "S=0123456789ABCDEF0123456789ABCDEF01234567" + */ + + } + + + + + + + + +Zorn Informational [Page 11] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +8.8. CheckAuthenticatorResponse() + + CheckAuthenticatorResponse( + IN 0-to-256-unicode-char Password, + IN 24-octet NtResponse, + IN 16-octet PeerChallenge, + IN 16-octet AuthenticatorChallenge, + IN 0-to-256-char UserName, + IN 42-octet ReceivedResponse, + OUT Boolean ResponseOK ) + { + + 20-octet MyResponse + + set ResponseOK = FALSE + GenerateAuthenticatorResponse( Password, NtResponse, PeerChallenge, + AuthenticatorChallenge, UserName, + giving MyResponse) + + if (MyResponse = ReceivedResponse) then set ResponseOK = TRUE + return ResponseOK + } + +8.9. NewPasswordEncryptedWithOldNtPasswordHash() + + datatype-PWBLOCK + { + 256-unicode-char Password + 4-octets PasswordLength + } + + NewPasswordEncryptedWithOldNtPasswordHash( + IN 0-to-256-unicode-char NewPassword, + IN 0-to-256-unicode-char OldPassword, + OUT datatype-PWBLOCK EncryptedPwBlock ) + { + NtPasswordHash( OldPassword, giving PasswordHash ) + + EncryptPwBlockWithPasswordHash( NewPassword, + PasswordHash, + giving EncryptedPwBlock ) + } + + + + + + + + + +Zorn Informational [Page 12] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +8.10. EncryptPwBlockWithPasswordHash() + + EncryptPwBlockWithPasswordHash( + IN 0-to-256-unicode-char Password, + IN 16-octet PasswordHash, + OUT datatype-PWBLOCK PwBlock ) + { + + Fill ClearPwBlock with random octet values + + PwSize = lstrlenW( Password ) * sizeof( unicode-char ) + PwOffset = sizeof( ClearPwBlock.Password ) - PwSize + Move PwSize octets to (ClearPwBlock.Password + PwOffset ) from + Password + ClearPwBlock.PasswordLength = PwSize + Rc4Encrypt( ClearPwBlock, + sizeof( ClearPwBlock ), + PasswordHash, + sizeof( PasswordHash ), + giving PwBlock ) + } + +8.11. Rc4Encrypt() + + Rc4Encrypt( + IN x-octet Clear, + IN integer ClearLength, + IN y-octet Key, + IN integer KeyLength, + OUT x-octet Cypher ) + { + /* + * Use the RC4 encryption algorithm [6] to encrypt Clear of + * length ClearLength octets into a Cypher of the same length + * such that the Cypher can only be decrypted back to Clear + * by providing a Key of length KeyLength octets. + */ + } + + + + + + + + + + + + + +Zorn Informational [Page 13] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +8.12. OldNtPasswordHashEncryptedWithNewNtPasswordHash() + + OldNtPasswordHashEncryptedWithNewNtPasswordHash( + IN 0-to-256-unicode-char NewPassword, + IN 0-to-256-unicode-char OldPassword, + OUT 16-octet EncryptedPasswordHash ) + { + NtPasswordHash( OldPassword, giving OldPasswordHash ) + NtPasswordHash( NewPassword, giving NewPasswordHash ) + NtPasswordHashEncryptedWithBlock( OldPasswordHash, + NewPasswordHash, + giving EncryptedPasswordHash ) + } + +8.13. NtPasswordHashEncryptedWithBlock() + + NtPasswordHashEncryptedWithBlock( + IN 16-octet PasswordHash, + IN 16-octet Block, + OUT 16-octet Cypher ) + { + DesEncrypt( 1st 8-octets PasswordHash, + 1st 7-octets Block, + giving 1st 8-octets Cypher ) + + DesEncrypt( 2nd 8-octets PasswordHash, + 2nd 7-octets Block, + giving 2nd 8-octets Cypher ) + } + +9. Examples + + The following sections include protocol negotiation and hash + generation examples. + +9.1. Negotiation Examples + + Here are some examples of typical negotiations. The peer is on the + left and the authenticator is on the right. + + The packet sequence ID is incremented on each authentication retry + response and on the change password response. All cases where the + packet sequence ID is updated are noted below. + + Response retry is never allowed after Change Password. Change + Password may occur after response retry. + + + + + +Zorn Informational [Page 14] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +9.1.1. Successful authentication + + <- Authenticator Challenge + Peer Response/Challenge -> + <- Success/Authenticator Response + + (Authenticator Response verification succeeds, call continues) + +9.1.2. Authenticator authentication failure + + <- Authenticator Challenge + Peer Response/Challenge -> + <- Success/Authenticator Response + + (Authenticator Response verification fails, peer disconnects) + +9.1.3. Failed authentication with no retry allowed + + <- Authenticator Challenge + Peer Response/Challenge -> + <- Failure (E=691 R=0) + + (Authenticator disconnects) + +9.1.4. Successful authentication after retry + + <- Authenticator Challenge + Peer Response/Challenge -> + <- Failure (E=691 R=1), disable short timeout + Response (++ID) to challenge in failure message -> + <- Success/Authenticator Response + + (Authenticator Response verification succeeds, call continues) + +9.1.5. Failed hack attack with 3 attempts allowed + + <- Authenticator Challenge + Peer Response/Challenge -> + <- Failure (E=691 R=1), disable short timeout + Response (++ID) to challenge in Failure message -> + <- Failure (E=691 R=1), disable short timeout + Response (++ID) to challenge in Failure message -> + <- Failure (E=691 R=0) + + + + + + + + +Zorn Informational [Page 15] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +9.1.6. Successful authentication with password change + + <- Authenticator Challenge + Peer Response/Challenge -> + <- Failure (E=648 R=0 V=3), disable short + timeout + ChangePassword (++ID) to challenge in Failure message -> + <- Success/Authenticator Response + + (Authenticator Response verification succeeds, call continues) + +9.1.7. Successful authentication with retry and password change + + <- Authenticator Challenge + Peer Response/Challenge -> + <- Failure (E=691 R=1), disable short timeout + Response (++ID) to first challenge+23 -> + <- Failure (E=648 R=0 V=2), disable short + timeout + ChangePassword (++ID) to first challenge+23 -> + <- Success/Authenticator Response + + (Authenticator Response verification succeeds, call continues) + +9.2. Hash Example + + Intermediate values for user name "User" and password "clientPass". + All numeric values are hexadecimal. + +0-to-256-char UserName: +55 73 65 72 + +0-to-256-unicode-char Password: +63 00 6C 00 69 00 65 00 6E 00 74 00 50 00 61 00 73 00 73 00 + +16-octet AuthenticatorChallenge: +5B 5D 7C 7D 7B 3F 2F 3E 3C 2C 60 21 32 26 26 28 + +16-octet PeerChallenge: +21 40 23 24 25 5E 26 2A 28 29 5F 2B 3A 33 7C 7E + +8-octet Challenge: +D0 2E 43 86 BC E9 12 26 + +16-octet PasswordHash: +44 EB BA 8D 53 12 B8 D6 11 47 44 11 F5 69 89 AE + + + + + +Zorn Informational [Page 16] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +24 octet NT-Response: +82 30 9E CD 8D 70 8B 5E A0 8F AA 39 81 CD 83 54 42 33 11 4A 3D 85 D6 DF + +16-octet PasswordHashHash: +41 C0 0C 58 4B D2 D9 1C 40 17 A2 A1 2F A5 9F 3F + +42-octet AuthenticatorResponse: +"S=407A5589115FD0D6209F510FE9C04566932CDA56" + +9.3. Example of DES Key Generation + + DES uses 56-bit keys, expanded to 64 bits by the insertion of parity + bits. After the parity of the key has been fixed, every eighth bit + is a parity bit and the number of bits that are set (1) in each octet + is odd; i.e., odd parity. Note that many DES engines do not check + parity, however, simply stripping the parity bits. The following + example illustrates the values resulting from the use of the password + "MyPw" to generate a pair of DES keys (e.g., for use in the + NtPasswordHashEncryptedWithBlock() described in section 8.13). + + 0-to-256-unicode-char Password: + 4D 79 50 77 + + 16-octet PasswordHash: + FC 15 6A F7 ED CD 6C 0E DD E3 33 7D 42 7F 4E AC + + First "raw" DES key (initial 7 octets of password hash): + FC 15 6A F7 ED CD 6C + + First parity-corrected DES key (eight octets): + FD 0B 5B 5E 7F 6E 34 D9 + + Second "raw" DES key (second 7 octets of password hash) + 0E DD E3 33 7D 42 7F + + Second parity-corrected DES key (eight octets): + 0E 6E 79 67 37 EA 08 FE + +10. Security Considerations + + As an implementation detail, the authenticator SHOULD limit the + number of password retries allowed to make brute-force password + guessing attacks more difficult. + + + + + + + + +Zorn Informational [Page 17] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +11. References + + [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC + 1661, July 1994. + + [2] Simpson, W., "PPP Challenge Handshake Authentication Protocol + (CHAP)", RFC 1994, August 1996. + + [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [4] "Data Encryption Standard (DES)", Federal Information Processing + Standard Publication 46-2, National Institute of Standards and + Technology, December 1993. + + [5] Rivest, R., "MD4 Message Digest Algorithm", RFC 1320, April + 1992. + + [6] RC4 is a proprietary encryption algorithm available under + license from RSA Data Security Inc. For licensing information, + contact: + + RSA Data Security, Inc. + 100 Marine Parkway + Redwood City, CA 94065-1031 + + [7] Eastlake, D., Crocker, S. and J. Schiller, "Randomness + Recommendations for Security", RFC 1750, December 1994. + + [8] "The Unicode Standard, Version 2.0", The Unicode Consortium, + Addison-Wesley, 1996. ISBN 0-201-48345-9. + + [9] Zorn, G. and Cobb, S., "Microsoft PPP CHAP Extensions", RFC + 2433, October 1998. + + [10] "DES Modes of Operation", Federal Information Processing + Standards Publication 81, National Institute of Standards and + Technology, December 1980. + + [11] "Secure Hash Standard", Federal Information Processing Standards + Publication 180-1, National Institute of Standards and + Technology, April 1995. + + [12] Zorn, G., "PPP LCP Internationalization Configuration Option", + RFC 2484, January 1999. + + + + + + +Zorn Informational [Page 18] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +12. Acknowledgements + + Thanks (in no particular order) to Bruce Johnson, Tony Bell, Paul + Leach, Terence Spies, Dan Simon, Narendra Gidwani, Gurdeep Singh + Pall, Jody Terrill, Brad Robel-Forrest, and Joe Davies for useful + suggestions and feedback. + +13. Author's Address + + Questions about this memo can also be directed to: + + Glen Zorn + Microsoft Corporation + One Microsoft Way + Redmond, Washington 98052 + + Phone: +1 425 703 1559 + Fax: +1 425 936 7329 + EMail: gwz@acm.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 19] + +RFC 2759 Microsoft MS-CHAP-V2 January 2000 + + +14. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Zorn Informational [Page 20] + diff --git a/doc/rfc3078.txt b/doc/rfc3078.txt new file mode 100644 index 00000000..5bbcc130 --- /dev/null +++ b/doc/rfc3078.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group G. Pall +Request for Comments: 3078 Microsoft Corporation +Category: Informational G. Zorn +Updates: 2118 cisco Systems + March 2001 + + + Microsoft Point-To-Point Encryption (MPPE) Protocol + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + The Point-to-Point Protocol (PPP) provides a standard method for + transporting multi-protocol datagrams over point-to-point links. + + The PPP Compression Control Protocol provides a method to negotiate + and utilize compression protocols over PPP encapsulated links. + + This document describes the use of the Microsoft Point to Point + Encryption (MPPE) to enhance the confidentiality of PPP-encapsulated + packets. + +Specification of Requirements + + In this document, the key words "MAY", "MUST, "MUST NOT", "optional", + "recommended", "SHOULD", and "SHOULD NOT" are to be interpreted as + described in [5]. + +1. Introduction + + The Microsoft Point to Point Encryption scheme is a means of + representing Point to Point Protocol (PPP) packets in an encrypted + form. + + MPPE uses the RSA RC4 [3] algorithm to provide data confidentiality. + The length of the session key to be used for initializing encryption + tables can be negotiated. MPPE currently supports 40-bit and 128-bit + session keys. + + + + +Pall & Zorn Informational [Page 1] + +RFC 3078 MPPE Protocol March 2001 + + + MPPE session keys are changed frequently; the exact frequency depends + upon the options negotiated, but may be every packet. + + MPPE is negotiated within option 18 [4] in the Compression Control + Protocol. + +2. Configuration Option Format + + + Description + + The CCP Configuration Option negotiates the use of MPPE on the + link. By default (i.e., if the negotiation of MPPE is not + attempted), no encryption is used. If, however, MPPE negotiation + is attempted and fails, the link SHOULD be terminated. + + A summary of the CCP Configuration Option format is shown below. The + fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Supported Bits | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Supported Bits | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 18 + + Length + + 6 + + Supported Bits + + This field is 4 octets, most significant octet first. + + 3 2 1 + 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | |H| |M|S|L|D| |C| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + +Pall & Zorn Informational [Page 2] + +RFC 3078 MPPE Protocol March 2001 + + + The 'C' bit is used by MPPC [4] and is not discussed further in this + memo. The 'D' bit is obsolete; although some older peers may attempt + to negotiate this option, it SHOULD NOT be accepted. If the 'L' bit + is set (corresponding to a value of 0x20 in the least significant + octet), this indicates the desire of the sender to negotiate the use + of 40-bit session keys. If the 'S' bit is set (corresponding to a + value of 0x40 in the least significant octet), this indicates the + desire of the sender to negotiate the use of 128-bit session keys. + If the 'M' bit is set (corresponding to a value of 0x80 in the least + significant octet), this indicates the desire of the sender to + negotiate the use of 56-bit session keys. If the 'H' bit is set + (corresponding to a value of 0x01 in the most significant octet), + this indicates that the sender wishes to negotiate the use of + stateless mode, in which the session key is changed after the + transmission of each packet (see section 10, below). In the + following discussion, the 'S', 'M' and 'L' bits are sometimes + referred to collectively as "encryption options". + + All other bits are reserved and MUST be set to 0. + +2.1. Option Negotiation + + MPPE options are negotiated as described in [2]. In particular, the + negotiation initiator SHOULD request all of the options it supports. + The responder SHOULD NAK with a single encryption option (note that + stateless mode may always be negotiated, independent of and in + addition to an encryption option). If the responder supports more + than one encryption option in the set requested by the initiator, the + option selected SHOULD be the "strongest" option offered. + Informally, the strength of the MPPE encryption options may be + characterized as follows: + + STRONGEST + 128-bit encryption ('S' bit set) + 56-bit encryption ('M' bit set) + 40-bit encryption ('L' bit set) + WEAKEST + + This characterization takes into account the generally accepted + strength of the cipher. + + The initiator SHOULD then either send another request containing the + same option(s) as the responder's NAK or cancel the negotiation, + dropping the connection. + + + + + + + +Pall & Zorn Informational [Page 3] + +RFC 3078 MPPE Protocol March 2001 + + +3. MPPE Packets + + Before any MPPE packets are transmitted, PPP MUST reach the Network- + Layer Protocol phase and the CCP Control Protocol MUST reach the + Opened state. + + Exactly one MPPE datagram is encapsulated in the PPP Information + field. The PPP Protocol field indicates type 0x00FD for all + encrypted datagrams. + + The maximum length of the MPPE datagram transmitted over a PPP link + is the same as the maximum length of the Information field of a PPP + encapsulated packet. + + Only packets with PPP Protocol numbers in the range 0x0021 to 0x00FA + are encrypted. Other packets are not passed thru the MPPE processor + and are sent with their original PPP Protocol numbers. + + Padding + + It is recommended that padding not be used with MPPE. If the + sender uses padding it MUST negotiate the Self-Describing- + Padding Configuration option [10] during LCP phase and use + self-describing pads. + + Reliability and Sequencing + + The MPPE scheme does not require a reliable link. Instead, it + relies on a 12-bit coherency count in each packet to keep the + encryption tables synchronized. If stateless mode has not been + negotiated and the coherency count in the received packet does + not match the expected count, the receiver MUST send a CCP + Reset-Request packet to cause the resynchronization of the RC4 + tables. + + MPPE expects packets to be delivered in sequence. + + MPPE MAY be used over a reliable link, as described in "PPP + Reliable Transmission" [6], but this typically just adds + unnecessary overhead since only the coherency count is + required. + + Data Expansion + + The MPPE scheme does not expand or compress data. The number + of octets input to and output from the MPPE processor are the + same. + + + + +Pall & Zorn Informational [Page 4] + +RFC 3078 MPPE Protocol March 2001 + + +3.1. Packet Format + + A summary of the MPPE packet format is shown below. The fields are + transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PPP Protocol |A|B|C|D| Coherency Count | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Encrypted Data... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + PPP Protocol + + The PPP Protocol field is described in the Point-to-Point + Protocol Encapsulation [1]. + + When MPPE is successfully negotiated by the PPP Compression + Control Protocol, the value of this field is 0x00FD. This + value MAY be compressed when Protocol-Field-Compression is + negotiated. + + Bit A + + This bit indicates that the encryption tables were initialized + before this packet was generated. The receiver MUST re- + initialize its tables with the current session key before + decrypting this packet. This bit is referred to as the FLUSHED + bit in this document. If the stateless option has been + negotiated, this bit MUST be set on every encrypted packet. + Note that MPPC and MPPE both recognize the FLUSHED bit; + therefore, if the stateless option is negotiated, it applies to + both MPPC and MPPE. + + Bit B + + This bit does not have any significance in MPPE. + + Bit C + + This bit does not have any significance in MPPE. + + Bit D + + This bit set to 1 indicates that the packet is encrypted. This + bit set to 0 means that this packet is not encrypted. + + + + +Pall & Zorn Informational [Page 5] + +RFC 3078 MPPE Protocol March 2001 + + + Coherency Count + + The coherency count is used to assure that the packets are sent + in proper order and that no packet has been dropped. It is a + monotonically increasing counter which incremented by 1 for + each packet sent. When the counter reaches 4095 (0x0FFF), it + is reset to 0. + + Encrypted Data + + The encrypted data begins with the protocol field. For + example, in case of an IP packet (0x0021 followed by an IP + header), the MPPE processor will first encrypt the protocol + field and then encrypt the IP header. + + If the packet contains header compression, the MPPE processor + is applied AFTER header compression is performed and MUST be + applied to the compressed header as well. For example, if a + packet contained the protocol type 0x002D (for a compressed + TCP/IP header), the MPPE processor would first encrypt 0x002D + and then it would encrypt the compressed Van-Jacobsen TCP/IP + header. + + Implementation Note + + If both MPPE and MPPC are negotiated on the same link, the MPPE + processor MUST be invoked after the MPPC processor by the + sender and the MPPE processor MUST be invoked before the MPPC + processor by the receiver. + +4. Initial Session Keys + + In the current implementation, initial session keys are derived from + peer credentials; however, other derivation methods are possible. + For example, some authentication methods (such as Kerberos [8] and + TLS [9]) produce session keys as side effects of authentication; + these keys may be used by MPPE in the future. For this reason, the + techniques used to derive initial MPPE session keys are described in + separate documents. + +5. Initializing RC4 Using a Session Key + + Once an initial session key has been derived, the RC4 context is + initialized as follows: + + rc4_key(RC4Key, Length_Of_Key, Initial_Session_Key) + + + + + +Pall & Zorn Informational [Page 6] + +RFC 3078 MPPE Protocol March 2001 + + +6. Encrypting Data + + Once initialized, data is encrypted using the following function and + transmitted with the CCP and MPPE headers. + + EncryptedData = rc4(RC4Key, Length_Of_Data, Data) + +7. Changing Keys + +7.1. Stateless Mode Key Changes + + If stateless encryption has been negotiated, the session key changes + every time the coherency count changes; i.e., on every packet. In + stateless mode, the sender MUST change its key before encrypting and + transmitting each packet and the receiver MUST change its key after + receiving, but before decrypting, each packet (see "Synchronization", + below). + +7.2. Stateful Mode Key Changes + + If stateful encryption has been negotiated, the sender MUST change + its key before encrypting and transmitting any packet in which the + low order octet of the coherency count equals 0xFF (the "flag" + packet), and the receiver MUST change its key after receiving, but + before decrypting, a "flag" packet (see "Synchronization", below). + +7.3. The MPPE Key Change Algorithm + + The following method is used to change keys: + + /* + * SessionKeyLength is 8 for 40-bit keys, 16 for 128-bit keys. + * + * SessionKey is the same as StartKey in the first call for + * a given session. + */ + + void + GetNewKeyFromSHA( + IN unsigned char *StartKey, + IN unsigned char *SessionKey, + IN unsigned long SessionKeyLength + OUT unsigned char *InterimKey ) + { + unsigned char Digest[20]; + + ZeroMemory(Digest, 20); + + + + +Pall & Zorn Informational [Page 7] + +RFC 3078 MPPE Protocol March 2001 + + + /* + * SHAInit(), SHAUpdate() and SHAFinal() + * are an implementation of the Secure + * Hash Algorithm [7] + */ + + SHAInit(Context); + SHAUpdate(Context, StartKey, SessionKeyLength); + SHAUpdate(Context, SHApad1, 40); + SHAUpdate(Context, SessionKey, SessionKeyLength); + SHAUpdate(Context, SHApad2, 40); + SHAFinal(Context, Digest); + + MoveMemory(InterimKey, Digest, SessionKeyLength); + } + + The RC4 tables are re-initialized using the newly created interim key: + + rc4_key(RC4Key, Length_Of_Key, InterimKey) + + Finally, the interim key is encrypted using the new tables to produce + a new session key: + + SessionKey = rc4(RC4Key, Length_Of_Key, InterimKey) + + For 40-bit session keys the most significant three octets of the new + session key are now set to 0xD1, 0x26 and 0x9E respectively; for 56- + bit keys, the most significant octet is set to 0xD1. + + Finally, the RC4 tables are re-initialized using the new session key: + + rc4_key(RC4Key, Length_Of_Key, SessionKey) + +8. Synchronization + + Packets may be lost during transfer. The following sections describe + synchronization for both the stateless and stateful cases. + +8.1. Stateless Synchronization + + If stateless encryption has been negotiated and the coherency count + in the received packet (C1) is greater than the coherency count in + the last packet previously received (C2), the receiver MUST perform N + = C1 - C2 key changes before decrypting the packet, in order to + ensure that its session key is synchronized with the session key of + the sender. Normally, the value of N will be 1; however, if + intervening packets have been lost, N may be greater than 1. For + example, if C1 = 5 and C2 = 02 then N = 3 key changes are required. + + + +Pall & Zorn Informational [Page 8] + +RFC 3078 MPPE Protocol March 2001 + + + Since the FLUSHED bit is set on every packet if stateless encryption + was negotiated, the transmission of CCP Reset-Request packets is not + required for synchronization. + +8.2. Stateful Synchronization + + If stateful encryption has been negotiated, the sender MUST change + its key before encrypting and transmitting any packet in which the + low order octet of the coherency count equals 0xFF (the "flag" + packet), and the receiver MUST change its key after receiving, but + before decrypting, a "flag" packet. However, the "flag" packet may + be lost. If this happens, the low order octet of the coherency count + in the received packet will be less than that in the last packet + previously received. In this case, the receiver MUST perform a key + change before decrypting the newly received packet, (since the sender + will have changed its key before transmitting the packet), then send + a CCP Reset-Request packet (see below). It is possible that 256 or + more consecutive packets could be lost; the receiver SHOULD detect + this condition and perform the number of key changes necessary to + resynchronize with the sender. + + If packet loss is detected while using stateful encryption, the + receiver MUST drop the packet and send a CCP Reset-Request packet + without data. After transmitting the CCP Reset-Request packet, the + receiver SHOULD silently discard all packets until a packet is + received with the FLUSHED bit set. On receiving a packet with the + FLUSHED bit set, the receiver MUST set its coherency count to the one + received in that packet and re-initialize its RC4 tables using the + current session key: + + rc4_key(RC4Key, Length_Of_Key, SessionKey) + + When the sender receives a CCP Reset-Request packet, it MUST re- + initialize its own RC4 tables using the same method and set the + FLUSHED bit in the next packet sent. Thus synchronization is + achieved without a CCP Reset-Ack packet. + +9. Security Considerations + + Because of the way that the RC4 tables are reinitialized during + stateful synchronization, it is possible that two packets may be + encrypted using the same key. For this reason, the stateful mode + SHOULD NOT be used in lossy network environments (e.g., layer two + tunnels on the Internet). + + + + + + + +Pall & Zorn Informational [Page 9] + +RFC 3078 MPPE Protocol March 2001 + + + Since the MPPE negotiation is not integrity protected, an active + attacker could alter the strength of the keys used by modifying the + Supported Bits field of the CCP Configuration Option packet. The + effects of this attack can be minimized through appropriate peer + configuration, however. + + Peers MUST NOT transmit user data until the MPPE negotiation is + complete. + + It is possible that an active attacker could modify the coherency + count of a packet, causing the peers to lose synchronization. + + An active denial-of-service attack could be mounted by methodically + inverting the value of the 'D' bit in the MPPE packet header. + +10. References + + [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD + 51, RFC 1661, July 1994. + + [2] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC + 1962, June 1996. + + [3] RC4 is a proprietary encryption algorithm available under + license from RSA Data Security Inc. For licensing information, + contact: + + RSA Data Security, Inc. + 100 Marine Parkway + Redwood City, CA 94065-1031 + + [4] Pall, G., "Microsoft Point-to-Point Compression (MPPC) + Protocol", RFC 2118, March 1997. + + [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [6] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994. + + [7] "Secure Hash Standard", Federal Information Processing Standards + Publication 180-1, National Institute of Standards and + Technology, April 1995. + + [8] Kohl, J. and C. Neuman "The Kerberos Network Authentication + System (V5)", RFC 1510, September 1993. + + [9] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC + 2246, January 1999. + + + +Pall & Zorn Informational [Page 10] + +RFC 3078 MPPE Protocol March 2001 + + + [10] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January + 1994. + +11. Acknowledgements + + Anthony Bell, Richard B. Ward, Terence Spies and Thomas Dimitri, all + of Microsoft Corporation, significantly contributed to the design and + development of MPPE. + + Additional thanks to Robert Friend, Joe Davies, Jody Terrill, Archie + Cobbs, Mark Deuser, and Jeff Haag, for useful feedback. + +12. Authors' Addresses + + Questions about this memo can be directed to: + + Gurdeep Singh Pall + Microsoft Corporation + One Microsoft Way + Redmond, Washington 98052 + USA + + Phone: +1 425 882 8080 + Fax: +1 425 936 7329 + EMail: gurdeep@microsoft.com + + + Glen Zorn + cisco Systems + 500 108th Avenue N.E. + Suite 500 + Bellevue, Washington 98004 + USA + + Phone: +1 425 438 8218 + Fax: +1 425 438 1848 + EMail: gwz@cisco.com + + + + + + + + + + + + + + +Pall & Zorn Informational [Page 11] + +RFC 3078 MPPE Protocol March 2001 + + +13. Full Copyright Statement + + Copyright (C) The Internet Society (2001). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Pall & Zorn Informational [Page 12] + diff --git a/doc/rfc3544.txt b/doc/rfc3544.txt new file mode 100644 index 00000000..b4d2ac5e --- /dev/null +++ b/doc/rfc3544.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group T. Koren +Request for Comments: 3544 Cisco Systems +Obsoletes: 2509 S. Casner +Category: Standards Track Packet Design + C. Bormann + Universitaet Bremen TZI + July 2003 + + + IP Header Compression over PPP + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document describes an option for negotiating the use of header + compression on IP datagrams transmitted over the Point-to-Point + Protocol (RFC 1661). It defines extensions to the PPP Control + Protocols for IPv4 and IPv6 (RFC 1332, RFC 2472). Header compression + may be applied to IPv4 and IPv6 datagrams in combination with TCP, + UDP and RTP transport protocols as specified in RFC 2507, RFC 2508 + and RFC 3545. + +1. Introduction + + The IP Header Compression (IPHC) defined in [RFC2507] may be used for + compression of both IPv4 and IPv6 datagrams or packets encapsulated + with multiple IP headers. IPHC is also capable of compressing both + TCP and UDP transport protocol headers. The IP/UDP/RTP header + compression defined in [RFC2508] and [RFC3545] fits within the + framework defined by IPHC so that it may also be applied to both IPv4 + and IPv6 packets. + + + + + + + + + +Koren, et al. Standards Track [Page 1] + +RFC 3544 IP Header Compression over PPP July 2003 + + + In order to establish compression of IP datagrams sent over a PPP + link each end of the link must agree on a set of configuration + parameters for the compression. The process of negotiating link + parameters for network layer protocols is handled in PPP by a family + of network control protocols (NCPs). Since there are separate NCPs + for IPv4 and IPv6, this document defines configuration options to be + used in both NCPs to negotiate parameters for the compression scheme. + + This document obsoletes RFC 2509, adding two new suboptions to the IP + header compression configuration option. One suboption negotiates + usage of Enhanced RTP-Compression (specified in [RFC3545]), and the + other suboption negotiates header compression for only TCP or only + non-TCP packets. + + IPHC relies on the link layer's ability to indicate the types of + datagrams carried in the link layer frames. In this document nine + new types for the PPP Data Link Layer Protocol Field are defined + along with their meaning. + + In general, header compression schemes that use delta encoding of + compressed packets require that the lower layer does not reorder + packets between compressor and decompressor. IPHC uses delta + encoding of compressed packets for TCP and RTP. The IPHC + specification [RFC2507] includes methods that allow link layers that + may reorder packets to be used with IPHC. Since PPP does not reorder + packets these mechanisms are disabled by default. When using + reordering mechanisms such as multiclass multilink PPP [RFC2686], + care must be taken so that packets that share the same compression + context are not reordered. + +2. Configuration Option + + This document specifies a new compression protocol value for the IPCP + IP-Compression-Protocol option as specified in [RFC1332]. The new + value and the associated option format are described in section 2.1. + + The option format is structured to allow future extensions to the + IPHC scheme. + + NOTE: The specification of link and network layer parameter + negotiation for PPP [RFC1661], [RFC1331], [RFC1332] does not + prohibit multiple instances of one configuration option but states + that the specification of a configuration option must explicitly + allow multiple instances. [RFC3241] updates RFC 1332 by + explicitly allowing the sending of multiple instances of the IP- + Compression-Protocol configuration option, each with a different + value for IP-Compression-Protocol. Each type of compression + protocol may independently establish its own parameters. + + + +Koren, et al. Standards Track [Page 2] + +RFC 3544 IP Header Compression over PPP July 2003 + + + NOTE: [RFC1332] is not explicit about whether the option + negotiates the capabilities of the receiver or of the sender. In + keeping with current practice, we assume that the option describes + the capabilities of the decompressor (receiving side) of the peer + that sends the Config-Req. + +2.1. Configuration Option Format + + Both the network control protocol for IPv4, IPCP [RFC1332] and the + IPv6 NCP, IPV6CP [RFC2472] may be used to negotiate IP Header + Compression parameters for their respective protocols. The format of + the configuration option is the same for both IPCP and IPV6CP. + + Description + + This NCP configuration option is used to negotiate parameters for + IP Header Compression. Successful negotiation of parameters + enables the use of Protocol Identifiers FULL_HEADER, + COMPRESSED_TCP, COMPRESSED_TCP_NODELTA, COMPRESSED_NON_TCP and + CONTEXT_STATE as specified in [RFC2507]. The option format is + summarized below. The fields are transmitted from left to right. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | IP-Compression-Protocol | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | TCP_SPACE | NON_TCP_SPACE | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | F_MAX_PERIOD | F_MAX_TIME | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MAX_HEADER | suboptions... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + 2 + + Length + >= 14 + + The length may be increased if the presence of additional + parameters is indicated by additional suboptions. + + IP-Compression-Protocol + 0061 (hex) + + + + + + +Koren, et al. Standards Track [Page 3] + +RFC 3544 IP Header Compression over PPP July 2003 + + + TCP_SPACE + The TCP_SPACE field is two octets and indicates the maximum value + of a context identifier in the space of context identifiers + allocated for TCP. + + Suggested value: 15 + + TCP_SPACE must be at least 0 and at most 255 (the value 0 implies + having one context). + + NON_TCP_SPACE + The NON_TCP_SPACE field is two octets and indicates the maximum + value of a context identifier in the space of context identifiers + allocated for non-TCP. These context identifiers are carried in + COMPRESSED_NON_TCP, COMPRESSED_UDP and COMPRESSED_RTP packet + headers. + + Suggested value: 15 + + NON_TCP_SPACE must be at least 0 and at most 65535 (the value 0 + implies having one context). + + F_MAX_PERIOD + Maximum interval between full headers. No more than F_MAX_PERIOD + COMPRESSED_NON_TCP headers may be sent between FULL_HEADER + headers. + + Suggested value: 256 + + A value of zero implies infinity, i.e. there is no limit to the + number of consecutive COMPRESSED_NON_TCP headers. + + F_MAX_TIME + Maximum time interval between full headers. COMPRESSED_NON_TCP + headers may not be sent more than F_MAX_TIME seconds after sending + the last FULL_HEADER header. + + Suggested value: 5 seconds + + A value of zero implies infinity. + + MAX_HEADER + The largest header size in octets that may be compressed. + + Suggested value: 168 octets + + + + + + +Koren, et al. Standards Track [Page 4] + +RFC 3544 IP Header Compression over PPP July 2003 + + + The value of MAX_HEADER should be large enough so that at least + the outer network layer header can be compressed. To increase + compression efficiency MAX_HEADER should be set to a value large + enough to cover common combinations of network and transport layer + headers. + + suboptions + The suboptions field consists of zero or more suboptions. Each + suboption consists of a type field, a length field and zero or + more parameter octets, as defined by the suboption type. The + value of the length field indicates the length of the suboption in + its entirety, including the lengths of the type and length fields. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Parameters... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.2. RTP-Compression Suboption + + The RTP-Compression suboption is included in the NCP IP-Compression- + Protocol option for IPHC if IP/UDP/RTP compression is to be enabled. + + Inclusion of the RTP-Compression suboption enables use of additional + Protocol Identifiers COMPRESSED_RTP and COMPRESSED_UDP along with + additional forms of CONTEXT_STATE as specified in [RFC2508]. + + Description + + Enable use of Protocol Identifiers COMPRESSED_RTP, COMPRESSED_UDP + and CONTEXT_STATE as specified in [RFC2508]. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + 1 + + Length + 2 + + + + + + + +Koren, et al. Standards Track [Page 5] + +RFC 3544 IP Header Compression over PPP July 2003 + + +2.3. Enhanced RTP-Compression Suboption + + To use the enhanced RTP header compression defined in [RFC3545], a + new sub-option 2 is added. Sub-option 2 is negotiated instead of, + not in addition to, sub-option 1. + + Description + + Enable use of Protocol Identifiers COMPRESSED_RTP and + CONTEXT_STATE as specified in [RFC2508]. In addition, enable use + of [RFC3545] compliant compression including the use of Protocol + Identifier COMPRESSED_UDP with additional flags and use of the C + flag with the FULL_HEADER Protocol Identifier to indicate use of + HDRCKSUM with COMPRESSED_RTP and COMPRESSED_UDP packets. + + 0 1 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + 2 + + Length + 2 + +2.4. Negotiating header compression for only TCP or only non-TCP + packets + + In RFC 2509 it was not possible to negotiate only TCP header + compression or only non-TCP header compression because a value of 0 + in the TCP_SPACE or the NON_TCP_SPACE fields actually means that 1 + context is negotiated. + + A new suboption 3 is added to allow specifying that the number of + contexts for TCP_SPACE or NON_TCP_SPACE is zero, disabling use of the + corresponding compression. + + + + + + + + + + + + + +Koren, et al. Standards Track [Page 6] + +RFC 3544 IP Header Compression over PPP July 2003 + + + Description + + Enable header compression for only TCP or only non-TCP packets. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Parameter | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + 3 + + Length + 3 + + Parameter + + The parameter is 1 byte with one of the following values: + + 1 = the number of contexts for TCP_SPACE is 0 + 2 = the number of contexts for NON_TCP_SPACE is 0 + + This suboption overrides the values that were previously assigned to + TCP_SPACE and NON_TCP_SPACE in the IP Header Compression option. + + If suboption 3 is included multiple times with parameter 1 and 2, + compression is disabled for all packets. + +3. Multiple Network Control Protocols + + The IPHC protocol is able to compress both IPv6 and IPv4 datagrams. + Both IPCP and IPV6CP are able to negotiate option parameter values + for IPHC. These values apply to the compression of packets where the + outer header is an IPv4 header and an IPv6 header, respectively. + +3.1. Sharing Context Identifier Space + + For the compression and decompression of IPv4 and IPv6 datagram + headers the context identifier space is shared. While the parameter + values are independently negotiated, sharing the context identifier + spaces becomes more complex when the parameter values differ. Since + the compressed packets share context identifier space, the + compression engine must allocate context identifiers out of a common + pool; for compressed packets, the decompressor has to examine the + context state to determine what parameters to use for decompression. + + + + + +Koren, et al. Standards Track [Page 7] + +RFC 3544 IP Header Compression over PPP July 2003 + + + Context identifier spaces are not shared between TCP and non- + TCP/UDP/RTP. Doing so would require additional mechanisms to ensure + that no error can occur when switching from using a context + identifier for TCP to non-TCP. + +4. Demultiplexing of Datagrams + + The IPHC specification [RFC2507] defines four header formats for + different types of compressed headers. They are compressed TCP, + compressed TCP with no delta encoding, compressed non-TCP with 8 bit + CID and compressed non-TCP with 16 bit CID. The two non-TCP formats + may be distinguished by their contents so both may use the same + link-level identifier. A fifth header format, the full header is + distinct from a regular header in that it carries additional + information to establish shared context between the compressor and + decompressor. + + The specification of IP/UDP/RTP Header Compression [RFC2508] defines + four additional formats of compressed headers. They are for + compressed UDP and compressed RTP (on top of UDP), both with either + 8- or 16-bit CIDs. In addition, there is an explicit error message + from the decompressor to the compressor. + + The link layer must be able to indicate these header formats with + distinct values. Nine PPP Data Link Layer Protocol Field values are + specified below. + + FULL_HEADER + The frame contains a full header as specified in [RFC2508] Section + 3.3.1. This is the same as the FULL_HEADER specified in [RFC2507] + Section 5.3. + Value: 0061 (hex) + + COMPRESSED_TCP + The frame contains a datagram with a compressed header with the + format as specified in [RFC2507] Section 6a. + Value: 0063 (hex) + + COMPRESSED_TCP_NODELTA + The frame contains a datagram with a compressed header with the + format as specified in [RFC2507] Section 6b. + Value: 2063 (hex) + + COMPRESSED_NON_TCP + The frame contains a datagram with a compressed header with the + format as specified in either Section 6c or Section 6d of + [RFC2507]. + Value: 0065 (hex) + + + +Koren, et al. Standards Track [Page 8] + +RFC 3544 IP Header Compression over PPP July 2003 + + + COMPRESSED_RTP_8 + The frame contains a datagram with a compressed header with the + format as specified in [RFC2508] Section 3.3.2, using 8-bit CIDs. + Value: 0069 (hex) + + COMPRESSED_RTP_16 + The frame contains a datagram with a compressed header with the + format as specified in [RFC2508] Section 3.3.2, using 16-bit CIDs. + Value: 2069 (hex) + + COMPRESSED_UDP_8 + The frame contains a datagram with a compressed header with the + format as specified in [RFC2508] Section 3.3.3 or as specified in + [RFC3545] Section 2.1, using 8-bit CIDs. + Value: 0067 (hex) + + COMPRESSED_UDP_16 + The frame contains a datagram with a compressed header with the + format as specified in [RFC2508] Section 3.3.3 or as specified in + [RFC3545] Section 2.1, using 16-bit CIDs. + Value: 2067 (hex) + + CONTEXT_STATE + The frame is a link-level message sent from the decompressor to + the compressor as specified in [RFC2508] Section 3.3.5. + Value: 2065 (hex) + +5. Changes from RFC 2509 + + Two new suboptions are specified. See Sections 2.3 and 2.4. + +6. References + +6.1. Normative References + + [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for low-speed + serial links", RFC 1144, February 1990. + + [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol + (IPCP)", RFC 1332, May 1992. + + [RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC + 2472, December 1998. + + [RFC2507] Degermark, M., Nordgren, B. and S. Pink, "Header + Compression for IP", RFC 2507, February 1999. + + + + + +Koren, et al. Standards Track [Page 9] + +RFC 3544 IP Header Compression over PPP July 2003 + + + [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP + Headers for Low-Speed Serial Links", RFC 2508, February + 1999. + + [RFC3241] Bormann, C., "Robust Header Compression (ROHC) over PPP", + RFC 3241, April 2002. + + [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B. and + P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with + High Delay, Packet Loss and Reordering", RFC 3545, July + 2003. + +6.2. Informative References + + [RFC1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD + 51, RFC 1661, July 1994. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 2434, + October 1998. + + [RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link + PPP", RFC 2686, September 1999. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R. and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", RFC 3550, July 2003. + +7. IANA Considerations + + This document does not require any additional allocations from + existing namespaces in the IANA Point-to-Point Protocol Field + Assignments registry. However, there are three namespaces that were + defined by RFC 1332, RFC 2472, and RFC 2509 but not created in the + registry. Those three namespaces, described below, have been added + to the PPP registry. This document specifies two additional + allocations in the third one. + + Section 3.2 of RFC 1332 specifies an IP-Compression-Protocol + Configuration Option for the PPP IP Control Protocol and defines one + value for the IP-Compression-Protocol type field in that option. An + IANA registry has been created to allocate additional values for that + type field. As stated in RFC 1332, the values for the IP- + Compression-Protocol type field are always the same as the (primary) + PPP DLL Protocol Number assigned to packets of the particular + compression protocol. Assignment of additional IP-Compression- + Protocol type values is through the IETF consensus procedure as + specified in [RFC2434]. + + + +Koren, et al. Standards Track [Page 10] + +RFC 3544 IP Header Compression over PPP July 2003 + + + Section 4.2 of RFC 2472 specifies an IPv6-Compression-Protocol + Configuration Option for the PPP IPv6 Control Protocol and defines + one value for the IPv6-Compression-Protocol type field in that + option. An IANA registry has been created to allocate additional + values for that type field. The IPv6-Compression-Protocol + Configuration Option has the same structure as the IP-Compression- + Protocol Configuration Option defined in RFC 1332, but the set of + values defined for the type field may be different. As stated in RFC + 2472, the values for the IPv6-Compression-Protocol type field are + always the same as the (primary) PPP DLL Protocol Number assigned to + packets of the particular compression protocol. Assignment of + additional IPv6-Compression-Protocol type values is through the IETF + consensus procedure as specified in [RFC2434]. + + Section 2.1 of RFC 2509 specifies an additional type value to be + registered for both the IP-Compression-Protocol Configuration Option + and the IPv6-Compression-Protocol Configuration Option to indicate + use of the "IP Header Compression" protocol. The specification of + that type value is repeated in Section 2.1 of this document which + obsoletes RFC 2509. In conjunction with the additional type value, + the format for the variable-length option is specified. The format + includes a suboption field that may contain one or more suboptions. + Each suboption begins with a suboption type value. An IANA registry + has been created for the suboption type values; and is titled, "IP + Header Compression Configuration Option Suboption Types". + + Section 2.2 of RFC 2509 (and this document) defines one suboption + type. Sections 2.3 and 2.4 of this document define two additional + suboption types. It is expected that the number of additional + suboptions that will need to be defined is small. Therefore, anyone + wishing to define new suboptions is required to produce a revision of + this document to be vetted through the normal Internet Standards + process, as specified in [RFC2434]. + + RFC 2509 also defines nine PPP Data Link Layer Protocol Field values + which are already listed in the IANA registry of Point-to-Point + Protocol Field Assignments. Section 4 of this document repeats the + specification of those values without change. + +8. Security Considerations + + Negotiation of the option defined here imposes no additional security + considerations beyond those that otherwise apply to PPP [RFC1661]. + + The use of header compression can, in rare cases, cause the + misdelivery of packets. If necessary, confidentiality of packet + contents should be assured by encryption. + + + + +Koren, et al. Standards Track [Page 11] + +RFC 3544 IP Header Compression over PPP July 2003 + + + Encryption applied at the IP layer (e.g., using IPSEC mechanisms) + precludes header compression of the encrypted headers, though + compression of the outer IP header and authentication/security + headers is still possible as described in [RFC2507]. For RTP + packets, full header compression is possible if the RTP payload is + encrypted by itself without encrypting the UDP or RTP headers, as + described in [RFC3550]. This method is appropriate when the UDP and + RTP header information need not be kept confidential. + +9. Intellectual Property Rights Notice + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + + + + + + + + + + + + + + + + + +Koren, et al. Standards Track [Page 12] + +RFC 3544 IP Header Compression over PPP July 2003 + + +10. Acknowledgements + + Mathias Engan was the primary author of RFC 2509, of which this + document is a revision. + +11. Authors' Addresses + + Tmima Koren + Cisco Systems, Inc. + 170 West Tasman Drive + San Jose, CA 95134-1706 + United States + + EMail: tmima@cisco.com + + + Stephen L. Casner + Packet Design + 3400 Hillview Avenue, Building 3 + Palo Alto, CA 94304 + United States + + EMail: casner@packetdesign.com + + + Carsten Bormann + Universitaet Bremen FB3 TZI + Postfach 330440 + D-28334 Bremen, GERMANY + + Phone: +49.421.218-7024 + Fax: +49.421.218-7000 + EMail: cabo@tzi.org + + + + + + + + + + + + + + + + + + +Koren, et al. Standards Track [Page 13] + +RFC 3544 IP Header Compression over PPP July 2003 + + +12. Full Copyright Statement + + Copyright (C) The Internet Society (2003). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assignees. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Koren, et al. Standards Track [Page 14] + |