idnits 2.17.1 draft-ietf-capport-architecture-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (March 17, 2018) is 2225 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7710 (Obsoleted by RFC 8910) == Outdated reference: A later version (-11) exists of draft-ietf-intarea-provisioning-domains-01 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force K. Larose 3 Internet-Draft Sandvine 4 Intended status: Informational D. Dolson 5 Expires: September 18, 2018 March 17, 2018 7 CAPPORT Architecture 8 draft-ietf-capport-architecture-01 10 Abstract 12 This document aims to document consensus on the CAPPORT architecture. 13 DHCP or Router Advertisements, ICMP, and an HTTP API are used to 14 provide the solution. The role of Provisioning Domains (PvDs) is 15 described. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on September 18, 2018. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Components . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.1. User Equipment . . . . . . . . . . . . . . . . . . . . . 5 56 2.2. Provisioning Service . . . . . . . . . . . . . . . . . . 6 57 2.2.1. DHCP or Router Advertisements . . . . . . . . . . . . 6 58 2.2.2. Provisioning Domains . . . . . . . . . . . . . . . . 6 59 2.3. Captive Portal API Server . . . . . . . . . . . . . . . . 7 60 2.4. Captive Portal Enforcement . . . . . . . . . . . . . . . 7 61 2.5. ICMP/ICMP6 . . . . . . . . . . . . . . . . . . . . . . . 8 62 2.6. Component Diagram . . . . . . . . . . . . . . . . . . . . 9 63 3. User Equipment Identity . . . . . . . . . . . . . . . . . . . 10 64 3.1. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 10 65 3.2. Recommended Properties . . . . . . . . . . . . . . . . . 10 66 3.2.1. Uniquely Identify User Equipment . . . . . . . . . . 11 67 3.2.2. Hard to Spoof . . . . . . . . . . . . . . . . . . . . 11 68 3.2.3. Visible to the API . . . . . . . . . . . . . . . . . 11 69 3.2.4. Visible to the Enforcement Device . . . . . . . . . . 11 70 3.3. Evaluating an Identifier . . . . . . . . . . . . . . . . 12 71 3.4. Examples of an Identifier . . . . . . . . . . . . . . . . 12 72 3.4.1. Physical Interface . . . . . . . . . . . . . . . . . 12 73 3.4.2. IP Address . . . . . . . . . . . . . . . . . . . . . 13 74 4. Solution Workflow . . . . . . . . . . . . . . . . . . . . . . 13 75 4.1. Initial Connection . . . . . . . . . . . . . . . . . . . 14 76 4.2. Conditions Expire . . . . . . . . . . . . . . . . . . . . 14 77 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 80 7.1. Trusting the Network . . . . . . . . . . . . . . . . . . 15 81 7.2. Authenticated APIs . . . . . . . . . . . . . . . . . . . 16 82 7.3. Secure APIs . . . . . . . . . . . . . . . . . . . . . . . 16 83 7.4. Risk of Nuisance Captive Portal . . . . . . . . . . . . . 16 84 7.5. User Options . . . . . . . . . . . . . . . . . . . . . . 17 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 87 8.2. Informative References . . . . . . . . . . . . . . . . . 17 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 90 1. Introduction 92 In this document, "Captive Portal" is used to describe a network to 93 which a device may be voluntarily attached, such that network access 94 is limited until some requirements have been fulfilled. Typically a 95 user is required to use a web browser to fulfil requirements imposed 96 by the network operator, such as reading advertisements, accepting an 97 acceptable-use policy, or providing some form of credentials. 99 Implementations generally require a web server, some method to allow/ 100 block traffic, and some method to alert the user. Common methods of 101 alerting the user involve modifying HTTP or DNS traffic. 103 Problems with captive portal implementations have been described in 104 [I-D.nottingham-capport-problem]. [If that document cannot be 105 published, consider putting its best parts into an appendix of this 106 document.] 108 This document standardizes an architecture for implementing captive 109 portals that provides tools for addressing most of those problems. 110 We are guided by these principles: 112 o Solutions SHOULD NOT require the forging of responses from DNS or 113 HTTP servers, or any other protocol. In particular, solutions 114 SHOULD NOT require man-in-the-middle proxy of TLS traffic. 116 o Solutions MUST operate at the layer of Internet Protocol (IP) or 117 above, not being specific to any particular access technology such 118 as Cable, WiFi or 3GPP. 120 o Solutions SHOULD allow a device to be alerted that it is in a 121 captive network when attempting to use any application on the 122 network. (Versus requiring a user to visit a clear-text HTTP site 123 in order to receive a notification.) 125 o Solutions SHOULD allow a device to learn that it is in a captive 126 network before any application attempts to use the network. 128 o The state of captivity SHOULD be explicitly available to devices 129 (in contrast to modification of DNS or HTTP, which is only 130 indirectly machine-detectable by the client--by comparing 131 responses to well-known queries with expected responses). 133 o The architecture MUST provide a path of incremental migration, 134 acknowledging a huge variety of portals and end-user device 135 implementations and software versions. 137 o The architecture SHOULD improve security by providing mechanisms 138 for trust, allowing alerts from trusted network operators to be 139 distinguished from attacks from untrusted agents. 141 A side-benefit of the architecture described in this document is that 142 devices without user interfaces are able to identify parameters of 143 captivity. However, this document does not yet describe a mechanism 144 for such devices to escape captivity. 146 The architecture uses the following mechanisms: 148 o Network provisioning protocols provide end-user devices with a URI 149 for the API that end-user devices query for information about what 150 is required to escape captivity. DHCP, DHCPv6, and Router- 151 Advertisement options for this purpose are available in [RFC7710]. 152 Other protocols (such as RADIUS), Provisioning Domains 153 [I-D.ietf-intarea-provisioning-domains], or static configuration 154 may also be used. A device MAY query this API at any time to 155 determine whether the network is holding the device in a captive 156 state. 158 o End-user devices are notified of captivity with ICMP/ICMP6 159 messages in response to traffic. This notification can work with 160 any Internet protocol, not just clear-text HTTP. This 161 notification does not carry the portal URI; rather it provides a 162 notification to the User Equipment that it is in a captive state. 164 o Receipt of the ICMP/ICMP6 messages informs an end-user device that 165 it is captive. In response, the device SHOULD query the 166 provisioned API to obtain information about the network state. 167 The device MAY take immediate action to satisfy the portal 168 (according to its configuration/policy). 170 The architecture attempts to provide privacy, authentication, and 171 safety mechanisms to the extent possible. 173 1.1. Requirements Language 175 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 176 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 177 document are to be interpreted as described in RFC 2119 [RFC2119]. 179 1.2. Terminology 181 Captive Network: A network which limits communication of attached 182 devices to restricted hosts until the user has satisfied Captive 183 Portal Conditions, after which access is permitted to a wider set of 184 hosts (typically the internet). 186 Captive Portal Conditions: site-specific requirements that a user or 187 device must satisfy in order to gain access to the wider network. 189 Captive Portal Enforcement: The network equipment which enforces the 190 traffic restriction and notifies the User Equipment it is in a 191 captive state. 193 Captive Portal User Equipment: Also known as User Equipment. A 194 device which has voluntarily joined a network for purposes of 195 communicating beyond the constraints of the captive network. 197 Captive Portal Server: The web server providing a user interface for 198 assisting the user in satisfying the conditions to escape captivity. 200 2. Components 202 2.1. User Equipment 204 The User Equipment is the device that a user desires to be attached 205 to a network with full access to all hosts on the network (e.g., to 206 have Internet access). The User Equipment communication is typically 207 restricted by the Captive Portal Enforcement, described in 208 Section 2.4, until site-specific requirements have been met. 210 At this time we consider only devices with web browsers, with web 211 applications being the means of satisfying Captive Portal Conditions. 213 o An example interactive User Equipment is a smart phone. 215 o SHOULD support provisioning of the URI for the Captive Portal API 216 (e.g., by DHCP) 218 o SHOULD distinguish Captive Portal API access per network 219 interface, in the manner of Provisioning Domain Architecture 220 [RFC7556]. 222 o SHOULD have a mechanism for notifying the user of the Captive 223 Portal 225 o SHOULD have a web browser so that the user may navigate the 226 Captive Portal user interface. 228 o SHOULD be able to receive and validate the Captive Portal ICMP 229 message types, and to access the Captive Portal API in response. 231 o MAY restrict application access to networks not granting full 232 network access. E.g., a device connected to a mobile network may 233 be connecting to a WiFi network; the operating system MAY avoid 234 updating the default route until network access restrictions have 235 been lifted (excepting access to the Captive Portal server). This 236 has been termed "make before break". 238 None of the above requirements are mandatory because (a) we do not 239 wish to say users or devices must seek access beyond the captive 240 network, (b) the requirements may be fulfilled by manually visiting 241 the captive portal web application, and (c) legacy devices must 242 continue to be supported. 244 2.2. Provisioning Service 246 Here we discuss candidate mechanisms for provisioning the User 247 Equipment with the URI of the API to query captive portal state and 248 navigate the portal. 250 2.2.1. DHCP or Router Advertisements 252 A standard for providing a portal URI using DHCP or Router 253 Advertisements is described in [RFC7710]. The CAPPORT architecture 254 expects this URI to indicate the API described in Section 2.3. 256 Although it is not clear from RFC7710 what protocol should be 257 executed at the specified URI, some readers might have assumed it to 258 be an HTML page, and hence there might be User Equipment assuming a 259 browser should open this URI. For backwards compatibility, it is 260 RECOMMENDED that the server check the "Accept" field when serving the 261 URI, and serve HTML pages for "text/html" and serve the API for 262 "application/json". [REVISIT: are these details appropriate?] 264 2.2.2. Provisioning Domains 266 Although still a work in progress, 267 [I-D.ietf-intarea-provisioning-domains] proposes a mechanism for User 268 Equipment to be provided with PvD Bootstrap Information containing 269 the URI for a JSON file containing key-value pairs to be downloaded 270 over HTTPS. This JSON file would fill the role of the Captive Portal 271 API described in Section 2.3. 273 The PvD security model provides secure binding between the 274 information provided by the trusted Router Advertisement and the 275 HTTPS server. 277 One key-value pair can be used to indicate the network has restricted 278 access, requiring captive portal navigation by a user. E.g., 279 key="captivePortal" and value=. The key-value pair 280 should provide a different result when access is not restricted. 281 E.g., key="captivePortal" and value="". 283 This JSON file is extensible, allowing new key-value pairs to 284 indicate such things as network access expiry time, URI for API 285 access by IOT devices, etc. 287 The PvD server MUST support multiple (repeated) queries from each 288 User Equipment, always returning the current captive portal 289 information. The User Equipment is expected to make this query upon 290 receiving (and validating) an ICMP Captive Portal message (see 291 Section 2.5). 293 2.3. Captive Portal API Server 295 The purpose of a Captive Portal API is to permit a query of Captive 296 Portal state without interrupting the user. This API thereby removes 297 the need for a device to perform clear-text "canary" HTTP queries to 298 check for response tampering. 300 The URI of this API will have been provisioned to the User Equipment. 301 (Refer to Section 2.2). 303 This architecture expects the User Equipment to query the API when 304 the User Equipment attaches to the network and multiple times 305 thereafter. Therefore the API MUST support multiple repeated queries 306 from the same User Equipment, returning current state of captivity 307 for the equipment. 309 At minimum the API MUST provide: (1) the state of captivity and (2) a 310 URI for a browser to present the portal application to the user. The 311 API SHOULD provide evidence to the caller that it supports the 312 present architecture. 314 When user equipment receives (and validates) ICMP Captive Portal 315 alerts, the user equipment SHOULD query the API to check the state. 316 The User Equipment SHOULD rate-limit these API queries in the event 317 of ICMP flooding by an attacker. (See Section 7.) 319 The API MUST be extensible to support future use-cases by allowing 320 extensible information elements. Suggestions include quota 321 information, expiry time, method of providing credentials, security 322 token for validating ICMP messages. 324 The API MUST use TLS for privacy and server authentication. The 325 implementation of the API MUST ensure both privacy and integrity of 326 any information provided by or required by it. 328 This document does not specify the details of the API. 330 2.4. Captive Portal Enforcement 332 The Captive Portal Enforcement component restricts network access to 333 User Equipment according to site-specific policy. Typically User 334 Equipment is permitted access to a small number of services and is 335 denied general network access until it has performed some action. 337 The Captive Portal Enforcement component: 339 o Allows traffic through for allowed User Equipment. 341 o Blocks (discards) traffic and sends ICMP notifications for 342 disallowed User Equipment. 344 o Permits disallowed User Equipment to access necessary APIs and web 345 pages to fulfill requirements of exiting captivity. 347 o Updates allow/block rules per User Equipment in response to 348 operations from the Captive Portal back-end. 350 As an upgrade path, captive portals MAY continue to support methods 351 that work today, such as modification of port-80 HTTP responses to 352 redirect users to the portal. Various user-equipment vendors probe 353 canary URLs to identify the state captivity [reference Mariko 354 Kobayashi's survey]. While doing so, ICMP messages SHOULD also be 355 sent, to activate work-flows in supporting devices. [TODO: give some 356 thought to precise recommendations for backwards compatibility.] 358 2.5. ICMP/ICMP6 360 ICMP messages have been selected for indicating to a sender that 361 packets could not be delivered for reason of a network policy (in 362 particular, captive portal). ICMP is already used to indicate 363 reasons that packets could not be delivered (network unreachable, 364 port unreachable, packet too large, etc.). 366 A mechanism to trigger captive portal work-flows in the User 367 Equipment is proposed in [I-D.wkumari-capport-icmp-unreach]. 369 The Captive Portal Enforcement function is REQUIRED to send such ICMP 370 messages when disallowed User Equipment attempts to send to the 371 network. These ICMP messages MUST be rate-limited to a configurable 372 rate. 374 The ICMP messages MUST NOT be sent to the Internet devices. The 375 indications are only sent to the User Equipment. 377 The User Equipment operating system is NOT REQUIRED to deliver the 378 impact of the ICMP message to the application that triggered it. The 379 User Equipment might be able to satisfy the Captive Portal 380 requirements quickly enough that existing transport connections are 381 not impacted. 383 2.6. Component Diagram 385 The following diagram shows the communication between each component. 387 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 388 . CAPTIVE NETWORK . 389 . +--------------+ . 390 . +------------+ Provision API URI | Provisioning | . 391 . | |<---------------------------+| Service | . 392 . | User | +--------------+ . 393 . | Equipment | Query CAPPORT status; +-------------+ . 394 . | |+--------------------------->| CAPPORT API | . 395 . | | | Server | . 396 . | | +------+------+ . 397 . | | |Status . 398 . | | Portal user interface +------+------+ . 399 . | |+--------------------------> | CAPPORT | . 400 . +------------+ | web portal | . 401 . ^ | Connection Attempt +-------------+ . 402 . | | to prohibited service. | . 403 . | +------------------> +---------------+ Allow/Deny . 404 . | | | Rules . 405 . | ICMP Unreachable | Captive Portal| | . 406 . +---------------------+ | Enforcement | <---+ . 407 . +---------------+ . 408 . | . 409 . To/from external network . 410 . | . 411 . | . 412 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 413 EXTERNAL NETWORK 415 Figure 1: Captive Portal Architecture Component Diagram 417 In the diagram: 419 o During provisioning (e.g., DHCP), the User Equipment acquires the 420 URI for the CAPPORT API. 422 o The User Equipment queries the API to learn of its state of 423 captivity. If captive, the User Equipment presents the portal 424 user interface to the user. 426 o The User Equipment attempts to communicate to the external network 427 through the Captive Portal enforcement device. 429 o The Captive Portal Enforcement device either allows the User 430 Equipment's packets to the external network, or responds with an 431 ICMP message. 433 o The CAPPORT web portal server directs the Captive Portal 434 Enforcement device to either allow or deny external network access 435 for the User Equipment. 437 Although the provisioning, API, and web portal functions are shown as 438 discrete blocks, they could of course be combined into a single 439 element. 441 3. User Equipment Identity 443 Multiple components in the architecture interact with both the User 444 Equipment and each other. Since the User Equipment is the focus of 445 these interactions, the components must be able to both identify the 446 user equipment from their interactions with it, and be able to agree 447 on the identify of the user equipment when interacting with each 448 other. 450 The methods by which the components interact restrict the type of 451 information that may be used as an identifying characteristics. This 452 section discusses the identifying characteristics. 454 3.1. Identifiers 456 An Identifier is a chatacteristic of the User Equipment used by the 457 components of a Captive Portal to uniquely determine which specific 458 User Equipment is interacting with them. An Identifier MAY be a 459 field contained in packets sent by the User Equipment to the External 460 Network. Or, an Identifier MAY be an ephemeral property not 461 contained in packets destined for the External Network, but instead 462 correlated with such information through knowledge available to the 463 different components. 465 3.2. Recommended Properties 467 The set of possible identifiers is quite large. However, in order to 468 be considered a good identifier, an identifier SHOULD meet the 469 following criteria. Note that the optimal identifier will likely 470 change depending on the position of the components in the network as 471 well as the information available to them. An identifier SHOULD: 473 o Uniquely Identify the User Equipment 475 o Be Hard to Spoof 476 o Be Visible to the API 478 o Be Visible to the Enforcement Device 480 3.2.1. Uniquely Identify User Equipment 482 In order to uniquely identify the User Equipment, at most one user 483 equipment interacting with the other components of the Captive Portal 484 MUST have a given value of the identifier. 486 Over time, the user equipment identified by the value MAY change. 487 Allowing the identified device to change over time ensures that the 488 space of possible identifying vallues need not be overly large. 490 Independent Captive Portals MAY use the same identifying value to 491 identify different User Equipment. Allowing indendent captive 492 portals to reuse identifying values allows the identifier to be a 493 property of the local network, expanding the space of possible 494 identifiers. 496 3.2.2. Hard to Spoof 498 A good identifier does not lend itself to being easily spoofed. At 499 no time should it be simple or straightforward for one User Equipment 500 to pretend to be another User Equipment, regardless of whether both 501 are active at the same time. This property is particularly important 502 when the user equipment is extended externally to devices such as 503 billing systems, or where the identity of the User Equipment could 504 imply liability. 506 3.2.3. Visible to the API 508 Since the API will need to perform operations which rely on the 509 identify of the user equipment, such as query whether it is captive, 510 the API needs to be able to relate requests to the User Equipment 511 making the request. 513 3.2.4. Visible to the Enforcement Device 515 The Enforcement Device will decide on a per packet basis whether it 516 should be permitted to communicate with the external network. Since 517 this decision depends on which User Equipment sent the packet, the 518 Enforcement Device requires that it be able to map the packet to its 519 concept of the User Equipment. 521 3.3. Evaluating an Identifier 523 To evaluate whether an identifer is appropriate, one should consider 524 every recommended property from the perspective of interactions among 525 the components in the architecture. When comparing identifiers, 526 choose the one which best satifies all of the recommended properties. 527 The architecture does not provide an exact measure of how well an 528 identifier satisfies a given property; care should be taken in 529 performing the evaluation. 531 3.4. Examples of an Identifier 533 This section provides some examples of identifiers, along with some 534 evaluation of whether they are good identifiers. The list of 535 identifiers is not exhaustive. Other identifiers may be used. An 536 important point to note is that whether the identifiers are good 537 depends heavily on the capabilities of the components and where in 538 the network the components exist. 540 3.4.1. Physical Interface 542 The physical interface by which the User Equipment is attached to the 543 network can be used to identify the User Equipment. This identifier 544 has the property of being extremely difficult to spoof: the User 545 Equipment is unaware of the property; one User Equipment cannot 546 manipulate its interactions to appear as though it is another. 548 Further, if only a single User Equipment is attatched to a given 549 physical interface, then the identifier will be unique. If multiple 550 User Equipment is attached to the network on the same physical 551 interface, then this property is not appropriate. 553 Another consideration related to uniqueness of the User Equipment is 554 that if the attached User Equipment changes, both the API server and 555 the Enforcement Device must invalidate their state related to the 556 User Equipment. 558 The Enforcement Device needs to be aware of the physical interface, 559 which constrains the environment: it must either be part of the 560 device providing physical access (e.g., implemented in firmware), or 561 packets traversing the network must be extended to include 562 information about the source physical interface (e.g. a tunnel). 564 The API server faces a similar problem, implying that it should co- 565 exist with the Enforcement Device, or that the enforcement device 566 should extend requests to it with the identifying information. 568 3.4.2. IP Address 570 A natural identifier to consider is the IP address of the User 571 Equipment. At any given time, no device on the network can have the 572 same IP address without causing the network to malfunction, so it is 573 appropriate from the perspective of uniqueness. 575 However, it may be possible to spoof the IP address, particularly for 576 malicious reasons where proper functioning of the network is not 577 necessary for the malicious actor. Consequently, any solution using 578 the IP address should proactively try to prevent spoofing of the IP 579 address. Similarily, if the mapping of IP address to User Equipment 580 is changed, the components of the architecture must remove or update 581 their mapping to prevent spoofing. Demonstrations of return 582 routeability, such as that required for TCP connection establishment, 583 might be sufficient defense against spoofing, though this might not 584 be sufficient in networks that use broadcast media (such as some 585 wireless networks). 587 Since the IP address may traverse multiple segments of the network, 588 more flexibility is afforded to the Enforcement Device and the API 589 server: they simply must exist on a segment of the network where the 590 IP address is still unique. However, consider that a NAT may be 591 deployed between the User Equipment and the Enforcement Device. In 592 such cases, it is possible for the components to still uniquely 593 identify the device if they are aware of the port mapping. 595 In some situtations, the User Equipment may have multiple IP 596 addresses, while still satisfying all of the recommended properties. 597 This raises some challenges to the components of the network. For 598 example, if the user equipment tries to access the network with 599 multiple IP addresses, should the enforcement device and API server 600 treat each IP address as a unique User Equipment, or should it tie 601 the multiple addresses together into one view of the subscriber? An 602 implementation MAY do either. Attention should be paid to IPv6 and 603 the fact that it is expected for a device to have multiple IPv6 604 addresses on a single link. In such cases, idenfication could be 605 performed by subnet, such as the /64 to which the IP belongs. 607 4. Solution Workflow 609 This section aims to improve understanding by describing a possible 610 workflow of solutions adhering to the architecture. 612 4.1. Initial Connection 614 This section describes a possible work-flow when User Equipment 615 initially joins a Captive Network. 617 1. The User Equipment joins the Captive Network by acquiring a DHCP 618 lease, RA, or similar, acquiring provisioning information. 620 2. The User Equipment learns the URI for the Captive Portal API from 621 the provisioning information (e.g., [RFC7710]). 623 3. The User Equipment accesses the CAPPORT API to receive parameters 624 of the Captive Network, including web-portal URI. (This step 625 replaces the clear-text query to a canary URL.) 627 4. If necessary, the User navigates the web portal to gain access to 628 the external network. 630 5. The Captive Portal API server indicates to the Captive Portal 631 Enforcement device that the User Equipment is allowed to access 632 the external network. 634 6. The User Equipment attempts a connection outside the captive 635 network 637 7. If the requirements have been satisfied, the access is permitted; 638 otherwise the "Expired" behavior occurs. 640 8. The User Equipment accesses the network until conditions Expire. 642 4.2. Conditions Expire 644 This section describes a possible work-flow when conditions expire 645 and the user visits the portal again (e.g., low quota, or time 646 expiry). 648 1. Pre-condition: the Captive Portal Enforcement has been configured 649 to detect an expiry condition, which has now occurred. 651 2. The User Equipment sends a packet to the outside network. 653 3. The Captive Portal Enforcement detects that the packet is from an 654 expired User Equipment. 656 4. The Captive Portal Enforcement sends an ICMP message to the User 657 Equipment indicating that it needs to refresh its access. 658 [I-D.wkumari-capport-icmp-unreach]. 660 5. The User Equipment verifies the ICMP message is plausible. 662 6. The User Equipment queries the Captive Portal API to refresh 663 parameters and status of the Captive Network. 665 7. If necessary, the User once again navigates the web portal to 666 gain access to the external network. 668 8. The Captive Portal API Server gives more quota (time, bytes, 669 etc.) to the User Equipment by indicating to the Captive Portal 670 Enforcement the new, extended quota. 672 9. The User Equipment accesses the external network. 674 5. Acknowledgements 676 The authors thank various individuals for their feedback on the 677 mailing list and during the IETF98 hackathon: David Bird, Eric Kline, 678 Alexis La Goulette, Alex Roscoe, Darshak Thakore, and Vincent van 679 Dam. 681 6. IANA Considerations 683 This memo includes no request to IANA. 685 7. Security Considerations 687 7.1. Trusting the Network 689 When joining a network, some trust is placed in the network operator. 690 This is usually considered to be a decision by a user on the basis of 691 the reputation of an organization. However, once a user makes such a 692 decision, protocols can support authenticating a network is operated 693 by who claims to be operating it. The Provisioning Domain 694 Architecture [RFC7556] provides some discussion on authenticating an 695 operator. 697 Given that a user chooses to visit a Captive Portal URI, the URI 698 location SHOULD be securely provided to the user's device. E.g., the 699 DHCPv6 AUTH option can sign this information. 701 If a user decides to incorrectly trust an attacking network, they 702 might be convinced to visit an attacking web page and unwittingly 703 provide credentials to an attacker. Browsers can authenticate 704 servers but cannot detect cleverly misspelled domains, for example. 706 7.2. Authenticated APIs 708 The solution described here assumes that when the User Equipment 709 needs to trust the API server, server authentication will be 710 performed using TLS mechanisms. 712 7.3. Secure APIs 714 The solution described here requires that the API be secured using 715 TLS. This is required to allow the user equipment and API server to 716 exchange secrets which can be used to validate future interactions. 717 The API must ensure the integrity of this information, as well as its 718 confidentiality. 720 7.4. Risk of Nuisance Captive Portal 722 It is possible for any user on the Internet to send ICMP packets in 723 an attempt to cause the receiving equipment to go to the captive 724 portal. This has been considered and addressed in the following 725 ways: 727 The ICMP packet does not carry the URL, making this method safer 728 than HTTP 3xx-redirect methods currently in use. The User 729 Equipment does not have to use clear-text HTTP to solicit the URL 730 of the portal. 732 Because the ICMP messages will carry embedded packets sent by the 733 sender, the receiver of the ICMP message can validate that the 734 transport header is plausibly one it sent (i.e., the transport- 735 layer 5-tuple matches an open connection; there is no need to save 736 every packet it sent). This validation requires an off-path 737 attacker to guess the 5-tuple in order to affect a flow. It is 738 trivial for an on-path attacker to send a plausible ICMP packet. 739 (This is not a new ICMP attack.) The impact of getting a valid 740 ICMP packet to the User Equipment is that it will visit the 741 CAPPORT API to check the status. For this reason we recommend the 742 User Equipment rate-limit these requests to the API. 744 We considered that the ICMP packet could carry a short secret 745 token that would be known to the User Equipment and Captive Portal 746 Enforcement device but would not be available to an attacker, even 747 to an on-path attacker. Although possible to guess by brute 748 force, the impact would be at worst a nuisance visit to the API. 749 We suggest that a 32-bit token would be sufficient to deter 750 nuisance attacks. 752 Even when redirected, the User Equipment securely authenticates 753 with API servers. 755 7.5. User Options 757 The ICMP messaging informs the User Equipment that it is being held 758 captive. There is no requirement that the User Equipment do 759 something about this. Devices MAY permit users to disable automatic 760 reaction to captive-portal indications for privacy reasons. However, 761 there is the trade-off that the user doesn't get notified when 762 network access is restricted. Hence, end-user devices MAY allow 763 users to manually control captive portal interactions, possibly on 764 the granularity of Provisioning Domains. 766 8. References 768 8.1. Normative References 770 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 771 Requirement Levels", BCP 14, RFC 2119, 772 DOI 10.17487/RFC2119, March 1997, 773 . 775 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 776 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 777 . 779 [RFC7710] Kumari, W., Gudmundsson, O., Ebersman, P., and S. Sheng, 780 "Captive-Portal Identification Using DHCP or Router 781 Advertisements (RAs)", RFC 7710, DOI 10.17487/RFC7710, 782 December 2015, . 784 8.2. Informative References 786 [I-D.ietf-intarea-provisioning-domains] 787 Pfister, P., Vyncke, E., Pauly, T., and D. Schinazi, 788 "Discovering Provisioning Domain Names and Data", draft- 789 ietf-intarea-provisioning-domains-01 (work in progress), 790 February 2018. 792 [I-D.nottingham-capport-problem] 793 Nottingham, M., "Captive Portals Problem Statement", 794 draft-nottingham-capport-problem-01 (work in progress), 795 April 2016. 797 [I-D.wkumari-capport-icmp-unreach] 798 Bird, D. and W. Kumari, "Captive Portal ICMP Messages", 799 draft-wkumari-capport-icmp-unreach-02 (work in progress), 800 April 2017. 802 Authors' Addresses 804 Kyle Larose 805 Sandvine 806 408 Albert Street 807 Waterloo, ON N2L 3V3 808 Canada 810 Phone: +1 519 880 2400 811 Email: klarose@sandvine.com 813 David Dolson 815 Email: ddolson@acm.org