制約付きアプリケーションプロトコル

制約アプリケーション プロトコル( CoAP ) は、RFC 7252 で定義されているように、制約のあるデバイス向けの特殊なUDP ベースのインターネット アプリケーション プロトコルです。これにより、「ノード」と呼ばれる制約のあるデバイスが、同様のプロトコルを使用してより広範なインターネットと通信できるようになります。CoAP は、同じ制約のあるネットワーク (低電力、損失の多いネットワークなど) 上のデバイス間、インターネット上のデバイスと一般ノード間、およびインターネットで結合された異なる制約のあるネットワーク上のデバイス間での使用を目的として設計されています。CoAP は、モバイル通信ネットワーク上の SMS などの他のメカニズムでも使用されています。

CoAP は、無線センサー ネットワークノードなどのリソースが制限されたインターネット デバイスで使用することを目的としたアプリケーション層プロトコルです。CoAP は、Web との統合を簡素化するためにHTTPに簡単に変換できるように設計されており、マルチキャストサポート、非常に低いオーバーヘッド、シンプルさなどの特殊な要件も満たしています。^{[1] [2]}マルチキャスト、低いオーバーヘッド、シンプルさは、従来のインターネット デバイスよりもメモリと電源がはるかに少なく、組み込まれる傾向があるモノのインターネット(IoT) とマシン間(M2M) 通信にとって重要です。したがって、効率が非常に重要です。CoAP は、UDP または UDP アナログをサポートするほとんどのデバイスで実行できます。

Internet Engineering Task Force ( IETF ) の Constrained RESTful Environments Working Group (CoRE) は、このプロトコルの主要な標準化作業を行いました。プロトコルを IoT および M2M アプリケーションに適したものにするために、さまざまな新機能が追加されました。

プロトコルのコアはRFC  7252 で規定されています。特に次のようなさまざまな拡張が提案されています。

• RFC  7641 (2015) 制約付きアプリケーションプロトコルにおけるリソースの監視
• RFC  7959 (2016) 制約付きアプリケーション プロトコル (CoAP) におけるブロック単位の転送
• RFC  8323 (2018) TCP、TLS、WebSocket経由の CoAP (制約付きアプリケーション プロトコル)
• RFC  8974 (2021) 制約付きアプリケーション プロトコル (CoAP) における拡張トークンとステートレス クライアント

CoAP は、シンプルなバイナリ ヘッダー形式を使用して、要求と応答の 2 つのメッセージ タイプを使用します。CoAP はデフォルトでUDPにバインドされ、オプションでDTLSにバインドされているため、高度な通信セキュリティが提供されます。UDP にバインドされている場合、メッセージ全体が1 つのデータグラム内に収まる必要があります。RFC 4944 で定義されている6LoWPANで使用する場合、メッセージは 1 つのIEEE 802.15.4フレームに収まるようにして、断片化を最小限に抑える必要があります。

トークン、オプション、およびペイロード フィールドが省略されている場合、つまり CoAP ヘッダーのみで構成されている場合、最小の CoAP メッセージの長さは 4 バイトです。ヘッダーの後にはトークン値 (0 ～ 8 バイト) が続き、その後には最適化されたタイプ、長さ、値の形式でオプションのリストが続く場合があります。ヘッダー、トークン、およびオプション (ある場合) の後のバイトはメッセージ ペイロードと見なされ、1 バイトの「ペイロード マーカー」(0xFF) がプレフィックスとして付きます。ペイロードの長さはデータグラムの長さによって決まります。

最初の 4 バイトはすべての CoAP データグラムで必須であり、固定サイズのヘッダーを構成します。

これらのフィールドは、次のマクロを使用して C の 4 バイトから抽出できます。

#define COAP_HEADER_VERSION(データ) ( (0xC0 & (データ)[0]) >> 6 ) 
#define COAP_HEADER_TYPE(データ) ( (0x30 & (データ)[0]) >> 4 ) 
#define COAP_HEADER_TKL(データ) ( (0x0F & (データ)[0]) >> 0 ) 
#define COAP_HEADER_CLASS(データ) ( ((データ)[1] >> 5) & 0x07 ) 
#define COAP_HEADER_CODE(データ) ( ((データ)[1] >> 0) & 0x1F ) 
#define COAP_HEADER_MID(データ) ( ((データ)[2] << 8) | (データ)[3] )

CoAP のバージョン番号を示します。

これは、リクエストとレスポンスの 2 つのメッセージ タイプ コンテキストのデータグラムのメッセージ タイプについて説明します。

• リクエスト
  • 0: 確認可能: このメッセージは対応する確認メッセージを期待します。
  • 1 : 確認不可 : このメッセージは確認メッセージを期待していません。
• 応答
  • 2: 確認: このメッセージは確認可能なメッセージを確認する応答です
  • 3: リセット: このメッセージは、メッセージを受信したが処理できなかったことを示します。

可変長トークン フィールドの長さを示します。長さは 0 ～ 8 バイトです。

上位 3 ビットは、「クラス」と呼ばれる数値を形成します。これは、HTTP ステータス コードのクラスに類似しています。下位 5 ビットは、要求または応答に関する詳細を伝えるコードを形成します。コード全体は通常、 の形式で伝えられますclass.code。

最新のCoAP要求/応答コードは[1]で見つけることができますが、以下のリストにいくつかの例を示します。

メッセージの重複を検出し、確認/リセット タイプのメッセージを、確認可能/確認不可タイプのメッセージと一致させるために使用されます。

すべてのリクエストには、クライアントによって生成された値を持つトークン (ただし、長さが 0 の場合もあります) が含まれます。サーバーは、対応する応答で、すべてのトークン値を変更せずにクライアントに返す必要があります。これは、特に同時要求の場合に、リクエストと応答を一致させるためのクライアント ローカル識別子として使用することを目的としています。

要求と応答のマッチングはメッセージ ID では行われません。応答は確認応答 (メッセージ ID をマッチングに使用) とは別のメッセージで送信される可能性があるためです。たとえば、結果の取得に時間がかかる場合に再送信を防ぐためにこれを行うことができます。このような分離された応答は「個別応答」と呼ばれます。対照的に、応答を確認応答で直接送信することは「ピギーバック応答」と呼ばれ、効率上の理由から好まれると予想されます。

オプションデルタ:

• 0～12: 0～12のデルタの場合: 最後のオプションIDと目的のオプションID間の正確なデルタ値を表します。オプションデルタ拡張値はありません。
• 13: デルタが13から268の場合: オプションデルタ拡張は、オプションデルタ値から13を引いた値を表す8ビット値です。
• 14: デルタが269から65,804の場合: オプションデルタ拡張は、オプションデルタ値から269を引いた値を表す16ビット値です。
• 15: ペイロード マーカー用に予約されており、オプション デルタとオプション長は 0xFF として一緒に設定されます。

オプションの長さ:

• 0～12: オプションの長さが0～12の場合: オプションの長さの拡張値なしで正確な長さの値を表します
• 13: オプション長が13から268の場合: オプション長拡張は、オプション長値から13を引いた値を表す8ビット値です。
• 14: オプション長が269から65,804の場合: オプション長拡張は、オプション長値から269を引いた値を表す16ビット値です。
• 15: 将来の使用のために予約されています。オプション長フィールドが 0xFF に設定されている場合、エラーになります。

オプション値:

• オプション値フィールドのサイズは、バイト単位のオプション長値によって定義されます。
• このフィールドの意味と形式はそれぞれのオプションによって異なります。

• 透過的な HTTP-CoAP マッピング モジュールを備えた Squid 3.1.9
• jcoap プロキシ
• カリフォルニウム cf-proxy2
• コーアポン
• フリーCoAP

多くの CoAP アプリケーション ドメインでは、各リソースを個別にアドレス指定するのではなく、複数の CoAP リソースをグループとしてアドレス指定する機能が不可欠です (たとえば、照明スイッチを切り替えることでトリガーされる単一の CoAP 要求で、部屋内のすべての CoAP 対応照明をオンにする)。このニーズに対応するために、IETF は実験的な RFC の形式で CoAP のオプション拡張機能を開発しました: CoAP のグループ通信 - RFC 7390 ^[3] この拡張機能は、IP マルチキャストを使用して CoAP 要求をすべてのグループ メンバーに配信します。マルチキャストを使用すると、メンバーに要求を配信するために必要なパケットの数を減らすなど、特定の利点があります。ただし、マルチキャストには、信頼性が低い、キャッシュに適していないなどの制限もあります。マルチキャストの代わりにユニキャストを使用する CoAP グループ通信の代替方法は、グループが作成される仲介者に依存します。クライアントはグループ要求を仲介者に送信し、仲介者は次に個々のユニキャスト要求をグループ メンバーに送信し、メンバーからの応答を収集して、集約された応答をクライアントに返します。^[4]

CoAPは4つのセキュリティモードを定義している: ^[5]

• DTLSが無効になっているNoSec
• PreSharedKey (DTLS が有効になっている場合) には事前共有キーのリストがあり、各キーには通信に使用できるノードのリストが含まれています。デバイスは AES 暗号スイートをサポートしている必要があります。
• RawPublicKey: DTLS が有効になっており、デバイスは証明書なしで非対称キー ペアを使用し、帯域外で検証されます。デバイスは、キー交換のために AES 暗号スイートと楕円曲線アルゴリズムをサポートする必要があります。
• 証明書。DTLS が有効になっており、デバイスは検証にX.509証明書を使用します。

CoAPトラフィックのセキュリティラッパーとしてDTLSを使用するのではなく、セキュリティアソシエートをCoAPリソースとして実装することでDTLSを最適化する研究が行われてきました。この研究では、最適化されていない実装の最大6.5倍の改善が示されました。^[6]

DTLSに加えて、RFC8613 ^[7]は、アプリケーション層でCoAPのセキュリティを提供する制約付きRESTful環境のためのオブジェクトセキュリティ（OSCORE）プロトコルを定義しています。

プロトコル標準にはDDoS増幅攻撃の脅威を軽減するための規定が含まれていますが^[8]、これらの規定は実際には実装されておらず^[9] 、その結果、主に中国に位置する580,000を超えるターゲットが存在し、最大320Gbit/sの攻撃が発生しています^{[10] 。}

• モノのインターネット
• OMA 軽量 M2M
• モノのウェブ
• 静的コンテキスト ヘッダー圧縮 (SCHC)

Wikimedia Commons にはSSL と TLSに関連するメディアがあります。

• RFC 7252「制約付きアプリケーション プロトコル (CoAP)」
• coap.me –ブレーメン大学が運営する CoAP テスト サーバー