idnits 2.17.00 (12 Aug 2021) /tmp/idnits33374/draft-ohba-6tsch-security-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 24, 2013) is 3253 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ZigBeeIP' is mentioned on line 495, but not defined == Missing Reference: 'IEEE802154e' is mentioned on line 483, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 489, but not defined == Unused Reference: 'RFC2119' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 446, but no explicit reference was found in the text == Unused Reference: 'RFC6550' is defined on line 453, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-palattella-6tsch-terminology' is defined on line 469, but no explicit reference was found in the text == Unused Reference: 'I-D.draft-thubert-6tsch-architecture' is defined on line 475, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: draft-ietf-hip-rfc5201-bis has been published as RFC 7401 == Outdated reference: A later version (-01) exists of draft-palattella-6tsch-terminology-00 == Outdated reference: A later version (-02) exists of draft-thubert-6tsch-architecture-00 Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TSCH S. Chasko 3 Internet-Draft L+G 4 Intended status: Informational S. Das 5 Expires: December 26, 2013 ACS 6 R. Marin-Lopez 7 University of Murcia 8 Y. Ohba, Ed. 9 Toshiba 10 P. Thubert 11 cisco 12 A. Yegin 13 Samsung 14 June 24, 2013 16 Security Framework and Key Management Protocol Requirements for 6TSCH 17 draft-ohba-6tsch-security-00 19 Abstract 21 Since 6TSCH forms layer 3 meshes over IPv6, PANA model matches the 22 target architecture so PANA can apply for the process by a new device 23 of joining the mesh to extend it. This document details that 24 particular operation within the whole 6TSCH architecture. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 26, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Security Framework . . . . . . . . . . . . . . . . . . . . . 3 63 4. KMP requirements . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. Phase-1 KMP requirements . . . . . . . . . . . . . . . . 6 65 4.2. Phase-2 KMP requirements . . . . . . . . . . . . . . . . 6 66 5. KMP candidates . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.1. Phase-1 KMP candidates . . . . . . . . . . . . . . . . . 7 68 5.2. Phase-2 KMP candidates . . . . . . . . . . . . . . . . . 7 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 8.2. Informative References . . . . . . . . . . . . . . . . . 10 74 8.3. External Informative References . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 The emergence of radio technology enabled a large variety of new 80 types of devices to be interconnected, at a very low marginal cost 81 compared to wire, at any range from Near Field to interplanetary 82 distances, and in circumstances where wiring could be less than 83 practical, for instance rotating devices. 85 At the same time, a new breed of Time Sensitive Networks is being 86 developed to enable traffic that is highly sensitive to jitter and 87 quite sensitive to latency. Such traffic is not limited to voice and 88 video, but also includes command and control operations such as found 89 in industrial automation or in-vehicular sensors and actuators. 91 6TSCH builds on a series of semi-proprietary wireless protocols that 92 provide adequate Time Sensitive behaviors for low speed control 93 loops, protocols that are rapidly gaining acceptance in the 94 automation industry for mission critical Process Control 95 applications. For such applications, security is not an option and a 96 power efficient authentication mechanism is strictly required. 98 Following Metcalf's law, value of using radios augments with the 99 square of the number of devices connected, and this implies the 100 capability to form autonomic mesh networks be it only for reasons of 101 spatial reuse of the spectrum. Since 6TSCH forms layer 3 meshes over 102 IPv6, the PANA model matches the target architecture so PANA can 103 apply for the process by a new device of joining the mesh to extend 104 it. 106 ZigBee IP [ZigBeeIP] ("ZigBee" is a registered trademark of the 107 ZigBee Alliance) is a standard for IPv6-based wireless mesh networks 108 using PANA for network access authentication and secure distribution 109 of a link-layer group key called Network Key to authenticated mesh 110 nodes. Each mesh node in the same ZigBee IP network derives the same 111 MAC key from the Network Key to protect IEEE 802.15.4 MAC frames 112 exchanged between adjacent mesh nodes. While sharing the same MAC 113 key among all mesh nodes can make the required key state maintained 114 by each mesh node compact, a compromise of a mesh node can lead to 115 MAC key leakage in the entire ZigBee IP network. Also, the cost of 116 updating the MAC key can be high as the key needs to be updated at 117 all mesh nodes whenever the frame counter at any single node wraps up 118 or the key is considered to be weak. 120 This document introduces a more secure and scalable key management 121 framework for 6TSCH networks using PANA as the boostrapping mechansim 122 and identifies requirements for key management protocols to be used 123 in the framework. 125 2. Acronyms 127 6TSCH: TBD (Editor's note: what is the expansion of 6TSCH?) 129 KMP: Key Managment Protocol 131 PANA: Protocol for carrying Authentication for Network Access 133 SA: Security Association 135 MAC: Media Access Control 137 3. Security Framework 138 This section describes a security framework consisting of three 139 phases as shown in Figure 1. The architecture is applicable to not 140 only 6TSCH networks but also non-time synchronized mesh networks. 141 Each node in a mesh network runs through the following phases: 143 o Phase-1 (Bootstrapping Phase): In this phase, a node (re)installs 144 credentials used for subsequent phases from an authentication 145 server. The credentials include Phase-2 credentials and Phase-3 146 credentials, and may also include long-term Phase-1 credentials if 147 the initial Phase-1 credentials are intended for one-time use such 148 as a temporal PIN. An authentication and key establishment 149 protocol called a Phase-1 KMP is conducted between the node and 150 the authentication server using Phase-1 credentials. The Phase-1 151 credentials have longer lifetime than Phase-2 and Phase-3 152 credentials so that Phase-2 and Phase-3 credentials can be renewed 153 using the Phase-1 credentials. Both symmetric and asymmetric key 154 credentials can be used as Phase-1 credentials. A symmetric key 155 that is established as a result of successful Phase-1 KMP is used 156 for encrypting the Phase-2 and Phase-3 credentials distributed 157 from the authentication server to the node. When the 158 authentication server is multiple hops away from the node, mutual 159 authentication between the node and the authentication server is 160 conducted via a neighboring node acting as an authentication 161 relay. There may be no link-layer security available between the 162 node and its neighboring node in this phase. An authentication 163 server is typically (but is not necessarily) located in the 164 coordinator of the mesh network. 166 o Phase-2 (Link Establishment Phase): In this phase, the node 167 performs mutual authentication with its neighboring node using the 168 Phase-2 credentials to establish SAs between adjacent nodes for 169 protecting 802.15.4 MAC frames. The authentication and key 170 establishment protocol used in this phase is referred as a Phase-2 171 KMP or a link establishment KMP. For highly scalable mesh 172 networks consisting of thousands of mesh nodes, asymmetric key 173 credentials are used as the Phase-2 credentials. The SA of a link 174 between node i and node j maintains MAC keys. K_i denotes a MAC 175 key for protecting broadcast MAC frames originated at node i. 176 K_ij denotes a MAC key for protecting unicast MAC frames 177 originated at node i and destined for node j. There are several 178 variations of forming MAC keys. 180 1. K_ij=K_i for all j, K_i!=K_j for all i, j (i!=j) 182 2. K_ij=K_ji, K_i!=K_j for all i,j (i!=j) 184 3. K_ij!=K_ji, K_i!=K_j for all i,j (i!=j) 185 In model 1, unicast and broadcast keys for protecting MAC frames 186 originated at a given node are the same. In models 2 and 3, 187 unicast and broadcast keys originated at a given node are 188 distinct. The difference between models 2 and 3 is that unicast 189 keys are bi-directinal in model 2 while they are uni-directinal in 190 model 3. One model may be chosen among three depending on 191 required security level and the number of keys maintained by each 192 node. 194 o Phase-3 (Operational Phase): In this phase, the node is able to 195 run various higher-layer protocols over IP over an established 196 secure link. Additional authentication and key establishment may 197 take place for the higher-layer protocols using Phase-3 198 credentials. A node in Phase-3 is able to process Phase-1 and 199 Phase-2 KMPs. Example use cases are: 201 * A Phase-3 node can initiate a Phase-1 KMP to update its Phase-2 202 or Phase-3 credentials. 204 * A Phase-3 node can forward Phase-1 KMP messages originated from 205 or destined for a Phase-1 node that is joining the mesh network 206 through the Phase-3 node. 208 * A Phase-3 node can initiate a Phase 2 KMP to establish a new 209 link with a newly discovered neighbor node. 211 +---------------------------------+ 212 | Phase-1 (Bootstrap) | 213 +---------------------------------+ 214 | 215 v 216 +---------------------------------+ 217 | Phase-2 (Link Establishment) | 218 +---------------------------------+ 219 | 220 v 221 +---------------------------------+ 222 | Phase-3 (Operational) | 223 +---------------------------------+ 225 Figure 1: 3-Phase Key Management Model 227 N)s - Node N is running Phase-1 KMP as a server 228 N)c - Node N is running Phase-1 KMP as a client 229 N)r - Node N is running Phase-1 KMP as a relay 230 N)) - Node N is running Phase-2 KMP 231 . .. ... 232 N, N, N - Node N is in Phase-1, -2 and -3, respectively 234 . . .. ... ... ... 235 A A)s A)) A)s A A 236 / \ / \ / \ / \ / \ 237 . . . . .. .. ... ... ... ... ... ... 238 B C B)c C)c B)) C)) B)r C B)) C)) B C 239 / \ / / \ / / \ / 240 . . . . . . . . .. .. ... ... 241 D E D E D E D)c E)c D)) E)) D E 243 (0) -> (1) -> (2) -> (3) -> (4) -> (5) 245 (0) Initially all nodes but Node A (i.e., the authentication server) 246 are in Phase-1. (1) Nodes B and C run Phase-1 KMP with Node A to 247 obtain Phase-2 and Phase-3 credentials. (2) Nodes B and C run 248 Phase-2 KMP with Node A. (3) Nodes D and E run Phase-1 KMP using 249 Node B as an authentication relay. (Alternatively, Node E may use 250 Node C as an authentication relay.) (4) Node D runs Phase-2 KMP with 251 Node B. Node E runs Phase-2 KMP with Nodes B and C. (5) All nodes 252 are operational. 254 Figure 2: Example Sequence 256 Since we already identified PANA as the Phase-1 KMP due to its 257 authentication relay and secure credential distribution capabilities, 258 and Phase-3 KMP requirements would depend on application protocols, 259 we focus on Phase-2 KMP requirements in the next seciton. 261 4. KMP requirements 263 4.1. Phase-1 KMP requirements 265 Requirements on Phase-1 KMP are listed below. 267 R1-1: Phase-1 KMP MUST support mutual authentication. 269 R1-2: Phase-1 KMP MUST support stateless authentication relay 270 operation. 272 R1-3:s Phase-1 KMP MUST support secure credential distribution. 274 4.2. Phase-2 KMP requirements 276 Requirements on Phase-2 KMP are listed below. 278 R2-1: Phase-2 KMP Nodes MUST mutually authenticate each other before 279 establishing a link and forming a mesh network. No authentication 280 server is involved in the Phase-2 authentication. 282 R2-2: Phase-2 KMP authentication credentials MAY be pre-provisioned 283 or MAY be obtained via Phase-1 KMP. 285 R2-3: Phase-2 KMP authentication credentials MUST have a lifetime. 287 R2-4: Phase-2 KMP MUST support asymmetric key-based credentials for 288 scalable operation. 290 R2-5: Phase-2 KMP message exchanges MUST be integrity and reply 291 protected after successful authentication. 293 R2-6: Phase-2 KMP MUST have the capability to establish security 294 association and unicast session keys after successful authentication 295 to protect unicast MAC frames between nodes. 297 R2-7: Phase-2 KMP MUST have the capability to establish security 298 association and broadcast session keys after successful 299 authentication to protect broadcast MAC frames between nodes. 301 R2-8: Phase-2 KMP MUST have the capability to distribute the 302 broadcast session keys securely. 304 5. KMP candidates 306 5.1. Phase-1 KMP candidates 308 PANA [RFC5191] is the Phase-1 KMP candidate since it supports mutual 309 authenticatio, stateless authentication relay function [RFC6345] and 310 encrypted distribution of attributes [RFC6786]. The PANA 311 Authentication Agent (PAA) is located in the coordinator of the mesh 312 network. 314 5.2. Phase-2 KMP candidates 316 Once Phase-1 is complete by using PANA, it is assumed that node will 317 have a certified public key (and associated private key). A candiate 318 Phase 2 KMP must use this certified public key to perform an 319 authentication process. As a consequence of a successful 320 authentication some cryptographic material for unicast and multicast 321 link protection between nodes must be generated. 323 A list of candidate protocols may provide the requirements defined in 324 Section 4.2 (this is a preliminary list that may be extended in the 325 future): 327 o HIP DEX [I-D.moskowitz-hip-rg-dex]. The Host Identity Protocol 328 Diet EXchange (HIP DEX) is a lighter version of the HIP Base 329 Exchange (HIP BEX) [I-D.ietf-hip-rfc5201-bis] specifically 330 designed to be used in constrained devices (e.g sensor networks). 331 In particular, HIP DEX may be used to authenticate two IEEE 332 802.15.4 nodes and provide key material for a MAC layer security 333 protocol as supported in IEEE 802.15.4. However, by just using 334 the value of the public key and the private key is not enough to 335 carry out the authentication between nodes. In particular, a node 336 A and node B should not be able to successfully finish HIP DEX 337 execution if they both have not been authenticated in Phase-1. 338 Thus, HIP DEX will require the inclusion of the certificate of 339 each node to achieve full mutual authentication. The information 340 in the certificate must ensure that the node was authenticated in 341 Phase-1. In consequence, HIP DEX must include a CERT parameter 342 for carrying this certificate. Once the HIP DEX protocol has 343 succesfully finished a Pair-Wise Key SA is derived. This SA is 344 used to secure and authenticate user data, thus it can be used to 345 provide the required keys for protecting IEEE 802.15.4 unicast MAC 346 frames. The same message is used to refresh the Pair-Wise Key SA. 347 So far HIP DEX only specifies how this key material is used for 348 protecting data traffic with ESP. To distribute multicast keys 349 HIP DEX may also use UPDATE message. For less resource- 350 constrained devices, HIP-BEX (Basic Exchange) is more suitable 351 than HIP-DEX since HIP-BEX has better security properties (such as 352 use of ephemeral Diffie-Hellman) than HIP-DEX at the cost of 353 increased complexity. 355 o PANA [RFC5191] and some certificate-based EAP method. Another 356 candidate is to use PANA between node A and node B. In this case, 357 one of the nodes (e.g. node A) acts as PaC while the other (e.g. 358 node B) is acting as PAA. Moreover the PAA will operate in 359 standalone mode [RFC4137]. That is, the EAP server is placed on 360 the PAA and not in a backend authentication server. Finally, the 361 selected EAP method must work with public key/private key 362 cryptography. Once the PAA authentication is complete, the PaC 363 and PAA can derive cryptographic material (for instance, from the 364 MSK) which can be used to protect unicast MAC frames. Futhermore, 365 by using the extension defined in [RFC6345] is possible to 366 distribute a multicast key encrypted with the PANA SA. It is 367 worth noting that, though this candidate solution leverages the 368 PaC implementation from Phase-1, each node needs to deploy a PAA 369 implementation, an EAP server and a specific EAP method, which may 370 be different from the one used for Phase-1. 372 o DTLS[RFC6347]. Datagram Transport Layer Security (DTLS) is being 373 considered in constrained devices for protecting application data 374 traffic (e.g. CoAP). It is not only being considered for unicast 375 application data traffic but also for multicast data traffic 376 [I-D.keoh-tls-multicast-security]. In particular, a multicast key 377 is distributed over an unicast DTLS channel established between 378 two nodes (node A and node B). This multicast key is used to 379 protect multicast traffic by using TLS records. The Phase2-KMP 380 should be able to export this key material to the IEEE 802.15.4 381 MAC layer so that the protection is carried out at link layer. In 382 [RFC5705], a mechanism for exporting key material after a TLS/DTLS 383 execution is defined. Nevertheless, the exported key material is 384 intended to be used in unicast communications for upper layers or 385 protocols at upper layers. However, multicast key exportation is 386 not specified. In principle, this exported key material may be 387 used for protecting unicast IEEE 802.15.4 MAC frames. However, 388 this usage and the multicast key exportation for multicast IEEE 389 802.15.4 protection need further investigation. 391 6. Security Considerations 393 In this section, security issues that can potentially impact the 394 operation of IEEE 802.15.4e TSCH MAC are described. 396 In TSCH MAC, time synchronization and channel hopping information are 397 advertised in Enhanced Beacon (EB) frames. The advertised 398 information is used by mesh nodes to determine the timeslots 399 available for transmission and reception of MAC frames. A rogue node 400 can inject forged EB frames and can cause replay and DoS attacks to 401 TSCH MAC operation. To mitigate such attacks, all EB frames MUST be 402 integrity protected. While it is possible to use a pre-installed 403 static key for protecting EB frames to every node, the static key 404 becomes vulnerable when the associated MAC frame counter continues to 405 be used after the frame counter wraps. Therefore, the 6TSCH solution 406 MUST provide a mechanism by which mesh nodes can use the available 407 time slots to run an authentication and key exchange protocol and 408 provide intergrity protection to EB frames. 410 7. IANA Considerations 412 There is no IANA action required for this document. 414 8. References 416 8.1. Normative References 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, March 1997. 421 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 422 Yegin, "Protocol for Carrying Authentication for Network 423 Access (PANA)", RFC 5191, May 2008. 425 [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. 426 Yegin, "Protocol for Carrying Authentication for Network 427 Access (PANA) Relay Element", RFC 6345, August 2011. 429 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 430 Security Version 1.2", RFC 6347, January 2012. 432 [RFC6786] Yegin, A. and R. Cragie, "Encrypting the Protocol for 433 Carrying Authentication for Network Access (PANA) 434 Attribute-Value Pairs", RFC 6786, November 2012. 436 [I-D.moskowitz-hip-rg-dex] 437 Moskowitz, R., "HIP Diet EXchange (DEX)", draft-moskowitz- 438 hip-rg-dex-06 (work in progress), May 2012. 440 8.2. Informative References 442 [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 443 "State Machines for Extensible Authentication Protocol 444 (EAP) Peer and Authenticator", RFC 4137, August 2005. 446 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 447 "Transmission of IPv6 Packets over IEEE 802.15.4 448 Networks", RFC 4944, September 2007. 450 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 451 Layer Security (TLS)", RFC 5705, March 2010. 453 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 454 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 455 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 456 Lossy Networks", RFC 6550, March 2012. 458 [I-D.keoh-tls-multicast-security] 459 Keoh, S., Kumar, S., and E. Dijk, "DTLS-based Multicast 460 Security for Low-Power and Lossy Networks (LLNs)", draft- 461 keoh-tls-multicast-security-00 (work in progress), October 462 2012. 464 [I-D.ietf-hip-rfc5201-bis] 465 Moskowitz, R., Heer, T., Jokela, P., and T. Henderson, 466 "Host Identity Protocol Version 2 (HIPv2)", draft-ietf- 467 hip-rfc5201-bis-11 (work in progress), February 2013. 469 [I-D.draft-palattella-6tsch-terminology] 470 Palattella, MR., Ed., Thubert, P., Watteyne, T., and Q. 471 Wang, "Terminology in IPv6 over Time Slotted Channel 472 Hopping. draft-palattella-6tsch-terminology-00 (work in 473 progress) ", March 2013. 475 [I-D.draft-thubert-6tsch-architecture] 476 Thubert, P., Ed., Assimiti, R., and T. Watteyne, "An 477 Architecture for IPv6 over Time Synchronized Channel 478 Hopping. draft-thubert-6tsch-architecture-00 (work in 479 progress) ", March 2013. 481 8.3. External Informative References 483 [IEEE802154e] 484 IEEE standard for Information Technology, "IEEE std. 485 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 486 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 487 2012. 489 [IEEE802154] 490 IEEE standard for Information Technology, "IEEE std. 491 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 492 and Physical Layer (PHY) Specifications for Low-Rate 493 Wireless Personal Area Networks", June 2011. 495 [ZigBeeIP] 496 ZigBee Public Document 15-002r00, "ZigBee IP 497 Specification", 2013. 499 Authors' Addresses 501 Stephen Chasko 502 Landis+Gyr 503 3000 Mill Creek Ave. 504 Alpharetta, GA 30022 505 USA 507 Email: Stephen.Chasko@landisgyr.com 509 Subir Das 510 Applied Communication Sciences 511 1 Telcordia Drive 512 Piscataway, NJ 08854 513 USA 515 Email: sdas@appcomsci.com 516 Rafa Marin-Lopez 517 University of Murcia 518 Campus de Espinardo S/N, Faculty of Computer Science 519 Murcia 30100 520 Spain 522 Phone: +34 868 88 85 01 523 Email: rafa@um.es 525 Yoshihiro Ohba (editor) 526 Toshiba Corporate Research and Development Center 527 1 Komukai-Toshiba-cho 528 Saiwai-ku, Kawasaki, Kanagawa 212-8582 529 Japan 531 Phone: +81 44 549 2127 532 Email: yoshihiro.ohba@toshiba.co.jp 534 Pascal Thubert 535 Cisco Systems, Inc 536 Village d'Entreprises Green Side 537 400, Avenue de Roumanille 538 Batiment T3 539 Biot - Sophia Antipolis 06410 540 FRANCE 542 Phone: +33 497 23 26 34 543 Email: pthubert@cisco.com 545 Alper Yegin 546 Samsung 547 Istanbul 548 Turkey 550 Email: alper.yegin@yegin.org