idnits 2.17.1 draft-carpenter-limited-domains-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 2, 2019) is 1881 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-herbert-fast-03 == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-16 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-18 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-11 == Outdated reference: A later version (-17) exists of draft-ietf-intarea-frag-fragile-09 == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-07 == Outdated reference: A later version (-10) exists of draft-ietf-opsec-ipv6-eh-filtering-06 == Outdated reference: A later version (-10) exists of draft-voyer-6man-extension-header-insertion-05 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational B. Liu 5 Expires: September 3, 2019 Huawei Technologies 6 March 2, 2019 8 Limited Domains and Internet Protocols 9 draft-carpenter-limited-domains-06 11 Abstract 13 There is a noticeable trend towards network requirements, behaviours 14 and semantics that are specific to a limited region of the Internet 15 and a particular set of requirements. Policies, default parameters, 16 the options supported, the style of network management and security 17 requirements may vary. This document reviews examples of such 18 limited domains, also known as controlled environments, and emerging 19 solutions, and develops a related taxonomy. It then briefly 20 discusses the standardization of protocols for limited domains. 21 Finally, it shows the needs for a precise definition of limited 22 domain membership and for mechanisms to allow nodes to join a domain 23 securely and to find other members, including boundary nodes. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 3, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Failure Modes in Today's Internet . . . . . . . . . . . . . . 4 61 3. Examples of Limited Domain Requirements . . . . . . . . . . . 4 62 4. Examples of Limited Domain Solutions . . . . . . . . . . . . 7 63 5. Taxonomy of Limited Domains . . . . . . . . . . . . . . . . . 10 64 5.1. The Domain as a Whole . . . . . . . . . . . . . . . . . . 10 65 5.2. Individual Nodes . . . . . . . . . . . . . . . . . . . . 11 66 5.3. The Domain Boundary . . . . . . . . . . . . . . . . . . . 11 67 5.4. Topology . . . . . . . . . . . . . . . . . . . . . . . . 11 68 5.5. Technology . . . . . . . . . . . . . . . . . . . . . . . 12 69 5.6. Connection to the Internet . . . . . . . . . . . . . . . 12 70 5.7. Security, Trust and Privacy Model . . . . . . . . . . . . 12 71 5.8. Operations . . . . . . . . . . . . . . . . . . . . . . . 13 72 5.9. Making use of this taxonomy . . . . . . . . . . . . . . . 13 73 6. The Scope of Protocols in Limited Domains . . . . . . . . . . 13 74 7. Functional Requirements of Limited Domains . . . . . . . . . 15 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 77 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 78 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 79 12. Informative References . . . . . . . . . . . . . . . . . . . 17 80 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 22 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 83 1. Introduction 85 As the Internet continues to grow and diversify, with a realistic 86 prospect of tens of billions of nodes being connected directly and 87 indirectly, there is a noticeable trend towards local requirements, 88 behaviours and semantics. The word "local" should be understood in a 89 special sense, however. In some cases it may refer to geographical 90 and physical locality - all the nodes in a single building, on a 91 single campus, or in a given vehicle. In other cases it may refer to 92 a defined set of users or nodes distributed over a much wider area, 93 but drawn together by a single virtual network over the Internet, or 94 a single physical network running partially in parallel with the 95 Internet. We expand on these possibilities below. To capture the 96 topic, this document refers to such networks as "limited domains". 98 Some people have concerns about splintering of the Internet along 99 political or linguistic boundaries by mechanisms that block the free 100 flow of information across the network. That is not the topic of 101 this document, which does not discuss filtering mechanisms and does 102 not apply to protocols that are designed for use across the whole 103 Internet. It is only concerned with domains that have specific 104 technical requirements. 106 The word "domain" in this document does not refer to naming domains 107 in the DNS, although in some cases a limited domain might 108 incidentally be congruent with a DNS domain. In particular, with a 109 "split horizon" DNS configuration [RFC6950], the split might be at 110 the edge of a limited domain. 112 Another term that has been used in some contexts is "controlled 113 environment". For example, [RFC8085] uses this to delimit the scope 114 within which a particular tunnel encapsulation might be used. A 115 specific example is GRE-in-UDP encapsulation [RFC8086] which 116 explicitly states that "The controlled environment has less 117 restrictive requirements than the general Internet." For example, 118 non-congestion-controlled traffic might be acceptable within the 119 controlled environment. The same phrase has been used to delimit the 120 scope of quality of service or security protocols, e.g. [RFC6398], 121 [RFC6455]. In this document, we assume that "limited domain" and 122 "controlled environment" mean the same thing in practice. 124 The requirements of limited domains will be different in different 125 scenarios. Policies, default parameters, and the options supported 126 may vary. Also, the style of network management may vary, between a 127 completely unmanaged network, one with fully autonomic management, 128 one with traditional central management, and mixtures of the above. 129 Finally, the requirements and solutions for security and privacy may 130 vary. 132 This documents analyses and discusses some of the consequences of 133 this trend, and how it impacts the idea of universal interoperability 134 in the Internet. Firstly we list examples of limited domain 135 scenarios and of technical solutions for limited domains, with the 136 main focus being the Internet layer of the protocol stack. Then we 137 develop a taxonomy of the features to be found in limited domains. 138 With this background, we discuss the resulting challenge to the idea 139 that all Internet standards must be universal in scope and 140 applicability. To the contrary, we assert that some protocols need 141 to be specifically limited in their applicability. This implies that 142 the concepts of a limited domain, and of its membership, need to be 143 formalised and supported by secure mechanisms. While this document 144 does not propose a design for such mechanisms, it does outline some 145 resulting functional requirements. 147 2. Failure Modes in Today's Internet 149 Today, the Internet does not have a well-defined concept of limited 150 domains. One result of this is that certain protocols and features 151 fail on certain paths. Earlier analyses of this topic have focused 152 either on the loss of transparency of the Internet [RFC2775], 153 [RFC4924] or on the middleboxes responsible for that loss [RFC3234], 154 [RFC7663], [RFC8517]. Unfortunately the problems persist, both in 155 application protocols, and even in very fundamental mechanisms. For 156 example, the Internet is not transparent to IPv6 extension headers 157 [RFC7872], and Path MTU Discovery has been unreliable for many years 158 [RFC2923], [RFC4821]. IP fragmentation is also unreliable 159 [I-D.ietf-intarea-frag-fragile], and problems in TCP MSS negotiation 160 have been reported [I-D.andrews-tcp-and-ipv6-use-minmtu]. 162 On the security side, the widespread insertion of firewalls at domain 163 boundaries that are perceived by humans but unknown to protocols 164 results in arbitrary failure modes as far as the application layer is 165 concerned. There are operational recommendations and practices that 166 effectively guarantee arbitrary failures in realistic scenarios 167 [I-D.ietf-opsec-ipv6-eh-filtering]. 169 The recent discussions about the unreliability of IP fragmentation 170 and the filtering of IPv6 extension headers have clearly shown that 171 at least for some protocol elements, transparency is a lost cause and 172 middleboxes are here to stay. In summary, some application 173 environments require protocol features that cannot cross the whole 174 Internet. Ignoring this during protocol design is not an option. 176 3. Examples of Limited Domain Requirements 178 This section describes various examples where limited domain 179 requirements can easily be identified, either based on an application 180 scenario or on a technical imperative. It is of course not a 181 complete list, and it is presented in an arbitrary order, loosely 182 from smaller to bigger. 184 1. A home network. It will be unmanaged, constructed by a non- 185 specialist, and will possibly include wiring errors such as 186 physical loops. It must work with devices "out of the box" as 187 shipped by their manufacturers and must create adequate security 188 by default. Remote access may be required. The requirements 189 and applicable principles are summarised in [RFC7368]. 191 2. A small office network. This is sometimes very similar to a 192 home network, if whoever is in charge has little or no 193 specialist knowledge, but may have differing security and 194 privacy requirements. In other cases it may be professionally 195 constructed using recommended products and configurations, but 196 operate unmanaged. Remote access may be required. 198 3. A vehicle network. This will be designed by the vehicle 199 manufacturer but may include devices added by the vehicle's 200 owner or operator. Parts of the network will have demanding 201 performance and reliability requirements with implications for 202 human safety. Remote access may be required to certain 203 functions, but absolutely forbidden for others. Communication 204 with other vehicles, roadside infrastructure, and external data 205 sources will be required. See 206 [I-D.ietf-ipwave-vehicular-networking] for a survey of use 207 cases. 209 4. Supervisory Control And Data Acquisition (SCADA) networks, and 210 other hard real time networks. These will exhibit specific 211 technical requirements, including tough real-time performance 212 targets. See for example [I-D.ietf-detnet-use-cases] for 213 numerous use cases. An example is a building services network. 214 This will be designed specifically for a particular building, 215 but using standard components. Additional devices may need to 216 be added at any time. Parts of the network may have demanding 217 reliability requirements with implications for human safety. 218 Remote access may be required to certain functions, but 219 absolutely forbidden for others. 221 5. Sensor networks. The two preceding cases will all include 222 sensors, but some networks may be specifically limited to 223 sensors and the collection and processing of sensor data. They 224 may be in remote or technically challenging locations and 225 installed by non-specialists. 227 6. Internet of Things (IoT) networks. While this term is very 228 flexible and covers many innovative types of network, including 229 ad hoc networks that are formed spontaneously, it seems 230 reasonable to expect that IoT edge networks will have special 231 requirements and protocols that are useful only within a 232 specific domain, and that these protocols cannot, and for 233 security reasons should not, run over the Internet as a whole. 235 7. An important subclass of IoT networks consists of constrained 236 networks [RFC7228] in which the nodes are limited in power 237 consumption and communications bandwidth, and are therefore 238 limited to using very frugal protocols. 240 8. Delay tolerant networks may consist of domains that are 241 relatively isolated and constrained in power (e.g. deep space 242 networks) and are connected only intermittently to the outside, 243 with a very long latency on such connections [RFC4838]. Clearly 244 the protocol requirements and possibilities are very specialised 245 in such networks. 247 9. "Traditional" enterprise and campus networks, which may be 248 spread over many kilometres and over multiple separate sites, 249 with multiple connections to the Internet. Interestingly, the 250 IETF appears never to have analysed this long-established class 251 of networks in a general way, except in connection with IPv6 252 deployment (e.g. [RFC7381]). 254 10. Data centres and hosting centres, or distributed services acting 255 as such centres. These will have high performance, security and 256 privacy requirements and will typically include large numbers of 257 independent "tenant" networks overlaid on shared infrastructure. 259 11. Content Delivery Networks (CDNs), comprising distributed data 260 centres and the paths between them, spanning thousands of 261 kilometres, with numerous connections to the Internet. 263 12. Massive Web Service Provider Networks. This is a small class of 264 networks with well known trademarked names, combining aspects of 265 distributed enterprise networks, data centres and CDNs. They 266 have their own international networks bypassing the generic 267 carriers. Like CDNs, they have numerous connections to the 268 Internet, typically offering a tailored service in each economy. 270 Three other aspects, while not tied to specific network types, also 271 strongly depend on the concept of limited domains: 273 1. Intent Based Networking. In this concept, a network domain is 274 configured and managed in accordance with an abstract policy 275 known as "Intent", to ensure that the network performs as 276 required [I-D.moulchan-nmrg-network-intent-concepts]. Whatever 277 technologies are used to support this, they will be applied 278 within the domain boundary. 280 2. Many of the above types of network may be extended throughout the 281 Internet by a variety of virtual private network (VPN) 282 techniques. Therefore we argue that limited domains may overlap 283 each other in an arbitrary fashion by use of virtualization 284 techniques. As noted above in the discussion of controlled 285 environments, specific tunneling and encapsulation techniques may 286 only be usable within a given domain. 288 3. Network Slicing. A network slice is a virtual network that 289 consists of a managed set of resources carved off from a larger 290 network [I-D.geng-netslices-architecture]. Whatever technologies 291 are used to support slicing, they will require a clear definition 292 of the boundary of a given slice. 294 While it is clearly desirable to use common solutions, and therefore 295 common standards, wherever possible, it is increasingly difficult to 296 do so while satisfying the widely varying requirements outlined 297 above. However, there is a tendency when new protocols and protocol 298 extensions are proposed to always ask the question "How will this 299 work across the open Internet?" This document suggests that this is 300 not always the right question. There are protocols and extensions 301 that are not intended to work across the open Internet. On the 302 contrary, their requirements and semantics are specifically limited 303 (in the sense defined above). 305 A common argument is that if a protocol is intended for limited use, 306 the chances are very high that it will in fact be used (or misused) 307 in other scenarios including the so-called open Internet. This is 308 undoubtedly true and means that limited use is not an excuse for bad 309 design or poor security. In fact, a limited use requirement 310 potentially adds complexity to both the protocol and its security 311 design, as discussed later. 313 Nevertheless, because of the diversity of limited domains with 314 specific requirements that is now emerging, specific standards (and 315 ad hoc standards) will probably emerge for different types of domain. 316 There will be attempts to capture each market sector, but the market 317 will demand standardised solutions within each sector. In addition, 318 operational choices will be made that can in fact only work within a 319 limited domain. The history of RSVP illustrates that a standard 320 defined as if it could work over the open Internet may not in fact do 321 so. In general we can no longer assume that a protocol designed 322 according to classical Internet guidelines will in fact work reliably 323 across the network as a whole. However, the "open Internet" must 324 remain as the universal method of interconnection. Reconciling these 325 two aspects is a major challenge. 327 4. Examples of Limited Domain Solutions 329 This section lists various examples of specific limited domain 330 solutions that have been proposed or defined. It intentionally does 331 not include Layer 2 technology solutions, which by definition apply 332 to limited domains. 334 1. Differentiated Services. This mechanism [RFC2474] allows a 335 network to assign locally significant values to the 6-bit 336 Differentiated Services Code Point field in any IP packet. 337 Although there are some recommended codepoint values for 338 specific per-hop queue management behaviours, these are 339 specifically intended to be domain-specific codepoints with 340 traffic being classified, conditioned and re-marked at domain 341 boundaries (unless there is an inter-domain agreement that makes 342 re-marking unnecessary). 344 2. Integrated Services. Although it is not intrinsic in the design 345 of RSVP [RFC2205], it is clear from many years' experience that 346 Integrated Services can only be deployed successfully within a 347 limited domain that is configured with adequate equipment and 348 resources. 350 3. Network function virtualisation. As described in 351 [I-D.irtf-nfvrg-gaps-network-virtualization], this general 352 concept is an open research topic, in which virtual network 353 functions are orchestrated as part of a distributed system. 354 Inevitably such orchestration applies to an administrative 355 domain of some kind, even though cross-domain orchestration is 356 also a research area. 358 4. Service Function Chaining (SFC). This technique [RFC7665] 359 assumes that services within a network are constructed as 360 sequences of individual functions within a specific SFC-enabled 361 domain. As that RFC states: "Specific features may need to be 362 enforced at the boundaries of an SFC-enabled domain, for example 363 to avoid leaking SFC information". A Network Service Header 364 (NSH) [RFC8300] is used to encapsulate packets flowing through 365 the service function chain: "The intended scope of the NSH is 366 for use within a single provider's operational domain." 368 5. Firewall and Service Tickets (FAST). Such tickets would 369 accompany a packet to claim the right to traverse a network or 370 request a specific network service [I-D.herbert-fast]. They 371 would only be valid within a particular domain. 373 6. Data Centre Network Virtualization Overlays. A common 374 requirement in data centres that host many tenants (clients) is 375 to provide each one with a secure private network, all running 376 over the same physical infrastructure. [RFC8151] describes 377 various use cases for this, and specifications are under 378 development. These include use cases in which the tenant 379 network is physically split over several data centres, but which 380 must appear to the user as a single secure domain. 382 7. Segment Routing. This is a technique which "steers a packet 383 through an ordered list of instructions, called segments" 384 [RFC8402]. The semantics of these instructions are explicitly 385 local to a segment routing domain or even to a single node. 386 Technically, these segments or instructions are represented as 387 an MPLS label or an IPv6 address, which clearly adds a semantic 388 interpretation to them within the domain. 390 8. Autonomic Networking. As explained in 391 [I-D.ietf-anima-reference-model], an autonomic network is also a 392 security domain within which an autonomic control plane 393 [I-D.ietf-anima-autonomic-control-plane] is used by autonomic 394 service agents. These agents manage technical objectives, which 395 may be locally defined, subject to domain-wide policy. Thus the 396 domain boundary is important for both security and protocol 397 purposes. 399 9. Homenet. As shown in [RFC7368], a home networking domain has 400 specific protocol needs that differ from those in an enterprise 401 network or the Internet as a whole. These include the Home 402 Network Control Protocol (HNCP) [RFC7788] and a naming and 403 discovery solution [I-D.ietf-homenet-simple-naming]. 405 10. Creative uses of IPv6 features. As IPv6 enters more general 406 use, engineers notice that it has much more flexibility than 407 IPv4. Innovative suggestions have been made for: 409 * The flow label, e.g. [RFC6294], 410 [I-D.fioccola-v6ops-ipv6-alt-mark]. 412 * Extension headers, e.g. for segment routing 413 [I-D.ietf-6man-segment-routing-header]. 415 * Meaningful address bits, e.g. [I-D.jiang-semantic-prefix]. 416 Also, segment routing uses IPv6 addresses as segment 417 identifiers with specific local meanings [RFC8402]. 419 All of these suggestions are only viable within a specified 420 domain. The case of the extension header is particularly 421 interesting, since its existence has been a major "selling 422 point" for IPv6, but it is notorious that new extension headers 423 are virtually impossible to deploy across the whole Internet 424 [RFC7045], [RFC7872]. It is worth noting that extension header 425 filtering is considered as an important security issue 426 [I-D.ietf-opsec-ipv6-eh-filtering]. There is considerable 427 appetite among vendors or operators to have flexibility in 428 defining extension headers for use in limited or specialised 429 domains, e.g. [I-D.voyer-6man-extension-header-insertion] and 430 [BIGIP]. Locally significant hop-by-hop options could also be 431 envisaged, that would be understood by routers inside a domain 432 but not elsewhere. 434 11. Deterministic Networking (DetNet). The Deterministic Networking 435 Architecture [I-D.ietf-detnet-architecture] and encapsulation 436 [I-D.ietf-detnet-dp-sol] aim to support flows with extremely low 437 data loss rates and bounded latency, but only within a part of 438 the network that is "DetNet aware". Thus, as for differentiated 439 services above, the concept of a domain is fundamental. 441 12. Provisioning Domains (PvDs). An architecture for Multiple 442 Provisioning Domains has been defined [RFC7556] to allow hosts 443 attached to multiple networks to learn explicit details about 444 the services provided by each of those networks. 446 5. Taxonomy of Limited Domains 448 This section develops a taxonomy for describing limited domains. 449 Several major aspects are considered in this taxonomy: 451 o The domain as a whole. 453 o The individual nodes. 455 o The domain boundary. 457 o The domain's topology. 459 o The domain's technology. 461 o How the domain connects to the Internet. 463 o The security, trust and privacy model. 465 o Operations. 467 The following sub-sections analyse each of these aspects. 469 5.1. The Domain as a Whole 471 o Why does the domain exist? (e.g., human choice, administrative 472 policy, orchestration requirements, technical requirements) 474 o If there are special requirements, are they at Layer 2, Layer 3 or 475 an upper layer? 477 o Is the domain managed by humans or fully autonomic? 479 o If managed, what style of management applies? (Manual 480 configuration, automated configuration, orchestration?) 482 o Is there a policy model? (Intent, configuration policies?) 484 o Does the domain provide controlled or paid service or open access? 486 5.2. Individual Nodes 488 o Is a domain member a complete node, or only one interface of a 489 node? 491 o Are nodes permanent members of a given domain, or are join and 492 leave operations possible? 494 o Are nodes physical or virtual devices? 496 o Are virtual nodes general-purpose, or limited to specific 497 functions, applications or users? 499 o Are nodes constrained (by battery etc)? 501 o Are devices installed "out of the box" or pre-configured? 503 5.3. The Domain Boundary 505 o How is the domain boundary identified or defined? 507 o Is the domain boundary fixed or dynamic? 509 o Are boundary nodes special? Or can any node be at the boundary? 511 5.4. Topology 513 o Is the domain a subset of a layer 2 or 3 connectivity domain? 515 o In IP addressing terms, is the domain Link-local, Site-local, or 516 Global? 518 o Does the domain overlap other domains? (In other words, a node 519 may or may not be allowed to be a member of multiple domains.) 521 o Does the domain match physical topology, or does it have a virtual 522 (overlay) topology? 524 o Is the domain in a single building, vehicle or campus? Or is it 525 distributed? 527 o If distributed, are the interconnections private or over the 528 Internet? 530 o In IP addressing terms, is the domain Link-local, Site-local, or 531 Global? 533 5.5. Technology 535 o What routing protocol(s) are used, or even different forwarding 536 mechanisms (MPLS or other non-IP mechanism)? 538 o In an overlay domain, what overlay technique is used (L2VPN, 539 L3VPN,...)? 541 o Are there specific QoS requirements? 543 o Link latency - normal or long latency links? 545 o Mobility - are nodes mobile? Is the whole network mobile? 547 o Which specific technologies, such as those in Section 4, are 548 applicable? 550 5.6. Connection to the Internet 552 o Is the Internet connection permanent or intermittent? (Never 553 connected is out of scope.) 555 o What traffic is blocked, in and out? 557 o What traffic is allowed, in and out? 559 o What traffic is transformed, in and out? 561 o Is secure and privileged remote access needed? 563 o Does the domain allow unprivileged remote sessions? 565 5.7. Security, Trust and Privacy Model 567 o Must domain members be authorized? 569 o Are all nodes in the domain at the same trust level? 571 o Is traffic authenticated? 573 o Is traffic encrypted? 575 o What is hidden from the outside? 577 5.8. Operations 579 o Safety level - does the domain have a critical (human) safety 580 role? 582 o Reliability requirement - normal or 99.999% ? 584 o Environment - hazardous conditions? 586 o Installation - are specialists needed? 588 o Service visits - easy, difficult, impossible? 590 o Software/firmware updates - possible or impossible? 592 5.9. Making use of this taxonomy 594 This taxonomy could be used to design or analyse a specific type of 595 limited domain. For the present document, it is intended only to 596 form a background to the following two sections, concerning the scope 597 of protocols used in limited domains, and mechanisms reuqired to 598 securely define domain membership and properties. 600 6. The Scope of Protocols in Limited Domains 602 One consequence of the deployment of limited domains in the Internet 603 is that some protocols will be designed, extended or configured so 604 that they only work correctly between end systems in such domains. 605 This is to some extent encouraged by some existing standards and by 606 the assignment of code points for local or experimental use. In any 607 case it cannot be prevented. Also, by endorsing efforts such as 608 Service Function Chaining, Segment Routing and Deterministic 609 Networking, the IETF is in effect encouraging such deployments. 610 Furthermore, it seems inevitable, if the "Internet of Things" becomes 611 reality, that millions of edge networks containing completely novel 612 types of node will be connected to the Internet; each one of these 613 edge networks will be a limited domain. 615 It is therefore appropriate to discuss whether protocols or protocol 616 extensions should sometimes be standardised to interoperate only 617 within a Limited Domain Boundary. Such protocols would not be 618 required to interoperate across the Internet as a whole. Several 619 possibly overlapping scenarios could then arise: 621 A. If a limited domain is split into two parts connected over the 622 Internet directly at the IP layer (i.e. with no tunnel 623 encapsulating the packets), a limited-domain protocol could be 624 operated between those two parts regardless of its special nature, 625 as long as it respects standard IP formats and is not arbitrarily 626 blocked by firewalls. A simple example is any protocol using a 627 port number assigned to a specific non-IETF protocol. 629 Such a protocol could reasonably be described as an "inter-domain" 630 protocol because the Internet is transparent to it, even if it is 631 meaningless except in the two parts of the limited domain. This 632 is of course nothing new in the Internet architecture. 634 B. If a limited-domain protocol does not respect standard IP 635 formats (for example, if it includes a non-standard IPv6 extension 636 header), it could not be operated between two parts of a domain 637 split at the IP layer. 639 Such a protocol could reasonably be described as an "intra-domain" 640 protocol, and the Internet is opaque to it. 642 C. If a limited-domain protocol is clearly specified to be 643 invalid outside its domain of origin, neither scenario A nor B 644 applies. The two domains need to be unified as a single virtual 645 domain. For example, an encapsulating tunnel between the parts of 646 the split domain could be used. Also, nodes at the domain 647 boundary must drop all packets using the limited-domain protocol. 649 D. If a limited-domain protocol has domain-specific variants, 650 such that implementations in different domains could not 651 interoperate if those domains were unified by some mechanism, the 652 protocol is not interoperable in the normal sense. If two domains 653 using it were merged, the protocol might fail unpredictably. A 654 simple example is any protocol using a port number assigned for 655 experimental use. Such a protocol usually also falls into 656 scenario C. 658 To provide an existing example, consider Differentiated Services 659 [RFC2474]. A packet containing any value whatever in the 6 bits of 660 the Differentiated Service Code Point (DSCP) is well-formed and falls 661 into scenario A. However, because the semantics of DSCP values are 662 locally significant, the packet also falls into scenario D. In fact, 663 differentiated services are only interoperable across domain 664 boundaries if there is a corresponding agreement between the 665 operators; otherwise a specific gateway function is required for 666 meaningful interoperability. Much more detailed discussion is to be 667 found in [RFC2474] and [RFC8100]. 669 To provide a provocative example, consider the proposal in 670 [I-D.voyer-6man-extension-header-insertion] that the restrictions in 671 [RFC8200] should be relaxed to allow IPv6 extension headers to be 672 inserted on the fly in IPv6 packets. If this is done in such a way 673 that the affected packets can never leave the specific limited domain 674 in which they were modified, scenario C applies. If the semantic 675 content of the inserted headers is locally defined, scenario D also 676 applies. In neither case is the Internet disturbed. 678 We conclude that it is reasonable to explicitly define limited-domain 679 protocols, either as standards or as proprietary mechanisms, as long 680 as they describe which of the above scenarios apply and they clarify 681 how the domain is defined. As long as all relevant standards are 682 respected outside the domain boundary, a well-specified limited- 683 domain protocol is not harmful to the Internet. However, as 684 described in the next section, mechanisms are needed to support 685 domain membership operations. 687 7. Functional Requirements of Limited Domains 689 As the preceding taxonomy shows, there are very numerous aspects to a 690 domain, so the common features are not immediately obvious. It would 691 be possible, but tedious, to apply the taxonomy to each of the domain 692 types described in Section 3. However, we can deduce some generally 693 required features and functions without doing so. 695 A basic assumption is that domains should be created and managed as 696 automatically as possible, with minimal human configuration required. 697 We therefore investigate protocol requirements for automating domain 698 creation and management. 700 Firstly, if we drew a topology map, any domain -- virtual or physical 701 -- will have a well defined boundary between "inside" and "outside". 702 However, that boundary in itself has no technical meaning. What 703 matters in reality is whether a node is a member of the domain, and 704 whether it is at the boundary between the domain and the rest of the 705 Internet. Thus the boundary in itself does not need to be 706 identified. However, a sending node needs to know whether it is 707 sending to an inside or outside destination; a receiving node needs 708 to know whether a packet originated inside or outside; and a boundary 709 node needs to know which of its interfaces are inward-facing or 710 outward-facing. It is irrelevant whether the interfaces involved are 711 physical or virtual. 713 With this perspective, we can list some general functional 714 requirements. An underlying assumption here is that domain 715 membership operations should be cryptographically secured; a domain 716 without such security cannot be reliably protected from attack. 718 1. Domain Identity. A domain must have a unique and verifiable 719 identifier; effectively this should be a public key for the 720 domain. Without this, there is no way to secure domain 721 operations and domain membership. The holder of the 722 corresponding private key becomes the trust anchor for the 723 domain. 725 2. Node Eligibility. It must be possible for a node to determine 726 which domain(s) it can potentially join, and on which 727 interface(s). 729 3. Secure Enrolment. A node must be able to enrol in a given domain 730 via secure node identfication and to acquire relevant security 731 credentials (authorization) for operations within the domain. If 732 a node has multiple physical or virtual interfaces, they may 733 require to be individually enrolled. 735 4. Withdrawal. A node must be able to cancel enrolment in a given 736 domain. 738 5. Dynamic Membership. Optionally, a node should be able 739 temporarily leave or rejoin a domain (i.e. enrolment is 740 persistent but membership is intermittent). 742 6. Role, implying authorization to perform a certain set of actions. 743 A node must have a verifiable role. In the simplest case, the 744 choices of role are "interior node" and "boundary node". In a 745 boundary node, individual interfaces may have different roles, 746 e.g. "inward facing" and "outward facing". 748 7. Verify Peer. A node must be able to verify whether another node 749 is a member of the domain. 751 8. Verify Role. A node must be able to learn the verified role of 752 another node. In particular, it must be possible for a node to 753 find boundary nodes (interfacing to the Internet). 755 9. Domain Data. In a domain with management requirements, it must 756 be possible for a node to acquire domain policy and/or domain 757 configuration data. This would include, for example, filtering 758 policy to ensure that inappropriate packets do not leave the 759 domain. 761 These requirements could form the basis for further analysis and 762 solution design. 764 Another aspect is whether individual packets within a limited domain 765 need to carry any sort of indicator that they belong to that domain, 766 or whether this information will be implicit in the IP addresses of 767 the packet. A related question is whether individual packets need 768 cryptographic authentication. This topic is for further study. 770 8. Security Considerations 772 Clearly, the boundary of a limited domain will almost always also act 773 as a security boundary. In particular, it will serve as a trust 774 boundary, and as a boundary of authority for defining capabilities. 775 Within the boundary, limited-domain protocols or protocol features 776 will be useful, but they will be meaningless if they enter or leave 777 the domain. 779 The security model for a limited-scope protocol must allow for the 780 boundary, and in particular for a trust model that changes at the 781 boundary. Typically, credentials will need to be signed by a domain- 782 specific authority. 784 9. IANA Considerations 786 This document makes no request of the IANA. 788 10. Contributors 790 Sheng Jiang made important contributions to this document. 792 11. Acknowledgements 794 Useful comments were received from Amelia Andersdotter, Edward 795 Birrane, David Black, Ron Bonica, Tim Chown, Darren Dukes, Tom 796 Herbert, John Klensin, Michael Richardson, Rick Taylor, Niels ten 797 Oever, and other members of the ANIMA and INTAREA WGs. 799 12. Informative References 801 [BIGIP] Li, R., "HUAWEI - Big IP Initiative.", 2018, 802 . 804 [I-D.andrews-tcp-and-ipv6-use-minmtu] 805 Andrews, M., "TCP Fails To Respect IPV6_USE_MIN_MTU", 806 draft-andrews-tcp-and-ipv6-use-minmtu-04 (work in 807 progress), October 2015. 809 [I-D.fioccola-v6ops-ipv6-alt-mark] 810 Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "IPv6 811 Performance Measurement with Alternate Marking Method", 812 draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress), 813 June 2018. 815 [I-D.geng-netslices-architecture] 816 67, 4., Dong, J., Bryant, S., kiran.makhijani@huawei.com, 817 k., Galis, A., Foy, X., and S. Kuklinski, "Network Slicing 818 Architecture", draft-geng-netslices-architecture-02 (work 819 in progress), July 2017. 821 [I-D.herbert-fast] 822 Herbert, T., "Firewall and Service Tickets", draft- 823 herbert-fast-03 (work in progress), September 2018. 825 [I-D.ietf-6man-segment-routing-header] 826 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 827 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 828 (SRH)", draft-ietf-6man-segment-routing-header-16 (work in 829 progress), February 2019. 831 [I-D.ietf-anima-autonomic-control-plane] 832 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 833 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 834 plane-18 (work in progress), August 2018. 836 [I-D.ietf-anima-reference-model] 837 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 838 and J. Nobre, "A Reference Model for Autonomic 839 Networking", draft-ietf-anima-reference-model-10 (work in 840 progress), November 2018. 842 [I-D.ietf-detnet-architecture] 843 Finn, N., Thubert, P., Varga, B., and J. Farkas, 844 "Deterministic Networking Architecture", draft-ietf- 845 detnet-architecture-11 (work in progress), February 2019. 847 [I-D.ietf-detnet-dp-sol] 848 Korhonen, J., Andersson, L., Jiang, Y., Finn, N., Varga, 849 B., Farkas, J., Bernardos, C., Mizrahi, T., and L. Berger, 850 "DetNet Data Plane Encapsulation", draft-ietf-detnet-dp- 851 sol-04 (work in progress), March 2018. 853 [I-D.ietf-detnet-use-cases] 854 Grossman, E., "Deterministic Networking Use Cases", draft- 855 ietf-detnet-use-cases-20 (work in progress), December 856 2018. 858 [I-D.ietf-homenet-simple-naming] 859 Lemon, T., Migault, D., and S. Cheshire, "Homenet Naming 860 and Service Discovery Architecture", draft-ietf-homenet- 861 simple-naming-03 (work in progress), October 2018. 863 [I-D.ietf-intarea-frag-fragile] 864 Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 865 and F. Gont, "IP Fragmentation Considered Fragile", draft- 866 ietf-intarea-frag-fragile-09 (work in progress), February 867 2019. 869 [I-D.ietf-ipwave-vehicular-networking] 870 Jeong, J., "IP Wireless Access in Vehicular Environments 871 (IPWAVE): Problem Statement and Use Cases", draft-ietf- 872 ipwave-vehicular-networking-07 (work in progress), 873 November 2018. 875 [I-D.ietf-opsec-ipv6-eh-filtering] 876 Gont, F. and W. LIU, "Recommendations on the Filtering of 877 IPv6 Packets Containing IPv6 Extension Headers", draft- 878 ietf-opsec-ipv6-eh-filtering-06 (work in progress), July 879 2018. 881 [I-D.irtf-nfvrg-gaps-network-virtualization] 882 Bernardos, C., Rahman, A., Zuniga, J., Contreras, L., 883 Aranda, P., and P. Lynch, "Network Virtualization Research 884 Challenges", draft-irtf-nfvrg-gaps-network- 885 virtualization-10 (work in progress), September 2018. 887 [I-D.jiang-semantic-prefix] 888 Jiang, S., Qiong, Q., Farrer, I., Bo, Y., and T. Yang, 889 "Analysis of Semantic Embedded IPv6 Address Schemas", 890 draft-jiang-semantic-prefix-06 (work in progress), July 891 2013. 893 [I-D.moulchan-nmrg-network-intent-concepts] 894 Sivakumar, K. and M. Chandramouli, "Concepts of Network 895 Intent", draft-moulchan-nmrg-network-intent-concepts-00 896 (work in progress), October 2017. 898 [I-D.voyer-6man-extension-header-insertion] 899 daniel.voyer@bell.ca, d., Leddy, J., Filsfils, C., Dukes, 900 D., Previdi, S., and S. Matsushima, "Insertion of IPv6 901 Segment Routing Headers in a Controlled Domain", draft- 902 voyer-6man-extension-header-insertion-05 (work in 903 progress), January 2019. 905 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 906 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 907 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, 908 September 1997, . 910 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 911 "Definition of the Differentiated Services Field (DS 912 Field) in the IPv4 and IPv6 Headers", RFC 2474, 913 DOI 10.17487/RFC2474, December 1998, 914 . 916 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 917 DOI 10.17487/RFC2775, February 2000, 918 . 920 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 921 RFC 2923, DOI 10.17487/RFC2923, September 2000, 922 . 924 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 925 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 926 . 928 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 929 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 930 . 932 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 933 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 934 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 935 April 2007, . 937 [RFC4924] Aboba, B., Ed. and E. Davies, "Reflections on Internet 938 Transparency", RFC 4924, DOI 10.17487/RFC4924, July 2007, 939 . 941 [RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for 942 the IPv6 Flow Label", RFC 6294, DOI 10.17487/RFC6294, June 943 2011, . 945 [RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and 946 Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October 947 2011, . 949 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 950 RFC 6455, DOI 10.17487/RFC6455, December 2011, 951 . 953 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 954 "Architectural Considerations on Application Features in 955 the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, 956 . 958 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 959 of IPv6 Extension Headers", RFC 7045, 960 DOI 10.17487/RFC7045, December 2013, 961 . 963 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 964 Constrained-Node Networks", RFC 7228, 965 DOI 10.17487/RFC7228, May 2014, 966 . 968 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 969 Weil, "IPv6 Home Networking Architecture Principles", 970 RFC 7368, DOI 10.17487/RFC7368, October 2014, 971 . 973 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 974 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 975 Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, 976 . 978 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 979 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 980 . 982 [RFC7663] Trammell, B., Ed. and M. Kuehlewind, Ed., "Report from the 983 IAB Workshop on Stack Evolution in a Middlebox Internet 984 (SEMI)", RFC 7663, DOI 10.17487/RFC7663, October 2015, 985 . 987 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 988 Chaining (SFC) Architecture", RFC 7665, 989 DOI 10.17487/RFC7665, October 2015, 990 . 992 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 993 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 994 2016, . 996 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 997 "Observations on the Dropping of Packets with IPv6 998 Extension Headers in the Real World", RFC 7872, 999 DOI 10.17487/RFC7872, June 2016, 1000 . 1002 [RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1003 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1004 March 2017, . 1006 [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- 1007 in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, 1008 March 2017, . 1010 [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection 1011 Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, 1012 March 2017, . 1014 [RFC8151] Yong, L., Dunbar, L., Toy, M., Isaac, A., and V. Manral, 1015 "Use Cases for Data Center Network Virtualization Overlay 1016 Networks", RFC 8151, DOI 10.17487/RFC8151, May 2017, 1017 . 1019 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1020 (IPv6) Specification", STD 86, RFC 8200, 1021 DOI 10.17487/RFC8200, July 2017, 1022 . 1024 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 1025 "Network Service Header (NSH)", RFC 8300, 1026 DOI 10.17487/RFC8300, January 2018, 1027 . 1029 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1030 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1031 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1032 July 2018, . 1034 [RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C. 1035 Jacquenet, "An Inventory of Transport-Centric Functions 1036 Provided by Middleboxes: An Operator Perspective", 1037 RFC 8517, DOI 10.17487/RFC8517, February 2019, 1038 . 1040 Appendix A. Change log [RFC Editor: Please remove] 1042 draft-carpenter-limited-domains-00, 2018-06-11: 1044 Initial version 1046 draft-carpenter-limited-domains-01, 2018-07-01: 1048 Minor terminology clarifications 1050 draft-carpenter-limited-domains-02, 2018-08-03: 1052 Additions following IETF102 discussions 1053 Updated authorship/contributors 1055 draft-carpenter-limited-domains-03, 2018-09-12: 1057 First draft of taxonomy 1059 Editorial improvements 1061 draft-carpenter-limited-domains-04, 2018-10-14: 1063 Reorganized section 3 1065 Newly written sections 6 and 7 1067 Editorial improvements 1069 draft-carpenter-limited-domains-05, 2018-12-12: 1071 Added discussion of transparency/filtering debates 1073 Added discussion of "controlled environment" 1075 Modified assertion about localized standards 1077 Editorial improvements 1079 draft-carpenter-limited-domains-06, 2019-03-02: 1081 Minor updates, fixed reference nits 1083 Authors' Addresses 1085 Brian Carpenter 1086 The University of Auckland 1087 School of Computer Science 1088 University of Auckland 1089 PB 92019 1090 Auckland 1142 1091 New Zealand 1093 Email: brian.e.carpenter@gmail.com 1094 Bing Liu 1095 Huawei Technologies 1096 Q14, Huawei Campus 1097 No.156 Beiqing Road 1098 Hai-Dian District, Beijing 100095 1099 P.R. China 1101 Email: leo.liubing@huawei.com