idnits 2.17.1 draft-ietf-dime-ikev2-psk-diameter-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5778]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5134 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) == Missing Reference: 'RFC 5778' is mentioned on line 130, but not defined == Unused Reference: 'RFC3748' is defined on line 509, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-dime-local-keytran-01 ** Obsolete normative reference: RFC 3588 (Obsoleted by RFC 6733) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Cakulev 3 Internet-Draft Alcatel Lucent 4 Intended status: Standards Track A. Lior 5 Expires: September 9, 2010 Bridgewater Systems 6 March 8, 2010 8 Diameter IKEv2 PSK: Pre-Shared Secret-based Support for IKEv2 Server to 9 Diameter Server Interaction 10 draft-ietf-dime-ikev2-psk-diameter-02.txt 12 Abstract 14 The Internet Key Exchange protocol version 2 (IKEv2) is a component 15 of the IPsec architecture and is used to perform mutual 16 authentication as well as to establish and to maintain IPsec security 17 associations (SAs) between the respective parties. IKEv2 supports 18 several different authentication mechanisms, such as the Extensible 19 Authentication Protocol (EAP), certificates, and pre-shared secrets. 21 With [RFC 5778] the Diameter interworking for Mobile IPv6 between the 22 Home Agent, as a Diameter client, and the Diameter server has been 23 specified. However, that specification focused on the usage of EAP 24 and did not include support for pre-shared secret based 25 authentication available with IKEv2. This document therefore extends 26 the functionality offered by [RFC 5778] with pre-shared key based 27 authentication offered by IKEv2 when no EAP is used. 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on September 9, 2010. 52 Copyright Notice 54 Copyright (c) 2010 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the BSD License. 67 This document may contain material from IETF Documents or IETF 68 Contributions published or made publicly available before November 69 10, 2008. The person(s) controlling the copyright in some of this 70 material may not have granted the IETF Trust the right to allow 71 modifications of such material outside the IETF Standards Process. 72 Without obtaining an adequate license from the person(s) controlling 73 the copyright in such materials, this document may not be modified 74 outside the IETF Standards Process, and derivative works of it may 75 not be created outside the IETF Standards Process, except to format 76 it for publication as an RFC or to translate it into languages other 77 than English. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 82 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 5 83 3. Application Identifier . . . . . . . . . . . . . . . . . . . . 6 84 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 7 85 4.1. Support for IKEv2 and Pre-Shared Secrets . . . . . . . . . 7 86 4.2. Session Management . . . . . . . . . . . . . . . . . . . . 7 87 4.2.1. Session-Termination-Request/Answer . . . . . . . . . . 8 88 4.2.2. AbortSession-Request/Answer . . . . . . . . . . . . . 8 89 5. Command Codes for Diameter IKEv2 with PSK . . . . . . . . . . 9 90 5.1. IKEv2-PSK-Request (IKEPSKR) Command . . . . . . . . . . . 9 91 5.2. IKEv2-PSK-Answer (IKEPSKA) Command . . . . . . . . . . . . 10 92 6. Attribute Value Pair Definitions . . . . . . . . . . . . . . . 11 93 6.1. IKEv2-Nonces . . . . . . . . . . . . . . . . . . . . . . . 11 94 6.1.1. Ni . . . . . . . . . . . . . . . . . . . . . . . . . . 11 95 6.1.2. Nr . . . . . . . . . . . . . . . . . . . . . . . . . . 11 96 7. AVP Occurrence Tables . . . . . . . . . . . . . . . . . . . . 12 97 8. AVP Flag Rules . . . . . . . . . . . . . . . . . . . . . . . . 13 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 99 9.1. Command Codes . . . . . . . . . . . . . . . . . . . . . . 14 100 9.2. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 14 101 9.3. AVP Values . . . . . . . . . . . . . . . . . . . . . . . . 14 102 9.4. Application Identifier . . . . . . . . . . . . . . . . . . 14 103 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 105 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16 106 11.2. Informative References . . . . . . . . . . . . . . . . . . 16 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 109 1. Introduction 111 [RFC4306] defines Internet Key Exchange v2 as a protocol that 112 performs mutual authentication between two parties and establishes a 113 security association (SA) that includes shared secret information 114 that can be used to efficiently establish SAs for Encapsulating 115 Security Payload (ESP) [RFC4303] and/or Authentication Header (AH) 116 [RFC4302], and a set of cryptographic algorithms to be used by the 117 SAs to protect the traffic that they carry. IKEv2 protocol allows 118 several different mechanisms for authenticating a IKEv2 Peer to be 119 used, such as the Extensible Authentication Protocol, certificates, 120 and pre-shared secrets. 122 From a service provider perspective it is important to ensure that a 123 user is authorized to use the services. Therefore, the IKEv2 Server 124 must verify that the IKEv2 Peer is authorized for the requested 125 services possibly with the assistance of the operator's Diameter 126 servers. [RFC 5778] defines the home agent as a Diameter client to 127 the Diameter server communication when the mobile node authenticates 128 using the IKEv2 protocol with the Extensible Authentication Protocol 129 or using the Mobile IPv6 Authentication Protocol. This document 130 extends the functionality offered by [RFC 5778] with pre-shared key 131 based authentication offered by IKEv2. This document does not assume 132 that the IKEv2 Server has the pre-shared secrets (PSK) with the IKEv2 133 Peer. Instead, it allows for PSK to be derived for a specific IKEv2 134 session and exchanged between IKEv2 Server and HAAA. This is 135 accomplished through the use of a new Diameter application 136 specifically designed for performing IKEv2 authorization decisions. 138 2. Requirements notation 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 3. Application Identifier 146 This specification defines a new Diameter application and its 147 respective Application Identifier: 149 Diameter IKE PSK (IKEPSK) TBD1 by IANA 151 The IKEPSK Application Identifier is used when the IKEv2 Peer is to 152 be authenticated and authorized using IKEv2 with PSK-based 153 authentication. 155 4. Protocol Description 157 4.1. Support for IKEv2 and Pre-Shared Secrets 159 When IKEv2 is used with PSK-based initiator authentication, the 160 Diameter commands IKEv2-PSK-Request and IKEv2-PSK-Answer defined in 161 this document are used to authorize the IKEv2 Peer for the services. 162 Upon receiving the IKE_AUTH message from the IKEv2 Peer, the IKEv2 163 Server uses the information received in IDi to determine if it has 164 the PSK for this IKEv2 Peer. If there is no PSK found associated 165 with this IKEv2 Peer, the IKEv2 Server MUST send an Authorize-Only 166 (Auth-Request-Type set to "Authorize-Only") Diameter IKEv2-PSK 167 message with the IKEv2 Peer's IDi payload to the HAAA to obtain the 168 PSK. The IDi payload extracted from the IKE_AUTH message has to 169 contain an identity that is meaningful for the Diameter 170 infrastructure, such as a Network Access Identifier (NAI), since it 171 is used by the IKEv2 Server to populate the User-Name AVP in the 172 Diameter message. The IKEv2 Server also includes in the IKEv2-Nonces 173 AVP of the same Diameter message the initiator and responder nonces 174 (Ni and Nr) exchanged during initial IKEv2 exchange. 176 This message is routed to the IKEv2 Peer's HAAA. Upon receiving 177 Diameter IKEv2-PSK-Request message from the IKEv2 Server, the HAAA 178 SHALL use the User-Name AVP to retrieve the associated keying 179 material. The HAAA SHALL use the nonces Ni and Nr received in IKEv2- 180 Nonces AVP to generate the PSK. It is outside of scope of this 181 document how the HAAA obtains or generates the PSK. For example, if 182 the HAAA previously performed EAP based access authentication and 183 authorization of the IKEv2 Peer, it can use the available EMSK to 184 generate the PSK [RFC5295]. The HAAA returns the PSK to the IKEv2 185 Server using the Key AVP as specified in 186 [I-D.ietf-dime-local-keytran]. 188 Once the IKEv2 Server receives the PSK from the HAAA, the IKEv2 189 Server verifies the IKE_AUTH message received from the IKEv2 Peer. 190 If the verification of AUTH is successful, the IKEv2 Server sends the 191 IKE message back to the IKEv2 Peer. 193 4.2. Session Management 195 The HAAA may maintain state or may be stateless. This is indicated 196 by presence or absence of the Auth-Session-State AVP. The IKEv2 197 Server MUST support the Authorization Session State Machine defined 198 in [RFC3588]. 200 This specification makes an assumption that each IKE_SA created 201 between the IKEv2 Peer and the IKEv2 Server as a result of a 202 successful IKEv2 negotiation exchange together with CHILD_SAs set up 203 through that particular IKE_SA correspond to one currently active PSK 204 and one active Diameter session. 206 4.2.1. Session-Termination-Request/Answer 208 In the case where session tracking is being used, when the IKEv2 209 Server terminates the SA it SHALL send a Session-Termination-Request 210 (STR) message [RFC3588] to inform the HAAA that the authorized 211 session has been terminated. 213 The Session-Termination-Answer (STA) message [RFC3588] is sent by the 214 HAAA to acknowledge the notification that the session has been 215 terminated. 217 4.2.2. AbortSession-Request/Answer 219 The Abort-Session-Request (ASR) message [RFC3588] is sent by the HAAA 220 to the IKEv2 Server to terminate the authorized session. When the 221 IKEv2 Server receives the ASR message, it MUST delete the 222 corresponding IKE_SA and all CHILD_SAs set up through it. 224 The Abort-Session-Answer (ASA) message [RFC3588] is sent by the IKEv2 225 Server in response to an ASR message. 227 5. Command Codes for Diameter IKEv2 with PSK 229 This section defines new Command-Code values that MUST be supported 230 by all Diameter implementations conforming to this specification. 232 +-------------------+---------+------+-------------+-------------+ 233 | Command-Name | Abbrev. | Code | Reference | Application | 234 +-------------------+---------+------+-------------+-------------+ 235 | IKEv2-PSK-Request | IKEPSKR | TBD2 | Section 5.1 | IKEPSK | 236 | | | | | | 237 | IKEv2-PSK-Answer | IKEPSKA | TBD3 | Section 5.2 | IKEPSK | 238 +-------------------+---------+------+-------------+-------------+ 240 Table 1: Command Codes 242 5.1. IKEv2-PSK-Request (IKEPSKR) Command 244 The IKEv2-PSK-Request message, indicated with the Command-Code set to 245 TBD2 and the 'R' bit set in the Command Flags field is sent from the 246 IKEv2 Server to the HAAA to initiate IKEv2 with PSK authorization. 247 In this case, the Application-ID field of the Diameter Header MUST be 248 set to the Diameter IKE PSK Application ID (value of TDB1). 250 Message format 252 ::= < Diameter Header: TBD2, REQ, PXY > 253 < Session-Id > 254 { Auth-Application-Id } 255 { Origin-Host } 256 { Origin-Realm } 257 { Destination-Realm } 258 { Auth-Request-Type } 259 [ Destination-Host ] 260 [ NAS-Identifier ] 261 [ NAS-IP-Address ] 262 [ NAS-IPv6-Address ] 263 [ NAS-Port ] 264 [ Origin-State-Id ] 265 { User-Name } 266 [ Auth-Session-State ] 267 { IKEv2-Nonces } 268 * [ Proxy-Info ] 269 * [ Route-Record ] 270 ... 271 * [ AVP ] 273 IKEv2-PSK-Request message MUST include a IKEv2-Nonces AVP containing 274 Ni and Nr nonces exchanged during initial IKEv2 exchange. 276 5.2. IKEv2-PSK-Answer (IKEPSKA) Command 278 The IKEv2-PSK-Answer (IKEPSKA) message, indicated by the Command-Code 279 field set to TBD3 and the 'R' bit cleared in the Command Flags field, 280 is sent by the HAAA to the IKEv2 Server in response to the IKEPSKR 281 command. In this case, the Application-ID field of the Diameter 282 Header MUST be set to the Diameter IKE PSK Application ID (value of 283 TDB1). 285 Message format 287 ::= < Diameter Header: TBD3, PXY > 288 < Session-Id > 289 { Auth-Application-Id } 290 { Auth-Request-Type } 291 { Result-Code } 292 { Origin-Host } 293 { Origin-Realm } 294 [ User-Name ] 295 [ Key ] 296 [ Error-Message ] 297 [ Error-Reporting-Host ] 298 * [ Failed-AVP ] 299 [ Origin-State-Id ] 300 * [ Redirect-Host ] 301 [ Redirect-Host-Usage ] 302 [ Redirect-Max-Cache-Time ] 303 * [ Proxy-Info ] 304 * [ Route-Record ] 305 ... 306 * [ AVP ] 308 If the authorization procedure was successful then the IKEv2-PSK- 309 Answer message SHALL include the Key AVP as specified in 310 [I-D.ietf-dime-local-keytran]. The value of the Key-Type AVP SHALL 311 be set to TBD4. The Keying-Material AVP SHALL contain the PSK. 312 Exactly how the PSK is derived is beyond the scope of this document. 313 The Key-Lifetime AVP may be included and if it is included then the 314 associated key shall not be used if the lifetime has expired. 316 6. Attribute Value Pair Definitions 318 This section defines new AVPs for the IKEv2 with PSK. 320 6.1. IKEv2-Nonces 322 The IKEv2-Nonces AVP (Code TBD5) is of type Grouped and contains the 323 nonces exchanged between the IKEv2 Peer and the IKEv2 Server during 324 IKEv2 initial exchange. The nonces are used for PSK generation. 326 IKEv2-Nonces ::= < AVP Header: TBD5> 327 {Ni} 328 {Nr} 329 *[AVP] 331 6.1.1. Ni 333 The Ni AVP (AVP Code TBD6) is of type Unsigned32 and contains the 334 IKEv2 initiator nonce. 336 6.1.2. Nr 338 The Nr AVP (AVP Code TBD7) is of type Unsigned32 and contains the 339 IKEv2 responder nonce. 341 7. AVP Occurrence Tables 343 The following tables present the AVPs defined or used in this 344 document and their occurrences in Diameter messages. Note that AVPs 345 that can only be present within a Grouped AVP are not represented in 346 this table. 348 The table uses the following symbols: 350 0: 352 The AVP MUST NOT be present in the message. 354 0+: 356 Zero or more instances of the AVP MAY be present in the message. 358 0-1: 360 Zero or one instance of the AVP MAY be present in the message. 362 1: 364 One instance of the AVP MUST be present in the message. 366 +-------------------+ 367 | Command-Code | 368 |---------+---------+ 369 AVP Name | IKEPSKR | IKEPSKA | 370 -------------------------------|---------+---------+ 371 Key | 0-1 | 0-1 | 372 IKEv2-Nonces | 0-1 | 0 | 373 +---------+---------+ 375 IKEPSKR and IKEPSKA Commands AVP Table 377 8. AVP Flag Rules 379 The following table describes the Diameter AVPs, their AVP Code 380 values, types, possible flag values, and whether the AVP MAY be 381 encrypted. The Diameter base [RFC3588] specifies the AVP Flag rules 382 for AVPs in Section 4.5. 384 +--------------------+ 385 | AVP Flag rules | 386 +----+---+------+----+----+ 387 AVP Defined | | |SHOULD|MUST|MAY | 388 Attribute Name Code in Value Type |MUST|MAY| NOT | NOT|Encr| 389 +-------------------------------------------+----+---+------+----+----+ 390 |Key TBD Note 1 Grouped | M | P | | V | Y | 391 +-------------------------------------------+----+---+------+----+----+ 392 |Keying-Material TBD Note 1 OctetString| M | P | | V | Y | 393 +-------------------------------------------+----+---+------+----+----+ 394 |Key-Lifetime TBD Note 1 Integer64 | M | P | | V | Y | 395 +-------------------------------------------+----+---+------+----+----+ 396 |Key-SPI TBD Note 1 Unsigned32 | M | P | | V | Y | 397 +-------------------------------------------+----+---+------+----+----+ 398 |Key-Type TBD Note 1 Enumerated | M | P | | V | Y | 399 +-------------------------------------------+----+---+------+----+----+ 400 |Key-Name TBD Note 1 OctetString| M | P | | V | Y | 401 +-------------------------------------------+----+---+------+----+----+ 402 |IKEv2-Nonces TBD5 6.2 Grouped | M | P | | V | Y | 403 +-------------------------------------------+----+---+------+----+----+ 404 |Ni TBD6 6.2.1 Unsigned32 | M | P | | V | Y | 405 +-------------------------------------------+----+---+------+----+----+ 406 |Nr TBD7 6.2.2 Unsigned32 | M | P | | V | Y | 407 +-------------------------------------------+----+---+------+----+----+ 409 AVP Flag Rules Table 411 Note 1: Key, Keying-Material, Key-Type, Key-SPI, Key-Name and Key- 412 Lifetime AVPs are defined in [I-D.ietf-dime-local-keytran]. 414 9. IANA Considerations 416 This section contains the namespaces that have either been created in 417 this specification or had their values assigned to existing 418 namespaces managed by IANA. 420 9.1. Command Codes 422 IANA is requested to allocate a command code value for the IKEv2-PSK- 423 Request message (IKEPSKR) and for the IKEv2-PSK-Answer message 424 (IKEPSKA) from the Command Code namespace defined in [RFC3588]. See 425 Section 5 for the assignment of the namespace in this specification. 427 9.2. AVP Codes 429 This specification requires IANA to register the following new AVPs 430 from the AVP Code namespace defined in [RFC3588]. 432 o IKEv2-Nonces 434 o Ni 436 o Nr 438 The AVPs are defined in Section 6. 440 9.3. AVP Values 442 IANA is requested to create a new value for the Key-Type AVP. The 443 new value TBD4 signifies that IKEv2 PSK is being sent. 445 9.4. Application Identifier 447 This specification requires IANA to allocate one new value "Diameter 448 IKE PSK" from the Application Identifier namespace defined in 449 [RFC3588]. 451 Application Identifier | Value 452 -------------------------------+------ 453 Diameter IKE PSK (IKEPSK) | TBD1 455 10. Security Considerations 457 The security considerations of the Diameter Base protocol [RFC3588] 458 are applicable to this document. 460 The Diameter messages between the IKEv2 Server and the HAAA may be 461 transported via one or more AAA brokers or Diameter agents. In this 462 case, the HA to the Diameter server AAA communication relies on the 463 security properties of the intermediating AAA inter-connection 464 networks, AAA brokers, and Diameter agents. Furthermore, any agents 465 that process IKEv2-PSK-Answer messages can see the contents of the 466 Master-Security-Association AVP. For this reason, this specification 467 strongly recommends avoiding Diameter agents when they cannot be 468 trusted to keep the keys secret. 470 This specification expects that the HAAA derives and returns the 471 associated session key to the IKEv2 Server. For the key derivation 472 this specification recommends the use of a short lived secrets, 473 possibly based on a previous network access authentication run if 474 such secrets are available. To ensure key freshness, limit the key 475 scope etc., this specification also recommends the use of nonces, if 476 nonces are included in IKEv2-PSK-Request. However, this 477 specification does not define how the Diameter server actually 478 derives required keys. The details of the key derivation depends on 479 the deployment where this specification is used and therefore the 480 security properties of the system depend on how this is done. 482 11. References 484 11.1. Normative References 486 [I-D.ietf-dime-local-keytran] 487 Wu, W. and G. Zorn, "Diameter Attribute-Value Pairs for 488 Cryptographic Key Transport", 489 draft-ietf-dime-local-keytran-01 (work in progress), 490 January 2010. 492 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 493 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 495 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 496 December 2005. 498 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 499 RFC 4303, December 2005. 501 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 502 RFC 4306, December 2005. 504 11.2. Informative References 506 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 507 Requirement Levels", BCP 14, RFC 2119, March 1997. 509 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 510 Levkowetz, "Extensible Authentication Protocol (EAP)", 511 RFC 3748, June 2004. 513 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 514 "Specification for the Derivation of Root Keys from an 515 Extended Master Session Key (EMSK)", RFC 5295, 516 August 2008. 518 Authors' Addresses 520 Violeta Cakulev 521 Alcatel Lucent 522 600 Mountain Ave. 523 3D-517 524 Murray Hill, NJ 07974 525 US 527 Phone: +1 908 582 3207 528 Email: violeta.cakulev@alcatel-lucent.com 530 Avi Lior 531 Bridgewater Systems 532 303 Terry Fox Drive 533 Otawa, Ontario K2K 3J1 534 Canada 536 Phone: +1 613-591-6655 537 Email: avi@bridgewatersystems.com