Universal Plug and Play

The foundation for UPnP networking is IP addressing. Each device must implement a DHCP client and search for a DHCP server when the device is first connected to the network. If no DHCP server is available, the device must assign itself an address. The process by which a UPnP device assigns itself an address is known within the UPnP Device Architecture as AutoIP. In UPnP Device Architecture Version 1.0,[7] AutoIP is defined within the specification itself; in UPnP Device Architecture Version 1.1,[8] AutoIP references IETF RFC 3927. If during the DHCP transaction, the device obtains a domain name, for example, through a DNS server or via DNS forwarding, the device should use that name in subsequent network operations; otherwise, the device should use its IP address.

Once a device has established an IP address, the next step in UPnP networking is discovery. The UPnP discovery protocol is known as the Simple Service Discovery Protocol (SSDP). When a device is added to the network, SSDP allows that device to advertise its services to control points on the network. This is achieved by sending SSDP alive messages. When a control point is added to the network, SSDP allows that control point to actively search for devices of interest on the network or listen passively to the SSDP alive messages of devices. The fundamental exchange is a discovery message containing a few essential specifics about the device or one of its services, for example, its type, identifier, and a pointer (network location) to more detailed information.

After a control point has discovered a device, the control point still knows very little about the device. For the control point to learn more about the device and its capabilities, or to interact with the device, the control point must retrieve the device's description from the location (URL) provided by the device in the discovery message. The UPnP Device Description is expressed in XML and includes vendor-specific manufacturer information like the model name and number, serial number, manufacturer name, (presentation) URLs to vendor-specific web sites, etc. The description also includes a list of any embedded services. For each service, the Device Description document lists the URLs for control, eventing and service description. Each service description includes a list of the commands, or actions, to which the service responds, and parameters, or arguments, for each action; the description for a service also includes a list of variables; these variables model the state of the service at run time, and are described in terms of their data type, range, and event characteristics.

Having retrieved a description of the device, the control point can send actions to a device's service. To do this, a control point sends a suitable control message to the control URL for the service (provided in the device description). Control messages are also expressed in XML using the Simple Object Access Protocol (SOAP). Much like function calls, the service returns any action-specific values in response to the control message. The effects of the action, if any, are modeled by changes in the variables that describe the run-time state of the service.

Another capability of UPnP networking is event notification, or eventing. The event notification protocol defined in the UPnP Device Architecture is known as General Event Notification Architecture (GENA). A UPnP description for a service includes a list of actions the service responds to and a list of variables that model the state of the service at run time. The service publishes updates when these variables change, and a control point may subscribe to receive this information. The service publishes updates by sending event messages. Event messages contain the names of one or more state variables and the current value of those variables. These messages are also expressed in XML. A special initial event message is sent when a control point first subscribes; this event message contains the names and values for all evented variables and allows the subscriber to initialize its model of the state of the service. To support scenarios with multiple control points, eventing is designed to keep all control points equally informed about the effects of any action. Therefore, all subscribers are sent all event messages, subscribers receive event messages for all "evented" variables that have changed, and event messages are sent no matter why the state variable changed (either in response to a requested action or because the state the service is modeling changed).

The final step in UPnP networking is presentation. If a device has a URL for presentation, then the control point can retrieve a page from this URL, load the page into a web browser, and depending on the capabilities of the page, allow a user to control the device and/or view device status. The degree to which each of these can be accomplished depends on the specific capabilities of the presentation page and device.

A UPnP AV media server is the UPnP-server ("master" device) that provides media library information and streams media-data (like audio/video/picture/files) to UPnP clients on the network. It is a computer system or a similar digital appliance that stores digital media, such as photographs, movies, or music and shares these with other devices.

UPnP AV media servers provide a service to UPnP AV client devices, so-called control points, for browsing the media content of the server and request the media server to deliver a file to the control point for playback.

UPnP media servers are available for most operating systems and many hardware platforms. UPnP AV media servers can either be categorized as software-based or hardware-based. Software-based UPnP AV media servers can be run on a PC. Hardware-based UPnP AV media servers may run on any NAS devices or any specific hardware for delivering media, such as a DVR. As of May 2008, there were more software-based UPnP AV media servers than there were hardware-based servers.

• UPnP MediaServer ControlPoint - which is the UPnP-client (a 'slave' device) that can auto-detect UPnP-servers on the network to browse and stream media/data-files from them.
• UPnP MediaRenderer DCP - which is a 'slave' device that can render (play) content.
• UPnP RenderingControl DCP - control MediaRenderer settings; volume, brightness, RGB, sharpness, and more.
• UPnP Remote User Interface (RUI) client/server - which sends/receives control-commands between the UPnP-client and UPnP-server over network, (like record, schedule, play, pause, stop, etc.).
  • Web4CE (CEA 2014) for UPnP Remote UI[15] - CEA-2014 standard designed by Consumer Electronics Association's R7 Home Network Committee. Web-based Protocol and Framework for Remote User Interface on UPnP Networks and the Internet (Web4CE). This standard allows a UPnP-capable home network device to provide its interface (display and control options) as a web page to display on any other device connected to the home network. That means that one can control a home networking device through any web-browser-based communications method for CE devices on a UPnP home network using ethernet and a special version of HTML called CE-HTML.
• QoS (quality of service) - is an important (but not mandatory) service function for use with UPnP AV (Audio and Video). QoS (quality of service) refers to control mechanisms that can provide different priority to different users or data flows, or guarantee a certain level of performance to a data flow in accordance with requests from the application program. Since UPnP AV is mostly to deliver streaming media that is often near real-time or real-time audio/video data which it is critical to be delivered within a specific time or the stream is interrupted. QoS guarantees are especially important if the network capacity is limited, for example public networks, like the internet.
  • QoS for UPnP consist of Sink Device (client-side/front-end) and Source Device (server-side/back-end) service functions. With classes such as; Traffic Class that indicates the kind of traffic in the traffic stream, (for example, audio or video). Traffic Identifier (TID) which identifies data packets as belonging to a unique traffic stream. Traffic Specification (TSPEC) which contains a set of parameters that define the characteristics of the traffic stream, (for example operating requirement and scheduling). Traffic Stream (TS) which is a unidirectional flow of data that originates at a source device and terminates at one or more sink device(s).
• Remote Access - defines methods for connecting UPnP device sets that are not in the same multicast domain.

The UPnP protocol, by default, does not implement any authentication, so UPnP device implementations must implement the additional Device Protection service,[16] or implement the Device Security Service.[17] There also exists a non-standard solution called UPnP-UP (Universal Plug and Play - User Profile)[18][19] which proposes an extension to allow user authentication and authorization mechanisms for UPnP devices and applications. Many UPnP device implementations lack authentication mechanisms, and by default assume local systems and their users are completely trustworthy.[20][21]

When the authentication mechanisms are not implemented, routers and firewalls running the UPnP IGD protocol are vulnerable to attack. For example, Adobe Flash programs running outside the sandbox of the browser (e.g. this requires specific version of Adobe Flash with acknowledged security issues) are capable of generating a specific type of HTTP request which allows a router implementing the UPnP IGD protocol to be controlled by a malicious web site when someone with a UPnP-enabled router simply visits that web site.[22] This only applies to the "firewall-hole-punching"-feature of UPnP; it does not apply when the IGD does not support UPnP or UPnP has been disabled on the IGD. Also, not all routers can have such things as DNS server settings altered by UPnP because much of the specification (including LAN Host Configuration) is optional for UPnP enabled routers.[23] As a result, some UPnP devices ship with UPnP turned off by default as a security measure.

In 2011, researcher Daniel Garcia developed a tool designed to exploit a flaw in some UPnP IGD device stacks that allow UPnP requests from the Internet.[24][25] The tool was made public at DEFCON 19 and allows portmapping requests to external IP addresses from the device and internal IP addresses behind the NAT. The problem is widely propagated around the world, with scans showing millions of vulnerable devices at a time.[26]

In January 2013, the security company Rapid7 in Boston reported[27] on a six-month research programme. A team scanned for signals from UPnP-enabled devices announcing their availability for internet connection. Some 6900 network-aware products from 1500 companies at 81 million IP-addresses responded to their requests. 80% of the devices are home routers; others include printers, webcams and surveillance cameras. Using the UPnP-protocol, many of those devices can be accessed and/or manipulated.

In February 2013, the UPnP forum responded in a press release[28] by recommending more recent versions of the used UPnP stacks, and by improving the certification program to include checks to avoid further such issues.

UPnP is often the only significant multicast application in use in digital home networks; therefore, multicast network misconfiguration or other deficiencies can appear as UPnP issues rather than underlying network issues.

If IGMP snooping is enabled on a switch, or more commonly a wireless router/switch, it will interfere with UPnP/DLNA device discovery (SSDP) if incorrectly or incompletely configured (e.g. without an active querier or IGMP proxy), making UPnP appear unreliable.

Typical scenarios observed include a server or client (e.g. smart TV) appearing after power on, and then disappearing after a few minutes (often 30 by default configuration) due to IGMP group membership expiring.

On 8 June 2020, yet another protocol design flaw was announced.[29] Dubbed "CallStranger"[30] by its discoverer, it allows an attacker to subvert the event subscription mechanism and execute a variety of attacks: amplification of requests for use in DDoS; enumeration; and data exfiltration.

OCF had published a fix to the protocol specification in April 2020,[31] but since many devices running UPnP are not easily upgradable, CallStranger is likely to remain a threat for a long time to come.[32] CallStranger has fueled calls for end-users to abandon UPnP because of repeated failures in security of its design and implementation.[33]