idnits 2.17.1 draft-carpenter-nmrg-homenet-an-use-case-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 19, 2014) is 3630 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-13 == Outdated reference: A later version (-10) exists of draft-ietf-homenet-hncp-00 == Outdated reference: A later version (-11) exists of draft-ietf-mif-mpvd-arch-01 == Outdated reference: A later version (-06) exists of draft-irtf-nmrg-an-gap-analysis-00 == Outdated reference: A later version (-07) exists of draft-irtf-nmrg-autonomic-network-definitions-00 == Outdated reference: A later version (-03) exists of draft-jiang-config-negotiation-ps-02 == Outdated reference: A later version (-02) exists of draft-mglt-homenet-naming-architecture-dhc-options-01 == Outdated reference: A later version (-02) exists of draft-pfister-homenet-prefix-assignment-01 == Outdated reference: A later version (-02) exists of draft-stenberg-homenet-dnssd-hybrid-proxy-zeroconf-00 ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 UCAN BOF B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational May 19, 2014 5 Expires: November 20, 2014 7 Autonomic Networking Use Case for Home Networks 8 draft-carpenter-nmrg-homenet-an-use-case-01 10 Abstract 12 This document describes a use case for autonomic networking in home 13 network scenarios. It is one of a series of use cases intended to 14 illustrate requirements for autonomic networking. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on November 20, 2014. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 52 3. Intended User and Administrator Experience . . . . . . . . . 3 53 4. Analysis of Parameters and Information Involved . . . . . . . 3 54 4.1. Parameters each device can decide for itself . . . . . . 4 55 4.2. Information needed from policy intent . . . . . . . . . . 4 56 5. Interaction with other devices . . . . . . . . . . . . . . . 5 57 5.1. Information needed from neighbor devices . . . . . . . . 5 58 5.2. Monitoring, diagnostics and reporting . . . . . . . . . . 6 59 6. Comparison with current solutions . . . . . . . . . . . . . . 6 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 63 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 7 64 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 This document is one of a set of use cases being developed to clarify 70 the requirements for discovery and negotiation protocols for 71 autonomic networking (AN). The background to AN is described in 72 [I-D.irtf-nmrg-autonomic-network-definitions] and 73 [I-D.irtf-nmrg-an-gap-analysis]. A problem statement and outline 74 requirements for the negotiation protocol are given in 75 [I-D.jiang-config-negotiation-ps]. 77 Note in draft: The format of this document may be modified as we 78 agree on a common format for AN use cases. In particular, opinions 79 may vary about how concrete vs how abstract a use case should be. 81 2. Problem Statement 83 The use case considered here is autonomic operation of home networks 84 based on IPv6, in general accordance with [I-D.ietf-homenet-arch]. 85 The model assumes that a typical homenet in the future will have 86 multiple network segments, several routers, and a reasonably large 87 number of hosts, but no expert human manager. For some aspects of 88 homenet configuration, a protocol solution known as HNCP (homenet 89 control protocol) has been designed and implemented 90 [I-D.ietf-homenet-hncp]. A solution has also been described for 91 bootstrapping trust in a homenet 92 [I-D.behringer-homenet-trust-bootstrap]. 94 Additional issues that impact homenet configuration are discussed in 95 [I-D.winters-homenet-sper-interaction], 97 [I-D.pfister-homenet-prefix-assignment], 98 [I-D.mglt-homenet-naming-architecture-dhc-options] and 99 [I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf]. 101 The problem to be solved by AN is how to replace these and other 102 partial solutions by a generic solution that sets all necessary 103 parameters for the homenet to operate efficiently, reliably and 104 securely, with minimal human intervention and without the need for 105 traditional top-down configuration. 107 It should be noted that HNCP has a quite generic design, but so far 108 has been described for a fairly narrow scope of application, and 109 other aspects of homenet bootstrapping, discovery and configuration 110 are currently handled by other methods. The present draft takes no 111 position on these various solutions, since its goal is only to 112 describe the use case. 114 This use case does not currently consider the challenges posed by 115 multiple provisioning domains as defined by [I-D.ietf-mif-mpvd-arch]. 117 3. Intended User and Administrator Experience 119 In a homenet, the basic assumption is that no human involved has 120 technical knowledge beyond the ability to unwrap a product, connect a 121 few cables, and follow simple instructions. Indeed, the parody "Have 122 you tried turning it off and on again?" may apply literally. 123 Therefore, the desired user experience is that everything just works, 124 that there are no mandatory user actions, and that no specialist 125 knowledge is needed. If any user choices are offered, there must be 126 a reasonable default. When power failures or equipment failures 127 occur, recovery to the best possible running state must be automatic. 128 If any diagnostic messages are produced, they must be simple and 129 clear, and of course provided in the user's own language. If any 130 logs are recorded, it is to be expected that the normal user will 131 never look at them and could not understand them. 133 4. Analysis of Parameters and Information Involved 135 Numerous parameters are involved in a homenet (some of them can of 136 course be pre-configured with default values). They include: 138 o Identity of a trust anchor to act as a local certification 139 authority (CA) and registration authority (RA) for nodes inside 140 the homenet. 142 o Identity of border devices (equivalent to perimeter 143 identification). 145 o Firewall rules (for border devices and for host firewalls). 147 o IP address prefix(es) for the whole homenet. 149 o Individual prefix(es) for each subnet. 151 o Choice of routing protocol. 153 o Initial configuration of all routers. 155 o Default router for each subnet. 157 o Rules for address selection. 159 o Local namespace information (delegated zone if any, etc.). 161 o DNS server(s). 163 4.1. Parameters each device can decide for itself 165 This section identifies those of the above parameters that do not 166 need external information in order for the devices concerned to set 167 them to a reasonable value after bootstrap or after a network 168 disruption. There are few of these: 170 o Default firewall rules for hosts. Hosts should be shipped from 171 the manufacturer with generally applicable default firewall rules. 173 o Default rules for address selection should conform to [RFC6724]. 175 4.2. Information needed from policy intent 177 This section identifies those parameters that need external 178 information about policy intent in order for the devices concerned to 179 set them. to a non-default value. It's assumed that in a homenet, 180 policy intent will likely be provided by the main homenet router, and 181 may itself be a default setting in that router, since there is 182 normally no human expert to set policy. Not all devices will need to 183 know all of these intents. 185 o Method of determining the trust anchor. 187 o Whether firewall rules will be changed from their default 188 settings. 190 o Whether more than one GUA prefix will be deployed. 192 o Whether a ULA prefix will be deployed. 194 o Which routing protocol is preferred. 196 o Whether DHCPv6 will be deployed. 198 o Whether non-default rules for address selection will be deployed. 200 o Whether IPv4 and DHCP will be deployed (IPv6 is assumed). 202 5. Interaction with other devices 204 5.1. Information needed from neighbor devices 206 This section identifies those of the above parameters that need 207 external information from neighbor devices (such as other routers) in 208 order for the devices concerned to set them. In many cases, two-way 209 dialogue with neighbor devices is needed to set or optimise them. 211 o Identity of a trust anchor. 213 o Routers will need to discover their neighbors. 215 o Routers will need to determine whether they are border devices. 217 o Border routers will need to apply a default border firewall 218 policy; interior routers will not be firewalls by default. 220 o Hosts may need to acquire a non-default firewall policy. 222 o Border routers will need to determine the IP address prefix(es) 223 for the whole homenet. 225 o One border router will need to generate the ULA prefix for the 226 whole homenet. 228 o Routers will need to discover the network topology and then to 229 apply a prefix delegation method to deliver at least one prefix to 230 each subnet. 232 o With knowledge of its neighbors and after prefix delegation, each 233 router will need to configure and launch the agreed routing 234 protocol. 236 o Hosts need to acquire a default router for each interface. 238 o Hosts may need to acquire non-default rules for address selection. 240 o The local namespace service must configure itself. Relevant 241 devices will need to know at least the zone name delegated to the 242 homenet. This is a complex topic, so the reader is referred to 243 drafts that already describe the needed functions: 244 [I-D.mglt-homenet-naming-architecture-dhc-options] and 245 [I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf]. 247 o Hosts need to acquire DNS server address(es). 249 5.2. Monitoring, diagnostics and reporting 251 This section discusses what role devices should play in monitoring, 252 fault diagnosis, and reporting. 254 o In general, failure to successfully set reasonable values for any 255 network parameter should be logged and notified to the user, in 256 simple, non-technical words in the user's own language. 258 o Similarly, hard failures should be logged and notified, even if 259 the network has somehow routed around them. 261 o Users are very unlikely to take an interest in warnings of any 262 kind, so they are probably a waste of time. 264 o Firewall incidents are typically logged in a proprietary fashion. 265 It would be conceivable for all firewalls in a homenet to log 266 incidents centrally but it seems unlikely that such a feature 267 would ever be used by a typical home user. 269 6. Comparison with current solutions 271 This section briefly compares the above use case with current 272 solutions. Today's typical single-router homenets do largely run 273 without significant human intervention, relying on fixed DHCP setups 274 for IPv4 and on out-of-the-box Router Advertisements for IPv6. This 275 comparison is not very illuminating, since we are interested in 276 complex homenets with multiple routers. A better comparison is with 277 the emerging prototype homenet environment based on the various 278 drafts cited in Section 2. The functionality described is very 279 similar. The actual content of the messages would also be very 280 similar to those in HNCP etc. However, using a generic autonomic 281 discovery and negotiation protocol instead of a mixture of dedicated 282 solutions has the advantage that additional parameters can be 283 included in the autonomic solution without creating new mechanisms. 284 This is the principal argument for a generic approach. 286 7. Security Considerations 288 Relevant security issues are discussed in 289 [I-D.irtf-nmrg-autonomic-network-definitions], 290 [I-D.jiang-config-negotiation-ps] and [I-D.ietf-homenet-arch]. The 291 security specificity of a homenet is the need to establish a trust 292 anchor in the absence of a human expert, which will allow remaining 293 security features to configure themselves autonomically. 295 8. IANA Considerations 297 This document requests no action by IANA. 299 9. Acknowledgements 301 Valuable comments were received from Steven Barth, Michael Behringer, 302 Sheng Jiang, Mark Townsley, and others. 304 This document was produced using the xml2rfc tool [RFC2629]. 306 10. Change log [RFC Editor: Please remove] 308 draft-carpenter-nmrg-homenet-an-use-case-01: clarifications, more 309 accurate characterisation of HNCP, 2014-05-19. 311 draft-carpenter-nmrg-homenet-an-use-case-00: original version, 312 2014-04-10. 314 11. References 316 [I-D.behringer-homenet-trust-bootstrap] 317 Behringer, M., Pritikin, M., and S. Bjarnason, 318 "Bootstrapping Trust on a Homenet", draft-behringer- 319 homenet-trust-bootstrap-02 (work in progress), February 320 2014. 322 [I-D.ietf-homenet-arch] 323 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 324 "IPv6 Home Networking Architecture Principles", draft- 325 ietf-homenet-arch-13 (work in progress), March 2014. 327 [I-D.ietf-homenet-hncp] 328 Stenberg, M. and S. Barth, "Home Networking Control 329 Protocol", draft-ietf-homenet-hncp-00 (work in progress), 330 April 2014. 332 [I-D.ietf-mif-mpvd-arch] 333 Anipko, D., "Multiple Provisioning Domain Architecture", 334 draft-ietf-mif-mpvd-arch-01 (work in progress), May 2014. 336 [I-D.irtf-nmrg-an-gap-analysis] 337 Behringer, M., Carpenter, B., and S. Jiang, "Gap Analysis 338 for Autonomic Networking", draft-irtf-nmrg-an-gap- 339 analysis-00 (work in progress), April 2014. 341 [I-D.irtf-nmrg-autonomic-network-definitions] 342 Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., 343 Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic 344 Networking - Definitions and Design Goals", draft-irtf- 345 nmrg-autonomic-network-definitions-00 (work in progress), 346 December 2013. 348 [I-D.jiang-config-negotiation-ps] 349 Jiang, S., Yin, Y., and B. Carpenter, "Network 350 Configuration Negotiation Problem Statement and 351 Requirements", draft-jiang-config-negotiation-ps-02 (work 352 in progress), January 2014. 354 [I-D.mglt-homenet-naming-architecture-dhc-options] 355 Migault, D., Cloetens, W., Griffiths, C., and R. Weber, 356 "DHCP Options for Homenet Naming Architecture", draft- 357 mglt-homenet-naming-architecture-dhc-options-01 (work in 358 progress), February 2014. 360 [I-D.pfister-homenet-prefix-assignment] 361 Pfister, P., Paterson, B., and J. Arkko, "Prefix and 362 Address Assignment in a Home Network", draft-pfister- 363 homenet-prefix-assignment-01 (work in progress), May 2014. 365 [I-D.stenberg-homenet-dnssd-hybrid-proxy-zeroconf] 366 Stenberg, M., "Auto-Configuration of a Network of Hybrid 367 Unicast/Multicast DNS-Based Service Discovery Proxy 368 Nodes", draft-stenberg-homenet-dnssd-hybrid-proxy- 369 zeroconf-00 (work in progress), February 2014. 371 [I-D.winters-homenet-sper-interaction] 372 Winters, T., "Service Provider Edge Router Interaction", 373 draft-winters-homenet-sper-interaction-01 (work in 374 progress), February 2014. 376 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 377 June 1999. 379 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 380 "Default Address Selection for Internet Protocol Version 6 381 (IPv6)", RFC 6724, September 2012. 383 Author's Address 385 Brian Carpenter 386 Department of Computer Science 387 University of Auckland 388 PB 92019 389 Auckland 1142 390 New Zealand 392 Email: brian.e.carpenter@gmail.com