[要約] 要約：RFC 4077は、シグナリング圧縮のためのネガティブアクノリッジメントメカニズムについて説明しています。 目的：このRFCの目的は、シグナリング圧縮におけるエラー処理とフロー制御のための効果的なメカニズムを提供することです。
Network Working Group A.B. Roach
Request for Comments: 4077 Estacado Systems
Category: Standards Track May 2005
A Negative Acknowledgement Mechanism for Signaling Compression
圧縮をシグナル伝達するための否定的な認識メカニズム
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 (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document describes a mechanism that allows Signaling Compression (SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed. This negative feedback can be used by the recipient to make fine-grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations.
このドキュメントでは、シグナリング圧縮（SIGCOMP）の実装を可能にするメカニズムが、解凍できないメッセージの受信時に正確なエラー情報を報告します。この否定的なフィードバックは、受信者が再送信する前に圧縮メッセージに細粒の調整を行い、エラー状況から迅速かつ効率的な回復を可能にするために使用できます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. The Problem ................................................2
1.1.1. Compartment Disposal ................................3
1.1.2. Client Restart ......................................3
1.1.3. Server Failover .....................................3
1.2. The Solution ...............................................4
2. Node Behavior ...................................................4
2.1. Normal SigComp Message Transmission ........................4
2.2. Receiving a "Bad" SigComp Message ..........................5
2.3. Receiving a SigComp NACK ...................................6
2.3.1. Unreliable Transport ................................6
2.3.2. Reliable Transport ..................................6
2.4. Detecting Support for NACK .................................7
3. Message Format ..................................................7
3.1. Message Fields .............................................8
3.2. Reason Codes ...............................................9
4. Security Considerations ........................................13
4.1. Reflector Attacks .........................................13
4.2. NACK Spoofing .............................................13
5. IANA Considerations ............................................14
6. Acknowledgements ...............................................14
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................14
Signaling Compression [1], often called "SigComp", defines a protocol for transportation of compressed messages between two network elements. One of the key features of SigComp is the ability of the sending node to request that the receiving node store state objects for later retrieval.
しばしば「Sigcomp」と呼ばれるシグナリング圧縮[1]は、2つのネットワーク要素間で圧縮メッセージを輸送するためのプロトコルを定義します。SigCompの重要な機能の1つは、送信ノードが受信ノードストア状態オブジェクトを後で検索することを要求する能力です。
While the "SigComp - Extended Operations" document [2] defines a mechanism that allows for confirmation of state creation, operational experience with the SigComp protocol has demonstrated that there are still several circumstances in which a sender's view of the shared state differs from the receiver's view. A non-exhaustive list detailing the circumstances in which such failures may occur is below.
「SIGCOMP-拡張操作」ドキュメント[2]は、状態の作成の確認を可能にするメカニズムを定義していますが、SIGCOMPプロトコルの運用経験は、共有状態の送信者の見解が受信者の状況がまだ異なることを実証しています。ビュー。そのような障害が発生する可能性のある状況を詳述する網羅的ではないリストは以下にあります。
In SigComp, stored states are associated with compartments. Conceptually, the compartments represent one instance of a remote application. These compartments are used to limit the amount of state that each remote application is allowed to store. Compartments are created upon receipt of a valid SigComp message from a remote application. In the current protocol, applications are expected to signal when they are finished with a compartment so that it can be deleted (by using the S-bit in requested feedback data).
Sigcompでは、保存された状態はコンパートメントに関連付けられています。概念的には、コンパートメントはリモートアプリケーションの1つのインスタンスを表します。これらのコンパートメントは、各リモートアプリケーションが保存できる状態の量を制限するために使用されます。コンパートメントは、リモートアプリケーションから有効なSigCompメッセージを受信すると作成されます。現在のプロトコルでは、アプリケーションは、コンパートメントで終了したときに削除できるように信号を送信すると予想されます（要求されたフィードバックデータでS-BITを使用して）。
Unfortunately, expecting the applications to be well-behaved is not sufficient to prevent state from piling up. Unexpected client failures, reboots, and loss of connectivity can cause compartments to become "stuck" and never removed. To prevent this situation, it becomes necessary to implement a scheme by which compartments that appear disused may eventually be discarded.
残念ながら、アプリケーションが行方不明になることを期待するだけでは、状態が積み重なるのを防ぐのに十分ではありません。予期しないクライアントの障害、再起動、接続の喪失により、コンパートメントが「スタック」され、削除されない可能性があります。この状況を防ぐために、使用されていないように見えるコンパートメントが最終的に破棄される可能性があるスキームを実装する必要があります。
While the preceding facts make such a practice necessary, discarding compartments without explicit signaling can have the unfortunate side effect that active compartments are sometimes discarded. This leads to a different view of state between the server and the client.
前述の事実はそのような慣行を必要としますが、明示的なシグナリングなしでコンパートメントを破棄すると、アクティブコンパートメントが時々破棄されるという不幸な副作用があります。これにより、サーバーとクライアントの間の状態の異なるビューにつながります。
The prime motivation for SigComp was compression of messages to be sent over a radio interface. Consequently, most deployments of SigComp will involve a mobile unit as one of the endpoints. Mobile terminals are generally not guaranteed to be available for extended durations of time. Node restarts (due to, for example, a battery running out) will induce situations in which the network-based server believes that the client contains several states that are no longer actually available.
Sigcompの主な動機は、無線インターフェイスを介して送信されるメッセージの圧縮でした。その結果、SigCompのほとんどの展開には、エンドポイントの1つとしてモバイルユニットが含まれます。通常、モバイルターミナルは、長期にわたって利用可能になることは保証されていません。ノードの再起動（たとえば、バッテリーがなくなるため）は、ネットワークベースのサーバーがクライアントに実際に利用できなくなったいくつかの状態が含まれていると考えている状況を誘発します。
Many applications for which SigComp will be used (e.g., SIP [3]) use DNS SRV records for server lookup. One of the important features of DNS SRV records is the ability to specify multiple servers from which clients will select at random, with probabilities determined by the q-value weighting. The reason for defining this behavior for SRV records is to allow load distribution through a set of equivalent servers, and to permit clients to continue to function even if the server with which they are communicating fails. When using protocols that use SRV for such distribution, the traffic to a failed server is typically sent by the client to an equivalent server that can serve the same purpose. From an application perspective, this new server often appears to be the same endpoint as the failed server, and will consequently resolve to the same compartment.
SigCompが使用される多くのアプリケーション（例：SIP [3]）がサーバールックアップにDNS SRVレコードを使用します。DNS SRVレコードの重要な機能の1つは、Q値の重み付けによって決定される確率で、クライアントがランダムに選択する複数のサーバーを指定する機能です。SRVレコードのこの動作を定義する理由は、一連の同等のサーバーを介した負荷分布を許可し、クライアントが通信しているサーバーが失敗しても機能し続けることです。このような配布にSRVを使用するプロトコルを使用する場合、故障したサーバーへのトラフィックは通常、クライアントから同じ目的を果たすことができる同等のサーバーに送信されます。アプリケーションの観点から見ると、この新しいサーバーは、故障したサーバーと同じエンドポイントであるように見えることが多く、その結果、同じコンパートメントに解決します。
Although SigComp state can be replicated amongst such a cluster of servers, maintaining integrity of such states requires a two-phase commit process that adds a great deal of complexity to the server and can degrade performance significantly.
Sigcomp状態はこのようなサーバーのクラスター間で複製することができますが、そのような状態の完全性を維持するには、サーバーに多大な複雑さを加え、パフォーマンスを大幅に分解できる2フェーズのコミットプロセスが必要です。
Although SigComp allows returned SigComp parameters to signal that all states have been lost (by setting "state_memory_size" to 0 for one message in the reverse direction), such an approach provides an incomplete solution to the problem. In addition to wiping out an entire compartment when only one state is corrupt or missing, this approach suffers from the unfortunate behavior that it requires a message in the reverse direction that the remote application will authorize. Unless a lower-layer security mechanism is employed (e.g., TLS), this would typically mean that a compressed application-level message in the reverse direction must be sent before recovery can occur. In many cases (such as SIP-based mobile terminals), these messages won't be sent often; in others (pure client/server deployments), they won't ever be sent.
Sigcompは、返されたSigCompパラメーターを許可して、すべての状態が失われたことを示していますが（逆方向の1つのメッセージに対して「State_memory_size」を0に設定することにより）、このようなアプローチは問題に対する不完全な解決策を提供します。1つの状態のみが破損または欠落している場合にコンパートメント全体を拭くことに加えて、このアプローチは、リモートアプリケーションが承認する逆方向のメッセージが必要であるという不幸な動作に苦しんでいます。低層セキュリティメカニズムが採用されていない限り（TLSなど）、これは通常、回復が発生する前に逆方向の圧縮アプリケーションレベルのメッセージを送信する必要があることを意味します。多くの場合（SIPベースのモバイル端子など）、これらのメッセージは頻繁に送信されません。その他（純粋なクライアント/サーバーの展開）では、送信されることはありません。
The proposed solution to this problem is a simple Negative Acknowledgement (NACK) mechanism which allows the recipient to communicate to the sender that a failure has occurred. This NACK contains a reason code that communicates the nature of the failure. For certain types of failures, the NACK will also contain additional details that might be useful in recovering from the failure.
この問題に対する提案された解決策は、レシピエントが障害が発生したことを送信者に通信できるようにする単純な否定的な認識（NACK）メカニズムです。このNACKには、障害の性質を伝える理由コードが含まれています。特定の種類の障害については、NACKには、障害から回復するのに役立つ可能性のある追加の詳細も含まれます。
The following sections detail the behavior of nodes sending and receiving SigComp NACKs. The actual format and values are described in Section 3.
次のセクションでは、Sigcomp Nacksの送信と受信ノードの動作について詳しく説明しています。実際の形式と値については、セクション3で説明します。
Although normal in all other respects, SigComp implementations that use the NACK mechanism need to calculate and store a SHA-1 hash for each SigComp message that they send. This must be stored in such a way that, given the SHA-1 hash, the implementation is able to locate the compartment with which the sent message was associated.
他のすべての点では正常ですが、NACKメカニズムを使用するSigCompの実装は、送信するSigCompメッセージごとにSHA-1ハッシュを計算して保存する必要があります。これは、SHA-1ハッシュを考えると、実装が送信されたメッセージが関連付けられているコンパートメントを見つけることができるように保存する必要があります。
In other words, if someone hands the SHA-1 hash back to the compressor, it needs to be able to find the compartment with which it was working when it sent the message with that hash. This only requires that the compressor knows with which compartment it is working when it sends a message (which is always the case), and that the SHA-1 hash, when stored, points to that compartment in some way.
言い換えれば、誰かがSHA-1ハッシュをコンプレッサーに戻した場合、そのハッシュでメッセージを送信したときに機能していたコンパートメントを見つけることができる必要があります。これには、コンプレッサーがメッセージを送信するときにどのコンパートメントが機能しているかを知っている必要があります（常にそうです）、SHA-1ハッシュは、保存されている場合、何らかの方法でそのコンパートメントを指します。
When a received SigComp message causes a decompression failure, the recipient forms and sends a SigComp NACK message. This NACK message contains a SHA-1 hash of the received SigComp message that could not be decompressed. It also contains the exact reason decompression failed, as well as any additional details that might assist the NACK recipient to correct any problems. See Section 3 for more information about formatting the NACK message and its fields.
受信したSigCompメッセージが減圧の故障を引き起こすと、受信者はSigcomp Nackメッセージを形成して送信します。このNACKメッセージには、減圧できなかったSigCompメッセージのSHA-1ハッシュが含まれています。また、解凍が失敗した正確な理由と、NACKの受信者が問題を修正するのに役立つ追加の詳細も含まれています。NACKメッセージとそのフィールドのフォーマットの詳細については、セクション3を参照してください。
For a connection-oriented transport, such as TCP, the NACK message is sent back to the originator of the failed message over that same connection.
TCPなどの接続指向のトランスポートの場合、NACKメッセージは、同じ接続で失敗したメッセージの発信者に送信されます。
For a stream-based transport, such as TCP, the standard SigComp delimiter of 0xFFFF is used to terminate the NACK message.
TCPなどのストリームベースのトランスポートの場合、0xFFFFの標準Sigcompデリミターを使用してNACKメッセージを終了します。
For a connectionless transport, such as UDP, the NACK message is sent back to the originator of the failed message at the port and IP address from which the message was sent. Note that this may or may not be the same port on which the application would typically receive messages. To accommodate implementations that use connect() or similar constructs, the NACK will be sent from the IP address and port to which the uninterpretable message was sent. From a practical perspective, this is probably easiest to determine by binding listening sockets to a specific interface; however, other mechanisms may also be employed.
UDPなどのコネクションレストランスポートの場合、NACKメッセージは、メッセージが送信されたポートアドレスとIPアドレスの失敗したメッセージの発信者に送信されます。これは、アプリケーションが通常メッセージを受信するのと同じポートである場合とそうでない場合があることに注意してください。Connect（）または同様のコンストラクトを使用する実装に対応するために、NACKは、解釈不能なメッセージが送信されたIPアドレスとポートから送信されます。実用的な観点から、これはおそらく、リスニングソケットを特定のインターフェイスに結合することで決定するのが最も簡単です。ただし、他のメカニズムも採用される場合があります。
The behavior specified above is strictly necessary for any generally useful form of a NACK mechanism. In the most general case, when an implementation receives a message that it cannot decompress, it has exactly three useful pieces of information: (1) the contents of the message, (2) an indication of why the message cannot be decoded, and (3) the IP address and port from which the message originated. Note that none of these contains any indication of where the remote application is listening for messages, if it differs from the sending port.
上記で指定された動作は、一般的に有用な形式のNACKメカニズムに厳密に必要です。最も一般的なケースでは、実装が解凍できないというメッセージを受信すると、正確に3つの有用な情報があります。（1）メッセージの内容、（2）メッセージをデコードできない理由、および（3）メッセージが発信されたIPアドレスとポート。これらのいずれにも、送信ポートとは異なる場合、リモートアプリケーションがメッセージを聞いている場所の表示は含まれていないことに注意してください。
The first action taken upon receipt of a NACK is an attempt to find the message to which the NACK corresponds. This search is performed using the 20-byte SHA-1 hash contained in the NACK. Once the matching message is located, further operations are performed based on the compartment that was associated with the sent message.
NACKの受領時に行われた最初のアクションは、NACKが対応するメッセージを見つける試みです。この検索は、NACKに含まれる20バイトのSHA-1ハッシュを使用して実行されます。一致するメッセージが配置されると、送信されたメッセージに関連付けられたコンパートメントに基づいて、さらなる操作が実行されます。
Further behavior of a node upon receiving a SigComp NACK depends on whether a reliable or unreliable transport is being used.
Sigcomp Nackを受信する際のノードのさらなる動作は、信頼性の高い輸送または信頼できない輸送が使用されているかどうかに依存します。
When SigComp is used over an unreliable transport, the application has no reasonable expectation that the transport layer will deliver any particular message. It then becomes the application layer's responsibility to ensure that data is retransmitted as necessary. In these circumstances, the NACK mechanism relies on such behavior to ensure delivery of the message, and never performs retransmissions on the application's behalf.
Sigcompが信頼性の低い輸送で使用される場合、アプリケーションは輸送層が特定のメッセージを提供するという合理的な期待はありません。次に、データが必要に応じて再送信されるようにするためのアプリケーションレイヤーの責任となります。これらの状況では、NACKメカニズムはそのような動作に依存してメッセージの配信を確保し、アプリケーションに代わって再送信を実行することはありません。
When a NACK is received for a message sent over an unreliable transport, the NACK recipient uses the contained information to make appropriate adjustments to the compressor associated with the proper compartment. The exact nature of these adjustments are specific to the compression scheme being used, and will vary from implementation to implementation. The only requirement on these adjustments is that they must have the effect of compensating for the error that has been indicated (e.g., by removing the state that the remote node indicates it cannot retrieve).
信頼性の低いトランスポートを介して送信されたメッセージに対してNACKを受信すると、NACKの受信者は含まれている情報を使用して、適切なコンパートメントに関連付けられたコンプレッサーに適切な調整を行います。これらの調整の正確な性質は、使用される圧縮スキームに固有であり、実装から実装までさまざまです。これらの調整の唯一の要件は、示されているエラーを補償する効果がなければならないことです（たとえば、リモートノードが取得できないことを示す状態を削除することにより）。
In particular, when an unreliable transport is used, the original message must not be retransmitted by the SigComp layer upon receipt of a NACK. Instead, the next application-initiated transmission of a message will take advantage of the adjustments made as a result of processing the NACK.
特に、信頼性の低いトランスポートを使用する場合、NACKを受け取ったときにSigComp層によって元のメッセージを再送信してはなりません。代わりに、メッセージの次のアプリケーションによって開始された送信は、NACKの処理の結果として行われた調整を利用します。
When a reliable transport is employed, the application makes a basic assumption that any message passed down the stack will be retransmitted as necessary to ensure that the remote node receives it, unless a failure is indicated by the transport layer. Because SigComp acts as a shim between the transport-layer and the application, it becomes the responsibility of the SigComp implementation to ensure that any failure to transmit a message is communicated to the application.
信頼できるトランスポートが採用されると、アプリケーションは、輸送層で障害が示されない限り、リモートノードが受信することを確認するために、必要に応じてスタックに渡されたメッセージが必要に応じて再送信されるという基本的な仮定を作成します。Sigcompは輸送層とアプリケーションの間のシムとして機能するため、メッセージの送信の失敗がアプリケーションに伝えられるようにすることは、SigCompの実装の責任となります。
When a NACK is received for a message sent over a reliable transport, the SigComp layer must indicate to the application that an error has occurred. In general, the application should react in the same way as it does for any other transport layer error, such as a TCP connection reset. For most applications, this reaction will initially be an attempt to reset and re-establish the connection, and re-initiate the failed transaction. The SigComp layer should also use the information contained in the NACK to make appropriate adjustments to the compressor associated with the proper compartment (similar to the adjustments made for unreliable transport). Thus, if the compartment is not reset by resetting the TCP connection, the next message will take advantage of the adjustments.
信頼できるトランスポートを介して送信されたメッセージに対してNACKが受信されると、SigComp層はエラーが発生したことをアプリケーションに示す必要があります。一般に、アプリケーションは、TCP接続リセットなど、他の輸送層エラーと同じように反応する必要があります。ほとんどのアプリケーションでは、この反応は最初に接続をリセットして再確立し、失敗したトランザクションを再誘導する試みになります。SigComp層は、NACKに含まれる情報を使用して、適切なコンパートメントに関連付けられたコンプレッサーを適切に調整する必要があります（信頼できない輸送のために行われた調整と同様）。したがって、TCP接続をリセットしてコンパートメントがリセットされない場合、次のメッセージは調整を活用します。
Detection of support for the NACK mechanism may be beneficial in certain circumstances. For example, with the current definition of SigComp, acknowledgment of state receipt is required before a sender can reference such state. When multiple messages are sent before a response is received, the need to wait for such responses can cause significant decreases in message compression efficiency. If it is known that the receiver supports the NACK mechanism, the sender can instead optimistically assume that the state created by a sent message has been created, and is allowed to be referenced. If such an assumption turns out to be false (due to, for example, packet loss or packet reordering), the sender can recover upon receipt of a NACK.
NACKメカニズムのサポートの検出は、特定の状況で有益な場合があります。たとえば、Sigcompの現在の定義では、送信者がそのような状態を参照する前に、州の領収書の承認が必要です。応答が受信される前に複数のメッセージが送信されると、そのような応答を待つ必要があると、メッセージ圧縮効率が大幅に減少する可能性があります。受信者がNACKメカニズムをサポートしていることがわかっている場合、送信者は代わりに、送信されたメッセージによって作成された状態が作成され、参照されることが許可されていると楽観的に仮定できます。そのような仮定が偽であることが判明した場合（たとえば、パケットの損失やパケットの再注文により）、送信者はNACKの受領時に回復できます。
In order to facilitate such detection, any implementation that will send NACK messages upon decompression failure will indicate a SigComp version number of 0x02 in its Universal Decompressor Virtual Machine (UDVM). The bytecodes sent to such an endpoint can check the version number, and send appropriate indication back to their compressor as requested feedback. Except for the NACK mechanism described in this document, implementations advertising a version of 0x02 behave exactly like those advertising a version number of 0x01.
このような検出を容易にするために、減圧障害時にNACKメッセージを送信する実装は、Universal Decompressor Virtual Machine（UDVM）のSigCompバージョン番号0x02を示します。このようなエンドポイントに送信されたバイテコードは、バージョン番号を確認し、要求されたフィードバックとして適切な表示をコンプレッサーに送り返すことができます。このドキュメントで説明されているNACKメカニズムを除き、0x02のバージョンを宣伝する実装は、0x01のバージョン番号を宣伝するものとまったく同じように動作します。
SigComp NACK packets are syntactically valid SigComp messages which have been specifically designed to be safely ignored by implementations that do not support the NACK mechanism.
SigComp NACKパケットは、NACKメカニズムをサポートしていない実装によって安全に無視されるように特別に設計された構文的に有効なSigCompメッセージです。
In particular, NACK messages are formatted as the second variant of a SigComp message (typically used for code upload) with a "code_len" field of zero. The NACK information (message identifier, reason for failure, and error details) is encoded in the "remaining SigComp message" area, typically used for input data. Further, the "destination" field is used as a version identifier to indicate which version of NACK is being employed.
特に、NACKメッセージは、ゼロの「code_len」フィールドを持つSigCompメッセージの2番目のバリアント（通常はコードアップロードに使用される）としてフォーマットされます。NACK情報（メッセージ識別子、障害の理由、およびエラーの詳細）は、通常、入力データに使用される「残りのSIGCOMPメッセージ」領域にエンコードされています。さらに、「宛先」フィールドは、nackのバージョンを採用しているバージョン識別子として使用されます。
The format of the NACK message and the use of the fields within it are shown in Figure 1.
NACKメッセージの形式とその中のフィールドの使用を図1に示します。
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 | T | 0 |
+---+---+---+---+---+---+---+---+
| |
: returned feedback item :
| |
+---+---+---+---+---+---+---+---+
| code_len = 0 |
+---+---+---+---+---+---+---+---+
| code_len = 0 | version = 1 |
+---+---+---+---+---+---+---+---+
| Reason Code |
+---+---+---+---+---+---+---+---+
| OPCODE of failed instruction |
+---+---+---+---+---+---+---+---+
| PC of failed instruction |
| |
+---+---+---+---+---+---+---+---+
| |
: SHA-1 Hash of failed message :
| |
+---+---+---+---+---+---+---+---+
| |
: Error Details :
| |
+---+---+---+---+---+---+---+---+
Figure 1: SigComp NACK Message Format
図1：Sigcomp Nackメッセージ形式
o "Reason Code" is a one-byte value that indicates the nature of the decompression failure. The specific codes are given in Section 3.2.
o 「理由コード」は、減圧障害の性質を示す1バイトの値です。特定のコードは、セクション3.2に記載されています。
o "OPCODE of failed instruction" is a one-byte field that includes the opcode to which the PC was pointing when the failure occurred. If failure occurred before the UDVM began executing any code, this field is set to 0.
o 「失敗した命令のオペコード」は、障害が発生したときにPCが指していたオペコードを含む1バイトのフィールドです。UDVMがコードの実行を開始する前に障害が発生した場合、このフィールドは0に設定されています。
o "PC of failed instruction" is a two-byte field containing the value of the program counter when failure occurred (i.e., the memory address of the failed UDVM instruction). The field is encoded with the most significant byte of the PC first (i.e., in network or big endian order). If failure occurred before the UDVM began executing any code, this field is set to 0.
o 「PC of Failed Instructed」は、障害が発生したときにプログラムカウンターの値を含む2バイトフィールドです（つまり、故障したUDVM命令のメモリアドレス）。このフィールドは、最初にPCの最も重要なバイト（つまり、ネットワークまたは大きなエンド順）でエンコードされます。UDVMがコードの実行を開始する前に障害が発生した場合、このフィールドは0に設定されています。
o "SHA-1 Hash of failed message" contains the full 20-byte SHA-1 hash of the SigComp message that could not be decompressed. This information allows the NACK recipient to locate the message that failed to decompress so that adjustments to the correct compartment can be performed. When performing this hash, the entire SigComp message is used, from the header byte (binary 11111xxx) to the end of the input. Any lower-level protocol headers (such as UDP or IP) and message delimiters (the 0xFFFF that marks message boundaries in stream protocols) are not included in the hash. When used over a stream based protocol, any 0xFFxx escape sequences are un-escaped before performing the hash operation.
o 「失敗したメッセージのSHA-1ハッシュ」には、減圧できなかったSigCompメッセージの20バイトのSHA-1ハッシュが含まれています。この情報により、NACKの受信者は、正しいコンパートメントへの調整を実行できるように、減圧に失敗したメッセージを見つけることができます。このハッシュを実行すると、ヘッダーバイト（バイナリ11111xxx）から入力の最後まで、SigCompメッセージ全体が使用されます。低レベルのプロトコルヘッダー（UDPやIPなど）およびメッセージデリミター（ストリームプロトコルのメッセージ境界をマークする0xFFFF）は、ハッシュに含まれていません。ストリームベースのプロトコルで使用する場合、0xFFXXエスケープシーケンスは、ハッシュ操作を実行する前に未着開です。
o "Error Details" provides additional information that might be useful in correcting the problem that caused decompression failure. Its meaning is specific to the "Reason Code". See Section 3.2 for specific information on what appears in this field.
o 「エラーの詳細」は、減圧障害を引き起こした問題を修正するのに役立つ可能性のある追加情報を提供します。その意味は、「理由コード」に固有です。このフィールドに表示されるものに関する特定の情報については、セクション3.2を参照してください。
o "Code_len" is the "code_len" field from a standard SigComp message. It is always set to "0" for NACK messages.
o 「code_len」は、標準のSigcompメッセージの「code_len」フィールドです。NACKメッセージに対して常に「0」に設定されています。
o "Version" gives the version of the NACK mechanism being employed. This document defines version 1.
o 「バージョン」は、採用されているNACKメカニズムのバージョンを提供します。このドキュメントはバージョン1を定義します。
Note that many of the status codes are more useful in debugging interoperability problems than with on-the-fly correction of errors. The "STATE_NOT_FOUND" error is a notable exception: it will generally cause the NACK recipient to encode future messages so as to not use the indicated state.
ステータスコードの多くは、エラーの飛行中の修正よりも、相互運用性の問題をデバッグするのに役立つことに注意してください。「state_not_found」エラーは顕著な例外です。通常、NACK受信者は、指定された状態を使用しないように将来のメッセージをエンコードします。
Upon receiving the other status messages, an implementation would typically be expected either to use a different set of bytecodes or, if that is not an option, to send that specific message uncompressed.
他のステータスメッセージを受信すると、実装は通常、異なるバイトコードのセットを使用するか、それがオプションではない場合、特定のメッセージを非圧縮して送信することが期待されます。
Error Code Details
-------------------------- ---- ---------------------------
STATE_NOT_FOUND 1 State ID (6 - 20 bytes)
CYCLES_EXHAUSTED 2 Cycles Per Bit (1 byte)
USER_REQUESTED 3
SEGFAULT 4
TOO_MANY_STATE_REQUESTS 5
INVALID_STATE_ID_LENGTH 6
INVALID_STATE_PRIORITY 7
OUTPUT_OVERFLOW 8
STACK_UNDERFLOW 9
BAD_INPUT_BITORDER 10
DIV_BY_ZERO 11
SWITCH_VALUE_TOO_HIGH 12
TOO_MANY_BITS_REQUESTED 13
INVALID_OPERAND 14
HUFFMAN_NO_MATCH 15
MESSAGE_TOO_SHORT 16
INVALID_CODE_LOCATION 17
BYTECODES_TOO_LARGE 18 Memory size (2 bytes)
INVALID_OPCODE 19
INVALID_STATE_PROBE 20
ID_NOT_UNIQUE 21 State ID (6 - 20 bytes)
MULTILOAD_OVERWRITTEN 22
STATE_TOO_SHORT 23 State ID (6 - 20 bytes)
INTERNAL_ERROR 24
FRAMING_ERROR 25
Only the five errors "STATE_NOT_FOUND", "CYCLES_EXHAUSTED", "BYTECODES_TOO_LARGE", "ID_NOT_UNIQUE", and "STATE_TOO_SHORT" contain details; for all other error codes, the "Error Details" field has zero length.
5つのエラー「state_not_found "、" cycles_exasted "、" bytecodes_too_large "、" id_not_unique "、および「state_too_short」のみが詳細を含んでいます。他のすべてのエラーコードでは、「エラー詳細」フィールドの長さはゼロです。
Figure 2: SigComp NACK Reason Codes
図2：Sigcomp Nack Reason Codes
1. STATE_NOT_FOUND A state that was referenced cannot be found. The state may have been referenced by the UDVM executing a STATE-ACCESS instruction; it also may have been referenced by the "partial state identifier" field in a SigComp message. The "details" field contains the state identifier for the state that could not be found. This is also the proper error to return in the case that a unique state item was matched but fewer bytes of state ID were sent than required by the minimum_access_length.
1. state_not_found参照された状態は見つかりません。状態は、状態アクセス命令を実行するUDVMによって参照されている可能性があります。また、SigCompメッセージの「部分状態識別子」フィールドによって参照されている可能性があります。「詳細」フィールドには、見つからなかった状態の状態識別子が含まれています。これは、一意の状態項目が一致したが、最小限のaccess_lengthで要求されるよりもState IDのバイトが少ない場合に戻るための適切なエラーでもあります。
2. CYCLES_EXHAUSTED Decompression of the message has taken more cycles than were allocated to it. The "details" field contains a one-byte value that communicates the number of cycles per bit. The cycles per bit is represented as an unsigned 8-bit integer (i.e., not encoded).
2. メッセージのcycles_exexhexedの減圧は、割り当てられたよりも多くのサイクルを取りました。「詳細」フィールドには、ビットあたりのサイクル数を伝える1バイト値が含まれています。ビットあたりのサイクルは、署名されていない8ビット整数（つまり、エンコードされていない）として表されます。
3. USER_REQUESTED The DECOMPRESSION-FAILURE opcode has been executed.
3. user_requested減圧 - 排出 - オペコードが実行されました。
4. SEGFAULT An attempt to read from or write to memory that is outside of the UDVM's memory space has been attempted.
4. segfault UDVMのメモリスペースの外側にあるメモリから読んだり、書いたりする試みが試みられました。
5. TOO_MANY_STATE_REQUESTS More than four requests to store or delete state objects have been requested.
5. to_many_state_requests状態オブジェクトを保存または削除するための4つ以上のリクエストが要求されています。
6. INVALID_STATE_ID_LENGTH A state id length less than 6 or greater than 20 has been specified.
6. invalid_state_id_lengthは、6未満または20未満の状態IDの長さが指定されています。
7. INVALID_STATE_PRIORITY A state priority of 65535 has been specified when attempting to store a state.
7. Invalid_state_priority州を保存しようとすると、65535の州の優先度が指定されています。
8. OUTPUT_OVERFLOW The decompressed message is too large to be decoded by the receiving node.
8. output_overflow減圧メッセージは大きすぎて受信ノードによってデコードできません。
9. STACK_UNDERFLOW An attempt to pop a value off the UDVM stack was made with a stack_fill value of 0.
9. stack_underflow UDVMスタックから値をポップする試みは、stack_fill値0で作成されました。
10. BAD_INPUT_BITORDER An INPUT-BITS or INPUT-HUFFMAN instruction was encountered with the "input_bit_order" register set to an invalid value (i.e., one of the upper 13 bits is set).
10. bad_input_bitorder inupt-bitsまたはinput-huffman命令には、「input_bit_order」レジスタが無効な値に設定されています（つまり、上部13ビットの1つが設定されています）。
11. DIV_BY_ZERO A DIVIDE or REMAINDER opcode was encountered with a divisor of 0.
11. div_by_zero分割または残りのオペコードは、0の除数で遭遇しました。
12. SWITCH_VALUE_TOO_HIGH The input to a SWITCH opcode exceeds the number of branches defined.
12. switch_value_too_highスイッチオペコードへの入力は、定義されたブランチの数を超えています。
13. TOO_MANY_BITS_REQUESTED An INPUT-BITS or INPUT-HUFFMAN instruction was encountered that attempted to input more than 16 bits.
13. to_many_bits_requested入力ビットまたは入力ハフマン命令に16ビット以上の入力を試みた。
14. INVALID_OPERAND An operand for an instruction could not be resolved to an integer value (e.g., a literal or reference operand beginning with 11111111).
14. Invalid_operand命令用のオペランドは、整数値（たとえば、11111111から始まるリテラルまたは参照オペランド）に解決することはできませんでした。
15. HUFFMAN_NO_MATCH The input string does not match any of the bitcodes in the INPUT-HUFFMAN opcode.
15. huffman_no_match入力文字列は、入力-Huffmanオペコードのビットコードのいずれも一致しません。
16. MESSAGE_TOO_SHORT When attempting to decode a SigComp message, the recipient determined that there were not enough bytes in the message for it to be valid.
16. message_too_short sigcompメッセージをデコードしようとすると、受信者はメッセージに十分なバイトが有効であるために十分なバイトがないと判断しました。
17. INVALID_CODE_LOCATION The "code location" field in the SigComp message was set to the invalid value of 0.
17. invalid_code_location sigcompメッセージの「コード位置」フィールドは、0の無効な値に設定されました。
18. BYTECODES_TOO_LARGE The bytecodes that a SigComp message attempted to upload exceed the amount of memory available in the receiving UDVM. The details field is a two-byte expression of the DECOMPRESSION_MEMORY_SIZE of the receiving UDVM. This value is communicated most-significant-byte first.
18. bytecodes_too_large sigcompメッセージがアップロードしようとしたバイテコードは、受信UDVMで利用可能なメモリの量を超えています。詳細フィールドは、受信UDVMの減圧_memory_sizeの2バイト式です。この値は、最初に最も重要なバイトに伝えられます。
19. INVALID_OPCODE The UDVM attempted to identify an undefined byte value as an instruction.
19. Invalid_opCode UDVMは、未定義のバイト値を命令として識別しようとしました。
20. INVALID_STATE_PROBE When attempting to retrieve state, the state_length operand is set to 0 but the state_begin operand is non-zero.
20. Invalid_state_Probe状態を取得しようとすると、State_Length Operandは0に設定されていますが、State_Begin Operandはゼロではありません。
21. ID_NOT_UNIQUE A partial state identifier that was used to access state matched more than one state item. Note that this error might be returned as the result of executing a STATE-ACCESS instruction or attempting to locate a unique piece of state as identified by the "partial state identifier" in a SigComp message. The "details" field contains the partial state identifier that was requested.
21. id_not_unique複数の状態項目に一致する状態にアクセスするために使用された部分状態識別子。このエラーは、SigCompメッセージの「部分状態識別子」によって識別されたように、状態アクセス命令を実行するか、一意の状態を見つけようとしようとした結果として返される可能性があることに注意してください。「詳細」フィールドには、要求された部分状態識別子が含まれています。
22. MULTILOAD_OVERWRITTEN A MULTILOAD instruction attempted to overwrite itself.
22. Multiload_overwritted自体の上書きを試みたマルチロード命令。
23. STATE_TOO_SHORT A STATE-ACCESS instruction has attempted to copy more bytes from a state item than the state item actually contains. The "details" field contains the partial state identifier that was requested. Implementors are cautioned to return only the partial state identifier that was requested; if the NACK contains any state identifier in addition to what was requested, attackers may be able to use that additional information to access the state.
23. state_too_short状態アクセス命令は、状態アイテムが実際に含むよりも、状態アイテムからより多くのバイトをコピーしようとしました。「詳細」フィールドには、要求された部分状態識別子が含まれています。実装者は、要求された部分状態識別子のみを返すように注意されています。NACKに要求されたものに加えて状態識別子が含まれている場合、攻撃者はその追加情報を使用して状態にアクセスできる場合があります。
24. INTERNAL_ERROR The UDVM encountered an unexpected condition that prevented it from decompressing the message.
24. internal_error udvmは、メッセージの減圧を防ぐために予期しない状態に遭遇しました。
25. FRAMING_ERROR The UDVM encountered a framing error (unquoted 0xFF 80 .. 0xFF FE in an input stream.) This error is applicable only to messages received on a stream transport. In the case of a framing error, a SHA-1 hash for a unique message cannot be determined. Consequently, when a FRAMING_ERROR NACK is sent, the "SHA-1 Hash of failed message" field should be set to all zeros.
25. framing_error udvmにフレーミングエラーが発生しました（入力ストリームでは1 quoted 0xff 80 .. 0xff fe）。このエラーは、ストリームトランスポートで受信したメッセージにのみ適用できます。フレーミングエラーの場合、一意のメッセージのSHA-1ハッシュを決定することはできません。その結果、framing_error nackが送信されると、「失敗したメッセージのsha-1ハッシュ」フィールドはすべてのゼロに設定する必要があります。
Because SigComp NACK messages are by necessity sent in response to other messages, it is possible to trigger them by intentionally sending malformed messages to a SigComp implementation with a spoofed IP address. However, because such actions can only generate one message for each message sent, they don't serve as amplifier attacks. Further, due to the reasonably small size of NACK packets, there cannot be a significant increase in the size of the packet generated.
Sigcomp Nackメッセージは、他のメッセージに応じて必然的に送信されるため、スプーフィングされたIPアドレスでSigCompの実装に不正なメッセージを意図的に送信することにより、それらをトリガーすることができます。ただし、そのようなアクションは、送信された各メッセージに対して1つのメッセージのみを生成できるため、増幅器攻撃としては機能しません。さらに、NACKパケットのサイズがかなり少ないため、生成されたパケットのサイズが大幅に増加することはできません。
It is worth noting that nearly all deployed protocols exhibit this same behavior.
ほぼすべての展開されたプロトコルがこの同じ動作を示すことは注目に値します。
Although it is possible to forge NACK messages as if they were generated by a different node, the damage that can be caused is minimal. Reporting a loss of state will typically result in nothing more than the re-transmission of that state in a subsequent message. Other failure codes would result in the next message being sent using an alternate compression mechanism, or possibly uncompressed.
まるで別のノードによって生成されたようにNACKメッセージを偽造することは可能ですが、引き起こされる可能性のある損傷は最小限です。状態の損失を報告することは、通常、後続のメッセージでその状態の再送信にすぎないようになります。他の障害コードは、代替圧縮メカニズムを使用して次のメッセージが送信されるか、おそらく非圧縮されます。
Although all of the above consequences result in slightly larger messages, none of them have particularly catastrophic implications for security.
上記の結果はすべて、わずかに大きなメッセージをもたらしますが、セキュリティに特に壊滅的な意味を持つことはありません。
This document defines a new value for the IANA registered attribute SigComp_version.
このドキュメントは、IANA登録属性Sigcomp_versionの新しい値を定義します。
Value (in hex): 02
値（16進数）：02
Description: SigComp version 2 (NACK support)
説明：Sigcompバージョン2（NACKサポート）
Reference: [RFC4077]
参照：[RFC4077]
Thanks to Carsten Bormann, Zhigang Liu, Pekka Pessi, and Robert Sugar for their comments and suggestions. Special thanks to Abigail Surtees and Richard Price for several very detailed reviews and suggestions.
Carsten Bormann、Zhigang Liu、Pekka Pessi、Robert Sugarのコメントと提案に感謝します。いくつかの非常に詳細なレビューと提案をしてくれたAbigail SurteesとRichard Priceに感謝します。
[1] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003.
[1] Price、R.、Bormann、C.、Christoffersson、J.、Hannu、H.、Liu、Z。、およびJ. Rosenberg、「Signaling Compression（Sigcomp）」、RFC 3320、2003年1月。
[2] Hannu, H., Christoffersson, J., Forsgren, S., Leung, K.-C., Liu, Z., and R. Price, "Signaling Compression (SigComp) - Extended Operations", RFC 3321, January 2003.
[2] Hannu、H.、Christoffersson、J.、Forsgren、S.、Leung、K. -C.、Liu、Z.、およびR. Price、「Signaling Compression（Sigcomp） - 拡張操作」、RFC 3321、2003年1月。
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[3] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
Author's Address
著者の連絡先
Adam Roach Estacado Systems 17210 Campbell Road Suite 250 Dallas, TX 75252 US
Adam Roach Estacado Systems 17210 Campbell Road Suite 250 Dallas、TX 75252 US
EMail: adam@estacado.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。