Secure Inter-Domain Routing Y. Fu
Internet-Draft Z. Yan
Intended status: Informational X. Liu
Expires: March 16, 2017 C. Wang
CNNIC
September 12, 2016
Scenarios of unexpected resource assignment in RPKI
draft-fu-sidr-unexpected-scenarios-02
Abstract
There are some unexpected scenarios where a CA allocates resources to
the sub-node caused by misoperation or malicious operation of CA in
RPKI. Then some mechanisms may be needed to avoid these scenarios to
happen. This document describes these scenarios and related
experiments are presented.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 16, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Fu, et al. Expires March 16, 2017 [Page 1]
Internet-Draft draft-fu-sidr-unexpected-scenarios-02 September 2016
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The scenarios of unexpected resource assignment . . . . . . . 3
3.1. Unauthorized resource assignment . . . . . . . . . . . . 3
3.2. Resource reassignment . . . . . . . . . . . . . . . . . . 3
3.3. Resource transfer . . . . . . . . . . . . . . . . . . . . 4
4. Experimental Result . . . . . . . . . . . . . . . . . . . . . 4
4.1. Unauthorized resource assignment . . . . . . . . . . . . 4
4.1.1. Completely unauthorized assignment . . . . . . . . . 4
4.1.2. Partially unauthorized assignment . . . . . . . . . . 6
4.2. Resource reassignment . . . . . . . . . . . . . . . . . . 8
4.2.1. Matching case . . . . . . . . . . . . . . . . . . . . 8
4.2.2. Intersection case . . . . . . . . . . . . . . . . . . 10
4.2.3. Subset case . . . . . . . . . . . . . . . . . . . . . 12
4.3. Resource transfer . . . . . . . . . . . . . . . . . . . . 14
5. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. The CA function enhancement . . . . . . . . . . . . . . . 15
5.2. The RP function enhancement . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
n RPKI, CAs (Certification Authorities) are organized in a
hierarchical structure which is aligned to the existing INR (Internet
Number Resources, including IP prefixes and AS numbers) allocation
hierarchy. Each INR allocation requires corresponding resource
certificates to attest to it. Two important resource certificates
[RFC6480] are needed during this allocation process, and they are CA
certificates and EE (End-entity) certificates: CA certificates attest
to the INR holdings; EE certificates are primarily used for the
validation of ROAs (Route Origin Authorizations) [RFC6482] which is
used to verify whether an AS is permitted to originate routes to
specific IP prefixes. Besides, Manifest [RFC6486] is used to ensure
the integrity of the repository. So the operation of CA is very
important for the RPKI deployment and applications based on it.
Fu, et al. Expires March 16, 2017 [Page 2]
Internet-Draft draft-fu-sidr-unexpected-scenarios-02 September 2016
Considering misoperation and malicious operation are inevitable and
the significant impact they may cause, this draft describes and
analyzes some scenarios of the unexpected resource assignment caused
by CA in RPKI deployment. Then some experiments are given to show
these scenarios more clearly. Some suggestions are also proposed to
avoid corresponding side-effects.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. The scenarios of unexpected resource assignment
As described in [RFC6480], the holder of resource ( IP addresses and
AS numbers ) may reallocate portions of that block, to the sub-node,
subject to contractual constraints established by the registries.
But some scenarios of unexpected resource allocation may be caused by
the misoperaion of malicious operation of the CA as below: for
simplicity, we describe some scenarios with the AS number allocation
case.
3.1. Unauthorized resource assignment
For this scenario, a CA allocates a block of IP address which does
not belong to him to subordinate node. That is, this CA doesn't own
this block of IP Prefixes actually. So the sub-node cannot use these
addresses. But in RPKI scenario, this assignment could be operated
successfully. This scenario may be caused by misoperation of the CA
or on purpose.
According to the resources to be allocated, we divide this case into
two kinds of scenarios: Completely unauthorized assignment and
Partially unauthorized assignment.
(1) Completely unauthorized assignment: the resources to be allocated
to subordinate node are without the ownership of CA.
(2) Partially unauthorized assignment: the resources to be allocated
to subordinate node are with the partially ownership of CA.
3.2. Resource reassignment
In this scenario, a CA reassign the resource to one sub-node which
has been already assigned to another sub-node. This scenario could
be sorted into three types:
Fu, et al. Expires March 16, 2017 [Page 3]
Internet-Draft draft-fu-sidr-unexpected-scenarios-02 September 2016
(1) Matching: the block of IP address which is reassigned is the same
as which has been already assigned to the other sub-node.
(2) Subset: The block of IP address which is reassigned is smaller
than which has been already assigned to the other sub-node.
(3) Intersection: The block of IP address which is reassigned has
overlap with which has been already assigned to the other sub-node.
3.3. Resource transfer
In practice, resource transfer between two Internet registries is
reasonably achievable for most useful operational needs. For the
resource transfer, a block of IP addresses will be transferred from
one sub-node to the other. This scenario is described in
[I-D.ymbk-sidr-transfer] in more detail. The resource reassignment
may happened in this scenario by the misoperation of the CA.
4. Experimental Result
We test the scenarios described above in our testbed. In this
section, we present the test results for each case and analyze these
results.
4.1. Unauthorized resource assignment
4.1.1. Completely unauthorized assignment
The test scenario is described in Figure 1: APNIC allocates AS number
65551 and IP prefixes of 192.0.3.128/26 to TWNIC. But APNIC doesn't
own this resource completely. We simulated this process of
assignment on our testbed and the result is illustrated in Figure 2.
Fu, et al. Expires March 16, 2017 [Page 4]
Internet-Draft draft-fu-sidr-unexpected-scenarios-02 September 2016
ASNs;
+-------------+ 64496-64511,65536-65551
| | IP prefixes:
| IANA +---------192.0.2.0/24,198.51.100.0/24
| | 203.0.113.0/24
+------|------+
|
+-------------+ ASNs
| | 64497-64510,65537-65550
| | IP prefixes:
| APNIC ---------192.0.2.128/25,
| | 198.51.100.128/25
-------|------+ 203.0.113.128/25
| | |
----------------| | |---------------
| | |
+-----------+ +------|------+ +-----------+
| JPNIC | | TWNIC | | CNNIC |
+-----|-----+ +------|------+ +----|------+
| | |
ASNs: ASNs: ASNs:
65540-65550 65551 64498-64505
IP prefixes IP prefixes IP prefixes:
203.0.113.128/26 192.0.3.128/26 192.0.2.128/26
198.51.100.128/26
Figure 1: The network architecture of the completely unauthorized
assignment
We test this case with the tools offered by http://rpki.net/. The
result (as described in Figure 2) shows: APNIC has allocated the
unauthorized resources (ASNs: 65551, IP prefixes: 192.0.3.128/26) to
TWNIC successfully, but TWNIC did not receive these resources
actually.
Fu, et al. Expires March 16, 2017 [Page 5]
Internet-Draft draft-fu-sidr-unexpected-scenarios-02 September 2016
root@ubuntu:~#rpkic -i cnnic show_received_resources
Parent: apnic
notBefore: 2015-07-15T15:53:25Z
notAfter: 2016-07-14T15:36:05Z
URI: rsync://localhost/rpki/iana/apnic/BqHiZw817JRhXby5cljw-Iy75c4.cer
SIA URI: rsync://localhost/rpki/iana/apnic/cnnic/
AIA URI: rsync://localhost/rpki/iana/RAseYE67qlpBd34u5UqhMjwq8c0.cer
ASN: 64498-64505
IPv4: 192.0.2.128/26,198.51.100.128/26
IPv6:
root@ubuntu:~# rpkic -i jpnic show_received_resources
Parent: apnic
notBefore: 2015-07-15T15:25:54Z
notAfter: 2016-07-14T15:20:04Z
URI: rsync://localhost/rpki/iana/apnic/NSt9KXs-a2py_OGZlol4fipm1lQ.cer
SIA URI: rsync://localhost/rpki/iana/apnic/jpnic/
AIA URI: rsync://localhost/rpki/iana/RAseYE67qlpBd34u5UqhMjwq8c0.cer
ASN: 65540-65550
IPv4: 203.0.113.128/26
IPv6:
root@ubuntu:~# rpkic -i twnic show_received_resources
root@ubuntu:~#
Figure 2: The test result of completely unauthorized assignment
4.1.2. Partially unauthorized assignment
The test scenario is described in Figure 3: APNIC allocates ASNs (
9700-9818 ) to JPNIC. But APNIC only take the ownership of ASNs (
9801-9818 ). We simulated this process of assignment on our testbed
and the result is illustrated in Figure 4.
Fu, et al. Expires March 16, 2017 [Page 6]
Internet-Draft draft-fu-sidr-unexpected-scenarios-02 September 2016
+-------------+
| | ASNs:
| IANA +---------9800-9819,132176-132191
+------|------+
|
+-------------+
| | ASNs:
| APNIC ---------9801-9818,132177-132190
| |
--------------+
| |
----------------| |---------------
| |
+-----------+ +-----------+
| JPNIC | | CNNIC |
+-----|-----+ +----|------+
| |
ASNs: ASNs:
9700-9818 132178-132189
Figure 3: The network architecture of partially unauthorized
assignment
Our test result for this scenario (as described in Figure 4) shows:
APNIC think that it has allocated the partially unauthorized
resources to JPNIC successfully, but JPNIC only received the legal
part (ASNs 9801-9818), without the illegal part (ASNs 9700-9800).
Fu, et al. Expires March 16, 2017 [Page 7]
Internet-Draft draft-fu-sidr-unexpected-scenarios-02 September 2016
root@ubuntu:~# rpkic -i apnic show_child_resources
Child: cnnic
ASN: 132178-132179
IPv4: 203.0.113.0/26,218.214.108.0/26
Child: jpnic
ASN: 9700-9818
IPv4: 218.241.104.0/26
root@ubuntu:~#rpkic -i cnnic show_received_resources
Parent: apnic
notBefore: 2015-08-31T15:45:37Z
notAfter: 2016-08-30T12:24:04Z
URI: rsync://192.168.137.139/rpki/iana/apnic/t4jbcdikZIF9RGeLpZ0fiBd59Uw.cer
SIA URI: rsync://192.168.137.139/rpki/iana/apnic/cnnic/
AIA URI: rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer
ASN: 132178-132189
IPv4: 203.0.113.0/26,218.214.108.0/26
IPv6:
root@ubuntu:~# rpkic -i jpnic show_received_resources
Parent: apnic
notBefore: 2015-08-31T15:47:38Z
notAfter: 2016-08-30T12:25:25Z
URI: rsync://192.168.137.139/rpki/iana/apnic/V4CxZVxBkwwIiBruCy7k7DESUvg.cer
SIA URI: rsync://192.168.137.139/rpki/iana/apnic/jpnic/
AIA URI: rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer
ASN: 9801-9818
IPv4: 218.241.104.0/26
IPv6:
Figure 4: The test result of partially unauthorized assignment
4.2. Resource reassignment
In the "Resource reassignment" case, we mean that a CA allocate the
resources, which have been allocated to one subordinate CA ( e.g.
CNNIC ), to another subordinate CA ( e.g. JPNIC ). This case may
also be caused by misoperation of CA or on purpose. And it may
result in resource conflicts in the Internet.
4.2.1. Matching case
For the matching case, the test scenario is described in Figure 5:
the resources to be allocated to JPNIC (ASNs 132178-132189) is
identical to those allocated to CNNIC (ASNs 132178-132189).
Fu, et al. Expires March 16, 2017 [Page 8]
Internet-Draft draft-fu-sidr-unexpected-scenarios-02 September 2016
+-------------+
| | ASNs:
| IANA +---------9800-9819,132176-132191
+------|------+
|
+-------------+
| | ASNs:
| APNIC ---------9801-9818,132177-132190
| |
--------------+
| |
----------------| |---------------
| |
+-----------+ +-----------+
| JPNIC | | CNNIC |
+-----|-----+ +----|------+
| |
ASNs: ASNs:
132178-132189 132178-132189
Figure 5: The network architecture of matching case
We test this case with the tools offered by http://rpki.net/. The
result (as described in Fig 6) is that both CNNIC and JPNIC can
receive these ASNs at the same time. It may result in resource
confliction in the internet.
Fu, et al. Expires March 16, 2017 [Page 9]
Internet-Draft draft-fu-sidr-unexpected-scenarios-02 September 2016
root@ubuntu:~# rpkic -i apnic show_child_resources
Child: cnnic
ASN: 132178-132189
IPv4: 203.0.113.0/26
Child: jpnic
ASN: 132178-132189
IPv4: 203.0.113.0/26
root@ubuntu:~# rpkic -i jpnic show_received_resources
Parent: apnic
notBefore: 2015-08-31T13:43:18Z
notAfter: 2016-08-30T12:25:25Z
URI: rsync://192.168.137.139/rpki/iana/apnic/V4CxZVxBkwwIiBruCy7k7DESUvg.cer
SIA URI: rsync://192.168.137.139/rpki/iana/apnic/cnnic/
AIA URI: rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer
ASN: 132178-132189
IPv4: 203.0.113.0/26
IPv6:
root@ubuntu:~# rpkic -i cnnic show_received_resources
Parent: apnic
notBefore: 2015-08-31T13:39:19Z
notAfter: 2016-08-30T12:24:04Z
URI: rsync://192.168.137.139/rpki/iana/apnic/t4jbcdikZIF9RGeLpZ0fiBd59Uw.cer
SIA URI: rsync://192.168.137.139/rpki/iana/apnic/cnnic/
AIA URI: rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer
ASN: 132178-132189
IPv4: 203.0.113.0/26
IPv6:
Figure 6: The test result of matching case
CNNIC and JPNIC receive the same resource assigned by the APNIC at
the same time. So the same resource could be allocated to the
different sub-node simultaneously.
4.2.2. Intersection case
As is shown in Figure 7, in the intersection case, there is an
overlap between the resources to be allocated to JPNIC (ASNs
132180-132190) and those allocated to CNNIC (ASNs 132177-132185).
Fu, et al. Expires March 16, 2017 [Page 10]
Internet-Draft draft-fu-sidr-unexpected-scenarios-02 September 2016
+-------------+
| | ASNs:
| IANA +---------9800-9819,132176-132191
+------|------+
|
+-------------+
| | ASNs:
| APNIC ---------9801-9818,132177-132190
| |
--------------+
| |
----------------| |---------------
| |
+-----------+ +-----------+
| JPNIC | | CNNIC |
+-----|-----+ +----|------+
| |
ASNs: ASNs:
132180-132190 132177-132185
Figure 7: The network architecture of intersection case
Our test result (as described in Figure 8) shows that both CNNIC and
JPNIC can receive these ASNs.
Fu, et al. Expires March 16, 2017 [Page 11]
Internet-Draft draft-fu-sidr-unexpected-scenarios-02 September 2016
root@ubuntu:~# rpkic -i apnic show_child_resources
Child: cnnic
ASN: 132177-132185
IPv4: 203.0.113.0/26,218.241.108.0/26
Child: jpnic
ASN: 132180-132190
IPv4: 218.241.104.0/26
root@ubuntu:~#rpkic -i cnnic show_received_resources
Parent: apnic
notBefore: 2015-08-31T14:58:54Z
notAfter: 2016-08-30T12:24:04Z
URI: rsync://192.168.137.139/rpki/iana/apnic/t4jbcdikZIF9RGeLpZ0fiBd59Uw.cer
SIA URI: rsync://192.168.137.139/rpki/iana/apnic/cnnic/
AIA URI: rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer
ASN: 132177-132185
IPv4: 203.0.113.0/26,218.214.108.0/26
IPv6:
root@ubuntu:~# rpkic -i jpnic show_received_resources
Parent: apnic
notBefore: 2015-08-31T14:58:44Z
notAfter: 2016-08-30T12:25:25Z
URI: rsync://192.168.137.139/rpki/iana/apnic/V4CxZVxBkwwIiBruCy7k7DESUvg.cer
SIA URI: rsync://192.168.137.139/rpki/iana/apnic/jpnic/
AIA URI: rsync://192.168.137.139/rpki/iana/HFOgArj0R8dF5vZ-7beqS0CzT2w.cer
ASN: 132180-132090
IPv4: 218.241.104.0/26
IPv6:
Figure 8: The test result of intersection case
4.2.3. Subset case
For the subset case, the network architecture is described in
Figure 9: APNIC allocates the ASN 65540 and a block of IP address (
203.0.113.128/26 ) to JPNIC. Then it reallocated this resources to
CNNIC. These resources are the subset of CNNIC's resource.
Fu, et al. Expires March 16, 2017 [Page 12]
Internet-Draft draft-fu-sidr-unexpected-scenarios-02 September 2016
ASNs:
+-------------+ 64496-64511,65536-65551
| | IP prefixes:
| IANA +---------192.0.2.0/24,198.51.100.0/24
| | 203.0.113.0/24
+------|------+
|
+-------------+ ASNs:
| | 64497-64510,65537-65550
| | IP prefixes:
| APNIC ---------192.0.2.128/25,
| | 198.51.100.128/25
--------------+ 203.0.113.128/25
| |
----------------| |---------------
| |
+-----------+ +-----------+
| JPNIC | | CNNIC |
+-----|-----+ +----|------+
| |
ASNs: ASNs:
65540 64498-64505,65540
IP prefixes IP prefixes:
203.0.113.128/26 192.0.2.128/26
198.51.100.128/26
203.0.113.128/26
Figure 9: The network architecture of subset case
We test this case with the tools offered by http://rpki.net/. The
result (as described in Fig 6 ) is that both CNNIC and JPNIC can
receive these ASNs and IP Prefixes at the same time. It may result
in resource confliction in the internet.
Fu, et al. Expires March 16, 2017 [Page 13]
Internet-Draft draft-fu-sidr-unexpected-scenarios-02 September 2016
root@ubuntu:~# rpkic -i apnic show_child_resources
Child: cnnic
ASN: 64498-64505,65540
IPv4: 192.0.2.128/26,198.51.100.128/26,203.0.113.128/26
Child: jpnic
ASN: 65540
IPv4: 203.0.113.128/26
root@ubuntu:~# rpkic -i cnnic show_received_resources
Parent: apnic
notBefore: 2015-07-15T15:37:58Z
notAfter: 2016-07-14T15:36:05Z
URI: rsync://localhost/rpki/iana/apnic/BqHiZw817JRhXby5cljw-Iy75c4.cer
SIA URI: rsync://localhost/rpki/iana/apnic/cnnic/
AIA URI: rsync://localhost/rpki/iana/RAseYE67qlpBd34u5UqhMjwq8c0.cer
ASN: 64498-64505,65540
IPv4: 192.0.2.128/26,198.51.100.128/26,203.0.113.128/26
IPv6:
root@ubuntu:~# rpkic -i jpnic show_received_resources
Parent: apnic
notBefore: 2015-07-15T15:25:54Z
notAfter: 2016-07-14T15:20:04Z
URI: rsync://localhost/rpki/iana/apnic/NSt9KXs-a2py_OGZlol4fipm1lQ.cer
SIA URI: rsync://localhost/rpki/iana/apnic/jpnic/
AIA URI: rsync://localhost/rpki/iana/RAseYE67qlpBd34u5UqhMjwq8c0.cer
ASN: 65540
IPv4: 203.0.113.128/26
IPv6:
Figure 10: The test result of subset case
CNNIC and JPNIC could receive the same resources assigned by APNIC at
the same time. So the test result verify that the same resources
could be allocated to different sub-nodes simultaneously.
4.3. Resource transfer
This issue is described in [I-D.ymbk-sidr-transfer]. The most
serious problem caused by it is the address reassignment described
above.
5. Solutions
In order to avoid the above issues or reduce the related side-
effects, the following two solutions may be needed.
Fu, et al. Expires March 16, 2017 [Page 14]
Internet-Draft draft-fu-sidr-unexpected-scenarios-02 September 2016
5.1. The CA function enhancement
We have designed a mechanism to enhance the CA function to avoid the
above misoperation or malicious operation. The detail information
will be given in the future.
5.2. The RP function enhancement
The enhancement of RP function is needed to discover these resource
assignment errors.
6. Security Considerations
TBD.
7. IANA Considerations
This draft does not request any IANA action.
8. Acknowledgements
The authors would like to thanks the valuable comments made by XXX
and other members of sidr WG.
This document was produced using the xml2rfc tool [RFC2629].
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <http://www.rfc-editor.org/info/rfc6480>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012,
<http://www.rfc-editor.org/info/rfc6482>.
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure
(RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012,
<http://www.rfc-editor.org/info/rfc6486>.
Fu, et al. Expires March 16, 2017 [Page 15]
Internet-Draft draft-fu-sidr-unexpected-scenarios-02 September 2016
9.2. Informative References
[I-D.ymbk-sidr-transfer]
Austein, R., Bush, R., Huston, G., and G. Michaelson,
"Resource Transfer in the Resource Public Key
Infrastructure", draft-ymbk-sidr-transfer-01 (work in
progress), July 2015.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
<http://www.rfc-editor.org/info/rfc2629>.
[RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
Format", RFC 5914, DOI 10.17487/RFC5914, June 2010,
<http://www.rfc-editor.org/info/rfc5914>.
Authors' Addresses
Yu Fu
CNNIC
No.4 South 4th Street, Zhongguancun
Hai-Dian District, Beijing, 100190
P.R. China
Email: fuyu@cnnic.cn
Zhiwei Yan
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing, 100190
P.R. China
Email: yanzhiwei@cnnic.cn
Xiaowei Liu
CNNIC
No.4 South 4th Street, Zhongguancun
Beijing, 100190
P.R. China
Email: liuxiaowei@cnnic.cn
Fu, et al. Expires March 16, 2017 [Page 16]
Internet-Draft draft-fu-sidr-unexpected-scenarios-02 September 2016
Cuicui Wang
CNNIC
No.4 South 4th Street, Zhongguancun
Hai-Dian District, Beijing, 100190
P.R. China
Email: wangcuicui@cnnic.cn
Fu, et al. Expires March 16, 2017 [Page 17]