[要約] RFC 7820は、OWAMPとTWAMPにおけるUDPチェックサムの補数について説明しています。このRFCの目的は、ネットワークのパフォーマンス測定における正確性と信頼性を向上させることです。
Internet Engineering Task Force (IETF) T. Mizrahi
Request for Comments: 7820 Marvell
Category: Experimental March 2016
ISSN: 2070-1721
UDP Checksum Complement in the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)
一方向アクティブ測定プロトコル（OWAMP）および双方向アクティブ測定プロトコル（TWAMP）のUDPチェックサム補完
Abstract
概要
The One-Way Active Measurement Protocol (OWAMP) and the Two-Way Active Measurement Protocol (TWAMP) are used for performance monitoring in IP networks. Delay measurement is performed in these protocols by using timestamped test packets. Some implementations use hardware-based timestamping engines that integrate the accurate transmission time into every outgoing OWAMP/TWAMP test packet during transmission. Since these packets are transported over UDP, the UDP Checksum field is then updated to reflect this modification. This document proposes to use the last 2 octets of every test packet as a Checksum Complement, allowing timestamping engines to reflect the checksum modification in the last 2 octets rather than in the UDP Checksum field. The behavior defined in this document is completely interoperable with existing OWAMP/TWAMP implementations.
一方向アクティブ測定プロトコル（OWAMP）および双方向アクティブ測定プロトコル（TWAMP）は、IPネットワークのパフォーマンス監視に使用されます。これらのプロトコルでは、タイムスタンプ付きのテストパケットを使用して遅延測定が実行されます。一部の実装では、ハードウェアベースのタイムスタンプエンジンを使用して、送信中にすべての発信OWAMP / TWAMPテストパケットに正確な送信時間を統合します。これらのパケットはUDPを介して転送されるため、UDPチェックサムフィールドはこの変更を反映するように更新されます。このドキュメントでは、すべてのテストパケットの最後の2オクテットをチェックサム補完として使用することを提案しています。これにより、タイムスタンプエンジンがチェックサムの変更をUDPチェックサムフィールドではなく最後の2オクテットに反映できるようになります。このドキュメントで定義されている動作は、既存のOWAMP / TWAMP実装と完全に相互運用できます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7820.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7820で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................5
2.1. Terminology ................................................5
2.2. Abbreviations ..............................................5
3. Using the UDP Checksum Complement in OWAMP and TWAMP ............6
3.1. Overview ...................................................6
3.2. OWAMP/TWAMP Test Packets with Checksum Complement ..........6
3.2.1. Transmission of OWAMP/TWAMP with Checksum
Complement .........................................10
3.2.2. Intermediate Updates of OWAMP/TWAMP with
Checksum Complement ................................10
3.2.3. Reception of OWAMP/TWAMP with Checksum Complement ..10
3.3. Interoperability with Existing Implementations ............10
3.4. Using the Checksum Complement with or without
Authentication ............................................11
3.4.1. Checksum Complement in Authenticated Mode ..........11
3.4.2. Checksum Complement in Encrypted Mode ..............11
4. Security Considerations ........................................12
5. References .....................................................12
5.1. Normative References ......................................12
5.2. Informative References ....................................13
Appendix A. Checksum Complement Usage Example .....................14
Acknowledgments ...................................................15
Author's Address ..................................................15
The One-Way Active Measurement Protocol [OWAMP] and the Two-Way Active Measurement Protocol [TWAMP] are used for performance monitoring in IP networks.
一方向アクティブ測定プロトコル[OWAMP]および双方向アクティブ測定プロトコル[TWAMP]は、IPネットワークのパフォーマンス監視に使用されます。
Delay and delay variation are two of the metrics that OWAMP/TWAMP can measure. Measurement is performed using timestamped test packets. In some use cases, such as carrier networks, these two metrics are an essential aspect of the Service Level Agreement (SLA) and therefore must be measured with a high degree of accuracy. If packets are timestamped in hardware as they exit the host, then greater accuracy is possible in comparison to higher-layer timestamps (as explained further below).
遅延と遅延変動は、OWAMP / TWAMPが測定できる2つのメトリックです。タイムスタンプ付きのテストパケットを使用して測定が実行されます。キャリアネットワークなどの一部のユースケースでは、これら2つのメトリックはサービスレベルアグリーメント（SLA）の重要な側面であるため、高い精度で測定する必要があります。ホストを出るときにパケットにハードウェアでタイムスタンプを付けると、上位層のタイムスタンプと比較してより高い精度が可能になります（以下でさらに説明します）。
The accuracy of delay measurements relies on the timestamping method and its implementation. In order to facilitate accurate timestamping, an implementation can use a hardware-based timestamping engine, as shown in Figure 1. In such cases, the OWAMP/TWAMP packets are sent and received by a software layer, whereas the timestamping engine modifies every outgoing test packet by incorporating its accurate transmission time into the Timestamp field in the packet.
遅延測定の精度は、タイムスタンプ方式とその実装に依存しています。正確なタイムスタンプを容易にするために、実装ではハードウェアベースのタイムスタンプエンジンを使用できます（図1を参照）。このような場合、OWAMP / TWAMPパケットはソフトウェアレイヤーで送受信され、タイムスタンプエンジンはすべての発信テストを変更します。正確な送信時間をパケットのタイムスタンプフィールドに組み込むことにより、パケットを送信します。
OWAMP/TWAMP-enabled Node
+-------------------+
| |
| +-----------+ |
Software | |OWAMP/TWAMP| |
| | protocol | |
| +-----+-----+ |
| | | +-----------------------+
| +-----+-----+ | / Intermediate entity |
| | Accurate | | / in charge of: |
ASIC/FPGA | | Timestamp | | /__ - Timestamping |
| | engine | | |- Updating checksum or |
| +-----------+ | | Checksum Complement |
| | | +-----------------------+
+---------+---------+
|
|test packets
|
___ v _
/ \_/ \__
/ \_
/ IP /
\_ Network /
/ \
\__/\_ ___/
\_/
ASIC: Application-Specific Integrated Circuit FPGA: Field-Programmable Gate Array
ASIC：特定用途向け集積回路FPGA：フィールドプログラマブルゲートアレイ
Figure 1: Accurate Timestamping in OWAMP/TWAMP
図1：OWAMP / TWAMPでの正確なタイムスタンプ
OWAMP/TWAMP test packets are transported over UDP. When the UDP payload is changed by an intermediate entity such as the timestamping engine, the UDP Checksum field must be updated to reflect the new payload. When using UDP over IPv4 [UDP], an intermediate entity that cannot update the value of the UDP Checksum has no choice except to assign a value of zero to the Checksum field, causing the receiver to ignore the Checksum field and potentially accept corrupted packets. UDP over IPv6, as defined in [IPv6], does not allow a zero checksum, except in specific cases [ZeroChecksum]. As discussed in [ZeroChecksum], the use of a zero checksum is generally not recommended and should be avoided to the extent possible.
OWAMP / TWAMPテストパケットはUDPを介して転送されます。タイムスタンプエンジンなどの中間エンティティによってUDPペイロードが変更された場合、UDPチェックサムフィールドを更新して、新しいペイロードを反映する必要があります。 UDP over IPv4 [UDP]を使用する場合、UDPチェックサムの値を更新できない中間エンティティは、チェックサムフィールドにゼロの値を割り当てる以外に選択肢がなく、受信者はチェックサムフィールドを無視し、破損したパケットを受け入れる可能性があります。 [IPv6]で定義されているUDP over IPv6は、特定の場合[ZeroChecksum]を除いて、ゼロチェックサムを許可しません。 [ZeroChecksum]で説明したように、ゼロチェックサムの使用は一般に推奨されておらず、可能な限り回避する必要があります。
Since an intermediate entity only modifies a specific field in the packet, i.e., the Timestamp field, the UDP Checksum update can be performed incrementally, using the concepts presented in [Checksum].
中間エンティティはパケット内の特定のフィールド、つまりタイムスタンプフィールドのみを変更するため、[チェックサム]に示されている概念を使用して、UDPチェックサム更新を段階的に実行できます。
A similar problem is addressed in Annex E of [IEEE1588]. When the Precision Time Protocol (PTP) is transported over IPv6, 2 octets are appended to the end of the PTP payload for UDP Checksum updates. The value of these 2 octets can be updated by an intermediate entity, causing the value of the UDP Checksum field to remain correct.
[IEEE1588]のAnnex Eでも同様の問題が扱われています。プレシジョンタイムプロトコル（PTP）がIPv6を介して転送される場合、UDPチェックサム更新のために2オクテットがPTPペイロードの最後に追加されます。これらの2つのオクテットの値は、中間エンティティによって更新され、UDPチェックサムフィールドの値が正しいままになる可能性があります。
This document defines a similar concept for [OWAMP] and [TWAMP], allowing intermediate entities to update OWAMP/TWAMP test packets and maintain the correctness of the UDP Checksum by modifying the last 2 octets of the packet.
このドキュメントでは、[OWAMP]と[TWAMP]の同様の概念を定義し、中間エンティティがOWAMP / TWAMPテストパケットを更新し、パケットの最後の2オクテットを変更してUDPチェックサムの正確性を維持できるようにします。
The term "Checksum Complement" is used throughout this document and refers to the 2 octets at the end of the UDP payload, used for updating the UDP Checksum by intermediate entities.
「チェックサム補完」という用語は、このドキュメント全体で使用されており、中間エンティティによるUDPチェックサムの更新に使用される、UDPペイロードの最後の2オクテットを指します。
The usage of the Checksum Complement can in some cases simplify the implementation, because if the packet data is processed in serial order, it is simpler to first update the Timestamp field and then update the Checksum Complement, rather than to update the timestamp and then update the UDP Checksum residing at the UDP header.
パケットデータがシリアル順に処理される場合、タイムスタンプを更新してから更新するのではなく、最初にタイムスタンプフィールドを更新してからチェックサム補完を更新する方が簡単であるため、チェックサム補完の使用により、実装が簡素化される場合があります。 UDPヘッダーにあるUDPチェックサム。
The Checksum Complement mechanism is also defined for the Network Time Protocol in [RFC7821].
チェックサム補完メカニズムは、[RFC7821]のネットワークタイムプロトコルにも定義されています。
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 [KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [キーワード]で説明されているように解釈されます。
HMAC Hashed Message Authentication Code
HMACハッシュメッセージ認証コード
OWAMP One-Way Active Measurement Protocol
OWAMP一方向アクティブ測定プロトコル
PTP Precision Time Protocol
PTPプレシジョンタイムプロトコル
TWAMP Two-Way Active Measurement Protocol
TWAMP双方向アクティブ測定プロトコル
UDP User Datagram Protocol
UDPユーザーデータグラムプロトコル
The UDP Checksum Complement is a 2-octet field that is piggybacked at the end of the test packet. It resides in the last 2 octets of the UDP payload.
UDPチェックサム補完は、テストパケットの最後に便乗される2オクテットのフィールドです。 UDPペイロードの最後の2オクテットに存在します。
+----------------------------------+
| IPv4/IPv6 Header |
+----------------------------------+
| UDP Header |
+----------------------------------+
^ | |
| | OWAMP/TWAMP |
UDP | packet |
Payload +----------------------------------+
| |UDP Checksum Complement (2 octets)|
v +----------------------------------+
Figure 2: Checksum Complement in OWAMP/TWAMP Test Packets
図2：OWAMP / TWAMPテストパケットのチェックサム補完
The Checksum Complement is used to compensate for changes performed in the packet by intermediate entities, as described in the Introduction (Section 1). An example of the usage of the Checksum Complement is provided in Appendix A.
概要（セクション1）で説明されているように、チェックサム補完は、中間エンティティによってパケットで実行された変更を補正するために使用されます。チェックサム補完の使用例は、付録Aにあります。
The One-Way Active Measurement Protocol [OWAMP] and the Two-Way Active Measurement Protocol [TWAMP] both make use of timestamped test packets. A Checksum Complement MAY be used in the following cases:
一方向アクティブ測定プロトコル[OWAMP]と双方向アクティブ測定プロトコル[TWAMP]は、どちらもタイムスタンプ付きのテストパケットを使用します。チェックサム補数は、次の場合に使用できます。
o In OWAMP test packets sent by the sender to the receiver.
o OWAMPでは、送信者から受信者に送信されるテストパケット。
o In TWAMP test packets sent by the sender to the reflector.
o TWAMPでは、送信者がリフレクターに送信したテストパケット。
o In TWAMP test packets sent by the reflector to the sender.
o TWAMPでは、リフレクターから送信者に送信されるテストパケット。
OWAMP/TWAMP test packets are transported over UDP, either over IPv4 or over IPv6. This document applies to both OWAMP and TWAMP over IPv4 and over IPv6.
OWAMP / TWAMPテストパケットは、IPv4またはIPv6のいずれかでUDPを介して転送されます。このドキュメントは、IPv4およびIPv6上のOWAMPとTWAMPの両方に適用されます。
OWAMP/TWAMP test packets contain a Packet Padding field. This document proposes to use the last 2 octets of the Packet Padding field as the Checksum Complement. In this case, the Checksum Complement is always the last 2 octets of the UDP payload, and thus the field is located at (UDP Length - 2 octets) after the beginning of the UDP header.
OWAMP / TWAMPテストパケットには、Packet Paddingフィールドが含まれています。このドキュメントでは、チェックサム補完としてパケットパディングフィールドの最後の2オクテットを使用することを提案しています。この場合、チェックサムコンプリメントは常にUDPペイロードの最後の2オクテットであるため、フィールドはUDPヘッダーの先頭の（UDP長さ-2オクテット）にあります。
Figure 3 illustrates the OWAMP test packet format, including the UDP Checksum Complement.
図3は、UDPチェックサム補完を含むOWAMPテストパケット形式を示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
. Packet Padding .
. .
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Checksum Complement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Checksum Complement in OWAMP Test Packets
図3：OWAMPテストパケットのチェックサム補完
Figure 4 illustrates the TWAMP test packet format, including the UDP Checksum Complement. ("TTL" means "Time to Live", and "MBZ" refers to the "MUST be zero" field [IPPMIPsec].)
図4は、UDPチェックサム補完を含むTWAMPテストパケット形式を示しています。 （「TTL」は「存続時間」を意味し、「MBZ」は「ゼロでなければならない」フィールド[IPPMIPsec]を意味します。）
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receive Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Timestamp |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Error Estimate | MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender TTL | |
+-+-+-+-+-+-+-+-+ +
| |
. .
. Packet Padding .
. .
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Checksum Complement |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Checksum Complement in TWAMP Test Packets
図4：TWAMPテストパケットのチェックサム補完
The length of the Packet Padding field in test packets is announced during the session initiation through the <Padding Length> field in the Request-Session message [OWAMP] or in the Request-TW-Session message [TWAMP].
テストパケットのパケットパディングフィールドの長さは、セッション開始時に、Request-Sessionメッセージ[OWAMP]またはRequest-TW-Sessionメッセージ[TWAMP]の<Padding Length>フィールドを介して通知されます。
When a Checksum Complement is included, the padding length MUST be sufficiently long to include the Checksum Complement:
チェックサム補完が含まれる場合、パディングの長さはチェックサム補完を含めるのに十分な長さでなければなりません：
o In OWAMP, the padding length is at least 2 octets, allowing the sender to incorporate the Checksum Complement in the last 2 octets of the padding.
o OWAMPでは、パディングの長さは少なくとも2オクテットであるため、送信者はパディングの最後の2オクテットにチェックサム補完を組み込むことができます。
o In TWAMP, the padding length is at least 29 octets in unauthenticated mode and at least 58 octets in authenticated mode. The additional padding is required, since the header of reflector test packets is longer than the header of sender test packets. The difference between the sender packet and the reflector packet is 27 octets in unauthenticated mode and 56 octets in authenticated mode. Thus, the padding in reflector test packets is shorter than the padding in sender packets. Using at least 29 octets of padding (58 in authenticated mode) in sender test packets allows both the sender and the reflector to use a 2-octet Checksum Complement. Note: If the minimal length requirement is not met, the reflector cannot use a Checksum Complement in the reflected test packets, but the sender can use a Checksum Complement in the test packets it transmits.
o TWAMPでは、パディングの長さは、非認証モードでは少なくとも29オクテット、認証モードでは少なくとも58オクテットです。リフレクターテストパケットのヘッダーは送信者テストパケットのヘッダーよりも長いため、追加のパディングが必要です。送信側パケットとリフレクターパケットの違いは、非認証モードでは27オクテット、認証モードでは56オクテットです。したがって、リフレクタテストパケットのパディングは、送信者パケットのパディングよりも短くなります。送信者テストパケットで少なくとも29オクテットのパディング（認証モードでは58オクテット）を使用すると、送信者とリフレクターの両方で2オクテットのチェックサム補完を使用できます。注：最小長の要件が満たされていない場合、リフレクターは反射されたテストパケットでチェックサムコンプリメントを使用できませんが、送信者は送信するテストパケットでチェックサムコンプリメントを使用できます。
o Two optional TWAMP features are defined in [TWAMP-Reflect]: octet reflection and symmetrical size. When at least one of these features is enabled, the Request-TW-Session message includes the <Padding Length> field, as well as a <Length of padding to reflect> field. In this case, both fields must be sufficiently long to allow at least 2 octets of padding in both sender test packets and reflector test packets. Specifically, when octet reflection is enabled, the two Length fields must be defined such that the padding expands at least 2 octets beyond the end of the reflected octets.
o [TWAMP-Reflect]には、オクテット反射と対称サイズという2つのオプションのTWAMP機能が定義されています。これらの機能の少なくとも1つが有効になっている場合、Request-TW-Sessionメッセージには、<Padding Length>フィールドと、<Length of padding to exclude>フィールドが含まれます。この場合、両方のフィールドは、送信者テストパケットとリフレクターテストパケットの両方で少なくとも2オクテットのパディングを許可するのに十分な長さである必要があります。具体的には、オクテット反射が有効になっている場合、パディングが反射オクテットの終わりを超えて少なくとも2オクテット拡大するように、2つの長さフィールドを定義する必要があります。
As described in Section 1, the extensions described in this document are implemented by two logical layers -- a protocol layer and a timestamping layer. It is assumed that the two layers are synchronized regarding whether the usage of the Checksum Complement is enabled or not; since both logical layers reside in the same network device, it is assumed that there is no need for a protocol that synchronizes this information between the two layers. When Checksum Complement usage is enabled, the protocol layer must take care to verify that test packets include the necessary padding, thereby avoiding the need for the timestamping layer to verify that en-route test packets include the necessary padding.
セクション1で説明したように、このドキュメントで説明する拡張機能は、プロトコルレイヤーとタイムスタンプレイヤーという2つの論理レイヤーによって実装されます。チェックサム補完の使用が有効かどうかに関して、2つの層が同期していると想定されています。両方の論理層が同じネットワークデバイスに存在するため、2つの層の間でこの情報を同期するプロトコルは不要であると想定されています。チェックサム補完の使用が有効になっている場合、プロトコルレイヤーは、テストパケットに必要なパディングが含まれていることを確認するように注意を払う必要があります。
The transmitter of an OWAMP/TWAMP test packet MAY include a Checksum Complement field, incorporated in the last 2 octets of the padding.
OWAMP / TWAMPテストパケットの送信機は、パディングの最後の2オクテットに組み込まれたチェックサム補完フィールドを含めることができます。
A transmitter that includes a Checksum Complement in its outgoing test packets MUST include a Packet Padding field in these packets, the length of which MUST be sufficient to include the Checksum Complement. The length of the Packet Padding field is negotiated during session initiation, as described in Section 3.2.
発信テストパケットにチェックサムコンプリメントを含むトランスミッタは、これらのパケットにパケットパディングフィールドを含める必要があり、その長さはチェックサムコンプリメントを含めるのに十分でなければなりません（MUST）。パケットパディングフィールドの長さは、セクション3.2で説明されているように、セッションの開始時にネゴシエートされます。
An intermediate entity that receives and alters an OWAMP/TWAMP test packet can alter either the UDP Checksum field or the Checksum Complement field in order to maintain the correctness of the UDP Checksum value.
OWAMP / TWAMPテストパケットを受信して変更する中間エンティティは、UDPチェックサム値の正確さを維持するために、UDPチェックサムフィールドまたはチェックサム補完フィールドのいずれかを変更できます。
This document does not impose new requirements on the receiving end of an OWAMP/TWAMP test packet.
このドキュメントでは、OWAMP / TWAMPテストパケットの受信側に新しい要件を課していません。
The UDP layer at the receiving end verifies the UDP Checksum of received test packets, and the OWAMP/TWAMP layer should treat the Checksum Complement as part of the padding.
受信側のUDP層は受信したテストパケットのUDPチェックサムを検証し、OWAMP / TWAMP層はチェックサム補完をパディングの一部として扱う必要があります。
The behavior defined in this document does not impose new requirements on the reception behavior of OWAMP/TWAMP test packets. The protocol stack of the receiving host performs the conventional UDP Checksum verification; thus, from the perspective of the receiving host, the existence of the Checksum Complement is transparent. Therefore, the functionality described in this document allows interoperability with existing implementations that comply with [OWAMP] or [TWAMP].
このドキュメントで定義されている動作は、OWAMP / TWAMPテストパケットの受信動作に新しい要件を課すものではありません。受信ホストのプロトコルスタックは、従来のUDPチェックサム検証を実行します。したがって、受信側ホストの観点からは、チェックサム補完の存在は透過的です。したがって、このドキュメントで説明する機能により、[OWAMP]または[TWAMP]に準拠する既存の実装との相互運用が可能になります。
Both OWAMP and TWAMP may use authentication or encryption, as defined in [OWAMP] and [TWAMP].
OWAMPとTWAMPはどちらも、[OWAMP]と[TWAMP]で定義されている認証または暗号化を使用できます。
OWAMP and TWAMP test packets can be authenticated using an HMAC (Hashed Message Authentication Code). The HMAC covers some of the fields in the test packet header. The HMAC does not cover the Timestamp field and the Packet Padding field.
OWAMPおよびTWAMPテストパケットは、HMAC（ハッシュメッセージ認証コード）を使用して認証できます。 HMACは、テストパケットヘッダーの一部のフィールドをカバーしています。 HMACは、タイムスタンプフィールドとパケットパディングフィールドをカバーしません。
A Checksum Complement MAY be used when authentication is enabled. In this case, an intermediate entity can timestamp test packets and update their Checksum Complement field without modifying the HMAC.
認証が有効な場合は、チェックサム補完が使用される場合があります。この場合、中間エンティティは、HMACを変更せずに、テストパケットにタイムスタンプを付け、チェックサム補完フィールドを更新できます。
When OWAMP and TWAMP are used in encrypted mode, the Timestamp field is encrypted.
OWAMPおよびTWAMPが暗号化モードで使用される場合、タイムスタンプフィールドは暗号化されます。
A Checksum Complement SHOULD NOT be used in encrypted mode. The Checksum Complement is effective in both unauthenticated mode and authenticated mode, allowing the intermediate entity to perform serial processing of the packet without storing and forwarding it.
チェックサム補数は、暗号化モードでは使用しないでください。チェックサム補完は非認証モードと認証モードの両方で有効であり、中間エンティティがパケットを保存および転送せずにシリアル処理を実行できるようにします。
On the other hand, in encrypted mode, an intermediate entity that timestamps a test packet must also re-encrypt the packet accordingly. Re-encryption typically requires the intermediate entity to store the packet, re-encrypt it, and then forward it. Thus, from an implementer's perspective, the Checksum Complement has very little value in encrypted mode, as it does not necessarily simplify the implementation.
一方、暗号化モードでは、テストパケットにタイムスタンプを付ける中間エンティティも、それに応じてパケットを再暗号化する必要があります。再暗号化では、通常、中間エンティティがパケットを格納し、再暗号化してから転送する必要があります。したがって、実装者の観点から見ると、暗号化モードでは、チェックサム補完は必ずしも実装を単純化するわけではないので、その価値はほとんどありません。
Note: While [OWAMP] and [TWAMP] include an inherent security mechanism, these protocols can be secured by other measures, e.g., [IPPMIPsec]. For reasons similar to those described above, a Checksum Complement SHOULD NOT be used in this case.
注：[OWAMP]と[TWAMP]には固有のセキュリティメカニズムが含まれていますが、これらのプロトコルは[IPPMIPsec]などの他の方法で保護できます。上記と同様の理由により、この場合はチェックサム補完を使用しないでください。
This document describes how a Checksum Complement extension can be used for maintaining the correctness of the UDP Checksum.
このドキュメントでは、UDPチェックサムの正確性を維持するためにチェックサム補完拡張機能を使用する方法について説明します。
The purpose of this extension is to ease the implementation of accurate timestamping engines, as illustrated in Figure 1. The extension is intended to be used internally in an OWAMP/TWAMP-enabled node, and not intended to be used by intermediate switches and routers that reside between the sender and the receiver/reflector. Any modification of a test packet by intermediate switches or routers should be considered a malicious man-in-the-middle (MITM) attack.
この拡張機能の目的は、図1に示すように、正確なタイムスタンプエンジンの実装を容易にすることです。この拡張機能は、OWAMP / TWAMP対応のノードで内部的に使用することを意図しており、中間スイッチやルーターが使用することを意図していません。送信者と受信者/反射器の間に存在します。中間スイッチまたはルーターによるテストパケットの変更は、悪意のある中間者（MITM）攻撃と見なす必要があります。
It is important to emphasize that the scheme described in this document does not increase the protocol's vulnerability to MITM attacks; a MITM attacker who maliciously modifies a packet and its Checksum Complement is logically equivalent to a MITM attacker who modifies a packet and its UDP Checksum field.
このドキュメントで説明されているスキームは、MITM攻撃に対するプロトコルの脆弱性を増加させないことを強調することが重要です。悪意を持ってパケットとそのチェックサム補完を変更するMITM攻撃者は、パケットとそのUDPチェックサムフィールドを変更するMITM攻撃者と論理的に同等です。
The concept described in this document is intended to be used only in unauthenticated mode or authenticated mode. As described in Section 3.4.2, using the Checksum Complement in encrypted mode does not simplify the implementation compared to using the conventional checksum, and therefore the Checksum Complement should not be used.
このドキュメントで説明する概念は、非認証モードまたは認証モードでのみ使用することを目的としています。セクション3.4.2で説明したように、暗号化モードでチェックサムコンプリメントを使用しても、従来のチェックサムを使用する場合に比べて実装が単純化されないため、チェックサムコンプリメントを使用しないでください。
[Checksum] Rijsinghani, A., Ed., "Computation of the Internet Checksum via Incremental Update", RFC 1624, DOI 10.17487/RFC1624, May 1994, <http://www.rfc-editor.org/info/rfc1624>.
[チェックサム] Rijsinghani、A。、編、「インクリメンタルアップデートによるインターネットチェックサムの計算」、RFC 1624、DOI 10.17487 / RFC1624、1994年5月、<http://www.rfc-editor.org/info/rfc1624> 。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[IPv6] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[キーワード] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[OWAMP] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, <http://www.rfc-editor.org/info/rfc4656>.
[OWAMP] Shalunov、S.、Teitelbaum、B.、Karp、A.、Boote、J.、and M. Zekauskas、 "A One-way Active Measurement Protocol（OWAMP）"、RFC 4656、DOI 10.17487 / RFC4656、September 2006、<http://www.rfc-editor.org/info/rfc4656>。
[TWAMP] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <http://www.rfc-editor.org/info/rfc5357>.
[TWAMP] Hedayat、K.、Krzanowski、R.、Morton、A.、Yum、K。、およびJ. Babiarz、「A Two-Way Active Measurement Protocol（TWAMP）」、RFC 5357、DOI 10.17487 / RFC5357、10月2008、<http://www.rfc-editor.org/info/rfc5357>。
[TWAMP-Reflect] Morton, A. and L. Ciavattone, "Two-Way Active Measurement Protocol (TWAMP) Reflect Octets and Symmetrical Size Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, <http://www.rfc-editor.org/info/rfc6038>.
[TWAMP-Reflect] Morton、A.およびL. Ciavattone、「Two-Way Active Measurement Protocol（TWAMP）Reflect Octets and Symmetrical Size Features」、RFC 6038、DOI 10.17487 / RFC6038、2010年10月、<http：// www。 rfc-editor.org/info/rfc6038>。
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[UDP] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、DOI 10.17487 / RFC768、1980年8月、<http://www.rfc-editor.org/info/rfc768>。
[IEEE1588] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Std 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, July 2008.
[IEEE1588] IEEE、「IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems」、IEEE Std 1588-2008、DOI 10.1109 / IEEESTD.2008.4579760、July 2008。
[IPPMIPsec] Pentikousis, K., Ed., Zhang, E., and Y. Cui, "IKEv2-Derived Shared Secret Key for the One-Way Active Measurement Protocol (OWAMP) and Two-Way Active Measurement Protocol (TWAMP)", RFC 7717, DOI 10.17487/RFC7717, December 2015, <http://www.rfc-editor.org/info/rfc7717>.
[IPPMIPsec] Pentikousis、K.、Ed。、Zhang、E。、およびY. Cui、「一方向アクティブ測定プロトコル（OWAMP）および双方向アクティブ測定プロトコル（TWAMP）のIKEv2派生共有秘密鍵」 、RFC 7717、DOI 10.17487 / RFC7717、2015年12月、<http://www.rfc-editor.org/info/rfc7717>。
[RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March 2016, <http://www.rfc-editor.org/info/rfc7821>.
[RFC7821]ミズラヒ、T。、「ネットワークタイムプロトコル（NTP）でのUDPチェックサム補完」、RFC 7821、DOI 10.17487 / RFC7821、2016年3月、<http://www.rfc-editor.org/info/rfc7821> 。
[ZeroChecksum] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013, <http://www.rfc-editor.org/info/rfc6936>.
[ZeroChecksum] Fairhurst、G。およびM. Westerlund、「ゼロチェックサムを使用したIPv6 UDPデータグラムの使用に関する適用性声明」、RFC 6936、DOI 10.17487 / RFC6936、2013年4月、<http://www.rfc-editor.org / info / rfc6936>。
Consider a session between an OWAMP sender and an OWAMP receiver, in which the sender transmits test packets to the receiver.
OWAMP送信者とOWAMP受信者の間のセッションについて考えてみましょう。この場合、送信者はテストパケットを受信者に送信します。
The sender's software layer generates an OWAMP test packet with a timestamp T and a UDP Checksum value U. The value of U is the checksum of the UDP header, UDP payload, and pseudo-header. Thus, U is equal to:
送信者のソフトウェア層は、タイムスタンプTとUDPチェックサム値Uを含むOWAMPテストパケットを生成します。Uの値は、UDPヘッダー、UDPペイロード、および疑似ヘッダーのチェックサムです。したがって、Uは次と等しくなります。
U = Const + checksum(T) (1)
Where "Const" is the checksum of all the fields that are covered by the checksum, except the timestamp T.
「Const」は、タイムスタンプTを除く、チェックサムの対象となるすべてのフィールドのチェックサムです。
Recall that the sender's software emits the test packet with a Checksum Complement field, which is simply the last 2 octets of the padding. In this example, it is assumed that the sender initially assigns zero to these 2 octets.
送信者のソフトウェアは、チェックサム補完フィールドを持つテストパケットを送信することを思い出してください。これは、パディングの最後の2オクテットにすぎません。この例では、送信者が最初にこれらの2つのオクテットにゼロを割り当てると想定されています。
The sender's timestamping engine updates the Timestamp field to the accurate time, changing its value from T to T'. The sender also updates the Checksum Complement field from zero to a new value C, such that:
送信者のタイムスタンプエンジンは、タイムスタンプフィールドを正確な時刻に更新し、その値をTからT 'に変更します。送信者はまた、次のように、チェックサム補完フィールドをゼロから新しい値Cに更新します。
checksum(C) = checksum(T) - checksum(T') (2)
When the test packet is transmitted by the sender's timestamping engine, the value of the checksum remains U as before:
テストパケットが送信者のタイムスタンプエンジンによって送信されるとき、チェックサムの値は以前と同様にUのままです。
U = Const + checksum(T) = Const + checksum(T) + checksum(T') -
checksum(T') = Const + checksum(T') + checksum(C) (3)
Thus, after the timestamping engine has updated the timestamp, U remains the correct checksum of the packet.
したがって、タイムスタンプエンジンがタイムスタンプを更新した後、Uはパケットの正しいチェックサムのままです。
When the test packet reaches the receiver, the receiver performs a conventional UDP Checksum computation, and the computed value is U. Since the Checksum Complement is part of the padding, the value of checksum(C) is transparently included in the computation, as per Equation (3), without requiring special treatment by the receiver.
テストパケットがレシーバーに到達すると、レシーバーは従来のUDPチェックサム計算を実行し、計算値はUです。チェックサムコンプリメントはパディングの一部であるため、checksum（C）の値は透過的に計算に含まれます。受信者による特別な処理を必要としない式（3）。
Acknowledgments
謝辞
The author gratefully acknowledges Al Morton, Greg Mirsky, Steve Baillargeon, Brian Haberman, and Spencer Dawkins for their helpful comments.
著者は、役立つコメントを提供してくれたAl Morton、Greg Mirsky、Steve Baillargeon、Brian Haberman、およびSpencer Dawkinsに感謝の意を表します。
Author's Address
著者のアドレス
Tal Mizrahi Marvell 6 Hamada St. Yokneam, 20692 Israel
Tal Mizrahi Marvell 6 Hamada St. Yokneam、20692 Israel
Email: talmi@marvell.com