idnits 2.17.1 draft-carpenter-limited-domains-04.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 (October 14, 2018) is 1992 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.herbert-fast' is defined on line 786, but no explicit reference was found in the text == 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-14 == Outdated reference: A later version (-30) exists of draft-ietf-anima-autonomic-control-plane-18 == Outdated reference: A later version (-10) exists of draft-ietf-anima-reference-model-08 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-08 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-use-cases-19 == Outdated reference: A later version (-03) exists of draft-ietf-homenet-simple-naming-02 == Outdated reference: A later version (-30) exists of draft-ietf-ipwave-vehicular-networking-04 == 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-04 Summary: 0 errors (**), 0 flaws (~~), 12 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: April 17, 2019 Huawei Technologies 6 October 14, 2018 8 Limited Domains and Internet Protocols 9 draft-carpenter-limited-domains-04 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 and emerging solutions, and develops a related 19 taxonomy. It then briefly discusses the standardization of protocols 20 for limited domains. Finally, it shows the needs for a precise 21 definition of limited domain membership and for mechanisms to allow 22 nodes to join a domain securely and to find other members, including 23 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 April 17, 2019. 42 Copyright Notice 44 Copyright (c) 2018 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 . . . . . . . . . . . . . . 3 61 3. Examples of Limited Domain Requirements . . . . . . . . . . . 4 62 4. Examples of Limited Domain Solutions . . . . . . . . . . . . 7 63 5. Taxonomy of Limited Domains . . . . . . . . . . . . . . . . . 9 64 5.1. The Domain as a Whole . . . . . . . . . . . . . . . . . . 10 65 5.2. Individual Nodes . . . . . . . . . . . . . . . . . . . . 10 66 5.3. The Domain Boundary . . . . . . . . . . . . . . . . . . . 10 67 5.4. Topology . . . . . . . . . . . . . . . . . . . . . . . . 11 68 5.5. Technology . . . . . . . . . . . . . . . . . . . . . . . 11 69 5.6. Connection to the Internet . . . . . . . . . . . . . . . 11 70 5.7. Security, Trust and Privacy Model . . . . . . . . . . . . 12 71 5.8. Operations . . . . . . . . . . . . . . . . . . . . . . . 12 72 5.9. Making use of this taxonomy . . . . . . . . . . . . . . . 12 73 6. The Scope of Protocols in Limited Domains . . . . . . . . . . 12 74 7. Functional Requirements of Limited Domains . . . . . . . . . 14 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 77 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 78 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 79 12. Informative References . . . . . . . . . . . . . . . . . . . 16 80 Appendix A. Change log [RFC Editor: Please remove] . . . . . . . 21 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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. 110 The requirements of limited domains will be different in different 111 scenarios. Policies, default parameters, and the options supported 112 may vary. Also, the style of network management may vary, between a 113 completely unmanaged network, one with fully autonomic management, 114 one with traditional central management, and mixtures of the above. 115 Finally, the requirements and solutions for security and privacy may 116 vary. 118 This documents analyses and discusses some of the consequences of 119 this trend, and how it impacts the idea of universal interoperability 120 in the Internet. Firstly we list examples of limited domain 121 scenarios and of technical solutions for limited domains, with the 122 main focus being the Internet layer of the protocol stack. Then we 123 develop a taxonomy of the features to be found in limited domains. 124 With this background, we discuss the resulting challenge to the 125 notion that all Internet standards must be universal in scope and 126 applicability. To the contrary, we assert that some protocols need 127 to be specifically limited in their applicability. This implies that 128 the concepts of a limited domain, and of its membership, need to be 129 formalised and supported by secure mechanisms. While this document 130 does not propose a design for such mechanisms, it does outline some 131 resulting functional requirements. 133 2. Failure Modes in Today's Internet 135 Today, the Internet does not have a well-defined concept of limited 136 domains. One result of this is that certain protocols and features 137 fail on certain paths. Previously, this has been analysed in terms 138 of transparency [RFC2775], [RFC4924] or of intrusive middleboxes 139 [RFC3234], [RFC7663], [I-D.dolson-plus-middlebox-benefits]. 140 Unfortunately the problems persist, both in application protocols, 141 and even in very fundamental mechanisms. For example, the Internet 142 is not transparent to IPv6 extension headers [RFC7872], and Path MTU 143 Discovery has been unreliable for many years [RFC2923], [RFC4821]. 144 IP fragmentation is also unreliable 146 [I-D.bonica-intarea-frag-fragile], and problems in TCP MSS 147 negotiation have been reported [I-D.andrews-tcp-and-ipv6-use-minmtu]. 149 On the security side, the widespread insertion of firewalls at domain 150 boundaries that are perceived by humans but unknown to protocols 151 results in arbitrary failure modes as far as the application layer is 152 concerned. 154 This situation is not acceptable, so it seems that a new approach is 155 needed. 157 3. Examples of Limited Domain Requirements 159 This section describes various examples where limited domain 160 requirements can easily be identified, either based on an application 161 scenario or on a technical imperative. It is of course not a 162 complete list, and it is presented in an arbitrary order, loosely 163 from smaller to bigger. 165 1. A home network. It will be unmanaged, constructed by a non- 166 specialist, and will possibly include wiring errors such as 167 physical loops. It must work with devices "out of the box" as 168 shipped by their manufacturers and must create adequate security 169 by default. Remote access may be required. The requirements 170 and applicable principles are summarised in [RFC7368]. 172 2. A small office network. This is sometimes very similar to a 173 home network, if whoever is in charge has little or no 174 specialist knowledge, but may have differing security and 175 privacy requirements. In other cases it may be professionally 176 constructed using recommended products and configurations, but 177 operate unmanaged. Remote access may be required. 179 3. A vehicle network. This will be designed by the vehicle 180 manufacturer but may include devices added by the vehicle's 181 owner or operator. Parts of the network will have demanding 182 performance and reliability requirements with implications for 183 human safety. Remote access may be required to certain 184 functions, but absolutely forbidden for others. Communication 185 with other vehicles, roadside infrastructure, and external data 186 sources will be required. See 187 [I-D.ietf-ipwave-vehicular-networking] for a survey of use 188 cases. 190 4. Supervisory Control And Data Acquisition (SCADA) networks, and 191 other hard real time networks. These will exhibit specific 192 technical requirements, including tough real-time performance 193 targets. See for example [I-D.ietf-detnet-use-cases] for 194 numerous use cases. An example is a building services network. 195 This will be designed specifically for a particular building, 196 but using standard components. Additional devices may need to 197 be added at any time. Parts of the network may have demanding 198 reliability requirements with implications for human safety. 199 Remote access may be required to certain functions, but 200 absolutely forbidden for others. 202 5. Sensor networks. The two preceding cases will all include 203 sensors, but some networks may be specifically limited to 204 sensors and the collection and processing of sensor data. They 205 may be in remote or technically challenging locations and 206 installed by non-specialists. 208 6. Internet of Things (IoT) networks. While this term is very 209 flexible and covers many innovative types of network, including 210 ad hoc networks that are formed spontaneously, it seems 211 reasonable to expect that IoT edge networks will have special 212 requirements and protocols that are useful only within a 213 specific domain, and that these protocols cannot, and for 214 security reasons should not, run over the Internet as a whole. 216 7. An important subclass of IoT networks consists of constrained 217 networks [RFC7228] in which the nodes are limited in power 218 consumption and communications bandwidth, and are therefore 219 limited to using very frugal protocols. 221 8. Delay tolerant networks may consist of domains that are 222 relatively isolated and constrained in power (e.g. deep space 223 networks) and are connected only intermittently to the outside, 224 with a very long latency on such connections [RFC4838]. Clearly 225 the protocol requirements and possibilities are very specialised 226 in such networks. 228 9. "Traditional" enterprise and campus networks, which may be 229 spread over many kilometres and over multiple separate sites, 230 with multiple connections to the Internet. Interestingly, the 231 IETF appears never to have analysed this long-established class 232 of networks in a general way, except in connection with IPv6 233 deployment (e.g. [RFC7381]). 235 10. Data centres and hosting centres, or distributed services acting 236 as such centres. These will have high performance, security and 237 privacy requirements and will typically include large numbers of 238 independent "tenant" networks overlaid on shared infrastructure. 240 11. Content Delivery Networks (CDNs), comprising distributed data 241 centres and the paths between them, spanning thousands of 242 kilometres, with numerous connections to the Internet. 244 12. Massive Web Service Provider Networks. This is a small class of 245 networks with well known trademarked names, combining aspects of 246 distributed enterprise networks, data centres and CDNs. They 247 have their own international networks bypassing the generic 248 carriers. Like CDNs, they have numerous connections to the 249 Internet, typically offering a tailored service in each economy. 251 Three other aspects, while not tied to specific network types, also 252 strongly depend on the concept of limited domains: 254 1. Intent Based Networking. In this concept, a network domain is 255 configured and managed in accordance with an abstract policy 256 known as "Intent", to ensure that the network performs as 257 required [I-D.moulchan-nmrg-network-intent-concepts]. Whatever 258 technologies are used to support this, they will be applied 259 within the domain boundary. 261 2. Many of the above types of network may be extended throughout the 262 Internet by a variety of virtual private network (VPN) 263 techniques. Therefore we may argue that limited domains may 264 overlap each other in an arbitrary fashion by use of 265 virtualization techniques. 267 3. Network Slicing. A network slice is a virtual network that 268 consists of a managed set of resources carved off from a larger 269 network [I-D.geng-netslices-architecture]. Whatever technologies 270 are used to support slicing, they will require a clear definition 271 of the boundary of a given slice. 273 While it is clearly desirable to use common solutions, and therefore 274 common standards, wherever possible, it is increasingly difficult to 275 do so while satisfying the widely varying requirements outlined 276 above. However, there is a tendency when new protocols and protocol 277 extensions are proposed to always ask the question "How will this 278 work across the open Internet?" This document suggests that this is 279 not always the right question. There are protocols and extensions 280 that are not intended to work across the open Internet. On the 281 contrary, their requirements and semantics are specifically limited 282 (in the sense defined above). 284 A common argument is that if a protocol is intended for limited use, 285 the chances are very high that it will in fact be used (or misused) 286 in other scenarios including the so-called open Internet. This is 287 undoubtedly true and means that limited use is not an excuse for bad 288 design or poor security. In fact, a limited use requirement 289 potentially adds complexity to both the protocol and its security 290 design, as discussed later. 292 Nevertheless, because of the diversity of limited environments with 293 specific requirements that is now emerging, specific standards will 294 necessarily emerge. There will be attempts to capture each market 295 sector, but the market will demand standardised limited solutions. 296 However, the "open Internet" must remain as the universal method of 297 interconnection. Reconciling these two aspects is a major challenge. 299 4. Examples of Limited Domain Solutions 301 This section lists various examples of specific limited domain 302 solutions that have been proposed or defined. It intentionally does 303 not include Layer 2 technology solutions, which by definition apply 304 to limited domains. 306 1. Differentiated Services. This mechanism [RFC2474] allows a 307 network to assign locally significant values to the 6-bit 308 Differentiated Services Code Point field in any IP packet. 309 Although there are some recommended codepoint values for 310 specific per-hop queue management behaviours, these are 311 specifically intended to be domain-specific codepoints with 312 traffic being classified, conditioned and re-marked at domain 313 boundaries (unless there is an inter-domain agreement that makes 314 re-marking unnecessary). 316 2. Network function virtualisation. As described in 317 [I-D.irtf-nfvrg-gaps-network-virtualization], this general 318 concept is an open research topic, in which virtual network 319 functions are orchestrated as part of a distributed system. 320 Inevitably such orchestration applies to an administrative 321 domain of some kind, even though cross-domain orchestration is 322 also a research area. 324 3. Service Function Chaining (SFC). This technique [RFC7665] 325 assumes that services within a network are constructed as 326 sequences of individual functions within a specific SFC-enabled 327 domain. As that RFC states: "Specific features may need to be 328 enforced at the boundaries of an SFC-enabled domain, for example 329 to avoid leaking SFC information". A Network Service Header 330 (NSH) [RFC8300] is used to encapsulate packets flowing through 331 the service function chain: "The intended scope of the NSH is 332 for use within a single provider's operational domain." 334 4. Firewall and Service Tickets (FAST). Such tickets would 335 accompany a packet to claim the right to traverse a network or 336 request a specific network service [I-D.herbert-fast]". They 337 would only be valid within a particular domain. 339 5. Data Centre Network Virtualization Overlays. A common 340 requirement in data centres that host many tenants (clients) is 341 to provide each one with a secure private network, all running 342 over the same physical infrastructure. [RFC8151] describes 343 various use cases for this, and specifications are under 344 development. These include use cases in which the tenant 345 network is physically split over several data centres, but which 346 must appear to the user as a single secure domain. 348 6. Segment Routing. This is a technique which "steers a packet 349 through an ordered list of instructions, called segments" 350 [I-D.ietf-spring-segment-routing]. The semantics of these 351 instructions are explicitly local to a segment routing domain or 352 even to a single node. Technically, these segments or 353 instructions are represented as an MPLS label or an IPv6 354 address, which clearly adds a semantic interpretation to them 355 within the domain. 357 7. Autonomic Networking. As explained in 358 [I-D.ietf-anima-reference-model], an autonomic network is also a 359 security domain within which an autonomic control plane 360 [I-D.ietf-anima-autonomic-control-plane] is used by service 361 agents. These service agents manage technical objectives, which 362 may be locally defined, subject to domain-wide policy. Thus the 363 domain boundary is important for both security and protocol 364 purposes. 366 8. Homenet. As shown in [RFC7368], a home networking domain has 367 specific protocol needs that differ from those in an enterprise 368 network or the Internet as a whole. These include the Home 369 Network Control Protocol (HNCP) [RFC7788] and a naming and 370 discovery solution [I-D.ietf-homenet-simple-naming]. 372 9. Creative uses of IPv6 features. As IPv6 enters more general 373 use, engineers notice that it has much more flexibility than 374 IPv4. Innovative suggestions have been made for: 376 * The flow label, e.g. [RFC6294], 377 [I-D.fioccola-v6ops-ipv6-alt-mark]. 379 * Extension headers, e.g. for segment routing 380 [I-D.ietf-6man-segment-routing-header]. 382 * Meaningful address bits, e.g. [I-D.jiang-semantic-prefix]. 383 Also, segment routing uses IPv6 addresses as segment 384 identifiers with specific local meanings 385 [I-D.ietf-spring-segment-routing]. 387 All of these suggestions are only viable within a specified 388 domain. The case of the extension header is particularly 389 interesting, since its existence has been a major "selling 390 point" for IPv6, but it is notorious that new extension headers 391 are virtually impossible to deploy across the whole Internet 392 [RFC7045], [RFC7872]. It is worth noting that extension header 393 filtering is considered as an important security issue 394 [I-D.ietf-opsec-ipv6-eh-filtering]. There is considerable 395 appetite among vendors or operators to have flexibility in 396 defining extension headers for use in limited or specialised 397 domains, e.g. [I-D.voyer-6man-extension-header-insertion] and 398 [BIGIP]. 400 10. Deterministic Networking (DetNet). The Deterministic Networking 401 Architecture [I-D.ietf-detnet-architecture] and encapsulation 402 [I-D.ietf-detnet-dp-sol] aim to support flows with extremely low 403 data loss rates and bounded latency, but only within a part of 404 the network that is "DetNet aware". Thus, as for differentiated 405 services above, the concept of a domain is fundamental. 407 11. Provisioning Domains (PvDs). An architecture for Multiple 408 Provisioning Domains has been defined [RFC7556] to allow hosts 409 attached to multiple networks to learn explicit details about 410 the services provided by each of those networks. 412 5. Taxonomy of Limited Domains 414 This section develops a taxonomy for describing limited domains. 415 Several major aspects are considered in this taxonomy: 417 o The domain as a whole. 419 o The individual nodes. 421 o The domain boundary. 423 o The domain's topology. 425 o The domain's technology. 427 o How the domain connects to the Internet. 429 o The security, trust and privacy model. 431 o Operations. 433 The following sub-sections analyse each of these aspects. 435 5.1. The Domain as a Whole 437 o Why does the domain exist? (e.g., human choice, administrative 438 policy, orchestration requirements, technical requirements) 440 o If there are special requirements, are they at Layer 2, Layer 3 or 441 an upper layer? 443 o Is the domain managed by humans or fully autonomic? 445 o If managed, what style of management applies? (Manual 446 configuration, automated configuration, orchestration?) 448 o Is there a policy model? (Intent, configuration policies?) 450 o Does the domain provide controlled or paid service or open access? 452 5.2. Individual Nodes 454 o Is a domain member a complete node, or only one interface of a 455 node? 457 o Are nodes permanent members of a given domain, or are join and 458 leave operations possible? 460 o Are nodes physical or virtual devices? 462 o Are virtual nodes general-purpose, or limited to specific 463 functions, applications or users? 465 o Are nodes constrained (by battery etc)? 467 o Are devices installed "out of the box" or pre-configured? 469 5.3. The Domain Boundary 471 o How is the domain boundary identified or defined? 473 o Is the domain boundary fixed or dynamic? 475 o Are boundary nodes special? Or can any node be at the boundary? 477 5.4. Topology 479 o Is the domain a subset of a layer 2 or 3 connectivity domain? 481 o In IP addressing terms, is the domain Link-local, Site-local, or 482 Global? 484 o Does the domain overlap other domains? (In other words, a node 485 may or may not be allowed to be a member of multiple domains.) 487 o Does the domain match physical topology, or does it have a virtual 488 (overlay) topology? 490 o Is the domain in a single building, vehicle or campus? Or is it 491 distributed? 493 o If distributed, are the interconnections private or over the 494 Internet? 496 o In IP addressing terms, is the domain Link-local, Site-local, or 497 Global? 499 5.5. Technology 501 o In routing terms, what routing protocol(s) are used, or even 502 different forwarding mechanisms (MPLS or other non-IP mechanism)? 504 o In an overlay domain, what overlay technique is used (L2VPN, 505 L3VPN,...)? 507 o Are there specific QoS requirements? 509 o Link latency - normal or long latency links? 511 o Mobility - are nodes mobile? Is the whole network mobile? 513 o Which specific technologies, such as those in Section 4, are 514 applicable? 516 5.6. Connection to the Internet 518 o Is the Internet connection permanent or intermittent? (Never 519 connected is out of scope.) 521 o What traffic is blocked, in and out? 523 o What traffic is allowed, in and out? 524 o What traffic is transformed, in and out? 526 o Is secure and privileged remote access needed? 528 o Does the domain allow unprivileged remote sessions? 530 5.7. Security, Trust and Privacy Model 532 o Must domain members be authorized? 534 o Are all nodes in the domain at the same trust level? 536 o Is traffic authenticated? 538 o Is traffic encrypted? 540 o What is hidden from the outside? 542 5.8. Operations 544 o Safety level - does the domain have a critical (human) safety 545 role? 547 o Reliability requirement - normal or 99.999% ? 549 o Environment - hazardous conditions? 551 o Installation - are specialists needed? 553 o Service visits - easy, difficult, impossible? 555 o Software/firmware updates - possible or impossible? 557 5.9. Making use of this taxonomy 559 This taxonomy could be used to design or analyse a specific type of 560 limited domain. For the present document, it is intended to form a 561 background to the following two sections, concerning the scope of 562 protocols used in limited domains, and mechanisms reuqired to 563 securely define domain membership and properties. 565 6. The Scope of Protocols in Limited Domains 567 One consequence of the deployment of limited domains in the Internet 568 is that some protocols will be designed, extended or configured so 569 that they only work correctly between end systems in such domains. 570 This is to some extent encouraged by some existing standards and by 571 the assignment of code points for local or experimental use. In any 572 case it cannot be prevented. Also, by endorsing efforts such as 573 Service Function Chaining, Segment Routing and Deterministic 574 Networking, the IETF is in effect encouraging such deployments. 575 Furthermore, it seems inevitable, if the "Internet of Things" becomes 576 reality, that millions of edge networks containing completely novel 577 types of node will be connected to the Internet; each one of these 578 edge networks will be a limited domain. 580 It is therefore appropriate to discuss whether protocols or protocol 581 extensions should sometimes be standardised to interoperate only 582 within a Limited Domain Boundary. Such protocols would not be 583 required to interoperate across the Internet as a whole. Several 584 possibly overlapping scenarios could then arise: 586 A. If a limited domain is split into two parts connected over the 587 Internet directly at the IP layer (i.e. with no tunnel 588 encapsulating the packets), a limited-domain protocol could be 589 operated between those two parts regardless of its special nature, 590 as long as it respects standard IP formats and is not arbitrarily 591 blocked by firewalls. A simple example is any protocol using a 592 port number assigned to a specific non-IETF protocol. 594 Such a protocol could reasonably be described as an "inter-domain" 595 protocol because the Internet is transparent to it, even if it is 596 meaningless except in the two parts of the limited domain. This 597 is of course nothing new in the Internet architecture. 599 B. If a limited-domain protocol does not respect standard IP 600 formats (for example, if it includes a non-standard IPv6 extension 601 header), it could not be operated between two parts of a domain 602 split at the IP layer. 604 Such a protocol could reasonably be described as an "intra-domain" 605 protocol, and the Internet is opaque to it. 607 C. If a limited-domain protocol is clearly specified to be 608 invalid outside its domain of origin, neither scenario A nor B 609 applies. The two domains need to be unified as a single virtual 610 domain. For example, an encapsulating tunnel between the parts of 611 the split domain could be used. Also, nodes at the domain 612 boundary must drop all packets using the limited-domain protocol. 614 D. If a limited-domain protocol has domain-specific variants, 615 such that implementations in different domains could not 616 interoperate if those domains were unified by some mechanism, the 617 protocol is not interoperable in the normal sense. If two domains 618 using it were merged, the protocol might fail unpredictably. A 619 simple example is any protocol using a port number assigned for 620 experimental use. Such a protocol usually also falls into 621 scenario C. 623 To provide an existing example, consider Differentiated Services 624 [RFC2474]. A packet containing any value whatever in the 6 bits of 625 the Differentiated Service Code Point (DSCP) is well-formed and falls 626 into scenario A. However, because the semantics of DSCP values are 627 locally significant, the packet also falls into scenario D. In fact, 628 differentiated services are only interoperable across domain 629 boundaries if there is a corresponding agreement between the 630 operators; otherwise a specific gateway function is required for 631 meaningful interoperability. Much more detailed discussion is to be 632 found in [RFC2474] and [RFC8100]. 634 To provide a provocative example, consider the proposal in 635 [I-D.voyer-6man-extension-header-insertion] that the restrictions in 636 [RFC8200] should be relaxed to allow IPv6 extension headers to be 637 inserted on the fly in IPv6 packets. If this is done in such a way 638 that the affected packets can never leave the specific limited domain 639 in which they were modified, scenario C applies. If the semantic 640 content of the inserted headers is locally defined, scenario D also 641 applies. In neither case is the Internet disturbed. 643 We conclude that it is reasonable to explicitly define limited-domain 644 protocols, either as standards or as proprietary mechanisms, as long 645 as they describe which of the above scenarios apply and they clarify 646 how the domain is defined. As long as all relevant standards are 647 respected outside the domain boundary, a well-specified limited- 648 domain protocol is not harmful to the Internet. However, as 649 described in the next section, mechanisms are needed to support 650 domain membership operations. 652 7. Functional Requirements of Limited Domains 654 As the preceding taxonomy shows, there are very numerous aspects to a 655 domain, so the common features are not immediately obvious. It would 656 be possible, but tedious, to apply the taxonomy to each of the domain 657 types described in Section 3. However, we can deduce some generally 658 required features and functions without doing so. 660 Firstly, if we drew a topology map, any domain -- virtual or physical 661 -- will have a well defined boundary between "inside" and "outside". 662 However, that boundary in itself has no technical meaning. What 663 matters in reality is whether a node is a member of the domain, and 664 whether it is at the boundary between the domain and the rest of the 665 Internet. Thus the boundary in itself does not need to be 666 identified. However, a sending node needs to know whether it is 667 sending to an inside or outside destination; a receiving node needs 668 to know whether a packet originated inside or outside; and a boundary 669 node needs to know which of its interfaces are inward-facing or 670 outward-facing. It is irrelevant whether the interfaces involved are 671 physical or virtual. 673 With this perspective, we can list some general functional 674 requirements. An underlying assumption here is that domain 675 membership operations should be cryptographically secured; a domain 676 without such security cannot be reliably protected from attack. 678 1. Domain Identity. A domain must have a unique and verifiable 679 identifier; effectively this should be a public key for the 680 domain. Without this, there is no way to secure domain 681 operations and domain membership. The holder of the 682 corresponding private key becomes the trust anchor for the 683 domain. 685 2. Node Eligibility. It must be possible for a node to determine 686 which domain(s) it can potentially join, and on which 687 interface(s). 689 3. Secure Enrolment. A node must be able to enrol in a given domain 690 via secure node identfication and to acquire relevant security 691 credentials (authorization) for operations within the domain. If 692 a node has multiple physical or virtual interfaces, they may 693 require to be individually enrolled. 695 4. Withdrawal. A node must be able to cancel enrolment in a given 696 domain. 698 5. Dynamic Membership. Optionally, a node should be able 699 temporarily leave or rejoin a domain (i.e. enrolment is 700 persistent but membership is intermittent). 702 6. Role, implying authorization to perform a certain set of actions. 703 A node must have a verifiable role. In the simplest case, the 704 choices of role are "interior node" and "boundary node". In a 705 boundary node, individual interfaces may have different roles, 706 e.g. "inward facing" and "outward facing". 708 7. Verify Peer. A node must be able to verify whether another node 709 is a member of the domain. 711 8. Verify Role. A node must be able to learn the verified role of 712 another node. In particular, it must be possible for a node to 713 find boundary nodes (interfacing to the Internet). 715 9. Domain Data. In a domain with management requirements, it must 716 be possible for a node to acquire domain policy and/or domain 717 configuration data. This would include, for example, filtering 718 policy to ensure that inappropriate packets do not leave the 719 domain. 721 These requirements could form the basis for further analysis and 722 solution design. 724 8. Security Considerations 726 Clearly, the boundary of a limited domain will almost always also act 727 as a security boundary. In particular, it will serve as a trust 728 boundary, and as a boundary of authority for defining capabilities. 729 Within the boundary, limited-domain protocols or protocol features 730 will be useful, but they will be meaningless if they enter or leave 731 the domain. 733 The security model for a limited-scope protocol must allow for the 734 boundary, and in particular for a trust model that changes at the 735 boundary. Typically, credentials will need to be signed by a domain- 736 specific authority. 738 9. IANA Considerations 740 This document makes no request of the IANA. 742 10. Contributors 744 Sheng Jiang made important contributions to this document. 746 11. Acknowledgements 748 Useful comments were received from Amelia Andersdotter, Edward 749 Birrane, Ron Bonica, Tim Chown, Darren Dukes, Tom Herbert, John 750 Klensin, Michael Richardson, Rick Taylor, Niels ten Oever, and other 751 members of the ANIMA and INTAREA WGs. 753 12. Informative References 755 [BIGIP] Li, R., "HUAWEI - Big IP Initiative.", 2018, 756 . 758 [I-D.andrews-tcp-and-ipv6-use-minmtu] 759 Andrews, M., "TCP Fails To Respect IPV6_USE_MIN_MTU", 760 draft-andrews-tcp-and-ipv6-use-minmtu-04 (work in 761 progress), October 2015. 763 [I-D.bonica-intarea-frag-fragile] 764 Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., 765 and F. Gont, "IP Fragmentation Considered Fragile", draft- 766 bonica-intarea-frag-fragile-03 (work in progress), July 767 2018. 769 [I-D.dolson-plus-middlebox-benefits] 770 Dolson, D., Snellman, J., Boucadair, M., and C. Jacquenet, 771 "Beneficial Functions of Middleboxes", draft-dolson-plus- 772 middlebox-benefits-03 (work in progress), March 2017. 774 [I-D.fioccola-v6ops-ipv6-alt-mark] 775 Fioccola, G., Velde, G., Cociglio, M., and P. Muley, "IPv6 776 Performance Measurement with Alternate Marking Method", 777 draft-fioccola-v6ops-ipv6-alt-mark-01 (work in progress), 778 June 2018. 780 [I-D.geng-netslices-architecture] 781 67, 4., Dong, J., Bryant, S., kiran.makhijani@huawei.com, 782 k., Galis, A., Foy, X., and S. Kuklinski, "Network Slicing 783 Architecture", draft-geng-netslices-architecture-02 (work 784 in progress), July 2017. 786 [I-D.herbert-fast] 787 Herbert, T., "Firewall and Service Tickets", draft- 788 herbert-fast-03 (work in progress), September 2018. 790 [I-D.ietf-6man-segment-routing-header] 791 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 792 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 793 (SRH)", draft-ietf-6man-segment-routing-header-14 (work in 794 progress), June 2018. 796 [I-D.ietf-anima-autonomic-control-plane] 797 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic 798 Control Plane (ACP)", draft-ietf-anima-autonomic-control- 799 plane-18 (work in progress), August 2018. 801 [I-D.ietf-anima-reference-model] 802 Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., 803 and J. Nobre, "A Reference Model for Autonomic 804 Networking", draft-ietf-anima-reference-model-08 (work in 805 progress), October 2018. 807 [I-D.ietf-detnet-architecture] 808 Finn, N., Thubert, P., Varga, B., and J. Farkas, 809 "Deterministic Networking Architecture", draft-ietf- 810 detnet-architecture-08 (work in progress), September 2018. 812 [I-D.ietf-detnet-dp-sol] 813 Korhonen, J., Andersson, L., Jiang, Y., Finn, N., Varga, 814 B., Farkas, J., Bernardos, C., Mizrahi, T., and L. Berger, 815 "DetNet Data Plane Encapsulation", draft-ietf-detnet-dp- 816 sol-04 (work in progress), March 2018. 818 [I-D.ietf-detnet-use-cases] 819 Grossman, E., "Deterministic Networking Use Cases", draft- 820 ietf-detnet-use-cases-19 (work in progress), October 2018. 822 [I-D.ietf-homenet-simple-naming] 823 Lemon, T., Migault, D., and S. Cheshire, "Simple Homenet 824 Naming and Service Discovery Architecture", draft-ietf- 825 homenet-simple-naming-02 (work in progress), July 2018. 827 [I-D.ietf-ipwave-vehicular-networking] 828 Jeong, J., "IP Wireless Access in Vehicular Environments 829 (IPWAVE): Problem Statement and Use Cases", draft-ietf- 830 ipwave-vehicular-networking-04 (work in progress), July 831 2018. 833 [I-D.ietf-opsec-ipv6-eh-filtering] 834 Gont, F. and W. LIU, "Recommendations on the Filtering of 835 IPv6 Packets Containing IPv6 Extension Headers", draft- 836 ietf-opsec-ipv6-eh-filtering-06 (work in progress), July 837 2018. 839 [I-D.ietf-spring-segment-routing] 840 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 841 Litkowski, S., and R. Shakir, "Segment Routing 842 Architecture", draft-ietf-spring-segment-routing-15 (work 843 in progress), January 2018. 845 [I-D.irtf-nfvrg-gaps-network-virtualization] 846 Bernardos, C., Rahman, A., Zuniga, J., Contreras, L., 847 Aranda, P., and P. Lynch, "Network Virtualization Research 848 Challenges", draft-irtf-nfvrg-gaps-network- 849 virtualization-10 (work in progress), September 2018. 851 [I-D.jiang-semantic-prefix] 852 Jiang, S., Qiong, Q., Farrer, I., Bo, Y., and T. Yang, 853 "Analysis of Semantic Embedded IPv6 Address Schemas", 854 draft-jiang-semantic-prefix-06 (work in progress), July 855 2013. 857 [I-D.moulchan-nmrg-network-intent-concepts] 858 Sivakumar, K. and M. Chandramouli, "Concepts of Network 859 Intent", draft-moulchan-nmrg-network-intent-concepts-00 860 (work in progress), October 2017. 862 [I-D.voyer-6man-extension-header-insertion] 863 daniel.voyer@bell.ca, d., Leddy, J., Filsfils, C., Dukes, 864 D., Previdi, S., and S. Matsushima, "Insertion of IPv6 865 Segment Routing Headers in a Controlled Domain", draft- 866 voyer-6man-extension-header-insertion-04 (work in 867 progress), June 2018. 869 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 870 "Definition of the Differentiated Services Field (DS 871 Field) in the IPv4 and IPv6 Headers", RFC 2474, 872 DOI 10.17487/RFC2474, December 1998, 873 . 875 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 876 DOI 10.17487/RFC2775, February 2000, 877 . 879 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 880 RFC 2923, DOI 10.17487/RFC2923, September 2000, 881 . 883 [RFC3234] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and 884 Issues", RFC 3234, DOI 10.17487/RFC3234, February 2002, 885 . 887 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 888 Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, 889 . 891 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 892 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 893 Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, 894 April 2007, . 896 [RFC4924] Aboba, B., Ed. and E. Davies, "Reflections on Internet 897 Transparency", RFC 4924, DOI 10.17487/RFC4924, July 2007, 898 . 900 [RFC6294] Hu, Q. and B. Carpenter, "Survey of Proposed Use Cases for 901 the IPv6 Flow Label", RFC 6294, DOI 10.17487/RFC6294, June 902 2011, . 904 [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing 905 of IPv6 Extension Headers", RFC 7045, 906 DOI 10.17487/RFC7045, December 2013, 907 . 909 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 910 Constrained-Node Networks", RFC 7228, 911 DOI 10.17487/RFC7228, May 2014, 912 . 914 [RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J. 915 Weil, "IPv6 Home Networking Architecture Principles", 916 RFC 7368, DOI 10.17487/RFC7368, October 2014, 917 . 919 [RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V., 920 Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment 921 Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014, 922 . 924 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 925 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 926 . 928 [RFC7663] Trammell, B., Ed. and M. Kuehlewind, Ed., "Report from the 929 IAB Workshop on Stack Evolution in a Middlebox Internet 930 (SEMI)", RFC 7663, DOI 10.17487/RFC7663, October 2015, 931 . 933 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 934 Chaining (SFC) Architecture", RFC 7665, 935 DOI 10.17487/RFC7665, October 2015, 936 . 938 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 939 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 940 2016, . 942 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 943 "Observations on the Dropping of Packets with IPv6 944 Extension Headers in the Real World", RFC 7872, 945 DOI 10.17487/RFC7872, June 2016, 946 . 948 [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection 949 Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, 950 March 2017, . 952 [RFC8151] Yong, L., Dunbar, L., Toy, M., Isaac, A., and V. Manral, 953 "Use Cases for Data Center Network Virtualization Overlay 954 Networks", RFC 8151, DOI 10.17487/RFC8151, May 2017, 955 . 957 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 958 (IPv6) Specification", STD 86, RFC 8200, 959 DOI 10.17487/RFC8200, July 2017, 960 . 962 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 963 "Network Service Header (NSH)", RFC 8300, 964 DOI 10.17487/RFC8300, January 2018, 965 . 967 Appendix A. Change log [RFC Editor: Please remove] 969 draft-carpenter-limited-domains-00, 2018-06-11: 971 Initial version 973 draft-carpenter-limited-domains-01, 2018-07-01: 975 Minor terminology clarifications 977 draft-carpenter-limited-domains-02, 2018-08-03: 979 Additions following IETF102 discussions 981 Updated authorship/contributors 983 draft-carpenter-limited-domains-03, 2018-09-12: 985 First draft of taxonomy 987 Editorial improvements 989 draft-carpenter-limited-domains-04, 2018-10-14: 991 Reorganized section 3 993 Newly written sections 6 and 7 995 Editorial improvements 997 Authors' Addresses 999 Brian Carpenter 1000 Department of Computer Science 1001 University of Auckland 1002 PB 92019 1003 Auckland 1142 1004 New Zealand 1006 Email: brian.e.carpenter@gmail.com 1008 Bing Liu 1009 Huawei Technologies 1010 Q14, Huawei Campus 1011 No.156 Beiqing Road 1012 Hai-Dian District, Beijing 100095 1013 P.R. China 1015 Email: leo.liubing@huawei.com