idnits 2.17.1 draft-ietf-i2rs-protocol-security-requirements-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 24, 2016) is 2894 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I7498-2' is mentioned on line 166, but not defined == Outdated reference: A later version (-23) exists of draft-ietf-i2rs-ephemeral-state-06 == Outdated reference: A later version (-06) exists of draft-ietf-i2rs-security-environment-reqs-01 -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS working group S. Hares 3 Internet-Draft Huawei 4 Intended status: Informational D. Migault 5 Expires: November 25, 2016 J. Halpern 6 Ericsson 7 May 24, 2016 9 I2RS Security Related Requirements 10 draft-ietf-i2rs-protocol-security-requirements-06 12 Abstract 14 This presents security-related requirements for the I2RS protocol for 15 mutual authentication, transport protocols, data transfer and 16 transactions. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on November 25, 2016. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Security Definitions . . . . . . . . . . . . . . . . . . 3 56 2.2. I2RS Specific Definitions . . . . . . . . . . . . . . . . 6 57 3. Security-Related Requirements . . . . . . . . . . . . . . . . 7 58 3.1. Mutual authentication of an I2RS client and an I2RS Agent 8 59 3.2. Transport Requirements Based on Mutual Authentication . . 9 60 3.3. Data Confidentiality Requirements . . . . . . . . . . . . 10 61 3.4. Data Integrity Requirements . . . . . . . . . . . . . . . 10 62 3.5. Role-Based Data Model Security . . . . . . . . . . . . . 11 63 3.6. Security of the environment . . . . . . . . . . . . . . . 12 64 4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 69 7.2. Informative References . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 72 1. Introduction 74 The Interface to the Routing System (I2RS) provides read and write 75 access to information and state within the routing process. An I2RS 76 client interacts with one or more I2RS agents to collect information 77 from network routing systems. 79 This document describes the requirements for the I2RS protocol in the 80 security-related areas of mutual authentication of the I2RS client 81 and agent, the transport protocol carrying the I2RS protocol 82 messages, and the atomicity of the transactions. These requirements 83 align with the description of the I2RS architecture found in 84 [I-D.ietf-i2rs-architecture] document which solves the problem 85 described in [I-D.ietf-i2rs-problem-statement]. 87 [I-D.ietf-i2rs-ephemeral-state] discusses I2RS role-based access 88 control that provides write conflict resolution in the ephemeral data 89 store using the I2RS Client Identity, I2RS Secondary Identity and 90 priority. The draft [I-D.ietf-i2rs-traceability] describes the 91 traceability framework and its requirements for I2RS. The draft 92 [I-D.ietf-i2rs-pub-sub-requirements] describes the requirements for 93 I2RS to be able to publish information or have a remote client 94 subscribe to an information data stream. 96 1.1. Requirements Language 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC 2119 [RFC2119]. 102 2. Definitions 104 2.1. Security Definitions 106 This document utilizes the definitions found in the following 107 documents: [RFC4949] and [I-D.ietf-i2rs-architecture] 109 Specifically, this document utilizes the following definitions: 111 access control 113 [RFC4949] defines access control as the following: 115 1. (I) Protection of system resources against unauthorized 116 access. 118 2. (I) A process by which use of system resources is regulated 119 according to a security policy and is permitted only by 120 authorized entities (users, programs, processes, or other 121 systems) according to that policy. (See: access, access 122 control service, computer security, discretionary access 123 control, mandatory access control, role-based access control.) 125 3. (I) /formal model/ Limitations on interactions between 126 subjects and objects in an information system. 128 4. (O) "The prevention of unauthorized use of a resource, 129 including the prevention of use of a resource in an 130 unauthorized manner." [I7498-2] 132 5. (O) /U.S. Government/ A system using physical, electronic, 133 or human controls to identify or admit personnel with properly 134 authorized access to a SCIF. 136 Authentication 138 [RFC4949] describes authentication as the process of verifying 139 (i.e., establishing the truth of) an attribute value claimed by or 140 for a system entity or system resource. Authentication has two 141 steps: identify and verify. 143 Data Confidentiality 145 [RFC4949] describes data confidentiality as having two properties: 147 a) Data is not disclosed to system entities unless they have 148 been authorized to know the data, and 150 b) Data is not disclosed to unauthorized individuals, entities 151 or processes. 153 The key point is that confidentiality implies that the originator 154 has the ability to authorize where the information goes. 155 Confidentiality is important for both read and write scope of the 156 data. 158 Data Integrity 160 [RFC4949] states data integrity includes: 162 1. (I) The property that data has not been changed, destroyed, 163 or lost in an unauthorized or accidental manner. [...] 165 2. (O) "The property that information has not been modified or 166 destroyed in an unauthorized manner." [I7498-2] 168 Data Privacy 170 [RFC4949] describes data privacy as a synonym for data 171 confidentiality. This I2RS document will utilize data privacy as 172 a synonym for data confidentiality. 174 Identity 176 [RFC4949] (I) The collective aspect of a set of attribute values 177 (i.e., a set of characteristics) by which a system user or other 178 system entity is recognizable or known. (See: authenticate, 179 registration. Compare: identifier.) 181 Identifier 183 [RFC4949] (I) A data object -- often, a printable, non-blank 184 character string -- that definitively represents a specific 185 identity of a system entity, distinguishing that identity from all 186 others. (Compare: identity.) 188 Mutual Authentication 190 [RFC4949] implies that mutual authentication exists between two 191 interacting system entities. 193 Mutual authentication in I2RS implies that both sides move from a 194 state of mutual suspicion to to mutual authentication to trusted 195 mutual communication after each system has been identified and 196 validated by its peer system. 198 role 200 [RFC4949] describes role as: 202 1. (I) A job function or employment position to which people 203 or other system entities may be assigned in a system. [...] 205 2. (O) /Common Criteria/ A pre-defined set of rules 206 establishing the allowed interactions between a user and the 207 TOE. 209 The I2RS uses the common criteria definition. 211 role-based access control 213 [RFC4949] describes role-based access control as: "A form of 214 identity-based access control wherein the system entities that are 215 identified and controlled are functional positions in an 216 organization or process." 218 security audit trail 220 [RFC4949] describes a security audit trail as "A chronological 221 record of system activities that is sufficient to enable the 222 reconstruction and examination of the sequence environments and 223 activities surrounding or leading to an operation, procedure, or 224 event in a security-relevant transaction from inception to final 225 results." 227 Requirements to support a security audit is not covered in this 228 document. 230 [I-D.ietf-i2rs-traceability] describes traceability for I2RS 231 interface and the I2RS protocol. Traceability is not equivalent 232 to a security audit trail. 234 Trust 236 [RFC4949] 238 1. (I) /information system/ A feeling of certainty (sometimes 239 based on inconclusive evidence) either (a) that the system 240 will not fail or (b) that the system meets its specifications 241 (i.e., the system does what it claims to do and does not 242 perform unwanted functions). (See: trust level, trusted 243 system, trustworthy system. Compare: assurance.) 245 2. . (I) /PKI/ A relationship between a certificate user and a CA 246 in which the user acts according to the assumption that the CA 247 creates only valid digital certificates. (Also referred as 248 "trusted" in [RFC4949].) 250 2.2. I2RS Specific Definitions 252 I2RS protocol data integrity 254 The transfer of data via the I2RS protocol has the property of 255 data integrity described in [RFC4949]. 257 I2RS component protocols 259 Protocols which are combined to create the I2RS protocol. 261 I2RS Higher-level protocol 263 The I2RS protocol exists as a higher-level protocol which may 264 combine other protocols (NETCONF, RESTCONF, IPFIX and others) 265 within a specific I2RS client-agent relationship with a specific 266 trust for ephemeral configurations, event, tracing, actions, and 267 data flow interactions. The protocols included in the I2RS 268 protocol protocol are defined as I2RS component protocols. (Note: 269 Version 1 of the I2RS protocol will combine only NETCONF and 270 RESTCONF. Experiments with other protocols such as IPFIX have 271 shown these are useful to combine with NETCONF and RESTCONF 272 features.) 274 I2RS message 276 is a complete data message of one of the I2RS component protocols. 277 The I2RS component protocols may require multiple IP-packets to 278 send one protocol message. 280 I2RS multi-message atomicity 282 An I2RS operation (read, write, event, action) must be contained 283 within one I2RS message. Each I2RS operation must be atomic. 284 While it is possible to have an I2RS operation which is contained 285 in multiple I2RS (E.g. write in multiple messages), this is not 286 supported in order to simply the first version of I2RS. Multiple- 287 message atomicity of I2RS operations would be used in a roll-back 288 of a grouping of commands (e.g. multiple writes). 290 I2RS transaction 292 is a unit of I2RS functionality. Some examples of I2RS 293 transactions are: 295 * The I2RS client issues a read request to a I2RS agent, and the 296 I2RS Agent responding to the read request 298 * The I2RS client issues a write of ephemeral configuration 299 values into an I2RS agent's data model, followed by the I2RS 300 agent response to the write. 302 * An I2RS client may issue an action request, the I2RS agent 303 responds to the action-request, and then responds when action 304 is complete. Actions can be single step processes or multiple 305 step process. 307 * An I2RS client requests to receive an event notification, and 308 the I2RS Agent sets up to send the events. 310 * An I2RS agent sends events to an I2RS Client on an existing 311 connection. 313 An I2RS action may require multiple I2RS messages in order to 314 complete a transation. 316 I2RS secondary identifier 318 The I2RS architecture document [I-D.ietf-i2rs-architecture] 319 defines a secondary identity as the entity of some non-I2RS entity 320 (e.g. application) which has requested a particular I2RS client 321 perform an operation. The I2RS secondary identifier represents 322 this identity so it may be distinguished from all others. 324 3. Security-Related Requirements 326 The security for the I2RS protocol requires mutually authenticated 327 I2RS clients and I2RS agents. The I2RS client and I2RS agent using 328 the I2RS protocol MUST be able to exchange data over a secure 329 transport, but some functions may operate on a non-secure transport. 330 The I2RS protocol MUST be able to provide atomicity of an I2RS 331 transaction, but it is not required to have multi-message atomicity 332 and roll-back mechanism transactions. Multiple messages transactions 333 may be impacted by the interdependency of data. This section 334 discusses the details of these security requirements. 336 There are dependencies in some of the requirements below. For 337 confidentiality (section 3.3) and integrity (section 3.4) to be 338 achieved, the client-agent must have mutual authentication (section 339 3.1) and secure transport (section 3.2). I2RS allows the use of an 340 insecure transport for portions of data models that clearly indicate 341 insecure transport. If insecure transport is used, then 342 confidentiality and integrity cannot be achieved. 344 3.1. Mutual authentication of an I2RS client and an I2RS Agent 346 The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following 347 requirements: 349 o SEC-REQ-01: All I2RS clients and I2RS agents MUST have an 350 identity, and at least one unique identifier that uniquely 351 identifies each party in the I2RS protocol context. 353 o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for 354 mutual identification of the I2RS client and I2RS agent. 356 o SEC-REQ-03: An I2RS agent, upon receiving an I2RS message from a 357 I2RS client, MUST confirm that the I2RS client has a valid 358 identifier. 360 o SEC-REQ-04: The I2RS client, upon receiving an I2RS message from 361 an I2RS agent, MUST confirm the I2RS agent has a valid identifier. 363 o SEC-REQ-05: Identifier distribution and the loading of these 364 identifiers into I2RS agent and I2RS Client SHOULD occur outside 365 the I2RS protocol. 367 o SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF 368 or private) will distribute or load identifiers so that the I2RS 369 client/agent has these identifiers prior to the I2RS protocol 370 establishing a connection between I2RS client and I2RS agent. 372 o SEC-REQ-07: Each Identifier MUST have just one priority. 374 o SEC-REQ-08: Each Identifier is associated with one secondary 375 identifier during a particular I2RS transaction (e.g. read/write 376 sequence), but the secondary identifier may vary during the time a 377 connection between the I2RS client and I2RS agent is active. 378 Since a single I2RS client may be use by multiple applications, 379 the secondary identifier may vary as the I2RS client is utilize by 380 different application each of whom have a unique secondary 381 identity and identifier. 383 3.2. Transport Requirements Based on Mutual Authentication 385 SEC-REQ-09: The I2RS protocol MUST be able to transfer data over a 386 secure transport and optionally MAY be able to transfer data over a 387 non-secure transport. A secure transport MUST provide data 388 confidentiality, data integrity, and replay prevention. 390 The default I2RS transport is a secure transport. 392 A non-secure transport can be can be used for publishing telemetry 393 data or other operational state that was specifically indicated to 394 non-confidential in the data model in the Yang syntax. 396 The configuration of ephemeral data in the I2RS Agent by the I2RS 397 client SHOULD be done over a secure transport. It is anticipated 398 that the passing of most I2RS ephemeral state operational status 399 SHOULD be done over a secure transport. As 400 [I-D.ietf-i2rs-ephemeral-state] notes data model MUST indicate 401 whether the transport exchanging the data between I2RS client and 402 I2RS agent is secure or insecure. The default mode of transport is 403 secure so data models SHOULD clearly annotate what data nodes can be 404 passed over an insecure connection. 406 SEC-REQ-10: A secure transport MUST be associated with a key 407 management solution that can guarantee that only the entities having 408 sufficient privileges can get the keys to encrypt/decrypt the 409 sensitive data. Per BCP107 [RFC4107] this key management system 410 SHOULD be automatic, but MAY be manual in the following scenarios: 412 a) The environment has limited bandwidth or high round-trip times. 414 b) The information being protected has low value. 416 c) The total volume of traffic over the entire lifetime of the 417 long-term session key will be very low. 419 d) The scale of the deployment is limited. 421 Most I2RS environments (Clients and Agents) will not have the 422 environment described by BCP107 [RFC4107] but a few I2RS use cases 423 required limited non-secure light-weight telemetry messages that have 424 these requirements. An I2RS data model must indicate which portions 425 can be served by manual key management. 427 SEC-REQ-11: The I2RS protocol MUST be able to support multiple secure 428 transport sessions providing protocol and data communication between 429 an I2RS Agent and an I2RS client. However, a single I2RS Agent to 430 I2RS client connection MAY elect to use a single secure transport 431 session or a single non-secure transport session. 433 SEC-REQ-12: The I2RS Client and I2RS Agent protocol SHOULD implement 434 mechanisms that mitigate DoS attacks. 436 3.3. Data Confidentiality Requirements 438 SEC-REQ-13: In a critical infrastructure, certain data within routing 439 elements is sensitive and read/write operations on such data SHOULD 440 be controlled in order to protect its confidentiality. For example, 441 most carriers do not want a router's configuration and data flow 442 statistics known by hackers or their competitors. While carriers may 443 share peering information, most carriers do not share configuration 444 and traffic statistics. To achieve this, access control to sensitive 445 data needs to be provided, and the confidentiality protection on such 446 data during transportation needs to be enforced. 448 3.4. Data Integrity Requirements 450 SEC-REQ-14: An integrity protection mechanism for I2RS SHOULD be able 451 to ensure the following: 453 1) the data being protected is not modified without detection 454 during its transportation, 456 2) the data is actually from where it is expected to come from, 457 and 459 3) the data is not repeated from some earlier interaction of the 460 protocol. (That is, when both confidentiality and integrity of 461 data is properly protected, it is possible to ensure that 462 encrypted data is not modified or replayed without detection.) 464 SEC-REQ-15: The integrity that the message data is not repeated means 465 that I2RS client to I2RS agent transport SHOULD protect against 466 replay attack 468 Requirements SEC-REQ-14 and SEC-REQ-15 are SHOULD requirements only 469 because it is recognized that some I2RS Client to I2RS agent 470 communication occurs over a non-secure channel. The I2RS client to 471 I2RS agent over a secure channel would implement these features. In 472 order to provide some traceability or notification for the non-secure 473 protocol, SEC-REQ-16 suggests traceability and notification are 474 important to include for any non-secure protocol. 476 SEC-REQ-16: The I2RS message traceability and notification 477 requirements requirements found in [I-D.ietf-i2rs-traceability] and 479 [I-D.ietf-i2rs-pub-sub-requirements] SHOULD be supported in 480 communication channel that is non-secure to trace or notify about 481 potential security issues. 483 3.5. Role-Based Data Model Security 485 The I2RS Architecture [I-D.ietf-i2rs-architecture] defines a role or 486 security role as specifying read, write, or notification access by a 487 I2RS client to data within an agent's data model. 489 SEC-REQ-17: The rules around what role is permitted to access and 490 manipulate what information plus a secure transport (which protects 491 the data in transit) SHOULD ensure that data of any level of 492 sensitivity is reasonably protected from being observed by those 493 without permission to view it, so that privacy requirements are met. 495 SEC-REQ-18: Role security MUST work when multiple transport 496 connections are being used between the I2RS client and I2RS agent as 497 the I2RS architecture [I-D.ietf-i2rs-architecture] states. These 498 transport message streams may start/stop without affecting the 499 existence of the client/agent data exchange. TCP supports a single 500 stream of data. SCTP [RFC4960] provides security for multiple 501 streams plus end-to-end transport of data. 503 SEC-REQ-19: I2RS clients MAY be used by multiple applications to 504 configure routing via I2RS agents, receive status reports, turn on 505 the I2RS audit stream, or turn on I2RS traceability. Application 506 software using I2RS client functions may host multiple secure 507 identities, but each connection will use only one identifier with one 508 priority. Therefore, the security of each I2RS Client to I2RS Agent 509 connection is unique. 511 Please note the security of the application to I2RS client connection 512 is outside of the I2RS protocol or I2RS interface. 514 Sec-REQ-20: If an I2RS agents or an I2RS client is tightly correlated 515 with a person, then the I2RS protocol and data models should provide 516 additional security that protects the person's privacy. An example 517 of an I2RS agent correlated with a person is a I2RS agent running on 518 someone's phone to control tethering, and an example of a I2RS client 519 might be the client tracking such tethering. This protection MAY 520 require a variety of forms including: "operator-applied knobs", roles 521 that restrict personal access, data-models with specific "privacy 522 roles", and access filters. 524 3.6. Security of the environment 526 The security for the implementation of a protocol also considers the 527 protocol environment. The environmental security requirements are 528 found in: [I-D.ietf-i2rs-security-environment-reqs]. 530 4. Acknowledgement 532 The authors would like to thank Wes George, Ahmed Abro, Qin Wu, Eric 533 Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia 534 Atlas, and Jeff Haas for their contributions to the I2RS security 535 requirements discussion and this document. The authors would like to 536 thank Bob Moskowitz for his review of the requirements. 538 5. IANA Considerations 540 This draft includes no request to IANA. 542 6. Security Considerations 544 This is a document about security requirements for the I2RS protocol 545 and data modules. The whole document is security considerations. 547 7. References 549 7.1. Normative References 551 [I-D.ietf-i2rs-architecture] 552 Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 553 Nadeau, "An Architecture for the Interface to the Routing 554 System", draft-ietf-i2rs-architecture-15 (work in 555 progress), April 2016. 557 [I-D.ietf-i2rs-problem-statement] 558 Atlas, A., Nadeau, T., and D. Ward, "Interface to the 559 Routing System Problem Statement", draft-ietf-i2rs- 560 problem-statement-11 (work in progress), May 2016. 562 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 563 Requirement Levels", BCP 14, RFC 2119, 564 DOI 10.17487/RFC2119, March 1997, 565 . 567 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 568 Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, 569 June 2005, . 571 7.2. Informative References 573 [I-D.ietf-i2rs-ephemeral-state] 574 Haas, J. and S. Hares, "I2RS Ephemeral State 575 Requirements", draft-ietf-i2rs-ephemeral-state-06 (work in 576 progress), May 2016. 578 [I-D.ietf-i2rs-pub-sub-requirements] 579 Voit, E., Clemm, A., and A. Prieto, "Requirements for 580 Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- 581 requirements-09 (work in progress), May 2016. 583 [I-D.ietf-i2rs-security-environment-reqs] 584 Migault, D., Halpern, J., and S. Hares, "I2RS Environment 585 Security Requirements", draft-ietf-i2rs-security- 586 environment-reqs-01 (work in progress), April 2016. 588 [I-D.ietf-i2rs-traceability] 589 Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to 590 the Routing System (I2RS) Traceability: Framework and 591 Information Model", draft-ietf-i2rs-traceability-11 (work 592 in progress), May 2016. 594 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 595 FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, 596 . 598 [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", 599 RFC 4960, DOI 10.17487/RFC4960, September 2007, 600 . 602 Authors' Addresses 604 Susan Hares 605 Huawei 606 7453 Hickory Hill 607 Saline, MI 48176 608 USA 610 Email: shares@ndzh.com 611 Daniel Migault 612 Ericsson 613 8400 boulevard Decarie 614 Montreal, QC HAP 2N2 615 Canada 617 Email: daniel.migault@ericsson.com 619 Joel Halpern 620 Ericsson 621 US 623 Email: joel.halpern@ericsson.com