Term
| In TR-069, Connection Request is used to trigger the CPE-initiated session. Describe how connection to the CPE is handled in TR-369. |
|
Definition
| By definition, the CPE (called Agent now) is in an "always-on" mode of connection to the "ACS" (i.e. Collector) - due to the persistent TCP connection. Thus, it is not necessary to trigger a connection request - no such thing actually exists in TR-369. |
|
|
Term
| Explain the meaning of the following terms in the context of TR-369: Agent, Collector, Endpoint, EndpointID, Record, MTP |
|
Definition
Agent = what would normally be considered a CPE
Collector = typically an ACS, but can be any app which collects data and operates with Agents
Endpoint = can be either an Agent or a Collector
EndpointID = an analogy to cpeid in TR-069
Record = Message exchange between Endpoints
MTP = Message Transfer Protocol - the exchange of messages within MTP replaces TR-069 session |
|
|
Term
| List some of the prominent features of USP communication |
|
Definition
- Records can be sent from either side at any time
- Due to this, no Inform events are sent any more
- TR-069 session is gone, connection is in "always on" mode
- End-to-End security is built in the protocol (native support for message encryption)
- Possibility of relaying messages
- One agent can support multiple collectors; simply, this means that one device can be associated with multiple Collectors (imagine a cpe being connected to several ACS's with different purposes...) |
|
|
Term
| Provide a detailed breakdown of MTP. |
|
Definition
MTP stands for Message Transfer Protocol.
Typically this would be a persistent (TCP) connection among two or more Endpoints. Following protocols are supported:
CoAP, MQTT, STOMP, Websockets
The protocol is used as transparent transport for Records.
The MTP can be established either at the start or on demand. |
|
|
Term
| Explain- and give an example of a brokered protocol. |
|
Definition
| A brokered protocol, such as MQTT, is a communication protocol which relies on the usage of brokers. Brokers are intermediate agents which typically receive the communication message, perform some action on it and then relay it to the intended destination. |
|
|
Term
| How are USP Records encoded? |
|
Definition
| In ProtoBuf. Hence, they are binary-represented. |
|
|
Term
| What is determined by the usage of (No)SessionContext within a USP Record? |
|
Definition
| Whether the message will be contained directly in the Record, or whether it will be segmented. |
|
|
Term
| What are the types of messages in USP? |
|
Definition
| Request, Response, Error. |
|
|
Term
| Name USP alternatives to the following TR-069 methods: GetParameterValues, SetParameterValues, GetParameterNames, AddObject, DeleteObject |
|
Definition
GetParameterValues = Get
SetParameterValues = Set
GetParameterNames = GetInstances
AddObject = Add
DeleteObject = Delete |
|
|
Term
| Describe how the execution of operational RPC's differs from TR-069. |
|
Definition
| In TR-069, you have dedicated operational RPC's, such as Download, Reboot, etc. In USP, these operations are part of the data model. |
|
|
Term
| Describe notifications of events have changed in USP compared to TR-069. |
|
Definition
| There is the Notify message, and the events are, like Operations, reflected on the data model. As a Controller, you can subscribe to specific notifications (e.g. for changes caused by other Controllers.) |
|
|
Term
| What are some of the challenges of USP implementation? |
|
Definition
ProtoBuf usage makes the Records much less introspectable.
With E2E encryption we need to implement encryption inside the Controller (which will further decrease introspectability).
Communication with Endpoints: we cannot trigger a connection from the Endpoint, the connection is supposed to be always on, which necessitates a large number of concurrent open connections.
The Agent setup is much more complex - notifications, certificates, ACLs all typically need to be setup for agents. |
|
|
Term
| Describe the basic scheme of Session Context in USP. |
|
Definition
USP Messages are exchanged between Controllers and Agents. In some deployment scenarios, the Controller and Agent have a direct connection. In other deployment scenarios, the messages exchanged by the Controller and Agent traverse multiple intermediate MTP Proxies. The latter deployment scenario typically occurs when the Agent or Controller is deployed outside the proximal or Local Area Network. In both types of scenarios, the End-to-End (E2E) message exchange capabilities of USP permit the:
Exchange of USP Records within an E2E Session Context that allows for:
Integrity protection for non-payload fields
Protected and unprotected payloads
Segmentation and reassembly of E2E Messages that would be too large to transfer through the intermediate MTP Proxies.
Exchange of USP Records without an E2E Session Context that allows for:
Integrity protection for non-payload fields
Unprotected payloads or protected payloads where the payload protection security mechanism doesn’t require a concept of a session (e.g., COSE) |
|
|
Term
| How is communication within Session Context signfiied in a USP Record? |
|
Definition
| When exchanging USP Records within an E2E Session Context, record_type of session_context is used, and all required parameters for record_type of session_context are supplied. |
|
|
Term
| How is payload protection of Records signified within the Session Context? |
|
Definition
| By using the "payload_security" attribute. |
|
|
Term
| How does USP handle possible constraints on the maximum packet size imposed by some of the MTP's/network elements in between? |
|
Definition
| By segmentation of USP records within Session Context. Since USP can use different types of MTPs, some MTPs place a constraint on the size of the USP Message that it can transport. To handle this, USP has a Segmentation and Reassembly function. |
|
|
Term
| How is integrity of USP Records attained and verified? |
|
Definition
The Record is either considered protected based on the security of the underlying MTP, or the integrity of the non-payload fields is protected by the Endpoint using one of the mechanisms below:
R-E2E.29 – Unless protected by the underlying MTP, when a USP Endpoint transmits a USP Record, the USP Endpoint MUST protect the integrity of the non-payload portion of the USP Record.
R-E2E.30 – When a USP Endpoint receives a USP Record, the USP Endpoint MUST verify the integrity of the non-payload portion of the USP Record when the USP Record contains the mac_signature field or the USP Endpoint is not protected by the underlying MTP.
The integrity of the non-payload fields is accomplished by the transmitting USP Endpoint generating a Message Authentication Code (MAC) or signature of the non-payload fields which is then placed into the mac_signature field where the receiving USP Endpoint then verifies the MAC or signature as appropriate. The method to generate and validate MAC or signature depends on the value of the payload_security field. If the value of the payload_security field is PLAINTEXT then the integrity validation method always uses the signature method described in section Using the Signature Method to Validate the Integrity of USP Records. If the value of the payload_security field is TLS12 then the validation method that is used is dependent on whether the TLS handshake has been completed. If the TLS handshake has not been completed, the signature method described in section Using the Signature Method to Validate the Integrity of USP Records is used otherwise the MAC method described in section Using TLS to Validate the Integrity of USP Records is used. |
|
|
Term
| Describe the "Signature Method" for verification of USP Records. |
|
Definition
| When the transmitting USP Endpoint protects the integrity of the non-payload fields of the USP Record using the signature method in this section, the non-payload fields are protected by signing a hash of the non-payload fields using the private key of the sending USP Endpoint’s certificate. The receiving USP Endpoint then verifies the integrity using either the public key of the certificate in the USP Record sender_cert field or of the certificate used for Secure Message Exchange. |
|
|
Term
| Describe how Record Integrity is verified when TLS is used |
|
Definition
When the transmitting and receiving USP Endpoints have established a TLS session, the transmitting USP Endpoint no longer needs to generate a signature or transmit the sender’s certificate with the USP Record. Instead the transmitting USP Endpoint generates a MAC that is verified by the receiving USP Endpoint. The MAC ensures the integrity of the non-payload fields of the USP Record. The MAC mechanism used in USP for this purpose is the SHA-256 keyed-Hash Message Authentication Code (HMAC) algorithm.
This means that Hash-based Message Authentication Code is used to hash the non-payload fields of the record. HMAC is a more powerful tool than pure hashing, as it uses complicated math and a secret key used by both Endpoints to hash the content. The keys used for HMAC are exchanged within TLS establishment. |
|
|
Term
| What is the motivation for having additional security measures for Records on top of transport-level security assured by the underlying protocol? |
|
Definition
| In the context of brokered protocols being used for the transport (which secure "only" point to point security), end to end security needs to be ascertained as well. |
|
|
Term
| How, in general, is End to End security achieved in USP? |
|
Definition
| l. End-to-end security is established by securing the payloads prior to segmentation and transmission by the originating USP Endpoint and the decryption of reassembled payloads by the receiving USP Endpoint. The indication whether and how the USP Message has been secured is via the payload_security field. This field defines the security protocol or mechanism applied to the USP payload, if any. |
|
|
Term
| What condition must be met for TLS to be usable for Payload protection of Record? |
|
Definition
| Session context must be initiated. |
|
|
Term
| Describe general requirements for USP security. |
|
Definition
| USP contains mechanisms for Authentication and Authorization, and Encryption. Encryption can be provided at the MTP layer, the USP layer, or both. Where Endpoints can determine (through Authentication) that the termination points of the MTP and USP messages are the same, MTP encryption is sufficient to provide end-to-end encryption and security. Where the termination points are different (because there is a proxy or other intermediate device between the USP Endpoints), USP layer End to End Message Exchange is required, or the intermediate device must be a trusted part of the end-to-end ecosystem. |
|
|
Term
| How is the authentication of Controllers and of Agents done? |
|
Definition
| Authentication of Controllers is done using X.509 certificates. Authentication of Agents is done either by using X.509 certificates or shared secrets. |
|
|
Term
| What are the security prerequisites for an Agent processing a Message from the Controller? |
|
Definition
R-SEC.0 - Prior to processing a USP Message from a Controller, the Agent MUST either:
have the Controller’s certificate information and have a cryptographically protected connection between the two Endpoints, or
have a Trusted Broker’s certificate information and have a cryptographically protected connection between the Agent and the Trusted Broker |
|
|
Term
| What constraints are placed on Controller certificates? |
|
Definition
| The URN form of the Controller Endpoint ID is in the Controller certificate subjectaltName with a type uniformResourceIdentifier attribute. (Additionally, this must match the USP Record "from_id".) |
|
|
Term
| Describe in greater detail Agent authentication. |
|
Definition
| R-SEC.9 - Controllers MUST authenticate Agents either through X.509 certificates, a shared secret, or by trusting a Trusted Broker to vouch for Agent identity. |
|
|
Term
| How does the verification of Controller certificate by the Agent work? |
|
Definition
|
|
Term
| How does the No Secure Message Exchange work? |
|
Definition
|
|
Term
| How does checking a certificate work within USP? |
|
Definition
|
|
Term
| How is a Role determined for an Endpoint on USP? |
|
Definition
|
|
