[Search] [txt|xml|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
UCAN BOF                                                    B. Carpenter
Internet-Draft                                         Univ. of Auckland
Intended status: Informational                              May 19, 2014
Expires: November 20, 2014


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

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 November 20, 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.





Carpenter               Expires November 20, 2014               [Page 1]


Internet-Draft             Homenet AN Use Case                  May 2014


Table of Contents

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

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: The format of this document 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 some aspects of
   homenet configuration, a protocol solution known as HNCP (homenet
   control protocol) has been designed and implemented
   [I-D.ietf-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],



Carpenter               Expires November 20, 2014               [Page 2]


Internet-Draft             Homenet AN Use Case                  May 2014


   [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 generic 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.

   It should be noted that HNCP has a quite generic design, but so far
   has been described for a fairly narrow scope of application, and
   other aspects of homenet bootstrapping, discovery and configuration
   are currently handled by other methods.  The present draft takes no
   position on these various solutions, since its goal is only to
   describe the use case.

   This use case does not currently consider the challenges posed by
   multiple provisioning domains as defined by [I-D.ietf-mif-mpvd-arch].

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 "Have
   you tried turning 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:

   o  Identity of a trust anchor to act as a local certification
      authority (CA) and registration authority (RA) for nodes inside
      the homenet.

   o  Identity of border devices (equivalent to perimeter
      identification).




Carpenter               Expires November 20, 2014               [Page 3]


Internet-Draft             Homenet AN Use Case                  May 2014


   o  Firewall rules (for border devices and for host firewalls).

   o  IP address prefix(es) for the whole homenet.

   o  Individual prefix(es) for each subnet.

   o  Choice of routing protocol.

   o  Initial configuration of all routers.

   o  Default router for each subnet.

   o  Rules for address selection.

   o  Local namespace information (delegated zone if any, etc.).

   o  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:

   o  Default firewall rules for hosts.  Hosts should be shipped from
      the manufacturer with generally applicable default firewall rules.

   o  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.

   o  Method of determining the trust anchor.

   o  Whether firewall rules will be changed from their default
      settings.

   o  Whether more than one GUA prefix will be deployed.

   o  Whether a ULA prefix will be deployed.



Carpenter               Expires November 20, 2014               [Page 4]


Internet-Draft             Homenet AN Use Case                  May 2014


   o  Which routing protocol is preferred.

   o  Whether DHCPv6 will be deployed.

   o  Whether non-default rules for address selection will be deployed.

   o  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.

   o  Identity of a trust anchor.

   o  Routers will need to discover their neighbors.

   o  Routers will need to determine whether they are border devices.

   o  Border routers will need to apply a default border firewall
      policy; interior routers will not be firewalls by default.

   o  Hosts may need to acquire a non-default firewall policy.

   o  Border routers will need to determine the IP address prefix(es)
      for the whole homenet.

   o  One border router will need to generate the ULA prefix for the
      whole homenet.

   o  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.

   o  With knowledge of its neighbors and after prefix delegation, each
      router will need to configure and launch the agreed routing
      protocol.

   o  Hosts need to acquire a default router for each interface.

   o  Hosts may need to acquire non-default rules for address selection.

   o  The local namespace service must configure itself.  Relevant
      devices will need to know at least the zone name delegated to the



Carpenter               Expires November 20, 2014               [Page 5]


Internet-Draft             Homenet AN Use Case                  May 2014


      homenet.  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].

   o  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.

   o  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.

   o  Similarly, hard failures should be logged and notified, even if
      the network has somehow routed around them.

   o  Users are very unlikely to take an interest in warnings of any
      kind, so they are probably a waste of time.

   o  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 a mixture of dedicated
   solutions 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.








Carpenter               Expires November 20, 2014               [Page 6]


Internet-Draft             Homenet AN Use Case                  May 2014


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 Steven Barth, Michael Behringer,
   Sheng Jiang, Mark Townsley, and others.

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

10.  Change log [RFC Editor: Please remove]

   draft-carpenter-nmrg-homenet-an-use-case-01: clarifications, more
   accurate characterisation of HNCP, 2014-05-19.

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

11.  References

   [I-D.behringer-homenet-trust-bootstrap]
              Behringer, M., Pritikin, M., and S. Bjarnason,
              "Bootstrapping Trust on a Homenet", draft-behringer-
              homenet-trust-bootstrap-02 (work in progress), February
              2014.

   [I-D.ietf-homenet-arch]
              Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
              "IPv6 Home Networking Architecture Principles", draft-
              ietf-homenet-arch-13 (work in progress), March 2014.

   [I-D.ietf-homenet-hncp]
              Stenberg, M. and S. Barth, "Home Networking Control
              Protocol", draft-ietf-homenet-hncp-00 (work in progress),
              April 2014.






Carpenter               Expires November 20, 2014               [Page 7]


Internet-Draft             Homenet AN Use Case                  May 2014


   [I-D.ietf-mif-mpvd-arch]
              Anipko, D., "Multiple Provisioning Domain Architecture",
              draft-ietf-mif-mpvd-arch-01 (work in progress), May 2014.

   [I-D.irtf-nmrg-an-gap-analysis]
              Behringer, M., Carpenter, B., and S. Jiang, "Gap Analysis
              for Autonomic Networking", draft-irtf-nmrg-an-gap-
              analysis-00 (work in progress), April 2014.

   [I-D.irtf-nmrg-autonomic-network-definitions]
              Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
              Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
              Networking - Definitions and Design Goals", draft-irtf-
              nmrg-autonomic-network-definitions-00 (work in progress),
              December 2013.

   [I-D.jiang-config-negotiation-ps]
              Jiang, S., Yin, Y., and B. Carpenter, "Network
              Configuration Negotiation Problem Statement and
              Requirements", draft-jiang-config-negotiation-ps-02 (work
              in progress), January 2014.

   [I-D.mglt-homenet-naming-architecture-dhc-options]
              Migault, D., Cloetens, W., Griffiths, C., and R. Weber,
              "DHCP Options for Homenet Naming Architecture", draft-
              mglt-homenet-naming-architecture-dhc-options-01 (work in
              progress), February 2014.

   [I-D.pfister-homenet-prefix-assignment]
              Pfister, P., Paterson, B., and J. Arkko, "Prefix and
              Address Assignment in a Home Network", draft-pfister-
              homenet-prefix-assignment-01 (work in progress), May 2014.

   [I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf]
              Stenberg, M., "Auto-Configuration of a Network of Hybrid
              Unicast/Multicast DNS-Based Service Discovery Proxy
              Nodes", draft-stenberg-homenet-dnssd-hybrid-proxy-
              zeroconf-00 (work in progress), February 2014.

   [I-D.winters-homenet-sper-interaction]
              Winters, T., "Service Provider Edge Router Interaction",
              draft-winters-homenet-sper-interaction-01 (work in
              progress), February 2014.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.





Carpenter               Expires November 20, 2014               [Page 8]


Internet-Draft             Homenet AN Use Case                  May 2014


   [RFC6724]  Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, September 2012.

Author's Address

   Brian Carpenter
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland  1142
   New Zealand

   Email: brian.e.carpenter@gmail.com





































Carpenter               Expires November 20, 2014               [Page 9]