One document matched: draft-carpenter-nmrg-homenet-an-use-case-01.xml

<?xml version="1.0" encoding="UTF-8"?>

<!-- This is built from a template for a generic Internet Draft. Suggestions for
     improvement welcome - write to Brian Carpenter, brian.e.carpenter @ gmail.com -->

<!-- This can be converted using the Web service at http://xml.resource.org/experimental.html
     (which supports the latest, sometimes undocumented and under-tested, features.) -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [


]>


<?rfc toc="yes"?>            <!-- You want a table of contents -->
<?rfc symrefs="yes"?>        <!-- Use symbolic labels for references -->
<?rfc sortrefs="yes"?>       <!-- This sorts the references -->
<?rfc iprnotified="no" ?>    <!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>


<!-- This defines the specific filename and version number of your draft (and inserts the appropriate IETF boilerplate -->
<rfc ipr="trust200902" docName="draft-carpenter-nmrg-homenet-an-use-case-01" category="info"  >


<front>
<title abbrev="Homenet AN Use Case">Autonomic Networking Use Case for Home Networks</title>


<author initials="B. E." surname="Carpenter" fullname="Brian Carpenter">
    <organization abbrev="Univ. of Auckland"></organization>
    <address>
      <postal>
        <street>Department of Computer Science</street>
        <street>University of Auckland</street>
        <street>PB 92019</street>
        <city>Auckland</city>
        <region></region>
        <code>1142</code>
        <country>New Zealand</country>
      </postal>
      
      <email>brian.e.carpenter@gmail.com</email>
    </address>
</author>


<date day="19" month="May" year="2014" />

<area>Operations and Management</area>
<workgroup>UCAN BOF</workgroup>


<abstract>

<t>
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. 
</t>
    
</abstract>
</front>

<middle>
<section anchor="intro" title="Introduction">
<t>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
<xref target="I-D.irtf-nmrg-autonomic-network-definitions"/> and
<xref target="I-D.irtf-nmrg-an-gap-analysis"/>. A problem statement and outline
requirements for the negotiation protocol are given in 
<xref target="I-D.jiang-config-negotiation-ps"/>. </t>

<t>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. </t>
</section> <!-- intro -->

<section anchor="problem" title="Problem Statement">

<t>The use case considered here is autonomic operation of home networks based on IPv6,
in general accordance with <xref target="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 <xref target="I-D.ietf-homenet-hncp"/>. A solution has also been
described for bootstrapping trust in a homenet <xref target="I-D.behringer-homenet-trust-bootstrap"/>. </t>

<t>Additional issues that impact homenet configuration are discussed in
<xref target="I-D.winters-homenet-sper-interaction"/>,
<xref target="I-D.pfister-homenet-prefix-assignment"/>,
<xref target="I-D.mglt-homenet-naming-architecture-dhc-options"/> and
<xref target="I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf"/>. </t>

<t>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. </t>

<t>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. </t>

<t>This use case does not currently consider the challenges posed by multiple
provisioning domains as defined by <xref target="I-D.ietf-mif-mpvd-arch"/>. </t>

</section> <!-- problem -->

<section anchor="experience" title="Intended User and Administrator Experience">

<t>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. </t>

</section> <!-- experience -->

<section anchor="params" title="Analysis of Parameters and Information Involved">
<t>Numerous parameters are involved in a homenet (some of
them can of course be pre-configured with default values). They include:</t>
 <t><list style="symbols">
 <t>Identity of a trust anchor to act as a local certification authority (CA)
 and registration authority (RA) for nodes inside the homenet. </t>
 <t>Identity of border devices (equivalent to perimeter identification). </t>
 <t>Firewall rules (for border devices and for host firewalls). </t>
 <t>IP address prefix(es) for the whole homenet. </t>
 <t>Individual prefix(es) for each subnet. </t>
 <t>Choice of routing protocol. </t>
 <t>Initial configuration of all routers. </t>
 <t>Default router for each subnet. </t>
 <t>Rules for address selection. </t>
 <t>Local namespace information (delegated zone if any, etc.). </t>
 <t>DNS server(s). </t>
 </list></t>


<section anchor="device" title="Parameters each device can decide for itself">
<t>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:  </t>

 <t><list style="symbols">
 <t>Default firewall rules for hosts. Hosts should be shipped from the manufacturer
 with generally applicable default firewall rules. </t>
 <t>Default rules for address selection should conform to <xref target="RFC6724"/>. </t>
 </list></t>
</section> <!-- device -->

<section anchor="intent" title="Information needed from policy intent">
<t>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. </t>

 <t><list style="symbols">
 <t>Method of determining the trust anchor. </t>
 <t>Whether firewall rules will be changed from their default settings. </t>
 <t>Whether more than one GUA prefix will be deployed. </t>
 <t>Whether a ULA prefix will be deployed. </t>
 <t>Which routing protocol is preferred. </t> 
 <t>Whether DHCPv6 will be deployed. </t> 
 <t>Whether non-default rules for address selection will be deployed. </t>
 <t>Whether IPv4 and DHCP will be deployed (IPv6 is assumed). </t>
 
 </list></t>
</section> <!-- intent -->

</section> <!-- params -->

<section anchor="interact" title="Interaction with other devices">

<section anchor="peers" title="Information needed from neighbor devices">
<t>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.</t>
 <t><list style="symbols">
 <t>Identity of a trust anchor. </t>
 <t>Routers will need to discover their neighbors. </t>
 <t>Routers will need to determine whether they are border devices. </t>
 <t>Border routers will need to apply a default border firewall
 policy; interior routers will not be firewalls by default. </t> 
 <t>Hosts may need to acquire a non-default firewall policy. </t>
 <t>Border routers will need to determine the IP address prefix(es) for the whole homenet. </t>
 <t>One border router will need to generate the ULA prefix for the whole homenet. </t>
 <t>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. </t>
 <t>With knowledge of its neighbors and after prefix delegation, each
 router will need to configure and launch the agreed routing protocol. </t>
 <t>Hosts need to acquire a default router for each interface. </t>
 <t>Hosts may need to acquire non-default rules for address selection. </t>
 <t>The local namespace service must configure itself. Relevant devices will need to know
 at least the zone name delegated to the homenet. This is a complex topic, so
 the reader is referred to drafts that already describe the needed functions:
 <xref target="I-D.mglt-homenet-naming-architecture-dhc-options"/> and
 <xref target="I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf"/>. </t>
 <t>Hosts need to acquire DNS server address(es). </t>
 </list></t>

</section> <!-- peers -->


<section anchor="monitor" title="Monitoring, diagnostics and reporting">
<t>This section discusses what role devices should play in monitoring,
fault diagnosis, and reporting. </t>

 <t><list style="symbols">
 <t>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. </t>
 <t>Similarly, hard failures should be logged and notified, even if the network
 has somehow routed around them. </t>
 <t>Users are very unlikely to take an interest in warnings of any kind, so
 they are probably a waste of time. </t>
 <t>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. </t>
 
 </list></t>

</section> <!-- monitor -->

</section> <!-- interact -->

<section anchor="compare" title="Comparison with current solutions">
<t>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 <xref target="problem"/>. 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. </t>
</section> <!-- compare -->


<section anchor="security" title="Security Considerations">

<t>Relevant security issues are discussed in
<xref target="I-D.irtf-nmrg-autonomic-network-definitions"/>,
<xref target="I-D.jiang-config-negotiation-ps"/>
and <xref target="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.</t>


</section> <!-- security -->


<section anchor="iana" title="IANA Considerations">
<t>This document requests no action by IANA. </t>


</section> <!-- iana -->




<section anchor="ack" title="Acknowledgements">

<t>
Valuable comments were received from
Steven Barth,
Michael Behringer,
Sheng Jiang,
Mark Townsley,
and others.
 </t>



<t>This document was produced using the xml2rfc tool
<xref target="RFC2629"/>.</t>

</section> <!-- ack -->


<section anchor ="changes" title="Change log [RFC Editor: Please remove]">

<t>draft-carpenter-nmrg-homenet-an-use-case-01:  clarifications, more accurate characterisation of HNCP, 2014-05-19.</t>
<t>draft-carpenter-nmrg-homenet-an-use-case-00:  original version, 2014-04-10.</t>


</section> <!-- changes -->

</middle>

<back>

<references title="References">

<?rfc include='reference.RFC.2629'?>
<?rfc include='reference.RFC.6724'?>
<?rfc include="reference.I-D.irtf-nmrg-autonomic-network-definitions.xml"?>
<?rfc include="reference.I-D.irtf-nmrg-an-gap-analysis.xml"?>
<?rfc include="reference.I-D.jiang-config-negotiation-ps.xml"?>
<?rfc include="reference.I-D.ietf-homenet-arch.xml"?>
<?rfc include="reference.I-D.ietf-homenet-hncp.xml"?>
<?rfc include="reference.I-D.behringer-homenet-trust-bootstrap.xml"?>
<?rfc include="reference.I-D.winters-homenet-sper-interaction.xml"?>
<?rfc include="reference.I-D.pfister-homenet-prefix-assignment.xml"?>
<?rfc include="reference.I-D.mglt-homenet-naming-architecture-dhc-options.xml"?>
<?rfc include="reference.I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf.xml"?>
<?rfc include="reference.I-D.ietf-mif-mpvd-arch.xml"?>
 
</references>




</back>
</rfc>