Network Working Group K. Sklower
Request for Comments: 2419 University of California, Berkeley
Obsoletes: 1969 G. Meyer
Category: Standards Track Shiva
September 1998
Network Working Group K. Sklower
Request for Comments: 2419 University of California, Berkeley
Obsoletes: 1969 G. Meyer
Category: Standards Track Shiva
September 1998
The PPP DES Encryption Protocol, Version 2 (DESE-bis)
PPP DES加密协议，第2版（DESE bis）
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
Abstract
摘要
The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links.
点到点协议（PPP）[1]提供了通过点到点链路传输多协议数据报的标准方法。
The PPP Encryption Control Protocol (ECP) [2] provides a method to negotiate and utilize encryption protocols over PPP encapsulated links.
PPP加密控制协议（ECP）[2]提供了一种通过PPP封装链路协商和利用加密协议的方法。
This document provides specific details for the use of the DES standard [5, 6] for encrypting PPP encapsulated packets.
本文件提供了使用DES标准[5,6]加密PPP封装数据包的具体细节。
Acknowledgements
致谢
The authors extend hearty thanks to Fred Baker of Cisco, Philip Rakity of Flowpoint, and William Simpson of Daydreamer for helpful improvements to the clarity and correctness of the document.
作者衷心感谢思科公司的弗雷德·贝克（Fred Baker）、Flowpoint公司的菲利普·拉基蒂（Philip Rakity）和Daydreamer公司的威廉·辛普森（William Simpson），他们对文档的清晰性和正确性做出了有益的改进。
Table of Contents
目录
1. Introduction ................................................ 2
1.1. Motivation ................................................ 2
1.2. Conventions ............................................... 2
2. General Overview ............................................ 2
3. Structure of This Specification ............................. 4
4. DESE Configuration Option for ECP ........................... 4
5. Packet Format for DESE ...................................... 5
1. Introduction ................................................ 2
1.1. Motivation ................................................ 2
1.2. Conventions ............................................... 2
2. General Overview ............................................ 2
3. Structure of This Specification ............................. 4
4. DESE Configuration Option for ECP ........................... 4
5. Packet Format for DESE ...................................... 5
6. Encryption .................................................. 6
6.1. Padding Considerations .................................... 7
6.2. Generation of the Ciphertext .............................. 8
6.3. Retrieval of the Plaintext ................................ 8
6.4. Recovery after Packet Loss ................................ 8
7. MRU Considerations .......................................... 9
8. Differences from RFC 1969 ................................... 9
8.1. When to Pad ............................................... 9
8.2. Assigned Numbers .......................................... 9
8.3. Minor Editorial Changes ................................... 9
9. Security Considerations ..................................... 9
10. References ................................................. 10
11. Authors' Addresses ......................................... 11
12. Full Copyright Statement ................................... 12
6. Encryption .................................................. 6
6.1. Padding Considerations .................................... 7
6.2. Generation of the Ciphertext .............................. 8
6.3. Retrieval of the Plaintext ................................ 8
6.4. Recovery after Packet Loss ................................ 8
7. MRU Considerations .......................................... 9
8. Differences from RFC 1969 ................................... 9
8.1. When to Pad ............................................... 9
8.2. Assigned Numbers .......................................... 9
8.3. Minor Editorial Changes ................................... 9
9. Security Considerations ..................................... 9
10. References ................................................. 10
11. Authors' Addresses ......................................... 11
12. Full Copyright Statement ................................... 12
The purpose of this memo is two-fold: to show how one specifies the necessary details of a "data" or "bearer" protocol given the context of the generic PPP Encryption Control Protocol, and also to provide at least one commonly-understood means of secure data transmission between PPP implementations.
本备忘录的目的有两个：说明如何在通用PPP加密控制协议的上下文中指定“数据”或“承载”协议的必要细节，以及提供PPP实现之间安全数据传输的至少一种常见方式。
The DES encryption algorithm is a well studied, understood and widely implemented encryption algorithm. The DES cipher was designed for efficient implementation in hardware, and consequently may be relatively expensive to implement in software. However, its pervasiveness makes it seem like a reasonable choice for a "model" encryption protocol.
DES加密算法是一种经过充分研究、理解和广泛实施的加密算法。DES密码设计用于在硬件中高效实现，因此在软件中实现可能相对昂贵。然而，它的普及性使得它似乎是“模型”加密协议的合理选择。
Source code implementing DES in the "Electronic Code Book Mode" can be found in [7]. US export laws forbid the inclusion of compilation-ready source code in this document.
在“电子代码本模式”中实现DES的源代码可在[7]中找到。美国出口法禁止在本文件中包含可编译源代码。
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 [8].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[8]中所述进行解释。
The purpose of encrypting packets exchanged between two PPP implementations is to attempt to insure the privacy of communication conducted via the two implementations. The encryption process depends on the specification of an encryption algorithm and a shared
加密两个PPP实现之间交换的数据包的目的是试图确保通过这两个实现进行的通信的隐私。加密过程取决于加密算法和共享密钥的规范
secret (usually involving at least a key) between the sender and receiver.
发送方和接收方之间的秘密（通常至少涉及一个密钥）。
Generally, the encryptor will take a PPP packet including the protocol field, apply the chosen encryption algorithm, place the resulting cipher text (and in this specification, an explicit sequence number) in the information field of another PPP packet. The decryptor will apply the inverse algorithm and interpret the resulting plain text as if it were a PPP packet which had arrived directly on the interface.
通常，加密机将获取一个包含协议字段的PPP数据包，应用所选的加密算法，将生成的密文（在本规范中，是一个明确的序列号）放入另一个PPP数据包的信息字段中。解密程序将应用反向算法并解释生成的纯文本，就像它是直接到达接口的PPP数据包一样。
The means by which the secret becomes known to both communicating elements is beyond the scope of this document; usually some form of manual configuration is involved. Implementations might make use of PPP authentication, or the EndPoint Identifier Option described in PPP Multilink [3], as factors in selecting the shared secret. If the secret can be deduced by analysis of the communication between the two parties, then no privacy is guaranteed.
通信双方都知道秘密的方式超出了本文件的范围；通常涉及某种形式的手动配置。实现可能使用PPP身份验证或PPP Multilink[3]中描述的端点标识符选项作为选择共享机密的因素。如果通过分析双方之间的通信可以推断出秘密，那么就不能保证隐私。
While the US Data Encryption Standard (DES) algorithm [5, 6] provides multiple modes of use, this specification selects the use of only one mode in conjunction with the PPP Encryption Control Protocol (ECP): the Cipher Block Chaining (CBC) mode. In addition to the US Government publications cited above, the CBC mode is also discussed in [7], although no C source code is provided for it per se.
虽然美国数据加密标准（DES）算法[5,6]提供了多种使用模式，但本规范仅选择一种模式与PPP加密控制协议（ECP）结合使用：密码块链接（CBC）模式。除了上面引用的美国政府出版物外，CBC模式也在[7]中进行了讨论，尽管没有为其本身提供C源代码。
The initialization vector for this mode is deduced from an explicit 64-bit nonce, which is exchanged in the clear during the negotiation phase. The 56-bit key required by all DES modes is established as a shared secret between the implementations.
此模式的初始化向量由显式64位nonce推导而来，该nonce在协商阶段以清除方式交换。所有DES模式所需的56位密钥被确定为实现之间的共享密钥。
One reason for choosing the chaining mode is that it is generally thought to require more computation resources to deduce a 64 bit key used for DES encryption by analysis of the encrypted communication stream when chaining mode is used, compared with the situation where each block is encrypted separately with no chaining. Certainly, identical sequences of plaintext will produce different ciphers when chaining mode is in effect, thus complicating analysis.
选择链接模式的一个原因是，通常认为，与每个块单独加密而没有链接的情况相比，当使用链接模式时，通过分析加密的通信流来推导用于DES加密的64位密钥需要更多的计算资源。当然，当链接模式生效时，相同的明文序列将产生不同的密码，从而使分析复杂化。
However, if chaining is to extend beyond packet boundaries, both the sender and receiver must agree on the order the packets were encrypted. Thus, this specification provides for an explicit 16 bit sequence number to sequence decryption of the packets. This mode of operation even allows recovery from occasional packet loss; details are also given below.
但是，如果链接要扩展到数据包边界之外，则发送方和接收方必须就数据包的加密顺序达成一致。因此，该规范提供了显式的16位序列号来对分组进行序列解密。这种操作模式甚至允许从偶尔的数据包丢失中恢复；详情如下。
The PPP Encryption Control Protocol (ECP), provides a framework for negotiating parameters associated with encryption, such as choosing the algorithm. It specifies the assigned numbers to be used as PPP protocol numbers for the "data packets" to be carried as the associated "data protocol", and describes the state machine.
PPP加密控制协议（ECP）为协商与加密相关的参数（如选择算法）提供了一个框架。它指定了要用作PPP协议编号的分配编号，用于作为关联“数据协议”携带的“数据包”，并描述了状态机。
Thus, a specification for use in that matrix need only describe any additional configuration options required to specify a particular algorithm, and the process by which one encrypts/decrypts the information once the Opened state has been achieved.
因此，在该矩阵中使用的规范只需要描述指定特定算法所需的任何附加配置选项，以及一旦达到打开状态就对信息进行加密/解密的过程。
Description
描述
The ECP DESE Configuration Option indicates that the issuing implementation is offering to employ this specification for decrypting communications on the link, and may be thought of as a request for its peer to encrypt packets in this manner.
ECP DESE配置选项指示发出实现提供使用该规范来解密链路上的通信，并且可以被认为是请求其对等方以这种方式加密分组。
The ECP DESE Configuration Option has the following fields, which are transmitted from left to right:
ECP DESE配置选项具有以下字段，这些字段从左向右传输：
Figure 1: ECP DESE Configuration Option
图1:ECP DESE配置选项
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 = 3 | Length | Initial Nonce ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 = 3 | Length | Initial Nonce ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
类型
Type = 3, to indicate the DESE-bis protocol. The former value 1 indicating the previous DESE specification is deprecated, i.e. systems implementing this specification MUST NOT offer the former value 1 in a configure-request and MUST configure-reject the former value on receipt of a configure-request containing it.
类型=3，表示DESE bis协议。表示先前DESE规范的前一个值1已被弃用，即实现此规范的系统不得在配置请求中提供前一个值1，并且必须在收到包含前一个值的配置请求时配置拒绝前一个值。
Length
长
10
10
Initial Nonce
初始时刻
This field is an 8 byte quantity which is used by the peer implementation to encrypt the first packet transmitted after the sender reaches the opened state.
此字段是一个8字节的数量，对等实现使用它来加密发送方达到打开状态后传输的第一个数据包。
To guard against replay attacks, the implementation SHOULD offer a different value during each ECP negotiation. An example might be to use the number of seconds since Jan 1st, 1970 (GMT/UT) in the upper 32 bits, and the current number of nanoseconds relative to the last second mark in the lower 32 bits.
为了防止重播攻击，实现应该在每次ECP协商期间提供不同的值。例如，在上32位中使用自1970年1月1日以来的秒数（GMT/UT），在下32位中使用相对于最后一秒标记的当前纳秒数。
Its formulaic role is described in the Encryption section below.
下面的加密部分描述了它的公式化作用。
Description
描述
The DESE packets themselves have the following fields:
DESE数据包本身具有以下字段：
Figure 2: DES Encryption Protocol Packet Format
图2:DES加密协议数据包格式
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address | Control | 0000 | Protocol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq. No. High | Seq. No. Low | Ciphertext ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address | Control | 0000 | Protocol ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq. No. High | Seq. No. Low | Ciphertext ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address and Control
地址和控制
These fields MUST be present unless the PPP Address and Control Field Compression option (ACFC) has been negotiated.
除非已协商PPP地址和控制字段压缩选项（ACFC），否则这些字段必须存在。
Protocol ID
协议ID
The value of this field is 0x53 or 0x55; the latter indicates that ciphertext includes headers for the Multilink Protocol, and REQUIRES that the Individual Link Encryption Control Protocol has reached the opened state. The leading zero MAY be absent if the PPP Protocol Field Compression option (PFC) has been negotiated.
该字段的值为0x53或0x55；后者表示密文包含多链路协议的头，并要求单个链路加密控制协议已达到打开状态。如果已协商PPP协议字段压缩选项（PFC），则前导零可能不存在。
Sequence Number
序列号
These 16-bit numbers are assigned by the encryptor sequentially starting with 0 (for the first packet transmitted once ECP has reached the opened state.
这16位数字由加密机按顺序从0开始分配（对于ECP达到打开状态后传输的第一个数据包）。
Ciphertext
密文
The generation of this data is described in the next section.
下一节将描述此数据的生成。
Once the ECP has reached the Opened state, the sender MUST NOT apply the encryption procedure to LCP packets nor ECP packets.
一旦ECP达到打开状态，发送方不得对LCP数据包或ECP数据包应用加密程序。
If the async control character map option has been negotiated on the link, the sender applies mapping after the encryption algorithm has been run.
如果已在链接上协商异步控制字符映射选项，则发送方将在运行加密算法后应用映射。
The encryption algorithm is generally to pad the Protocol and Information fields of a PPP packet to some multiple of 8 bytes, and apply DES in Chaining Block Cipher mode with a 56-bit key K.
加密算法通常是将PPP数据包的协议和信息字段填充到8字节的倍数，并使用56位密钥K以链式分组密码模式应用DES。
There are a lot of details concerning what constitutes the Protocol and Information fields, in the presence or non-presence of Multilink, and whether the ACFC and PFC options have been negotiated, and the sort of padding chosen.
关于协议和信息字段的构成，在多链路存在或不存在的情况下，以及ACFC和PFC选项是否已协商，以及选择的填充类型，有很多详细信息。
Regardless of whether ACFC has been negotiated on the link, the sender applies the encryption procedure to only that portion of the packet excluding the address and control field.
无论是否已在链路上协商ACFC，发送方仅将加密过程应用于数据包的该部分，不包括地址和控制字段。
If the Multilink Protocol has been negotiated and encryption is to be construed as being applied to each link separately, then the encryption procedure is to be applied to the (possibly extended) protocol and information fields of the packet in the Multilink Protocol.
如果已协商多链路协议，并且将加密解释为分别应用于每个链路，则将加密过程应用于多链路协议中的（可能扩展的）协议和分组的信息字段。
If the Multilink Protocol has been negotiated and encryption is to be construed as being applied to the bundle, then the multilink procedure is to be applied to the resulting DESE packets.
如果多链路协议已协商，并且加密将被解释为应用于捆绑包，则多链路过程将应用于生成的DESE数据包。
Since the DES algorithm operates on blocks of 8 octets, plain text packets which are of length not a multiple of 8 octets must be padded. This can be injurious to the interpretation of some protocols which do not contain an explicit length field in their protocol headers.
由于DES算法在8个八位字节的块上运行，因此必须填充长度不是8个八位字节倍数的纯文本数据包。这可能会损害某些协议的解释，这些协议的协议头中不包含显式长度字段。
Since there is no standard directory of protocols which are susceptible to corruption through padding, this can lead to confusion over which protocols should be protected against padding-induced corruption. Consequently, this specification requires that the unambiguous technique described below MUST be applied to ALL plain text packets.
由于没有容易因填充而损坏的协议的标准目录，这可能会导致混淆应该保护哪些协议以防止填充导致的损坏。因此，本规范要求下述明确技术必须应用于所有纯文本数据包。
The method of padding is based on that described for the LCP Self-Describing-Padding (SDP) option (as defined in RFC 1570 [4]), but differs in two respects: first, maximum-pad value is fixed to be 8, and second, the method is to be applied to ALL packets, not just "specifically identified protocols".
填充方法基于LCP自描述填充（SDP）选项（如RFC 1570[4]中所定义）所述的方法，但在两个方面有所不同：第一，最大填充值固定为8，第二，该方法应用于所有数据包，而不仅仅是“特定识别的协议”。
Plain text which is not a multiple of 8 octets long MUST be padded prior to encrypting the plain text with sufficient octets in the sequence of octets 1, 2, 3 ... 7 to make the plain text a multiple of 8 octets.
非8个八位字节的倍数的纯文本必须先填充，然后才能使用八位字节1、2、3…序列中足够的八位字节对纯文本进行加密。。。7将纯文本设置为8个八位字节的倍数。
Plain text which is already a multiple of 8 octets may require padding with a further 8 octets (1, 2, 3 ... 8). These additional octets MUST be appended prior to encrypting the plain text if the last octet of the plain text has a value of 1 through 8, inclusive.
已经是8个八位字节倍数的纯文本可能需要再填充8个八位字节（1、2、3…8）。如果纯文本的最后一个八位字节的值为1到8，则必须在加密纯文本之前附加这些额外的八位字节。
After the peer has decrypted the cipher text, it strips off the Self-Describing-Padding octets, to recreate the original plain text.
对等方解密密文后，它会去掉自描述的填充八位字节，以重新创建原始纯文本。
Note that after decrypting, only the content of the last octet need be examined to determine how many pad bytes should be removed. However, the peer SHOULD discard the frame if all the octets forming the padding do not match the scheme just described.
请注意，解密后，只需检查最后一个八位字节的内容，以确定应删除多少pad字节。但是，如果构成填充的所有八位字节与刚才描述的方案不匹配，则对等方应丢弃帧。
The padding operation described above is performed independently of whether or not the LCP Self-Describing-Padding (SDP) option has been negotiated. If it has, SDP would be applied to the packet as a whole after it had been ciphered and after the Encryption Protocol Identifiers had been prepended.
上述填充操作独立于LCP自描述填充（SDP）选项是否已协商而执行。如果有，SDP将在对数据包进行加密和在加密协议标识符之前应用于整个数据包。
In this discussion, E[k] will denote the basic DES cipher determined by a 56-bit key k acting on 64 bit blocks. and D[k] will denote the corresponding decryption mechanism. The padded plaintext described in the previous section then becomes a sequence of 64 bit blocks P[i] (where i ranges from 1 to n). The circumflex character (^) represents the bit-wise exclusive-or operation applied to 64-bit blocks.
在本讨论中，E[k]将表示由作用于64位块的56位密钥k确定的基本DES密码。D[k]表示相应的解密机制。上一节中描述的填充明文随后成为64位块P[i]的序列（其中i的范围为1到n）。扬抑符（^）表示应用于64位块的逐位异或运算。
When encrypting the first packet to be transmitted in the opened state let C[0] be the result of applying E[k] to the Initial Nonce received in the peer's ECP DESE option; otherwise let C[0] be the final block of the previously transmitted packet.
当在打开状态下加密要发送的第一个分组时，让C[0]是将E[k]应用于对等方的ECP DESE选项中接收的初始Nonce的结果；否则，设C[0]为先前发送的分组的最后一个块。
The ciphertext for the packet is generated by the iterative process
数据包的密文是通过迭代过程生成的
C[i] = E[k](P[i] ^ C[i-1])
C[i] = E[k](P[i] ^ C[i-1])
for i running between 1 and n.
因为我在1和n之间运行。
When decrypting the first packet received in the opened state, let C[0] be the result of applying E[k] to the Initial Nonce transmitted in the ECP DESE option. The first packet will have sequence number zero. For subsequent packets, let C[0] be the final block of the previous packet in sequence space. Decryption is then accomplished by
当解密在打开状态下接收的第一个分组时，设C[0]是将E[k]应用于在ECP DESE选项中传输的初始Nonce的结果。第一个数据包的序列号为零。对于后续数据包，设C[0]为序列空间中前一数据包的最后一个块。然后通过以下方式完成解密：
P[i] = C[i-1] ^ D[k](C[i]),
P[i]=C[i-1]^D[k]（C[i]），
for i running between 1 and n.
因为我在1和n之间运行。
Packet loss is detected when there is a discontinuity in the sequence numbers of consecutive packets. Suppose packet number N - 1 has an unrecoverable error or is otherwise lost, but packets N and N + 1 are received correctly.
当连续数据包的序列号不连续时，检测到数据包丢失。假设数据包编号N-1有不可恢复的错误或丢失，但数据包N和N+1被正确接收。
Since the algorithm in the previous section requires C[0] for packet N to be C[last] for packet N - 1, it will be impossible to decode packet N. However, all packets N + 1 and following can be decoded in the usual way, since all that is required is the last block of ciphertext of the previous packet (in this case packet N, which WAS received).
由于上一节中的算法要求数据包N的C[0]为数据包N-1的C[last]，因此不可能对数据包N进行解码。然而，所有数据包N+1及其后的数据包都可以用通常的方式进行解码，因为所需的只是上一个数据包（在本例中，数据包N已被接收）的最后一个密文块。
Because padding can occur, and because there is an additional protocol field in effect, implementations should take into account the growth of the packets. As an example, if PFC had been negotiated, and if the MRU before had been exactly a multiple of 8, then the plaintext resulting combining a full sized data packets with a one byte protocol field would require an additional 7 bytes of padding, and the sequence number would be an additional 2 bytes so that the information field in the DESE protocol is now 10 bytes larger than that in the original packet. Because the convention is that PPP options are independent of each other, negotiation of DESE does not, by itself, automatically increase the MRU value.
由于可能会发生填充，并且由于存在一个有效的附加协议字段，所以实现应该考虑数据包的增长。例如，如果已经协商PFC，并且如果之前的MRU正好是8的倍数，那么将全尺寸数据包与一个字节的协议字段相结合所产生的明文将需要额外的7字节填充，序列号将是额外的2个字节，因此DESE协议中的信息字段现在比原始数据包中的信息字段大10个字节。由于PPP期权相互独立，因此DESE谈判本身不会自动增加MRU值。
In RFC 1969, the method of Self-Describing Padding was not applied to all packets transmitted using DESE. Following the method of the SDP option itself, only "specifically identified protocols", were to be padded. Protocols with an explicit length identifier were exempt. (Examples included non-VJ-compressed IP, XNS, CLNP).
在RFC 1969中，自描述填充的方法并没有应用于使用DESE传输的所有数据包。按照SDP选项本身的方法，只需填充“特别确定的协议”。具有显式长度标识符的协议被豁免。（示例包括非VJ压缩IP、XNS、CLNP）。
In this speficiation, the method is applied to ALL packets.
在此说明中，该方法应用于所有数据包。
Secondly, this specification is clarified as being completely independent of the Self-Describing-Padding option for PPP, and fixes the maximum number of padding octets as 8.
其次，该规范被澄清为完全独立于PPP的自描述填充选项，并将填充八位字节的最大数量固定为8。
Since this specification could theoretically cause misinterpretation of a packet transmitted according to the previous specification, a new type field number has been assigned for the DESE-bis protocol
由于该规范在理论上可能导致对根据先前规范传输的分组的错误解释，因此已经为DESE bis协议分配了新类型的字段号
This specification has been designated a standards track document. Some other language has been changed for greater clarity.
本规范被指定为标准跟踪文件。为了更加清晰，其他一些语言也作了修改。
This proposal is concerned with providing confidentiality solely. It does not describe any mechanisms for integrity, authentication or nonrepudiation. It does not guarantee that any message received has not been modified in transit through replay, cut-and-paste or active
本提案仅涉及保密。它没有描述任何完整性、身份验证或不可否认性机制。它不保证接收到的任何消息在传输过程中未通过重播、剪切粘贴或激活进行修改
tampering. It does not provide authentication of the source of any packet received, or protect against the sender of any packet denying its authorship.
篡改。它不提供对接收到的任何数据包的源的身份验证，也不防止任何数据包的发送方拒绝其作者身份。
This proposal relies on exterior and unspecified methods for authentication and retrieval of shared secrets. It proposes no new technology for privacy, but merely describes a convention for the application of the DES cipher to data transmission between PPP implementation.
该方案依赖外部和未指定的方法来验证和检索共享机密。它没有提出新的隐私技术，只是描述了一种将DES密码应用于PPP实现之间的数据传输的约定。
Any methodology for the protection and retrieval of shared secrets, and any limitations of the DES cipher are relevant to the use described here.
保护和检索共享机密的任何方法以及DES密码的任何限制都与此处描述的使用有关。
[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] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 1996.
[2] Meyer，G.，“PPP加密协议（ECP）”，RFC 1968，1996年6月。
[3] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[3] K.Sklower、Lloyd、B.McGregor、G.Carr、D.和T.Coradetti，“PPP多链路协议（MP）”，RFC 1990，1996年8月。
[4] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1994.
[4] 辛普森，W.，编辑，“PPP LCP扩展”，RFC 15701994年1月。
[5] National Bureau of Standards, "Data Encryption Standard", FIPS PUB 46 (January 1977).
[5] 国家标准局，“数据加密标准”，FIPS PUB 46（1977年1月）。
[6] National Bureau of Standards, "DES Modes of Operation", FIPS PUB 81 (December 1980).
[6] 国家标准局，“DES运行模式”，FIPS PUB 81（1980年12月）。
[7] Schneier, B., "Applied Cryptography - Protocols Algorithms, and source code in C", John Wiley & Sons, Inc. 1994. There is an errata associated with the book, and people can get a copy by sending e-mail to schneier@counterpane.com.
[7] Schneier，B.，“应用密码学-协议算法和C语言源代码”，John Wiley&Sons，Inc.1994。这本书有一个相关的勘误表，人们可以通过发送电子邮件到schneier@counterpane.com.
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[8] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Keith Sklower Computer Science Department 339 Soda Hall, Mail Stop 1776 University of California Berkeley, CA 94720-1776
基思斯科尔计算机科学系339苏打厅，邮件停止1776加利福尼亚大学伯克利，CA 947 20 1776
Phone: (510) 642-9587 EMail: sklower@CS.Berkeley.EDU
电话：（510）642-9587电子邮件：sklower@CS.Berkeley.EDU
Gerry M. Meyer Cisco Systems Ltd. Bothwell House, Pochard Way, Strathclyde Business Park, Bellshill, ML4 3HB Scotland, UK
Gerry M.Meyer Cisco系统有限公司位于英国苏格兰ML4 3HB贝尔希尔斯特拉斯克莱德商业园波查德路博思韦尔大厦
Phone: (UK) (pending) Fax: (UK) (pending) Email: gemeyer@cisco.com
电话：（英国）（待定）传真：（英国）（待定）电子邮件：gemeyer@cisco.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
版权所有（C）互联网协会（1998年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。