Eingeschränktes Anwendungsprotokoll

Das Constrained Application Protocol ( CoAP ) ist ein spezielles , UDP-basiertes Internet-Anwendungsprotokoll für ressourcenbeschränkte Geräte, wie in RFC 7252 (veröffentlicht 2014) definiert. Es ermöglicht diesen ressourcenbeschränkten Geräten, sogenannten „Knoten“, die Kommunikation mit dem Internet über ähnliche Protokolle. CoAP ist für die Kommunikation zwischen Geräten im selben ressourcenbeschränkten Netzwerk (z. B. energiearme, verlustbehaftete Netzwerke), zwischen Geräten und allgemeinen Knoten im Internet sowie zwischen Geräten in verschiedenen ressourcenbeschränkten Netzwerken, die beide mit dem Internet verbunden sind, konzipiert. CoAP wird auch über andere Mechanismen wie SMS in Mobilfunknetzen genutzt.

CoAP ist ein Anwendungsschichtprotokoll, das für ressourcenbeschränkte Internetgeräte wie Knoten in drahtlosen Sensornetzwerken entwickelt wurde . CoAP lässt sich leicht in HTTP übersetzen und so einfach ins Web integrieren. Gleichzeitig erfüllt es spezielle Anforderungen wie Multicast- Unterstützung, sehr geringen Overhead und Einfachheit. ^{[ 1 ] [ 2 ]} Multicast, geringer Overhead und Einfachheit sind wichtig für das Internet der Dinge (IoT) und die Maschine-zu-Maschine -Kommunikation (M2M), da diese Geräte häufig eingebettet sind und deutlich weniger Speicher und Stromversorgung als herkömmliche Internetgeräte besitzen. Daher ist Effizienz von großer Bedeutung. CoAP ist auf den meisten Geräten lauffähig, die UDP oder ein UDP-Äquivalent unterstützen.

Die Arbeitsgruppe „Constrained RESTful Environments“ ( CoRE ) der Internet Engineering Task Force ( IETF ) hat die wichtigsten Standardisierungsarbeiten für dieses Protokoll durchgeführt. Um das Protokoll für IoT- und M2M-Anwendungen geeignet zu machen, wurden verschiedene neue Funktionen hinzugefügt.

Der Kern des Protokolls ist in RFC  7252 spezifiziert . Es wurden verschiedene Erweiterungen vorgeschlagen, insbesondere:

• RFC  7641 (2015) Beobachtung von Ressourcen im Constrained Application Protocol
• RFC  7959 (2016) Blockweise Übertragungen im Constrained Application Protocol (CoAP)
• RFC  8323 (2018) CoAP (Constrained Application Protocol) über TCP, TLS und WebSockets
• RFC  8974 (2021) Erweiterte Token und zustandslose Clients im Constrained Application Protocol (CoAP)

CoAP verwendet zwei Nachrichtentypen, Anfragen und Antworten, mit einem einfachen, binären Header-Format. Standardmäßig ist CoAP an UDP und optional an DTLS gebunden und bietet so ein hohes Maß an Kommunikationssicherheit. Bei Bindung an UDP muss die gesamte Nachricht in ein einzelnes Datagramm passen. Bei Verwendung mit 6LoWPAN gemäß RFC 4944 sollten Nachrichten in einen einzelnen IEEE-802.15.4 -Frame passen, um die Fragmentierung zu minimieren.

Die kürzeste CoAP-Nachricht ist 4 Byte lang, wenn Token, Optionen und Nutzdaten weggelassen werden, d. h. wenn sie nur aus dem CoAP-Header besteht. Auf den Header folgt der Tokenwert (0 bis 8 Byte), dem gegebenenfalls eine Liste von Optionen in einem optimierten Typ-Längen-Wert-Format folgt. Alle Bytes nach Header, Token und Optionen (falls vorhanden) bilden die Nutzdaten der Nachricht. Diese beginnen mit dem ein Byte langen Nutzdatenmarker (0xFF). Die Länge der Nutzdaten ergibt sich aus der Datagrammlänge.

Die ersten 4 Bytes sind in allen CoAP-Datagrammen obligatorisch; sie bilden den Header fester Größe.

Diese Felder können in C mithilfe dieser Makros aus diesen 4 Bytes extrahiert werden:

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

Gibt die CoAP-Versionsnummer an.

Dies beschreibt den Nachrichtentyp des Datagramms für den Zwei-Nachrichtentyp-Kontext von Anfrage und Antwort.

• Anfrage
  • 0 : Bestätigbar : Diese Nachricht erwartet eine entsprechende Bestätigungsnachricht.
  • 1 : Nicht bestätigbar : Diese Nachricht erwartet keine Bestätigungsnachricht.
• Antwort
  • 2 : Bestätigung : Diese Nachricht ist eine Antwort, die den Empfang einer bestätigungspflichtigen Nachricht bestätigt.
  • 3 : Reset : Diese Meldung bedeutet, dass eine Nachricht empfangen, aber nicht verarbeitet werden konnte.

Gibt die Länge des Token-Felds variabler Länge an, das 0–8 Byte lang sein kann.

Die drei höchstwertigen Bits bilden eine Zahl, die als „Klasse“ bezeichnet wird und analog zur Klasse der HTTP-Statuscodes ist . Die fünf niederwertigsten Bits bilden einen Code, der weitere Details zur Anfrage oder Antwort enthält. Der gesamte Code wird typischerweise in der Form übermittelt class.code.

Die neuesten CoAP-Anfrage-/Antwortcodes finden Sie unter [1] , wobei die folgende Liste einige Beispiele enthält:

Wird verwendet, um doppelte Nachrichten zu erkennen und Nachrichten vom Typ Bestätigung/Zurücksetzung mit Nachrichten vom Typ Bestätigbar/Nicht bestätigbar abzugleichen.

Jede Anfrage enthält ein Token (das auch leer sein kann), dessen Wert vom Client generiert wurde. Der Server muss jeden Token-Wert unverändert in der entsprechenden Antwort an den Client zurücksenden. Er dient als clientseitiger Identifikator zum Abgleich von Anfragen und Antworten, insbesondere bei gleichzeitigen Anfragen.

Der Abgleich von Anfragen und Antworten erfolgt nicht über die Nachrichten-ID, da eine Antwort in einer separaten Nachricht und die Bestätigung (die die Nachrichten-ID zum Abgleich verwendet) gesendet werden kann. Dies kann beispielsweise geschehen, um erneute Übertragungen zu vermeiden, wenn die Ergebnisermittlung einige Zeit in Anspruch nimmt. Eine solche separate Antwort wird als „getrennte Antwort“ bezeichnet. Im Gegensatz dazu wird die direkte Übermittlung der Antwort in der Bestätigung als „mitgesendete Antwort“ bezeichnet, was aus Effizienzgründen bevorzugt werden sollte.

Option Delta:

• 0 bis 12: Für Deltawerte zwischen 0 und 12: Stellt den exakten Deltawert zwischen der letzten Options-ID und der gewünschten Options-ID dar, ohne erweiterten Deltawert.
• 13: Für Delta von 13 bis 268: Option Delta Extended ist ein 8-Bit-Wert, der den Option-Delta-Wert minus 13 darstellt.
• 14: Für Delta von 269 bis 65.804: Das erweiterte Optionsdelta ist ein 16-Bit-Wert, der den Optionsdeltawert minus 269 darstellt.
• 15: Reserviert für die Nutzlastmarkierung, bei der das Optionsdelta und die Optionslänge zusammen auf 0xFF gesetzt sind.

Optionslänge:

• 0 bis 12: Für Optionslängen zwischen 0 und 12: Stellt den exakten Längenwert ohne Erweiterungswert für die Optionslänge dar.
• 13: Bei Optionslängen von 13 bis 268: Die erweiterte Optionslänge ist ein 8-Bit-Wert, der die Optionslänge minus 13 darstellt.
• 14: Bei Optionslängen von 269 bis 65.804: Die erweiterte Optionslänge ist ein 16-Bit-Wert, der die Optionslänge minus 269 darstellt.
• 15: Für zukünftige Verwendung reserviert. Es ist ein Fehler, wenn das Feld für die Optionslänge auf 0xFF gesetzt ist.

Optionswert:

• Die Größe des Optionswertfelds wird durch den Wert für die Optionlänge in Bytes definiert.
• Semantik und Format dieses Feldes hängen von der jeweiligen Option ab.

Es gibt Proxy- Implementierungen, die Forward- oder Reverse -Proxy-Funktionalität für das CoAP-Protokoll bereitstellen , sowie Implementierungen, die zwischen Protokollen wie HTTP und CoAP übersetzen.

Die folgenden Projekte bieten Proxy-Funktionalität:

• Squid 3.1.9 mit transparentem HTTP-CoAP-Mapping-Modul
• jcoap-Proxy
• Californium cf-proxy2
• CoAPthon
• FreeCoAP
• libcoap

In many CoAP application domains it is essential to have the ability to address several CoAP resources as a group, instead of addressing each resource individually (e.g. to turn on all the CoAP-enabled lights in a room with a single CoAP request triggered by toggling the light switch). To address this need, the IETF has developed an optional extension for CoAP in the form of an experimental RFC: Group Communication for CoAP - RFC 7390^[3] This extension relies on IP multicast to deliver the CoAP request to all group members. The use of multicast has certain benefits such as reducing the number of packets needed to deliver the request to the members. However, multicast also has its limitations such as poor reliability and being cache-unfriendly. An alternative method for CoAP group communication that uses unicasts instead of multicasts relies on having an intermediary where the groups are created. Clients send their group requests to the intermediary, which in turn sends individual unicast requests to the group members, collects the replies from them, and sends back an aggregated reply to the client.^[4]

CoAP defines four security modes:^[5]

• NoSec, where DTLS is disabled
• PreSharedKey, where DTLS is enabled, there is a list of pre-shared keys, and each key includes a list of which nodes it can be used to communicate with. Devices must support the AES cipher suite.
• RawPublicKey, where DTLS is enabled and the device uses an asymmetric key pair without a certificate, which is validated out of band. Devices must support the AES cipher suite and Elliptic Curve algorithms for key exchange.
• Certificate, where DTLS is enabled and the device uses X.509 certificates for validation.

Research has been conducted on optimizing DTLS by implementing security associates as CoAP resources rather than using DTLS as a security wrapper for CoAP traffic. This research has indicated that improvements of up to 6.5 times none optimized implementations.^[6]

In addition to DTLS, RFC8613^[7] defines the Object Security for Constrained RESTful Environments (OSCORE) protocol which provides security for CoAP at the application layer.

Although the protocol standard includes provisions for mitigating the threat of DDoS amplification attacks,^[8] these provisions are not implemented in practice,^[9] resulting in the presence of over 580,000 targets primarily located in China and attacks up to 320 Gbit/s.^[10]

• Internet of Things
• OMA Lightweight M2M
• Web of Things
• Statische Kontextheader-Komprimierung (SCHC)

• RFC 7252 „Das Constrained Application Protocol (CoAP)“
• coap.me – CoAP-Testserver der Universität Bremen