Re: [WARP] Extending access to local network resources

On 21 Jan 2010, at 07:18, Arve Bersvendsen wrote:
> On Thu, 14 Jan 2010 19:04:18 +0100, Stephen Jolly <stephen.jolly@rd.bbc.co.uk> wrote:
>> Anyway, the specific proposal I would like to make is for another special value of the "origin" attribute of the "access" element in the widget configuration document called "link-local" or similar, an associated special value in the access-request list and an associated processing rule that says that when the "link-local" value is specified, the user agent should grant access to network resources on the same subnet(s) as the user agent.
> 
> Just so we are on the same page here, by link-local, you mean exactly what (for IPv4) is defined in RFC 3927, which roughly translates to «Two devices connected directly, without involvment of DHCP» - a.k.a. 169.254.0.0/16?

RFC 3927 defines a set of IPv4 addesses that are guaranteed to be either unreachable or assigned to other hosts on the local link.  Such hosts may have other addresses though, so I'm defining "link-local" to *any* address on "the local subnet(s)".  I believe that a user agent can determine this straightforwardly (by resolving the hostname in the requested resource's URL and comparing the routing prefix of the resulting IP address to the routing prefixes of the IP addresses of the host on which the user agent is running, be they IPv4 or IPv6 addresses).

Clearly the fact that a host can be connected to multiple networks, consecutively or simultaneously, needs to be taken into account when the policy and user interface for granting network access are implemented, as does the fact that some "local" networks can contain a large number of untrusted third parties: public WiFi hotspots or mobile data networks, for example.

>> 4. Clearly the "local network" and the "local link" are not necessarily the same thing.  I'm proposing a solution targeting the latter because (a) it actually has a useful definition and (b) I believe it to be sufficient for the use cases I care about.
> 
> Provided my understanding of link-local is in line with yours, I would prefer a mechanism for accessing the local network.
> 
>> I look forward to your comments and criticisms - in particular I would like to understand the holes that Arve says are opened by making a distinction between "local" and "remote" IP addresses.
> 
> To moderate my statement a bit - it's more a concern than a risk, when you at all allow access to "local network", and you have relaxed cross-domain security, a maliciously crafted widget can potentially attack local networking equipment such as routers. (This risk also exists on the web, but is generally less practical, given that an attacker would be shooting blind due to the same-origin-policy)

I agree that "link-local" security would not protect local network resources from maliciously crafted widgets, but I think that's unavoidable.  In this particular respect defining a "link-local" set of origins offers no additional security over simply using <access origin="*"/>, I agree.  However, there are other respects in which additional security is provided (eg the user gains some control over the origins with which potentially private information can be shared), and there are other advantages (eg the user can be moderately confident that a video streaming application is only going to stream from the local network, rather than an expensive connection between the local network and the Internet).

> The other problem is one of the definition of local network not being entirely clear - the archetypal definition is the IPv4 one with four reserved IP ranges.  That definition breaks for IPv6, and it breaks for networks not using NAT.  In order to have a useful definition, the network would have to provide information about the locality of any given host a widget tries to access.

I believe that the Unique Local Addresses defined by RFC 4193 are the IPv6 equivalent to the reserved "private network" ranges in IPv4.  It might therefore be possible to define a set of "non-globally-routable" addresses for IPv4 and IPv6 similar to your definition of IPv4 private networks for Opera widgets (http://dev.opera.com/articles/view/opera-widgets-specification-fourth-ed/#private_network), but I think that a "link-local" restriction is a better match to my use cases.

S

Received on Thursday, 21 January 2010 11:46:23 UTC