Network Working Group G. Pall
Request for Comments: 3078 Microsoft Corporation
Category: Informational G. Zorn
Updates: 2118 cisco Systems
March 2001
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
Microsoft点对点加密（MPPE）协议
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.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.
点到点协议（PPP）提供了通过点到点链路传输多协议数据报的标准方法。
The PPP Compression Control Protocol provides a method to negotiate and utilize compression protocols over PPP encapsulated links.
PPP压缩控制协议提供了一种通过PPP封装链路协商和利用压缩协议的方法。
This document describes the use of the Microsoft Point to Point Encryption (MPPE) to enhance the confidentiality of PPP-encapsulated packets.
本文档介绍如何使用Microsoft点对点加密（MPPE）来增强PPP封装数据包的机密性。
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].
在本文件中，关键词“可能”、“必须”、“不得”、“可选”、“建议”、“应该”和“不应该”的解释如[5]所述。
The Microsoft Point to Point Encryption scheme is a means of representing Point to Point Protocol (PPP) packets in an encrypted form.
Microsoft点对点加密方案是一种以加密形式表示点对点协议（PPP）数据包的方法。
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.
MPPE使用RSA RC4[3]算法来提供数据保密性。可以协商用于初始化加密表的会话密钥的长度。MPPE目前支持40位和128位会话密钥。
MPPE session keys are changed frequently; the exact frequency depends upon the options negotiated, but may be every packet.
MPPE会话密钥频繁更改；确切的频率取决于协商的选项，但可能是每个数据包。
MPPE is negotiated within option 18 [4] in the Compression Control Protocol.
MPPE在压缩控制协议的选项18[4]内协商。
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.
CCP配置选项协商链路上MPPE的使用。默认情况下（即，如果未尝试协商MPPE），则不使用加密。但是，如果尝试MPPE协商失败，则应终止链接。
A summary of the CCP Configuration Option format is shown below. The fields are transmitted from left to right.
CCP配置选项格式摘要如下所示。字段从左向右传输。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
18
Length
长
6
6.
Supported Bits
支持位
This field is 4 octets, most significant octet first.
该字段为4个八位字节，最重要的八位字节排在第一位。
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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".
“C”位由MPPC[4]使用，本备忘录中不再进一步讨论。“D”位已过时；尽管一些年长的同龄人可能会尝试协商此选项，但不应接受。如果设置了“L”位（对应于最低有效八位字节中的0x20值），则表示发送方希望协商使用40位会话密钥。如果设置了“S”位（对应于最低有效八位字节中的0x40值），则表示发送方希望协商使用128位会话密钥。如果设置了“M”位（对应于最低有效八位字节中的0x80值），则表示发送方希望协商56位会话密钥的使用。如果设置了“H”位（对应于最高有效八位字节中的0x01值），则表示发送方希望协商无状态模式的使用，在该模式中，会话密钥在每个数据包传输后更改（见下文第10节）。在下面的讨论中，“S”、“M”和“L”位有时统称为“加密选项”。
All other bits are reserved and MUST be set to 0.
所有其他位都是保留的，必须设置为0。
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:
MPPE选项按照[2]中所述进行协商。特别是，协商发起人应请求其支持的所有选项。响应者应使用单个加密选项进行NAK（注意，无状态模式可能始终是协商的，独立于加密选项，并且是加密选项的补充）。如果响应程序在发起程序请求的集合中支持多个加密选项，则所选选项应为提供的“最强”选项。非正式地说，MPPE加密选项的强度可以描述如下：
STRONGEST 128-bit encryption ('S' bit set) 56-bit encryption ('M' bit set) 40-bit encryption ('L' bit set) WEAKEST
最强128位加密（“S”位集）56位加密（“M”位集）40位加密（“L”位集）最弱
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.
然后，发起方应发送另一个包含与响应方的NAK相同选项的请求，或取消协商，断开连接。
Before any MPPE packets are transmitted, PPP MUST reach the Network-Layer Protocol phase and the CCP Control Protocol MUST reach the Opened state.
在传输任何MPPE数据包之前，PPP必须达到网络层协议阶段，CCP控制协议必须达到打开状态。
Exactly one MPPE datagram is encapsulated in the PPP Information field. The PPP Protocol field indicates type 0x00FD for all encrypted datagrams.
PPP信息字段中只封装了一个MPPE数据报。PPP协议字段指示所有加密数据报的类型0x00FD。
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.
通过PPP链路传输的MPPE数据报的最大长度与PPP封装包的信息字段的最大长度相同。
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.
只有PPP协议编号在0x0021到0x00FA范围内的数据包才被加密。其他数据包不通过MPPE处理器，而是使用其原始PPP协议号发送。
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.
建议不要将填充物与MPPE一起使用。如果发送方使用填充，则必须在LCP阶段协商自描述填充配置选项[10]，并使用自描述填充。
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方案不需要可靠的链路。相反，它依赖于每个数据包中的12位一致性计数来保持加密表的同步。如果未协商无状态模式，且接收数据包中的一致性计数与预期计数不匹配，则接收器必须发送CCP重置请求数据包，以导致RC4表的重新同步。
MPPE expects packets to be delivered in sequence.
MPPE希望数据包按顺序传递。
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.
MPPE可以在可靠链路上使用，如“PPP可靠传输”[6]中所述，但这通常只会增加不必要的开销，因为只需要一致性计数。
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.
MPPE方案不扩展或压缩数据。MPPE处理器输入和输出的八位字节数相同。
A summary of the MPPE packet format is shown below. The fields are transmitted from left to right.
MPPE数据包格式的摘要如下所示。字段从左向右传输。
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
PPP协议
The PPP Protocol field is described in the Point-to-Point Protocol Encapsulation [1].
PPP协议字段在点对点协议封装[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.
当PPP压缩控制协议成功协商MPPE时，此字段的值为0x00FD。协商协议字段压缩时，可压缩此值。
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.
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.translate error, please retry
Bit B
B位
This bit does not have any significance in MPPE.
此位在MPPE中没有任何意义。
Bit C
C位
This bit does not have any significance in MPPE.
此位在MPPE中没有任何意义。
Bit D
D位
This bit set to 1 indicates that the packet is encrypted. This bit set to 0 means that this packet is not encrypted.
此位设置为1表示数据包已加密。此位设置为0表示此数据包未加密。
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.
一致性计数用于确保数据包以正确的顺序发送，并且没有数据包被丢弃。它是一个单调递增的计数器，每个发送的数据包递增1。当计数器达到4095（0x0FFF）时，将重置为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.
加密数据以协议字段开头。例如，对于IP数据包（0x0021后跟IP报头），MPPE处理器将首先加密协议字段，然后加密IP报头。
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.
如果数据包包含报头压缩，则MPPE处理器在执行报头压缩后应用，并且必须也应用于压缩的报头。例如，如果数据包包含协议类型0x002D（对于压缩的TCP/IP头），MPPE处理器将首先加密0x002D，然后加密压缩的Van Jacobsen TCP/IP头。
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.
如果MPPE和MPPC在同一链路上协商，则发送方必须在MPPC处理器之后调用MPPE处理器，接收方必须在MPPC处理器之前调用MPPE处理器。
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.
在当前实现中，初始会话密钥来自对等凭据；然而，其他推导方法也是可能的。例如，某些身份验证方法（如Kerberos[8]和TLS[9]）产生会话密钥作为身份验证的副作用；MPPE将来可能会使用这些密钥。因此，用于派生初始MPPE会话密钥的技术在单独的文档中描述。
Once an initial session key has been derived, the RC4 context is initialized as follows:
导出初始会话密钥后，RC4上下文将按如下方式初始化：
rc4_key(RC4Key, Length_Of_Key, Initial_Session_Key)
rc4密钥（RC4Key、密钥长度、初始会话密钥）
Once initialized, data is encrypted using the following function and transmitted with the CCP and MPPE headers.
初始化后，使用以下函数对数据进行加密，并使用CCP和MPPE报头进行传输。
EncryptedData = rc4(RC4Key, Length_Of_Data, Data)
EncryptedData=rc4（RC4Key，数据的长度，数据）
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).
如果协商了无状态加密，则每次一致性计数更改时会话密钥都会更改；i、 在每一个包裹上。在无状态模式下，发送方必须在加密和发送每个数据包之前更改其密钥，接收方必须在接收每个数据包之后但在解密之前更改其密钥（请参阅下文的“同步”）。
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).
如果协商了有状态加密，则发送方必须在加密和传输相干计数的低阶八位组等于0xFF的任何数据包之前更改其密钥（“标志”数据包），接收方必须在接收到“标志”数据包之后但在解密之前更改其密钥（见下文“同步”）。
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.
*/
/*
* 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];
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);
零内存（摘要，20）；
/*
* SHAInit(), SHAUpdate() and SHAFinal()
* are an implementation of the Secure
* Hash Algorithm [7]
*/
/*
* 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);
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);
}
MoveMemory(InterimKey, Digest, SessionKeyLength);
}
The RC4 tables are re-initialized using the newly created interim key:
使用新创建的临时密钥重新初始化RC4表：
rc4_key(RC4Key, Length_Of_Key, InterimKey)
rc4_键（RC4Key、_键长度、InterimKey）
Finally, the interim key is encrypted using the new tables to produce a new session key:
最后，使用新表对临时密钥进行加密，以生成新会话密钥：
SessionKey = rc4(RC4Key, Length_Of_Key, InterimKey)
SessionKey=rc4（RC4Key，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.
对于40位会话密钥，新会话密钥的最重要的三个八位字节现在分别设置为0xD1、0x26和0x9E；对于56位键，最重要的八位字节设置为0xD1。
Finally, the RC4 tables are re-initialized using the new session key:
最后，使用新的会话密钥重新初始化RC4表：
rc4_key(RC4Key, Length_Of_Key, SessionKey)
rc4_键（RC4Key、_键的长度、会话键）
Packets may be lost during transfer. The following sections describe synchronization for both the stateless and stateful cases.
数据包可能在传输过程中丢失。以下各节介绍无状态和有状态情况下的同步。
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.
如果已协商无状态加密，且接收到的数据包（C1）中的一致性计数大于先前接收到的最后一个数据包（C2）中的一致性计数，则接收方必须在解密数据包之前执行N=C1-C2密钥更改，以确保其会话密钥与发送方的会话密钥同步。通常，N的值为1；然而，如果中间分组已经丢失，则N可以大于1。例如，如果C1=5和C2=02，则需要更改N=3个键。
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.
由于如果协商无状态加密，则在每个数据包上设置刷新位，因此同步不需要传输CCP重置请求数据包。
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.
如果协商了有状态加密，则发送方必须在加密和传输任何数据包之前更改其密钥，其中相干计数的低阶八位组等于0xFF（“标志”数据包），接收方必须在接收到“标志”数据包后但在解密之前更改其密钥。然而，“标志”数据包可能丢失。如果发生这种情况，则接收到的分组中的相干计数的低阶八位组将小于先前接收到的最后一个分组中的八位组。在这种情况下，接收方必须在解密新接收的数据包之前执行密钥更改（因为发送方将在发送数据包之前更改其密钥），然后发送CCP重置请求数据包（见下文）。可能丢失256个或更多连续分组；接收方应检测到这种情况，并执行与发送方重新同步所需的密钥更改次数。
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:
如果在使用有状态加密时检测到数据包丢失，则接收方必须丢弃该数据包并发送一个无数据的CCP重置请求数据包。在发送CCP重置请求数据包后，接收器应默默地丢弃所有数据包，直到接收到设置了刷新位的数据包。在接收到设置了刷新位的数据包时，接收器必须将其一致性计数设置为该数据包中接收到的一致性计数，并使用当前会话密钥重新初始化其RC4表：
rc4_key(RC4Key, Length_Of_Key, SessionKey)
rc4_键（RC4Key、_键的长度、会话键）
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.
当发送方收到CCP重置请求数据包时，它必须使用相同的方法重新初始化自己的RC4表，并在下一个发送的数据包中设置刷新位。因此，在没有CCP重置Ack分组的情况下实现同步。
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).
由于RC4表在有状态同步期间重新初始化的方式，两个数据包可能使用相同的密钥进行加密。因此，有状态模式不应用于有损网络环境（例如，互联网上的第二层隧道）。
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.
由于MPPE协商没有完整性保护，主动攻击者可以通过修改CCP配置选项数据包的Supported Bits字段来改变密钥的强度。但是，可以通过适当的对等配置将此攻击的影响降至最低。
Peers MUST NOT transmit user data until the MPPE negotiation is complete.
在MPPE协商完成之前，对等方不得传输用户数据。
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.
通过有系统地反转MPPE数据包头中“D”位的值，可以发起主动拒绝服务攻击。
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[1] 辛普森，W.，编辑，“点对点协议（PPP）”，STD 51，RFC 1661994年7月。
[2] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC 1962, June 1996.
[2] Rand，D.，“PPP压缩控制协议（CCP）”，RFC 1962，1996年6月。
[3] RC4 is a proprietary encryption algorithm available under license from RSA Data Security Inc. For licensing information, contact:
[3] RC4是RSA Data Security Inc.许可下提供的专有加密算法。有关许可信息，请联系：
RSA Data Security, Inc. 100 Marine Parkway Redwood City, CA 94065-1031
RSA Data Security，Inc.加利福尼亚州红木市海洋公园路100号，邮编94065-1031
[4] Pall, G., "Microsoft Point-to-Point Compression (MPPC) Protocol", RFC 2118, March 1997.
[4] 《微软点对点压缩（MPPC）协议》，RFC21181997年3月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.
[6] 兰德博士，“PPP可靠传输”，RFC1663，1994年7月。
[7] "Secure Hash Standard", Federal Information Processing Standards Publication 180-1, National Institute of Standards and Technology, April 1995.
[7] “安全散列标准”，联邦信息处理标准出版物180-1，国家标准与技术研究所，1995年4月。
[8] Kohl, J. and C. Neuman "The Kerberos Network Authentication System (V5)", RFC 1510, September 1993.
[8] Kohl，J.和C.Neuman，“Kerberos网络身份验证系统（V5）”，RFC15101993年9月。
[9] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[9] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[10] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1994.
[10] 辛普森，W.，编辑，“PPP LCP扩展”，RFC 15701994年1月。
Anthony Bell, Richard B. Ward, Terence Spies and Thomas Dimitri, all of Microsoft Corporation, significantly contributed to the design and development of MPPE.
微软公司的Anthony Bell、Richard B.Ward、Terence Spies和Thomas Dimitri对MPPE的设计和开发做出了重大贡献。
Additional thanks to Robert Friend, Joe Davies, Jody Terrill, Archie Cobbs, Mark Deuser, and Jeff Haag, for useful feedback.
还要感谢罗伯特·弗里德、乔·戴维斯、乔迪·泰瑞尔、阿尔奇·科布斯、马克·道瑟和杰夫·哈格提供的有用反馈。
Questions about this memo can be directed to:
有关本备忘录的问题，请联系：
Gurdeep Singh Pall Microsoft Corporation One Microsoft Way Redmond, Washington 98052 USA
Gurdeph Singh Pall Microsoft Corporation One Microsoft Way Redmond，华盛顿98052美国
Phone: +1 425 882 8080
Fax: +1 425 936 7329
EMail: gurdeep@microsoft.com
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
格伦佐恩思科系统500美国华盛顿贝尔维尤第108大道北500号套房，邮编：98004
Phone: +1 425 438 8218
Fax: +1 425 438 1848
EMail: gwz@cisco.com
Phone: +1 425 438 8218
Fax: +1 425 438 1848
EMail: gwz@cisco.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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.
RFC编辑功能的资金目前由互联网协会提供。