idnits 2.17.00 (12 Aug 2021) /tmp/idnits65070/draft-schwartz-sip-e164-ownership-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 626. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 633. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 639. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 390: '... The verifier MUST follow the proce...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2008) is 5192 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '3' is defined on line 513, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 520, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 554, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4474 (ref. '2') (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 4871 (ref. '3') (Obsoleted by RFC 6376) ** Obsolete normative reference: RFC 3761 (ref. '5') (Obsoleted by RFC 6116, RFC 6117) == Outdated reference: A later version (-01) exists of draft-elwell-sip-e164-problem-statement-00 == Outdated reference: A later version (-08) exists of draft-ietf-sip-saml-03 -- Obsolete informational reference (is this intentional?): RFC 2459 (ref. '11') (Obsoleted by RFC 3280) Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP D. Schwartz 3 Internet-Draft XConnect 4 Intended status: Informational H. Kaplan 5 Expires: August 28, 2008 Acme Packet 6 K. Darilion 7 enum.at 8 H. Tschofenig 9 Nokia Siemens Networks 10 February 25, 2008 12 E.164 Ownership Problem Statement 13 draft-schwartz-sip-e164-ownership-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 28, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 When a call travels end-to-end relayed from the PSTN to SIP then 47 problems occur with E.164 number ownership. Additionally, there are 48 security challenges when the PSTN-VoIP gateway has to authenticate 49 and authorize the calling party. Without addressing these two 50 aspects the overall security story is weak or non-existent. This 51 document aims to investigate these two aspect; it does, however, not 52 investigate current E.164 number handling with RFC 4474 ("SIP 53 Identity"). Such an analysis is provided by other documents already. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. The End-to-End Picture . . . . . . . . . . . . . . . . . . . . 3 62 3.1. IP-IP Case . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3.2. IP-PSTN-IP Case . . . . . . . . . . . . . . . . . . . . . 5 64 3.3. PSTN-to-IP Case . . . . . . . . . . . . . . . . . . . . . 5 65 3.4. IP-to-PSTN Case . . . . . . . . . . . . . . . . . . . . . 6 67 4. Authenticating and Authorizing the Calling Party Identity . . 7 69 5. Verifying Ownership: What does it mean? . . . . . . . . . . . 8 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 73 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 84 Intellectual Property and Copyright Statements . . . . . . . . . . 15 86 1. Introduction 88 RFC 4474 [2] defines a mechanism whereby an authentication service 89 asserts the identity of a SIP UAC and determines whether he or she is 90 authorized to use that identity. The authentication service then 91 computes a hash over some particular headers, including the From 92 header field and the bodies in the message. This hash is signed with 93 the certificate for the domain and inserted in the 'Identity' header 94 field in the SIP message. The proxy also inserts a companion header 95 field, Identity-Info, that tells the verifying party how to acquire 96 its certificate, in case it is not yet known already. 98 When the verifier receives the SIP message, it verifies the signature 99 provided in the Identity header, and thus can determine whether the 100 domain indicated by the host portion of the AoR in the From header 101 field authenticated the user, and permitted the user to assert that 102 From header field value. 104 The use of phone numbers with SIP was introduced with the TEL URL 105 scheme [4] whereby domain names were not used with the phone numbers. 106 SIP URIs always have domain names. In SIP [1], a translation between 107 SIP URIs and TEL URLs is described: when translating from a SIP URI 108 to a TEL URL, the domain name from the SIP URI is simply dropped. 109 When translating in the other direction (or simply generating a SIP 110 URI from an E.164 number [13]) it is not clear how to populate the 111 domain name. 113 When SIP Identity [2] is applied to E.164 numbers then there is the 114 question what the identity assertion actually means. Additionally, 115 the usage of the domain for an E.164 number causes problems, as 116 described in [6]. This document will, however, not focus on this 117 aspect. Instead, we investigate the overall end-to-end security 118 story and the ownership problem for E.164 numbers. 120 2. Terminology 122 This document largely relies on the terminology introduced by [2]. 124 3. The End-to-End Picture 126 In the context of "ownership" it is hard to speak of the end-to-end 127 picture without first identifying four possible use-cases for this 128 e2e communication. The first two start AND end on IP and the second 129 two start OR end on IP. Please refer to Figure 1 below for the first 130 two cases. 132 -------- 133 //// \\\\ 134 +------------+ | PSTN |------------+ 135 | IP-based | | | | 136 | SIP Phone |<--+ \\\\ //// +------------+ 137 | of Bob | | -------- | PSTN-based | 138 |+19175551234| | ^ | | Phone | 139 +------------+ | | | | of Carl | 140 | | | |+15167654321| 141 +------------+ | | | +------------+ 142 | IP-based | | | | 143 | SIP Phone | ------------ | | +------------+ 144 | of Alice | / \ | | | IP-based | 145 |+12121234567| // Federation \\ | | | Phone | 146 +------------+ // \\\ | v | of Dan | 147 | /// - - - - - - - - ----- |+12039994321| 148 | //// \\\\ +------------+ 149 | / \ ^ 150 | | | | 151 +---->| IP-based |------+ 152 | Network | 153 \ / 154 \\\\ //// 155 ------------------------- 157 Figure 1: Federation based IP-to-IP Communication 159 3.1. IP-IP Case 161 The first use case is that of a call that originates and terminates 162 on the IP network without ever touching the PSTN but that uses E.164 163 addressing instead of the preferred URI. This case is quite 164 prevalent today in some of the private peering federations. These 165 federations are seen as a first choice (if I can terminate to an IP 166 great - otherwise let me know and I will failover or route advance to 167 the PSTN) for outbound routing of E.164 numbers. Since these 168 federations are being used in conjunction with the PSTN it is quite 169 logical that the addressing will be E.164 and not SIP URI based. 171 As can be seen in Figure 1 if Alice calls Bob the call will be IP 172 based end-to-end while if she calls Carl it will exit to the PSTN. 173 Ownership, therefore needs to be considered in the context of this 174 use-case. Does the COR play any role in this case? Can these 175 numbers be treated as private plan numbers placing all onus solely on 176 the respective VSPs servicing Alice and Bob? 178 3.2. IP-PSTN-IP Case 180 In this case Dan's VSP is not a member of the federation that is 181 shared by Alice and Bob and as such so far as Alice is concerned Dan 182 is not accessible via IP. 184 What considerations should be discussed in this case? In reality 185 both origination and termination are IP, however, the transit is PSTN 186 and who know what happens in that world. What is the notion of 187 ownership here? Since any "domain" information will be stripped by 188 the PSTN is there any advantage whatsoever to including it? 190 3.3. PSTN-to-IP Case 192 Consider Figure 2 where Carl is using a PSTN phone and initiates 193 calls to Alice. Alice is using an IP-based phone. The call of Carl 194 traverses the PSTN and enters the Internet via some PSTN/VoIP 195 gateway. This gateway applies SIP Identity to the call. What does 196 the signed identity mean? Can the gateway in typical deployment 197 cases verify the caller id in any meaningful way? Later, when 198 Alice's SIP UA receives the call it may run some authorization 199 procedure against the received identity. It may "outsource" the 200 decision to the user by just displaying anything received. Unless 201 the calling domain itself operates the gateway it is less likely that 202 the domain part that may have been added to the E.164 number contains 203 information that can be associated meaningfully with the calling 204 party. For example, a bank might use the PSTN within their branches 205 and operate their own gateway to the IP-based network and hence the 206 domain part of the identity could in fact indicate, for example, 207 mybank-example.com. If this gate is operated by an entirely 208 different entity then the domain might show something like 209 gateway.operator-example.com. Without a binding between the E.164 210 number and the domain of the authentication service attacks are 211 possible. 213 -------- 214 //// \\\\ 215 +->| PSTN |--+ 216 | | | | 217 | \\\\ //// | 218 | -------- | 219 | | 220 | v 221 | +----+-------+ 222 +---+------+ |PSTN / VoIP | +-----+ 223 |PSTN Phone| |Gateway | |SIP | 224 |of Carl | +----+-------+ |UA | 225 +----------+ | |Alice| 226 Invite +-----+ 227 | ^ 228 V | 229 +-------------+ Invite 230 |VoIP | | 231 |Service | Invite +-------+ 232 |Provider(s) |----------->+ | 233 +-------------+ | | 234 |Verif. | 235 |Service| 236 | | 237 +-------+ 238 |---------| 239 called 240 party 241 domain 243 Figure 2: PSTN-to-IP Communication 245 3.4. IP-to-PSTN Case 247 Consider Figure 3 where Alice calls Carl. Carl uses a PSTN phone and 248 Alice an IP-based phone. When Alice initiates the call the E.164 249 number needs to get translated, for example using ENUM, to a SIP URI 250 and subsequently to an IP address. The call of Alice traverses her 251 VoIP provider where the SIP Identity signature is added. It then 252 hits the PSTN/VoIP gateway. What would the gateway do with the SIP 253 Identity header? Can he do anything meaningful with it? Ideally, 254 Alice would like to know whether she, for example, talks to someone 255 at her bank rather than to someone intercepting the call. Would 256 Connected Identity help her? What would the quality of the 257 subsequently established media security between the gateway and 258 Alice's SIP UA be? 259 +-------+ +-----+ -C 260 |PSTN | |SIP | |a 261 |Phone |<----------------+ |UA | |l 262 |of Carl| | |Alice| |l 263 +-------+ | +-----+ |i 264 --------------------------- | |n 265 //// \\\\ | |g 266 | PSTN | Invite | 267 | | | |P 268 \\\\ //// | |a 269 --------------------------- | |r 270 ^ | |t 271 | v |y 272 +------------+ +--------+| 273 |PSTN / VoIP |<--Invite----|VoIP ||D 274 |Gateway | |Service ||o 275 +------------+ |Provider||m 276 | Y ||a 277 +--------+|i 278 -n 280 Figure 3: IP-to-PSTN Communication 282 4. Authenticating and Authorizing the Calling Party Identity 284 RFC 4474 rightfully makes some important assumptions about the 285 behavior of the authentication service that contribute significantly 286 to the security of the overall system. While some assumptions seem 287 to be obvious for SIP usage, they are less obvious when considering 288 them in relationship with a PSTN interworking or E.164 number usage. 289 Section 4 of [2] says: 291 "The authentication service authenticates Alice (possibly by 292 sending a Digest authentication challenge) and validates that she 293 is authorized to assert the identity that is populated in the From 294 header field. This value may be Alice's AoR, or it may be some 295 other value that the policy of the proxy server permits her to 296 use. 298 ... 300 The proxy, as the holder of the private key of its domain, is 301 asserting that the originator of this request has been 302 authenticated and that she is authorized to claim the identity 303 (the SIP address- of-record) that appears in the From header 304 field. " 306 The crutial question therefore is: In the generic case is the 307 authentication service able to authenticate the caller-ID used in the 308 PSTN and to authorize it's usage? 310 There are problems with this step: 312 1. The PSTN builds on a walled garden with a chain-of-trust security 313 model. This is "nice" as long as the participating parties are 314 indeed honest. Unfortunately, this is not true anymore (and has 315 not been the case for a long time already) [add-references]. 316 Caller-ID spoofing is common and even transit providers are not 317 trustworthy either. 318 2. A call originated on the PSTN is often times routed to a PSTN/ 319 VoIP gateway. That PSTN gateway is operated by the owner of the 320 called number, rather than the owner of the calling number. 322 5. Verifying Ownership: What does it mean? 324 Imagine a verification service at Alice's VoIP provider network 325 receives a SIP message with an 'Identity' and an 'Identity-Info' 326 header. 328 When the username and the domain name are tightly bound together then 329 there is no question whether a particular authentication service 330 operating at a specific domain is administratively reponsible for a 331 specific username part. However, if this binding is relaxed or even 332 removed then there is a question of which authentication service is 333 allowed to warrant for which usernames. 335 Ownership is an artificial construct but one could compare it with an 336 oracle that returns the name of a domain when asked who is 337 authoritative for using a particular E.164 number. 339 The problem is compounded by the fact that there may be more than one 340 legitimate owner. Consider if you will the case where an enterprise 341 (PBX) uses a Voice Service Provider (VSP) for IP communication 342 services and the VSP acquires E.164 numbers from an exchange who in 343 turn acquires the numbers from the Carrier of Record (COR). This is 344 illustrated in Figure 4. 346 +-----------------------------------+ 347 | COR | 348 | +-----------------------------+ | 349 | | E.164 Exchnage | | 350 | | +---------------------+ | | 351 | | | VSP | | | 352 | | | +-----------+ | | | 353 | | | | PBX | | | | 354 | | | +-----------+ | | | 355 | | | | | | 356 | | +---------------------+ | | 357 | | | | 358 | +-----------------------------+ | 359 | | 360 +-----------------------------------+ 362 Figure 4: Will the real 'Owner' please stand up? 364 If one was to compare this to the path validation approach used in 365 chain-of-trust certificate validation schemes, the COR would be the 366 trust anchor and would sign the exchange cert who in turn would sign 367 the VSP cert who in turn would sign the PBX cert which would be used 368 in 4474 [2]. While the steps needed to traverse up the chain and 369 check all the certs are seemingly quite expensive (performance wise 370 for calls at least) one must realize that calling patterns are quite 371 determanistic and as such caching is believed to alleviate this issue 372 and make it tolerable. Without this chain-of-trust approach it is 373 hard to give credibility to any "ownership" assertion. 375 Looking at "ownership" in this way may necessitate an Authority 376 Information Access (AIA) [11] equivalent so that a URI scoping an 377 E.164 number would provide the pointer back up the tree for complete 378 validation. If the number is ported from one COR to another all that 379 would be needed is to modify the AIA information starting with the 380 anchor and down to where relevant. 382 There are various owership verification steps that got used in the 383 IETF within other protocols. RFC 4474 [2], for example, uses the 384 following verification step for SIP URIs: 386 "6. Verifier Behavior 388 Step 2: 390 The verifier MUST follow the process described in Section 13.4 to 391 determine if the signer is authoritative for the URI in the From 392 header field. 394 13.4. Domain Names and Subordination 396 When a verifier processes a request containing an Identity-Info 397 header, it must compare the domain portion of the URI in the From 398 header field of the request with the domain name that is the 399 subject of the certificate acquired from the Identity-Info 400 header." 402 This is a concept of referential integrity where information of the 403 protocol (in this case the identity) is matched against information 404 from the certificate. The signer and the verifier need to have a 405 trust anchor in common. There are additional aspects about the 406 detailed matching procedure that are described in Section 13.4 of 407 [2]. 409 Unfortunately, this simple authorization check cannot be used with 410 E.164 numbers because of the missing domain concept in the identifier 411 itself and because of number portability. Imagine if the SIP 412 Identity authentication service would have to sign calling parties 413 SIP URIs that do not belong to the domain the authentication service 414 is responsible for. The corresponding verification check would be 415 far more complicated -- the authentication service would have to show 416 that it is indeed entitled to act on behalf of someone else. 418 A couple of other ownership approaches have been used in IETF 419 protocols. These examples are not meant to claim that the problem is 420 easy to solve (in the style of just pick one) or that there is even a 421 satisfactory solution at all. They are just listed to illustrate the 422 different flavors and the quality of the warrants: 424 Return Routability Check: A form of check is to exploit the 425 topological properties of identifier routing and the possible 426 placements of adversaries with respect to a certain message 427 interaction. RRT and various other forms fall into that category. 428 An example can be found in [8]. 430 Authorization Certificates: 432 A form of check is to use authorization certificates. The basic 433 idea is that one would trust the entity that creates the 434 authorization certificate (most likely in a hierarchical form) 435 then you also trust its content. SIP-SAML (see [7]) and [12] 436 belong to this category. When the identity of the certificate is 437 constructed in a suitable way then together with a delegated 438 signing the same effect could be accomplished. 440 Distributed Databases: 442 Another form of mechanism is to use an out-of-band database 443 lookup, for example using the DNS, in order to verify that the 444 entity which uses the private key for creating the SIP Identity 445 header is authorized to attach the corresponding public key to the 446 this distributed database. The identity would be used for the 447 lookup to the database and the security of the system relies on 448 ensuring that only those entities add the public key that are also 449 owner of the corresponding E.164 number. An example of such an 450 approach can be found in [15]. The usage of TRIP [10] (with 451 extensions with information about E.164 numbers that are 452 authorized for usage by a specific provider) has been discussed as 453 well. 455 Cryptographic Addresses and Hash Chains: 457 These mechanisms utilize a temporal property by creating a binding 458 between the public key (or values from a hash chain) and the 459 identity be verified by re-computing the hash value and by 460 comparing the hash with the identifier. These mechanisms have 461 found some excitment with protocol work at lower layers (see, for 462 example, [9]). 464 Needless to say that each mechanism has different scalability, 465 security and deployment properties. 467 6. Security Considerations 469 With the work on this subject it is important to keep two quotes in 470 mind: 472 o "The security of a system is as good as the weakest link." 473 o "If you think cryptography is the solution to your problem, you 474 don't know what your problem is." --- Roger Needham 476 The authors argue that the problem scope and the envisioned technical 477 properties are not yet understood enough. Furthermore, it is 478 necessary to investigate deployment challenges imposed by the 479 existing infrastructure and deployment incentives for various 480 approaches. 482 7. Contributors 484 We would like to thank the following individuals for their 485 contributions to this document: 487 o Dan Wing 488 o John Elwell 489 o Kai Fischer 491 8. IANA Considerations 493 There are no IANA considerations with this document. 495 9. Acknowledgments 497 We would like to thank Joel M. Halpern, Paul Kyzivat, Dale Worley, 498 Jonathan Rosenberg, and Henry Sinnreich for their feedback on the 499 mailing list. 501 10. References 503 10.1. Normative References 505 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 506 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 507 Session Initiation Protocol", RFC 3261, June 2002. 509 [2] Peterson, J. and C. Jennings, "Enhancements for Authenticated 510 Identity Management in the Session Initiation Protocol (SIP)", 511 RFC 4474, August 2006. 513 [3] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and 514 M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", 515 RFC 4871, May 2007. 517 [4] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 518 December 2004. 520 [5] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource 521 Identifiers (URI) Dynamic Delegation Discovery System (DDDS) 522 Application (ENUM)", RFC 3761, April 2004. 524 10.2. Informative References 526 [6] Elwell, J., "SIP E.164 Problem Statement", 527 draft-elwell-sip-e164-problem-statement-00 (work in progress), 528 February 2008. 530 [7] Tschofenig, H., Hodges, J., Peterson, J., Polk, J., and D. 531 Sicker, "SIP SAML Profile and Binding", draft-ietf-sip-saml-03 532 (work in progress), November 2007. 534 [8] Wing, D., "SIP E.164 Return Routability Check (RRC)", 535 draft-wing-sip-e164-rrc-01 (work in progress), February 2008. 537 [9] Aura, T., "Cryptographically Generated Addresses (CGA)", 538 RFC 3972, March 2005. 540 [10] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing 541 over IP (TRIP)", RFC 3219, January 2002. 543 [11] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet X.509 544 Public Key Infrastructure Certificate and CRL Profile", 545 RFC 2459, January 1999. 547 [12] Bellovin, S., Ioannidis, J., Keromytis, A., and R. Stewart, "On 548 the Use of Stream Control Transmission Protocol (SCTP) with 549 IPsec", RFC 3554, July 2003. 551 [13] ITU-T, "The international public telecommunication numbering 552 plan", Recommendation E.164, May 1997. 554 [14] Peterson, J., "A Privacy Mechanism for the Session Initiation 555 Protocol (SIP)", RFC 3323, November 2002. 557 [15] Darilion, K. and H. Tschofenig, "E.164 Ownership using Public 558 Keys stored in ENUM", draft-darilion-sip-e164-enum-00 (work in 559 progress), February 2008. 561 Authors' Addresses 563 David Schwartz 564 XConnect 565 Malcha Technology Park 566 Jerusalem, 96951 567 Israel 569 Email: dschwartz@xconnect.net 570 Hadriel Kaplan 571 Acme Packet 572 71 Third Ave. 573 Burlington, MA 01803 574 USA 576 Phone: 577 Fax: 578 Email: hkaplan@acmepacket.com 579 URI: 581 Klaus Darilion 582 enum.at GmbH 583 Karlsplatz 1/9 584 Wien A-1010 585 Austria 587 Phone: +43 1 5056416 36 588 Email: klaus.darilion@enum.at 589 URI: http://www.enum.at/ 591 Hannes Tschofenig 592 Nokia Siemens Networks 593 Linnoitustie 6 594 Espoo 02600 595 Finland 597 Phone: +358 (50) 4871445 598 Email: Hannes.Tschofenig@nsn.com 599 URI: http://www.tschofenig.com 601 Full Copyright Statement 603 Copyright (C) The IETF Trust (2008). 605 This document is subject to the rights, licenses and restrictions 606 contained in BCP 78, and except as set forth therein, the authors 607 retain all their rights. 609 This document and the information contained herein are provided on an 610 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 611 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 612 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 613 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 614 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 615 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 617 Intellectual Property 619 The IETF takes no position regarding the validity or scope of any 620 Intellectual Property Rights or other rights that might be claimed to 621 pertain to the implementation or use of the technology described in 622 this document or the extent to which any license under such rights 623 might or might not be available; nor does it represent that it has 624 made any independent effort to identify any such rights. Information 625 on the procedures with respect to rights in RFC documents can be 626 found in BCP 78 and BCP 79. 628 Copies of IPR disclosures made to the IETF Secretariat and any 629 assurances of licenses to be made available, or the result of an 630 attempt made to obtain a general license or permission for the use of 631 such proprietary rights by implementers or users of this 632 specification can be obtained from the IETF on-line IPR repository at 633 http://www.ietf.org/ipr. 635 The IETF invites any interested party to bring to its attention any 636 copyrights, patents or patent applications, or other proprietary 637 rights that may cover technology that may be required to implement 638 this standard. Please address the information to the IETF at 639 ietf-ipr@ietf.org. 641 Acknowledgment 643 Funding for the RFC Editor function is provided by the IETF 644 Administrative Support Activity (IASA).