idnits 2.17.1 draft-ietf-stir-threats-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 12, 2014) is 3538 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-10 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. Peterson 3 Internet-Draft NeuStar, Inc. 4 Intended status: Informational August 12, 2014 5 Expires: February 13, 2015 7 Secure Telephone Identity Threat Model 8 draft-ietf-stir-threats-04.txt 10 Abstract 12 As the Internet and the telephone network have become increasingly 13 interconnected and interdependent, attackers can impersonate or 14 obscure calling party numbers when orchestrating bulk commercial 15 calling schemes, hacking voicemail boxes or even circumventing multi- 16 factor authentication systems trusted by banks. This document 17 analyzes threats in the resulting system, enumerating actors, 18 reviewing the capabilities available to and used by attackers, and 19 describing scenarios in which attacks are launched. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 13, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2 56 2. Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . 4 59 2.3. Attackers . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. Voicemail Hacking via Impersonation . . . . . . . . . . . 6 62 3.2. Unsolicited Commercial Calling from Impersonated Numbers 7 63 3.3. Telephony Denial-of-Service Attacks . . . . . . . . . . . 8 64 4. Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . 9 65 4.1. Solution-Specific Attacks . . . . . . . . . . . . . . . . 10 66 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 8. Informative References . . . . . . . . . . . . . . . . . . . 11 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 72 1. Introduction and Scope 74 As is discussed in the STIR problem statement 75 [I-D.ietf-stir-problem-statement], the primary enabler of 76 robocalling, vishing, swatting and related attacks is the capability 77 to impersonate a calling party number. The starkest examples of 78 these attacks are cases where automated callees on the PSTN rely on 79 the calling number as a security measure, for example to access a 80 voicemail system. Robocallers use impersonation as a means of 81 obscuring identity; while robocallers can, in the ordinary PSTN, 82 block (that is, withhold) their calling number from presentation, 83 callees are less likely to pick up calls from blocked identities, and 84 therefore appearing to calling from some number, any number, is 85 preferable. Robocallers however prefer not to call from a number 86 that can trace back to the robocaller, and therefore they impersonate 87 numbers that are not assigned to them. 89 The scope of impersonation in this threat model pertains solely to 90 the rendering of a calling telephone number to a callee (human user 91 or automaton) at the time of call set-up. The primary attack vector 92 is therefore one where the attacker contrives for the calling 93 telephone number in signaling to be a chosen number. In this attack, 94 the number is one that the attacker is not authorized to use (as a 95 caller), but gives in order for that number to be consumed or 96 rendered on the terminating side. The threat model assumes that this 97 attack simply cannot be prevented: there is no way to stop the 98 attacker from creating call setup messages that contain attacker- 99 chosen calling telephone numbers. The solution space therefore 100 focuses on ways that terminating or intermediary elements might 101 differentiate authorized from unauthorized calling party numbers, in 102 order that policies, human or automatic, might act on that 103 information. 105 Securing an authenticated calling party number at call set-up time 106 does not entail any assertions about the entity or entities that will 107 send and receive media during the call itself. In call paths with 108 intermediaries and gateways (as described below), there may be no way 109 to provide any assurance in the signaling about participants in the 110 media of a call. In those end-to-end IP environments where such 111 assurance is possible, it is highly desirable. However, in the 112 threat model described in this document, "impersonation" does not 113 consider impersonating an authorized listener after a call has been 114 established (e.g., as a third party attempting to eavesdrop on a 115 conversation). Attackers that could impersonate an authorized 116 listener require capabilities that robocallers and voicemail hackers 117 are unlikely to possess, and historically such attacks have not 118 played a role in enabling robocalling or related problems. 120 In SIP and even many traditional telephone protocols, call signaling 121 can be renegotiated after the call has been established. Using 122 various transfer mechanisms common in telephone systems, a callee can 123 easily be connected to, or conferenced in with, telephone numbers 124 other than the original calling number once a call has been 125 established. These post-setup changes to the call are outside the 126 scope of impersonation considered in this model: the motivating use 127 cases of defeating robocalling, voicemail hacking and swatting all 128 rely on impersonation during the initial call setup. Furthermore, 129 this threat model does not include in its scope the verification of 130 the reached party's telephone number back to the originator of the 131 call. There is no assurance to the originator that they are reaching 132 the correct number, nor any indication when call forwarding has taken 133 place. This threat model is focused only on verifying the calling 134 party number to the callee. 136 In much of the PSTN, there exists a supplemental service that 137 translates calling party numbers into names, including the proper 138 names of people and businesses, for rendering to the called user. 139 These services (frequently marketed as part of 'Caller ID') provide a 140 further attack surface for impersonation. The threat model described 141 in this document addresses only the calling party number, even though 142 presenting a forged calling party number may cause a chosen calling 143 party name to be rendered to the user as well. Providing a 144 verifiable calling party number therefore improves the security of 145 calling party name systems, but this threat model does not consider 146 attacks specific to names. Such attacks may be carried out against 147 the databases consulted by the terminating side of a call to provide 148 calling party names, or by impersonators forging a particular calling 149 party number in order to present a misleading name to the user. 151 2. Actors 153 2.1. Endpoints 155 There are two main categories of end-user terminals relevant to this 156 discussion, a dumb device (such as a 'black phone') or a smart 157 device. 159 Dumb devices comprise a simple dial pad, handset and ringer, 160 optionally accompanied by a display that can render a limited 161 number of characters. Typically the display renders enough 162 characters for a telephone number and an accompanying name, but 163 sometimes fewer are rendered. Although users interface with these 164 devices, the intelligence that drives them lives in the service 165 provider network. 167 Smart devices are general purpose computers with some degree of 168 programmability, and with the capacity to access the Internet and 169 to render text, audio and/or images. This category includes smart 170 phones, telephone applications on desktop and laptop computers, IP 171 private branch exchanges, etc. 173 There is a further category of automated terminals without an end 174 user. These include systems like voicemail services, which may 175 provide a different set of services to a caller based solely on the 176 calling party's number, for example granting the (purported) mailbox 177 owner access to a menu while giving other callers only the ability to 178 leave a message. Though the capability of voicemail services varies 179 widely, many today have Internet access and advanced application 180 interfaces (to render 'visual voicemail,' [refs.OMTP-VV] to 181 automatically transcribe voicemail to email, etc.). 183 2.2. Intermediaries 185 The endpoints of a traditional telephone call connect through 186 numerous intermediary devices in the network. The set of 187 intermediary devices traversed during call setup between two 188 endpoints is referred to as a call path. The length of the call path 189 can vary considerably: it is possible in VoIP deployments for two 190 endpoint entities to send traffic to one another directly, but, more 191 commonly, several intermediaries exist in a VoIP call path. One or 192 more gateways also may appear on a call path. 194 Intermediaries forward call signaling to the next device in the 195 path. These intermediaries may also modify the signaling in order 196 to improve interoperability, to enable proper network-layer media 197 connections, or to enforce operator policy. This threat model 198 assumes there are no restrictions on the modifications to 199 signaling that an intermediary can introduce (which is consistent 200 with the observed behavior of such devices). 202 A gateway is a subtype of intermediary that translates call 203 signaling from one protocol into another. In the process, they 204 tend to consume any signaling specific of the original protocol 205 (elements like transaction-matching identifiers) and may need to 206 transcode or otherwise alter identifiers as they are rendered in 207 the destination protocol. 209 This threat model assumes that intermediaries and gateways can 210 forward and retarget calls as necessary, which can result in a call 211 terminating at a place the originator did not expect; this is a 212 common condition in call routing. This observation is significant to 213 the solution space, because it limits the ability of the originator 214 to anticipate what the telephone number of the respondent will be 215 (for more on the "unanticipated respondent" problem, see 216 [I-D.peterson-sipping-retarget]). 218 Furthermore, we assume that some intermediaries or gateways may, due 219 to their capabilities or policies, discard calling party number 220 information, in whole or in part. Today, many IP-PSTN gateways 221 simply ignore any information available about the caller in the IP 222 leg of the call, and allow the telephone number of the PRI line used 223 by the gateway to be sent as the calling party number for the PSTN 224 leg of the call. For example, a call might also gateway to a multi- 225 frequency network where only a limited number of digits of automatic 226 numbering identification (ANI) data are signaled. Some protocols may 227 render telephone numbers in a way that makes it impossible for a 228 terminating side to parse or canonicalize a number. In these cases, 229 providing authenticated calling number data may be impossible, but 230 this is not indicative of an attack or other security failure. 232 2.3. Attackers 234 We assume that an attacker has the following capabilities: 236 An attacker can create telephone calls at will, originating them 237 either on the PSTN or over IP, and can supply an arbitrary calling 238 party number. 240 An attacker can capture and replay signaling previously observed 241 by it. 243 An attacker has access to the Internet, and thus the ability to 244 inject arbitrary traffic over the Internet, to access public 245 directories, etc. 247 There are attack scenarios in which an attacker compromises 248 intermediaries in the call path, or captures credentials that allow 249 the attacker to impersonate a caller. Those system-level attacks are 250 not considered in this threat model, though secure design and 251 operation of systems to prevent these sorts of attacks are necessary 252 for envisioned countermeasures to work. To date, robocallers and 253 other impersonators do not resort to compromising systems, but rather 254 exploit the intrinsic lack of secure identity in existing mechanisms: 255 it is remedying this problem that lies within the scope of this 256 threat model. 258 This threat model also does not consider scenarios in which the 259 operators of intermediaries or gateways are themselves adversaries 260 who intentionally discard valid identity information (without a user 261 requesting anonymity) or who send falsified identity; see 262 Section 4.1. 264 3. Attacks 266 The uses of impersonation described in this section are broadly 267 divided into two categories: those where an attack will not succeed 268 unless the attacker impersonates a specific identity, and those where 269 an attacker impersonates an arbitrary identity in order to disguise 270 its own. At a high level, impersonation encourages targets to answer 271 attackers' calls and makes identifying attackers more difficult. 272 This section shows how concrete attacks based on those different 273 techniques might be launched. 275 3.1. Voicemail Hacking via Impersonation 277 A voicemail service may allow users calling from their phones access 278 to their voicemail boxes on the basis of the calling party number. 279 If an attacker wants to access the voicemail of a particular target, 280 the attacker may try to impersonate the calling party number using 281 one of the scenarios described in Section 4. 283 This attack is closely related to attacks on similar automated 284 systems, potentially including banks, airlines, calling-card 285 services, conferencing providers, ISPs, and other businesses that 286 fully or partly grant access to resources on the basis of the calling 287 party number alone (rather than any shared secret or further identity 288 check). It is analogous to an attack in which a human is encouraged 289 to answer a phone, or to divulge information once a call is in 290 progress, by seeing a familiar calling party number. 292 The envisioned countermeasures for this attack involve the voicemail 293 system treating calls that supply an authenticated calling number 294 data differently from other calls. In the absence of that identity 295 information, for example, a voicemail service might enforce some 296 other caller authentication policy (perhaps requiring a PIN for 297 caller authentication). Asserted caller identity alone provides an 298 authenticated basis for granting access to a voice mailbox only when 299 an identity is claimed legitimately; the absence of a verifiably 300 legitimate calling identity here may not be evidence of malice, just 301 of uncertainty or a limitation imposed by the set of intermediaries 302 traversed for a specific call path. 304 If the voicemail service could learn ahead of time that it should 305 expect authenticated calling number data from a particular number, 306 that would enable the voicemail service to adopt stricter policies 307 for handling a request without authentication data. Since users 308 typically contact a voicemail service repeatedly, the service could 309 for example remember which requests contain authenticated calling 310 number data and require further authentication mechanisms when 311 identity is absent. The deployment of such a feature would be 312 facilitated in many environments by the fact that the voicemail 313 service is often operated by an organization that would be in a 314 position to enable or require authentication of calling party 315 identity (for example, carriers or enterprises). Even if the 316 voicemail service is decoupled from the number assignee, issuers of 317 credentials or other authorities could provide a service that informs 318 verifiers that they should expect identity in calls from particular 319 numbers. 321 3.2. Unsolicited Commercial Calling from Impersonated Numbers 323 The unsolicited commercial calling, or for short robocalling, attack 324 is similar to the voicemail attack, except that the robocaller does 325 not need to impersonate the particular number controlled by the 326 target, merely some "plausible" number. A robocaller may impersonate 327 a number that is not an assignable number (for example, in the United 328 States, a number beginning with 0), or an unassigned number. This 329 behavior is seen in the wild today. A robocaller may change numbers 330 every time a new call is placed, e.g., selecting numbers randomly. 332 A closely related attack is sending unsolicited bulk commercial 333 messages via text messaging services. These messages usually 334 originate on the Internet, though they may ultimately reach endpoints 335 over traditional telephone network protocols or the Internet. While 336 most text messaging endpoints are mobile phones, increasingly, 337 broadband residential services support text messaging as well. The 338 originators of these messages typically impersonate a calling party 339 number, in some cases a "short code" specific to text messaging 340 services. 342 The envisioned countermeasures to robocalling are similar to those in 343 the voicemail example, but there are significant differences. One 344 important potential countermeasure is simply to verify that the 345 calling party number is in fact assignable and assigned. Unlike 346 voicemail services, end users typically have never been contacted by 347 the number used by a robocaller before. Thus they can't rely on past 348 association to anticipate whether or not the calling party number 349 should supply authenticated calling number data. If there were a 350 service that could inform the terminating side that it should expect 351 this data for calls or texts from that number, however, that would 352 also help in the robocalling case. 354 When a human callee is to be alerted at call setup time, the time 355 frame for executing any countermeasures is necessarily limited. 356 Ideally, a user would not be alerted that a call has been received 357 until any necessary identity checks have been performed. This could 358 however result in inordinate post-dial delay from the perspective of 359 legitimate callers. Cryptographic and network operations must be 360 minimized for these countermeasures to be practical. For text 361 messages, a delay for executing anti-impersonation countermeasures is 362 much less likely to degrade perceptible service. 364 The eventual effect of these countermeasures would be to force 365 robocallers to either block their caller identity, in which case end 366 users could opt not to receive such calls or messages, or to force 367 robocallers to use authenticated calling numbers traceable to them, 368 which would then allow for other forms of redress. 370 3.3. Telephony Denial-of-Service Attacks 372 In the case of telephony denial-of-service (or TDoS) attacks, the 373 attack relies on impersonation in order to obscure the origin of an 374 attack that is intended to tie up telephone resources. By placing 375 incessant telephone calls, an attacker renders a target number 376 unreachable by legitimate callers. These attacks might target a 377 business, an individual or a public resource like emergency 378 responders; the attacker may intend to extort the target. Attack 379 calls may be placed from a single endpoint, or from multiple 380 endpoints under the control of the attacker, and the attacker may 381 control endpoints in different administrative domains. Impersonation 382 in this case allows the attack to evade policies that would block 383 based on the originating number, and furthermore prevents the victim 384 from learning the perpetrator of the attack, or even the originating 385 service provider of the attacker. 387 As is the case with robocalling, the attacker typically does not have 388 to impersonate a specific number in order to launch a denial-of- 389 service attack. The number simply has to vary enough to prevent 390 simple policies from blocking the attack calls. An attacker may 391 however have a further intention to create the appearance that a 392 particular party is to blame for an attack, and in that case, the 393 attacker might want to impersonate a secondary target in the attack. 395 The envisioned countermeasures are twofold. First, as with 396 robocalling, ensuring that calling party numbers are assignable or 397 assigned will help mitigate unsophisticated attacks. Second, if 398 authenticated calling number data is supplied for legitimate calls, 399 then Internet endpoints or intermediaries can make effective policy 400 decisions in the middle of an attack by deprioritizing unsigned calls 401 when congestion conditions exist; signed calls, if accepted, have the 402 necessary accountability should it turn out they are malicious. This 403 could extend to include, for example, an originating network 404 observing a congestion condition for a destination number and perhaps 405 dropping unsigned calls that are clearly part of a TDoS attack. As 406 with robocalling, all of these countermeasures must execute in a 407 timely manner to be effective. 409 There are certain flavors of TDoS attacks, including those against 410 emergency responders, against which authenticated calling number data 411 is unlikely to be a successful countermeasure. These entities are 412 effectively obligated to attempt to respond to every call they 413 receive, and the absence of authenticated calling number data in many 414 cases will not remove that obligation. 416 4. Attack Scenarios 418 The examples that follow rely on Internet protocols including SIP 419 [RFC3261] and WebRTC [I-D.ietf-rtcweb-overview]. 421 Impersonation, IP-IP 423 An attacker with an IP phone sends a SIP request to an IP-enabled 424 voicemail service. The attacker puts a chosen calling party number 425 into the From header field value of the INVITE. When the INVITE 426 reaches the endpoint terminal, the terminal renders the attacker's 427 chosen calling party number as the calling identity. 429 Impersonation, PSTN-PSTN 431 An attacker with a traditional PBX (connected to the PSTN through 432 ISDN) sends a Q.931 SETUP request with a chosen calling party number 433 which a service provider inserts into the corresponding SS7 434 [refs.Q764] calling party number (CgPN) field of a call setup message 435 (IAM). When the call setup message reaches the endpoint switch, the 436 terminal renders the attacker's chosen calling party number as the 437 calling identity. 439 Impersonation, IP-PSTN 441 An attacker on the Internet uses a commercial WebRTC service to send 442 a call to the PSTN with a chosen calling party number. The service 443 contacts an Internet-to-PSTN gateway, which inserts the attacker's 444 chosen calling party number into the SS7 [refs.Q764] call setup 445 message (the CgPN field of an IAM). When the call setup message 446 reaches the terminating telephone switch, the terminal renders the 447 attacker's chosen calling party number as the calling identity. 449 Impersonation, IP-PSTN-IP 451 An attacker with an IP phone sends a SIP request to the telephone 452 number of a voicemail service, perhaps without even knowing that the 453 voicemail service is IP-based. The attacker puts a chosen calling 454 party number into the From header field value of the INVITE. The 455 attacker's INVITE reaches an Internet-to-PSTN gateway, which inserts 456 the attacker's chosen calling party number into the CgPN of an IAM. 457 That IAM then traverses the PSTN until (perhaps after a call 458 forwarding) it reaches another gateway, this time back to the IP 459 realm, to an H.323 network. The PSTN-IP gateway takes the calling 460 party number in the IAM CgPN field and puts it into the SETUP 461 request. When the SETUP reaches the endpoint terminal, the terminal 462 renders the attacker's chosen calling party number as the calling 463 identity. 465 4.1. Solution-Specific Attacks 467 Solution-specific attacks are outside the scope of this document, 468 though two sorts of solutions are anticipated by the STIR problem 469 statement: in-band and out-of-band solutions (see 470 [I-D.ietf-stir-problem-statement]). There are a few points which 471 future work on solution-specific threats must acknowledge. The 472 design of the credential system envisioned as a solution to this 473 threats must for example limit the scope of the credentials issued to 474 carriers or national authorities to those numbers that fall under 475 their purview. This will impose limits on what (verifiable) 476 assertions can be made by intermediaries. 478 Some of the attacks that should be considered in the future include 479 the following: 481 Attacks Against In-band Solutions 482 Replaying parts of messages used by the solution 484 Using a SIP REFER request to induce a party with access to 485 credentials to place a call to a chosen number 487 Removing parts of messages used by the solution 489 Attacks Against Out-of-Band Solutions 491 Provisioning false or malformed data reflecting a placed call into 492 any datastores that are part of the out-of-band mechansim 494 Mining any datastores that are part of the out-of-band mechanism 496 Attacks Against Either Approach 498 Attack on any directories/services that report whether you should 499 expect authenticated calling number data or not 501 Canonicalization attacks 503 5. Acknowledgments 505 Sanjay Mishra, David Frankel, Penn Pfautz, Stephen Kent, Brian Rosen, 506 Alex Bobotek, Henning Schulzrinne, Hannes Tschofenig, Cullen Jennings 507 and Eric Rescorla provided key input to the discussions leading to 508 this document. 510 6. IANA Considerations 512 This memo includes no request to IANA. 514 7. Security Considerations 516 This document provides a threat model and is thus entirely about 517 security. 519 8. Informative References 521 [I-D.ietf-rtcweb-overview] 522 Alvestrand, H., "Overview: Real Time Protocols for 523 Browser-based Applications", draft-ietf-rtcweb-overview-10 524 (work in progress), June 2014. 526 [I-D.ietf-stir-problem-statement] 527 Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 528 Telephone Identity Problem Statement and Requirements", 529 draft-ietf-stir-problem-statement-05 (work in progress), 530 May 2014. 532 [I-D.peterson-sipping-retarget] 533 Peterson, J., "Retargeting and Security in SIP: A 534 Framework and Requirements", draft-peterson-sipping- 535 retarget-00 (work in progress), February 2005. 537 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 538 A., Peterson, J., Sparks, R., Handley, M., and E. 539 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 540 June 2002. 542 [refs.OMTP-VV] 543 OMTP, , "Visual Voice Mail Interface Specification", URL: 544 http://www.gsma.com/newsroom/wp-content/uploads/2012/07/ 545 OMTP_VVM_Specification_1_3.pdf, May 1998. 547 [refs.Q764] 548 ITU-T, , "Signaling System No. 7; ISDN User Part Signaling 549 procedure", ITU-T URL: 550 http://www.itu.int/rec/T-REC-Q.764/_page.print, September 551 1997. 553 [refs.Q931] 554 ITU-T, , "ISDN user-network interface layer 3 555 specification for basic call control", ITU-T URL: 556 http://www.itu.int/rec/T-REC-Q.931-199805-I/en, May 1998. 558 Author's Address 560 Jon Peterson 561 NeuStar, Inc. 562 1800 Sutter St Suite 570 563 Concord, CA 94520 564 US 566 Email: jon.peterson@neustar.biz