Autonomic Networking Use Case for Home Networks
draft-carpenter-nmrg-homenet-an-use-case-00

Abstract

This document describes a use case for autonomic networking in home network scenarios. It is one of a series of use cases intended to illustrate requirements for autonomic networking.

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 October 11, 2014.

Copyright Notice

Copyright (c) 2014 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 described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Problem Statement
• 3. Intended User and Administrator Experience
• 4. Analysis of Parameters and Information Involved
• 4.1. Parameters each device can decide for itself
• 4.2. Information needed from policy intent
• 5. Interaction with other devices
• 5.1. Information needed from neighbor devices
• 5.2. Monitoring, diagnostics and reporting
• 6. Comparison with current solutions
• 7. Security Considerations
• 8. IANA Considerations
• 9. Acknowledgements
• 10. Change log [RFC Editor: Please remove]
• 11. References
• Author's Address

1. Introduction

This document is one of a set of use cases being developed to clarify the requirements for discovery and negotiation protocols for autonomic networking (AN). The background to AN is described in [I-D.irtf-nmrg-autonomic-network-definitions] and [I-D.irtf-nmrg-an-gap-analysis]. A problem statement and outline requirements for the negotiation protocol are given in [I-D.jiang-config-negotiation-ps].

Note in draft: This version is preliminary. Its format may be modified as we agree on a common format for AN use cases. In particular, opinions may vary about how concrete vs how abstract a use case should be.

2. Problem Statement

The use case considered here is autonomic operation of home networks based on IPv6, in general accordance with [I-D.ietf-homenet-arch]. The model assumes that a typical homenet in the future will have multiple network segments, several routers, and a reasonably large number of hosts, but no expert human manager. For routing configuration, a dedicated protocol solution known as HNCP (homenet configuration protocol) has been designed and implemented [I-D.stenberg-homenet-hncp]. A solution has also been described for bootstrapping trust in a homenet [I-D.behringer-homenet-trust-bootstrap].

Additional issues that impact homenet configuration are discussed in [I-D.winters-homenet-sper-interaction], [I-D.pfister-homenet-prefix-assignment], [I-D.mglt-homenet-naming-architecture-dhc-options] and [I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf].

The problem to be solved by AN is how to replace these and other partial solutions by a complete solution that sets all necessary parameters for the homenet to operate efficiently, reliably and securely, with minimal human intervention and without the need for traditional top-down configuration.

3. Intended User and Administrator Experience

In a homenet, the basic assumption is that no human involved has technical knowledge beyond the ability to unwrap a product, connect a few cables, and follow simple instructions. Indeed, the parody "Did you try switching it off and on again?" may apply literally. Therefore, the desired user experience is that everything just works, that there are no mandatory user actions, and that no specialist knowledge is needed. If any user choices are offered, there must be a reasonable default. When power failures or equipment failures occur, recovery to the best possible running state must be automatic. If any diagnostic messages are produced, they must be simple and clear, and of course provided in the user's own language. If any logs are recorded, it is to be expected that the normal user will never look at them and could not understand them.

4. Analysis of Parameters and Information Involved

Numerous parameters are involved in a homenet (some of them can of course be pre-configured with default values). They include:

• Identity of a trust anchor to act as a local certification authority (CA) and registration authority (RA) for nodes inside the homenet.
• Firewall rules (for border devices and for host firewalls).
• IP address prefix for the whole homenet.
• Individual prefixes for each subnet.
• Initial configuration of all routers.
• Default router for each subnet.
• Rules for address selection.
• Local namespace.
• DNS server(s).

4.1. Parameters each device can decide for itself

This section identifies those of the above parameters that do not need external information in order for the devices concerned to set them to a reasonable value after bootstrap or after a network disruption. There are few of these:

• Default firewall rules for hosts. Hosts should be shipped from the manufacturer with generally applicable default firewall rules.
• Default rules for address selection should conform to [RFC6724].

4.2. Information needed from policy intent

This section identifies those parameters that need external information about policy intent in order for the devices concerned to set them. to a non-default value. It's assumed that in a homenet, policy intent will likely be provided by the main homenet router, and may itself be a default setting in that router, since there is normally no human expert to set policy. Not all devices will need to know all of these intents.

• Method of determining the trust anchor.
• Whether firewall rules will be changed from their default settings.
• Whether more than one GUA prefix will be deployed.
• Whether a ULA prefix will be deployed.
• Which routing protocol is preferred.
• Whether DHCPv6 will be deployed.
• Whether non-default rules for address selection will be deployed.
• Whether IPv4 and DHCP will be deployed (IPv6 is assumed).

5. Interaction with other devices

5.1. Information needed from neighbor devices

This section identifies those of the above parameters that need external information from neighbor devices (such as other routers) in order for the devices concerned to set them. In many cases, two-way dialogue with neighbor devices is needed to set or optimise them.

• Identity of a trust anchor.
• Routers will need to discover their neighbors.
• Routers will need to determine whether they are border devices.
• Border routers will need to apply a default border firewall policy; interior routers will not be firewalls by default.
• Hosts may need to acquire a non-default firewall policy.
• Border routers will need to determine the IP address prefix(es) for the whole homenet.
• One border router will need to generate the ULA prefix for the whole homenet.
• Routers will need to discover the network topology and then to apply a prefix delegation method to deliver at least one prefix to each subnet.
• With knowledge of its neighbors and after prefix delegation, each router will need to configure and launch the agreed routing protocol.
• Hosts need to acquire a default router for each interface.
• Hosts may need to acquire non-default rules for address selection.
• The local namespace service must configure itself. This is a complex topic, so the reader is referred to drafts that already describe the needed functions: [I-D.mglt-homenet-naming-architecture-dhc-options] and [I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf].
• Hosts need to acquire DNS server address(es).

5.2. Monitoring, diagnostics and reporting

This section discusses what role devices should play in monitoring, fault diagnosis, and reporting.

• In general, failure to successfully set reasonable values for any network parameter should be logged and notified to the user, in simple, non-technical words in the user's own language.
• Similarly, hard failures should be logged and notified, even if the network has somehow routed around them.
• Users are very unlikely to take an interest in warnings of any kind, so they are probably a waste of time.
• Firewall incidents are typically logged in a proprietary fashion. It would be conceivable for all firewalls in a homenet to log incidents centrally but it seems unlikely that such a feature would ever be used by a typical home user.

6. Comparison with current solutions

This section briefly compares the above use case with current solutions. Today's typical single-router homenets do largely run without significant human intervention, relying on fixed DHCP setups for IPv4 and on out-of-the-box Router Advertisements for IPv6. This comparison is not very illuminating, since we are interested in complex homenets with multiple routers. A better comparison is with the emerging prototype homenet environment based on the various drafts cited in Section 2. The functionality described is very similar. The actual content of the messages would also be very similar to those in HNCP etc. However, using a generic autonomic discovery and negotiation protocol instead of specific solutions (such as HNCP, which is dedicated to routing issues) has the advantage that additional parameters can be included in the autonomic solution without creating new mechanisms. This is the principal argument for a generic approach.

7. Security Considerations

Relevant security issues are discussed in [I-D.irtf-nmrg-autonomic-network-definitions], [I-D.jiang-config-negotiation-ps] and [I-D.ietf-homenet-arch]. The security specificity of a homenet is the need to establish a trust anchor in the absence of a human expert, which will allow remaining security features to configure themselves autonomically.

8. IANA Considerations

This document requests no action by IANA.

9. Acknowledgements

Valuable comments were received from Michael Behringer, Sheng Jiang and ...

This document was produced using the xml2rfc tool [RFC2629].

10. Change log [RFC Editor: Please remove]

draft-carpenter-nmrg-homenet-an-use-case-00: original version, 2014-04-10.

11. References

Author's Address