The present disclosure relates generally to data communications network traffic delivered to a home client being securely redirected to a remote client device.
Universal Plug and Play (UPnP®) is a set of communications network protocols promulgated by the UPnP Forum. The UPnP® architecture allows peer-to-peer networking of PCs, networked appliances, and wireless devices. It is a distributed, open architecture based on Transmission Control Protocol/Internet Protocol (TCP/IP), User Datagram Protocol (UDP) and Hypertext Transfer Protocol (HTTP). UPnP® enables communication between any two devices under the command of any control device on a local area network (LAN).
One example of UPnP® device is an Internet Gateway Device (IGD) (referred to herein as a Residential Gateway (RG)) which may be used to connect various devices in a residential LAN to the internet using a service provider (SP) and also to each other. The RG may be embedded with a modem and a router or may comprise separate physical devices such as a bridge modem and external router. The RG may also include any number of connection bridges such as an Ethernet® switch, an 802.11 Access Point (AP), a Multimedia over Coax Alliance (MoCA®) bridge or other similar devices.
Some RGs may allow a roaming (portable, mobile) UPnP® client to receive traffic that is sent “home” so that mobile devices may benefit from services delivered to their home network despite the fact that the mobile device is not home. Existing methods for redirecting traffic (or re-broadcasting content) from the home have a number of limitations. For example, only one client can legitimately receive traffic. Also, all clients desiring this service would have to be present in the “home” at one point. Further, the traffic would need to traverse the home network (and be redirected/rebroadcast) in order to reach the roaming client. In addition, redirected traffic may be redirected to illegitimate sites (i.e., public venues such as sports bars).
The following detailed description includes the best currently contemplated modes of carrying out the invention. The description is not to be taken in a limiting sense, but is made merely for the purpose of illustrating the general principles of the invention, since the scope of the invention is best defined by the appended claims.
Overview
In one embodiment a method comprises enrolling a mobile device in a local area network having a Residential Gateway by setting a variable to a mobile device identifier when the mobile device is disposed locally with respect to the Residential Gateway; receiving a request for data from the mobile device when the mobile device is not disposed locally with respect to the Residential Gateway; and delivering the data from a service provider to the mobile device, when the mobile device is not disposed locally with respect to the Residential Gateway.
In another embodiment an apparatus comprises a mobile device identified by a mobile device identifier; and a network gateway connected to a service provider through a local area network; in which the mobile device is enrolled in the local area network by setting a Universal Plug and Play ExternalClient variable in the network gateway to the mobile device identifier; the mobile device is authenticated using the mobile device identifier; and data is delivered to the mobile device in response to a request for the data from the mobile device.
In a further embodiment an apparatus comprises a network gateway connected to a service provider through a local area network; means for enrolling a mobile device in the local area network using a mobile device identifier; means for authenticating the mobile device using the mobile device identifier; and means for delivering data to the mobile device in response to a request for the data from the mobile device.
Description
Broadly, the present invention may provide access to data from a service provider (SP) to a remote device in a communications network. Embodiments of the present invention may make use of a UPnP® “hole” to provide a simple but secure method to redirect data and media streams to remote devices, for example, mobile devices. Embodiments also may provide functionality comparable to currently available data forwarding/redirection devices, while also allowing the SP to maintain more control over content as compared to prior systems. For example, such control may include content protection controls such as control over where content is sent. Embodiments of the present invention may be advantageously used in wired or wireless communications systems having mobile devices.
In some communications systems, only one client can legitimately receive traffic and all clients desiring service would have to be present in the “home” (e.g., local area network) at one point. With the present invention, more than one client may legitimately receive traffic and clients may not be required to be physically “home” at one point.
The MD may access an authorization function that may be built into the RG or into a separate device. For example, the authorization may reside in any of the local networked devices 14 besides the RG 12. This authorization function may be referred to as a home services manager. For simplicity, in the embodiments described in
The UPnP® Internet Gateway Device (IGD) specifications describe a variable, called an InternalClient, that can be used for the purpose of configuring the IGD. For example, a Residential Gateway (RG) may be used to direct inbound (downstream) traffic to a specific address defined by the value of InternalClient. Although the intent of this variable is to define a local client, some poor implementations of UPnP® IGD allow the variable to be set to either a public Internet Protocol (IP) address or a Domain Name System (DNS) name—thus redirecting inbound traffic to an external client. A potential security hole is that a widespread proliferation of malicious clients (that are UPnP® compliant) can individually assign this variable per IGD to an address different from its own. As a result, a denial of service (DoS) attack may occur by redirecting traffic from numerous IGDs, and even worse, may make it look like the IGDs were the culprits sending the traffic.
A solution for fixing this “security hole” is to require that a) only a device physically on the LAN can change the variable, b) the device changing the variable can only change it to its own address, and c) the variable can only be changed to a local (private) IP address. However, this (or a similar) variable may also be used for benign and beneficial purposes by allowing a roaming (portable, mobile) client to receive traffic that is sent “home”. For example, this variable may be used to allow mobile devices to benefit from services delivered to their home network despite the fact that the mobile device is not home. Some systems, which can redirect traffic (or rebroadcast content) from the home to a mobile device, have some disadvantages. For example, only one client can legitimately receive traffic. Also, the traffic would have to traverse the home network (and be redirected/rebroadcast) in order to reach the roaming client. With embodiments of the invention, more than one client can legitimately receive traffic and traffic does not have to traverse the home network. Furthermore, redirecting the traffic only to specific, authorized devices can help prevent traffic from being redirected to illegitimate sites (i.e., public venues such as sports bars) even in the instances where only one connection is permitted to the home.
The “security hole” with the existing UPnP® variable InternalClient may be fixed by the solution described above. In accordance with an embodiment of the present invention, if the InternalClient variable is locked down a new variable can be created. In particular embodiments, a new variable (ExternalClient) may have the same properties as InternalClient, with two possible restrictions added. One restriction is that only a device present on the home LAN 22 (physically present or logically present via a secure tunnel) can change the variable. Another restriction is that the device changing the variable can only change it to its own address/name. In cases where the client uses Dynamic Host Configuration Protocol (DHCP), then a name may be used.
There are at least three issues to address when enabling traffic delivered to the home to be redirected to a remote client. A first issue may be how to “disallow” malicious local clients; that is, how to tell if a trusted client has become untrusted. A second issue may be how to restrict traffic to be forwarded depending upon geographic location of client, for example by not forwarding content to a region that is “blacked out”. A third issue may be how to prove a remote client device has been on the home LAN.
In particular embodiments of the present invention, a number of solutions may be employed to deal with the three issues described above. With respect to the first issue (how to tell if trusted client has become untrusted) there are at least two possible solutions. For one solution, in accordance with an embodiment, it is recognized that any individual client on the home LAN 22 is trusted at one point. If the client is wireless it will have wireless encryption; if wired, the client will have a physical connection. Since UPnP® may rely on the notion that all clients on the home LAN 22 are trusted, this embodiment does not address higher layer LAN security issues, e.g., malicious applications, utilities, or other code running on UPnP® clients for devices that are legitimately allowed to be on the home network (i.e., misbehaving but authorized “trusted” clients).
Another solution may be to restrict the variable to only allow a device to change the variable to its own address; but to allow the address to be a public or private address, Dynamic Domain Name System (DDNS) name. The device must be on the same subnet of the RG 12 in order to change the variable. This solution may help prevent DoS attacks since the device cannot set up a DoS attack to another client/address.
The second issue described above was how to restrict traffic to be forwarded depending upon geographic location of client. Many SPs (and content providers) have indicated that it is desirable that honest people should be able to access content they legitimately subscribe to wherever they are; hence, validating remote geographic location is not a prohibitive requirement. One solution is to not forward traffic to a public IP address if the client requesting such is still on the LAN. This solution may help in preventing traffic being forwarded illegitimately.
The third issue described above was how to prove a remote client device has been on the LAN. One possible solution to this issue is to recognize that the device is required to have been on home LAN 22 in order to change the variable. Hence, if the variable has been changed, then the system will recognize that the device has been on the home LAN 22. Another possible solution is to determine whether the device has enrolled with the RG 12 using some other secure method. If this is the case, it can be recognized that the device has been on the home LAN 22 (or is not required to have been on the home LAN 22).
There may be four steps for allowing a MD 16 to remotely and legitimately access services delivered to a home. The four steps may include 1) enrolling the MD 16; 2) authorizing (which may include validating, authenticating) the MD 16; 3) the MD 16 requesting data; and 4) delivering the data to the MD 16. Each of these steps may have several possible embodiments as described below.
Three examples of enrollment methods are shown in
When an MD 16 is local it will be referred to as a mobile device local (MDL) and when the MD 16 is non-local it will be referred to as a mobile device remote (MDR). All three enrollment methods can use the knowledge that the MDL has access to the home LAN 22 at some point before going remote. Access is defined as any IP connection to the home LAN 22 side of the RG 12, or as a connection to a third device acting as the home service manager (not shown). Regarding the security of the connection it is expected that any device connected to the home LAN 22 is trusted. For the first and second enrollment methods a priori knowledge of the MDR IP address may be required, and this IP address may be dynamic, static, or a name that is part of a DDNS service.
Arrow 32 represents the process of the MDL joining the home LAN 22 by making a connection to the RG 12. The MDL may next set the ExternalClient variable to the MDR IP address, as shown by arrow 34. The RG 12 can use this information in later steps to validate and authorize the MDR and/or to redirect traffic to the MDR. Arrow 36 represents the movement of MDL to a remote location where it becomes an MDR.
The ID could also be an alternate, additional variable if the ExternalClient variable is already used for storing the address as in the first enrollment method 23. It may be advantageous for the RG 12 to dynamically generate and retain this identifier, and then pair it to the ExternalClient variable. Thus, when the MDR client is remote and seeks access, this identifier can be used as a “shared secret”. The media access control (MAC) address of the RG could be used as this shared secret, but it may be preferred to have the identifier be dynamic and eventually expire (unless legitimately refreshed).
As with the second enrollment method 38, this random ID could also be an alternate, additional variable if the ExternalClient variable is already used for storing the address as in the first enrollment method 23. It may be advantageous for the RG 12 to dynamically generate and retain this identifier, and then pair it to the ExternalClient variable. Thus, when the MDR client is remote and seeks access, this identifier can be used as a “shared secret”. It may be noted that a “cookie” could be used as a device/service ID. In other words, this variable could not only be used to register/enroll/reenroll the MDR but also the service(s) it is entitled to receive.
Furthermore, there are at least four examples of embodiments (and implementation methods) where the MDL does not migrate to MDR, and where it is possible that the MDR was not physically at home during the enrollment stage, but where the above-described communication signaling diagrams could still apply. One of these four embodiments is one in which the MDL is a separate device that has authorization to make changes on the RG 12 on behalf of the MDR (e.g., a VoIP base station on behalf of a VoIP mobile phone or a Media Server on behalf of a paired mobile Media Sink). A second embodiment is one in which the RG 12 is pre-provisioned during shipping with enrollment information. A third embodiment is one in which the RG 12 is provisioned by a SP 18 that has authorization to make changes on the RG 12. A fourth embodiment is one in which the MDR establishes a tunnel to the home network and thus establishes a logical (virtual) presence that is indistinguishable from being physically present. In this case, the MDR appears to be an MDL.
In these four exemplary embodiments, it may be preferable for better content protection that the MD 12 actually be physically at home at least once. However, these four options can be made more secure by combining with a secondary registration by the MDR (e.g., as exemplified in the second and third enrollment methods 38 and 46).
There are three examples of authentication methods (or paths) described in
After an MDR makes a request for data (e.g., using methods described below in connection with
Data Request Paths
Three examples of data request methods are shown in
Three examples of data path methods are shown in
In summary, it may be seen that the present invention may provide a system and method for providing conditional data delivery to remote devices, while allowing a service provider to maintain more control over where the streams of data are sent and other content protection issues.
It should be understood, of course, that the foregoing relates to exemplary embodiments of the invention and that modifications may be made without departing from the spirit and scope of the invention as set forth in the following claims.
Number | Name | Date | Kind |
---|---|---|---|
7167923 | Lo | Jan 2007 | B2 |
7340769 | Baugher | Apr 2008 | B2 |
7406079 | Yokomitsu et al. | Jul 2008 | B2 |
7500269 | Huotari et al. | Mar 2009 | B2 |
7533258 | Baugher | May 2009 | B2 |
7706263 | Zhou et al. | Apr 2010 | B2 |
7916740 | Zheng | Mar 2011 | B2 |
7941557 | Zhu et al. | May 2011 | B2 |
7954131 | Cholas et al. | May 2011 | B2 |
8001609 | Chan et al. | Aug 2011 | B1 |
8005988 | Maes | Aug 2011 | B2 |
8019883 | Margulis | Sep 2011 | B1 |
8051454 | Krikorian et al. | Nov 2011 | B2 |
8060909 | Krikorian et al. | Nov 2011 | B2 |
8068609 | Puranik et al. | Nov 2011 | B2 |
8112118 | Shieh et al. | Feb 2012 | B2 |
20020103850 | Moyer et al. | Aug 2002 | A1 |
20020191593 | O'Neill et al. | Dec 2002 | A1 |
20040218614 | Yokomitsu et al. | Nov 2004 | A1 |
20050232283 | Moyer et al. | Oct 2005 | A1 |
20060121916 | Aborn et al. | Jun 2006 | A1 |
20060156392 | Baugher | Jul 2006 | A1 |
20060156416 | Huotari et al. | Jul 2006 | A1 |
20060245403 | Kumar | Nov 2006 | A1 |
20060256800 | Harrington et al. | Nov 2006 | A1 |
20060270448 | Huotari et al. | Nov 2006 | A1 |
20070147391 | Wilhoite et al. | Jun 2007 | A1 |
20070281694 | Lin et al. | Dec 2007 | A1 |
20080057955 | Choi-Grogan | Mar 2008 | A1 |
20080137673 | Phuah et al. | Jun 2008 | A1 |
20080212495 | Stirbu | Sep 2008 | A1 |
20080275995 | Soliman et al. | Nov 2008 | A1 |
20090100492 | Hicks et al. | Apr 2009 | A1 |
20090207905 | Tomita | Aug 2009 | A1 |
20090271863 | Govindavajhala et al. | Oct 2009 | A1 |
20100106966 | Santos et al. | Apr 2010 | A1 |
20100172360 | Maes | Jul 2010 | A1 |
20100217837 | Ansari et al. | Aug 2010 | A1 |
20110002342 | Zheng | Jan 2011 | A1 |
20110061090 | Gillespie et al. | Mar 2011 | A1 |
20110099286 | Krikorian et al. | Apr 2011 | A1 |
20110265109 | Goyet et al. | Oct 2011 | A1 |
20110296481 | Cholas et al. | Dec 2011 | A1 |
20120011269 | Krikorian et al. | Jan 2012 | A1 |
20120028621 | Lazaridis | Feb 2012 | A1 |
20120036014 | Sunkada | Feb 2012 | A1 |
Number | Date | Country |
---|---|---|
2006074338 | Jul 2006 | WO |
2006074338 | Jul 2006 | WO |
2007050801 | May 2007 | WO |
Number | Date | Country | |
---|---|---|---|
20090254976 A1 | Oct 2009 | US |