Elvis Wiki - User contributions [en]

Constrained Application Protocol

2019-04-09T14:21:48Z

Awolfsbauer:

The '''Constrained Application Protocol''' ('''CoAP''') is a specialized web transfer protocol, as defined in RFC 7252, for use with constrained nodes and constrained networks in the Internet of Things.
The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation.

== Features ==

The work on Constrained Environments aims at realizing the REST architecture in a suitable form for the most constrained nodes and networks. The nodes usually consist of 8-bit microcontrollers with limited amounts of RAM and ROM.

CoAP has the following main features:

* Web protocol fulfilling M2M requirements in constrained environments
* UDP [RFC0768] binding with optional reliability supporting unicast and multicast requests
* Asynchronous message exchanges
* Low header overhead and parsing complexity
* URI and Content-type support
* Simple proxy and caching capabilities
* Stateless HTTP mapping
* Security binding to Datagram Transport Layer Security (DTLS)

== The Protocol ==

CoAP is similar to the client/server model of HTTP. M2M interactions typically result in a CoAP implementation acting in both client and server roles. A request is sent by a client to request an action on a resource (identified by a URI) on a server. The server then sends a response with a response code (equivalent to that of HTTP). Therefore, efficiency is very important, so CoAP uses UDP, a datagram-oriented transport.

CoAP is however a single protocol, with messaging and request/response as just features of the CoAP header

+----------------------+
| Application |
+----------------------+
+----------------------+ \
| Requests/Responses | |
|----------------------| | CoAP
| Messages | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+

== Message Format ==

By default, the messages are encoded in a simple binary format and transported over UDP. The message format starts with a fixed-size 4-byte header, followed by a variable-length Token value, which can be between 0 and 8 bytes long. Following the Token value comes a sequence of zero or more CoAP Options in Type-Length-Value (TLV) format, optionally followed by a payload that takes up the rest of the datagram.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

;Version (Ver) (2 bits)
:Indicates the CoAP Version number. This must set this field to 1 (binary 01). Other values are reserved for future versions.

;Type (T) (2 bits)
:Indicates if this message is of type Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3).

;Token Length (TKL) (4 bits)
:Indicates the length of the variable-length Token field, which may be 0-8 bytes in length.

;CoAP Request/Response Code (8 bits)
:Splits into a 3-bit class and 5-bit detail.

;Message ID (16 bits)
:Used to detect message duplication and to match messages of type Acknowledgement/Reset to messages of type Confirmable/Non-confirmable.

== Security Considerations ==

This section gives an overview of possible threats to the protocol as listed in section 11 of [https://tools.ietf.org/html/rfc7252 RFC 7252]. As CoAP realizes a subset of the features of HTTP/1.1, the security considerations in section 15 of [https://www.ietf.org/rfc/rfc2616.txt RFC2616] are also pertinent to CoAP.

Note:"NoSec" mode means that the system simply sends packets over normal UDP over IP and is indicated by the "coap" scheme and the CoAP default port. The system is secured only by keeping attackers from being able to send or receive packets from the network with the CoAP nodes. There is no protocol-level security (DTLS is disabled). The other available modes for securing CoAP are listed in section 9 of RFC7252.

;Parsing the Protocol and Processing URI's

The URI processing code in CoAP is likely to be a large source of vulnerabilities and should be implemented very carefully. Vulnerabilities include remotely crashing a node and remotely executing arbitrary code. CoAP aims to reduce the risk of these vulnerabilities by reducing parser complexity and moving much of the URI processing to the clients.

;Proxying and Caching

Proxies are man-in-the-middle by their nature. They can break any IPsec or DTLS protection that would otherwise happen between direct CoAP message exchange. Risks include the loss of confidentiality and availability. If the proxies also cache the threat to confidentiality and integrity of request/response data is amplified as CoAP does not implement cache-suppressing Cache-control as in HTTP/1.1.
For caching implementations any access control considerations also need to be applied to the value in the cache. A caching proxy must not make cache values available to requests that have lesser transport-security properties.

;Risk of Amplification

As CoAP server reply to request packets with response packets that may be significantly larger an attacker can use CoAP nodes to generate more traffic and use them in a denial-of-service(DoS) attack. Turning a small attack packet into a larger one is called amplification. The attacker wants to overload a victim but is limited in the amount of traffic can use amplification to generate larger amounts. If a node that enables NoSec access becomes available to an attacker it can access victims on the general internet. UDP provides no way to verify the source address given in the request packet and an attacker can place the IP of the victim in the source address of a request packet to generate a larger packet directed at the victim. The risk is reduced however as constrained networks are only able to generate small amounts of traffic. In contrast the network itself with its limited capacity is a viable victim of an amplification attack. Large amplification factors should not be provided if the request is not authenticated. Also the slicing/blocking modes of CoAP [BLOCK] should be used for large resources. Because CoAP supports the use of multicast IP addresses in requests, CoAP servers should not accept multicast requests that can not be authenticated. Servers should limit the use of multicast requests as they can be a source of an accidental or deliberate DoS attack.

;IP Address Spoofing

As there is no handshake in UDP a rogue endpoint that can read and write messages can attack a single endpoint, a group of endpoints or the whole network.

#Spoofing a Reset message in response to a message making an endpoint "deaf"
#Spoofing an ACK in response to a CON, preventing the sender of the CON from retransmitting to drown out the actual response
#Spoofing the entire response with forged payload/options, attacking a single endpoint or the supporting infrastructure
#Spoofing a multicast request for a target node resulting in network congestion or collapse due to a DoS attack on the victim, or forced wake-up from sleeping
#Spoofing observe messages

Response spoofing can be mitigated by choosing a nontrivial, randomized token in the request. Other kinds of spoofing can only be detected by CoAP if Confirmable message semantics are used and if one keeps track of Message ID's. A client can also attempt to overload a server by sending complex requests as the cost of a CON request is small. This can be used in a battery depletion attack or to make the server run out of resources for processing legitimate traffic. All these attacks can be prevented if a security mode other than NoSec is used.

;Cross-Protocol Attacks

In general, for any pair of protocols, one could have been designed in a way, that enables an attacker to cause the generation of replies that look like messages of the other protocol. Because a CoAP endpoint can be manipulated to send packets to a fake source address it can be used to attack a victim listening to UDP packets at a given IP address and port.

#The attacker sends a message to a CoAP endpoint with the given address as the fake source address.
#The endpoint replies with a message to the source address.
#The victim receives a UDP packet that it interprets according to the rules of a different protocol.

This can be used to circumvent firewall rules that prevent direct communication but allow communication from the CoAP endpoint. This scenario can work the other way too. A CoAP endpoint could be attacked from another UDP-based protocol. Attacks are possible if the endpoints rely only on checking IP addresses. To prevent these kinds of attacks strict checking of syntax of packets received should be implemented. Furthermore endpoints should not authorize actions based on trusting the source IP address of a packet.

;Constrained Node Considerations

Keys should be generated externally and added to the device during manufacturing or commissioning. Due to low processing power constrained nodes are susceptible to timing attacks. Cryptographic principles should be implemented with special care as many nodes are installed in exposed environments and have little resistance to tampering. The scope of credentials assigned to them should be considered carefully. A shared key assigned to a group of nodes may make any single node a target for subverting the entire group.

== Implementations ==

Generic implementations are becoming available for a variety of platforms. Implementations for constrained devices are typically written in C. CoAP is also used between them and more powerful systems such as cloud servers, home centrals, smartphones:

{| class="wikitable sortable"
|-
! Name !! Programming Language !! Client/Server !! License !! Link
|-
| Erbium for Contiki || C || Client + Server || 3-clause BSD || http://www.contiki-os.org/
|-
| libcoap || C || Client + Server || BSD/GPL || https://libcoap.net/
|-
| Eclipse tinydtls || C || Client + Server || EPL+EDL || https://projects.eclipse.org/projects/iot.tinydtls
|-
| LibNyoci || C || Client + Server || MIT || https://github.com/darconeous/libnyoci
|-
| microcoap || C || Client + Server || MIT || https://github.com/1248/microcoap
|-
| cantcoap || C++/C || Client + Server || BSD || https://github.com/staropram/cantcoap
|-
| Lobaro CoAP || C || Client + Server || MIT || https://www.lobaro.com/portfolio/lobaro-coap/
|-
| MR-CoAP || Java || || BSD || https://github.com/MR-CoAP/CoAP
|-
| Wakaama || C || Client + Server || EPL+EDL || https://www.eclipse.org/wakaama/index.html
|-
| coap-node || Javascript || Client || MIT || https://github.com/PeterEB/coap-node
|-
| coap-shepherd || Javascript || Server || MIT || https://github.com/PeterEB/coap-shepherd
|-
| Californium || Java || Client + Server || EPL+EDL || https://www.eclipse.org/californium
|-
| nCoap || Java || Client + Server || BSD || https://github.com/okleine/nCoAP
|-
| leshan || Java || Client + Server || EPL+EDL || https://github.com/eclipse/leshan
|-
| CoAP.NET || C# || Client + Server || 3-clause BSD || https://github.com/smeshlink/CoAP.NET
|-
| CoAPSharp || C#, .NET || Client + Server || LGPL || http://www.coapsharp.com
|-
| Waher.Networking.CoAP || C# || Server || || https://github.com/PeterWaher/IoTGateway
|-
| gen_coap || Erlang || Client + Server || MPL v1.1 || https://github.com/gotthardp/gen_coap
|-
| go-coap || Go || Client + Server || MIT || https://github.com/go-ocf/go-coap
|-
| node-coap || Javascript || Client + Server || MIT || https://github.com/mcollina/node-coap
|-
| coap-cli || Javascript || || MIT || https://github.com/mcollina/coap-cli
|-
| txThings || Python (Twisted) || Client + Server || MIT || https://github.com/mwasilak/txThings
|-
| aiocoap || Python 3 || Client + Server || MIT || https://github.com/chrysn/aiocoap
|-
| CoAPthon || Python || Client + Server || MIT || https://github.com/Tanganelli/CoAPthon
|-
| Ruby coap || Ruby || Client || MIT || https://github.com/nning/coap
|-
| Ruby david || Ruby || Server || MIT || https://github.com/nning/david
|-
| coap-rs || Rust || Client + Server || MIT || https://github.com/Covertness/coap-rs
|-
| Copper || JavaScript (Browser Plugin) || Client || BSD || https://github.com/mkovatsc/Copper
|-
| iCoAP || Objective-C || Client || MIT || https://github.com/stuffrabbit/iCoAP
|-
| SwiftCoAP || Swift || Client + Server || MIT || https://github.com/stuffrabbit/SwiftCoAP
|-
| nCoap || Java || Client + Server || BSD || https://github.com/okleine/nCoAP
|-
| txThings || Python (Twisted) || Client + Server || MIT || https://github.com/mwasilak/txThings
|}

== Courses ==

* [[Vertiefendes Wahlfach-Projekt]] (2018)
* [[CoAP Chat Application for RIOT OS]]

== References ==
* RFC 7252: https://tools.ietf.org/html/rfc7252
* RFC 2616: https://www.ietf.org/rfc/rfc2616.txt
* CoAP: RFC 7252 Constrained Application Protocol https://coap.technology/
* Learning Internet of Things: https://www.oreilly.com/library/view/learning-internet-of/9781783553532/

[[Category:Basic]]

Constrained Application Protocol

2019-04-09T14:20:01Z

Awolfsbauer:

The '''Constrained Application Protocol''' ('''CoAP''') is a specialized web transfer protocol, as defined in RFC 7252, for use with constrained nodes and constrained networks in the Internet of Things.
The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation.

== Features ==

The work on Constrained Environments aims at realizing the REST architecture in a suitable form for the most constrained nodes and networks. The nodes usually consist of 8-bit microcontrollers with limited amounts of RAM and ROM.

CoAP has the following main features:

* Web protocol fulfilling M2M requirements in constrained environments
* UDP [RFC0768] binding with optional reliability supporting unicast and multicast requests
* Asynchronous message exchanges
* Low header overhead and parsing complexity
* URI and Content-type support
* Simple proxy and caching capabilities
* Stateless HTTP mapping
* Security binding to Datagram Transport Layer Security (DTLS)

== The Protocol ==

CoAP is similar to the client/server model of HTTP. M2M interactions typically result in a CoAP implementation acting in both client and server roles. A request is sent by a client to request an action on a resource (identified by a URI) on a server. The server then sends a response with a response code (equivalent to that of HTTP). Therefore, efficiency is very important, so CoAP uses UDP, a datagram-oriented transport.

CoAP is however a single protocol, with messaging and request/response as just features of the CoAP header

+----------------------+
| Application |
+----------------------+
+----------------------+ \
| Requests/Responses | |
|----------------------| | CoAP
| Messages | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+

== Message Format ==

By default, the messages are encoded in a simple binary format and transported over UDP. The message format starts with a fixed-size 4-byte header, followed by a variable-length Token value, which can be between 0 and 8 bytes long. Following the Token value comes a sequence of zero or more CoAP Options in Type-Length-Value (TLV) format, optionally followed by a payload that takes up the rest of the datagram.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

;Version (Ver) (2 bits)
:Indicates the CoAP Version number. This must set this field to 1 (binary 01). Other values are reserved for future versions.

;Type (T) (2 bits)
:Indicates if this message is of type Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3).

;Token Length (TKL) (4 bits)
:Indicates the length of the variable-length Token field, which may be 0-8 bytes in length.

;CoAP Request/Response Code (8 bits)
:Splits into a 3-bit class and 5-bit detail.

;Message ID (16 bits)
:Used to detect message duplication and to match messages of type Acknowledgement/Reset to messages of type Confirmable/Non-confirmable.

== Security Considerations ==

This section gives an overview of possible threats to the protocol as listed in section 11 of RFC 7252. As CoAP realizes a subset of the features of HTTP/1.1, the security considerations in section 15 of RFC2616 are also pertinent to CoAP.

Note:"NoSec" mode means that the system simply sends packets over normal UDP over IP and is indicated by the "coap" scheme and the CoAP default port. The system is secured only by keeping attackers from being able to send or receive packets from the network with the CoAP nodes. There is no protocol-level security (DTLS is disabled). The other available modes for securing CoAP are listed in section 9 of RFC7252.

;Parsing the Protocol and Processing URI's

The URI processing code in CoAP is likely to be a large source of vulnerabilities and should be implemented very carefully. Vulnerabilities include remotely crashing a node and remotely executing arbitrary code. CoAP aims to reduce the risk of these vulnerabilities by reducing parser complexity and moving much of the URI processing to the clients.

;Proxying and Caching

Proxies are man-in-the-middle by their nature. They can break any IPsec or DTLS protection that would otherwise happen between direct CoAP message exchange. Risks include the loss of confidentiality and availability. If the proxies also cache the threat to confidentiality and integrity of request/response data is amplified as CoAP does not implement cache-suppressing Cache-control as in HTTP/1.1.
For caching implementations any access control considerations also need to be applied to the value in the cache. A caching proxy must not make cache values available to requests that have lesser transport-security properties.

;Risk of Amplification

As CoAP server reply to request packets with response packets that may be significantly larger an attacker can use CoAP nodes to generate more traffic and use them in a denial-of-service(DoS) attack. Turning a small attack packet into a larger one is called amplification. The attacker wants to overload a victim but is limited in the amount of traffic can use amplification to generate larger amounts. If a node that enables NoSec access becomes available to an attacker it can access victims on the general internet. UDP provides no way to verify the source address given in the request packet and an attacker can place the IP of the victim in the source address of a request packet to generate a larger packet directed at the victim. The risk is reduced however as constrained networks are only able to generate small amounts of traffic. In contrast the network itself with its limited capacity is a viable victim of an amplification attack. Large amplification factors should not be provided if the request is not authenticated. Also the slicing/blocking modes of CoAP [BLOCK] should be used for large resources. Because CoAP supports the use of multicast IP addresses in requests, CoAP servers should not accept multicast requests that can not be authenticated. Servers should limit the use of multicast requests as they can be a source of an accidental or deliberate DoS attack.

;IP Address Spoofing

As there is no handshake in UDP a rogue endpoint that can read and write messages can attack a single endpoint, a group of endpoints or the whole network.

#Spoofing a Reset message in response to a message making an endpoint "deaf"
#Spoofing an ACK in response to a CON, preventing the sender of the CON from retransmitting to drown out the actual response
#Spoofing the entire response with forged payload/options, attacking a single endpoint or the supporting infrastructure
#Spoofing a multicast request for a target node resulting in network congestion or collapse due to a DoS attack on the victim, or forced wake-up from sleeping
#Spoofing observe messages

Response spoofing can be mitigated by choosing a nontrivial, randomized token in the request. Other kinds of spoofing can only be detected by CoAP if Confirmable message semantics are used and if one keeps track of Message ID's. A client can also attempt to overload a server by sending complex requests as the cost of a CON request is small. This can be used in a battery depletion attack or to make the server run out of resources for processing legitimate traffic. All these attacks can be prevented if a security mode other than NoSec is used.

;Cross-Protocol Attacks

In general, for any pair of protocols, one could have been designed in a way, that enables an attacker to cause the generation of replies that look like messages of the other protocol. Because a CoAP endpoint can be manipulated to send packets to a fake source address it can be used to attack a victim listening to UDP packets at a given IP address and port.

#The attacker sends a message to a CoAP endpoint with the given address as the fake source address.
#The endpoint replies with a message to the source address.
#The victim receives a UDP packet that it interprets according to the rules of a different protocol.

This can be used to circumvent firewall rules that prevent direct communication but allow communication from the CoAP endpoint. This scenario can work the other way too. A CoAP endpoint could be attacked from another UDP-based protocol. Attacks are possible if the endpoints rely only on checking IP addresses. To prevent these kinds of attacks strict checking of syntax of packets received should be implemented. Furthermore endpoints should not authorize actions based on trusting the source IP address of a packet.

;Constrained Node Considerations

Keys should be generated externally and added to the device during manufacturing or commissioning. Due to low processing power constrained nodes are susceptible to timing attacks. Cryptographic principles should be implemented with special care as many nodes are installed in exposed environments and have little resistance to tampering. The scope of credentials assigned to them should be considered carefully. A shared key assigned to a group of nodes may make any single node a target for subverting the entire group.

== Implementations ==

Generic implementations are becoming available for a variety of platforms. Implementations for constrained devices are typically written in C. CoAP is also used between them and more powerful systems such as cloud servers, home centrals, smartphones:

{| class="wikitable sortable"
|-
! Name !! Programming Language !! Client/Server !! License !! Link
|-
| Erbium for Contiki || C || Client + Server || 3-clause BSD || http://www.contiki-os.org/
|-
| libcoap || C || Client + Server || BSD/GPL || https://libcoap.net/
|-
| Eclipse tinydtls || C || Client + Server || EPL+EDL || https://projects.eclipse.org/projects/iot.tinydtls
|-
| LibNyoci || C || Client + Server || MIT || https://github.com/darconeous/libnyoci
|-
| microcoap || C || Client + Server || MIT || https://github.com/1248/microcoap
|-
| cantcoap || C++/C || Client + Server || BSD || https://github.com/staropram/cantcoap
|-
| Lobaro CoAP || C || Client + Server || MIT || https://www.lobaro.com/portfolio/lobaro-coap/
|-
| MR-CoAP || Java || || BSD || https://github.com/MR-CoAP/CoAP
|-
| Wakaama || C || Client + Server || EPL+EDL || https://www.eclipse.org/wakaama/index.html
|-
| coap-node || Javascript || Client || MIT || https://github.com/PeterEB/coap-node
|-
| coap-shepherd || Javascript || Server || MIT || https://github.com/PeterEB/coap-shepherd
|-
| Californium || Java || Client + Server || EPL+EDL || https://www.eclipse.org/californium
|-
| nCoap || Java || Client + Server || BSD || https://github.com/okleine/nCoAP
|-
| leshan || Java || Client + Server || EPL+EDL || https://github.com/eclipse/leshan
|-
| CoAP.NET || C# || Client + Server || 3-clause BSD || https://github.com/smeshlink/CoAP.NET
|-
| CoAPSharp || C#, .NET || Client + Server || LGPL || http://www.coapsharp.com
|-
| Waher.Networking.CoAP || C# || Server || || https://github.com/PeterWaher/IoTGateway
|-
| gen_coap || Erlang || Client + Server || MPL v1.1 || https://github.com/gotthardp/gen_coap
|-
| go-coap || Go || Client + Server || MIT || https://github.com/go-ocf/go-coap
|-
| node-coap || Javascript || Client + Server || MIT || https://github.com/mcollina/node-coap
|-
| coap-cli || Javascript || || MIT || https://github.com/mcollina/coap-cli
|-
| txThings || Python (Twisted) || Client + Server || MIT || https://github.com/mwasilak/txThings
|-
| aiocoap || Python 3 || Client + Server || MIT || https://github.com/chrysn/aiocoap
|-
| CoAPthon || Python || Client + Server || MIT || https://github.com/Tanganelli/CoAPthon
|-
| Ruby coap || Ruby || Client || MIT || https://github.com/nning/coap
|-
| Ruby david || Ruby || Server || MIT || https://github.com/nning/david
|-
| coap-rs || Rust || Client + Server || MIT || https://github.com/Covertness/coap-rs
|-
| Copper || JavaScript (Browser Plugin) || Client || BSD || https://github.com/mkovatsc/Copper
|-
| iCoAP || Objective-C || Client || MIT || https://github.com/stuffrabbit/iCoAP
|-
| SwiftCoAP || Swift || Client + Server || MIT || https://github.com/stuffrabbit/SwiftCoAP
|-
| nCoap || Java || Client + Server || BSD || https://github.com/okleine/nCoAP
|-
| txThings || Python (Twisted) || Client + Server || MIT || https://github.com/mwasilak/txThings
|}

== Courses ==

* [[Vertiefendes Wahlfach-Projekt]] (2018)
* [[CoAP Chat Application for RIOT OS]]

== References ==
* RFC 7252: https://tools.ietf.org/html/rfc7252
* RFC 2616: https://www.ietf.org/rfc/rfc2616.txt
* CoAP: RFC 7252 Constrained Application Protocol https://coap.technology/
* Learning Internet of Things: https://www.oreilly.com/library/view/learning-internet-of/9781783553532/

[[Category:Basic]]

Constrained Application Protocol

2019-04-09T14:17:03Z

Awolfsbauer:

The '''Constrained Application Protocol''' ('''CoAP''') is a specialized web transfer protocol, as defined in RFC 7252, for use with constrained nodes and constrained networks in the Internet of Things.
The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation.

== Features ==

The work on Constrained Environments aims at realizing the REST architecture in a suitable form for the most constrained nodes and networks. The nodes usually consist of 8-bit microcontrollers with limited amounts of RAM and ROM.

CoAP has the following main features:

* Web protocol fulfilling M2M requirements in constrained environments
* UDP [RFC0768] binding with optional reliability supporting unicast and multicast requests
* Asynchronous message exchanges
* Low header overhead and parsing complexity
* URI and Content-type support
* Simple proxy and caching capabilities
* Stateless HTTP mapping
* Security binding to Datagram Transport Layer Security (DTLS)

== The Protocol ==

CoAP is similar to the client/server model of HTTP. M2M interactions typically result in a CoAP implementation acting in both client and server roles. A request is sent by a client to request an action on a resource (identified by a URI) on a server. The server then sends a response with a response code (equivalent to that of HTTP). Therefore, efficiency is very important, so CoAP uses UDP, a datagram-oriented transport.

CoAP is however a single protocol, with messaging and request/response as just features of the CoAP header

+----------------------+
| Application |
+----------------------+
+----------------------+ \
| Requests/Responses | |
|----------------------| | CoAP
| Messages | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+

== Message Format ==

By default, the messages are encoded in a simple binary format and transported over UDP. The message format starts with a fixed-size 4-byte header, followed by a variable-length Token value, which can be between 0 and 8 bytes long. Following the Token value comes a sequence of zero or more CoAP Options in Type-Length-Value (TLV) format, optionally followed by a payload that takes up the rest of the datagram.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

;Version (Ver) (2 bits)
:Indicates the CoAP Version number. This must set this field to 1 (binary 01). Other values are reserved for future versions.

;Type (T) (2 bits)
:Indicates if this message is of type Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3).

;Token Length (TKL) (4 bits)
:Indicates the length of the variable-length Token field, which may be 0-8 bytes in length.

;CoAP Request/Response Code (8 bits)
:Splits into a 3-bit class and 5-bit detail.

;Message ID (16 bits)
:Used to detect message duplication and to match messages of type Acknowledgement/Reset to messages of type Confirmable/Non-confirmable.

== Security Considerations ==

This section list some possible threats to the protocol. As CoAP realizes a subset of the features of HTTP/1.1, the security considerations in section 15 of RFC2616 are also pertinent to CoAP.

Note:"NoSec" mode means that the system simply sends packets over normal UDP over IP and is indicated by the "coap" scheme and the CoAP default port. The system is secured only by keeping attackers from being able to send or receive packets from the network with the CoAP nodes. There is no protocol-level security (DTLS is disabled).

;Parsing the Protocol and Processing URI's

The URI processing code in CoAP is likely to be a large source of vulnerabilities and should be implemented very carefully. Vulnerabilities include remotely crashing a node and remotely executing arbitrary code. CoAP aims to reduce the risk of these vulnerabilities by reducing parser complexity and moving much of the URI processing to the clients.

;Proxying and Caching

Proxies are man-in-the-middle by their nature. They can break any IPsec or DTLS protection that would otherwise happen between direct CoAP message exchange. Risks include the loss of confidentiality and availability. If the proxies also cache the threat to confidentiality and integrity of request/response data is amplified as CoAP does not implement cache-suppressing Cache-control as in HTTP/1.1.
For caching implementations any access control considerations also need to be applied to the value in the cache. A caching proxy must not make cache values available to requests that have lesser transport-security properties.

;Risk of Amplification

As CoAP server reply to request packets with response packets that may be significantly larger an attacker can use CoAP nodes to generate more traffic and use them in a denial-of-service(DoS) attack. Turning a small attack packet into a larger one is called amplification. The attacker wants to overload a victim but is limited in the amount of traffic can use amplification to generate larger amounts. If a node that enables NoSec access becomes available to an attacker it can access victims on the general internet. UDP provides no way to verify the source address given in the request packet and an attacker can place the IP of the victim in the source address of a request packet to generate a larger packet directed at the victim. The risk is reduced however as constrained networks are only able to generate small amounts of traffic. In contrast the network itself with its limited capacity is a viable victim of an amplification attack. Large amplification factors should not be provided if the request is not authenticated. Also the slicing/blocking modes of CoAP [BLOCK] should be used for large resources. Because CoAP supports the use of multicast IP addresses in requests, CoAP servers should not accept multicast requests that can not be authenticated. Servers should limit the use of multicast requests as they can be a source of an accidental or deliberate DoS attack.

;IP Address Spoofing

As there is no handshake in UDP a rogue endpoint that can read and write messages can attack a single endpoint, a group of endpoints or the whole network.

#Spoofing a Reset message in response to a message making an endpoint "deaf"
#Spoofing an ACK in response to a CON, preventing the sender of the CON from retransmitting to drown out the actual response
#Spoofing the entire response with forged payload/options, attacking a single endpoint or the supporting infrastructure
#Spoofing a multicast request for a target node resulting in network congestion or collapse due to a DoS attack on the victim, or forced wake-up from sleeping
#Spoofing observe messages

Response spoofing can be mitigated by choosing a nontrivial, randomized token in the request. Other kinds of spoofing can only be detected by CoAP if Confirmable message semantics are used and if one keeps track of Message ID's. A client can also attempt to overload a server by sending complex requests as the cost of a CON request is small. This can be used in a battery depletion attack or to make the server run out of resources for processing legitimate traffic. All these attacks can be prevented if a security mode other than NoSec is used.

;Cross-Protocol Attacks

In general, for any pair of protocols, one could have been designed in a way, that enables an attacker to cause the generation of replies that look like messages of the other protocol. Because a CoAP endpoint can be manipulated to send packets to a fake source address it can be used to attack a victim listening to UDP packets at a given IP address and port.

#The attacker sends a message to a CoAP endpoint with the given address as the fake source address.
#The endpoint replies with a message to the source address.
#The victim receives a UDP packet that it interprets according to the rules of a different protocol.

This can be used to circumvent firewall rules that prevent direct communication but allow communication from the CoAP endpoint. This scenario can work the other way too. A CoAP endpoint could be attacked from another UDP-based protocol. Attacks are possible if the endpoints rely only on checking IP addresses. To prevent these kinds of attacks strict checking of syntax of packets received should be implemented. Furthermore endpoints should not authorize actions based on trusting the source IP address of a packet.

;Constrained Node Considerations

Keys should be generated externally and added to the device during manufacturing or commissioning. Due to low processing power constrained nodes are susceptible to timing attacks. Cryptographic principles should be implemented with special care as many nodes are installed in exposed environments and have little resistance to tampering. The scope of credentials assigned to them should be considered carefully. A shared key assigned to a group of nodes may make any single node a target for subverting the entire group.

== Implementations ==

Generic implementations are becoming available for a variety of platforms. Implementations for constrained devices are typically written in C. CoAP is also used between them and more powerful systems such as cloud servers, home centrals, smartphones:

{| class="wikitable sortable"
|-
! Name !! Programming Language !! Client/Server !! License !! Link
|-
| Erbium for Contiki || C || Client + Server || 3-clause BSD || http://www.contiki-os.org/
|-
| libcoap || C || Client + Server || BSD/GPL || https://libcoap.net/
|-
| Eclipse tinydtls || C || Client + Server || EPL+EDL || https://projects.eclipse.org/projects/iot.tinydtls
|-
| LibNyoci || C || Client + Server || MIT || https://github.com/darconeous/libnyoci
|-
| microcoap || C || Client + Server || MIT || https://github.com/1248/microcoap
|-
| cantcoap || C++/C || Client + Server || BSD || https://github.com/staropram/cantcoap
|-
| Lobaro CoAP || C || Client + Server || MIT || https://www.lobaro.com/portfolio/lobaro-coap/
|-
| MR-CoAP || Java || || BSD || https://github.com/MR-CoAP/CoAP
|-
| Wakaama || C || Client + Server || EPL+EDL || https://www.eclipse.org/wakaama/index.html
|-
| coap-node || Javascript || Client || MIT || https://github.com/PeterEB/coap-node
|-
| coap-shepherd || Javascript || Server || MIT || https://github.com/PeterEB/coap-shepherd
|-
| Californium || Java || Client + Server || EPL+EDL || https://www.eclipse.org/californium
|-
| nCoap || Java || Client + Server || BSD || https://github.com/okleine/nCoAP
|-
| leshan || Java || Client + Server || EPL+EDL || https://github.com/eclipse/leshan
|-
| CoAP.NET || C# || Client + Server || 3-clause BSD || https://github.com/smeshlink/CoAP.NET
|-
| CoAPSharp || C#, .NET || Client + Server || LGPL || http://www.coapsharp.com
|-
| Waher.Networking.CoAP || C# || Server || || https://github.com/PeterWaher/IoTGateway
|-
| gen_coap || Erlang || Client + Server || MPL v1.1 || https://github.com/gotthardp/gen_coap
|-
| go-coap || Go || Client + Server || MIT || https://github.com/go-ocf/go-coap
|-
| node-coap || Javascript || Client + Server || MIT || https://github.com/mcollina/node-coap
|-
| coap-cli || Javascript || || MIT || https://github.com/mcollina/coap-cli
|-
| txThings || Python (Twisted) || Client + Server || MIT || https://github.com/mwasilak/txThings
|-
| aiocoap || Python 3 || Client + Server || MIT || https://github.com/chrysn/aiocoap
|-
| CoAPthon || Python || Client + Server || MIT || https://github.com/Tanganelli/CoAPthon
|-
| Ruby coap || Ruby || Client || MIT || https://github.com/nning/coap
|-
| Ruby david || Ruby || Server || MIT || https://github.com/nning/david
|-
| coap-rs || Rust || Client + Server || MIT || https://github.com/Covertness/coap-rs
|-
| Copper || JavaScript (Browser Plugin) || Client || BSD || https://github.com/mkovatsc/Copper
|-
| iCoAP || Objective-C || Client || MIT || https://github.com/stuffrabbit/iCoAP
|-
| SwiftCoAP || Swift || Client + Server || MIT || https://github.com/stuffrabbit/SwiftCoAP
|-
| nCoap || Java || Client + Server || BSD || https://github.com/okleine/nCoAP
|-
| txThings || Python (Twisted) || Client + Server || MIT || https://github.com/mwasilak/txThings
|}

== Courses ==

* [[Vertiefendes Wahlfach-Projekt]] (2018)
* [[CoAP Chat Application for RIOT OS]]

== References ==
* RFC 7252: https://tools.ietf.org/html/rfc7252
* RFC 2616: https://www.ietf.org/rfc/rfc2616.txt
* CoAP: RFC 7252 Constrained Application Protocol https://coap.technology/
* Learning Internet of Things: https://www.oreilly.com/library/view/learning-internet-of/9781783553532/

[[Category:Basic]]

Constrained Application Protocol

2019-04-09T14:07:10Z

Awolfsbauer:

The '''Constrained Application Protocol''' ('''CoAP''') is a specialized web transfer protocol, as defined in RFC 7252, for use with constrained nodes and constrained networks in the Internet of Things.
The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation.

== Features ==

The work on Constrained Environments aims at realizing the REST architecture in a suitable form for the most constrained nodes and networks. The nodes usually consist of 8-bit microcontrollers with limited amounts of RAM and ROM.

CoAP has the following main features:

* Web protocol fulfilling M2M requirements in constrained environments
* UDP [RFC0768] binding with optional reliability supporting unicast and multicast requests
* Asynchronous message exchanges
* Low header overhead and parsing complexity
* URI and Content-type support
* Simple proxy and caching capabilities
* Stateless HTTP mapping
* Security binding to Datagram Transport Layer Security (DTLS)

== The Protocol ==

CoAP is similar to the client/server model of HTTP. M2M interactions typically result in a CoAP implementation acting in both client and server roles. A request is sent by a client to request an action on a resource (identified by a URI) on a server. The server then sends a response with a response code (equivalent to that of HTTP). Therefore, efficiency is very important, so CoAP uses UDP, a datagram-oriented transport.

CoAP is however a single protocol, with messaging and request/response as just features of the CoAP header

+----------------------+
| Application |
+----------------------+
+----------------------+ \
| Requests/Responses | |
|----------------------| | CoAP
| Messages | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+

== Message Format ==

By default, the messages are encoded in a simple binary format and transported over UDP. The message format starts with a fixed-size 4-byte header, followed by a variable-length Token value, which can be between 0 and 8 bytes long. Following the Token value comes a sequence of zero or more CoAP Options in Type-Length-Value (TLV) format, optionally followed by a payload that takes up the rest of the datagram.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

;Version (Ver) (2 bits)
:Indicates the CoAP Version number. This must set this field to 1 (binary 01). Other values are reserved for future versions.

;Type (T) (2 bits)
:Indicates if this message is of type Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3).

;Token Length (TKL) (4 bits)
:Indicates the length of the variable-length Token field, which may be 0-8 bytes in length.

;CoAP Request/Response Code (8 bits)
:Splits into a 3-bit class and 5-bit detail.

;Message ID (16 bits)
:Used to detect message duplication and to match messages of type Acknowledgement/Reset to messages of type Confirmable/Non-confirmable.

== Security Considerations ==

This section list some possible threats to the protocol. As CoAP realizes a subset of the features of HTTP/1.1, the security considerations in section 15 of RFC2616 are also pertinent to CoAP.

Note:"NoSec" mode means that the system simply sends packets over normal UDP over IP and is indicated by the "coap" scheme and the CoAP default port. The system is secured only by keeping attackers from being able to send or receive packets from the network with the CoAP nodes. There is no protocol-level security (DTLS is disabled).

;Parsing the Protocol and Processing URI's

The URI processing code in CoAP is likely to be a large source of vulnerabilities and should be implemented very carefully. Vulnerabilities include remotely crashing a node and remotely executing arbitrary code. CoAP aims to reduce the risk of these vulnerabilities by reducing parser complexity and moving much of the URI processing to the clients.

;Proxying and Caching

Proxies are man-in-the-middle by their nature. They can break any IPsec or DTLS protection that would otherwise happen between direct CoAP message exchange. Risks include the loss of confidentiality and availability. If the proxies also cache the threat to confidentiality and integrity of request/response data is amplified as CoAP does not implement cache-suppressing Cache-control as in HTTP/1.1.
For caching implementations any access control considerations also need to be applied to the value in the cache. A caching proxy must not make cache values available to requests that have lesser transport-security properties.

;Risk of Amplification

As CoAP server reply to request packets with response packets that may be significantly larger an attacker can use CoAP nodes to generate more traffic and use them in a denial-of-service(DoS) attack. Turning a small attack packet into a larger one is called amplification. The attacker wants to overload a victim but is limited in the amount of traffic can use amplification to generate larger amounts. If a node that enables NoSec access becomes available to an attacker it can access victims on the general internet. UDP provides no way to verify the source address given in the request packet and an attacker can place the IP of the victim in the source address of a request packet to generate a larger packet directed at the victim. The risk is reduced however as constrained networks are only able to generate small amounts of traffic. In contrast the network itself with its limited capacity is a viable victim of an amplification attack. Large amplification factors should not be provided if the request is not authenticated. Also the slicing/blocking modes of CoAP [BLOCK] should be used for large resources. Because CoAP supports the use of multicast IP addresses in requests, CoAP servers should not accept multicast requests that can not be authenticated. Servers should limit the use of multicast requests as they can be a source of an accidental or deliberate DoS attack.

;IP Address Spoofing

As there is no handshake in UDP a rogue endpoint that can read and write messages can attack a single endpoint, a group of endpoints or the whole network.

#Spoofing a Reset message in response to a message making an endpoint "deaf"
#Spoofing an ACK in response to a CON, preventing the sender of the CON from retransmitting to drown out the actual response
#Spoofing the entire response with forged payload/options, attacking a single endpoint or the supporting infrastructure
#Spoofing a multicast request for a target node resulting in network congestion or collapse due to a DoS attack on the victim, or forced wake-up from sleeping
#Spoofing observe messages

Response spoofing can be mitigated by choosing a nontrivial, randomized token in the request. Other kinds of spoofing can only be detected by CoAP if Confirmable message semantics are used and if one keeps track of Message ID's. A client can also attempt to overload a server by sending complex requests as the cost of a CON request is small. This can be used in a battery depletion attack or to make the server run out of resources for processing legitimate traffic. All these attacks can be prevented if a security mode other than NoSec is used.

;Cross-Protocol Attacks

Because a CoAP endpoint can be manipulated to send packets to a fake source address it can be used to attack a victim listening to UDP packets at a given IP address and port.

#The attacker sends a message to a CoAP endpoint with the given address as the fake source address.
#The endpoint replies with a message to the source address.
#The victim receives a UDP packet that it interprets according to the rules of a different protocol.

;Constrained Node Considerations

Keys should be generated externally and added to the device during manufacturing or commissioning. Due to low processing power constrained nodes are susceptible to timing attacks. Cryptographic principles should be implemented with special care as many nodes are installed in exposed environments and have little resistance to tampering. The scope of credentials assigned to them should be considered carefully. A shared key assigned to a group of nodes may make any single node a target for subverting the entire group.

== Implementations ==

Generic implementations are becoming available for a variety of platforms. Implementations for constrained devices are typically written in C. CoAP is also used between them and more powerful systems such as cloud servers, home centrals, smartphones:

{| class="wikitable sortable"
|-
! Name !! Programming Language !! Client/Server !! License !! Link
|-
| Erbium for Contiki || C || Client + Server || 3-clause BSD || http://www.contiki-os.org/
|-
| libcoap || C || Client + Server || BSD/GPL || https://libcoap.net/
|-
| Eclipse tinydtls || C || Client + Server || EPL+EDL || https://projects.eclipse.org/projects/iot.tinydtls
|-
| LibNyoci || C || Client + Server || MIT || https://github.com/darconeous/libnyoci
|-
| microcoap || C || Client + Server || MIT || https://github.com/1248/microcoap
|-
| cantcoap || C++/C || Client + Server || BSD || https://github.com/staropram/cantcoap
|-
| Lobaro CoAP || C || Client + Server || MIT || https://www.lobaro.com/portfolio/lobaro-coap/
|-
| MR-CoAP || Java || || BSD || https://github.com/MR-CoAP/CoAP
|-
| Wakaama || C || Client + Server || EPL+EDL || https://www.eclipse.org/wakaama/index.html
|-
| coap-node || Javascript || Client || MIT || https://github.com/PeterEB/coap-node
|-
| coap-shepherd || Javascript || Server || MIT || https://github.com/PeterEB/coap-shepherd
|-
| Californium || Java || Client + Server || EPL+EDL || https://www.eclipse.org/californium
|-
| nCoap || Java || Client + Server || BSD || https://github.com/okleine/nCoAP
|-
| leshan || Java || Client + Server || EPL+EDL || https://github.com/eclipse/leshan
|-
| CoAP.NET || C# || Client + Server || 3-clause BSD || https://github.com/smeshlink/CoAP.NET
|-
| CoAPSharp || C#, .NET || Client + Server || LGPL || http://www.coapsharp.com
|-
| Waher.Networking.CoAP || C# || Server || || https://github.com/PeterWaher/IoTGateway
|-
| gen_coap || Erlang || Client + Server || MPL v1.1 || https://github.com/gotthardp/gen_coap
|-
| go-coap || Go || Client + Server || MIT || https://github.com/go-ocf/go-coap
|-
| node-coap || Javascript || Client + Server || MIT || https://github.com/mcollina/node-coap
|-
| coap-cli || Javascript || || MIT || https://github.com/mcollina/coap-cli
|-
| txThings || Python (Twisted) || Client + Server || MIT || https://github.com/mwasilak/txThings
|-
| aiocoap || Python 3 || Client + Server || MIT || https://github.com/chrysn/aiocoap
|-
| CoAPthon || Python || Client + Server || MIT || https://github.com/Tanganelli/CoAPthon
|-
| Ruby coap || Ruby || Client || MIT || https://github.com/nning/coap
|-
| Ruby david || Ruby || Server || MIT || https://github.com/nning/david
|-
| coap-rs || Rust || Client + Server || MIT || https://github.com/Covertness/coap-rs
|-
| Copper || JavaScript (Browser Plugin) || Client || BSD || https://github.com/mkovatsc/Copper
|-
| iCoAP || Objective-C || Client || MIT || https://github.com/stuffrabbit/iCoAP
|-
| SwiftCoAP || Swift || Client + Server || MIT || https://github.com/stuffrabbit/SwiftCoAP
|-
| nCoap || Java || Client + Server || BSD || https://github.com/okleine/nCoAP
|-
| txThings || Python (Twisted) || Client + Server || MIT || https://github.com/mwasilak/txThings
|}

== Courses ==

* [[Vertiefendes Wahlfach-Projekt]] (2018)
* [[CoAP Chat Application for RIOT OS]]

== References ==
* RFC 7252: https://tools.ietf.org/html/rfc7252
* RFC 2616: https://www.ietf.org/rfc/rfc2616.txt
* CoAP: RFC 7252 Constrained Application Protocol https://coap.technology/
* Learning Internet of Things: https://www.oreilly.com/library/view/learning-internet-of/9781783553532/

[[Category:Basic]]

Constrained Application Protocol

2019-04-09T13:52:22Z

Awolfsbauer:

The '''Constrained Application Protocol''' ('''CoAP''') is a specialized web transfer protocol, as defined in RFC 7252, for use with constrained nodes and constrained networks in the Internet of Things.
The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation.

== Features ==

The work on Constrained Environments aims at realizing the REST architecture in a suitable form for the most constrained nodes and networks. The nodes usually consist of 8-bit microcontrollers with limited amounts of RAM and ROM.

CoAP has the following main features:

* Web protocol fulfilling M2M requirements in constrained environments
* UDP [RFC0768] binding with optional reliability supporting unicast and multicast requests
* Asynchronous message exchanges
* Low header overhead and parsing complexity
* URI and Content-type support
* Simple proxy and caching capabilities
* Stateless HTTP mapping
* Security binding to Datagram Transport Layer Security (DTLS)

== The Protocol ==

CoAP is similar to the client/server model of HTTP. M2M interactions typically result in a CoAP implementation acting in both client and server roles. A request is sent by a client to request an action on a resource (identified by a URI) on a server. The server then sends a response with a response code (equivalent to that of HTTP). Therefore, efficiency is very important, so CoAP uses UDP, a datagram-oriented transport.

CoAP is however a single protocol, with messaging and request/response as just features of the CoAP header

+----------------------+
| Application |
+----------------------+
+----------------------+ \
| Requests/Responses | |
|----------------------| | CoAP
| Messages | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+

== Message Format ==

By default, the messages are encoded in a simple binary format and transported over UDP. The message format starts with a fixed-size 4-byte header, followed by a variable-length Token value, which can be between 0 and 8 bytes long. Following the Token value comes a sequence of zero or more CoAP Options in Type-Length-Value (TLV) format, optionally followed by a payload that takes up the rest of the datagram.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

;Version (Ver) (2 bits)
:Indicates the CoAP Version number. This must set this field to 1 (binary 01). Other values are reserved for future versions.

;Type (T) (2 bits)
:Indicates if this message is of type Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3).

;Token Length (TKL) (4 bits)
:Indicates the length of the variable-length Token field, which may be 0-8 bytes in length.

;CoAP Request/Response Code (8 bits)
:Splits into a 3-bit class and 5-bit detail.

;Message ID (16 bits)
:Used to detect message duplication and to match messages of type Acknowledgement/Reset to messages of type Confirmable/Non-confirmable.

== Security Considerations ==

This section list some possible threats to the protocol. As CoAP realizes a subset of the features of HTTP/1.1, the security considerations in section 15 of RFC2616 are also pertinent to CoAP.

;Parsing the Protocol and Processing URI's

The URI processing code in CoAP is likely to be a large source of vulnerabilities and should be implemented very carefully. Vulnerabilities include remotely crashing a node and remotely executing arbitrary code. CoAP aims to reduce the risk of these vulnerabilities by reducing parser complexity and moving much of the URI processing to the clients.

;Proxying and Caching

Proxies are man-in-the-middle by their nature. They can break any IPsec or DTLS protection that would otherwise happen between direct CoAP message exchange. Risks include the loss of confidentiality and availability. If the proxies also cache the threat to confidentiality and integrity of request/response data is amplified as CoAP does not implement cache-suppressing Cache-control as in HTTP/1.1.
For caching implementations any access control considerations also need to be applied to the value in the cache. A caching proxy must not make cache values available to requests that have lesser transport-security properties.

;Risk of Amplification

As CoAP server reply to request packets with response packets that may be significantly larger an attacker can use CoAP nodes to generate more traffic and use them in a denial-of-service(DoS) attack. Turning a small attack packet into a larger one is called amplification. The attacker wants to overload a victim but is limited in the amount of traffic can use amplification to generate larger amounts. If a node that enables NoSec access becomes available to an attacker it can access victims on the general internet. UDP provides no way to verify the source address given in the request packet and an attacker can place the IP of the victim in the source address of a request packet to generate a larger packet directed at the victim. The risk is reduced however as constrained networks are only able to generate small amounts of traffic. In contrast the network itself with its limited capacity is a viable victim of an amplification attack. Large amplification factors should not be provided if the request is not authenticated. Also the slicing/blocking modes of CoAP [BLOCK] should be used for large resources. Because CoAP supports the use of multicast IP addresses in requests, CoAP servers should not accept multicast requests that can not be authenticated. Servers should limit the use of multicast requests as they can be a source of an accidental or deliberate DoS attack.

;IP Address Spoofing

As there is no handshake in UDP a rogue endpoint that can read and write messages can attack a single endpoint, a group of endpoints or the whole network.

#Spoofing a Reset message in response to a message making an endpoint "deaf"
#Spoofing an ACK in response to a CON, preventing the sender of the CON from retransmitting to drown out the actual response
#Spoofing the entire response with forged payload/options, attacking a single endpoint or the supporting infrastructure
#Spoofing a multicast request for a target node resulting in network congestion or collapse due to a DoS attack on the victim, or forced wake-up from sleeping
#Spoofing observe messages

Response spoofing can be mitigated by choosing a nontrivial, randomized token in the request. Other kinds of spoofing can only be detected by CoAP if Confirmable message semantics are used and if one keeps track of Message ID's. A client can also attempt to overload a server by sending complex requests as the cost of a CON request is small. This can be used in a battery depletion attack or to make the server run out of resources for processing legitimate traffic. All these attacks can be prevented if a security mode other than NoSec is used.

;Cross-Protocol Attacks

;Constrained Node Considerations

Keys should be generated externally and added to the device during manufacturing or commissioning. Due to low processing power constrained nodes are susceptible to timing attacks. Cryptographic principles should be implemented with special care as many nodes are installed in exposed environments and have little resistance to tampering. The scope of credentials assigned to them should be considered carefully. A shared key assigned to a group of nodes may make any single node a target for subverting the entire group.

== Implementations ==

Generic implementations are becoming available for a variety of platforms. Implementations for constrained devices are typically written in C. CoAP is also used between them and more powerful systems such as cloud servers, home centrals, smartphones:

{| class="wikitable sortable"
|-
! Name !! Programming Language !! Client/Server !! License !! Link
|-
| Erbium for Contiki || C || Client + Server || 3-clause BSD || http://www.contiki-os.org/
|-
| libcoap || C || Client + Server || BSD/GPL || https://libcoap.net/
|-
| Eclipse tinydtls || C || Client + Server || EPL+EDL || https://projects.eclipse.org/projects/iot.tinydtls
|-
| LibNyoci || C || Client + Server || MIT || https://github.com/darconeous/libnyoci
|-
| microcoap || C || Client + Server || MIT || https://github.com/1248/microcoap
|-
| cantcoap || C++/C || Client + Server || BSD || https://github.com/staropram/cantcoap
|-
| Lobaro CoAP || C || Client + Server || MIT || https://www.lobaro.com/portfolio/lobaro-coap/
|-
| MR-CoAP || Java || || BSD || https://github.com/MR-CoAP/CoAP
|-
| Wakaama || C || Client + Server || EPL+EDL || https://www.eclipse.org/wakaama/index.html
|-
| coap-node || Javascript || Client || MIT || https://github.com/PeterEB/coap-node
|-
| coap-shepherd || Javascript || Server || MIT || https://github.com/PeterEB/coap-shepherd
|-
| Californium || Java || Client + Server || EPL+EDL || https://www.eclipse.org/californium
|-
| nCoap || Java || Client + Server || BSD || https://github.com/okleine/nCoAP
|-
| leshan || Java || Client + Server || EPL+EDL || https://github.com/eclipse/leshan
|-
| CoAP.NET || C# || Client + Server || 3-clause BSD || https://github.com/smeshlink/CoAP.NET
|-
| CoAPSharp || C#, .NET || Client + Server || LGPL || http://www.coapsharp.com
|-
| Waher.Networking.CoAP || C# || Server || || https://github.com/PeterWaher/IoTGateway
|-
| gen_coap || Erlang || Client + Server || MPL v1.1 || https://github.com/gotthardp/gen_coap
|-
| go-coap || Go || Client + Server || MIT || https://github.com/go-ocf/go-coap
|-
| node-coap || Javascript || Client + Server || MIT || https://github.com/mcollina/node-coap
|-
| coap-cli || Javascript || || MIT || https://github.com/mcollina/coap-cli
|-
| txThings || Python (Twisted) || Client + Server || MIT || https://github.com/mwasilak/txThings
|-
| aiocoap || Python 3 || Client + Server || MIT || https://github.com/chrysn/aiocoap
|-
| CoAPthon || Python || Client + Server || MIT || https://github.com/Tanganelli/CoAPthon
|-
| Ruby coap || Ruby || Client || MIT || https://github.com/nning/coap
|-
| Ruby david || Ruby || Server || MIT || https://github.com/nning/david
|-
| coap-rs || Rust || Client + Server || MIT || https://github.com/Covertness/coap-rs
|-
| Copper || JavaScript (Browser Plugin) || Client || BSD || https://github.com/mkovatsc/Copper
|-
| iCoAP || Objective-C || Client || MIT || https://github.com/stuffrabbit/iCoAP
|-
| SwiftCoAP || Swift || Client + Server || MIT || https://github.com/stuffrabbit/SwiftCoAP
|-
| nCoap || Java || Client + Server || BSD || https://github.com/okleine/nCoAP
|-
| txThings || Python (Twisted) || Client + Server || MIT || https://github.com/mwasilak/txThings
|}

== Courses ==

* [[Vertiefendes Wahlfach-Projekt]] (2018)
* [[CoAP Chat Application for RIOT OS]]

== References ==
* RFC 7252: https://tools.ietf.org/html/rfc7252
* RFC 2616: https://www.ietf.org/rfc/rfc2616.txt
* CoAP: RFC 7252 Constrained Application Protocol https://coap.technology/
* Learning Internet of Things: https://www.oreilly.com/library/view/learning-internet-of/9781783553532/

[[Category:Basic]]

Constrained Application Protocol

2019-04-09T13:44:45Z

Awolfsbauer:

The '''Constrained Application Protocol''' ('''CoAP''') is a specialized web transfer protocol, as defined in RFC 7252, for use with constrained nodes and constrained networks in the Internet of Things.
The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation.

== Features ==

The work on Constrained Environments aims at realizing the REST architecture in a suitable form for the most constrained nodes and networks. The nodes usually consist of 8-bit microcontrollers with limited amounts of RAM and ROM.

CoAP has the following main features:

* Web protocol fulfilling M2M requirements in constrained environments
* UDP [RFC0768] binding with optional reliability supporting unicast and multicast requests
* Asynchronous message exchanges
* Low header overhead and parsing complexity
* URI and Content-type support
* Simple proxy and caching capabilities
* Stateless HTTP mapping
* Security binding to Datagram Transport Layer Security (DTLS)

== The Protocol ==

CoAP is similar to the client/server model of HTTP. M2M interactions typically result in a CoAP implementation acting in both client and server roles. A request is sent by a client to request an action on a resource (identified by a URI) on a server. The server then sends a response with a response code (equivalent to that of HTTP). Therefore, efficiency is very important, so CoAP uses UDP, a datagram-oriented transport.

CoAP is however a single protocol, with messaging and request/response as just features of the CoAP header

+----------------------+
| Application |
+----------------------+
+----------------------+ \
| Requests/Responses | |
|----------------------| | CoAP
| Messages | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+

== Message Format ==

By default, the messages are encoded in a simple binary format and transported over UDP. The message format starts with a fixed-size 4-byte header, followed by a variable-length Token value, which can be between 0 and 8 bytes long. Following the Token value comes a sequence of zero or more CoAP Options in Type-Length-Value (TLV) format, optionally followed by a payload that takes up the rest of the datagram.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

;Version (Ver) (2 bits)
:Indicates the CoAP Version number. This must set this field to 1 (binary 01). Other values are reserved for future versions.

;Type (T) (2 bits)
:Indicates if this message is of type Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3).

;Token Length (TKL) (4 bits)
:Indicates the length of the variable-length Token field, which may be 0-8 bytes in length.

;CoAP Request/Response Code (8 bits)
:Splits into a 3-bit class and 5-bit detail.

;Message ID (16 bits)
:Used to detect message duplication and to match messages of type Acknowledgement/Reset to messages of type Confirmable/Non-confirmable.

== Security Considerations ==

This section list some possible threats to the protocol. As CoAP realizes a subset of the features of HTTP/1.1, the security considerations in section 15 of RFC2616 are also pertinent to CoAP.

;Parsing the Protocol and Processing URI's

The URI processing code in CoAP is likely to be a large source of vulnerabilities and should be implemented very carefully. Vulnerabilities include remotely crashing a node and remotely executing arbitrary code. CoAP aims to reduce the risk of these vulnerabilities by reducing parser complexity and moving much of the URI processing to the clients.

;Proxying and Caching

Proxies are man-in-the-middle by their nature. They can break any IPsec or DTLS protection that would otherwise happen between direct CoAP message exchange. Risks include the loss of confidentiality and availability. If the proxies also cache the threat to confidentiality and integrity of request/response data is amplified as CoAP does not implement cache-suppressing Cache-control as in HTTP/1.1.
For caching implementations any access control considerations also need to be applied to the value in the cache. A caching proxy must not make cache values available to requests that have lesser transport-security properties.

;Risk of Amplification

As CoAP server reply to request packets with response packets that may be significantly larger an attacker can use CoAP nodes to generate more traffic and use them in a denial-of-service(DoS) attack. Turning a small attack packet into a larger one is called amplification. The attacker wants to overload a victim but is limited in the amount of traffic can use amplification to generate larger amounts. If a node that enables NoSec access becomes available to an attacker it can access victims on the general internet. UDP provides no way to verify the source address given in the request packet and an attacker can place the IP of the victim in the source address of a request packet to generate a larger packet directed at the victim. The risk is reduced however as constrained networks are only able to generate small amounts of traffic. In contrast the network itself with its limited capacity is a viable victim of an amplification attack. Large amplification factors should not be provided if the request is not authenticated. Also the slicing/blocking modes of CoAP [BLOCK] should be used for large resources. Because CoAP supports the use of multicast IP addresses in requests, CoAP servers should not accept multicast requests that can not be authenticated. Servers should limit the use of multicast requests as they can be a source of an accidental or deliberate DoS attack.

;IP Address Spoofing

As there is no handshake in UDP a rogue endpoint that can read and write messages can attack a single endpoint, a group of endpoints or the whole network.

Response spoofing can be mitigated by choosing a nontrivial, randomized token in the request. Other kinds of spoofing can only be detected by CoAP if Confirmable message semantics are used and if one keeps track of Message ID's. A client can also attempt to overload a server by sending complex requests as the cost of a CON request is small. This can be used in a battery depletion attack or to make the server run out of resources for processing legitimate traffic. All these attacks can be prevented if a security mode other than NoSec is used.

;Cross-Protocol Attacks

;Constrained Node Considerations

Keys should be generated externally and added to the device during manufacturing or commissioning. Due to low processing power constrained nodes are susceptible to timing attacks. Cryptographic principles should be implemented with special care as many nodes are installed in exposed environments and have little resistance to tampering. The scope of credentials assigned to them should be considered carefully. A shared key assigned to a group of nodes may make any single node a target for subverting the entire group.

== Implementations ==

Generic implementations are becoming available for a variety of platforms. Implementations for constrained devices are typically written in C. CoAP is also used between them and more powerful systems such as cloud servers, home centrals, smartphones:

{| class="wikitable sortable"
|-
! Name !! Programming Language !! Client/Server !! License !! Link
|-
| Erbium for Contiki || C || Client + Server || 3-clause BSD || http://www.contiki-os.org/
|-
| libcoap || C || Client + Server || BSD/GPL || https://libcoap.net/
|-
| Eclipse tinydtls || C || Client + Server || EPL+EDL || https://projects.eclipse.org/projects/iot.tinydtls
|-
| LibNyoci || C || Client + Server || MIT || https://github.com/darconeous/libnyoci
|-
| microcoap || C || Client + Server || MIT || https://github.com/1248/microcoap
|-
| cantcoap || C++/C || Client + Server || BSD || https://github.com/staropram/cantcoap
|-
| Lobaro CoAP || C || Client + Server || MIT || https://www.lobaro.com/portfolio/lobaro-coap/
|-
| MR-CoAP || Java || || BSD || https://github.com/MR-CoAP/CoAP
|-
| Wakaama || C || Client + Server || EPL+EDL || https://www.eclipse.org/wakaama/index.html
|-
| coap-node || Javascript || Client || MIT || https://github.com/PeterEB/coap-node
|-
| coap-shepherd || Javascript || Server || MIT || https://github.com/PeterEB/coap-shepherd
|-
| Californium || Java || Client + Server || EPL+EDL || https://www.eclipse.org/californium
|-
| nCoap || Java || Client + Server || BSD || https://github.com/okleine/nCoAP
|-
| leshan || Java || Client + Server || EPL+EDL || https://github.com/eclipse/leshan
|-
| CoAP.NET || C# || Client + Server || 3-clause BSD || https://github.com/smeshlink/CoAP.NET
|-
| CoAPSharp || C#, .NET || Client + Server || LGPL || http://www.coapsharp.com
|-
| Waher.Networking.CoAP || C# || Server || || https://github.com/PeterWaher/IoTGateway
|-
| gen_coap || Erlang || Client + Server || MPL v1.1 || https://github.com/gotthardp/gen_coap
|-
| go-coap || Go || Client + Server || MIT || https://github.com/go-ocf/go-coap
|-
| node-coap || Javascript || Client + Server || MIT || https://github.com/mcollina/node-coap
|-
| coap-cli || Javascript || || MIT || https://github.com/mcollina/coap-cli
|-
| txThings || Python (Twisted) || Client + Server || MIT || https://github.com/mwasilak/txThings
|-
| aiocoap || Python 3 || Client + Server || MIT || https://github.com/chrysn/aiocoap
|-
| CoAPthon || Python || Client + Server || MIT || https://github.com/Tanganelli/CoAPthon
|-
| Ruby coap || Ruby || Client || MIT || https://github.com/nning/coap
|-
| Ruby david || Ruby || Server || MIT || https://github.com/nning/david
|-
| coap-rs || Rust || Client + Server || MIT || https://github.com/Covertness/coap-rs
|-
| Copper || JavaScript (Browser Plugin) || Client || BSD || https://github.com/mkovatsc/Copper
|-
| iCoAP || Objective-C || Client || MIT || https://github.com/stuffrabbit/iCoAP
|-
| SwiftCoAP || Swift || Client + Server || MIT || https://github.com/stuffrabbit/SwiftCoAP
|-
| nCoap || Java || Client + Server || BSD || https://github.com/okleine/nCoAP
|-
| txThings || Python (Twisted) || Client + Server || MIT || https://github.com/mwasilak/txThings
|}

== Courses ==

* [[Vertiefendes Wahlfach-Projekt]] (2018)
* [[CoAP Chat Application for RIOT OS]]

== References ==
* RFC 7252: https://tools.ietf.org/html/rfc7252
* RFC 2616: https://www.ietf.org/rfc/rfc2616.txt
* CoAP: RFC 7252 Constrained Application Protocol https://coap.technology/
* Learning Internet of Things: https://www.oreilly.com/library/view/learning-internet-of/9781783553532/

[[Category:Basic]]

Constrained Application Protocol

2019-04-01T19:14:34Z

Awolfsbauer:

The '''Constrained Application Protocol''' ('''CoAP''') is a specialized web transfer protocol, as defined in RFC 7252, for use with constrained nodes and constrained networks in the Internet of Things.
The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation.

== Features ==

The work on Constrained Environments aims at realizing the REST architecture in a suitable form for the most constrained nodes and networks. The nodes usually consist of 8-bit microcontrollers with limited amounts of RAM and ROM.

CoAP has the following main features:

* Web protocol fulfilling M2M requirements in constrained environments
* UDP [RFC0768] binding with optional reliability supporting unicast and multicast requests
* Asynchronous message exchanges
* Low header overhead and parsing complexity
* URI and Content-type support
* Simple proxy and caching capabilities
* Stateless HTTP mapping
* Security binding to Datagram Transport Layer Security (DTLS)

== The Protocol ==

CoAP is similar to the client/server model of HTTP. M2M interactions typically result in a CoAP implementation acting in both client and server roles. A request is sent by a client to request an action on a resource (identified by a URI) on a server. The server then sends a response with a response code (equivalent to that of HTTP). Therefore, efficiency is very important, so CoAP uses UDP, a datagram-oriented transport.

CoAP is however a single protocol, with messaging and request/response as just features of the CoAP header

+----------------------+
| Application |
+----------------------+
+----------------------+ \
| Requests/Responses | |
|----------------------| | CoAP
| Messages | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+

== Message Format ==

By default, the messages are encoded in a simple binary format and transported over UDP. The message format starts with a fixed-size 4-byte header, followed by a variable-length Token value, which can be between 0 and 8 bytes long. Following the Token value comes a sequence of zero or more CoAP Options in Type-Length-Value (TLV) format, optionally followed by a payload that takes up the rest of the datagram.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

;Version (Ver) (2 bits)
:Indicates the CoAP Version number. This must set this field to 1 (binary 01). Other values are reserved for future versions.

;Type (T) (2 bits)
:Indicates if this message is of type Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3).

;Token Length (TKL) (4 bits)
:Indicates the length of the variable-length Token field, which may be 0-8 bytes in length.

;CoAP Request/Response Code (8 bits)
:Splits into a 3-bit class and 5-bit detail.

;Message ID (16 bits)
:Used to detect message duplication and to match messages of type Acknowledgement/Reset to messages of type Confirmable/Non-confirmable.

== Security Considerations ==

This section list some possible threats to the protocol. As CoAP realizes a subset of the features of HTTP/1.1, the security considerations in section 15 of RFC2616 are also pertinent to CoAP.

;Parsing the Protocol and Processing URI's

The URI processing code in CoAP is likely to be a large source of vulnerabilities and should be implemented very carefully. Vulnerabilities include remotely crashing a node and remotely executing arbitrary code. CoAP aims to reduce the risk of these vulnerabilities by reducing parser complexity and moving much of the URI processing to the clients.

;Proxying and Caching

Proxies are man-in-the-middle by their nature. They can break any IPsec or DTLS protection that would otherwise happen between direct CoAP message exchange. Risks include the loss of confidentiality and availability. If the proxies also cache the threat to confidentiality and integrity of request/response data is amplified as CoAP does not implement cache-suppressing Cache-control as in HTTP/1.1.
For caching implementations any access control considerations also need to be applied to the value in the cache. A caching proxy must not make cache values available to requests that have lesser transport-security properties.

;Risk of Amplification

As CoAP server reply to request packets with response packets that may be significantly larger an attacker can use CoAP nodes to generate more traffic and use them in a denial-of-service(DoS) attack. Turning a small attack packet into a larger one is called amplification. The attacker wants to overload a victim but is limited in the amount of traffic can use amplification to generate larger amounts. If a node that enables NoSec access becomes available to an attacker it can access victims on the general internet. UDP provides no way to verify the source address given in the request packet and an attacker can place the IP of the victim in the source address of a request packet to generate a larger packet directed at the victim. The risk is reduced however as constrained networks are only able to generate small amounts of traffic. In contrast the network itself with its limited capacity is a viable victim of an amplification attack. Large amplification factors should not be provided if the request is not authenticated. Also the slicing/blocking modes of CoAP [BLOCK] should be used for large resources.

;IP Address Spoofing

;Cross-Protocol Attacks

;Constrained Node Considerations

Keys should be generated externally and added to the device during manufacturing or commissioning. Due to low processing power constrained nodes are susceptible to timing attacks. Cryptographic principles should be implemented with special care as many nodes are installed in exposed environments and have little resistance to tampering. The scope of credentials assigned to them should be considered carefully. A shared key assigned to a group of nodes may make any single node a target for subverting the entire group.

== Implementations ==

Generic implementations are becoming available for a variety of platforms. Implementations for constrained devices are typically written in C. CoAP is also used between them and more powerful systems such as cloud servers, home centrals, smartphones:

{| class="wikitable sortable"
|-
! Name !! Programming Language !! Client/Server !! License !! Link
|-
| Erbium for Contiki || C || Client + Server || 3-clause BSD || http://www.contiki-os.org/
|-
| libcoap || C || Client + Server || BSD/GPL || https://libcoap.net/
|-
| Eclipse tinydtls || C || Client + Server || EPL+EDL || https://projects.eclipse.org/projects/iot.tinydtls
|-
| LibNyoci || C || Client + Server || MIT || https://github.com/darconeous/libnyoci
|-
| microcoap || C || Client + Server || MIT || https://github.com/1248/microcoap
|-
| cantcoap || C++/C || Client + Server || BSD || https://github.com/staropram/cantcoap
|-
| Lobaro CoAP || C || Client + Server || MIT || https://www.lobaro.com/portfolio/lobaro-coap/
|-
| MR-CoAP || Java || || BSD || https://github.com/MR-CoAP/CoAP
|-
| Wakaama || C || Client + Server || EPL+EDL || https://www.eclipse.org/wakaama/index.html
|-
| coap-node || Javascript || Client || MIT || https://github.com/PeterEB/coap-node
|-
| coap-shepherd || Javascript || Server || MIT || https://github.com/PeterEB/coap-shepherd
|-
| Californium || Java || Client + Server || EPL+EDL || https://www.eclipse.org/californium
|-
| nCoap || Java || Client + Server || BSD || https://github.com/okleine/nCoAP
|-
| leshan || Java || Client + Server || EPL+EDL || https://github.com/eclipse/leshan
|-
| CoAP.NET || C# || Client + Server || 3-clause BSD || https://github.com/smeshlink/CoAP.NET
|-
| CoAPSharp || C#, .NET || Client + Server || LGPL || http://www.coapsharp.com
|-
| Waher.Networking.CoAP || C# || Server || || https://github.com/PeterWaher/IoTGateway
|-
| gen_coap || Erlang || Client + Server || MPL v1.1 || https://github.com/gotthardp/gen_coap
|-
| go-coap || Go || Client + Server || MIT || https://github.com/go-ocf/go-coap
|-
| node-coap || Javascript || Client + Server || MIT || https://github.com/mcollina/node-coap
|-
| coap-cli || Javascript || || MIT || https://github.com/mcollina/coap-cli
|-
| txThings || Python (Twisted) || Client + Server || MIT || https://github.com/mwasilak/txThings
|-
| aiocoap || Python 3 || Client + Server || MIT || https://github.com/chrysn/aiocoap
|-
| CoAPthon || Python || Client + Server || MIT || https://github.com/Tanganelli/CoAPthon
|-
| Ruby coap || Ruby || Client || MIT || https://github.com/nning/coap
|-
| Ruby david || Ruby || Server || MIT || https://github.com/nning/david
|-
| coap-rs || Rust || Client + Server || MIT || https://github.com/Covertness/coap-rs
|-
| Copper || JavaScript (Browser Plugin) || Client || BSD || https://github.com/mkovatsc/Copper
|-
| iCoAP || Objective-C || Client || MIT || https://github.com/stuffrabbit/iCoAP
|-
| SwiftCoAP || Swift || Client + Server || MIT || https://github.com/stuffrabbit/SwiftCoAP
|-
| nCoap || Java || Client + Server || BSD || https://github.com/okleine/nCoAP
|-
| txThings || Python (Twisted) || Client + Server || MIT || https://github.com/mwasilak/txThings
|}

== Courses ==

* [[Vertiefendes Wahlfach-Projekt]] (2018)
* [[CoAP Chat Application for RIOT OS]]

== References ==
* RFC 7252: https://tools.ietf.org/html/rfc7252
* RFC 2616: https://www.ietf.org/rfc/rfc2616.txt
* CoAP: RFC 7252 Constrained Application Protocol https://coap.technology/
* Learning Internet of Things: https://www.oreilly.com/library/view/learning-internet-of/9781783553532/

[[Category:Documentation]]

Constrained Application Protocol

2019-04-01T19:05:04Z

Awolfsbauer:

The '''Constrained Application Protocol''' ('''CoAP''') is a specialized web transfer protocol, as defined in RFC 7252, for use with constrained nodes and constrained networks in the Internet of Things.
The protocol is designed for machine-to-machine (M2M) applications such as smart energy and building automation.

== Features ==

The work on Constrained Environments aims at realizing the REST architecture in a suitable form for the most constrained nodes and networks. The nodes usually consist of 8-bit microcontrollers with limited amounts of RAM and ROM.

CoAP has the following main features:

* Web protocol fulfilling M2M requirements in constrained environments
* UDP [RFC0768] binding with optional reliability supporting unicast and multicast requests
* Asynchronous message exchanges
* Low header overhead and parsing complexity
* URI and Content-type support
* Simple proxy and caching capabilities
* Stateless HTTP mapping
* Security binding to Datagram Transport Layer Security (DTLS)

== The Protocol ==

CoAP is similar to the client/server model of HTTP. M2M interactions typically result in a CoAP implementation acting in both client and server roles. A request is sent by a client to request an action on a resource (identified by a URI) on a server. The server then sends a response with a response code (equivalent to that of HTTP). Therefore, efficiency is very important, so CoAP uses UDP, a datagram-oriented transport.

CoAP is however a single protocol, with messaging and request/response as just features of the CoAP header

+----------------------+
| Application |
+----------------------+
+----------------------+ \
| Requests/Responses | |
|----------------------| | CoAP
| Messages | |
+----------------------+ /
+----------------------+
| UDP |
+----------------------+

== Message Format ==

By default, the messages are encoded in a simple binary format and transported over UDP. The message format starts with a fixed-size 4-byte header, followed by a variable-length Token value, which can be between 0 and 8 bytes long. Following the Token value comes a sequence of zero or more CoAP Options in Type-Length-Value (TLV) format, optionally followed by a payload that takes up the rest of the datagram.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

;Version (Ver) (2 bits)
:Indicates the CoAP Version number. This must set this field to 1 (binary 01). Other values are reserved for future versions.

;Type (T) (2 bits)
:Indicates if this message is of type Confirmable (0), Non-confirmable (1), Acknowledgement (2), or Reset (3).

;Token Length (TKL) (4 bits)
:Indicates the length of the variable-length Token field, which may be 0-8 bytes in length.

;CoAP Request/Response Code (8 bits)
:Splits into a 3-bit class and 5-bit detail.

;Message ID (16 bits)
:Used to detect message duplication and to match messages of type Acknowledgement/Reset to messages of type Confirmable/Non-confirmable.

== Security Considerations ==

This section list some possible threats to the protocol. As CoAP realizes a subset of the features of HTTP/1.1, the security considerations in section 15 of RFC2616 are also pertinent to CoAP.

;Parsing the Protocol and Processing URI's

The URI processing code in CoAP is likely to be a large source of vulnerabilities and should be implemented very carefully. Vulnerabilities include remotely crashing a node and remotely executing arbitrary code. CoAP aims to reduce the risk of these vulnerabilities by reducing parser complexity and moving much of the URI processing to the clients.

;Proxying and Caching

Proxies are man-in-the-middle by their nature. They can break any IPsec or DTLS protection that would otherwise happen between direct CoAP message exchange. Risks include the loss of confidentiality and availability. If the proxies also cache the threat to confidentiality and integrity of request/response data is amplified as CoAP does not implement cache-suppressing Cache-control as in HTTP/1.1.
For caching implementations any access control considerations also need to be applied to the value in the cache. A caching proxy must not make cache values available to requests that have lesser transport-security properties.

;Risk of Amplification

As CoAP server reply to request packets with response packets that may be significantly larger an attacker can use CoAP nodes to generate more traffic and use them in a denial-of-service(DoS) attack. Turning a small attack packet into a larger one is called amplification. The attacker wants to overload a victim but is limited in the amount of traffic can use amplification to generate larger amounts. If a node that enables NoSec access becomes available to an attacker it can access victims on the general internet. UDP provides no way to verify the source address given in the request packet and an attacker can place the IP of the victim in the source address of a request packet to generate a larger packet directed at the victim. The risk is reduced however as constrained networks are only able to generate small amounts of traffic. In contrast the network itself with its limited capacity is a viable victim of an amplification attack. RFC 7252 lists some things to avoid in implementation to reduce the risk and possibility of such attacks.

;IP Address Spoofing

;Cross-Protocol Attacks

;Constrained Node Considerations

Keys should be generated externally and added to the device during manufacturing or commissioning. Due to low processing power constrained nodes are susceptible to timing attacks. Cryptographic principles should be implemented with special care as many nodes are installed in exposed environments and have little resistance to tampering. The scope of credentials assigned to them should be considered carefully. A shared key assigned to a group of nodes may make any single node a target for subverting the entire group.

== Implementations ==

Generic implementations are becoming available for a variety of platforms. Implementations for constrained devices are typically written in C. CoAP is also used between them and more powerful systems such as cloud servers, home centrals, smartphones:

{| class="wikitable sortable"
|-
! Name !! Programming Language !! Client/Server !! License !! Link
|-
| Erbium for Contiki || C || Client + Server || 3-clause BSD || http://www.contiki-os.org/
|-
| libcoap || C || Client + Server || BSD/GPL || https://libcoap.net/
|-
| Eclipse tinydtls || C || Client + Server || EPL+EDL || https://projects.eclipse.org/projects/iot.tinydtls
|-
| LibNyoci || C || Client + Server || MIT || https://github.com/darconeous/libnyoci
|-
| microcoap || C || Client + Server || MIT || https://github.com/1248/microcoap
|-
| cantcoap || C++/C || Client + Server || BSD || https://github.com/staropram/cantcoap
|-
| Lobaro CoAP || C || Client + Server || MIT || https://www.lobaro.com/portfolio/lobaro-coap/
|-
| MR-CoAP || Java || || BSD || https://github.com/MR-CoAP/CoAP
|-
| Wakaama || C || Client + Server || EPL+EDL || https://www.eclipse.org/wakaama/index.html
|-
| coap-node || Javascript || Client || MIT || https://github.com/PeterEB/coap-node
|-
| coap-shepherd || Javascript || Server || MIT || https://github.com/PeterEB/coap-shepherd
|-
| Californium || Java || Client + Server || EPL+EDL || https://www.eclipse.org/californium
|-
| nCoap || Java || Client + Server || BSD || https://github.com/okleine/nCoAP
|-
| leshan || Java || Client + Server || EPL+EDL || https://github.com/eclipse/leshan
|-
| CoAP.NET || C# || Client + Server || 3-clause BSD || https://github.com/smeshlink/CoAP.NET
|-
| CoAPSharp || C#, .NET || Client + Server || LGPL || http://www.coapsharp.com
|-
| Waher.Networking.CoAP || C# || Server || || https://github.com/PeterWaher/IoTGateway
|-
| gen_coap || Erlang || Client + Server || MPL v1.1 || https://github.com/gotthardp/gen_coap
|-
| go-coap || Go || Client + Server || MIT || https://github.com/go-ocf/go-coap
|-
| node-coap || Javascript || Client + Server || MIT || https://github.com/mcollina/node-coap
|-
| coap-cli || Javascript || || MIT || https://github.com/mcollina/coap-cli
|-
| txThings || Python (Twisted) || Client + Server || MIT || https://github.com/mwasilak/txThings
|-
| aiocoap || Python 3 || Client + Server || MIT || https://github.com/chrysn/aiocoap
|-
| CoAPthon || Python || Client + Server || MIT || https://github.com/Tanganelli/CoAPthon
|-
| Ruby coap || Ruby || Client || MIT || https://github.com/nning/coap
|-
| Ruby david || Ruby || Server || MIT || https://github.com/nning/david
|-
| coap-rs || Rust || Client + Server || MIT || https://github.com/Covertness/coap-rs
|-
| Copper || JavaScript (Browser Plugin) || Client || BSD || https://github.com/mkovatsc/Copper
|-
| iCoAP || Objective-C || Client || MIT || https://github.com/stuffrabbit/iCoAP
|-
| SwiftCoAP || Swift || Client + Server || MIT || https://github.com/stuffrabbit/SwiftCoAP
|-
| nCoap || Java || Client + Server || BSD || https://github.com/okleine/nCoAP
|-
| txThings || Python (Twisted) || Client + Server || MIT || https://github.com/mwasilak/txThings
|}

== Courses ==

* [[Vertiefendes Wahlfach-Projekt]] (2018)
* [[CoAP Chat Application for RIOT OS]]

== References ==
* RFC 7252: https://tools.ietf.org/html/rfc7252
* CoAP: RFC 7252 Constrained Application Protocol https://coap.technology/
* Learning Internet of Things: https://www.oreilly.com/library/view/learning-internet-of/9781783553532/

[[Category:Documentation]]

CoAP Chat Application for RIOT OS

2019-03-26T16:15:46Z

Awolfsbauer:

== Summary ==

This documentation describes the setup and usage of a
[[Constrained Application Protocol | CoAP]]-based, chat application for the [https://riot-os.org/ RIOT] operating system.

== Requirements ==

* Operating system: [https://github.com/RIOT-OS/RIOT RIOT OS]
* Packages: https://git.fh-campuswien.ac.at/WP-ITS/riochat (Note: this package already includes RIOT OS)
* Hardware: a compatible MCU, a list is available [https://github.com/RIOT-OS/RIOT/wiki/RIOT-Platforms here]

In order to build and use this application, you need to install the tool chains used by RIOT. Tutorials on how to do that can be found in the official RIOT GitHub repository and the official documentation:

* The [https://github.com/RIOT-OS/RIOT/wiki RIOT GitHub wiki] contains all the information to get started.
* A detailed step-by-step [https://github.com/RIOT-OS/Tutorials/blob/master/README.md Tutorial] is also available.
* The official [https://doc.riot-os.org/index.html RIOT Documentation].

== Description ==

=== Step 1 ===

Clone the repository from https://git.fh-campuswien.ac.at/WP-ITS/riochat and compile it on the board you are using with:

make BOARD= ''board name'' all

alternatively you can compile it in native mode, i.e without using an evaluation board:

make BOARD=native all

If you are using native mode, you will need to setup a [https://github.com/RIOT-OS/RIOT/wiki/Virtual-riot-network#your-first-topology-2-nodes-1-hop Virtual RIOT network] with at least two TAP devices, for communication between nodes. This can be achieved with the following script:

RIOT/dist/tools/tapsetup/tapsetup -c 2

Open a two terminals and run two nodes. The first with tap0 and the other with tap1.

make BOARD=native PORT=tap0 term

make BOARD=native PORT=tap1 term

=== Step 2 ===

After boot-up you can type <code>help</code> to see a list of all available commands:

> help
help
Command Description
---------------------------------------
server Riot CoAP Server
client Riot CoAP Client
s Riot CoAP Server
c Riot CoAP Client
reboot Reboot the node
ps Prints information about running threads.
ping6 Ping via ICMPv6
random_init initializes the PRNG
random_get returns 32 bit of pseudo randomness
nib Configure neighbor information base
ifconfig Configure network interfaces

Run client on one board (or terminal for native) and server on another.

=== Step 3 ===

After starting a client on a node you are greeted with the following options:

Help Screen:
Command Parameters Description
----------------------------------------------------------------------
/discovery[/d] send broadcast to find server
/connect[/c] connect to set server
/list[/l] list discovered server
/info[/i] get server info
/setserver[/ss] [serverid] set server to serverid
/setuser[/su] [username] set user to username
/options[/o] show config
/help[/h] this screen
/exit[/e] exit RioChat, drop back to Shell
----------------------------------------------------------------------
Just type to send messages, when you are connected.

After setting a user with <code>/setuser</code> you need to run <code>/discovery</code> to send a broadcast to find the server. <code>/list</code> shows you a list of discovered servers. Each server has a name a server address (IPv6) and an id. With <code>/setserver</code> you can set the server id to your desired server and with <code>/connect</code>, connect to it.
After you are connected you can type messages and send them to all clients that are connected to the server.

== Used Hardware ==

This project was realized with the [https://github.com/RIOT-OS/RIOT/wiki/Board:-SAMR21-xpro SAMR21-xpro] evaluation board by Atmel. It features the [https://www.microchip.com/wwwproducts/en/ATSAMR21G18A ATSAMR21G18A] SoC by Microchip. It contains an ARM® Cortex®-M0+ based 32-bit MCU with a 2.4GHz RF transceiver compliant with IEEE 802.15.4 standard.

== References ==

* https://github.com/RIOT-OS
* https://doc.riot-os.org/index.html
* https://www.microchip.com/wwwproducts/en/ATSAMR21G18A

[[Category:Documentation]]

CoAP Chat Application for RIOT OS

2019-03-26T16:10:46Z

Awolfsbauer:

== Summary ==

This documentation describes the setup and usage of a
[[Constrained Application Protocol | CoAP]]-based, chat application for the [https://riot-os.org/ RIOT] operating system.

== Requirements ==

* Operating system: [https://github.com/RIOT-OS/RIOT RIOT OS]
* Packages: https://git.fh-campuswien.ac.at/WP-ITS/riochat (Note: this package already includes RIOT OS)
* Hardware: a compatible MCU, a list is available [https://github.com/RIOT-OS/RIOT/wiki/RIOT-Platforms here]

In order to build and use this application, you need to install the tool chains used by RIOT. Tutorials on how to do that can be found in the official RIOT GitHub repository and the official documentation:

* The [https://github.com/RIOT-OS/RIOT/wiki RIOT GitHub wiki] contains all the information to get started.
* A detailed step-by-step [https://github.com/RIOT-OS/Tutorials/blob/master/README.md Tutorial] is also available.
* The official [https://doc.riot-os.org/index.html RIOT Documentation].

== Description ==

=== Step 1 ===

Clone the repository from https://git.fh-campuswien.ac.at/WP-ITS/riochat and compile it on the board you are using with:

make BOARD= ''board name'' all

alternatively you can compile it in native mode, i.e without using an evaluation board:

make BOARD=native all

If you are using native mode, you will need to setup a [https://github.com/RIOT-OS/RIOT/wiki/Virtual-riot-network#your-first-topology-2-nodes-1-hop Virtual RIOT network] with at least two TAP devices, for communication between nodes. This can be achieved with the following script:

RIOT/dist/tools/tapsetup/tapsetup -c 2

Open a two terminals and run two nodes. The first with tap0 and the other with tap1.

make BOARD=native PORT=tap0 term

make BOARD=native PORT=tap1 term

=== Step 2 ===

After boot-up you can type <code>help</code> to see a list of all available commands:

> help
help
Command Description
---------------------------------------
server Riot CoAP Server
client Riot CoAP Client
s Riot CoAP Server
c Riot CoAP Client
reboot Reboot the node
ps Prints information about running threads.
ping6 Ping via ICMPv6
random_init initializes the PRNG
random_get returns 32 bit of pseudo randomness
nib Configure neighbor information base
ifconfig Configure network interfaces

Run client on one board (or terminal for native) and server on another.

=== Step 3 ===

After starting a client on a node you are greeted with the following options:

Help Screen:
Command Parameters Description
----------------------------------------------------------------------
/discovery[/d] send broadcast to find server
/connect[/c] connect to set server
/list[/l] list discovered server
/info[/i] get server info
/setserver[/ss] [serverid] set server to serverid
/setuser[/su] [username] set user to username
/options[/o] show config
/help[/h] this screen
/exit[/e] exit RioChat, drop back to Shell
----------------------------------------------------------------------
Just type to send messages, when you are connected.

After setting a user with <code>/setuser</code> you need to run <code>/discovery</code> to send a broadcast to find the server. <code>/list</code> shows you a list of discovered servers. Each server has a name a server address (IPv6) and an id. With <code>/setserver</code> you can set the server id to your desired server and with <code>/connect</code>, connect to it.

== Used Hardware ==

This project was realized with the [https://github.com/RIOT-OS/RIOT/wiki/Board:-SAMR21-xpro SAMR21-xpro] evaluation board by Atmel. It features the [https://www.microchip.com/wwwproducts/en/ATSAMR21G18A ATSAMR21G18A] SoC by Microchip. It contains an ARM® Cortex®-M0+ based 32-bit MCU with a 2.4GHz RF transceiver compliant with IEEE 802.15.4 standard.

== References ==

* https://github.com/RIOT-OS
* https://doc.riot-os.org/index.html
* https://www.microchip.com/wwwproducts/en/ATSAMR21G18A

[[Category:Documentation]]

CoAP Chat Application for RIOT OS

2019-03-26T16:03:53Z

Awolfsbauer:

== Summary ==

This documentation describes the setup and usage of a
[[Constrained Application Protocol | CoAP]]-based, chat application for the [https://riot-os.org/ RIOT] operating system.

== Requirements ==

* Operating system: [https://github.com/RIOT-OS/RIOT RIOT OS]
* Packages: https://git.fh-campuswien.ac.at/WP-ITS/riochat (Note: this package already includes RIOT OS)
* Hardware: a compatible MCU, a list is available [https://github.com/RIOT-OS/RIOT/wiki/RIOT-Platforms here]

In order to build and use this application, you need to install the tool chains used by RIOT. Tutorials on how to do that can be found in the official RIOT GitHub repository and the official documentation:

* The [https://github.com/RIOT-OS/RIOT/wiki RIOT GitHub wiki] contains all the information to get started.
* A detailed step-by-step [https://github.com/RIOT-OS/Tutorials/blob/master/README.md Tutorial] is also available.
* The official [https://doc.riot-os.org/index.html RIOT Documentation].

== Description ==

=== Step 1 ===

Clone the repository from https://git.fh-campuswien.ac.at/WP-ITS/riochat and compile it on the board you are using with:

make BOARD= ''board name'' all

alternatively you can compile it in native mode, i.e without using an evaluation board:

make BOARD=native all

If you are using native mode, you will need to setup a [https://github.com/RIOT-OS/RIOT/wiki/Virtual-riot-network#your-first-topology-2-nodes-1-hop Virtual RIOT network] with at least two TAP devices, for communication between nodes. This can be achieved with the following script:

RIOT/dist/tools/tapsetup/tapsetup -c 2

Open a two terminals and run two nodes. The first with tap0 and the other with tap1.

make BOARD=native PORT=tap0 term

make BOARD=native PORT=tap1 term

=== Step 2 ===

After boot-up you can type help to see a list of all available commands:

> help
help
Command Description
---------------------------------------
server Riot CoAP Server
client Riot CoAP Client
s Riot CoAP Server
c Riot CoAP Client
reboot Reboot the node
ps Prints information about running threads.
ping6 Ping via ICMPv6
random_init initializes the PRNG
random_get returns 32 bit of pseudo randomness
nib Configure neighbor information base
ifconfig Configure network interfaces

Run client on one board (or terminal for native) and server on another.

=== Step 3 ===

After starting a client on a node you are greeted with the following options:

Help Screen:
Command Parameters Description
----------------------------------------------------------------------
/discovery[/d] send broadcast to find server
/connect[/c] connect to set server
/list[/l] list discovered server
/info[/i] get server info
/setserver[/ss] [serverid] set server to serverid
/setuser[/su] [username] set user to username
/options[/o] show config
/help[/h] this screen
/exit[/e] exit RioChat, drop back to Shell
----------------------------------------------------------------------
Just type to send messages, when you are connected.

After setting a user with <code>/setuser</code>

== Used Hardware ==

This project was realized with the [https://github.com/RIOT-OS/RIOT/wiki/Board:-SAMR21-xpro SAMR21-xpro] evaluation board by Atmel. It features the [https://www.microchip.com/wwwproducts/en/ATSAMR21G18A ATSAMR21G18A] SoC by Microchip. It contains an ARM® Cortex®-M0+ based 32-bit MCU with a 2.4GHz RF transceiver compliant with IEEE 802.15.4 standard.

== References ==

* https://github.com/RIOT-OS
* https://doc.riot-os.org/index.html
* https://www.microchip.com/wwwproducts/en/ATSAMR21G18A

[[Category:Documentation]]

CoAP Chat Application for RIOT OS

2019-03-26T15:36:42Z

Awolfsbauer:

CoAP Chat Application for RIOT OS

2019-03-26T15:19:24Z

Awolfsbauer:

CoAP Chat Application for RIOT OS

2019-03-26T15:07:35Z

Awolfsbauer:

CoAP Chat Application for RIOT OS

2019-03-26T15:03:57Z

Awolfsbauer:

== Summary ==

This documentation describes the setup and usage of a
[[Constrained Application Protocol | CoAP]]-based, chat application for the RIOT operating system.

== Requirements ==

* Operating system: [https://github.com/RIOT-OS/RIOT RIOT OS]
* Packages: https://git.fh-campuswien.ac.at/WP-ITS/riochat (Note: this package already includes RIOT OS)
* Hardware: a compatible MCU, a list is available [https://github.com/RIOT-OS/RIOT/wiki/RIOT-Platforms here]

In order to build and use this application, you need to install the toolchains used by RIOT. Tutorials on how to do that can be found in the official RIOT Github repository:

* The [https://github.com/RIOT-OS/RIOT/wiki RIOT GitHub wiki] contains all the information to get started.
* A detailed step-by-step [https://github.com/RIOT-OS/Tutorials/blob/master/README.md Tutorial] is also available.

== Description ==

=== Step 1 ===

Enter these commands in the shell

echo foo
echo bar

=== Step 2 ===

Make sure to read

* War and Peace
* Lord of the Rings
* The Baroque Cycle

== Used Hardware ==

[[https://github.com/RIOT-OS/RIOT/wiki/Board:-SAMR21-xpro]]

== Courses ==

* [[A course where this documentation was used]] (2017, 2018)
* [[Another one]] (2018)

== References ==

* https://wikipedia.org
* https://google.com

[[Category:Documentation]]

Constrained Application Protocol

2019-03-26T14:54:16Z

Awolfsbauer:

CoAP Chat Application for RIOT OS

2019-03-26T14:52:09Z

Awolfsbauer:

== Summary ==

This documentation describes the setup and usage of a
[[Constrained Application Protocol | CoAP]]-based, chat application for the RIOT operating system.

== Requirements ==

* Operating system: [https://github.com/RIOT-OS/RIOT RIOT OS]
* Packages: https://git.fh-campuswien.ac.at/WP-ITS/riochat (Note: this package already includes RIOT OS)
* Hardware: a compatible MCU, a list is available [https://github.com/RIOT-OS/RIOT/wiki/RIOT-Platforms here]

In order to complete these steps, you must have followed [[Some Other Documentation]] before.

== Description ==

=== Step 1 ===

Enter these commands in the shell

echo foo
echo bar

=== Step 2 ===

Make sure to read

* War and Peace
* Lord of the Rings
* The Baroque Cycle

== Used Hardware ==

[[https://github.com/RIOT-OS/RIOT/wiki/Board:-SAMR21-xpro]]

== Courses ==

* [[A course where this documentation was used]] (2017, 2018)
* [[Another one]] (2018)

== References ==

* https://wikipedia.org
* https://google.com

[[Category:Documentation]]

CoAP Chat Application for RIOT OS

2019-03-26T14:43:13Z

Awolfsbauer: Created page with "== Summary == This documentation describes the setup and usage of a CoAP-based, chat application for the RIOT operating system. == Requirements == * Operating system: RIOT..."

== Summary ==

This documentation describes the setup and usage of a CoAP-based, chat application for the RIOT operating system.

== Requirements ==

* Operating system: RIOT OS https://github.com/RIOT-OS/RIOT
* Packages: https://git.fh-campuswien.ac.at/WP-ITS/riochat (Note: this package already includes RIOT OS
* Hardware: a compatible MCU, a list is available [https://github.com/RIOT-OS/RIOT/wiki/RIOT-Platforms here]

In order to complete these steps, you must have followed [[Some Other Documentation]] before.

== Description ==

=== Step 1 ===

Enter these commands in the shell

echo foo
echo bar

=== Step 2 ===

Make sure to read

* War and Peace
* Lord of the Rings
* The Baroque Cycle

== Used Hardware ==

[[https://github.com/RIOT-OS/RIOT/wiki/Board:-SAMR21-xpro]]

== Courses ==

* [[A course where this documentation was used]] (2017, 2018)
* [[Another one]] (2018)

== References ==

* https://wikipedia.org
* https://google.com

[[Category:Documentation]]