Protokół aplikacji z ograniczeniami — Constrained Application Protocol

Protokół aplikacji z ograniczeniami ( CoAP ) to wyspecjalizowany protokół aplikacji internetowych dla urządzeń z ograniczeniami, zgodnie z definicją w RFC 7252 . Umożliwia tym ograniczonym urządzeniom zwanym „węzłami” komunikowanie się z szerszym Internetem przy użyciu podobnych protokołów. CoAP jest przeznaczony do użytku między urządzeniami w tej samej sieci z ograniczeniami (np. sieci o niskim poborze mocy, sieci ze stratami), między urządzeniami i ogólnymi węzłami w Internecie oraz między urządzeniami w różnych sieciach z ograniczeniami, które są połączone przez Internet. CoAP jest również wykorzystywany za pośrednictwem innych mechanizmów, takich jak SMS w sieciach telefonii komórkowej.

CoAP to protokół warstwy usług , który jest przeznaczony do użytku w urządzeniach internetowych o ograniczonych zasobach, takich jak węzły sieci czujników bezprzewodowych . CoAP został zaprojektowany z myślą o łatwym tłumaczeniu na HTTP w celu uproszczenia integracji z Internetem, przy jednoczesnym spełnieniu specjalistycznych wymagań, takich jak obsługa multiemisji , bardzo niskie koszty ogólne i prostota. Multiemisja, niskie koszty ogólne i prostota są ważne dla Internetu rzeczy (IoT) i komunikacji maszyna-maszyna (M2M), które są zwykle głęboko osadzone i mają znacznie mniej pamięci i zasilania niż tradycyjne urządzenia internetowe. Dlatego bardzo ważna jest wydajność. CoAP może działać na większości urządzeń obsługujących UDP lub analog UDP.

Internet Engineering Task Force ( IETF ) Ograniczone relaksującego Środowiska Working Group ( rdzeń ) uczynił główną prac normalizacyjnych do niniejszego protokołu. Aby protokół był odpowiedni dla aplikacji IoT i M2M, dodano różne nowe funkcje.

Specyfikacja

Rdzeń protokołu jest określony w RFC 7252. Zaproponowano różne rozszerzenia, w szczególności:

• RFC  7641 (2015) Obserwacja zasobów w protokole ograniczonej aplikacji
• RFC  7959 (2016) Transfery blokowe w protokole ograniczonej aplikacji (CoAP)
• RFC  8323 (2018) CoAP (Constrained Application Protocol) przez TCP, TLS i WebSockets
• RFC  8974 (2021) Rozszerzone tokeny i klienci bezstanowe w ograniczonym protokole aplikacji (CoAP)

Formaty wiadomości

Najmniejsza wiadomość CoAP ma długość 4 bajtów, jeśli pominie się Token, Opcje i Ładunek. CoAP wykorzystuje dwa typy wiadomości, żądania i odpowiedzi, używając prostego, binarnego, podstawowego formatu nagłówka. Po nagłówku podstawowym mogą następować opcje w zoptymalizowanym formacie Type-Length-Value. CoAP jest domyślnie powiązany z UDP i opcjonalnie z DTLS , zapewniając wysoki poziom bezpieczeństwa komunikacji.

Wszelkie bajty po nagłówkach w pakiecie są uważane za treść wiadomości. Długość treści wiadomości wynika z długości datagramu. Po połączeniu z UDP, cała wiadomość MUSI zmieścić się w jednym datagramie. W przypadku użycia z 6LoWPAN, jak zdefiniowano w RFC 4944, komunikaty POWINNY pasować do pojedynczej ramki IEEE 802.15.4, aby zminimalizować fragmentację.

Stały nagłówek CoAP: wersja, typ, długość tokena, kod żądania/odpowiedzi i identyfikator wiadomości.

Pierwsze 4 bajty są obowiązkowe we wszystkich datagramach CoAP.

Te pola można łatwo wyodrębnić z tych 4 bajtów w C za pomocą tych makr:

#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]) )

Wersja (VER) (2 bity)

Wskazuje numer wersji CoAP.

Typ (2 bity)

Opisuje typ komunikatu datagramu dla kontekstu dwóch typów komunikatów: żądania i odpowiedzi.

• Wniosek
  • 0 : Potwierdzone : Ten komunikat oczekuje odpowiedniego komunikatu potwierdzenia.
  • 1 : Brak potwierdzenia : Ta wiadomość nie oczekuje komunikatu potwierdzającego.
• Odpowiedź
  • 2: Potwierdzenie: Ta wiadomość jest odpowiedzią potwierdzającą wiadomość, którą można potwierdzić
  • 3 : Reset : Ta wiadomość wskazuje, że otrzymała wiadomość, ale nie może jej przetworzyć.

Długość tokena (4 bity)

Wskazuje długość pola Token o zmiennej długości, która może mieć długość od 0 do 8 bajtów.

Kod żądania/odpowiedzi (8 bitów)

Trzy najbardziej znaczące bity tworzą liczbę znaną jako „klasa”, która jest analogiczna do klasy kodów stanu HTTP . Pięć najmniej znaczących bitów tworzy kod, który przekazuje dalsze szczegóły dotyczące żądania lub odpowiedzi. Cały kod jest zazwyczaj przekazywany w formie class.code.

Najnowsze kody żądań/odpowiedzi CoAP można znaleźć pod adresem [1] , chociaż poniższa lista zawiera kilka przykładów:

Identyfikator wiadomości (16 bitów)

Służy do wykrywania duplikacji wiadomości i dopasowywania wiadomości typu Acknowledgement/Reset do wiadomości typu Confirmable/Non-confirmable.:Wiadomości odpowiedzi będą miały ten sam identyfikator wiadomości, co żądanie.

Znak

Pole opcjonalne, którego rozmiar jest wskazany przez pole Długość tokenu, którego wartości są generowane przez klienta. Serwer musi przesłać echo każdej wartości tokena bez żadnych modyfikacji z powrotem do klienta. Jest przeznaczony do użycia jako identyfikator lokalny klienta, aby zapewnić dodatkowy kontekst dla niektórych jednoczesnych transakcji.

Opcja

Różnica opcji:

• 0 do 12: Dla delta od 0 do 12: Reprezentuje dokładną wartość delty między ostatnim identyfikatorem opcji a żądanym identyfikatorem opcji, bez wartości Option Delta Extended
• 13: Dla delta od 13 do 268: Option Delta Extended to 8-bitowa wartość, która reprezentuje wartość Option Delta minus 13
• 14: Dla delta od 269 do 65 804: Option Delta Extended to 16-bitowa wartość, która reprezentuje wartość Option Delta minus 269
• 15: Zarezerwowane dla znacznika ładunku, gdzie Delta opcji i Długość opcji są ustawione razem jako 0xFF.

Długość opcji:

• 0 do 12: Dla opcji Długość od 0 do 12: Reprezentuje dokładną wartość długości, bez wartości Rozszerzona długość opcji
• 13: Dla długości opcji od 13 do 268: Rozszerzona długość opcji to wartość 8-bitowa, która reprezentuje wartość długości opcji minus 13
• 14: Dla długości opcji od 269 do 65 804: Rozszerzona długość opcji to 16-bitowa wartość, która reprezentuje wartość długości opcji minus 269
• 15: Zarezerwowane do wykorzystania w przyszłości. Jest to błąd, jeśli pole Długość opcji jest ustawione na 0xFF.

Wartość opcji:

• Rozmiar pola Wartość opcji określa wartość Długość opcji w bajtach.
• Semantyka i format tego pola zależy od odpowiedniej opcji.

Realizacje

Implementacje proxy

• Squid 3.1.9 z przezroczystym modułem mapowania HTTP-CoAP
• jcoap proxy
• Kaliforn cf-proxy2
• CoAPthon
• FreeCoAP

Komunikacja grupowa CoAP

W wielu domenach aplikacji CoAP niezbędna jest możliwość adresowania kilku zasobów CoAP jako grupy, zamiast adresowania każdego zasobu indywidualnie (np. włączenie wszystkich świateł z włączonym CoAP w pomieszczeniu za pomocą pojedynczego żądania CoAP wywołanego przez przełączenie przełącznik światła). Aby sprostać tej potrzebie, IETF opracował opcjonalne rozszerzenie dla CoAP w formie eksperymentalnego RFC: Group Communication for CoAP - RFC 7390 Rozszerzenie to opiera się na multiemisji IP w celu dostarczenia żądania CoAP do wszystkich członków grupy. Korzystanie z multiemisji ma pewne zalety, takie jak zmniejszenie liczby pakietów potrzebnych do dostarczenia żądania do członków. Jednak multiemisja ma również swoje ograniczenia, takie jak słaba niezawodność i nieprzyjazny dla pamięci podręcznej. Alternatywna metoda komunikacji grupowej CoAP, która wykorzystuje unicasty zamiast multicastów, polega na posiadaniu pośrednika, w którym tworzone są grupy. Klienci wysyłają swoje żądania grupowe do pośrednika, który z kolei wysyła indywidualne żądania emisji pojedynczej do członków grupy, zbiera od nich odpowiedzi i odsyła zagregowaną odpowiedź do klienta.

Bezpieczeństwo

CoAP definiuje cztery tryby bezpieczeństwa

• NoSec, gdzie DTLS jest wyłączony
• PreSharedKey, gdy DTLS jest włączony, istnieje lista wstępnie udostępnionych kluczy, a każdy klucz zawiera listę węzłów, z którymi może się komunikować. Urządzenia muszą obsługiwać zestaw szyfrów AES.
• RawPublicKey, gdzie włączony jest DTLS, a urządzenie używa asymetrycznej pary kluczy bez certyfikatu, która jest weryfikowana poza pasmem. Urządzenia muszą obsługiwać zestaw szyfrów AES i algorytmy krzywej eliptycznej do wymiany kluczy.
• Certyfikat, w którym włączona jest obsługa DTLS, a urządzenie używa certyfikatów X.509 do walidacji.

Przeprowadzono badania nad optymalizacją DTLS poprzez zaimplementowanie partnerów bezpieczeństwa jako zasobów CoAP zamiast używania DTLS jako opakowania bezpieczeństwa dla ruchu CoAP. Badanie to wykazało, że ulepszenia do 6,5 razy nie zoptymalizowane wdrożeń.

Oprócz DTLS, RFC8613 definiuje protokół Object Security for Constrained RESTful Environments ( OSCORE ), który zapewnia bezpieczeństwo dla CoAP w warstwie aplikacji.

Problemy z bezpieczeństwem

Chociaż standard protokołu zawiera zapisy dotyczące łagodzenia zagrożenia atakami wzmacniającymi DDoS , postanowienia te nie są w praktyce implementowane, co skutkuje obecnością ponad 580 000 celów zlokalizowanych głównie w Chinach i atakami o przepustowości do 320 Gb/s.

Zobacz też

• Internet przedmiotów
• OMA Lekki M2M
• Sieć rzeczy
• Kompresja nagłówka kontekstu statycznego (SCHC)

Bibliografia

Zewnętrzne linki

• RFC 7252 „Protokół aplikacji z ograniczeniami (CoAP)”
• coap.me – serwer testowy CoAP prowadzony przez Uniwersytet w Bremie