idnits 2.17.1 draft-daley-mpsec-traffic-sel-ps-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2009) is 5297 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) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-10) exists of draft-ietf-ipsecme-roadmap-01 -- Obsolete informational reference (is this intentional?): RFC 2407 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Daley 3 Internet-Draft NetStar Networks 4 Intended status: Standards Track S. Delord 5 Expires: April 29, 2010 R. Key 6 Telstra 7 S. Krishnan 8 Ericsson 9 October 26, 2009 11 Guidelines for Multiprotocol Traffic Selector Bindings in IPsec 12 draft-daley-mpsec-traffic-sel-ps-01.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 29, 2010. 37 Copyright Notice 39 Copyright (c) 2009 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents in effect on the date of 44 publication of this document (http://trustee.ietf.org/license-info). 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. 48 Abstract 50 In IPsec, secure connectivity is provided for network layer entities. 51 Traffic Selectors which specify interesting traffic for security 52 association encapsulation are identified only by network and 53 transport layer addressing. 55 This document discusses extending traffic selectors to allow more 56 generic definitions of interesting traffic. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Description and Models . . . . . . . . . . . . . . . . . . . . 3 62 3. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 64 5. Security Policy Database Considerations . . . . . . . . . . . 6 65 6. IKEv2 Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 6.1. Selector Format Considerations . . . . . . . . . . . . . . 7 67 7. IPsec Mode Considerations . . . . . . . . . . . . . . . . . . 7 68 8. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 7 69 9. Discussion of Initiator/Responder Mappings . . . . . . . . . . 8 70 10. External Interface Considerations . . . . . . . . . . . . . . 9 71 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 74 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 14.1. Normative References . . . . . . . . . . . . . . . . . . . 11 76 14.2. Informative References . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 79 1. Introduction 81 IPsec is focused on providing tunnel and transport security for 82 network layer IP traffic based on IP address and port selectors. In 83 some circumstances, endpoints may wish to provide IPsec services 84 based on other distinguishing information from the traffic stream 85 [RFC4301]. 87 This document discusses models, motivations, for multiprotocol 88 bindings for IPsec Traffic Selectors, their use in the Security 89 Policy Database (SPD) and their description within IKEv2 90 [RFC4306][I-D.ietf-ipsecme-roadmap]. 92 2. Description and Models 94 Devices which may prefer to choose extended traffic selector syntax 95 may support non-IP protocols for packet delivery or may have non- 96 Address and port information used in traffic selection for IP layer 97 traffic. 99 Example 1 MPLS Label 101 Where an MPLS label either arrives from an interface, or is used to 102 encapsulate traffic, it may be useful to transport data carried 103 within that label across the network. 105 At this stage, advice is sought on how encapsulation would occur, and 106 whether the communications path connecting A and B would make use of 107 an MPLS label inside the ESP label. 109 Similar to Diffserv in Example 1,the Traffic Class field of the MPLS 110 label stack entry [RFC5462] may be used for traffic selectors. 112 TS: Label A TS: Label B 113 +---------+ +---------+ 114 A | | | | B 115 -------|< - - - >|------------------------------|< - - - >|------- 116 ----> | |=============================>| | ----> 117 +---------+ ESP SA +---------+ 119 Example 2 Ethernet Pseudo Wire 120 For systems which do not contain IP addresses on the traffic side 121 (rather than the carriage side), there is currently no way to specify 122 IPsec connectivity across to a remote device. This may be the case 123 with Pseudo-wires which have shared identifiers, that are known at 124 provisioning time. 126 Allowing data associated with a particular interface group to be 127 encapsulated in protocols such as ESP, would provide a mechanism to 128 deliver secured pseudo wires. 130 wire ID wire ID 131 +---------+ +---------+ 132 | | | | 133 -------|< - - - >|------------------------------|< - - - >|------- 134 ----> | |=============================>| | ----> 135 +---------+ ESP SA +---------+ 137 Example 3 Security Classification Option 139 It is necessary under some security regimes to ensure that traffic of 140 specific security classifications are encrypted before transportation 141 over media of a lower protection value [DSDISMu]. Explicit marking 142 the classifications packets is provided by IPSO in IPv4 [RFC1108] and 143 CALIPSO in IPv6 [RFC5570]. 145 SECRET Level-Max=SECRET Level-Max=SECRET SECRET 146 Network Level-Min=CONFIDENTIAL Level-Min=CONFIDENTIAL Network 147 +---------+ +---------+ 148 | | | | 149 -------|< - - - >|------------------------------|< - - - >|------- 150 ----> | |=============================>| | ----> 151 +---------+ ESP SA +---------+ 152 RESTRICTED Network 154 Use of classification levels in traffic selectors 156 The figure above shows the interconnection of two SECRET classified 157 networks over a lower security medium, using a negotiated encrypted 158 tunnel. It shows transmission of data classified in a range between 159 CLASSIFIED and SECRET, as shown within the Classification Level field 160 of the IPSO basic security option [RFC1108]. 162 Use of the explicit labelling may provide a natural control point for 163 the encapsulation of data onto IPSec tunnels, or in filtering packets 164 arriving from such a tunnel. 166 3. Related work 168 An Informational specification is available which shows how 169 Fiberchannel Addressing can be used for traffic selectors in 170 [RFC4595]. In Section 4.4, it defines TS_FC_ADDR_RANGE, which uses 171 ranges of Fiberchannel addresses where other previously defined 172 methods have used IP addresses. 174 RFC 4595 also specifies transport of ESP (and AH) frames over 175 Fiberchannel encapsulation. Within this document discussion of 176 carriage of IKEv2, ESP and AH over non IP or IP/UDP transport is out- 177 of-scope. 179 Descriptions of challenges and mechanisms for provisioning security 180 on Pseudo-wires are available in [PWESECREQ][PWESEC]. This document 181 takes a different approach to previous pseudo-wire security 182 mechanisms in that it attempts to provide a more general key 183 derivation mechanism for data other than pseudo-wires. Additionally, 184 this document doesn't seek to provide a non-IP carriage for ESP and 185 ESP-like frames, as is the case in [PWESEC]. 187 Ways of identifying security classifications within IKEv2 exchanges 188 are described within [I-D.jml-ipsec-ikev2-security-context]. This 189 mechanism proposes a Security Context Transform, which could instead 190 be expressed within a Traffic-Selector type. 192 It is notable that there exist link-layer encryption mechanisms 193 available via IEEE LAN/MAN 802.1 Working Group [DOT1ae][DOT1XREV]. 194 This work doesn't seek to supplant existing link-layer security 195 mechanisms, but does seek to allow for use of secured transports for 196 non-IP data such as link-layer frames when used within the IPsec 197 framework. 199 4. Applicability 201 This document aims at identifying practices for defining extended 202 traffic selectors. It also explores alternative encoding mechanisms 203 and their impact on policy expression in IKEv2. 205 This document does not define encapsulation of ESP or AH protocols 206 over any new protocols, and only defines/discusses what may be 207 encapsulated by them. 209 5. Security Policy Database Considerations 211 Security Policy Databases provide expressions of the encryption and 212 authentication policy on IPsec hosts and gateways. SPDs are 213 referenced as part of packet delivery processes in order to match 214 packets either to a constructed SA, or to the key-deriving system 215 (such as IKEv2), based on interesting traffic matches. 217 Databases therefore require an interface for packet processes when 218 transmitting data [USAGIXFRM], configuration interfaces through which 219 to construct policy [RFC4807][IPSECSPOL][SETKEY], and key derivation 220 interfaces to ensure that policy is expressed through to the remote 221 peer during the key exchange. 223 At this stage, specification of inter device communication operations 224 using IKEv2 is necessary if support for extended traffic selectors is 225 to be provided. 227 6. IKEv2 Considerations 229 As a departure from IKE [RFC2407], IKEv2 specifies traffic selectors 230 separate to identifiers [RFC4306], including for IPv4 and IPv6. 232 In order to provide more general mapping for traffic selectors to 233 non-IP sources and destinations, Traffic Selector Type (TS Type) 234 allocation needs to be made. The existing TS Type space is 235 administered by IANA. As of April 2009 there are 230 allocatable 236 values within the space. 238 Along with a selector type allocation the format within IKEv2 and 239 interpretation of each traffic selector require specification. This 240 either requires a specific Traffic Selector option format, or a 241 general format which can express additional classes of information. 243 If a more expressive format were to be used, the syntax of this 244 format could be used for the IPSO, MPLS Labels, or Pseudo-wire 245 interchangeably. An endpoint which could understand the format, but 246 could not support a particular selector could down select or reject 247 the proposal. 249 RFC4807 Specifies an SNMP MIB for IPsec Security Policies [RFC4807]. 250 Within the specification is a mechanism to describe in ASN.1 encoding 251 for IP Address and DSCP based traffic selectors [RFC3289]. Were the 252 same encoding used for IKEv2 as the MIB, new object identifiers would 253 need to be added, but the format would be predetermined. 255 Another alternative is to use an XML Schema, although the mechanism 256 would have to be able to present a single canonical syntax for a 257 specific policy. 259 6.1. Selector Format Considerations 261 IKE Version 2 discusses security association rule ordering issues 262 which arise when one traffic selection expression overlaps with 263 another (selector correlation) [RFC4306]. The decorrelation 264 algorithm provides a means to identify non-overlapping subsets of the 265 selected traffic. 267 Key to being able to express decorrelated selectors is that all 268 fields which may be selected need to be expressed as ranges. 270 As such all selectable subfields within an MPLS Label would require 271 expression as start and end-range values. Similarly, locally 272 significant Pseudo-Wire Identifiers (PWids) make use of two integer 273 based values, a fixed length Group ID and fixed length Pseudo Wire 274 Identfier (PWid) [RFC4447]. 276 Conversely encoded within the LDP formats for Generalized Pseudowire 277 Identifiers have varying length bitstrings with data encoded within 278 them. Similarly, IPSO and CALIPSO have bit fields which are a 279 structured data representation within fixed fields. 281 These systems are not able to express these values easily as a range, 282 which allows for easy decorrelation. 284 7. IPsec Mode Considerations 286 When constructing more elaborate traffic selectors for IKEv2, it is 287 expected that the tunnel mode will be provided for traffic which 288 doesn't travel within IP-layer packets. 290 Traffic selectors for data carried within IP packets may still be 291 carried in Transport Mode, for example if DSCPs are used for 292 selectors. This requires further investigation. 294 8. Backward Compatibility 296 One advantage of IPsec is that traffic descriptors for IPv4 and IPv6 297 are available across the majority of existing implementations. 298 Introduction of multiple subsets of Traffic Selectors which are 299 optional to implement may cause compatibility issues. 301 Security Policy Database entries for IPsec devices support IPv4 and 302 IPv6 traffic selectors. Traffic Selectors are either associated with 303 static Security Associations, or are defined in conjunction with 304 IKEv2 policy [RFC4301][RFC4306]. 306 Where keying and SA configuration are static, it is possible that 307 traffic sent on an SA from a device supporting (and using) extended 308 Traffic Selectors will be rejected upon reception at the far end SA. 309 The reverse case (with legacy implementation ingress and general 310 traffic selector egress) would have equivalent function, with only 311 the intersection of the traffic selectors being allowed through to 312 the remote site. 314 Without an IKEv2 control channel this is not easily remedied. 315 Similar issues regarding persistent differences in configuration are 316 described in [RFC4306]. In the case that IKEv2 is used for key 317 negotiation, a system which supports only IPv4, IPv6 or Fiber Channel 318 Traffic Selectors will not be able to choose a traffic selector from 319 the extended mechanisms. 321 This may lead to Security Associations to fail completely, in 322 conformance to the IKEv2 protocol [RFC4306]. 324 9. Discussion of Initiator/Responder Mappings 326 Existing traffic selectors are for connectionless source and 327 destinations. Assignment of multiple selectors to each of the 328 initiator and responder is appropriate for such traffic. For systems 329 which provide connection oriented point-to-point service, multiple 330 sources and destinations are inappropriate. In such a case, there 331 needs to be a one-to-one mapping between initiator and responder 332 traffic selectors. 334 Expressed in existing IKEv2 syntax, it is not possible to describe 335 within a single CHILD_SA Security Association Initiator and Responder 336 Traffic Selectors elements which are mutually exclusive. 338 For example, if: 340 TSi is the set [ 192.0.2.0/26, 192.0.2.128/26 ] 341 and TSr set is [ 192.0.2.64/26, 192.0.2.192/26 ] 343 It is not possible to express in a single CHILD_SA or IKEv2 which has 344 the properties that only: 346 192.0.2.0/26 ===> 192.0.2.128/26 (A) 347 and 348 192.0.2.64/26 ===> 192.0.2.192/26 (B) 350 while 351 192.0.2.0/26 =/=> 192.0.2.192/26 352 and 353 192.0.2.64/26 =/=> 192.0.2.128/26 355 In order to allow only a single source and destination mapping within 356 IKEv2's syntax, the only way to specify mappings (A) and (B) are via 357 two separate SAs. For point-to-point circuit oriented connections 358 such as pseudo-wires, given RFC 4306 IKEv2 syntax, would require an 359 SA per source, destination pair. 361 As described in Section 4.4.1.2 of RFC4301, the structure of SPDs 362 identified within that system allows for multiple Selector Sets which 363 may be included into a single security association. As discussed 364 within that document, in order to provision selector sets 365 dynamically, changes need to be made within IKEv2. 367 At this stage, provisioning one circuit per SA is described, although 368 it is worth identifying if selector sets are viable under revision of 369 the specification. 371 10. External Interface Considerations 373 Referral of packets to the security policy database is typically 374 undertaken as a forwarding (routing) process in existing networks 375 [RFC4301]. Defining Traffic Selectors with non-IP address components 376 means that a different non-forwarding process may be invoked to refer 377 to the SPD. 379 When the forwarding process accesses the SPD, there is a transform on 380 a received packet which determines whether the traffic is interesting 381 to send over IPsec. This will either invoke the IKEv2 key 382 negotiation process, or assign the data to a security association (as 383 described in Section 2.9 of RFC 4306 [RFC4306]). 385 For forwarding and processes referring to the modified Security 386 Policy Database, there needs to be a mechanism which allows the match 387 new Traffic Selector attributes. This match process would then be 388 used as above, to invoke IKEv2 or to assign data for transmission. 390 If individual mechanisms are defined through the process described 391 below, each Traffic Selector Definition will require specification 392 not only of the type, and its expression within IKEv2, but also the 393 filtering and operational processes required to achieve effective 394 traffic protection [RFC4306]. 396 Depending on the mechanisms defined for expressing extended traffic 397 selectors, a general filtering mechanism may be defined which allows 398 new selection filters to be applied to the SPD, and exchanged over 399 IKEv2 using the Traffic Selector Payload [RFC2819]. The 400 expressibility of the Traffic Selectors must then be matched by the 401 filter mechanism, and map from the presented packet information to a 402 PROTECT operation [RFC4301]. 404 Existing interfaces between the Security Policy Database and the key 405 management process make implicit assumptions that the Traffic 406 Selectors are IP addresses [RFC2367]. Modifications to such 407 mechanisms may need to occur before existing APIs may be used with 408 new traffic selectors. 410 11. IANA Considerations 412 No new formats or messages are defined in this document. 414 In order to allocate a new traffic selector class, it is necessary to 415 receive a traffic selector type allocation from IANA 416 [RFC4306][IANAIKEV2]. This requires Expert Review by an IANA 417 identified resource, who would be able to understand the use case, 418 and whether the allocation should occur. 420 12. Security Considerations 422 Definition of new traffic selectors for non-IP traffic isn't a 423 significant departure from IKEv2's security model. The identity 424 associated with the communications, and the source and destination of 425 the tunnel headers do not change. Only the traffic identified for 426 transport changes. 428 Where non-IP datagrams are exchanged over ESP or AH tunnels, the 429 behavior may be different to IP. When providing connectivity through 430 the IPsec tunnels for physical or link-layer technologies, the tunnel 431 itself may establish alternative paths in the wider topology. 433 Where the tunneled lower layer traffic expands on an existing 434 infrastructure, there is a chance of loop creation. Unless tunnel 435 endpoints deploy mechanisms to prevent loops, data transfer through 436 the tunnel could be used to trivially deny service to devices on the 437 tunnel path, and the networks at either end. 439 Where more complex filter patterns are expressible within the Traffic 440 Selector IKEv2 payload, they may require decoding by an external 441 parser. Where an external parser for a language such as ASN.1 or XML 442 is in use, there are additional interfaces to exploit, and a more 443 complex structure to keep state about. The cost of this additional 444 risk needs to be balanced against the value in expressing more 445 complex policy. 447 13. Acknowledgments 449 Thanks to Dave Thaler for his discussion of Traffic Selector tuples, 450 and to Tero Kivinen and Stephen Kent for their contributions on 451 expression of ranges in traffic selectors. 453 14. References 455 14.1. Normative References 457 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 458 Internet Protocol", RFC 4301, December 2005. 460 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 461 RFC 4306, December 2005. 463 [RFC4807] Baer, M., Charlet, R., Hardaker, W., Story, R., and C. 464 Wang, "IPsec Security Policy Database Configuration MIB", 465 RFC 4807, March 2007. 467 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 468 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 469 Class" Field", RFC 5462, February 2009. 471 14.2. Informative References 473 [IANAIKEV2] 474 IANA, "http://www.iana.org/assignments/ikev2-parameters". 476 [IPSECSPOL] 477 "http://developer.apple.com/documentation/Darwin/ 478 Reference/Manpages/man3/ipsec_set_policy.3.html". 480 [SETKEY] "http://linux.die.net/man/8/setkey". 482 [USAGIXFRM] 483 Kanda, M., Miyazawa, K., and H. Esaki, "IPsec Security 484 Policy Database Configuration MIB, USAGI IPv6 IPsec 485 development for Linux. Applications and the Internet 486 Workshops, 2004. SAINT 2004 Workshops". 488 [DOT1ae] "http://standards.ieee.org/getieee802/download/ 489 802.1AE-2006.pdf". 491 [DOT1XREV] 492 "http://www.ieee802.org/1/pages/802.1x-rev.html". 494 [DSDISMu] "Australian Government Information Security Manual (ISM)", 495 Infosec policy The Australian Government Information and 496 Communications Technology Security Manual, September 2009. 498 [I-D.ietf-ipsecme-roadmap] 499 Frankel, S. and S. Krishnan, "IP Security (IPsec) and 500 Internet Key Exchange (IKE) Document Roadmap", 501 draft-ietf-ipsecme-roadmap-01 (work in progress), 502 March 2009. 504 [I-D.jml-ipsec-ikev2-security-context] 505 Latten, J., Wilson, G., Hallyn, S., and T. Jaeger, 506 "Security Context Addendum to IPsec", 507 draft-jml-ipsec-ikev2-security-context-01 (work in 508 progress), July 2009. 510 [PWESEC] Stein, Y(J)., "Pseudowire Security (PWsec)", 511 draft-stein-pwe3-pwsec-00 (work in progress), 512 October 2006. 514 [PWESECREQ] 515 Stein, Y(J)., "Requirements for PW Security", 516 draft-stein-pwe3-sec-req-01 (work in progress), 517 February 2007. 519 [RFC1108] Kent, S., "U.S", RFC 1108, November 1991. 521 [RFC2819] Waldbusser, S., "Remote Network Monitoring Management 522 Information Base", STD 59, RFC 2819, May 2000. 524 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 525 Management API, Version 2", RFC 2367, July 1998. 527 [RFC2407] Piper, D., "The Internet IP Security Domain of 528 Interpretation for ISAKMP", RFC 2407, November 1998. 530 [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information 531 Base for the Differentiated Services Architecture", 532 RFC 3289, May 2002. 534 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 535 Heron, "Pseudowire Setup and Maintenance Using the Label 536 Distribution Protocol (LDP)", RFC 4447, April 2006. 538 [RFC4595] Maino, F. and D. Black, "Use of IKEv2 in the Fibre Channel 539 Security Association Management Protocol", RFC 4595, 540 July 2006. 542 [RFC5570] StJohns, M., Atkinson, R., and G. Thomas, "Common 543 Architecture Label IPv6 Security Option (CALIPSO)", 544 RFC 5570, July 2009. 546 Authors' Addresses 548 Greg Daley 549 NetStar Australia Pty Ltd 550 Lvl 9/636 St Kilda Rd 551 Melbourne, Victoria 3004 552 Australia 554 Phone: +61 401 772 770 555 Email: gdaley@netstarnetworks.com 557 Simon Delord 558 Telstra 559 242 Exhibition St 560 Melbourne, VIC 3000 561 Australia 563 Email: simon.a.delord@team.telstra.com 565 Raymond Key 566 Telstra 567 242 Exhibition St 568 Melbourne, VIC 3000 569 Australia 571 Email: raymond.key@team.telstra.com 572 Suresh Krishnan 573 Ericsson 574 8400 Decarie Blvd. 575 Town of Mount Royal, QC 576 Canada 578 Phone: +1 514 345 7900 x42871 579 Email: suresh.krishnan@ericsson.com