idnits 2.17.1 draft-muks-dns-message-fragments-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 174: '... MUST maintain a timeout when waitin...' RFC 2119 keyword, line 176: '...essage fragments MUST be able to reass...' RFC 2119 keyword, line 179: '... The client MAY save information abo...' RFC 2119 keyword, line 180: '...If saved, this information MUST have a...' RFC 2119 keyword, line 189: '...sent, the server MUST NOT use DNS mess...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 20, 2015) is 3202 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 339 -- Looks like a reference, but probably isn't: '255' on line 339 == Unused Reference: 'RFC1123' is defined on line 519, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-dnsop-cookies-04 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Sivaraman 3 Internet-Draft Internet Systems Consortium 4 Intended status: Experimental S. Kerr 5 Expires: January 21, 2016 L. Song 6 Beijing Internet Institute 7 July 20, 2015 9 DNS message fragments 10 draft-muks-dns-message-fragments-00 12 Abstract 14 This document describes a method to transmit DNS messages over 15 multiple UDP datagrams by fragmenting them at the application layer. 16 The objective is to allow authoriative servers to successfully reply 17 to DNS queries via UDP using multiple smaller datagrams, where larger 18 datagrams may not pass through the network successfully. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 21, 2016. 37 Copyright Notice 39 Copyright (c) 2015 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 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. DNS Message Fragmentation Method . . . . . . . . . . . . . . 4 58 2.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 4 60 2.3. Other Notes . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. The ALLOW-FRAGMENTS EDNS(0) Option . . . . . . . . . . . . . 7 62 3.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.2. Option Fields . . . . . . . . . . . . . . . . . . . . . . 7 64 3.2.1. Maximum Fragment Size . . . . . . . . . . . . . . . . 7 65 3.3. Presentation Format . . . . . . . . . . . . . . . . . . . 7 66 4. The FRAGMENT EDNS(0) Option . . . . . . . . . . . . . . . . . 7 67 4.1. Wire Format . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.2. Option Fields . . . . . . . . . . . . . . . . . . . . . . 7 69 4.2.1. Fragment Identifier . . . . . . . . . . . . . . . . . 7 70 4.2.2. Fragment Count . . . . . . . . . . . . . . . . . . . 8 71 4.3. Presentation Format . . . . . . . . . . . . . . . . . . . 8 72 5. Network Considerations . . . . . . . . . . . . . . . . . . . 8 73 5.1. Background . . . . . . . . . . . . . . . . . . . . . . . 8 74 5.2. Implementation Requirements . . . . . . . . . . . . . . . 9 75 6. Open Issues and Discussion . . . . . . . . . . . . . . . . . 9 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 Appendix A. Change History (to be removed before publication) . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 1.1. Background 87 [RFC1035] describes how DNS messages are to be transmitted over UDP. 88 A DNS query message is transmitted using one UDP datagram from client 89 to server, and a corresponding DNS reply message is transmitted using 90 one UDP datagram from server to client. 92 The upper limit on the size of a DNS message that can be transmitted 93 thus depends on the maximum size of the UDP datagram that can be 94 transmitted successfully from the sender to the receiver. Typically 95 any size limit only matters for DNS replies, as DNS queries are 96 usually small. 98 As a UDP datagram is transmitted in a single IP PDU, in theory the 99 size of a UDP datagram (including various lower internet layer 100 headers) can be as large as 64 KiB. But practically, if the datagram 101 size exceeds the path MTU, then the datagram will either be 102 fragmented at the IP layer, or worse dropped, by a forwarder. In the 103 case of IPv6, DNS packets are fragmented by the sender only. If a 104 packet's size exceeds the path MTU, a Packet Too Big (PTB) ICMP 105 message will be received by sender without any clue to the sender to 106 reply again with a smaller sized message, due to the stateless 107 feature of DNS. In addition, IP-level fragmentation caused by large 108 DNS response packet will introduce risk of cache poisoning 109 [Fragment-Poisonous], in which the attacker can circumvent some 110 defense mechanisms (like port, IP, and query randomization 111 [RFC5452]). 113 As a result, a practical DNS payload size limitation is necessary. 114 [RFC1035] limited DNS message UDP datagram lengths to a maximum of 115 512 bytes. Although EDNS(0) [RFC6891] allows an initiator to 116 advertise the capability of receiving lager packets (up to 4096 117 bytes), it leads to fragmentation because practically most packets 118 are limited to 1500 byte size due to host Ethernet interfaces, or 119 1280 byte size due to minimum IPv6 MTU in the IPv6 stack [RFC3542]. 121 According to DNS specifications [RFC1035], if the DNS response 122 message can not fit within the packet's size limit, the response is 123 truncated and the initiator will have to use TCP as a fallback to re- 124 query to receive large response. However, not to mention the high 125 setup cost introduced by TCP due to additional roundtrips, some 126 firewalls and middle boxes even block TCP/53 which cause no responses 127 to be received as well. It becomes a significant issue when the DNS 128 response size inevitably increases with DNSSEC deployment. 130 In this memo, DNS message fragmentation attempts to work around 131 middle box misbehavior by splitting a single DNS message across 132 multiple UDP datagrams. Note that to avoid DNS amplification and 133 reflection attacks, DNS cookies [I-D.ietf-dnsop-cookies] is a 134 mandatory requirement when using DNS message fragments. 136 1.2. Motivation 138 It is not a new topic regarding large DNS packets(>512B) issue 139 [I-D.ietf-dnsop-respsize], starting from introduction of IPv6, 140 EDNS(0) [SAC016], and DNSSEC deployment [SAC035]. In current 141 production networks, using DNSSEC with longer DNSKEYs (ZSK>1024B and 142 KSK>2048B) will result in response packets no smaller than 1500B 143 [T-DNS]. Especially during the KSK rollover process, responses to 144 the query of DNSKEY RRset will be enlarged as they contain both the 145 new and old KSK. 147 When possible, we should avoid dropped packets as this means the 148 client must wait for a timeout, which incurs a high cost. For 149 example, a validator behind a firewall suffers waiting till the 150 timeout with no response, if the firewall drops large EDNS(0) packets 151 and IP fragments. It may even cause disaster when the validator can 152 not recieve response for new trust anchor KSK due to the extreme case 153 of bad middle boxes which also drop TCP/53. 155 Since UDP requires fewer packets on the wire and less state on 156 servers than TCP, in this memo we propose continuing to use UDP for 157 transmission but fragment the larger DNS packets into smaller DNS 158 packets at the application layer. We would like the fragments to 159 easily go through middle boxes and avoid falling back to TCP. 161 2. DNS Message Fragmentation Method 163 2.1. Client Behavior 165 Clients supporting DNS message fragmentation add an EDNS option to 166 their queries, which declares their support for this feature. 168 If a DNS reply is received that has been fragmented, it will consist 169 of multiple DNS message fragments (each transmitted in a respective 170 UDP packet), and every fragment contain an EDNS option which says how 171 many total fragments there are, and the identifier of the fragment 172 that the current packet represents. The client collects all of the 173 fragments and uses them to reconstruct the full DNS message. Clients 174 MUST maintain a timeout when waiting for the fragments to arrive. 176 Clients that support DNS message fragments MUST be able to reassemble 177 fragments into a DNS message of any size, up to the maximum of 64KiB. 179 The client MAY save information about what sizes of packets have been 180 received from a given server. If saved, this information MUST have a 181 limited duration. 183 Any DNSSEC validation is performed on the reassembled DNS message. 185 2.2. Server Behavior 187 Servers supporting DNS message fragmentation will look for the EDNS 188 option which declares client support for the feature. If not 189 present, the server MUST NOT use DNS message fragmentation. The 190 server MUST check that DNS cookies are supported. [**FIXME**] 191 Implementation of the first request case, where no existing 192 established cookie is available needs discussion; we want to avoid 193 additional round-trips here. Shane: don't cookies already handle 194 this case? 195 The server prepares the response DNS message normally. If the 196 message exceeds the maximum UDP payload size specified by the client, 197 then it should fragment the message into multiple UDP datagrams. 199 Each fragment contains an identical DNS header with TC=1, possibly 200 varying only in the section counts. Setting the TC flag in this way 201 insures that clients which do not support DNS fragments can fallback 202 to TCP transparently. 204 As many RR are included in each fragment as are possible without 205 going over the desired size of the fragment. An EDNS option is added 206 to every fragment, that includes both the fragment identifier and the 207 total number of fragments. 209 The server needs to know how many total fragments there are to insert 210 into each fragment. A simple approach would be to generate all 211 fragments, and then count the total number at the end, and update the 212 previously-generated fragments with the total number of fragments. 213 Other techniques may be possible. 215 The server MUST limit the number of fragments that it uses in a 216 reply. (See "Open Issues and Discussion" for remaining work.) 218 The server MUST NOT exceed the maximum fragment size requested by a 219 client. 221 The server should use the following sizes for each fragment in the 222 sequence in IPv4: 224 +-------------+---------------------------------+ 225 | Fragment ID | Size | 226 +-------------+---------------------------------+ 227 | 1 | min(512, client_specified_max) | 228 | 2 | min(1460, client_specified_max) | 229 | 3 | min(1480, client_specified_max) | 230 | N | min(1480, client_specified_max) | 231 +-------------+---------------------------------+ 233 The rationale is that the first packet will always get through, since 234 if a 512 octet packet doesn't work, DNS cannot function. We then 235 increase to sizes that are likely to get through. 1460 is the 1500 236 octet Ethernet packet size, minus the IP header overhead and enough 237 space to support tunneled traffic. 1480 is the 1500 octet Ethernet 238 packet size, minus the IP header overhead. [**FIXME**] Why not add 239 1240 here? Shane answers: 1280 is not any kind of limit in IPv4, as 240 far as I know. 242 The server should use the following sizes for each packet in the 243 sequence in IPv6: 245 +-------------+---------------------------------+ 246 | Fragment ID | Size | 247 +-------------+---------------------------------+ 248 | 1 | min(1240, client_specified_max) | 249 | 2 | min(1420, client_specified_max) | 250 | 3 | min(1460, client_specified_max) | 251 | N | min(1460, client_specified_max) | 252 +-------------+---------------------------------+ 254 Like with IPv4, the idea is that the first packet will always get 255 through. In this case we use the IPv6-mandated 1280 octets, minus 256 the IP header overhead. We then increase to 1420, which is the 1500 257 octet Ethernet packet size, minus the IP header overhead and enough 258 space to support tunneled traffic. 1460 is the 1500 octet Ethernet 259 packet size, minus the IP header overhead. 261 2.3. Other Notes 263 o The FRAGMENT option MUST NOT be present in DNS query messages, 264 i.e., when QR=0. If a DNS implementation notices the FRAGMENT 265 option in a DNS query message, it MUST ignore it. 267 o In DNS reply messages, the FRAGMENT option MUST NOT be present in 268 datagrams when truncation is not done, i.e., when TC=0. If a DNS 269 implementation notices the FRAGMENT option in a DNS reply message 270 fragment datagram that is not truncated, i.e, when TC=0, it MUST 271 drop all DNS reply message fragment datagrams received so far 272 (awaiting assembly) for that message's corresponding question 273 tuple (server IP, port, message ID) without using any data from 274 them. [**FIXME**] Dropping fragments to be received yet will be 275 problematic for implementations, but dropping fragments received 276 so far ought to be sufficient. 278 o More than one FRAGMENT option MUST NOT be present in a DNS reply 279 message fragment datagram. If a DNS implementation notices 280 multiple FRAGMENT options in a DNS reply message fragment 281 datagram, it MUST drop all reply datagrams received for that 282 message's corresponding question tuple (server IP, port, message 283 ID) without using any data from them. [**FIXME**] Dropping 284 fragments to be received yet will be problematic for 285 implementations, but dropping fragments received so far ought to 286 be sufficient. 288 3. The ALLOW-FRAGMENTS EDNS(0) Option 290 ALLOW-FRAGMENTS is an EDNS(0) [RFC6891] option that a client uses to 291 inform a server that it supports fragmented responses. [**FIXME**] 292 Why not simply use the FRAGMENT option here with count=0, 293 identifier=ignored and avoid using another option code? Shane: There 294 are no shortage of options. Plus, if we want to include a maximum 295 fragment size value in the ALLOW-FRAGMENTS then we really need a 296 separate option. 298 3.1. Wire Format 300 TBD. 302 3.2. Option Fields 304 3.2.1. Maximum Fragment Size 306 The Maximum Fragment Size field is represented as an unsigned 16-bit 307 integer. This is the maximum size used by any given fragment the 308 server returns. [**FIXME**] This field's purpose has to be explained. 309 Shane: discussed in the discussion section now. 311 3.3. Presentation Format 313 As with other EDNS(0) options, the ALLOW-FRAGMENTS option does not 314 have a presentation format. 316 4. The FRAGMENT EDNS(0) Option 318 FRAGMENT is an EDNS(0) [RFC6891] option that assists a client in 319 gathering the various fragments of a DNS message from multiple UDP 320 datagrams. It is described in a previous section. Here, its syntax 321 is provided. 323 4.1. Wire Format 325 TBD. 327 4.2. Option Fields 329 4.2.1. Fragment Identifier 331 The Fragment Identifier field is represented as an unsigned 8-bit 332 integer. The first fragment is identified as 1. Values in the range 333 [1,255] can be used to identify the various fragments. Value 0 is 334 used for signalling purposes. 336 4.2.2. Fragment Count 338 The Fragment Count field is represented as an unsigned 8-bit integer. 339 It contains the number of fragments in the range [1,255] that make up 340 the DNS message. Value 0 is used for signalling purposes. 342 4.3. Presentation Format 344 As with other EDNS(0) options, the FRAGMENT option does not have a 345 presentation format. 347 5. Network Considerations 349 5.1. Background 351 TCP-based application protocols co-exist well with competing traffic 352 flows in the internet due to congestion control methods such as in 353 [RFC5681] that are present in TCP implementations. 355 UDP-based application protocols have no restrictions in lower layers 356 to stop them from flooding datagrams into a network and causing 357 congestion. So applications that use UDP have to check themselves 358 from causing congestion so that their traffic is not disruptive. 360 In the case of [RFC1035], only one reply UDP datagram was sent per 361 request UDP datagram, and so the lock-step flow control automatically 362 ensured that UDP DNS traffic didn't lead to congestion. When DNS 363 clients didn't hear back from the server, and had to retransmit the 364 question, they typically paced themselves by using methods such as a 365 retransmission timer based on a smoothed round-trip time between 366 client and server. 368 Due to the message fragmentation described in this document, when a 369 DNS query causes multiple DNS reply datagrams to be sent back to the 370 client, there is a risk that without effective control of flow, DNS 371 traffic could cause problems to competing flows along the network 372 path. 374 Because UDP does not guarantee delivery of datagrams, there is a 375 possibility that one or more fragments of a DNS message will be lost 376 during transfer. This is especially a problem on some wireless 377 networks where a rate of datagrams can continually be lost due to 378 interference and other environmental factors. With larger numbers of 379 message fragments, the probability of fragment loss increases. 381 5.2. Implementation Requirements 383 TBD. 385 6. Open Issues and Discussion 387 1. Resolver behavior 389 We need some more discussion of resolver behavior in general, at 390 least to the point of making things clear to an implementor. 392 2. The use of DNS fragments mechanism 394 Is this mechanism designed for all DNS transactions, or only 395 used in some event or special cases like a key rollover process? 396 If the mechanism is designed for general DNS transactions, when 397 is it triggered and how is it integrated with existing patterns? 399 One option is that DNS fragments mechanism works as a backup 400 with EDNS, and triggered only when a larger packet fails in the 401 middle. It will be orthogonal with TCP which provide additional 402 context that TC bit will be used in server side. 404 3. What is the size of fragments? 406 Generally speaking the number of fragment increases if fragment 407 size is small (512 bytes, or other empirical value), which makes 408 the mechanism less efficient. If the size can changed 409 dynamically according to negotiation or some detection, it will 410 introduce more cost and round trip time. 412 4. What happens if a client that does not support DNS fragments 413 receives an out-of-order or partial fragment? 415 We need to consider what happens when a client that does not 416 support DNS fragments gets a partial response, possibly even out 417 of order. 419 5. We should explain risk of congestion, packet loss, etc. when 420 introducing the limit on the number of fragments. We might also 421 set specific upper limits for number of fragments. 423 6. EDNS buffer sizes vs. maximum fragmentation sizes 425 Mukund: We need further discussion about the sizes; also an 426 upper limit for each *fragment* has to be the client's UDP 427 payload size as it is the driver and it alone knows the ultimate 428 success/failure of message delivery. So if it sets a maximum 429 payload size of 1200, there's no point in trying 1460. Clients 430 that support DNS message fragments (and signal support using the 431 EDNS option) should adapt their UDP payload size discovery 432 algorithm to work with this feature, as the following splits on 433 sizes will assist PMTU discovery. 435 Shane: I think we need to separate the EDNS maximum UDP payload 436 size from the maximum fragment size. I think that it is quite 437 likely that (for example) we will want to restrict each fragment 438 to 1480 bytes, but that the EDNS buffer size might remain at 4 439 kibibytes. 441 7. TSIG should be addressed 443 We need to document how to handle TSIG, even though this is not 444 likely to be a real-world issue. Probably each fragment should 445 be TSIG signed, as this makes it harder for an attacker to 446 inject bogus packets that a client will have to process. 448 8. RR splitting should be addressed 450 We need to document whether or not RR can be split. Probably it 451 makes sense not to allow this, although this will reduce the 452 effectiveness of the fragmentation, as the units that can be 453 packed into each fragment will be bigger. 455 9. We need to document that some messages may not be possible to 456 split. 458 Some messages may be too large to split. A trivial example is a 459 TXT record that is larger than the buffer size. Probably the 460 best behavior here is to truncate. 462 10. DNSSEC checks 463 DNSSEC checks should be done on the final reassembled packet. 464 This needs to be documented. 466 11. Name compression 468 Name compression should be done on the each fragment separately. 469 This needs to be documented. 471 12. OPT-RR 473 Some OPT-RR seem to be oriented at the entire message, others 474 make more sense per packet. This needs to be sorted out. Also 475 we need to investigate the edge case where fragments have 476 conflicting options (Mukund thinks that we can copy the approach 477 in the EDNS specification and use the same rules about 478 conflicting OPT-RR that it uses.) 480 7. Security Considerations 482 To avoid DNS amplification or reflection attacks, DNS cookies 483 [I-D.ietf-dnsop-cookies] must be used. The DNS cookie EDNS option is 484 identical in all fragments that make up a DNS message. The 485 duplication of the same cookie values in all fragments that make up 486 the message is not expected to introduce a security weakness in the 487 case of off-path attacks. 489 8. IANA Considerations 491 The ALLOW-FRAGMENTS and FRAGMENT EDNS(0) options require option codes 492 to be assigned for them. 494 9. Acknowledgements 496 Thanks to Stephen Morris, JINMEI Tatuya, Paul Vixie, Mark Andrews, 497 and David Dragon for reviewing a pre-draft proposal and providing 498 support, comments and suggestions. 500 10. References 502 [Fragment-Poisonous] 503 Herzberg, A. and H. Shulman, "Fragmentation Considered 504 Poisonous", 2012. 506 [I-D.ietf-dnsop-cookies] 507 Eastlake, D. and M. Andrews, "Domain Name System (DNS) 508 Cookies", draft-ietf-dnsop-cookies-04 (work in progress), 509 July 2015. 511 [I-D.ietf-dnsop-respsize] 512 Vixie, P., Kato, A., and J. Abley, "DNS Referral Response 513 Size Issues", draft-ietf-dnsop-respsize-15 (work in 514 progress), February 2014. 516 [RFC1035] Mockapetris, P., "Domain names - implementation and 517 specification", STD 13, RFC 1035, November 1987. 519 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 520 and Support", STD 3, RFC 1123, October 1989. 522 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 523 "Advanced Sockets Application Program Interface (API) for 524 IPv6", RFC 3542, May 2003. 526 [RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More 527 Resilient against Forged Answers", RFC 5452, January 2009. 529 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 530 Control", RFC 5681, September 2009. 532 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 533 for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. 535 [SAC016] ICANN Security and Stability Advisory Committee, "Testing 536 Firewalls for IPv6 and EDNS0 Support", 2007. 538 [SAC035] ICANN Security and Stability Advisory Committee, "DNSSEC 539 Impact on Broadband Routers and Firewalls", 2008. 541 [T-DNS] Zhu, L., Hu, Z., and J. Heidemann, "T-DNS: Connection- 542 Oriented DNS to Improve Privacy and Security (extended)", 543 2007, . 545 Appendix A. Change History (to be removed before publication) 547 o draft-muks-dns-message-fragments-00 548 Initial draft. 550 Authors' Addresses 552 Mukund Sivaraman 553 Internet Systems Consortium 554 950 Charter Street 555 Redwood City, CA 94063 556 US 558 Email: muks@isc.org 559 URI: http://www.isc.org/ 561 Shane Kerr 562 Beijing Internet Institute 563 2/F, Building 5, No.58 Jinghai Road, BDA 564 Beijing 100176 565 CN 567 Email: shane@biigroup.cn 568 URI: http://www.biigroup.com/ 570 Linjian Song 571 Beijing Internet Institute 572 2/F, Building 5, No.58 Jinghai Road, BDA 573 Beijing 100176 574 CN 576 Email: songlinjian@gmail.com 577 URI: http://www.biigroup.com/