idnits 2.17.1 draft-wing-rtcweb-identity-media-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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2012) is 4407 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 4572 (Obsoleted by RFC 8122) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Wing 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track H. Kaplan 5 Expires: September 6, 2012 Acme Packet 6 March 5, 2012 8 SIP Identity using Media Path 9 draft-wing-rtcweb-identity-media-00 11 Abstract 13 This document defines a new SIP identity mechanism which creates a 14 signature over a certain subset of SIP headers and certain subset of 15 SDP lines. This this mechanism works with trickling ICE candidates 16 and works across zero or more Session Border Controllers. 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 September 6, 2012. 35 Copyright Notice 37 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 54 3. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Identity Media Signature . . . . . . . . . . . . . . . . . 6 56 3.2. Authentication Service . . . . . . . . . . . . . . . . . . 7 57 3.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 7 58 4. Proof of Identity Techniques . . . . . . . . . . . . . . . . . 7 59 4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 4.2. DTLS-SRTP . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 6.1. Device Disclosure . . . . . . . . . . . . . . . . . . . . 9 64 6.2. Modification of SDP . . . . . . . . . . . . . . . . . . . 10 65 7. Operational Differences from RFC4474 . . . . . . . . . . . . . 10 66 8. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 9.1. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 70 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 12. Normative References . . . . . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 SIP Identity [RFC4474] provides cryptographic identity for SIP 77 requests. It provides this protection by signing certain SIP header 78 fields (Contact, Date, Call-ID, CSeq, To, and From) and the SIP 79 message body. This mechanism suffers from two problems. First, it 80 is inefficient when ICE candidates are trickled (as each update to 81 the ICE candidate list would have to be signed and validated). 82 Second, it breaks entirely if IP addresses are modified during SIP 83 routing, such as by a Session Border Controller. 85 To avoid these problems, a new mechanism is described in this 86 document which provides cryptographic assurance of the endpoint's 87 identity that works with ICE candidate trickling and works through 88 most B2BUAs and through most SBCs. 90 The mechanism described in this document signs only certain SDP 91 attributes (rather than all SDP attributes) and certain SIP headers. 92 The remote endpoint is expected to validate the signature and 93 initiate a cryptographic handshake over the media path, which proves 94 the session has been established with the "From:" party in the SIP 95 header. A mechanism to perform the handshake over the media path is 96 shown using DTLS-SRTP and TLS. This mechanism is extensible so that 97 techniques other than DTLS-SRTP or TLS can be used. 99 Readers of this document are expected to be familiar with 100 "Enhancements for Authenticated Identity Management in the Session 101 Initiation Protocol (SIP)" [RFC4474], which defines the Identity and 102 Identity-Info header fields that are also used by this document. 104 2. Notational Conventions 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 3. Operation 112 This document can utilize an authentication proxy, a concept 113 originally introduced in [RFC4474]. The basic steps are: 115 o A new header, Identity-Media, is created containing the names of 116 certain SDP attributes from SDP bodyparts, and containing a hash 117 of non-SDP bodyparts. 119 o Several SIP headers and the Identity-Media header are all signed 120 (as detailed in Section 3.1), and the result is placed in 121 Identity-Media-Signature. 123 o The receiving domain validates the signature, and if the request 124 is an invitation to establish a media channel, performs a proof of 125 identity validation using DTLS. 127 The following figure shows how the Authentication Service and the 128 media validation is performed. The figure assumes the endpoints 129 themselves perform the media validation. 131 : Service : 132 Enterprise-A : Provider-1 : Enterprise-B 133 : : 134 Auth. : B2BUA or : Auth. 135 Endpoint-A Service : SBC : Service Endpoint-B 136 | | : | : | | 137 1. |--INVITE->| : | : | | 138 2. | sign : | : | | 139 3. | |-INVITE-->|-INVITE-->| | 140 4. | | : | : validate | 141 5. | | : | : |-------->| 142 6. |<============= DTLS =====================>| 143 7. | | : | : | validated 144 8. | | : | : | ring phone 145 | | : | : | | 146 : : 148 Figure 1: Message Flow 150 Step 1: Originating endpoint prepares to send an INVITE and chooses 151 the identity-challenge technique it supports, and indicates 152 that in the SDP it generates. Described in this document 153 are identity challenges for DTLS. It then sends the INVITE 154 to its local SIP proxy. 156 Step 2: Originating endpoint's authentication service creates a new 157 header, Identity-Media, containing certain attribute names 158 from the SDP (e.g., "a=fingerprint", "a=ice-pub-key"). The 159 authentication service then creates a signature over certain 160 SIP headers (e.g., From, To) and this new Identity-Media 161 header. The resulting signature is inserted into the new 162 Identity-Media-Signature header. An Identity-Info header is 163 added, pointing to this domain's certificate. The INVITE, 164 with these additional headers, is forwarded to the next 165 administrative domain. 166 [NOTE: alternatively, we could allow the UAC to create the 167 Identity-Media header with the attributes it wants signed, 168 then have the authentication server sign them and insert the 169 signature header - this would be more flexible] 171 Step 3: The next administrative domain has an SBC (or B2BUA). The 172 SBC modifies or rewrites certain SDP fields. Most typically 173 an SBC will modify the "m" and "c" lines. These 174 modifications do not break the signature, so long as the SBC 175 doesn't remove the headers Identity-Media, Identity-Media- 176 Signature, or Identity-Info, and do not remove or alter the 177 signed attributes from the SDP. 179 Step 4: The terminating endpoint's authentication service receives 180 the INVITE. It validates that the signature contained in 181 the Identity-Media-Signature header, and validates that the 182 signing certificate is owned by the originating domain from 183 step 2. This validation is done by using the certificate 184 pointed to in the Identity-Info header, which MUST match the 185 domain in the From: address. 187 Step 5: If the validation was successful, the terminating endpoint's 188 authentication service forwards the INVITE to the endpoint. 190 Step 6: The terminating endpoint chooses a compatible identity- 191 challenge technique from the INVITE (TLS or DTLS-SRTP) and 192 performs that challenge. Described in this document are 193 identity challenges for TLS and DTLS-SRTP. 195 Step 7: The TLS and DTLS-SRTP identity challenges cause the exchange 196 of a certificate on the media path. The terminating 197 endpoint compares the certificate or public key with the 198 fingerprint in the (signed) Identity-Media header 199 (originally created in step 2). If they match, the 200 terminating endpoint completes the identity challenge 201 exchange. After completion, the originating endpoint has 202 proven (to the terminating endpoint) that the originating 203 endpoint knows the private key associated with the 204 certificate (or public key) signed in step 2. The 205 terminating endpoint has now validated the identity of the 206 originating endpoint. 208 Step 8: The terminating endpoint can reliably and honestly indicate 209 calling party information ("caller-id") and ring the phone. 211 3.1. Identity Media Signature 213 In RFC4474, a signature is formed over some SIP headers and over the 214 entire body (which most typically contains SDP). In this 215 specification, some SIP headers are signed but only specific SDP 216 attributes that provide cryptographic identity are signed (e.g., 217 "a=fingerprint" and its value). The specific SDP attributes that are 218 signed depends on which cryptographic identity technique(s) is used; 219 see section Section 4. 221 The SIP headers that are signed, for the signature placed into the 222 Identity-Media-Signature header are: 224 o The AoR of the UA sending the message, or addr-spec of the From 225 header field (referred to occasionally here as the 'identity 226 field'). 228 o The addr-spec component of the To header field, which is the AoR 229 to which the request is being sent. 231 o The SIP method. 233 o [NOTE: Contact, CSeq and Call-Id not included] 235 o The Date header field, with exactly one space each for each SP and 236 the weekday and month items case set as shown in the BNF in 237 RFC3261. RFC3261 specifies that the BNF for weekday and month is 238 a choice amongst a set of tokens. The RFC2234 rules for the BNF 239 specify that tokens are case sensitive. However, when used to 240 construct the canonical string defined here, the first letter of 241 each week and month MUST be capitalized, and the remaining two 242 letters must be lowercase. This matches the capitalization 243 provided in the definition of each token. All requests that use 244 the Identity-Media mechanism MUST contain a Date header. 246 o The Identity-Media header field value. 248 The hash is formed of these elements: 250 digest-string = addr-spec "|" addr-spec "|" 251 Method "|" SIP-date "|" 252 attrib-bodyhash-list 254 The first addr-spec MUST be taken from the From header field value, 255 the second addr-spec MUST be taken from the To header field value. 257 The Identity-Info header points to where the authentication service's 258 certificate can be retrieved from. 260 3.2. Authentication Service 262 The authentication service examines the SIP message body to build the 263 Identity-Media header. For each message body found, in the order 264 found: 266 o if the body part is application/sdp, the authentication service 267 retrieves only the cryptographic attributes from the SDP (as 268 described in Section 4), and appends that information to the 269 Identity-Media header. 271 o otherwise, for all other body parts, the body part is hashed using 272 SHA-1, and the first 96 bytes are appended to the Identity-Media 273 header using "BPH=". 275 For example, A SIP request with three bodyparts: text/plain, 276 application/sdp, and image/jpg, the Identity-Media attribute would 277 contain a bodypart hash of the text/plain part, certain SDP attribute 278 lines from the application/sdp bodypart (a=fingerprint in this 279 example), and a bodypart hash of the image/jpg bodypart: 281 Identity-Media: BPH="e32je3j23cjek3dz","a=fingerprint", 282 BPH="8fj289r3i892381c" 284 This Identity-Media header, along with the headers and portions of 285 headers described in Section 3.1 are all signed by the authentication 286 service. The resulting signature is placed on the new Identity- 287 Media-Signature header. 289 3.3. Validation 291 The validation service can be performed by the remote endpoint itself 292 or by a device acting on behalf of the endpoint. The validation 293 service first checks the signature in the Identity-Media-Signature 294 field. If this is valid, the endpoint (or its validation service 295 operating on its behalf) then initiates a TLS or DTLS-SRTP identity 296 proof (Section 4). This causes the originating endpoint to prove 297 possession of its private key that corresponds to the certificate 298 that was signed by the remote domain's authentication service. 300 4. Proof of Identity Techniques 302 Two technique is described below -- TLS and DTLS-SRTP. Previous 303 versions of this document had described other techniques (ICE, HIP, 304 and ZRTP). Both TLS and DTLS-SRTP cryptographically prove the 305 identity signed by the authentication service in SIP is the same as 306 the identity on the media path. 308 The authentication service creates a new Identity-Media header and 309 places into that header those SDP attribute names associated with 310 that technique. The authentication service then creates a signature 311 over specific SIP headers (see Section 3.1), and places that 312 signature into the new Identity-Media-Signature header. The SIP 313 request is then sent outside of the originating domain. 315 The receiving domain validates the Identity-Media-Signature. If 316 successful, the SIP request is forwarded to the end system. The end 317 system initiates a DTLS session and validates that the (signed) 318 certificate fingerprint presented in the SIP signaling matches the 319 certificate presented in the DTLS exchange. If they match, and the 320 DTLS exchange completes successfully, the local endpoint has 321 validated the identity of the remote endpoint. 323 Note: Due to SIP forking, the calling party may receive many 324 identity challenges, each incurring a public key operation to prove 325 identity. Mechanisms to deal with this are for future study. 327 4.1. TLS 329 TLS uses the "fingerprint" attribute to provide a hash of the 330 certificate in the SDP. The fingerprint attribute is defined by 331 [RFC4572] for TLS. This a=fingerprint line is included in the 332 Identity-Media SDP attribute. 334 4.2. DTLS-SRTP 336 DTLS uses the same "fingerprint" attribute originally described for 337 TLS, and handled identically to TLS. 339 5. ABNF 341 The following figure shows the syntax of the new SIP header fields 342 using ABNF [RFC5234] 344 identity-media = "Identity-Media" HCOLON 345 attrib-bodyhash-list 346 attrib-bodyhash-list = attrib-bodyhash *(COMMA attrib-bodyhash) 347 attrib-bodyhash = quoted-attrib | quoted-bodyparthash 348 quoted-attribute = DQUOTE attribute DQUOTE ; SDP "a=" line 349 quoted-bodyhash = "BPH" EQUAL DQUOTE bodyparthash DQUOTE 350 bodyparthash = 32HEXDIG 352 identity-media-sig = "Identity-Media-Signature" HCOLON 353 signature 354 signature = DQUOT 32HEXDIG DQUOT 356 Identity-Info = "Identity-Info" HCOLON ident-info 357 *( SEMI ident-info-params ) 358 ident-info = LAQUOT absoluteURI RAQUOT 359 ident-info-params = ident-info-alg / ident-info-extension 360 ident-info-alg = "alg" EQUAL token 361 ident-info-extension = generic-param 363 Figure 2: ABNF for new SIP headers 365 6. Security Considerations 367 [[some of RFC4474's security considerations also apply.]] 369 6.1. Device Disclosure 371 Although the mechanism described in this paper allows SBCs to be used 372 with a cryptographic identity scheme, it does expose the identity of 373 the user's certificate -- which is exposed by DTLS-SRTP itself. If a 374 unique certificate is installed on each user's device, the remote 375 party will be able to discern which device is terminating the call. 376 This problem is more pronounced when SIP retargeting occurs in 377 conjunction with Connected Identity [RFC4916]. 379 If this isn't desired, there are two solutions: 381 o All devices under the control of the user will need to have the 382 same certificate (and associated private key) installed on them. 384 o The device needs to manufacture a new self-signed certificate (or 385 public key) for each call, and populate the appropriate SDP 386 attributes with that certificate (or public key). This is 387 possible because the identity service described in this paper does 388 not require the same certificate or public key to be used on every 389 call. 391 6.2. Modification of SDP 393 One issue with only signing specific SDP attributes is that a man in 394 the middle can modify the un-signed SDP for nefarious purposes, 395 beyond simply changing m=/c= lines. In particular, an attacker could 396 set the c= connection line used for DTLS-SRTP fingerprint to 0.0.0.0 397 and the m= media line to port 0, essentially disabling that offered 398 media session. The attacker could also add a set of c=/m= lines for 399 non-SRTP media, and thus make a non-SRTP offer with a perfectly valid 400 identity signature. Or an attacker could insert SDP capability 401 negotiation attributes to create a best-effort type SRTP offer, with 402 SRTP (rather than RTP) being the lowest preference. 404 This draft prevents such downgrade attacks by requiring the called UA 405 use DTLS-SRTP, HIP, ICE, or TLS on the media path to establish 406 identity. Thus, an attacker performing the attacks described above 407 will not successfully fool the called UA because the (intended) 408 victim will use DTLS-SRTP (or HIP, ICE, or TLS) on the media path, 409 and the attacker does not possess the private key of the legitimate 410 caller. 412 7. Operational Differences from RFC4474 414 RFC4474 imposes one public key operation for the authentication 415 service and one for validation. If Connected Identity [RFC4916] is 416 used, only one additional public key operation is necessary for the 417 header signature validation; the expense of the DTLS, TLS, or ICE 418 public key operation has already been incurred by both parties and is 419 not repeated. 421 RFC4474 includes the Contact URI in the signed headers. That is not 422 required by this mechanism because it adds no security property, and 423 will fail validation when crossing SBCs and B2BUA's. It is of 424 dubious security value because Via/Record-Route can be inserted for 425 response interception regardless, and some requests don't contain a 426 Contact anyway (e.g., MESSAGE). It does not provide any replay/ 427 copy-paste protection either, for the same reasons. 429 RFC4474 includes the CSeq in the signed headers. That is not 430 required by this mechanism because it adds little security, and will 431 fail validation when crossing SBCs and B2BUA's in some cases. It is 432 of little security value because it provides no protection from cut- 433 paste attack for different targets, and although it would prevent 434 replay attack within the same session, since the media key-related 435 SDP portions are signed anyway, replaying the request will not do 436 anything useful. 438 RFC4474 includes the Call-Id in the signed headers. That is not 439 required by this mechanism because it adds little security, and will 440 fail validation when crossing SBCs and B2BUA's in some cases. It is 441 of little security value because it provides no protection from cut- 442 paste attack for different targets, and although it would prevent 443 replay attack for the same target, since the media key-related SDP 444 portions are signed anyway, replaying the request will not do 445 anything useful. 447 The mechanism described in this document has the following advantages 448 over RFC4474: 450 o Only the edge network needs to create signatures on SIP requests 451 -- not every intervening SBC, 453 o The original cryptographically-provable identity is preserved 454 across any number of SBCs, B2BUA's, etc. 456 o SBCs, B2BUA's, and other "middle-boxes" in intermediate domains do 457 not need to be upgraded or changed in order for the originating 458 and terminating domains to use this new mechanism. 460 8. Limitations 462 For the identity procedure described in this document to function, 463 every device -- including Session Border Controllers -- on the path 464 MUST permit DTLS-SRTP on the media path. Further, those devices MUST 465 NOT interfere with the signed SDP attributes or the new SIP headers 466 necessary for Identity Media to operate. 468 For the technique described in this document to function, all on-path 469 SIP elements -- SBCs, B2BUAs, and SIP proxies -- MUST NOT interfere 470 with the signed headers. The identity mechanism described in this 471 document is not harmed if on-path SIP elements alter the SDP (e.g., 472 by deleting non-signed attributes, connection addresses, etc.). 474 9. Examples 475 9.1. DTLS 477 This example shows how two a=fingerprint lines in SDP would populate 478 the Identity-Media SIP header field. The following is an example of 479 an INVITE created by the endpoint. 481 (lines folded for readability) 483 INVITE sip:bob@biloxi.example.org SIP/2.0 484 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8 485 To: Bob 486 From: Alice ;tag=1928301774 487 Call-ID: a84b4c76e66710 488 CSeq: 314159 INVITE 489 Max-Forwards: 70 490 Date: Thu, 21 Feb 2002 13:02:03 GMT 491 Contact: 492 Content-Type: application/sdp 493 Content-Length: 147 495 v=0 496 o=- 6418913922105372816 2105372818 IN IP4 192.0.2.1 497 s=example2 498 c=IN IP4 192.0.2.1 499 t=0 0 500 m=audio 54113 RTP/SAVP 0 501 a=fingerprint:SHA-1 502 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 503 m=video 54115 RTP/SAVP 0 504 a=fingerprint:SHA-1 505 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB 507 Figure 3: Example with DTLS 509 The SIP proxy performing the Media Identity authentication service 510 would then insert the following three SIP headers into the message. 511 The Identity-Media header contains all of the SDP attribute lines 512 that are signed and the Identity-Media header contains the signature 513 of all of the relevant SIP headers and of the Identity-Media header. 514 Lines are folded for readability: 516 Identity-Info: 517 ;alg=rsa-sha1 518 Identity-Media: "a=fingerprint","a=fingerprint" 519 Identity-Media-Signature: 520 "ZYNBbHC00VMZr2kZt6VmCvPonWJMGvQTBDqghoWeLxJfzB2a1pxAr3VgrB0SsSAa 521 ifsRdiOPoQZYOy2wrVghuhcsMbHWUSFxI6p6q5TOQXHMmz6uEo3svJsSH49thyGn 522 FVcnyaZ++yRlBYYQTLqWzJ+KVhPKbfU/pryhVn9Yc6U=" 523 Figure 4: SIP Headers Inserted by Authentication Service 525 10. Acknowledgements 527 The mechanism described in this paper is derived from Jon Peterson 528 and Cullen Jennings' [RFC4474], which was formerly a document of the 529 SIP working group. 531 Thanks to Hans Persson for his suggestions which improved this 532 document. 534 11. IANA Considerations 536 [[This section will be completed in a later version of this 537 document.]] 539 12. Normative References 541 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 542 Requirement Levels", BCP 14, RFC 2119, March 1997. 544 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 545 Authenticated Identity Management in the Session 546 Initiation Protocol (SIP)", RFC 4474, August 2006. 548 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 549 Specifications: ABNF", STD 68, RFC 5234, January 2008. 551 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 552 Protocol (SIP)", RFC 4916, June 2007. 554 [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the 555 Transport Layer Security (TLS) Protocol in the Session 556 Description Protocol (SDP)", RFC 4572, July 2006. 558 Authors' Addresses 560 Dan Wing 561 Cisco Systems, Inc. 562 170 West Tasman Drive 563 San Jose, CA 95134 564 USA 566 Email: dwing@cisco.com 568 Hadriel Kaplan 569 Acme Packet 570 71 Third Ave. 571 Burlington, MA 01803 572 USA 574 Phone: 575 Fax: 576 Email: hkaplan@acmepacket.com 577 URI: