Ilustración representando emociones

Universal Plug and Play (UPnP) is a networking architecture, accompanied by a set of net- working protocols, which targets at enabling networked devices to seamlessly discover each other‘s presence on the network and to establish network services for entertainment, data sharing, and communications. Its main goal is on the one hand to allow devices to connect seamlessly, and on the other hand to simplify service discovery and usage in home as well as corporate environments. The concept of UPnP is an extension of plug-and-play, a tech- nology to dynamically attach devices directly to a computer, although UPnP is not directly related to the earlier plug-and-play technology. UPnP devices are “plug-and-play” because when connected to a network they automatically (zero configuration) “collaborate” with other devices. The main features of UPnP are:

• it is media and device independent, • it is platform independent,

• it is entirely based on widely-used Internet protocols and technologies, • it offers both user-interface-based and programmatic control,

• it provides mechanisms for the implementation of extensions.

Due to the fact that UPnP is based on existing Internet protocols - such as IP, TCP, UDP, HTTP - and Internet technologies - such as XML - UPnP functionality is based on the host system networking stack, and specifically on protocols and technologies used in Layer 3 of the OSI reference stack and above. Consequently, it is independent of the underlying data link and physical layer technologies and it can run on any underlying technology such as coax, phone line, power line, ethernet and IEEE 1394. Furthermore, it is platform indepen- dent, thus allowing vendors to use any operating system and any programming language to build UPnP products. On top of these features, UPnP also enables vendors to provide Web-based user interfaces for their devices, while at the same time allowing for conven- tional programmatic control, embedded inside application logic. Last but not least, UPnP defines placeholders in its message headers, which can be used to implement value-added services, specific to the capabilities of a particular device.

7.3.1.1 UPnP Architecture

UPnP network elements: The main elements that comprise a UPnP network are: • UPnP devices,

• UPnP services, • UPnP control points.

AUPnP devicecan be any UPnP-enabled equipment, from mobile phones to TVs and home gateways. The UPnP device properties are expressed using an XML document, called the Device Description Document. The aim of this document is to hold identification details of the device and a complete list of UPnP services the device supports.

UPnP services are the set of actions that can be invoked on the device, i.e. retrieving its status or switching it on/off. Additionally, UPnP enables devices to represent their state using a set of variables declared in the Device Description Document.

The UPnP control point is the final element of the UPnP network. It is essentially the “brains” of the UPnP network, as it is responsible for discovering all devices present on the network and performing control operations on these devices.

UPnP Device Architecture: The UPnP device architecture defines 5 steps to UPnP net- working: 0) addressing; the control point and device acquire addresses, 1) discovery; the control point finds devices, 2) description; the control point learns about device capabilities, 3) control; the control point invokes actions on devices, 4) eventing; the control point listens to state changes of devices, 5) presentation; the control point controls devices and/or views devices’ statuses using HTML UI.

A detailed description of the IPnP architecture can be found in the document: "UPnP Device Architecture 1.1", published by the UPnP Forum.

UPnP Extension Capabilities: UPnP vendors can differentiate their devices by: 1. extending services,

2. including additional UPnP services, 3. embedding additional devices.

When a control point retrieves a particular device’s description, these added features are exposed to the control point for control and eventing. The device and service descriptions authoritatively document the implementation of the device. Furthermore, UPnP working committees and UPnP vendors are allowed to extend SSDP messages with additional SSDP header fields. The UPnP specification provides the mechanisms to enable devices and con- trol points to understand extensions, by configuring them with external servers from which they can retrieve their semantics.

7.3.1.2 Application Areas

Today UPnP is an industry standard that meets wide deployment on media streaming de- vices, audiovisual appliances, home control systems and home appliances for the realization of popular applications, such as:

• Device Management: troubleshooting of malfunctions encountered during appliance operation. Through UPnP the error can be traced down remotely and the appliance can be fixed by the producer through the network. In other cases appliances can be upgraded with new programs that can be supported by the hardware, simply by tracing appliance compatibility through UPnP.

• Media Server & Media Renderer: with UPnP a media streaming device or a new tech- nology plasma TV can be turned into a media center capable of providing media con- tent on-demand, such as favorite songs and movies, via intuitive network downloading functions integrated on the remote control of the TV device. Moreover, UPnP-enabled services allow movies recorded, e.g., on the DVR at home to be copied elsewhere, for instance to the car server. UPnP makes sure the copies are legitimate by checking the user rights.

• Home appliances management: UPnP enables binding of services for home appli- ances management on any user terminal, intuitively and effortlessly. In this way, light control, appliance monitoring, doors control, can be easily facilitated over the home or external IP networks.

7.3.1.3 UPnP Implementation Aspects

In this section we review how end systems and in particular embedded devices can be interacted with using UPnP technology. Specifically, can be deployed in end devices using either of the following approaches:

1. as a standalone implementation running on the devices,

2. as a bridge-type implementation, using UPnP proxying functionality. What follows is a brief overview of these two implementation options.

Standalone implementation: in this case UPnP runs directly in the networked devices, and is the means by which the M2M API of a device is exposed to other networked de- vices. A diagram of the standalone implementation architecture is shown in Figure13. The stand-alone implementation results in simple inter-domain communication, as each device is able to directly communicate with a single centralized control point responsible for the entire domain. On the other hand, and most importantly to us, implementing UPnP on end de- vices imposes additional requirements on the hardware resources of the devices (in terms

Figure 13: UPnP standalone implementation.

of CPU, RAM), making them more expensive. Note that this implementation type is pro- hibitive for terminals of type TT2 and TT3, as these do not have the needed resources in terms of memory, computational capability and communication performance. Thus, while this implementation method can be suitable for terminals with some embedded computa- tional power and Ethernet connection such as, e.g., TVs and game consoles, it cannot be implemented in constrained devices for, e.g., environmental monitoring.

Bridge-type implementation: the bridge-type implementation introduces the concept of a UPnP bridge, that performs UPnP operations and message exchanges on behalf of the devices, acting as a UPnP “proxy”. In order to realize the bridge-type implementation, ad- ditional software is required to implement the low-level communication details with the end devices. This low-level software - hereafter calleddriver - is responsible for operations such as detecting when the device has been turned on/off, and implementing the M2M API of the end devices, translating high-level commands to device-specific actions. The UPnP “proxy” is responsible for exposing this M2M API to the UPnP network and invoking control/status retrieval operations on the devices via the low level driver. The concept of the UPnP bridge- type implementation is depicted in Figure14.

The main benefit of the bridge-type implementation is that it moves UPnP functionality away from end devices, making it a more suitable approach for devices with limited resources and/or devices that do not natively run IP. On the other hand, the bridge-type implementa- tion demands the implementation of the low-level driver for each type of device present on the network - the type refers to a class of devices using the same communication protocol stack, i.e., KNX and Zigbee devices.

Figure 14: UPnP bridge-type implementation.

Note that while this approach is suitable for devices of type TT2 and TT3, it requires a higher complexity in the Gateway node, which has to be UPnP-ready. In this case an application layer Gatewaymust be provided.

7.3.1.4 Communication Security in UPnP

Although UPnP operations (discovery, description, control, eventing, presentation) involve a variety of protocols and message formats (DHCP, IP auto-configuration, SSDP, HTTP, XML, SOAP, GENA, etc.) the Device Security service that has been specified by the UPnP Security Working Committee regards the SOAP control actions as a means to cater for security issues in non isolated network where more than one Control Points (CPs) might be able to discover and gain access to devices. SOAP security aspects are defined as:

• Authorization: CPs must be authorized prior to any secured action;

• Integrity Protection: the enclosed signatures caters for message integrity as well; • Replay Prevention: sequence numbers are used to protect against replay;

• Confidentiality: if required, action and replay content can be encrypted.

A Device that implements Device Security service must support the following cryptographic algorithms:

• AES 128-bit for symmetric bulk encryption; • SHA1 HMAC for symmetric signatures;

In the context of the Device Security service, a device can enforce its own policy as far as its access to services and embedded devices is concerned. This policy is created and updated by and administrative interface defined as Security Console. Although this interface can be provided and made available by the device as long as display and data entry capabilities are possible, administrative functions are usually performed by Control Points. Access control permissions are classified either as ownership or normal. Ownership is instantiated inside the device in the form of a list with at least one entry. Additionally, a Device maintains an access control list (ACL) which is editable by device owners and defines less than full owner- ship privileged entities. Both lists contain signature keys that are used to validate signatures in control messages by devices prior enforcing any control requests and actions.

UPnP Security from IOT-A perspective:

• UPnP Security defines mechanisms to be applied by UPnP devices when operating in networks that are not isolated and thus foreign Control Points might be able to acquire access to these devices. The Device Security service aims at securing the control actions anddoes not cover discovery and description functions.

• Trust establishment that regards acquisition of the ownership of a device by a Control Point is achieved by use of a password known by the device and presented by the CP in order to initialize ownership. Thereafter, the signature key of the Control Point is maintained by the device in the list of owners.

• Since the security mechanism is embedded into the body of SOAP messages, in order to allow for policy enforcement with respect to access control, end to end security can be verified by the validity of the signatures.

• The authentication mechanism is based on signing of messages with keys known to devices either as owner keys or as more restricted CPs.

From the above, we conclude that there must be a network element providing the missing services of description and discovery. In addition, UPnP entails quite heavy security proce- dures that are likely to be prohibitive by the IoT nodes, which themselves are very unlikely to implement UPnP at all, due to their resource limitations. This has implications on how end- to-end security can be enforced between an unconstrained UPnP-ready node and a IoT device that does not natively support UPnP. This is further discussed in Section7.5below.