[要約] RFC 2419は、PPP DES Encryption Protocolのバージョン2（DESE-bis）に関する仕様を提供しています。このプロトコルは、PPP接続を暗号化するためにDESアルゴリズムを使用します。目的は、セキュアな通信を確保することです。
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.
Copyright（C）The Internet Society（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.
このドキュメントは、PPPカプセル化パケットを暗号化するためのDES標準[5、6]の使用に関する特定の詳細を提供します。
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.
ドキュメントの明確さと正確さの改善に役立つ、シスコのフレッドベイカー、フローポイントのフィリップレイキティ、デイドリームのウィリアムシンプソンに感謝します。
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
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.
このメモの目的は2つあります。一般的なPPP暗号化制御プロトコルのコンテキストを前提として、「データ」または「ベアラ」プロトコルの必要な詳細を指定する方法を示すことと、少なくとも1つの一般的に理解されている手段を提供すること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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 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 secret (usually involving at least a key) between the sender and receiver.
2つのPPP実装間で交換されるパケットを暗号化する目的は、2つの実装を介して行われる通信のプライバシーを保証することです。暗号化プロセスは、暗号化アルゴリズムの仕様と、送信者と受信者の間の共有シークレット（通常は少なくともキーを含む）に依存します。
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マルチリンク[3]で説明されているEndPoint Identifier Optionを利用する場合があります。秘密が2つのパーティ間の通信の分析によって推定できる場合、プライバシーは保証されません。
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.
US Data Encryption Standard（DES）アルゴリズム[5、6]は複数の使用モードを提供しますが、この仕様では、PPP暗号化制御プロトコル（ECP）と組み合わせて1つのモード、Cipher Block Chaining（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から推定され、ネゴシエーションフェーズ中に平文で交換されます。すべての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.
連鎖モードを選択する1つの理由は、各ブロックが暗号化されている状況と比較して、連鎖モードが使用されている場合、暗号化された通信ストリームの分析によって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.
したがって、そのマトリックスで使用する仕様は、特定のアルゴリズムを指定するために必要な追加の構成オプションと、Opened状態が達成された後に情報を暗号化/復号化するプロセスのみを記述する必要があります。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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は非推奨です。つまり、この仕様を実装するシステムは、configure-requestで以前の値1を提供してはならず、それを含むconfigure-requestの受信時に以前の値をconfigure-rejectしなければなりません。
Length
長さ
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ネゴシエーション中に異なる値を提供する必要があります（SHOULD）。例としては、1970年1月1日（GMT / UT）からの秒数を上位32ビットで使用し、現在のナノ秒数を下位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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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がOpened状態に達すると、送信者はLCPパケットにもECPパケットにも暗号化手順を適用してはなりません（MUST NOT）。
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 Self-Describing-Padding（SDP）オプション（RFC 1570 [4]で定義）で説明されている方法に基づいていますが、2つの点で異なります。最初に、最大パッド値は8に固定されています。 2番目に、この方法は「特定のプロトコル」だけでなく、すべてのパケットに適用されます。
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オクテットの倍数でないプレーンテキストは、プレーンテキストを8オクテットの倍数にするために、オクテット1、2、3 ... 7のシーケンスで十分なオクテットで暗号化する前にパディングする必要があります。
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.
ピアが暗号テキストを復号化した後、ピアはSelf-Describing-Paddingオクテットを取り除き、元のプレーンテキストを再作成します。
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.
復号化後、削除する必要のあるパッドバイト数を決定するには、最後のオクテットの内容のみを調べる必要があることに注意してください。ただし、パディングを形成するすべてのオクテットが上記のスキームと一致しない場合、ピアはフレームを破棄する必要があります（SHOULD）。
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.
オープン状態で送信される最初のパケットを暗号化する場合、ピアのECP DESEオプションで受信された初期ナンスにE [k]を適用した結果をC [0]とします。そうでない場合は、C [0]を前に送信したパケットの最後のブロックにします。
The ciphertext for the packet is generated by the iterative process
パケットの暗号文は反復プロセスによって生成されます
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
開いた状態で受信した最初のパケットを復号化するとき、ECP DESEオプションで送信された初期ナンスにE [k]を適用した結果をC [0]とします。最初のパケットのシーケンス番号はゼロになります。後続のパケットでは、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以降はすべて、通常の方法です。必要なのは、前のパケット（この場合はWASが受信したパケット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の倍数であった場合、フルサイズのデータパケットと1バイトのプロトコルフィールドを組み合わせたプレーンテキストは、追加の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.
第2に、この仕様は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.
この提案は、共有シークレットの認証と取得のための外部の指定されていない方法に依存しています。プライバシーのための新しいテクノロジーは提案されていませんが、PPP実装間のデータ伝送にDES暗号を適用するための規約を説明しているだけです。
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 1661、1994年7月。
[2] Meyer, G., "The PPP Encryption Protocol (ECP)", RFC 1968, June 1996.
[2] Meyer、G。、「The PPP Encryption Protocol（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] Sklower、K.、Lloyd、B.、McGregor、G.、Carr、D.、and T. Coradetti、 "The PPP Multilink Protocol（MP）"、RFC 1990、August 1996。
[4] Simpson, W., Editor, "PPP LCP Extensions", RFC 1570, January 1994.
[4] シンプソン、W、編集者、「PPP LCP拡張機能」、RFC 1570、1994年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 Modes of Operation」、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。、「Applied Cryptography-Protocols Algorithms、and source code in 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カリフォルニア大学バークレー、カリフォルニア94720-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 Systems Ltd. Bothwell House、Pochard Way、Strathclyde Business Park、Bellshill、ML4 3HBスコットランド、英国
Phone: (UK) (pending) Fax: (UK) (pending) Email: gemeyer@cisco.com
電話：（英国）（保留）ファックス：（英国）（保留）メール：gemeyer@cisco.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。