idnits 2.17.1 draft-ietf-savi-framework-05.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 25, 2011) is 4658 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Wu 3 Internet-Draft J. Bi 4 Intended status: Informational Tsinghua Univ. 5 Expires: January 26, 2012 M. Bagnulo 6 UC3M 7 F. Baker 8 Cisco 9 C. Vogt, Ed. 10 Ericsson 11 July 25, 2011 13 Source Address Validation Improvement Framework 14 draft-ietf-savi-framework-05 16 Abstract 18 The Source Address Validation Improvement method was developed to 19 complement ingress filtering with finer-grained, standardized IP 20 source address validation. This document describes and motivates the 21 design of the SAVI method. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 26, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Deployment Options . . . . . . . . . . . . . . . . . . . . . . 6 72 4. Scalability Optimizations . . . . . . . . . . . . . . . . . . 8 73 5. Reliability Optimizations . . . . . . . . . . . . . . . . . . 10 74 6. Scenario with Multiple Assignment Methods . . . . . . . . . . 10 75 7. Prefix Configuration . . . . . . . . . . . . . . . . . . . . . 11 76 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12 77 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 11.1. Informative References . . . . . . . . . . . . . . . . . 12 81 11.2. Normative References . . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 Since IP source addresses are used by hosts and network entities to 87 determine the origin of a packet and as a destination for return 88 data, spoofing of IP source addresses can enable impersonation, 89 concealment, and malicious traffic redirection. Unfortunately, the 90 Internet architecture does not prevent IP source address spoofing 91 [draft-ietf-savi-threat-scope]. Since the IP source address of a 92 packet generally takes no role in forwarding the packet, it can be 93 selected arbitrarily by the sending host without jeopardizing packet 94 delivery. Extra methods are necessary for IP source address 95 validation, to augment packet forwarding with an explicit check of 96 whether a given packet's IP source address is legitimate. 98 IP source address validation can happen at different granularity: 99 Ingress filtering [BCP38], a widely deployed standard for IP source 100 address validation, functions at the coarse granularity of networks. 101 It verifies that the prefix of an IP source address routes to the 102 network from which the packet was received. An advantage of ingress 103 filtering is simplicity: the decision of whether to accept or to 104 reject an IP source address can be made solely based on the 105 information available from routing protocols. However, the 106 simplicity comes at the cost of not being able to validate IP source 107 addresses at a finer granularity, due to the aggregated nature of the 108 information available from routing protocols. Finer-grained IP 109 source address validation would ensure that source address 110 information is accurate, reduce the ability to launch denial-of- 111 service attacks, and help with localizing hosts and identify 112 misbehaving hosts. Partial solutions [BA2007] exist for finer- 113 grained IP source address validation, but are proprietary and hence 114 often unsuitable for corporate procurement. 116 The Source Address Validation Improvement method was developed to 117 complement ingress filtering with standardized IP source address 118 validation at the maximally fine granularity of individual IP 119 addresses: It prevents hosts attached to the same link from spoofing 120 each other's IP addresses. To facilitate deployment in networks of 121 various kinds, the SAVI method was designed to be modular and 122 extensible. This document describes and motivates the design of the 123 SAVI method. 125 2. Model 127 To enable network operators to deploy fine-grained IP source address 128 validation without a dependency on supportive functionality on hosts, 129 the SAVI method was designed to be purely network-based. A SAVI 130 instance is located on the path of hosts' packets, enforcing the 131 hosts' use of legitimate IP source addresses according to the 132 following three-step model: 134 1. Identify which IP source addresses are legitimate for a host, 135 based on monitoring packets exchanged by the host. 137 2. Bind a legitimate IP address to a link layer property of the 138 host's network attachment. This property, called a "binding 139 anchor", must be verifiable in every packet that the host sends, 140 and harder to spoof than the host's IP source address itself. 142 3. Enforce that the IP source addresses in packets match the binding 143 anchors to which they were bound. 145 This model allows SAVI functionality (a SAVI instance) to be located 146 anywhere on the link to which the hosts attach, hence enabling 147 different locations for a SAVI instance. One way to locate a SAVI 148 instance is in the hosts' default router. IP source addresses are 149 then validated in packets traversing the default router, yet the IP 150 source addresses in packets exchanged locally on the link may bypass 151 validation. Another way to locate a SAVI instance is in a switch 152 between the hosts and their default router. Thus, packets may 153 undergo IP source address validation even if exchanged locally on the 154 link. 156 The closer a SAVI instance is located to the hosts, the more 157 effective the SAVI method is. This is because each of the three 158 steps of the SAVI model can best be accomplished in a position close 159 to the host: 161 o Identifying a host's legitimate IP source addresses is most 162 efficient close to the host, because the likelihood that the 163 host's packets bypass a SAVI instance, and hence cannot be 164 monitored, increases with the distance between the SAVI instance 165 and the host. 167 o Selecting a binding anchor for a host's IP source address is 168 easiest close to the host, because many link layer properties are 169 unique for a given host only on a link segment directly attaching 170 to the host. 172 o Enforcing a host's use of a legitimate IP source address is most 173 reliable when pursued close to the host, because the likelihood 174 that the host's packets bypass a SAVI instance, and hence do not 175 undergo IP source address validation, increases with the distance 176 between the SAVI instance and the host. 178 The preferred location of SAVI instances is therefore close to hosts, 179 such as in switches that directly attach to the hosts whose IP source 180 addresses are being validated. 182 Nevertheless, it is useful for SAVI mechanisms to be able to handle 183 situations where hosts are not directly attached to the SAVI-capable 184 device. For instance, deployments with both SAVI-capable and legacy 185 switches could be supported. In general, a SAVI solution needs to 186 specify how it deals with a number of deployment scenarios and 187 exceptional situations, including interaction with legacy devices, 188 hosts moving between wireless attachment points, network partitions, 189 and so on. 191 Besides, in the case of legacy switches, the security level is lower, 192 as there is no full protection for the hosts connected to the legacy 193 server. 195 3. Deployment Options 197 The model of the SAVI method, as explained in Section 2, is 198 deployment-specific in two ways: 200 o The identification of legitimate IP source addresses is dependent 201 on the IP address assignment method in use on a link, since it is 202 through assignment that a host becomes the legitimate user of an 203 IP source address. 205 o Binding anchors are dependent on the technology used to build the 206 link on which they are used, as binding anchors are link layer 207 properties of a host's network attachment. 209 To facilitate the deployment of the SAVI method in networks of 210 various kinds, the SAVI method is designed to support different IP 211 address assignment methods, and to function with different binding 212 anchors. Naturally, both the IP address assignment methods in use on 213 a link and the available binding anchors have an impact on the 214 functioning and the strength of IP source address validation. The 215 following two sub-sections explain this impact, and describe how the 216 SAVI method accommodates this. 218 3.1. IP Address Assignment Methods 220 Since the SAVI method traces IP address assignment packets, it 221 necessarily needs to incorporate logic that is specific to particular 222 IP address assignment methods. However, developing SAVI method 223 variants for each IP address assignment method is alone not 224 sufficient, since multiple IP address assignment methods may co-exist 225 on a given link. The SAVI method hence comes in multiple variants: 227 for links with DHCP [rfc2131][rfc3315], Stateless Address 228 Autoconfiguration [rfc4862] with or without Secure Neighbor Discovery 229 [rfc3971], IKEv2[rfc5996] [rfc5739] [rfc5026] and combinations 230 thereof. 232 The reason to develop SAVI method variants for each single IP address 233 configuration method, in addition to the variant that handles all IP 234 address assignment methods, is to minimize the complexity of the 235 common case: many link deployments today either are constrained to a 236 single IP address assignment methods or, equivalently from the 237 perspective of the SAVI method, separate IP address assignment 238 methods into different IP address prefixes. The SAVI method for such 239 links can be simpler than the SAVI method for links with multiple IP 240 address assignment methods per IP address prefix. 242 3.2. Binding Anchors 244 The SAVI method supports a range of binding anchors: 246 o The IEEE extended unique identifier, EUI-48 or EUI-64, of a host's 247 interface. 249 o The port on an Ethernet switch to which a host attaches. 251 o The security association between a host and the base station on 252 wireless links. 254 o The combination of a host interface's link-layer address and a 255 customer relationship in cable modem networks. 257 o An ATM virtual channel, a PPPoE session identifier, or an L2TP 258 session identifier in a DSL network. 260 o A tunnel that connects to a single host, such as an IP-in-IP 261 tunnel, a GRE tunnel, or an MPLS label-switched path. 263 The various binding anchors differ significantly in the security they 264 provide. IEEE extended unique identifiers, for example, fail to 265 render a secure binding anchor because they can be spoofed with 266 little effort. And switch ports alone may be insufficient because 267 they may connect to more than a single host, such as in the case of 268 concatenated switches. 270 Given this diversity in the security provided, one could define a set 271 of possible binding anchors, and leave it up to the administrator to 272 choose one or more of them. Such a selection of binding anchors 273 would, of course, have to be accompanied by an explanation of the 274 pros and cons of the different binding anchors. In addition, SAVI 275 devices may have a default binding anchor depending on the lower 276 layers. Such a default could be to use switch ports when available, 277 and MAC addresses otherwise. Or to use MAC addresses, and switch 278 ports in addition if available. 280 4. Scalability Optimizations 282 The preference to locate a SAVI instance close to hosts implies that 283 multiple SAVI instances must be able to co-exist in order to support 284 large links. Although the model of the SAVI method is independent of 285 the number of SAVI instances per link, co-existence of multiple SAVI 286 instances without further measures can lead to higher-than-necessary 287 memory requirements: since a SAVI instance creates bindings for the 288 IP source addresses of all hosts on a link, bindings are replicated 289 if multiple SAVI instances co-exist on the link. High memory 290 requirements, in turn, increase the cost of a SAVI instance. This is 291 problematic in particular for SAVI instances that are located on a 292 switch, since it may significantly increase the cost of such a 293 switch. 295 To reduce memory requirements for SAVI instances that are located on 296 a switch, the SAVI method enables the suppression of binding 297 replication on links with multiple SAVI instances. This requires 298 manual disabling of IP source address validation on switch ports that 299 connect to other switches running a SAVI instance. Each SAVI 300 instance is then responsible for validating IP source addresses only 301 on those ports to which hosts attach either directly, or via switches 302 without a SAVI instance. On ports towards other switches running a 303 SAVI instance, IP source addresses are not validated. The switches 304 running SAVI instances thus form a "protection perimeter". The IP 305 source addresses in packets passing the protection perimeter are 306 validated by the ingress SAVI instance, but no further validation 307 takes place as long as the packets remain within, or leave the 308 protection perimeter. 310 .............. 311 protection perimeter --> : +--------+ : 312 +---+ +---+ : | SAVI | : 313 | A | | B | <-- hosts : | switch | : 314 +---+ +---+ : +--------+ : 315 ...|......|.............................: | : 316 : +--------+ +--------+ +--------+ : 317 : | SAVI |----------| legacy | | SAVI | : 318 : | switch | | switch |----------| switch | : 319 : +--------+ +--------+ +--------+ : 320 : | ...............................|........: 321 : +--------+ : +--------+ 322 : | SAVI | : | legacy | 323 : | switch | : | switch | 324 : +--------+ : +--------+ 325 :............: | | 326 +---+ +---+ 327 hosts --> | C | | D | 328 +---+ +---+ 330 Figure 1: Protection perimeter concept 332 Figure 1 illustrates the concept of the protection perimeter. The 333 figure shows a link with six switches, of which four, denoted "SAVI 334 switch", run a SAVI instance. The protection perimeter created by 335 the four SAVI instances is shown as a dotted line in the figure. IP 336 source address validation is enabled on all switch ports on the 337 protection perimeter, and it is disabled on all other switch ports. 338 Four hosts, denoted A through D in the figure, attach to the 339 protection perimeter. 341 In the example of figure Figure 1, the protection perimeter 342 encompasses one of the legacy switches, located in the middle of the 343 depicted link topology. This enables a single, unpartitioned 344 protection perimeter. A single protection perimeter minimizes memory 345 requirements for the SAVI instances because every binding is kept 346 only once, namely, by the SAVI instance that attaches to the host 347 being validated. Excluding the legacy switch from the protection 348 perimeter would result in two smaller protection perimeters to the 349 left and to the right of the depicted link topology. The memory 350 requirements for the SAVI instances would then be higher: since IP 351 source address validation would be activated on the two ports 352 connecting to the legacy switch, the SAVI instances adjacent to the 353 legacy switch would replicate all bindings from the respectively 354 other protection perimeter. The reason why it is possible to include 355 the legacy switch in the protection perimeter is because the depicted 356 link topology guarantees that packets cannot enter the protection 357 perimeter via this legacy switch. Without this guarantee, the legacy 358 switch would have to be excluded from the protection perimeter in 359 order to ensure that packets entering the protection perimeter 360 undergo IP source address validation. 362 5. Reliability Optimizations 364 The explicit storage of legitimate IP addresses in the form of 365 bindings implies that failure to create a binding, or the premature 366 removal of bindings, can lead to loss of legitimate packets. There 367 are three situations in which this can happen: 369 o Legitimate IP address configuration packets, which should trigger 370 the creation of a binding in a SAVI instance, are lost before 371 reaching the SAVI instance. 373 o A SAVI instance loses a binding, for example, due to a restart. 375 o The link topology changes, resulting in hosts to communicate 376 through SAVI instances that do not have a binding for those hosts' 377 IP addresses. 379 To limit the disruption that missing bindings for legitimate IP 380 addresses can have, the SAVI method includes a mechanism for reactive 381 binding creation based on regular packets. This mechanism 382 supplements the proactive binding creation based on IP address 383 configuration packets. Reactive binding creation occurs when a SAVI 384 instances recognizes excessive drops of regular packets originating 385 from the same IP address. The SAVI instance then verifies whether 386 said IP address is unique on the link. How the verification is 387 carried out depends on the IP address configuration method that the 388 SAVI instance supports: the SAVI method variant for Stateless 389 Address Autoconfiguration and for Secure Neighbor Discovery verifies 390 an IP address through the Duplicate Address Detection procedure. The 391 SAVI method variant for DHCP verifies an IP address through a DHCP 392 Lease Query message exchange with the DHCP server. If verification 393 indicates that the IP address is unique on the link, the SAVI 394 instance creates a binding for the IP address. Otherwise, no binding 395 is created, and packets sent from the IP address continue to be 396 dropped. 398 6. Scenario with Multiple Assignment Methods 400 While multiple assignment methods can be used on the same link, the 401 SAVI device may have to deal with a mix of binding discovery methods. 402 If the address prefix used for each assignment method is different, 403 mix scenario can handle the same as scenario with only one assignment 404 method. If different address assignment methods are used to assign 405 addresses from the same prefix, additional considerations are needed 406 because one binding mechanism may create a binding violating an 407 existing binding from another binding mechanism, e.g., binding from 408 SAVI-FCFS [savi-fcfs] may violate binding from SAVI-DHCP [savi-dhcp]. 409 Thus, the collision between different SAVI mechanisms in mix scenario 410 must be handled in case more than one address assignment method is 411 used to assign addresses from the same prefix. 413 Prioritization relationship between different address assignment 414 methods is used as the basis to solve possible collisions. Current 415 standard documents of address assignment methods have implied the 416 prioritization relationship in general cases. However, considering 417 in some scenarios, default prioritization level may not be quite 418 suitable. Configurable prioritization level should be supported in a 419 document of SAVI solution for the mix scenario. 421 7. Prefix Configuration 423 Before setting up a host-level granularity binding, it is important 424 to configure correct prefixes on the SAVI device. This document 425 suggests set 3 prefix configuration mechanisms at SAVI device: 427 o Manual Prefix Configuration: The allowed prefix scope of IPv4 428 Addresses, IPv6 static addresses, IPv6 addresses assigned by 429 SLAAC, and IPv6 addresses assigned by DHCPv6 can be set manually 430 at SAVI device. FE80::/64 is always a feasible prefix in IPv6. 432 o Prefix Configuration by RA Snooping: The allowed prefix scope of 433 IPv6 static addresses and IPv6 addresses assigned by SLAAC can be 434 set at SAVI device through snooping RA message at SAVI device. 436 o Prefix Configuration by DHCP-PD Snooping: The allowed prefix 437 scope of IPv6 static addresses, IPv6 addresses assigned by SLAAC, 438 and IPv6 addresses assigned by DHCPv6 can be set through snooping 439 DHCP-PD message at SAVI device. 441 If some of the prefix scopes is set to have no prefix, it implies 442 corresponding address assignment method is not allowed in the 443 network. 445 There is no need to explicitly present these prefix scopes, but these 446 restrictions should be used as premier check in binding set up. 448 8. Acknowledgment 450 The authors would like to thank the SAVI working group for a thorough 451 technical discussion on the design and the framework of the SAVI 452 method, as captured in this document, in particular Erik Nordmark, 453 Guang Yao, Eric Levy-Abegnoli, and Alberto Garcia. Thanks also to 454 Torben Melsen for reviewing this document. 456 This document was generated using the xml2rfc tool. 458 9. IANA Considerations 460 This memo asks the IANA for no new parameters. 462 Note to RFC Editor: This section will have served its purpose if it 463 correctly tells IANA that no new assignments or registries are 464 required, or if those assignments or registries are created during 465 the RFC publication process. From the authors' perspective, it may 466 therefore be removed upon publication as an RFC at the RFC Editor's 467 discretion. 469 10. Security Considerations 471 This document only discusses the possible methods to mitigate the 472 usage of forged IP addresses. Some such methods may rely on 473 cryptographic methods, but not all do. As a result, it is generally 474 not possible to prove address ownership in any strong sense. If 475 binding anchor is not exclusive for each user, or is without strong 476 security, addresses can still be forged. Besides, the binding may 477 not accord with the address management requirement, which can be more 478 specified for each client. However, given no new protocol is 479 introduced, the improvements are still acceptable. If there is 480 requirement the usage of IP address must be of strong security, the 481 only way is using cryptographic based authentication. 483 11. References 485 11.1. Informative References 487 [BA2007] Baker, F., "Cisco IP Version 4 Source Guard", IETF 488 Internet draft (work in progress), November 2007. 490 [BCP38] Paul, P. and D. Senie, "Network Ingress Filtering: 491 Defeating Denial of Service Attacks which employ IP Source 492 Address Spoofing", RFC 2827, BCP 38, May 2000. 494 11.2. Normative References 496 [draft-ietf-savi-threat-scope] 497 McPherson, D., Baker, F., and J. Halpern, "SAVI Threat 498 Scope", draft-ietf-savi-threat-scope-04 (work in 499 progress), March 2011. 501 [rfc2131] Droms, R., "Dynamic Host Configuration Protocol", 502 RFC 2131, March 1997. 504 [rfc3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 505 and M. Carney, "Dynamic Host Configuration Protocol for 506 IPv6 (DHCPv6)", RFC 3315, July 2003. 508 [rfc3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 509 Neighbor Discovery (SEND)", RFC 3971, March 2005. 511 [rfc4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 512 Address Autoconfiguration", RFC 4862, September 2007. 514 [rfc5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 515 Bootstrapping in Split Scenario", RFC 5026, October 2007. 517 [rfc5739] Eronen, P., Laganier, J., and C. Madson, "IPv6 518 Configuration in Internet Key Exchange Protocol Version 2 519 (IKEv2)", RFC 5739, February 2010. 521 [rfc5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 522 "Internet Key Exchange Protocol Version 2 (IKEv2)", 523 RFC 5996, September 2010. 525 [savi-dhcp] 526 Bi, J., Wu, J., Yao, G., and F. Baker, "SAVI Solution for 527 DHCP", draft-ietf-savi-dhcp-07 (work in progress), 528 November 2010. 530 [savi-fcfs] 531 Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS- 532 SAVI: First-Come First-Serve Source-Address Validation for 533 Locally Assigned Addresses", draft-ietf-savi-fcfs-05 (work 534 in progress), October 2010. 536 Authors' Addresses 538 Jianping Wu 539 Tsinghua University 540 Computer Science, Tsinghua University 541 Beijing 100084 542 China 544 Email: jianping@cernet.edu.cn 546 Jun Bi 547 Tsinghua University 548 Network Research Center, Tsinghua University 549 Beijing 100084 550 China 552 Email: junbi@tsinghua.edu.cn 554 Marcelo Bagnulo 555 Universidad Carlos III de Madrid 556 Avenida de la Universidad 30 557 Leganes, Madrid 28911 558 Spain 560 Email: marcelo@it.uc3m.es 562 Fred Baker 563 Cisco Systems 564 Santa Barbara, CA 93117 565 United States 567 Email: fred@cisco.com 569 Christian Vogt (editor) 570 Ericsson 571 200 Holger Way 572 San Jose, CA 95134 573 United States 575 Email: christian.vogt@ericsson.com