idnits 2.17.1 draft-ietf-rserpool-threats-04.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 3667, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 522. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 546. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 513), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 4) being 61 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (July 4, 2005) is 6870 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) == Unused Reference: 'Rserarch' is defined on line 484, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 490, but no explicit reference was found in the text == Unused Reference: 'RFC3365' is defined on line 493, but no explicit reference was found in the text -- No information found for draft-ietf-reserpool-arch - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Rserarch' Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Maureen Stillman(editor) 2 INTERNET DRAFT Ram Gopal 3 Senthil Sengodan 4 Nokia 5 Erik Guttman 6 Sun Microsystems 7 Matt Holdrege 8 Strix Systems 9 04 January 2005 10 expires July 4, 2005 12 Threats Introduced by Rserpool and Requirements for Security 13 in response to Threats 14 16 Status of This Memo 18 By submitting this Internet-Draft, I certify that any applicable 19 patent or other IPR claims of which I am aware have been disclosed, 20 and any of which I become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 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 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on July 4, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). All Rights Reserved. 45 Abstract 47 Rserpool is an architecture and set of protocols for the management 48 and access to server pools supporting highly reliable applications 49 and for client access mechanisms to a server pool. This Internet 50 draft describes security threats to the Rserpool architecture and 51 presents requirements for security to thwart these threats. 53 Contents 55 Status of This Memo 1 56 Abstract 1 57 1. Introduction 3 58 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Threats 4 60 2.1 PE Registration/Deregistration flooding . . . . . . . . . 4 61 2.2 PE Registration/Deregistration flooding . . . . . . . . . 4 62 2.3 PE Registration/Deregistration spoofing . . . . . . . . . 4 63 2.4 PE Registration/Deregistration unauthorized . . . . . . . 5 64 2.5 Malicious ENRP server joins the group of legitimate ENRP 65 servers . . . . . . . . . . . . . . . . . 5 66 2.6 Registration/deregistration with malicious ENRP servers . 5 67 2.7 Malicious ENRP Handlespace Resolution . . . . . . . . . . 5 68 2.8 Malicious node performs a replay attack.. . . . . . . . . 6 69 2.9 Re-establishing PU-PE security during failover. . . . . . 6 70 2.10 Integrity . . . . . . . . . . . . . . . . . . . . . . . . 6 71 2.11 Data Confidentiality . . . . . . . . . . . . . . . . . . 6 72 2.12 ENRP Server Discovery . . . . . . . . . . . . . . . . . . 7 73 2.13 Flood of endpoint unreachable messages . . . . . . . . . 7 74 2.14 Flood of endpoint keep alive messages . . . . . . . . . . 7 75 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 76 3.1 Database security . . . . . . . . . . . . . . . . . . . . 10 77 3.2 Cookie security . . . . . . . . . . . . . . . . . . . . . 10 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 11 79 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 81 7. Intellectual Property Statement . . . . . . . . . . . . . . . . 12 82 8. Author's addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 RSERPOOL provides a session layer for robustness. The session layer 86 function may redirect communication transparently to upper layers. This 87 alters the direct one-to-one association between communicating endpoints 88 which typically exists between clients and servers. In particular, 89 secure operation of protocols often relies on assumptions at different 90 layers regarding the identity of the communicating party and the 91 continuity of the communication between endpoints. Further, the 92 operation of RSERPOOL itself has security implications and risks. The 93 session layer operates dynamically which imposes additional concerns for 94 the overall security of the end-to-end application. This document 95 explores the security implications of RSERPOOL, both due to its own 96 functions and due to its being interposed between applications and 97 transport interfaces. 99 1.1 Definitions 101 This document uses the following terms: 103 ENRP Endpoint haNdlespace Redundancy Protocol: 104 Within the operational scope of Rserpool, ENRP defines the 105 procedures and message formats of a distributed fault-tolerant 106 registry service for storing, bookkeeping, retrieving, and 107 distributing pool operation and membership information. 109 ASAP Aggregate Server Access Protocol: 110 A session layer protocol which uses the Endpoint haNdlespace 111 Reduncancy Protocol to provide a high availability 112 handlespace. ASAP is responsible for the abstraction of the 113 underlying transport technologies, load distribution 114 management,fault management, as well as the presentation to 115 the upper layer (i.e., the ASAP user) a unified primitive 116 interface. 118 Operational scope: 119 The part of the network visible to pool users by a specific 120 instance of the reliable server pooling protocols. 122 Pool (or server pool): 123 A collection of servers providing the same application 124 functionality. 126 Pool handle: 127 A logical pointer to a pool. Each server pool will be 128 identifiable in the operational scope of the system by a 129 unique pool handle. 131 ENRP handlespace (or handlespace): 132 A cohesive structure of pool names and relations that may be 133 queried by an internal or external agent. 135 Pool element (PE): 136 A server entity that runs ASAP and has registered to a pool. 138 Pool user (PU): 139 A server pool user that runs ASAP. Note, a PU can also be a 140 PE if it has registered itself to a pool. 142 ENRP handlepace server (or ENRP server): 143 Entity which runs ENRP and is responsible for managing and 144 maintaining the handlespace within the operational scope. 146 2. Threats 148 2.1 PE Registration/Deregistration flooding -- non-existent PE 150 Threat: A malicious node could send a stream of false 151 registrations/deregistrations on behalf of non-existent PEs to ENRP 152 servers at a very rapid rate and thereby create unnecessary state in an 153 ENRP server. 155 Effect: Corrupting the pool registrar database and/or disabling the 156 Rserpool discovery and database function. 158 Requirement: An ENRP server that receives a registration/deregistration 159 should not create or update state information until it has authenticated 160 the PE. 162 2.2 PE Registration/Deregistration flooding -- unauthorized PE 164 Threat: A malicious node or PE could send a stream of 165 registrations/deregistrations that are unauthorized to 166 register/deregister - to ENRP servers at a very rapid rate and thereby 167 create unnecessary state in an ENRP server. 169 Effect: Corrupting the pool registrar database and/or disabling the 170 Rserpool discovery and database function. 172 Requirement: An ENRP server that receives a registration/deregistration 173 should not create or update state information until the authorization of 174 the registering/de-registering entity is verified. 176 2.3 PE Registration/Deregistration spoofing 178 Threat: A malicious node could send false registrations/deregistrations 179 to ENRP servers concerning a legitimate PE thereby creating false state 180 information in the ENRP servers. 182 Effect: Misinformation in the ENRP server concerning a PE would get 183 propagated to other ENRP servers thereby corrupting the ENRP database. 185 Requirement: An ENRP server that receives a registration/deregistration 186 should not create or update state information until it has authenticated 187 the PE. 189 2.4 PE Registration/Deregistration unauthorized 191 Threat: A PE who is not authorized to join a pool could send 192 registrations/deregistrations to ENRP servers thereby creating false 193 state information in the ENRP servers. 195 Effect: Misinformation in the ENRP server concerning a PE would get 196 propagated to other ENRP servers thereby corrupting the ENRP database. 198 Requirement: An ENRP server that receives a registration/deregistration 199 should not create or update state information until it has authorized 200 the requesting entity. 202 2.5 Malicious ENRP server joins the group of legitimate ENRP servers 204 Threat: Malicious ENRP server joins the group of legitimate ENRP servers 205 with the intent of propagating inaccurate updates to corrupt the ENRP 206 database. 208 Effect: Inconsistent ENRP database state. 210 Requirement: Mutual authentication of ENRP servers. 212 2.6 Registration/deregistration with malicious ENRP server 214 Threat: A PE unknowingly registers/deregisters with malicious ENRP 215 server. 217 Effect: Registration might not be properly processed or ignored. 219 Requirement: PE needs to authenticate the ENRP server. 221 2.7 Malicious ENRP Handlespace Resolution 223 Threat: The ASAP protocol receives a handlespace resolution response 224 from an ENRP server, but the ENRP server is malicious and returns random 225 IP addresses or an inaccurate list in response to the pool handle. 227 Effect: PU application communicates with the wrong PE or is unable to 228 locate the PE since the response is incorrect in saying that a PE with 229 that handle did not exist. 231 Requirement: ASAP needs to authenticate the ENRP server. 233 2.8 Malicious node performs a replay attack 235 Threat: A malicious node could replay the entire message previously sent 236 by a legitimate entity. This could create false/unnecessary state in the 237 ENRP servers when the replay is for registration/de-registration or 238 update. 240 Effect: False/extra state is maintained by ENRP servers 242 Requirement: Care should be taken to prevent replay attacks. 244 2.9 Re-establishing PU-PE security during failover 246 Threat: PU fails over from PE A to PE B. In the case that the PU had a 247 trusted relationship with PE A, then the PU will likely not have the 248 same relationship established with PE B. 250 Effect: If there was a trust relationship involving security context 251 between PU and PE A, the equivalent trust relationship will not exist 252 between PU and PE B. This will violate security policy. 254 Requirement: Either notify the application when fail over occurs so the 255 application can take appropriate action to establish a trusted 256 relationship with PE B OR reestablish the security context 257 transparently. 259 2.10 Integrity 261 Threats: 262 a) ENRP response to pool handle resolution is corrupted during 263 transmission 264 b) ENRP peer messages are corrupted during transmission 265 c) PE sends update for values and that information is corrupted during 266 transmission 268 Effect: ASAP receives corrupt information for pool handle resolution 269 which the PU believes to be accurate. 271 Requirement: Integrity mechanism needed. 273 2.11 Data Confidentiality 275 Threat: An eavesdropper capable of snooping on fields within messages in 276 transit, may be able to garner information such as topology/location/IP 277 addresses etc. that may not be desirable to divulge. 279 Effect: Information that an administrator does not wish to divulge are 280 divulged. 282 Requirement: Provision for data confidentiality service. 284 2.12 ENRP Server Discovery 286 Threat A: Thwarting successful discovery: When a PE wishes to register 287 with an ENRP server, it needs to discover an ENRP server. An attacker 288 could thwart the successful discovery of ENRP server(s) thereby inducing 289 the PE to believe that no ENRP server is available. For instance, the 290 attacker could reduce the returned set of ENRP servers to null or a 291 small set of inactive ENRP servers. 293 Threat B: A similar thwarting scenario also applies when an ENRP server 294 or ASAP on behalf of a PU needs to discover ENRP servers. 296 Threat C: Spoofing successful discovery: An attacker could spoof the 297 discovery by claiming to be a legitimate ENRP server. When a PE wishes 298 to register, it finds the spoofed ENRP server. 300 Threat D: A similar spoofing scenario also applies when an ENRP server 301 or ASAP on behalf of a PU needs to discover ENRP servers. 303 Effect A: A PE that could have been in an application server pool does 304 not become part of a pool. The PE does not complete discovery operation. 305 This is a DOS attack. 307 Effect B: An ENRP server that could have been in an ENRP server pool 308 does not become part of a pool. A PU is unable to utilize services of 309 ENRP servers. 311 Effect C,D: This malicious ENRP would either misrepresent, ignore 312 or otherwise hide or distort information about the PE to subvert 313 RSERPOOL operation. 315 Requirement: Discovery phase needs to be authenticated. 317 2.13 Flood of endpoint unreachable messages from the PU to the ENRP 318 server 320 These messages are sent by ASAP to the ENRP server when it is unable to 321 contact a PE. There is the potential that a PU could flood the ENRP 322 server intentionally or unintentionally with these messages. 324 Effect: DOS attack on the ENRP server 326 Requirement: Need to limit the number of endpoint unreachable messages 327 sent to the ENRP server from the PU. 329 2.14 Flood of endpoint keep alive messages from the ENRP server to a PE 331 These messages would be sent in response to a flood of endpoint 332 unreachable messages from the PUs to the ENRP server. 334 Effect: Unintentional DOS attack on the PE 336 Requirement: ENRP must limit the frequency of keep alive messages to a 337 given PE to prevent overwhelming the PE. 339 3. Security Considerations for Rserpool 341 This informational document characterizes potential security threats 342 targeting the Rserpool architecture. The security mechanisms required 343 to mitigate these threats are summarized for each architectural 344 component. It will be noted which mechanisms are required and which are 345 optional. 347 From the threats described in this document, the security services 348 required for the Rserpool protocol are enumerated below. 350 Threat 2.1, 2.2, 2.3, 2.4) PE registration/deregistration flooding 351 and/or spoofing. 352 Security mechanism in response: ENRP server authenticates the PE 354 Threat 2.6) PE registers with a malicious ENRP server 355 Security mechanism in response: PE authenticates the ENRP server 357 These combined threats result in a requirement for mutual authentication 358 of the ENRP server and the PE. 360 Threat 2.5) Malicious ENRP server joins the ENRP server pool 361 Security mechanism in response: ENRP servers mutually authenticate 363 Threat 2.7, 2.12) A PU communicates with a malicious ENRP server for 364 handlespace resolution 365 Security mechanism in response: The PU authenticates the ENRP server. 366 If the authentication fails, it looks for another ENRP server. 368 Threat 2.8) Replay attack 369 Security mechanism in response: Security protocol which has protection 370 from replay attacks 372 Threat 2.9) Re-establishing PU-PE security during failover 373 Requirement: Either notify the application when fail over occurs so the 374 application can take appropriate action to establish a trusted 375 relationship with PE B OR reestablish the security context 376 transparently. 378 Threat 2.10) Corrupted data which causes a PU to have misinformation 379 concerning a pool handle resolution 380 Security mechanism in response: Security protocol which supports 381 integrity protection 383 Threat 2.11) Eavesdropper snooping on handlespace information 384 Security mechanism in response: Security protocol which supports data 385 confidentiality 387 To summarize the threats 2.1-2.12 require security mechanisms which 388 support authentication, integrity, data confidentiality and protection 389 from replay attacks. 391 For Rserpool we need to authenticate the following: 393 PU -----> ENRP Server (PU authenticates the ENRP server) 394 PE <----> ENRP Server (mutual authentication) 395 ENRP server <-----> ENRP Server (mutual authentication) 397 Summary by component: 399 Rserpool client -- mandatory to implement authentication of the ENRP 400 server is required for accurate pool handle resolution. This is to 401 protect against threats from rogue ENRP servers. In addition, 402 confidentiality, integrity and preventing replay attack are also 403 mandatory to implement to protect from eavesdropping and data corruption 404 or false data transmission. Confidentiality is mandatory to implement 405 and is used when privacy is required. 407 PE to ENRP communications -- mandatory to implement mutual 408 authentication, integrity and protection from replay attack is required 409 for PE to ENRP communications. This is to protect the integrity of the 410 ENRP handle space database. Confidentiality is mandatory to implement 411 and is used when privacy is required. 413 ENRP to ENRP communications -- mandatory to implement mutual 414 authentication, integrity and protection from replay attack is required 415 for ENRP to ENRP communications. This is to protect the integrity of 416 the ENRP handle space database. Confidentiality is mandatory to 417 implement and is used when privacy is required. 419 Threat 2.13) Flood of Endpoint_Unreachable messages from the PU to ENRP 420 server 421 Security mechanism in response: ASAP must control the number of endpoint 422 unreachable messages transmitted from the PU to the ENRP server. 424 Threat 2.14) Flood of Endpoint_KeepAlive messages to the PE from the 425 ENRP server 426 Security mechanism in response: ENRP server must control the number of 427 Endpoint_KeepAlive messages to the PE 428 3.1 Security of the ENRP Database 430 Another consideration involves the security characteristics of the 431 ENRP database. Suppose that some of the PEs register with an ENRP 432 server using security and some do not. In this case, when a client 433 requests handle space resolution information from ENRP, it would have to 434 be informed which entries are "secure" and which are not. This would 435 not only complicate the protocol, but actually bring into question the 436 security and integrity of such a database. What can be asserted about 437 the security of such a database is a very thorny question. Due to these 438 two facts it was decided that either the entire ENRP server database is 439 secure, that is, it has registrations exclusively from PEs 440 that have used security mechanisms or the entire database is insecure, 441 that is, registrations are from PEs that have used no security 442 mechanisms. ENRP servers that support security are required to reject 443 any PE server registration that does not use the security mechanisms. 444 Likewise, ENRP servers that support security should not accept updates 445 from other ENRP servers that do not use security mechanisms. 447 3.2 Cookie mechanism security 449 The application layer is out of scope for Rserpool. However, some 450 questions have been raised about the security of the cookie mechanism 451 which will be addressed. 453 Cookies are passed via the ASAP control channel. If TCP is selected 454 as the transport, the data and control channel must always be 455 multiplexed. Therefore, the cases: 457 a) control channel is secured; data channel is not 458 b) data channel is secured; control channel is not 460 are not allowed. It is even hard to understand what this really means 461 from a security point of view. 463 The multiplexing requirement results in the following cases: 465 1) the multiplexed control channel-data channel is secure OR 466 2) the multiplexed control channel-data channel is not secured 468 This applies to cookies in the sense that if you choose to secure your 469 control-data channel, then the cookies are secured. 471 A second issue is that the PE could choose to sign and/or encrypt the 472 cookie. In this case, it must share keys and other information with 473 other PEs. This application level state sharing is out of scope of 474 Rserpool. 476 4. IANA Considerations 478 This document introduces no additional considerations for IANA. 480 5. References 482 Normative References: 484 [Rserarch] M. Tuexen, et. al., "Architecture for Reliable Server 485 Pooling", draft-ietf-reserpool-arch-08.txt, October, 2004, work in 486 progress. 488 Informative References: 490 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", 491 RFC 2026, October 1996. 493 [RFC3365] RFC 3365, Strong Security Requirements for IETF Standard 494 Protocols, August, 2002. 496 6. Acknowledgements 498 Thanks to the Rserpool security design team and others that provided 499 valuable comments: Lyndon Ong, Randy Stewart, Melinda Shore, Qiaobing 500 Xie, Michael Tuexen, Aron Silverton, Sohrab Modi, Javier Pastor-Balbas, 501 Xingang Guo, M. Piramanayagam, Bernard Aboba and Dhooria Manoj. 503 Funding for the RFC Editor function is currently provided by the 504 Internet Society. 506 7. Intellectual Property Statement 508 Full Copyright Statement 510 Copyright (C) The Internet Society (2004). This document is 511 subject to the rights, licenses and restrictions contained in BCP 512 78, and except as set forth therein, the authors retain all their 513 rights. 515 This document and the information contained herein are provided on 516 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 517 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 518 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 519 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 520 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 521 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 522 PARTICULAR PURPOSE. 524 Intellectual Property 526 The IETF takes no position regarding the validity or scope of any 527 Intellectual Property Rights or other rights that might be claimed 528 to pertain to the implementation or use of the technology 529 described in this document or the extent to which any license 530 under such rights might or might not be available; nor does it 531 represent that it has made any independent effort to identify any 532 such rights. Information on the procedures with respect to 533 rights in RFC documents can be found in BCP 78 and BCP 79. 535 Copies of IPR disclosures made to the IETF Secretariat and any 536 assurances of licenses to be made available, or the result of an 537 attempt made to obtain a general license or permission for the use 538 of such proprietary rights by implementers or users of this 539 specification can be obtained from the IETF on-line IPR repository 540 at http://www.ietf.org/ipr. 542 The IETF invites any interested party to bring to its attention 543 any copyrights, patents or patent applications, or other 544 proprietary rights that may cover technology that may be required 545 to implement this standard. Please address the information to the 546 IETF at ietf-ipr@ietf.org. 548 expires 04 July 2005 550 8. Author's Addresses 552 Ram Gopal 553 Nokia Research Center 554 5 Wayside Road 555 Burlington, MA 01803 556 USA 557 email: ram.gopal@nokia.com 559 Erik Guttman 560 Sun Microsystems 561 Eichhoelzelstr. 7 562 74915 Waibstadt 563 Germany 564 Email: Erik.Guttman@sun.com 566 Matt Holdrege 567 Strix Systems 568 26610 Agoura Road, Suite 110 569 Calabasas, CA, 91302 570 matt@strixsystems.com 572 Senthil Sengodan 573 Nokia Research Center 574 5 Wayside Road 575 Burlington, MA 01803 576 USA 577 email: Senthil.sengodan@nokia.com 579 Maureen Stillman 580 Nokia 581 35 Woodcrest Ave. 582 Ithaca, NY 14850 583 USA 584 email: maureen.stillman@nokia.com