idnits 2.17.1 draft-ietf-capport-architecture-00.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 (September 28, 2017) is 2394 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7710 (Obsoleted by RFC 8910) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 D. Dolson 4 Intended status: Informational Sandvine 5 Expires: April 1, 2018 September 28, 2017 7 CAPPORT Architecture 8 draft-ietf-capport-architecture-00 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 April 1, 2018. 34 Copyright Notice 36 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2.1. User Equipment . . . . . . . . . . . . . . . . . . . . . 5 56 2.2. Provisioning Service . . . . . . . . . . . . . . . . . . 5 57 2.2.1. DHCP or Router Advertisements . . . . . . . . . . . . 6 58 2.2.2. Provisioning Domains . . . . . . . . . . . . . . . . 6 59 2.3. Captive Portal API Server . . . . . . . . . . . . . . . . 6 60 2.4. Captive Portal Enforcement . . . . . . . . . . . . . . . 7 61 2.5. ICMP/ICMP6 . . . . . . . . . . . . . . . . . . . . . . . 8 62 2.6. Component Diagram . . . . . . . . . . . . . . . . . . . . 8 63 3. Solution Workflow . . . . . . . . . . . . . . . . . . . . . . 10 64 3.1. Initial Connection . . . . . . . . . . . . . . . . . . . 10 65 3.2. Conditions Expire . . . . . . . . . . . . . . . . . . . . 10 66 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 6.1. Trusting the Network . . . . . . . . . . . . . . . . . . 11 70 6.2. Authenticated APIs . . . . . . . . . . . . . . . . . . . 12 71 6.3. Risk of Nuisance Captive Portal . . . . . . . . . . . . . 12 72 6.4. User Options . . . . . . . . . . . . . . . . . . . . . . 13 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 75 7.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 In this document, "Captive Portal" is used to describe a network to 81 which a device may be voluntarily attached, such that network access 82 is limited until some requirements have been fulfilled. Typically a 83 user is required to use a web browser to fulfil requirements imposed 84 by the network operator, such as reading advertisements, accepting an 85 acceptable-use policy, or providing some form of credentials. 87 Implementations generally require a web server, some method to allow/ 88 block traffic, and some method to alert the user. Common methods of 89 alerting the user involve modifying HTTP or DNS traffic. 91 Problems with captive portal implementations have been described in 92 [I-D.nottingham-capport-problem]. [If that document cannot be 93 published, consider putting its best parts into an appendix of this 94 document.] 95 This document standardizes an architecture for implementing captive 96 portals that provides tools for addressing most of those problems. 97 We are guided by these principles: 99 o Solutions SHOULD NOT require the forging of responses from DNS or 100 HTTP servers, or any other protocol. In particular, solutions 101 SHOULD NOT require man-in-the-middle proxy of TLS traffic. 103 o Solutions MUST operate at the layer of Internet Protocol (IP) or 104 above, not being specific to any particular access technology such 105 as Cable, WiFi or 3GPP. 107 o Solutions SHOULD allow a device to be alerted that it is in a 108 captive network when attempting to use any application on the 109 network. (Versus requiring a user to visit a clear-text HTTP site 110 in order to receive a notification.) 112 o The state of captivity SHOULD be explicitly available to devices 113 (in contrast to modification of DNS or HTTP, which is only 114 indirectly machine-detectable by the client--by comparing 115 responses to well-known queries with expected responses). 117 o The architecture MUST provide a path of incremental migration, 118 acknowledging a huge variety of portals and end-user device 119 implementations and software versions. 121 o The architecture SHOULD improve security by providing mechanisms 122 for trust, allowing alerts from trusted network operators to be 123 distinguished from attacks from untrusted agents. 125 A side-benefit of the architecture described in this document is that 126 devices without user interfaces are able to identify parameters of 127 captivity. (However, this document does not yet describe a mechanism 128 for such devices to escape captivity.) 130 The architecture uses the following mechanisms: 132 o Network provisioning protocols provide end-user devices with a URI 133 for the API that end-user devices query for information about what 134 is required to escape captivity. DHCP, DHCPv6, and Router- 135 Advertisement options for this purpose are available in [RFC7710]. 136 Other protocols (such as RADIUS), Provisioning Domains 137 [I-D.bruneau-intarea-provisioning-domains], or static 138 configuration may also be used. A device MAY query this API at 139 any time to determine whether the network is holding the device in 140 a captive state. 142 o End-user devices are notified of captivity with ICMP/ICMP6 143 messages in response to traffic. This notification can work with 144 any Internet protocol, not just clear-text HTTP. This 145 notification does not carry the portal URI; rather it provides a 146 notification to the User Equipment that it is in a captive state. 148 o Receipt of the ICMP/ICMP6 messages informs an end-user device that 149 it is captive. In response, the device SHOULD query the 150 provisioned API to obtain information about the network state. 151 The device MAY take immediate action to satisfy the portal 152 (according to its configuration/policy). 154 The architecture attempts to provide privacy, authentication, and 155 safety mechanisms to the extent possible. 157 1.1. Requirements Language 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in RFC 2119 [RFC2119]. 163 1.2. Terminology 165 Captive Network: A network which limits communication of attached 166 devices to restricted hosts until the user has satisfied Captive 167 Portal Conditions, after which access is permitted to a wider set of 168 hosts (typically the internet). 170 Captive Portal Conditions: site-specific requirements that a user or 171 device must satisfy in order to gain access to the wider network. 173 Captive Portal Enforcement: The network equipment which enforces the 174 traffic restriction and notifies the User Equipment it is in a 175 captive state. 177 Captive Portal User Equipment: Also known as User Equipment. A 178 device which has voluntarily joined a network for purposes of 179 communicating beyond the constraints of the captive network. 181 Captive Portal Server: The web server providing a user interface for 182 assisting the user in satisfying the conditions to escape captivity. 184 2. Components 185 2.1. User Equipment 187 The User Equipment is the device that a user desires to be attached 188 to a network with full access to all hosts on the network (e.g., to 189 have Internet access). The User Equipment communication is typically 190 restricted by the Captive Portal Enforcement, described in 191 Section 2.4, until site-specific requirements have been met. 193 At this time we consider only devices with web browsers, with web 194 applications being the means of satisfying Captive Portal Conditions. 196 o An example interactive User Equipment is a smart phone. 198 o SHOULD support provisioning of the URI for the Captive Portal API 199 (e.g., by DHCP) 201 o MAY distinguish Captive Portal API access per network interface, 202 in the manner of Provisioning Domain Architecture [RFC7556]. 204 o SHOULD have a mechanism for notifying the user of the Captive 205 Portal 207 o SHOULD have a web browser so that the user may navigate the 208 Captive Portal user interface. 210 o SHOULD be able to receive and validate the Captive Portal ICMP 211 message types, and to access the Captive Portal API in response. 213 o MAY restrict application access to networks not granting full 214 network access. E.g., a device connected to a mobile network may 215 be connecting to a WiFi network; the operating system MAY avoid 216 updating the default route until network access restrictions have 217 been lifted (excepting access to the Captive Portal server). This 218 has been termed "make before break". 220 None of the above requirements are mandatory because (a) we do not 221 wish to say users or devices must seek access beyond the captive 222 network, (b) the requirements may be fulfilled by manually visiting 223 the captive portal web application, and (c) legacy devices must 224 continue to be supported. 226 2.2. Provisioning Service 228 Here we discuss candidate mechanisms for provisioning the User 229 Equipment with the URI of the API to query captive portal state and 230 navigate the portal. 232 2.2.1. DHCP or Router Advertisements 234 A standard for providing a portal URI using DHCP or Router 235 Advertisements is described in [RFC7710]. The CAPPORT architecture 236 expects this URI to indicate the API described in Section 2.3. 238 Although it is not clear from RFC7710 what protocol should be 239 executed at the specified URI, some readers might have assumed it to 240 be an HTML page, and hence there might be User Equipment assuming a 241 browser should open this URI. For backwards compatibility, it is 242 RECOMMENDED that the server check the "Accept" field when serving the 243 URI, and serve HTML pages for "text/html" and serve the API for 244 "application/json". [REVISIT: are these details appropriate?] 246 2.2.2. Provisioning Domains 248 Although still a work in progress, 249 [I-D.bruneau-intarea-provisioning-domains] proposes a mechanism for 250 User Equipment to be provided with PvD Bootstrap Information 251 containing the URI for a JSON file containing key-value pairs to be 252 downloaded over HTTPS. This JSON file would fill the role of the 253 Captive Portal API described in Section 2.3. 255 One key-value pair can be used to indicate the network has restricted 256 access, requiring captive portal navigation by a user. E.g., 257 key="captivePortal" and value=. The key-value pair 258 should provide a different result when access is not restricted. 259 E.g., key="captivePortal" and value="". 261 This JSON file is extensible, allowing new key-value pairs to 262 indicate such things as network access expiry time, URI for API 263 access by IOT devices, etc. 265 The PvD server MUST support multiple (repeated) queries from each 266 User Equipment, always returning the current captive portal 267 information. The User Equipment is expected to make this query upon 268 receiving (and validating) an ICMP Captive Portal message (see 269 Section 2.5). 271 2.3. Captive Portal API Server 273 The purpose of a Captive Portal API is to permit a query of Captive 274 Portal state without interrupting the user. This API thereby removes 275 the need for a device to perform clear-text "canary" HTTP queries to 276 check for response tampering. 278 The URI of this API will have been provisioned to the User Equipment. 279 (Refer to Section 2.2). 281 This architecture expects the User Equipment to query the API when 282 the User Equipment attaches to the network and multiple times 283 thereafter. Therefore the API MUST support multiple repeated queries 284 from the same User Equipment, returning current state of captivity 285 for the equipment. 287 At minimum the API MUST provide: (1) the state of captivity and (2) a 288 URI for a browser to present the portal application to the user. The 289 API SHOULD provide evidence to the caller that it supports the 290 present architecture. 292 When user equipment receives (and validates) ICMP Captive Portal 293 alerts, the user equipment SHOULD query the API to check the state. 294 The User Equipment SHOULD rate-limit these API queries in the event 295 of ICMP flooding by an attacker. (See Section 6.) 297 The API MUST be extensible to support future use-cases by allowing 298 extensible information elements. Suggestions include quota 299 information, expiry time, method of providing credentials, security 300 token for validating ICMP messages. 302 This document does not specify the details of the API. 304 The CAPPORT API SHOULD support TLS for privacy and server 305 authentication. 307 2.4. Captive Portal Enforcement 309 The Captive Portal Enforcement component restricts network access to 310 User Equipment according to site-specific policy. Typically User 311 Equipment is permitted access to a small number of services and is 312 denied general network access until it has performed some action. 314 The Captive Portal Enforcement component: 316 o Allows traffic through for allowed User Equipment. 318 o Blocks (discards) traffic and sends ICMP notifications for 319 disallowed User Equipment. 321 o Permits disallowed User Equipment to access necessary APIs and web 322 pages to fulfill requirements of exiting captivity. 324 o Updates allow/block rules per User Equipment in response to 325 operations from the Captive Portal back-end. 327 As an upgrade path, captive portals MAY continue to support methods 328 that work today, such as modification of port-80 HTTP responses to 329 redirect users to the portal. Various user-equipment vendors probe 330 canary URLs to identify the state captivity [reference Mariko 331 Kobayashi's survey]. While doing so, ICMP messages SHOULD also be 332 sent, to activate work-flows in supporting devices. [TODO: give some 333 thought to precise recommendations for backwards compatibility.] 335 2.5. ICMP/ICMP6 337 ICMP messages have been selected for indicating to a sender that 338 packets could not be delivered for reason of a network policy (in 339 particular, captive portal). ICMP is already used to indicate 340 reasons that packets could not be delivered (network unreachable, 341 port unreachable, packet too large, etc.). 343 A mechanism to trigger captive portal work-flows in the User 344 Equipment is proposed in [I-D.wkumari-capport-icmp-unreach]. 346 The Captive Portal Enforcement function is REQUIRED to send such ICMP 347 messages when disallowed User Equipment attempts to send to the 348 network. These ICMP messages MUST be rate-limited to a configurable 349 rate. 351 The ICMP messages MUST NOT be sent to the Internet devices. The 352 indications are only sent to the User Equipment. 354 The User Equipment operating system is NOT REQUIRED to deliver the 355 impact of the ICMP message to the application that triggered it. The 356 User Equipment might be able to satisfy the Captive Portal 357 requirements quickly enough that existing transport connections are 358 not impacted. 360 2.6. Component Diagram 361 The following diagram shows the communication between each component. 363 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 364 . CAPTIVE NETWORK . 365 . +--------------+ . 366 . +------------+ Provision API URI | Provisioning | . 367 . | |<---------------------------+| Service | . 368 . | User | +--------------+ . 369 . | Equipment | Query CAPPORT status; +-------------+ . 370 . | |+--------------------------->| CAPPORT API | . 371 . | | | Server | . 372 . | | +------+------+ . 373 . | | |Status . 374 . | | Portal user interface +------+------+ . 375 . | |+--------------------------> | CAPPORT | . 376 . +------------+ | web portal | . 377 . ^ | Connection Attempt +-------------+ . 378 . | | to prohibited service. | . 379 . | +------------------> +---------------+ Allow/Deny . 380 . | | | Rules . 381 . | ICMP Unreachable | Captive Portal| | . 382 . +---------------------+ | Enforcement | <---+ . 383 . +---------------+ . 384 . | . 385 . To/from external network . 386 . | . 387 . | . 388 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . o 389 EXTERNAL NETWORK 391 Figure 1: Captive Portal Architecture Component Diagram 393 In the diagram: 395 o During provisioning (e.g., DHCP), the User Equipment acquires the 396 URI for the CAPPORT API. 398 o The User Equipment queries the API to learn of its state of 399 captivity. If captive, the User Equipment presents the portal 400 user interface to the user. 402 o The User Equipment attempts to communicate to the external network 403 through the Captive Portal enforcement device. 405 o The Captive Portal Enforcement device either allows the User 406 Equipment's packets to the external network, or responds with an 407 ICMP message. 409 o The CAPPORT web portal server directs the Captive Portal 410 Enforcement device to either allow or deny external network access 411 for the User Equipment. 413 Although the provisioning, API, and web portal functions are shown as 414 discrete blocks, they could of course be combined into a single 415 element. 417 3. Solution Workflow 419 This section aims to improve understanding by describing a possible 420 workflow of solutions adhering to the architecture. 422 3.1. Initial Connection 424 This section describes a possible work-flow when User Equipment 425 initially joins a Captive Network. 427 1. The User Equipment joins the Captive Network by acquiring a DHCP 428 lease, RA, or similar, acquiring provisioning information. 430 2. The User Equipment learns the URI for the Captive Portal API from 431 the provisioning information (e.g., [RFC7710]). 433 3. The User Equipment accesses the CAPPORT API to receive parameters 434 of the Captive Network, including web-portal URI. (This step 435 replaces the clear-text query to a canary URL.) 437 4. If necessary, the User navigates the web portal to gain access to 438 the external network. 440 5. The Captive Portal API server indicates to the Captive Portal 441 Enforcement device that the User Equipment is allowed to access 442 the external network. 444 6. The User Equipment attempts a connection outside the captive 445 network 447 7. If the requirements have been satisfied, the access is permitted; 448 otherwise the "Expired" behavior occurs. 450 8. The User Equipment accesses the network until conditions Expire. 452 3.2. Conditions Expire 454 This section describes a possible work-flow when conditions expire 455 and the user visits the portal again (e.g., low quota, or time 456 expiry). 458 1. Pre-condition: the Captive Portal Enforcement has been configured 459 to detect an expiry condition, which has now occurred. 461 2. The User Equipment sends a packet to the outside network. 463 3. The Captive Portal Enforcement detects that the packet is from an 464 expired User Equipment. 466 4. The Captive Portal Enforcement sends an ICMP message to the User 467 Equipment indicating that it needs to refresh its access. 468 [I-D.wkumari-capport-icmp-unreach]. 470 5. The User Equipment verifies the ICMP message is plausible. 472 6. The User Equipment queries the Captive Portal API to refresh 473 parameters and status of the Captive Network. 475 7. If necessary, the User once again navigates the web portal to 476 gain access to the external network. 478 8. The Captive Portal API Server gives more quota (time, bytes, 479 etc.) to the User Equipment by indicating to the Captive Portal 480 Enforcement the new, extended quota. 482 9. The User Equipment accesses the external network. 484 4. Acknowledgements 486 The authors thank various individuals for their feedback on the 487 mailing list and during the IETF98 hackathon: David Bird, Eric Kline, 488 Alexis La Goulette, Alex Roscoe, Darshak Thakore, and Vincent van 489 Dam. 491 5. IANA Considerations 493 This memo includes no request to IANA. 495 6. Security Considerations 497 6.1. Trusting the Network 499 When joining a network, some trust is placed in the network operator. 500 This is usually considered to be a decision by a user on the basis of 501 the reputation of an organization. However, once a user makes such a 502 decision, protocols can support authenticating a network is operated 503 by who claims to be operating it. The Provisioning Domain 504 Architecture [RFC7556] provides some discussion on authenticating an 505 operator. 507 Given that a user chooses to visit a Captive Portal URI, the URI 508 location SHOULD be securely provided to the user's device. E.g., the 509 DHCPv6 AUTH option can sign this information. 511 If a user decides to incorrectly trust an attacking network, they 512 might be convinced to visit an attacking web page and unwittingly 513 provide credentials to an attacker. Browsers can authenticate 514 servers but cannot detect cleverly misspelled domains, for example. 516 6.2. Authenticated APIs 518 The solution described here assumes that when the User Equipment 519 needs to trust the API server, server authentication will be utilized 520 using TLS mechanisms. 522 6.3. Risk of Nuisance Captive Portal 524 It is possible for any user on the Internet to send ICMP packets in 525 an attempt to cause the receiving equipment to go to the captive 526 portal. This has been considered and addressed in the following 527 ways: 529 The ICMP packet does not carry the URL, making this method safer 530 than HTTP 3xx-redirect methods currently in use. The User 531 Equipment does not have to use clear-text HTTP to solicit the URL 532 of the portal. 534 Because the ICMP messages will carry embedded packets sent by the 535 sender, the receiver of the ICMP message can validate that the 536 transport header is plausibly one it sent (i.e., the transport- 537 layer 5-tuple matches an open connection; there is no need to save 538 every packet it sent). This validation requires an off-path 539 attacker to guess the 5-tuple in order to affect a flow. It is 540 trivial for an on-path attacker to send a plausible ICMP packet. 541 (This is not a new ICMP attack.) The impact of getting a valid 542 ICMP packet to the User Equipment is that it will visit the 543 CAPPORT API to check the status. For this reason we recommend the 544 User Equipment rate-limit these requests to the API. 546 We considered that the ICMP packet could carry a short secret 547 token that would be known to the User Equipment and Captive Portal 548 Enforcement device but would not be available to an attacker, even 549 to an on-path attacker. Although possible to guess by brute 550 force, the impact would be at worst a nuisance visit to the API. 551 We suggest that a 32-bit token would be sufficient to deter 552 nuisance attacks. 554 Even when redirected, the User Equipment securely authenticates 555 with API servers. 557 6.4. User Options 559 The ICMP messaging informs the User Equipment that it is being held 560 captive. There is no requirement that the User Equipment do 561 something about this. Devices MAY permit users to disable automatic 562 reaction to captive-portal indications for privacy reasons. However, 563 there is the trade-off that the user doesn't get notified when 564 network access is restricted. Hence, end-user devices MAY allow 565 users to manually control captive portal interactions, possibly on 566 the granularity of Provisioning Domains. 568 7. References 570 7.1. Normative References 572 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 573 Requirement Levels", BCP 14, RFC 2119, 574 DOI 10.17487/RFC2119, March 1997, 575 . 577 [RFC7556] Anipko, D., Ed., "Multiple Provisioning Domain 578 Architecture", RFC 7556, DOI 10.17487/RFC7556, June 2015, 579 . 581 [RFC7710] Kumari, W., Gudmundsson, O., Ebersman, P., and S. Sheng, 582 "Captive-Portal Identification Using DHCP or Router 583 Advertisements (RAs)", RFC 7710, DOI 10.17487/RFC7710, 584 December 2015, . 586 7.2. Informative References 588 [I-D.bruneau-intarea-provisioning-domains] 589 Pfister, P., Schinazi, D., Pauly, T., Vyncke, E., and B. 590 Bruneau, "Discovering Provisioning Domain Names and Data", 591 draft-bruneau-intarea-provisioning-domains-02 (work in 592 progress), July 2017. 594 [I-D.nottingham-capport-problem] 595 Nottingham, M., "Captive Portals Problem Statement", 596 draft-nottingham-capport-problem-01 (work in progress), 597 April 2016. 599 [I-D.wkumari-capport-icmp-unreach] 600 Bird, D. and W. Kumari, "Captive Portal ICMP Messages", 601 draft-wkumari-capport-icmp-unreach-02 (work in progress), 602 April 2017. 604 Authors' Addresses 606 Kyle Larose 607 Sandvine 608 408 Albert Street 609 Waterloo, ON N2L 3V3 610 Canada 612 Phone: +1 519 880 2400 613 Email: klarose@sandvine.com 615 David Dolson 616 Sandvine 617 408 Albert Street 618 Waterloo, ON N2L 3V3 619 Canada 621 Phone: +1 519 880 2400 622 Email: ddolson@sandvine.com