Constrained Application Protocol - Revision history

NKirnbauer: expired link changed with link from wayback machine

2024-10-23T10:31:57Z

expired link changed with link from wayback machine

← Older revision		Revision as of 10:31, 23 October 2024
Line 150:		Line 150:
	\| CoAP.NET \|\| C# \|\| Client + Server \|\| 3-clause BSD \|\| https://github.com/smeshlink/CoAP.NET		\| CoAP.NET \|\| C# \|\| Client + Server \|\| 3-clause BSD \|\| https://github.com/smeshlink/CoAP.NET
	\|-		\|-
	\| CoAPSharp \|\| C#, .NET \|\| Client + Server \|\| LGPL \|\| http://www.coapsharp.com		\| CoAPSharp \|\| C#, .NET \|\| Client + Server \|\| LGPL \|\| http://web.archive.org/web/20180222225621/http://www.coapsharp.com/
	\|-		\|-
	\| Waher.Networking.CoAP \|\| C# \|\| Server \|\| \|\| https://github.com/PeterWaher/IoTGateway		\| Waher.Networking.CoAP \|\| C# \|\| Server \|\| \|\| https://github.com/PeterWaher/IoTGateway

NKirnbauer: expired link changed with link from wayback machine

2024-08-28T14:56:58Z

expired link changed with link from wayback machine

← Older revision		Revision as of 14:56, 28 August 2024
Line 193:		Line 193:
	* RFC 7252: https://tools.ietf.org/html/rfc7252		* RFC 7252: https://tools.ietf.org/html/rfc7252
	* RFC 2616: https://www.ietf.org/rfc/rfc2616.txt		* RFC 2616: https://www.ietf.org/rfc/rfc2616.txt
	* CoAP: RFC 7252 Constrained Application Protocol https://coap.technology/		* CoAP: RFC 7252 Constrained Application Protocol http://web.archive.org/web/20191216093819/https://coap.technology/
	* Learning Internet of Things: https://www.oreilly.com/library/view/learning-internet-of/9781783553532/		* Learning Internet of Things: https://www.oreilly.com/library/view/learning-internet-of/9781783553532/

	[[Category:Basic]]		[[Category:Basic]]

NKirnbauer: /* Courses */

2024-08-22T18:54:27Z

Courses

← Older revision		Revision as of 18:54, 22 August 2024
Line 187:		Line 187:
	== Courses ==		== Courses ==

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

Awolfsbauer at 14:21, 9 April 2019

2019-04-09T14:21:48Z

← Older revision		Revision as of 14:21, 9 April 2019
Line 69:		Line 69:
	== Security Considerations ==		== 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.		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.		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.

Awolfsbauer at 14:20, 9 April 2019

2019-04-09T14:20:01Z

← Older revision		Revision as of 14:20, 9 April 2019
Line 69:		Line 69:
	== Security Considerations ==		== 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.		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).		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		;Parsing the Protocol and Processing URI's

Awolfsbauer at 14:17, 9 April 2019

2019-04-09T14:17:03Z

← Older revision		Revision as of 14:17, 9 April 2019
Line 100:		Line 100:
	;Cross-Protocol Attacks		;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.		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 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 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.		#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		;Constrained Node Considerations

Awolfsbauer at 14:07, 9 April 2019

2019-04-09T14:07:10Z

← Older revision		Revision as of 14:07, 9 April 2019
Line 70:		Line 70:

	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.		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		;Parsing the Protocol and Processing URI's
Line 98:		Line 100:
	;Cross-Protocol Attacks		;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		;Constrained Node Considerations

Awolfsbauer at 13:52, 9 April 2019

2019-04-09T13:52:22Z

← Older revision		Revision as of 13:52, 9 April 2019
Line 86:		Line 86:
	;IP Address Spoofing		;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.		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.		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.

Awolfsbauer at 13:44, 9 April 2019

2019-04-09T13:44:45Z

← Older revision		Revision as of 13:44, 9 April 2019
Line 82:		Line 82:
	;Risk of Amplification		;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.		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		;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		;Cross-Protocol Attacks

Ograsl at 16:36, 4 April 2019

2019-04-04T16:36:16Z

← Older revision		Revision as of 16:36, 4 April 2019
Line 181:		Line 181:
	* Learning Internet of Things: https://www.oreilly.com/library/view/learning-internet-of/9781783553532/		* Learning Internet of Things: https://www.oreilly.com/library/view/learning-internet-of/9781783553532/

	[[Category:~~Basics~~]]		[[Category:Basic]]