The Internet Protocol Journal, Volume 14, No. 4

Networking @ Home

Geoff Huston, APNIC

One of the more interesting sessions at the Internet Engineering Task Force (IETF) meeting in Quebec City in July 2011 was the first meeting of the recently established Homenet Working Group [1]. What is so interesting about networking the home? Well, if you regard challenges as "interesting," then just about everything is interesting when you look at networking in the home!

It has been a very long time since the state of the art in home Internet involved plugging the serial port of the PC into the dialup modem. The Asymmetric Digital Subscriber Line (ADSL) modem, even when combined with some form of Wi-Fi base station, is looking distinctly passé these days. Today, the home network is seeing the intersection of a whole set of interests, including phone service, television service, home security services, energy management, utility service metering, other forms of home device monitoring, and, of course, connecting laptops and mobile devices to the net. The home network is not just a wired Local-Area Network (LAN), Wi-Fi home networks are commonplace, and there are also various Bluetooth devices. Maybe sometime soon it will be common for the home network to host some form of Third-Generation (3G) femtocell mobile cell phone repeater as well. But these days even that level of network complexity is not enough. Increasingly, the home office is part of the work office, and if numerous residents are at home, then the home network may be an endpoint for several corporate and institutional Virtual Private Networks (VPNs) [2].

Within the home network we want sophisticated security. This security involves not just protecting the network from the neighbors; the security requirements include the ability for individuals to partition off their work-VPN part of the home network from other home users. For resiliency we might want a second network provider, so we might want to add site-based multihoming to the mix. And we need to make all this work for both IPv4 and IPv6.

That set of requirements represents a massive agenda. But to make this situation truly challenging, we cannot expect every home to come with an IT Operational Service Manager to ensure that all the various devices you bring into the home and connect to the network function as required for the particular requirements of the home. Indeed, we cannot expect any home to be so lavishly supported, nor can we afford to support home networking with a bevy of specialized call centers with on-demand support specialists, expert in the panoply of consumer devices that are being sold today.

With today's home networks, consumers are effectively on their own; and all this equipment better just work straight out of the box. No configuration, no buttons, it just has to work!

Routing @ Home

The evolution of networking at home has progressed from a single computer to a basic LAN, and from there to an Ethernet-bridged network with numerous Wi-Fi and wired LAN segments. All these environments have a single common architecture with a single "boundary" unit that acts as a point of demarcation between the Internet Service Provider (ISP) and the home network. This unit is generally called Customer Premises Equipment (CPE), and typically encompasses the functions of a modem; an IPv4 Network Address Translator (NAT); a Dynamic Host Configuration Protocol (DHCP) server for both IPv4 and IPv6; as well as security firewall, bridge, and rudimentary router functions.

But it is unrealistic to assume that home networks will continue to use a centralized model that places all of the management functions of the home network in a single unit. So how should we view home networks? Should home networks be a single bridged LAN, or are we seeing the evolution of home networks into multiple distinct domains with a routing fabric to glue them together? And if that is the case, what routing protocol should be used?

I have noticed in the low end of the CPE market it is not uncommon to see a rudimentary routing function supported by the Routing Information Protocol (RIP) [3]. Thankfully, it is RIP Version 2, so the routing protocol can be configured with variable-length subnet masks, but even so, RIP is a very basic and simple routing protocol. But perhaps in this environment, that might be a positive factor rather than a liability in so far as RIP is simple enough to be auto-configurable. On the other hand, if there is an emergent need for more complex functions, then maybe we need to look a little harder at the available options. One of these more complex functions is subnet management. In IPv6, the CPE will collect an IPv6 address prefix. This process differs from the conventional IPv4 environment where the CPE is typically assigned a single IPv4 address. So the ensuing question is: Is it possible to automate the distribution of IPv6 subnets across the entire home network? What form of management protocol is appropriate for this role?

Of course the situation gets much more complicated if the home network has two (or more) service providers. In the IPv6 environment, this task becomes a challenging one, not only with the distribution of multiple subnets across the home network, but also in the matter of exit path selection. If the home network is exercising due diligence to prevent source address spoofing, it is also necessary for the home routing infrastructure to deliver an outgoing packet to the "right" exit ISP, where the source address of the outgoing packet needs to match the address prefix provided by the corresponding ISP service. In other words, there is a requirement for source address routing in the home.

This challenge was not really addressed by the Site Multi-Homing by IPv6 Intermediation Working Group (SHIM6) [4], despite the best of intentions, and it represents an even greater challenge if the intent is to provide mechanisms that can achieve such routing in an unmanaged home network environment.

I must admit to some concern here. We have managed to keep Internet routing working by using two principles. The first is to try to keep the routing task as simple as possible. Routing propagates a single "best" path to a destination. It does not necessarily do this propagation quickly, nor necessarily does it carry around with it a whole set of alternatives. It does just one job. The second principle is to admit that we have never really succeeded with the first principle of functional simplicity and we have always had expertise at hand to oversee the routing function and apply manual patches as required. The specialized requirements for the home network appear to be breaking both principles. The requirements are certainly not simple, and I see a mix of routing techniques—including various forms of policy-based routing requirements—entering the discussion. Secondly, there is no assurance that if things fail expertise is at hand to mend the failure. Indeed, the more complex the routing environment, the greater the potential for complex forms of failure. As we contemplate ever more complex requirements in the home network, we face a greater risk of encountering failure "by design," where it is just not possible to design products for this environment that will "just work."

Names @ Home

What should I call my printer? More to the point, how should I identify my Wi-Fi printer to all those devices at home that want to use it to print? I am sure that I would not like to use a proprietary naming scheme that requires me to add additional name resolution software to every device at home that wants to print something, nor do I want to transcribe IP addresses into everything. I would like my printer to get dynamically assigned IPv4 and IPv6 addresses when the device is plugged in and switched on, and have the name of the printer published via a generic name resolution mechanism, namely the Domain Name System (DNS).

But most of the time the rest of the world has no need to know the name of my printer at home, and I am not sure that it is a good move, securitywise, to gratuitously publish information in the public DNS. So what I would like for my printer is some form of "local" or "scoped" DNS, where I can name my printers, my disk servers, and other devices that I have at home in the context of my home and not have this information leak further afield. Is this scoped form of name resolution, split horizon DNS, or split views, possible in the context of the DNS without invoking further elements of configuration management?

Multicast DNS (mDNS) is perhaps one of the strongest candidates for this role. In essence, mDNS replaces the explicit client-server structure of the DNS with a scoped name subdomain of .local that is inherently scoped to the associated multicast domain.

This setup allows a client to perform DNS-like name resolution functions on a local network without the need to configure a conventional DNS server environment, and without the need to obtain global delegation of a site name in the global DNS.

An alternative approach is to use a conventional DNS delegation and conventional unicast DNS queries and responses. Clients are able to use DNS Dynamic Updates [5] to provide the local DNS server with their details as they come online. This approach requires either open access from anyone to the nameserver or a security mechanism such as Transaction SIGnature (TSIG) [6]. TSIG generally requires manual configuration, and alternatives are either little used—such as Transaction KEY (TKEY) [7]—or involve further intricacies, such as Microsoft's Active Directory, which uses other user authentication mechanisms to bootstrap the TSIG part using the Generic Security Service Algorithm for Secret Key Transaction (GSS-TSIG)[8]. The DNS server itself can be advertised to all clients via the Simple Service Discovery Protocol (SSDP), as part of the larger Universal Plug and Play (UPnP) framework.

Sensing and Serving @ Home

Where to go from here? It is certainly the case that electronics has managed to pervade just about every device at home. Electricity meters are morphing into household energy-management systems, and many other household appliances are now controlled by internal processors. But individually configuring each of these devices is a forbidding task. Even adding an interface to allow manual configuration can often be a challenging objective.

The objective here is to define a standard mechanism to allow sensors to sense their local environment when powered up, obtain an IP address, advertise their existence and capabilities to the network, and, as appropriate, rendezvous with the sensor controller or controllers across the home network.

This example is another instance of a more generic class of automating the installation and use of services in "lightly" managed or even unmanaged networks, and it intersects significantly with the objectives encompassed with SSDP and UPnP. The potential volume of such devices places this example more squarely into a class of IPv6-only services, I suspect, which is a significant extension to the existing IPv4-centric UPnP frameworks.

What is needed is a bootstrap protocol that can provide a connecting device with:

  • Address configuration
  • Routing setup
  • Name management and name server discovery
  • Discovery of other services and controllers
  • Security capabilities

Security @ Home

One of the most significant concerns with home networks lies in the area of security management. Host computers in a home network often want to place a very high level of implicit trust in their immediate network neighbors at the same home. It is not unusual for hosts in a home network to share printers, file servers, data, and even user profiles. Indeed, it is probably commonplace. But beyond this local security domain a host should become paranoid and treat all connection attempts with suspicion. But where does the local trust domain start and stop? What is the "local" security boundary?

This question is difficult to answer in an automated fashion. It is no longer the local LAN, particularly as home networks transition into routed networks. The security boundary is related to the local multicast scope, but this supposition assumes that it is possible to define a multicast scope that encompasses the local trust domain of the home network, and this assumption brings us back to the same question.

Even if you thought you might have a clean answer to the boundary question, you need to remind yourself about telecommuting. With telecommuting, there is a requirement to partition out an entire local network segment from the rest of the home environment and the home security domain and transplant it into the work security domain.

Everything @ Home

Home is certainly the new field of engagement for networked goods and services. However, it is one of the most challenging places to operate in from the perspective of attempting to deliver coherent services in a reliable and secure manner. The components are sourced from various vendors, and constructed incrementally over extended periods of time. It is an environment where older components need to coexist with new devices, and the overall engineering of the environment is at best piecemeal, and perhaps more often not engineered at all. In this environment out-of-the-box interoperability is of paramount importance, and therefore it is an environment where good standards really matter. Perhaps unsurprisingly, given these constraints, networking in the home is one of the environments that appear to raise the most challenges. It is an unforgiving environment where there is no real substitute for simplicity and reliability in a "plug-and-play" world.

The IETF Homenet Working Group has a lot of work to do. The Working Group will have to examine the diverse set of approaches in use today, add IPv6 functions, and produce a coherent set of outcomes in the form of standards that support robust, capable home networks that work in an unmanaged environment.

Ahhh home! There really is no place quite like it!

References

[1] Homenet Working Group: http://www.ietf.org/dyn/wg/charter/homenet-charter

[2] Paul Ferguson and Geoff Huston, "What Is a VPN?" (Part 1 and Part 2), The Internet Protocol Journal, Volume 1, No. 1 and No. 2, June and September 1998.

[3] Gary Malkin, "RIP Version 2," RFC 2453, November 1998.

[4] Shim6 Working Group (concluded) http://wiki.tools.ietf.org/wg/shim6/charters

[5] Paul Vixie, ed., Yakov Rekhter, Susan Thomson, and Jim Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)," RFC 2136, December 1997.

[6] Paul Vixie, Olafur Gudmundsson, Donald E. Eastlake 3rd, and Brian Wellington, “Secret Key Transaction Authentication for DNS (TSIG),” RFC 2845, May 2000.

[7] Donald E. Eastlake 3rd, "Secret Key Establishment for DNS (TKEY RR)," RFC 2930, September 2000.

[8] Stuart Kwan, Praerit Garg, James Gilroy, Levon Esibov, Randy Hall, and Jeff Westhead, "Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)," RFC 3645, October 2003.

GEOFF HUSTON, B.Sc., M.Sc., is the Chief Scientist at APNIC, the Regional Internet Registry serving the Asia Pacific region. He has been closely involved with the development of the Internet for many years, particularly within Australia, where he was responsible for the initial build of the Internet within the Australian academic and research sector. He is author of numerous Internet-related books, and was a member of the Internet Architecture Board from 1999 until 2005; he served on the Board of Trustees of the Internet Society from 1992 until 2001. E-mail: gih@apnic.net