Internet DRAFT - draft-dessez-homenet-googleplus-interconnect

draft-dessez-homenet-googleplus-interconnect






Internet Engineering Task Force                                C. Dessez
Internet-Draft                                             Cisco Systems
Intended status: Experimental                              July 16, 2013
Expires: January 17, 2014


       Connecting Home Networks via the social network GooglePlus
            draft-dessez-homenet-googleplus-interconnect-01

Abstract

   This document describes an experimental implementation for connecting
   home networks via a social network.  The social network is used to
   extend the boundary of a single home network to include other home
   networks.  In this way, access to devices or services within a home
   can be granted among home networks based on their relation to one
   another within the social network.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 17, 2014.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as



Dessez                  Expires January 17, 2014                [Page 1]

Internet-Draft       GooglePlus Homenet Interconnect           July 2013


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology and abreviations . . . . . . . . . . . . . . .  3
   2.  Defining the set of connected homes  . . . . . . . . . . . . .  4
   3.  Overall architecture . . . . . . . . . . . . . . . . . . . . .  5
   4.  Network architecture . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Managing the tunnels . . . . . . . . . . . . . . . . . . .  6
     4.2.  Configuring the network  . . . . . . . . . . . . . . . . .  7
   5.  Sharing services within your set of connected homes  . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  Experimental results . . . . . . . . . . . . . . . . . . . . . 10
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
     10.2. Informative References . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11






























Dessez                  Expires January 17, 2014                [Page 2]

Internet-Draft       GooglePlus Homenet Interconnect           July 2013


1.  Introduction

   The goal of this experiment is to allow an average home user to
   extend the boundaries of their home network to other home networks
   the user trusts.  Other home networks may be owned by a single user,
   or "friends" of the user as defined by a social network.  This
   document describes an overall architecture and specific mechanisms
   chosen for a working implementation based on the social network
   Google Plus.

   In each home, one router is responsible for interacting with the
   social network.  The home network is represented within the social
   network as a "Page" which the user owns.  The router is given
   credentials to interact with its representative Page, while the user
   defines the relationship of the Pages to one another.  When a
   bidirectional relationship between two home network Pages is
   detected, the information necessary to setup a tunnel is shared by
   posting it to the social network.  An encrypted tunnel is then setup
   between the homes, and a link established.

   IP reachability among linked homes is achieved by insertion and
   propagation of routes into a routing protocol running within the home
   network.  Services are then advertised among homes as defined in
   [I-D.cheshire-mdnsext-hybrid] and
   [I-D.stenberg-homenet-dnssdext-hybrid-proxy-ospf].  Finally, by
   connecting to a UI hosted by the specific router, the user can define
   policies for the services permitted to be shared within a given
   circle defined by the social network.

   The mechanisms described in the following sections assume a homenet
   environment as described in [I-D.ietf-homenet-arch] with with a
   routing protocol such as that defined in
   ([I-D.acee-ospf-ospfv3-autoconfig]) as well as the mechanism of
   prefix assignment defined in [I-D.arkko-homenet-prefix-assignment] .

1.1.  Terminology and abreviations

   In this section we define terminology and abbreviations used
   throughout the text.

   o  Homenet: a home network as defined in [I-D.ietf-homenet-arch]

   o  Gplus: Google Plus.  Google's social network.

   o  Gplus router: the router that is responsible for the connection to
      Google Plus, on which the mechanisms described in this document
      are hosted.




Dessez                  Expires January 17, 2014                [Page 3]

Internet-Draft       GooglePlus Homenet Interconnect           July 2013


   o  Circle: represents a group of people for which you can define
      confidentiality and visibility policies in Google Plus.

   o  Gplus ID: the unique internal identifier of an entity in Google
      Plus.  It apparently consists in a decimal number on the order of
      10^21 for users and pages accounts, and a 64-bit hexadecimal
      number for circles.

   o  DNS-SD: DNS-Based Service Discovery [RFC6763].

   o  ULA: IPv6 Unique Local Addresses [RFC4193].

   o  CA: Certificate Authority (as defined in X.509 [RFC3280]).

   o  CRT: an X.509 certificate ([RFC3280])

   o  CSR: Certificate Signing Request or Certificate Request
      ([RFC3280]).

   o  CPE: Customer Premises Equipment.


2.  Defining the set of connected homes

   The central idea of this experiment is for the homenet to be
   represented within the social network in a way that is intuitive to
   the user.  For this to happen, the homenet must be represented in a
   way such that:

   o  the homenet is clearly linked to its owner

   o  the user can manage the relationships of the homenet with other
      homenets linked to other users

   o  the network devices in the homenet can retrieve its social
      topology and setup communication with its related homenets

   If social networks were widely used for connecting homenets today,
   there may be some specific entity that a user could define that would
   clearly be identified as a home network.  This would be available for
   setting up connections to, based on the users policy and relationship
   to other users with homenets as part of their profile.  As that is
   not the case today among popular social networks such as Facebook and
   Google Plus, we looked into what might be the closest fit and decided
   to use Google Plus pages.  Intended mainly for brands and businesses,
   they are not very different from user accounts on a social point of
   view (they organize their contacts and what they see by the system of
   circles).  A user may have several pages, and a page may have several



Dessez                  Expires January 17, 2014                [Page 4]

Internet-Draft       GooglePlus Homenet Interconnect           July 2013


   administrators, each of them being able to easily log in as the page
   while connected to their regular Gplus account.

   In this implementation, the home router connects to Gplus to retrieve
   the topology and communicate with other routers using the Google
   Pages API.  This API uses OAuth 2.0 ([RFC6749]) to allow the user to
   delegate the management of pages to their Gplus router.

   In Gplus, the relationships between people and pages are ruled by the
   system of circles.  One can circle whoever they want in one or more
   of their circles, without it needing to be accepted by the latter.
   But in our case, we consider a tunnel must be created only if the
   relationship is bidirectional, that is only if they have both circled
   each other in at least one circle.  Notice that whereas one cannot
   know what are the circles of someone else, they know who has circled
   them, which is enough to know whether a relationship is
   bidirectional.  The Section 5 will explain in details how the
   visibility policies of DNS-SD services are directly linked to
   circles.

   As stated earlier, the router needs to send messages through Gplus in
   order to exchange the information necessary to establish and
   configure the tunnel.  This information can be divided into three
   categories: routing information, cryptographic keys and DNS-SD
   settings.  The routing information and the DNS-SD settings, which we
   will call Network Setttings, are gathered in a post that is regularly
   updated and visible to everyone in the page's circles.  This will be
   detailed in .  As for the posts conveying cryptographic keys, they
   will be described in Section 4.


3.  Overall architecture

   Figure 1 represents the global functional architecture of the
   implementation and shows the interactions between its different
   parts.

   The interaction with Gplus is handled by a module called
   GplusHandler.  It performs regular polling to update the social
   topoly in the database, and provides the TunnelsManager with
   functions which can send and retrieve messages or force an update of
   the database.

   The TunnelsManager is responsible for launching and maintaining the
   tunnels.  It also takes care of routing and network settings issues.

   A user interface enables the user to modify the service policies
   stored in the database.  Thus, they can be accessed by the



Dessez                  Expires January 17, 2014                [Page 5]

Internet-Draft       GooglePlus Homenet Interconnect           July 2013


   FirewallManager and the customized DNS server that filters DNS-SD
   requests accordingly.

                                +-------+
                                | Gplus |
                                +-------+
                                    |
                                    |
                            +--------------+   +----------------+
                            | GplusHandler |---| TunnelsManager |
                            +--------------+   +----------------+
                                    |         /
                                    |        /
         +------------------+       |       /
         | UI to define     |   +----------+    +-----------------+
         | service policies |---| Database |----| FirewallManager |
         +------------------+   +----------+    +-----------------+
                                    |          /
                                    |         /
                             +---------------+
                             |  DNS Server:  |
                             | DNS-SD filter |
                             +---------------+

                     Overall functional architecture.

                                 Figure 1


4.  Network architecture

4.1.  Managing the tunnels

   The tunnelling technology chosen for this experiment is OpenVPN with
   the cryptography library OpenSSL.

   In OpenVPN, one end has to be a server listening to the connections
   of clients, which in this case are the Gplus routers of the connected
   homenets.  A server might have several clients connected to the same
   network interface.  Notice it can be configured such as the clients
   connected to the same server cannot send packets to each other.
   Though there might be better ways to proceed, for this experiment the
   choice of being server or client is made by comparing the Gplus IDs
   of the connected pages.

   To set a tunnel with proper authentication of the other end, an
   architecture of OpenSSL certificates must be built.  A Certificate
   Authority (CA) is built and owned by the server which must sign



Dessez                  Expires January 17, 2014                [Page 6]

Internet-Draft       GooglePlus Homenet Interconnect           July 2013


   certificates to the clients.  The certificates contain the Common
   Names of they owners, which define the identity of the tunnel
   endpoints.  For this experiment, the Common Name of a router is its
   Gplus ID.  Since each Gplus router may potentially host at the same
   time a server and multiple clients, it creates a CA and a Certificate
   Request (CSR).  Then it publishes in Gplus a post (here called
   Security Settings) containing the certificate (CRT) of its CA and its
   CSR and makes it visible by all its circles.  Therefore, when a new
   relationship appears in the social network, the server retrieves the
   client's CSR, signs it with the key of its CA and sends it back with
   a restricted visibility to the client.  As for the client, it
   retrieves the CRT of the server's CA and its signed CRT.  Notice
   there is no cryptography key sent on the social network, which is
   otherwise a secure channel to exchange the CAs and CSRs.

   Concerning contact addresses, the Gplus router must have a globally
   reachable IP address whether IPv4 (for example being the CPE) or
   preferably IPv6.  This/these addresse(s) are advertised in the
   Network Settings post which is published at boot time and regularly
   updated, and visible by all the circles of the homenet.

4.2.  Configuring the network

   In order to enable reachability of the devices of a connected homenet
   via the tunnel between them, routes must be configured.  For reasons
   explained in Section 6, instead of injecting routes to the globally
   routable prefixes of the connected homenets, the described design
   makes the Gplus routers generate and asign ULA prefixes and only
   those are advertised.

   In order to reduce the odds of collision, the ULA prefix is generated
   by the Gplus router following the following schema:

                  |  8 bits      |  40 bits              |
                  +--------------+-----------------------+
                  |  FD00::/8    |   Global ID           |
                  +--------------+-----------------------+

      Global ID =  f( hash( timestamp + GplusID ) )

   With:

      f          A function that take only the 40 last bits of its
                 argument







Dessez                  Expires January 17, 2014                [Page 7]

Internet-Draft       GooglePlus Homenet Interconnect           July 2013


      hash       A hashing function (SHA1 for this experiment)

      timestamp  A string containing the current UNIX timestamp

      GplusID    The homenet's Gplus ID

      +          The string concatenation operation


   Once generated, the prefix is delegated to the homenet and /64 are
   assigned as specified in [I-D.arkko-homenet-prefix-assignment].

   On the other ends of tunnels, the ULA prefix for this homenet is
   retrieved from the Network Settings post in Gplus and advertised
   through the connected homenets by injecting AS-External-LSAs in
   OSPFv3.

   In case there are other ULA prefixes assigned in the homenet, they
   should also be advertised and routed to the connected homenets.
   Otherwise the Default Address Selection mechanism for IPv6 specified
   in [RFC3484] will lead to an unpredictable behaviour as the source
   addressed chosen by a host to communicate over the tunnel might not
   be in the prefix advertised on Gplus and then would not be routed at
   the other end.  But having other ULA prefixes is non-desirable since
   it increases the odds of prefix collision.  In our implementation, we
   assume there is no other ULA prefix assigned in the homenet.

   Though we strive to avoid collisions while generating the ULA
   prefixes, the current design assumes there is no collision and does
   not treat such a case.  Collisions might appear in two situations:
   either a Gplus router chooses the same prefix as one of its connected
   routers, or a Gplus router has two connected routers that have the
   same prefix.  The best solution for this is left for further study.


5.  Sharing services within your set of connected homes

   Connecting homenets would be pointless without any service discovery
   mechanism.  The aim is to allow a host to query services in connected
   homenets, and to let only the authorized services appear in the
   responses.

   Inside a single home, automatic service discovery is enabled by the
   hybrid DNS-SD proxy mechanism specified in
   [I-D.stenberg-homenet-dnssdext-hybrid-proxy-ospf].  The following
   design assumes this running on all routers of the homenet and mostly
   relies on it to enable service discovery over multiple homes.




Dessez                  Expires January 17, 2014                [Page 8]

Internet-Draft       GooglePlus Homenet Interconnect           July 2013


   Connected homenets must have distinct domain names.  Each homenet
   must either have a domain name that is owned by their administrator
   or generate a local one.  In case of automatic generation we again
   have a problem of collisions and use Gplus IDs to make them the most
   unlikely possible.  In order to make to it a minimum human-friendly
   too, the formatted display name of the associated Gplus page is put
   at the beginning, concatenated with an hyphen, 10 hexadecimal digits
   corresponding to the Global ID of the ULA prefix (Section 4.2) and
   the TLD.  A generic TLD for homes might be defined in the future,
   though for this experiment we use ".test.".

   To advertise this domain name across the homenet, the Gplus router
   advertises a Domain Name TLV.

   To make hosts browse other homenets zones, a DNS Delegated Zone TLV
   must be advertise for each one of them.  The S bit must be set to 0
   because those zones are not full DNS-SD domains, and the B bit set to
   1 so that they are recommended for browsing at b._dns-
   sd._udp.(domain).  For each one, the domain name and authoritative
   DNS server address (a ULA address of the Gplus router) are retrieved
   from the Network Settings post published in Gplus.

   Thus, the Gplus router's DNS server receives from other homes all
   DNS-SD queries for its home's domain name.  Responses are filtered
   based on the source ULA address and the services authorized to the
   corresponding home.  Notice also that A records and AAAA records that
   do not point to ULA addresses are dropped.  A service is authorized
   if and only if a policy of one of the circles in which this home is
   allows it.  For this experiment, a policy is defined as an authorized
   DNS-SD type of service (e.g. _http._tcp) associated to a circle, but
   finer granularity might be implemented (which adds complexity because
   of hosts changing DNS zones or name).


6.  Security Considerations

   The goal of the experiment is to allow homes to reach one another
   more easily than reaching the whole of the internet.  Doing so, the
   boundaries of the homenet are redrawn to include multiple homes,
   which brings up security issues.  DNS requests and most common
   services' connections are not encrypted, which motivates the
   enforcement of a secure channel between homes.  Besides, tunnels also
   provide identity of the incoming packets.

   Injecting global prefixes in other homes might be a way to advertise
   larger prefixes than those actually owned (e.g. advertising a /48
   while only having a /56).  Of course we could limit the size of
   advertised prefixes but this is not enough.  One could imagine a PKI



Dessez                  Expires January 17, 2014                [Page 9]

Internet-Draft       GooglePlus Homenet Interconnect           July 2013


   verification system but this would assume support from ISPs which is
   not currently offered.  Using ULA prefixes mitigates this issue
   though it adds some others (already described in Section 4.2).

   Still, defining firewall rules is probably the toughest security
   concern.  First, to prevent spoofing, only packets with source and
   destination addresses in the expected ULA prefixes are allowed.  Even
   though the firewall of OpenVPN servers is not able to know for sure
   which connected client has sent a packet as an IP address might be
   spoofed, potential harm is very limited because it will not receive
   any packet back.
   Second, relying on unability to discover unauthorized services via
   DNS-SD is not sufficient, hence the need to accept only traffic
   corresponding to authorized services.  This is a non-trivial general
   issue since a service cannot be reduced to a contact port and IP
   address tuple.  This issue is left for further study.


7.  Experimental results

   TBD


8.  IANA Considerations

   This document contains no request to IANA.


9.  Acknowledgements

   The author would like to thank Mark Townsley, Alain Fiocco, Ole Troan
   and Markus Stenberg for valuable mentoring of the project, as well as
   Pierre-Alain Dupont, Nicolas Iooss, Maico Le Pape and Guillaume
   Mulocher for high contribution in the design and implementation of
   the prototype.


10.  References

10.1.  Normative References

   [I-D.acee-ospf-ospfv3-autoconfig]
              Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration",
              draft-acee-ospf-ospfv3-autoconfig-03 (work in progress),
              July 2012.

   [I-D.arkko-homenet-prefix-assignment]
              Arkko, J., Lindem, A., and B. Paterson, "Prefix Assignment



Dessez                  Expires January 17, 2014               [Page 10]

Internet-Draft       GooglePlus Homenet Interconnect           July 2013


              in a Home Network",
              draft-arkko-homenet-prefix-assignment-04 (work in
              progress), May 2013.

   [I-D.cheshire-mdnsext-hybrid]
              Cheshire, S., "Hybrid Unicast/Multicast DNS-Based Service
              Discovery", draft-cheshire-mdnsext-hybrid-02 (work in
              progress), July 2013.

   [I-D.ietf-homenet-arch]
              Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
              "Home Networking Architecture for IPv6",
              draft-ietf-homenet-arch-09 (work in progress), July 2013.

   [I-D.stenberg-homenet-dnssdext-hybrid-proxy-ospf]
              Stenberg, M., "Hybrid Unicast/Multicast DNS-Based Service
              Discovery Auto-Configuration Using OSPFv3",
              draft-stenberg-homenet-dnssdext-hybrid-proxy-ospf-00 (work
              in progress), June 2013.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3280]  Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              April 2002.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, October 2005.

   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework",
              RFC 6749, October 2012.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, February 2013.

10.2.  Informative References

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.










Dessez                  Expires January 17, 2014               [Page 11]

Internet-Draft       GooglePlus Homenet Interconnect           July 2013


Author's Address

   Cedric Dessez
   Cisco Systems
   Paris,
   France

   Email: cedric@dessez.fr











































Dessez                  Expires January 17, 2014               [Page 12]