Message Transfer Protocols
USP messages are sent between Endpoints over one or more Message Transfer Protocols.
Note: Message Transfer Protocol was a term adopted to avoid confusion with the term “Transport”, which is often overloaded to include both application layer (e.g. CoAP) and the actual OSI Transport layer (e.g. UDP). Throughout this document, Message Transfer Protocol (MTP) refers to application layer transport.
The requirements for each individual Message Transfer Protocol is covered in a section of this document. This version of the specification includes definitions for:
- The Constrained Application Protocol (CoAP)
- The Simple Text-Oriented Messaging Protocol
- MQ Telemetry Transport (MQTT)
Supporting Multiple MTPs
Agents and Controllers may support more than one MTP. When an Agent supports multiple MTPs, the Agent may be configured with parameters for reaching a particular Controller across more than one MTP. When an Agent needs to send a Notification to such a Controller, the Agent can be designed (or possibly configured) to select a particular MTP, to try sending the Notification to the Controller on all MTPs simultaneously, or to try MTPs sequentially. USP has been designed to allow Endpoints to recognize when they receive a duplicate Message and to discard any duplicates. Endpoints will always send responses on the same MTP where the Message was received.
This specification places the following requirement for encrypting MTP headers and payloads on USP implementations that are intended to be used in environments where USP Messages will be transported across the Internet:
R-MTP.0 – The Message Transfer Protocol MUST use secure transport when USP Messages cross inter-network boundaries.
For example, it may not be necessary to use MTP layer security when within an end-user’s local area network (LAN). It is necessary to secure transport to and from the Internet, however. If the device implementer can reasonably expect Messages to be transported across the Internet when the device is deployed, then the implementer needs to ensure the device supports encryption of all MTP protocols.
MTPs that operate over UDP will be expected to implement, at least, DTLS 1.2 as defined in RFC 6347.
MTPs that operate over TCP will be expected to implement, at least, TLS 1.2 as defined in RFC 5246.
Specific requirements for implementing these are provided in the individual MTP sections.
R-MTP.1 – When TLS or DTLS is used to secure an MTP, an Agent MUST require the MTP peer to provide an X.509 certificate.
R-MTP.2 - An Agent capable of obtaining absolute time SHOULD wait until it has accurate absolute time before establishing TLS or DTLS encryption to secure MTP communication. If an Agent for any reason is unable to obtain absolute time, it can establish TLS or DTLS without waiting for accurate absolute time. If an Agent chooses to establish TLS or DTLS before it has accurate absolute time (or if it does not support absolute time), it MUST ignore those components of the received X.509 certificate that involve absolute time, e.g. not-valid-before and not-valid-after certificate restrictions.
R-MTP.3 - An Agent that has obtained an accurate absolute time MUST validate those components of the received X.509 certificate that involve absolute time.
R-MTP.4 - When an Agent receives an X.509 certificate while establishing TLS or DTLS encryption of the MTP, the Agent MUST execute logic that achieves the same results as in the decision flow from Figures MTP.1.
Figure MTP.1 – Receiving a X.509 Certificate
Brokered USP Record Errors
MTPs that allow connectivity directly between Endpoints tear down the connection when encountering a USP Record error or other failure caused by the USP Record. This allows such a problem to be signaled to the other Endpoint. MTP protocols where Endpoints connect to a session broker do not tear down the connections to the session broker when encountering USP Record errors. To notify an Endpoint when a failed USP Record was sent, the receiving Endpoint replies with a simple error message.
These error messages are indicated using content type
application/vnd.bbf.usp.error. The following error codes (in the range 7100-7199) are defined to allow the error to be more specifically indicated. Requirements for communicating USP Record errors using this content type and these error codes are included in the definitions of brokered MTPs.
||Record could not be parsed||This error indicates the received USP Record could not be parsed.|
||Secure session required||This error indicates USP layer Secure Message Exchange is required.|
||Secure session not supported||This error indicates USP layer Secure Message Exchange was indicated in the received Record but is not supported by the receiving Endpoint.|
||Segmentation and reassembly not supported||This error indicates segmentation and reassembly was indicated in the received Record but is not supported by the receiving Endpoint.|
||Invalid Record value||This error indicates the value of at least one Record field was invalid.|