idnits 2.17.1 draft-ietf-ospf-security-extension-manual-keying-05.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 (May 27, 2013) is 3988 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) == Outdated reference: A later version (-10) exists of draft-ietf-karp-crypto-key-table-07 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF Working Group M. Bhatia 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track S. Hartman 5 Expires: November 28, 2013 Painless Security 6 D. Zhang 7 Huawei Technologies co., LTD. 8 A. Lindem 9 Ericsson 10 May 27, 2013 12 Security Extension for OSPFv2 when using Manual Key Management 13 draft-ietf-ospf-security-extension-manual-keying-05 15 Abstract 17 The current OSPFv2 cryptographic authentication mechanism as defined 18 in the OSPF standards is vulnerable to both inter-session and intra- 19 session replay attacks when its uses manual keying. Additionally, 20 the existing cryptographic authentication schemes do not cover the IP 21 header. This omission can be exploited to carry out various types of 22 attacks. 24 This draft proposes changes to the authentication sequence number 25 mechanism that will protect OSPFv2 from both inter-session and intra- 26 session replay attacks when its using manual keys for securing its 27 protocol packets. Additionally, we also describe some changes in the 28 cryptographic hash computation so that we eliminate most attacks that 29 result because OSPFv2 does not protect the IP header. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 28, 2013. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Section . . . . . . . . . . . . . . . . . . . 4 66 1.2. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 4 67 2. Replay Protection using Extended Sequence Numbers . . . . . . 4 68 3. OSPF Packet Extensions . . . . . . . . . . . . . . . . . . . . 5 69 4. OSPF Packet Key Selection . . . . . . . . . . . . . . . . . . 6 70 4.1. Key Selection for Unicast OSPF Packet Transmission . . . . 7 71 4.2. Key Selection for Multicast OSPF Packet Transmission . . . 7 72 4.3. Key Selection for OSPF Packet Reception . . . . . . . . . 8 73 5. Securing the IP header . . . . . . . . . . . . . . . . . . . . 8 74 6. Mitigating Cross-Protocol Attacks . . . . . . . . . . . . . . 9 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 The OSPFv2 cryptographic authentication mechanism as described in 85 [RFC2328] uses per-packet sequence numbers to provide protection 86 against replay attacks. The sequence numbers increase monotonically 87 so that the attempts to replay the stale packets can be thwarted. 88 The sequence number values are maintained as a part of adjacency 89 states. Therefore, if an adjacency is broken down, the associated 90 sequence numbers get reinitialized and the neighbors start all over 91 again. Additionally, the cryptographic authentication mechanism does 92 not specify how to deal with the rollover of a sequence number when 93 its value would wrap. These omissions can be taken advantage of by 94 attackers to implement various replay attacks ([RFC6039]). In order 95 to address these issues, we propose extensions to the authentication 96 sequence number mechanism. Compared with the cryptographic 97 authentication mechanism proposed in [RFC5709], the solution proposed 98 does not impose any more security presumption. 100 The cryptographic authentication as described in [RFC2328] and later 101 updated in [RFC5709] does not include the IP header. This also can 102 be exploited to launch several attacks as the source address in the 103 IP header is no longer protected. The OSPF specification, for 104 broadcast and NBMA (Non-Broadcast Multi-Access Networks), requires 105 the implementations to look at the source address in the IP header to 106 determine the neighbor from witch the packet was received. Changing 107 the IP source address of a packet which can confuse the receiver and 108 can be exploited to produce a number of denial of service attacks 109 [RFC6039]. If the packet is interpreted as coming from a different 110 neighbor, the sequence number received from the neighbor may be 111 updated. This may disrupt communication with the legitimate 112 neighbor. Hello packets may be reflected to cause a neighbor to 113 appear to have one-way communication. Old Database descriptions may 114 be reflected in cases where the per-packet sequence numbers are 115 sufficiently divergent in order to disrupt an adjacency [RFC6863]. 116 This is referred to as the IP layer issue in [RFC6862]. 118 [RFC2328] states that implementations MUST offer keyed MD5 119 authentication. It is likely that this will be deprecated in favor 120 of the stronger algorithms described in [RFC5709] in future 121 deployments [RFC6094]. 123 This draft proposes a few simple changes to the cryptographic 124 authentication mechanism, as currently described in [RFC5709], to 125 prevent such IP layer attacks. 127 1.1. Requirements Section 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 [RFC2119]. 133 When used in lowercase, these words convey their typical use in 134 common language, and are not to be interpreted as described in 135 RFC2119 [RFC2119]. 137 1.2. Acknowledgments 139 Thanks to Ran Atkinson for help in the analysis of RFC 6506 errata 140 leading to clarifications in this document. 142 2. Replay Protection using Extended Sequence Numbers 144 In order to provide replay protection against both inter-session and 145 intra-session replay attacks, the OSPFv2 sequence number is expanded 146 to 64-bits with the least significant 32-bit value containing a 147 strictly increasing sequence number and the most significant 32-bit 148 value containing the boot count. OSPFv2 implementations are required 149 to retain the boot count in non-volatile storage for the deployment 150 life the OSPF router. The requirement to preserve the boot count is 151 also placed on SNMP agents by the SNMPv3 security architecture (refer 152 to snmpEngineBoots in [RFC4222]. 154 Since there is no room in the OSPFv2 packet for a 64-bit sequence 155 number, it will occupy the 8 octets following the OSPFv2 packet and 156 MUST be included when calculating the OSPFv2 packet digest. These 157 additional 8 bytes are not included in the OSPFv2 packet header 158 length but are included in the OSPFv2 header Authentication Data 159 length and the IPv4 packet header length. 161 The lower order 32-bit sequence number MUST be incremented for every 162 OSPF packet sent by the OSPF router. Upon reception, the sequence 163 number MUST be greater than the sequence number in the last OSPF 164 packet of that type accepted from the sending OSPF neighbor. 165 Otherwise, the OSPF packet is considered a replayed packet and 166 dropped. OSPF packets of different types may arrive out of order if 167 they are priorized as recommended in [RFC3414]. 169 OSPF routers implementing this specification MUST use available 170 mechanisms to preserve the sequence number's strictly increasing 171 property for the deployed life of the OSPFv3 router (including cold 172 restarts). This is achieved by maintaining a boot count in non- 173 volatile storage and incrementing it each time the OSPF router loses 174 its prior sequence number state. The SNMPv3 snmpEngineBoots variable 175 [RFC4222] MAY be used for this purpose. However, maintaining a 176 separate boot count solely for OSPF sequence numbers has the 177 advantage of decoupling SNMP reinitialization and OSPF 178 reinitialization. Also, in the rare event that the lower order 32- 179 bit sequence number wraps, the boot count can be incremented to 180 preserve the strictly increasing property of the aggregate sequence 181 number. Hence, a separate OSPF boot count is RECOMMENDED. 183 3. OSPF Packet Extensions 185 The OSPF packet header includes an authentication type field, and 64- 186 bits of data for use by the appropriate authentication scheme 187 (determined by the type field). Authentication types 0, 1 and 2 are 188 defined [RFC2328]. This section of this defines Authentication type 189 TBD (3 is recommended). 191 When using this authentication scheme, the 64-bit Authentication 192 field in the OSPF packet header as defined in section D.3 of 193 [RFC2328] is changed as shown below. The sequence number is removed 194 and the Key ID is extended to 32 bits and moved to the former 195 position of the sequence number. 197 Additionally, the 64-bit sequence number is moved to the first 64- 198 bits following the OSPFv2 packet and is protected by the 199 authentication digest. These additional 64 bits or 8 octets are 200 included in the IP header length but not the OSPF header packet 201 length. 203 0 1 2 3 204 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Version # | Type | Packet length | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Router ID | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Area ID | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Checksum | AuType | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | 0 | Auth Data Len | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Key ID | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | | 219 | OSPF Protocol Packet | 220 ~ ~ 221 | | 222 | | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Sequence Number (Boot Count) | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Sequence Number (Strictly Increasing Packet Counter) | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | | 229 ~ Authentication Data ~ 230 | | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Figure 7 - Extended Sequence Number Packet Extensions 235 4. OSPF Packet Key Selection 237 This section describes how the proposed security solution selects 238 long-lived keys from key tables. [I-D.ietf-karp-crypto-key-table]. 239 Generally, a key used for OSPFv2 packet authentication should satisfy 240 the following requirements: 242 o For packet transmission, the key validity interval as defined by 243 SendLifeTimeStart and SendLifeTimeEnd must include the current 244 time. 246 o For packet reception, the key validity interval as defined by 247 AcceptLifeTimeStart and AcceptLifeTimeEnd must include the current 248 time. 250 o The key can be used for the desired security algorithm. 252 In the remainder of this section, additional requirements for keys 253 are enumerated for different scenarios. 255 4.1. Key Selection for Unicast OSPF Packet Transmission 257 Assume that a router R1 tries to send a unicast OSPF packet from its 258 interface I1 to the interface R2 of a remote router R2 using security 259 protocol P via interface I at time T. First, consider the 260 circumstances where R1 and R2 are not connected with a virtual link. 261 R1 then needs to select a long long-lived symmetric key from its key 262 table. Because the key should be shared by the by both R1 and R2 to 263 protect the communication between I1 and I2, the key should satisfy 264 the following requirements: 266 o The Peers field is unused. OSPF authentiction is interface based. 268 o The Interfaces field includes the local IP address of the 269 interface for nummbered interfaces or the MIB-II [RFC1213], 270 ifIndex for unnumbered interfaces. 272 o The Direction field is either "out" or "both". 274 When R1 and R2 are connected to a virtual link, the interfaces field 275 must identify the virtual endpoint rather than the virtual link. 276 Since there may be virtual links to the same router, the transit area 277 ID must be part of the identifier. Hence, the key should satisfy the 278 following requirements: 280 o The Peers field is unused. OSPF authentiction is interface based. 282 o The Interfaces field includes both the virtual endpoint's OSPF 283 router ID and the the transit area ID for the virtual link. 285 o The Direction field is either "out" or "both". 287 4.2. Key Selection for Multicast OSPF Packet Transmission 289 If a router R1 sends an OSPF packet from its interface I1 to a 290 multicast address (e.g., AllSPFRouters, AllDRouters), it needs to 291 select a key according to the following requirements: 293 o The Peers field is unused. OSPF authentication is interface 294 based. 296 o The Interfaces field includes the local IP address of the 297 interface for nummbered interfaces or the MIB-II [RFC1213], 298 ifIndex for unnumbered interfaces. 300 o The Direction field is either "out" or "both". 302 4.3. Key Selection for OSPF Packet Reception 304 When Cryptographic Authentication is used, the ID of the 305 authentication key is included in the authentication field of the 306 OSPF packet header. Using this key ID, it is relatively easy for a 307 receiver to locate the key. The simple requirements are: 309 o The interface on which the key was received is associated with the 310 key's interface. 312 o The PeerKeyName field includes the key ID obtained from the 313 authentication field. Since OSPF keys are symmetric, the 314 LocalKeyName and PeerKeyName for OSPF keys will be identical. 316 o The Direction field is either "in" or "both". 318 5. Securing the IP header 320 This document updates the definition of Apad which is currently a 321 constant defined in [RFC5709] to the source address from the IP 322 header of the OSPFv2 protocol packet. The overall cryptographic 323 authentication process defined in [RFC5709] remains unchanged. To 324 reduce the potential for confusion, this section minimizes the 325 repetition of text from RFC 5709 and is incorporated here by 326 reference [RFC5709]. 328 RFC 5709, Section 3.3, describes how the cryptographic authentication 329 must be computed. It requires OSPFv2 packet's Authentication Trailer 330 (which is the appendage described in RFC 2328, Section D.4.3, Page 331 233, items (6)(a) and (6)(d)) to be filled with the value Apad where 332 Apad is a hexadecimal constant value 0x878FE1F3 repeated (L/4) times, 333 where L is the length of the hash being used and is measured in 334 octets rather than bits. 336 Routers at the sending side must initialize Apad to a value of the 337 source address that would be used when sending out the OSPFv2 packet, 338 repeated L/4 times, where L is the length of the hash, measured in 339 octets. The basic idea is to incorporate the source address from the 340 IP header in the cryptographic authentication computation so that any 341 change of IP source address in a replayed packet can be detected. 343 At the receiving end, implementations MUST initialize Apad as the 344 source address from IP Header of the incoming OSPFv2 packet, repeated 345 L/4 times, instead of the constant that's currently defined in 346 [RFC5709]. Besides changing the value of Apad, this document does 347 not introduce any other changes to the authentication mechanism 348 described in [RFC5709]. This would prevent all attacks where a rogue 349 OSPF router changes the IP source address of an OSPFv2 packet and 350 replays it on the same multi-access interface or another interface 351 since the IP source address is now protected and such changes would 352 cause the authentication check to fail and the replayed packet to be 353 rejected. 355 6. Mitigating Cross-Protocol Attacks 357 In order to prevent cross protocol replay attacks for protocols 358 sharing common keys, the two octet OSPFv2 Cryptographic Protocol ID 359 is appended to the authentication key prior to use. Refer to IANA 360 Considerations (Section 8). 362 [RFC5709], Section 3.3 describes the mechanism to prepare the key 363 used in the hash computation. This document updates the sub section 364 "PREPARATION OF KEY" as follows: 366 The OSPFv2 Cryptographic Protocol ID is appended to the 367 Authentication Key (K) yielding a Protocol-Specific Authentication 368 Key (Ks). In this application, Ko is always L octets long. While 369 [RFC2104] supports a key that is up to B octets long, this 370 application uses L as the Ks length consistent with [RFC4822], 371 [RFC5310], and [RFC5709]. According to [FIPS-198], Section 3, keys 372 greater than L octets do not significantly increase the function 373 strength. Ks is computed as follows: 375 If the Protocol-Specific Authentication Key (Ks) is L octets long, 376 then Ko is equal to Ks. If the Protocol-Specific Authentication Key 377 (Ks) is more than L octets long, then Ko is set to H(Ks). If the 378 Protocol-Specific Authentication Key (Ks) is less than L octets long, 379 then Ko is set to the Protocol-Specific Authentication Key (Ks) with 380 zeros appended to the end of the Protocol-Specific Authentication Key 381 (Ks) such that Ko is L octets long. 383 Once the cryptographic key (Ko) used with the hash algorithm is 384 derived the rest of the authentication mechanism described in 385 [RFC5709] remains unchanged other than one detail that was 386 unspecified. When XORing Ko and Ipad of Opad, Ko MUST be padded with 387 zeros to the length of Ipad or Opad. It is expected that RFC 5709 388 [RFC5709] implementation perform this padding implicitly. 390 7. Security Considerations 392 This document attempts to fix the manual key management procedure 393 that currently exists within OSPFv2, as part of the Phase 1 of the 394 KARP Working Group. Therefore, only the OSPFv2 manual key management 395 mechanism is considered. Any solution that takes advantage of the 396 automatic key management mechanism is beyond the scope of this 397 document. 399 The proposed sequence number extension offers most of the benefits of 400 of more complicated mechanisms involving challenges. There are, 401 however, a couple drawbacks to this approach. First, it requires the 402 OSPF implementation to be able to save its boot count in non-volatile 403 storage. If the non-volatile storage is ever repaired or upgraded 404 such that the contents are lost or the OSPFv2 router is replaced with 405 a model, the keys MUST be changed to prevent replay attacks. 407 Second, if a router is taken out of service completely (either 408 intentionally or due to a persistent failure), the potential exists 409 for reestablishment of an OSPFv2 adjacency by replaying the entire 410 OSPFv2 session establishment. This scenario is however, extremely 411 unlikely, since it would imply an identical OSPFv2 adjacency 412 formation packet exchange. The replay of OSPFv2 hello packets alone 413 for an OSPFv2 router that has been taken out of service should not 414 result in any serious attack as the only consequence is superfluous 415 processing. Of course, this attack could also be thwarted by 416 changing the relevant manual keys. 418 This document also provides a solution to prevent certain denial of 419 service attacks that can be launched by changing the source address 420 in the IP header of the OSPFv2 protocol packet. 422 8. IANA Considerations 424 This document requests a new code point from the "OSPF Shortest Path 425 First (OSPF) Authentication Codes" registry: 427 o 3 - Cryptographic Authentication with Extended Sequence Numbers. 429 This document also requests a new code point from the "Authentication 430 Cryptographic Protocol ID" registry defined under "Keying and 431 Authentication for Routing Protocols (KARP) Parameters": 433 o 2 - OSPFv2. 435 9. References 436 9.1. Normative References 438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 439 Requirement Levels", BCP 14, RFC 2119, March 1997. 441 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 443 [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., 444 Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic 445 Authentication", RFC 5709, October 2009. 447 9.2. Informative References 449 [FIPS-198] 450 US National Institute of Standards & Technology, "The 451 Keyed-Hash Message Authentication Code (HMAC)", FIPS PUB 452 198 , March 2002. 454 [I-D.ietf-karp-crypto-key-table] 455 Housley, R., Polk, T., Hartman, S., and D. Zhang, 456 "Database of Long-Lived Symmetric Cryptographic Keys", 457 draft-ietf-karp-crypto-key-table-07 (work in progress), 458 March 2013. 460 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 461 for Network Management of TCP/IP-based internets:MIB-II", 462 STD 17, RFC 1213, March 1991. 464 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 465 Hashing for Message Authentication", RFC 2104, 466 February 1997. 468 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 469 (USM) for version 3 of the Simple Network Management 470 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 472 [RFC4222] Choudhury, G., "Prioritized Treatment of Specific OSPF 473 Version 2 Packets and Congestion Avoidance", BCP 112, 474 RFC 4222, October 2005. 476 [RFC4822] Atkinson, R. and M. Fanto, "RIPv2 Cryptographic 477 Authentication", RFC 4822, February 2007. 479 [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., 480 and M. Fanto, "IS-IS Generic Cryptographic 481 Authentication", RFC 5310, February 2009. 483 [RFC6039] Manral, V., Bhatia, M., Jaeggli, J., and R. White, "Issues 484 with Existing Cryptographic Protection Methods for Routing 485 Protocols", RFC 6039, October 2010. 487 [RFC6094] Bhatia, M. and V. Manral, "Summary of Cryptographic 488 Authentication Algorithm Implementation Requirements for 489 Routing Protocols", RFC 6094, February 2011. 491 [RFC6862] Lebovitz, G., Bhatia, M., and B. Weis, "Keying and 492 Authentication for Routing Protocols (KARP) Overview, 493 Threats, and Requirements", RFC 6862, March 2013. 495 [RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security 496 According to the Keying and Authentication for Routing 497 Protocols (KARP) Design Guide", RFC 6863, March 2013. 499 Authors' Addresses 501 Manav Bhatia 502 Alcatel-Lucent 503 Bangalore, 504 India 506 Phone: 507 Email: manav.bhatia@alcatel-lucent.com 509 Sam Hartman 510 Painless Security 512 Email: hartmans@painless-security.com 514 Dacheng Zhang 515 Huawei Technologies co., LTD. 516 Beijing, 517 China 519 Phone: 520 Fax: 521 Email: zhangdacheng@huawei.com 522 URI: 524 Acee Lindem 525 Ericsson 526 102 Carric Bend Court 527 Cary, NC 27519 528 USA 530 Phone: 531 Email: acee.lindem@ericsson.com