idnits 2.17.1 draft-ietf-tram-turn-mobility-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 4, 2016) is 2943 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) -- Looks like a reference, but probably isn't: '16' on line 512 ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRAM D. Wing 3 Internet-Draft P. Patil 4 Intended status: Standards Track T. Reddy 5 Expires: October 6, 2016 P. Martinsen 6 Cisco 7 April 4, 2016 9 Mobility with TURN 10 draft-ietf-tram-turn-mobility-02 12 Abstract 14 It is desirable to minimize traffic disruption caused by changing IP 15 address during a mobility event. One mechanism to minimize 16 disruption is to expose a shorter network path to the mobility event 17 so only the local network elements are aware of the changed IP 18 address but the remote peer is unaware of the changed IP address. 20 This draft provides such an IP address mobility solution using 21 Traversal Using Relays around NAT (TURN). This is achieved by 22 allowing a client to retain an allocation on the TURN server when the 23 IP address of the client changes. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 6, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3 61 3. Mobility using TURN . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Creating an Allocation . . . . . . . . . . . . . . . . . 5 63 3.1.1. Sending an Allocate Request . . . . . . . . . . . . . 5 64 3.1.2. Receiving an Allocate Request . . . . . . . . . . . . 5 65 3.1.3. Receiving an Allocate Success Response . . . . . . . 5 66 3.1.4. Receiving an Allocate Error Response . . . . . . . . 6 67 3.2. Refreshing an Allocation . . . . . . . . . . . . . . . . 6 68 3.2.1. Sending a Refresh Request . . . . . . . . . . . . . . 6 69 3.2.2. Receiving a Refresh Request . . . . . . . . . . . . . 6 70 3.2.3. Receiving a Refresh Response . . . . . . . . . . . . 7 71 3.3. New STUN Attribute MOBILITY-TICKET . . . . . . . . . . . 8 72 3.4. New STUN Error Response Code . . . . . . . . . . . . . . 8 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 75 5.1. open-sys . . . . . . . . . . . . . . . . . . . . . . . . 9 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 8.2. Informative References . . . . . . . . . . . . . . . . . 10 81 Appendix A. Example ticket construction . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 When moving between networks, the endpoint's IP address can change or 87 (due to NAT) the endpoint's public IP address can change. Such a 88 change of IP address breaks upper layer protocols such as TCP and 89 RTP. Various techniques exist to prevent this breakage, all tied to 90 making the endpoint's IP address static (e.g., Mobile IP, Proxy 91 Mobile IP, LISP). Other techniques exist, which make the change in 92 IP address agnostic to the upper layer protocol (e.g., SCTP). The 93 mechanism described in this document are in that last category. 95 A Traversal Using Relays around NAT (TURN) [RFC5766] server relays 96 media packets and is used for a variety of purposes, including 97 overcoming NAT and firewall traversal issues. The existing TURN 98 specification does not permit a TURN client to reuse an allocation 99 across client IP address changes. Due to this, when the IP address 100 of the client changes, the TURN client has to request for a new 101 allocation, create permissions for the remote peer, create channels 102 etc. In addition the client has to re-establish communication with 103 its SIP server, send an updated offer to the remote peer conveying 104 the new relayed candidate address, remote side has to regather all 105 candidates and signal them to the client and then the endpoints have 106 to perform Interactive Connectivity Establishment (ICE) [RFC5245] 107 connectivity checks. If ICE continuous nomination procedure 108 [I-D.uberti-mmusic-nombis] is used then new relayed candidate address 109 would have to be tricked [I-D.ietf-mmusic-trickle-ice] and ICE 110 connectivity checks have to be performed by the endpoints to nominate 111 pairs that will be selected by ICE. 113 This specification describes a mechanism to seamlessly reuse 114 allocations across client IP address changes without any of the 115 hassles described above. A critical benefit of this technique is 116 that the remote peer does not have to support mobility, or deal with 117 any of the address changes. The client, that is subject to IP 118 address changes, does all the work. The mobility technique works 119 across and between network types (e.g., between 3G and wired Internet 120 access), so long as the client can still access the TURN server. The 121 technique should also work seamlessly when (D)TLS is used as a 122 transport protocol for STUN. When there is a change in IP address, 123 the client uses (D)TLS Session Resumption without Server-Side State 124 as described in [RFC5077] to resume secure communication with the 125 TURN server, using the changed client IP address. 127 2. Notational Conventions 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 This note uses terminology defined in [RFC5245], and the following 134 additional terminology: 136 Break Before Make: The old communication path is broken ("break") 137 before the new communication can be made ("make"). Such changes 138 typically occur because a network is disconnected with a physical 139 cable, turning radio off, or moving out of radio range. 141 Make Before Break: A new communication path is created ("make") 142 before the old communication path is broken ("break"). Such changes 143 typically occur because a network is connected with a physical cable, 144 turning radio on, or moving in of radio range. 146 3. Mobility using TURN 148 To achieve mobility, a TURN client should be able to retain an 149 allocation on the TURN server across changes in the client IP address 150 as a consequence of movement to other networks. 152 When the client sends the initial Allocate request to the TURN 153 server, it will include a new STUN attribute MOBILITY-TICKET (with 154 zero length value), which indicates that the client is capable of 155 mobility and desires a ticket. The TURN server provisions a ticket 156 that is sent inside the new STUN attribute MOBILITY-TICKET in the 157 Allocate Success response to the client. The ticket will be used by 158 the client when it wants to refresh the allocation but with a new 159 client IP address and port. This ensures that an allocation can only 160 be refreshed by the same client that allocated relayed transport 161 address. When a client's IP address changes due to mobility, it 162 presents the previously obtained ticket in a Refresh Request to the 163 TURN server. If the ticket is found to be valid, the TURN server 164 will retain the same relayed address/port for the new IP address/port 165 allowing the client to continue using previous channel bindings -- 166 thus, the TURN client does not need to obtain new channel bindings. 167 Any data from external peer will be delivered by the TURN server to 168 this new IP address/port of the client. The TURN client will 169 continue to send application data to its peers using the previously 170 allocated channelBind Requests. 172 TURN TURN Peer 173 client server A 174 |-- Allocate request --------------->| | 175 | + MOBILITY-TICKET (length=0) | | 176 | | | 177 |<--------------- Allocate failure --| | 178 | (401 Unauthorized) | | 179 | | | 180 |-- Allocate request --------------->| | 181 | + MOBILITY-TICKET (length=0) | | 182 | | | 183 |<---------- Allocate success resp --| | 184 | + MOBILITY-TICKET | | 185 ... ... ... 186 (changes IP address) 187 | | | 188 |-- Refresh request ---------------->| | 189 | + MOBILITY-TICKET | | 190 | | | 191 |<----------- Refresh success resp --| | 192 | + MOBILITY-TICKET | | 193 | | | 195 3.1. Creating an Allocation 197 3.1.1. Sending an Allocate Request 199 In addition to the process described in Section 6.1 of [RFC5766], the 200 client includes the MOBILITY-TICKET attribute with length 0. This 201 indicates the client is a mobile node and wants a ticket. 203 3.1.2. Receiving an Allocate Request 205 In addition to the process described in Section 6.2 of [RFC5766], the 206 server does the following: 208 If the MOBILITY-TICKET attribute is included, and has length zero, 209 but TURN session mobility is forbidden by local policy, the server 210 MUST reject the request with the new Mobility Forbidden error code. 211 If the MOBILITY-TICKET attribute is included and has non-zero length 212 then the server MUST generate an error response with an error code of 213 400 (Bad Request). Following the rules specified in [RFC5389], if 214 the server does not understand the MOBILITY-TICKET attribute, it 215 ignores the attribute. 217 If the server can successfully process the request create an 218 allocation, the server replies with a success response that includes 219 a STUN MOBILITY-TICKET attribute. TURN server can store system 220 internal data into the ticket that is encrypted by a key known only 221 to the TURN server and sends the ticket in the STUN MOBILITY-TICKET 222 attribute as part of Allocate success response. The ticket is opaque 223 to the client, so the structure is not subject to interoperability 224 concerns, and implementations may diverge from this format. An 225 example for ticket construction is discussed in Appendix A. The 226 client could be roaming across networks with different path MTU and 227 from one address family to another (e.g. IPv6 to IPv4). The TURN 228 server to support mobility must assume that the path MTU is unknown 229 and use a ticket length in accordance with published guidance on STUN 230 UDP fragmentation (Section 7.1 of [RFC5389]). Clients MUST NOT 231 examine the ticket under the assumption that it complies with this 232 document. 234 3.1.3. Receiving an Allocate Success Response 236 In addition to the process described in Section 6.3 of [RFC5766], the 237 client will store the MOBILITY-TICKET attribute, if present, from the 238 response. This attribute will be presented by the client to the 239 server during a subsequent Refresh request to aid mobility. 241 3.1.4. Receiving an Allocate Error Response 243 If the client receives an Allocate error response with error code TBD 244 (Mobility Forbidden), the error is processed as follows: 246 o TBD (Mobility Forbidden): The request is valid, but the server is 247 refusing to perform it, likely due to administrative restrictions. 248 The client considers the current transaction as having failed. The 249 client MAY notify the user or operator and SHOULD NOT retry the same 250 request with this server until it believes the problem has been 251 fixed. 253 All other error responses must be handled as described in [RFC5766]. 255 3.2. Refreshing an Allocation 257 3.2.1. Sending a Refresh Request 259 If a client wants to refresh an existing allocation and update its 260 time-to-expiry or delete an existing allocation, it will send a 261 Refresh Request as described in Section 7.1 of [RFC5766]. If the 262 client wants to retain the existing allocation in case of IP change, 263 it will include the MOBILITY-TICKET attribute received in the 264 Allocate Success response. If a Refresh transaction was previously 265 made, the MOBILITY-TICKET attribute received in the Refresh Success 266 response of the transaction must be used. 268 3.2.2. Receiving a Refresh Request 270 In addition to the process described in Section 7.2 of [RFC5766], the 271 server does the following: 273 If the STUN MOBILITY-TICKET attribute is included in the Refresh 274 Request then the server will not retrieve the 5-tuple from the packet 275 to identify an associated allocation. Instead the TURN server will 276 decrypt the received ticket, verify the ticket's validity and 277 retrieve the 5-tuple allocation using the ticket. If this 5-tuple 278 obtained does not identify an existing allocation then the server 279 MUST reject the request with an error. 281 If the source IP address and port of the Refresh Request is different 282 from the stored 5-tuple allocation, the TURN server proceeds with 283 MESSAGE-INTEGRITY validation to identify the that it is the same user 284 which had previously created the TURN allocation. If the above 285 checks are not successful then server MUST reject the request with a 286 441 (Wrong Credentials) error. 288 If all of the above checks pass, the TURN server understands that the 289 client has either moved to a new network and acquired a new IP 290 address (Break Before Make) or is in the process of switching to a 291 new interface (Make Before Break). The source IP address of the 292 request could either be the host transport address or server- 293 reflexive transport address. The server then updates it's state data 294 with the new client IP address and port but does not discard the old 295 5-tuple from it's state data. TURN server calculates the ticket with 296 the new 5-tuple and sends the new ticket in the STUN MOBILITY-TICKET 297 attribute as part of Refresh Success response. 299 The TURN server MUST continue receiving and processing data on the 300 old 5-tuple and MUST continue transmitting data on the old-5 tuple 301 until it receives an Send Indication or ChannelData message from the 302 client on the new 5-tuple or an message from the client to close the 303 old connection (e.g., a TLS fatal alert, TCP RST). After receiving 304 any of those messages, a TURN server discards the the old ticket and 305 the old 5-tuple associated with the old ticket from its state data. 306 Data sent by the client to the peer is accepted on the new 5-tuple 307 and data received from the peer is forwarded to the new 5-tuple. If 308 the refresh request containing the MOBILITY-TICKET attribute does not 309 succeed (e.g., packet lost if the request is sent over UDP, or the 310 server being unable to fulfill the request) then the client can 311 continue to exchange data on the old 5-tuple until it receives 312 Refresh success response. 314 The old ticket can only be used for the purposes of retransmission. 315 If the client wants to refresh its allocation with a new server- 316 reflexive transport address, it MUST use the new ticket. If the TURN 317 server has not received a Refresh Request with STUN MOBILITY-TICKET 318 attribute but receives Send indications or ChannelData messages from 319 a client, the TURN server may discard or queue those Send indications 320 or ChannelData messages (at its discretion). Thus, it is RECOMMENDED 321 that the client avoid transmitting a Send indication or ChannelData 322 message until it has received an acknowledgement for the Refresh 323 Request with STUN MOBILITY-TICKET attribute. 325 To accommodate for loss of Refresh responses, a server must retain 326 the old STUN MOBILITY-TICKET attribute for a period of at least 30 327 seconds to be able recognize a retransmission of Refresh request with 328 the old STUN MOBILITY-TICKET attribute from the client. 330 3.2.3. Receiving a Refresh Response 332 In addition to the process described in Section 7.3 of [RFC5766], the 333 client will store the MOBILITY-TICKET attribute, if present, from the 334 response. This attribute will be presented by the client to the 335 server during a subsequent Refresh Request to aid mobility. 337 3.3. New STUN Attribute MOBILITY-TICKET 339 This attribute is used to retain an Allocation on the TURN server. 340 It is exchanged between the client and server to aid mobility. The 341 value of MOBILITY-TICKET is encrypted and is of variable-length. 343 3.4. New STUN Error Response Code 345 This document defines the following new error response code: 347 Mobility Forbidden: Mobility request was valid but cannot be 348 performed due to administrative or similar restrictions. 350 4. IANA Considerations 352 IANA is requested to add the following attributes to the STUN 353 attribute registry [iana-stun], 355 o MOBILITY-TICKET (0x8030, in the comprehension-optional range) 357 and to add a new STUN error code "Mobility Forbidden" with the value 358 405 to the STUN Error Codes registry [iana-stun]. 360 5. Implementation Status 362 [Note to RFC Editor: Please remove this section and reference to 363 [RFC6982] prior to publication.] 365 This section records the status of known implementations of the 366 protocol defined by this specification at the time of posting of this 367 Internet-Draft, and is based on a proposal described in [RFC6982]. 368 The description of implementations in this section is intended to 369 assist the IETF in its decision processes in progressing drafts to 370 RFCs. Please note that the listing of any individual implementation 371 here does not imply endorsement by the IETF. Furthermore, no effort 372 has been spent to verify the information presented here that was 373 supplied by IETF contributors. This is not intended as, and must not 374 be construed to be, a catalog of available implementations or their 375 features. Readers are advised to note that other implementations may 376 exist. 378 According to [RFC6982], "this will allow reviewers and working groups 379 to assign due consideration to documents that have the benefit of 380 running code, which may serve as evidence of valuable experimentation 381 and feedback that have made the implemented protocols more mature. 382 It is up to the individual working groups to use this information as 383 they see fit". 385 5.1. open-sys 387 Organization: This is a public project, the full list of authors 388 and contributors here: http://turnserver.open-sys.org/downloads/ 389 AUTHORS 391 Description: A mature open-source TURN server specs implementation 392 (RFC 5766, RFC 6062, RFC 6156, etc) designed for high-performance 393 applications, especially geared for WebRTC. 395 Implementation: http://code.google.com/p/rfc5766-turn-server/ 397 Level of maturity: The Mobile ICE feature implementation can be 398 qualified as "production" - it is well tested and fully 399 implemented, but not widely used, yet.. 401 Coverage: Fully implements MICE with TURN protocol. 403 Licensing: BSD: http://turnserver.open-sys.org/downloads/LICENSE 405 Implementation experience: MICE implementation is somewhat 406 challenging for a multi-threaded performance-oriented application 407 (because the mobile ticket information must be shared between the 408 threads) but it is doable. 410 Contact: Oleg Moskalenko . 412 6. Security Considerations 414 TURN server MUST use strong encryption and integrity protection for 415 the ticket to prevent an attacker from using a brute force mechanism 416 to obtain the ticket's contents or refreshing allocations. The 417 ticket MUST be constructed such that it has strong entropy to ensure 418 nothing can be gleaned by looking at the ticket alone. 420 An attacker monitoring the traffic between the TURN client and server 421 can impersonate the client and refresh the allocation using the 422 ticket issued to the client with the attackers IP address and port. 423 This attack can be prevented by using STUN long-term credential 424 mechanism or STUN Extension for Third-Party Authorization [RFC7635] 425 or (D)TLS connection between the TURN client and the TURN server. 426 With any of those three mechanisms, when the server receives Refresh 427 Request with STUN MOBILITY-TICKET attribute from the client it 428 identifies that it is indeed the same client but with a new IP 429 address and port using the ticket it had previously issued to refresh 430 the allocation. 432 Security considerations described in [RFC5766] are also applicable to 433 this mechanism. 435 7. Acknowledgements 437 Thanks to Alfred Heggestad, Lishitao, Sujing Zhou, Martin Thomson, 438 Emil Ivov, Oleg Moskalenko and Brandon Williams for review and 439 comments. 441 8. References 443 8.1. Normative References 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, 447 DOI 10.17487/RFC2119, March 1997, 448 . 450 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 451 "Transport Layer Security (TLS) Session Resumption without 452 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 453 January 2008, . 455 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 456 (ICE): A Protocol for Network Address Translator (NAT) 457 Traversal for Offer/Answer Protocols", RFC 5245, 458 DOI 10.17487/RFC5245, April 2010, 459 . 461 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 462 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 463 DOI 10.17487/RFC5389, October 2008, 464 . 466 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 467 Relays around NAT (TURN): Relay Extensions to Session 468 Traversal Utilities for NAT (STUN)", RFC 5766, 469 DOI 10.17487/RFC5766, April 2010, 470 . 472 8.2. Informative References 474 [I-D.ietf-mmusic-trickle-ice] 475 Ivov, E., Rescorla, E., and J. Uberti, "Trickle ICE: 476 Incremental Provisioning of Candidates for the Interactive 477 Connectivity Establishment (ICE) Protocol", draft-ietf- 478 mmusic-trickle-ice-02 (work in progress), January 2015. 480 [I-D.uberti-mmusic-nombis] 481 Uberti, J. and J. Lennox, "Improvements to ICE Candidate 482 Nomination", draft-uberti-mmusic-nombis-00 (work in 483 progress), March 2015. 485 [iana-stun] 486 IANA, , "IANA: STUN Attributes", April 2011, 487 . 490 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 491 Code: The Implementation Status Section", RFC 6982, 492 DOI 10.17487/RFC6982, July 2013, 493 . 495 [RFC7635] Reddy, T., Patil, P., Ravindranath, R., and J. Uberti, 496 "Session Traversal Utilities for NAT (STUN) Extension for 497 Third-Party Authorization", RFC 7635, 498 DOI 10.17487/RFC7635, August 2015, 499 . 501 Appendix A. Example ticket construction 503 The TURN server uses two different keys: one 128-bit key for Advance 504 Encryption Standard (AES) in Cipher Block Chaining (CBC) mode 505 (AES_128_CBC) and 256-bit key for HMAC-SHA-256-128 for integrity 506 protection. The ticket can be structured as follows: 508 struct { 509 opaque key_name[16]; 510 opaque iv[16]; 511 opaque state<0..2^16-1>; 512 opaque mac[16]; 513 } ticket; 515 Figure 1: Ticket Format 517 Here, key_name serves to identify a particular set of keys used to 518 protect the ticket. It enables the TURN server to easily recognize 519 tickets it has issued. The key_name should be randomly generated to 520 avoid collisions between servers. One possibility is to generate new 521 random keys and key_name every time the server is started. 523 The TURN state information (self-contained or handle) in 524 encrypted_state is encrypted using 128-bit AES in CBC mode with the 525 given IV. The MAC is calculated using HMAC-SHA-256-128 over key_name 526 (16 octets)and IV (16 octets), followed by the length of the 527 encrypted_state field (2 octets) and its contents (variable length). 529 Authors' Addresses 531 Dan Wing 532 Cisco Systems, Inc. 533 170 West Tasman Drive 534 San Jose, California 95134 535 USA 537 Email: dwing@cisco.com 539 Prashanth Patil 540 Cisco Systems, Inc. 541 Bangalore 542 India 544 Email: praspati@cisco.com 546 Tirumaleswar Reddy 547 Cisco Systems, Inc. 548 Cessna Business Park, Varthur Hobli 549 Sarjapur Marathalli Outer Ring Road 550 Bangalore, Karnataka 560103 551 India 553 Email: tireddy@cisco.com 555 Paal-Erik Martinsen 556 Cisco Systems, Inc. 557 Philip Pedersens vei 22 558 Lysaker, Akershus 1325 559 Norway 561 Email: palmarti@cisco.com