Internet DRAFT - draft-zhang-sidrops-vrp-aggregation

draft-zhang-sidrops-vrp-aggregation







sidrops                                                         J. Zhang
Internet-Draft                                   Zhongguancun Laboratory
Intended status: Best Current Practice                             M. Xu
Expires: 29 August 2024                                          Y. Wang
                                                     Tsinghua University
                                                        26 February 2024


Enhancing Route Origin Validation by Aggregating Validated ROA Payloads
                 draft-zhang-sidrops-vrp-aggregation-00

Abstract

   Resource Public Key Infrastructure (RPKI) enables address space
   holders to issue Route Origin Authorization (ROA) objects to
   authorize one or more Autonomous Systems (ASes) to originate BGP
   routes for specific IP address prefixes.  Individual BGP speakers can
   utilize Validated ROA Payloads (VRPs) to validate the legitimacy of
   BGP announcements.  This document highlights potential validation
   errors, and recommends extension of VRPs from reasonable aggregation
   to enhance Route Origin Validation (ROV) and prevent validation
   errors that may occur due to traffic engineering or route aggregation
   policies.

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 https://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 29 August 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.






Zhang, et al.            Expires 29 August 2024                 [Page 1]

Internet-Draft               VRP Aggregation               February 2024


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Problem Statement and Root Cause Analysis . . . . . . . . . .   3
     2.1.  Route Aggregation . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Traffic Engineering . . . . . . . . . . . . . . . . . . .   5
     2.3.  Incomplete or inaccurate registration . . . . . . . . . .   7
   3.  Algorithm and Implementation of VRP Aggregation . . . . . . .   7
     3.1.  Algorithm Rationality . . . . . . . . . . . . . . . . . .   8
     3.2.  Aggregatable ROA Payload  . . . . . . . . . . . . . . . .   8
     3.3.  Implementation of VRP Aggregation . . . . . . . . . . . .   9
     3.4.  Considerations for VRP Aggregation Algorithm and
           Implementation  . . . . . . . . . . . . . . . . . . . . .  10
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
     6.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   In Resource Public Key Infrastructure (RPKI), an address space holder
   issues a digitally signed object called Route Origin Authorization
   (ROA) to authorize a specific Autonomous System (AS) to announce BGP
   routes for one or more IP prefixes within the corresponding address
   space.  The BGP speaker loads validated RPKI ROA objects from the
   Relying Party (RP) cache into its local storage.  The loaded objects
   are formatted with (prefix, originating AS number, maximum length).
   These locally stored objects are referred to as "Validated ROA
   Payload" (VRP), as defined in [RFC6811].  VRPs will be used to
   validate the origination AS of BGP routes[RFC6483] .








Zhang, et al.            Expires 29 August 2024                 [Page 2]

Internet-Draft               VRP Aggregation               February 2024


   However, due to factors such as traffic engineering or route
   aggregation, the prefixes announced by a BGP route may not be
   consistent with the prefixes registered in the ROA.  Typically,
   address space holders register specific prefixes in the ROA, while
   the BGP route announcements may involve aggregated prefixes.

   This document proposes to extend the original VRPs with new VRPs,
   which are generated based on aggregation of contiguous prefixes
   authorized to the same origin AS in original VRPs.  VRP aggregation
   could improve the accuracy of route announcement validation, prevent
   valid announcements from being erroneously validated as "Invalid" or
   "Unknown," and avoid unnecessary traffic discarding.  Ultimately,
   this approach aims to improve the practicality and effectiveness of
   RPKI deployment.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Problem Statement and Root Cause Analysis

   RPKI is a cryptographic system that enables validation of the origin
   of route announcements and helps prevent route origin hijacking and
   other security threats.  Typically, if an address space holder does
   not register a specific prefix in RPKI, it implies that the holder
   does not authorize an AS to advertise that prefix in routing
   announcements.

   However, there are situations where a prefix included in a route
   announcement may be subject to aggregation or deaggregation due to
   factors such as traffic engineering or route optimization.  As a
   result, the prefix being advertised might differ from the registered
   specific prefix in RPKI.

   In such scenarios, when a route validation process relies solely on
   RPKI ROAs, it may inaccurately validate the route announcement as
   "Invalid" or "Unknown".  This can happen when the aggregated parent
   prefix is announced, yet only the pre-aggregation sub-prefixes are
   registered in the RPKI.  Complex routing policies or inaccurate
   registrations can both lead to similar situations.

   In this section, we outline a series of typical scenarios that may
   lead to the validation outcomes being erroneously labeled as
   "Invalid" or "Unknown".  We will explore three potential causes for



Zhang, et al.            Expires 29 August 2024                 [Page 3]

Internet-Draft               VRP Aggregation               February 2024


   such inaccuracies associated with aggregated but unregistered
   prefixes, specifically: route aggregation, traffic engineering
   (including path redundancy, load balancing, etc.), and issues arising
   from inaccurate registration.

2.1.  Route Aggregation

   By merging a series of contiguous IP address prefixes into a single
   less-specific prefix, routing information can be simplified and
   routing efficiency improved.  However, if the AS that performs route
   aggregation has only been authorized to origin multiple sub-prefixes,
   the resulting aggregated BGP route announcement, will not be
   validated as "Valid".

   *  Example.  As shown in Figure 1, the BGP route announcement for the
      prefix 76.191.76.0/22 from AS62915 is erroneously validated as
      "Invalid".  AS62915 has announced a prefix 76.191.76.0/22 in
      global BGP routing table, but it has been authorized to originate
      a set of contiguous sub-prefixes across three ROAs
      (76.191.74.0/23, AS62915, maxlength=24), (76.191.76.0/23, AS62915,
      maxlength=24), and (76.191.78.0/23, AS62915, maxlength=24).  These
      registered sub-prefixes can be aggregated into the parent prefix
      76.191.76.0/22.  However, these ROAs alone cannot validate the
      route 76.191.76.0/22 originating from AS62915.  Worse still, the
      upstream provider of AS62915, AS11404, has been authorized to
      originate a more extensive range of prefixes (76.191.64.0/18,
      AS11404, maxlength=24) in RPKI ROA, which includes the prefix
      76.191.76.0/22.  Consequently, the legitimate route announcement
      for the prefix 76.191.76.0/22 originating from AS62915 is
      mistakenly validated as "Invalid".  This incorrect validation
      results in the route announcement being discarded, leading to
      traffic intended for AS62915 not being routed correctly.



















Zhang, et al.            Expires 29 August 2024                 [Page 4]

Internet-Draft               VRP Aggregation               February 2024


                           +------------------------------------------+
                           | Announce |       76.191.64.0/18 √        |
         (Provider)AS11404 +------------------------------------------+
                     |     | RPKI ROA |  76.191.64.0/18, AS11404, 24  |
                     |     +------------------------------------------+
                     |
                     |     +----------------------------------------+
                     |     | Announce |      76.191.74.0/23 √       |
                     |     | Announce |      76.191.76.0/22 x       |
                     |     +----------------------------------------+
         (Customer)AS62915 |          | 76.191.74.0/23, AS62915, 24 |
                           | RPKI ROA | 76.191.76.0/23, AS62915, 24 |
                           |          | 76.191.78.0/23, AS62915, 24 |
                           +----------------------------------------+


          Figure 1: Prefix 76.191.76.0/22 announced by AS62915 is
      erroneously validated as "Invalid".  A '√' symbol following the
      prefix indicates that it has been validated as "Valid", while a
                      'x' symbol indicates "Invalid".

2.2.  Traffic Engineering

   Internet Service Providers (ISPs) might utilize traffic engineering
   to enhance the network resource utilization, optimize network
   performance, and ensure Quality of Service (QoS).  In this context,
   operators might announce multiple prefixes with parent-child
   relationships for the following considerations.  If only the sub-
   prefixes are registered in RPKI, the parent prefix will be unable to
   be validated.

   *  Path Redundancy.  In the scenario of multi-homing, child prefixes
      are announced to certain providers, while the parent prefix is
      announced to others.  The parent prefix path can serve as a backup
      path.  Thus, if the child prefix becomes unreachable, traffic can
      still be routed via the parent prefix.  The parent route
      60.244.0.0/16 from AS7482 in Figure 2 works as a backup path.  If
      there are failures in the path of the route announcement for the
      sub-prefix 60.244.0.0/18, the existence of the announcement of
      60.244.0.0/16 ensures that traffic can still be routed to AS7482
      via providers AS15412 and AS17709, maintaining network stability
      and reachability.  However, despite AS7482 announcing the prefix
      60.244.0.0/16 in the global BGP routing table, it has only been
      authorized to originate a set of contiguous sub-prefixes in two
      ROAs (60.244.0.0/17, AS7482, maxlength=24) and (60.244.128.0/17,
      AS7482, maxlength=24).  These two registered sub-prefixes can be
      aggregated into the parent prefix 60.244.0.0/16.  However, since
      there are two ROAs (60.244.0.0/16, AS17709, maxlength=24) and



Zhang, et al.            Expires 29 August 2024                 [Page 5]

Internet-Draft               VRP Aggregation               February 2024


      (60.244.0.0/16, AS17709, maxlength=17) that authorized the prefix
      60.244.0.0/16 to be originated from AS17709, the provider of
      AS7482, this BGP route anouncement is erroneously validated as
      "Invalid".



  (Provider)AS15412     AS4780    AS4637
                  \       |       /
                   \      |      /
                    \     |     /
                     \    |    /
                      \   |   /+---------------------------------------+
                       AS17709  | RPKI ROA | 60.244.0.0/16, AS17709, 24 |
                          |     | RPKI ROA | 60.244.0.0/16, AS17709, 17 |
                          |     +---------------------------------------+
                          |
                          |     +----------------------------------------+
              (Customer)AS7482  | RPKI ROA | 60.244.0.0/17,   AS7482, 24 |
                                | RPKI ROA | 60.244.128.0/17, AS7482, 24 |
                                +----------------------------------------+
+-------------------------------------------------------------------------+
|                         BGP Route Announcement                          |
|Stat|    Prefix   |                     AS_PATH                          |
+-------------------------------------------------------------------------+
| √  |60.244.0.0/18|* 4637  17709 7482                                    |
| √  |60.244.0.0/18|* 4780  17709 17709 17709 7482                        |
| x  |60.244.0.0/16|* 15412 17709 17709 17709 17709 17709 17709 17709 7482|
+-------------------------------------------------------------------------+


  Figure 2: Prefix 60.244.0.0/16 announced by AS7482 is erroneously
     validated as "Invalid".  The '*' symbol in AS_PATH indicates
      other ASes in the path that are irrelevant to the traffic
  engineering policy.  From top to bottom, the relationships are in
                    a provider-customer hierarchy.

   *  Load Balancing.  If an AS is connected to multiple upstream
      providers, it may announce different parent and child prefixes
      through different providers to achieve fine-grained traffic
      distribution, thus accomplishing load balancing.  As shown in
      Figure 3, the parent prefix 93.113.148.0/22 is only announced
      through AS6762, while its sub-prefix 93.113.150.0/24 is announced
      through three providers, AS6939, AS2914, and AS6762, which could
      achieve load balancing.  However, AS49367 has not been authorized
      to originate the parent prefix, this BGP route announcement for
      93.113.148.0/22 is validated as "Unknown".




Zhang, et al.            Expires 29 August 2024                 [Page 6]

Internet-Draft               VRP Aggregation               February 2024


  (Provider)AS2914  AS6762   AS6939
                \     |      /
                 \    |     /
                  \   |    / +-----------------------------------------+
                   \  |   /  |          | 93.113.148.0/24, AS49367, 24 |
                             |          | 93.113.149.0/24, AS49367, 24 |
          (Customer)AS49367  | RPKI ROA | 93.113.150.0/24, AS49367, 24 |
                             |          | 93.113.151.0/24, AS49367, 24 |
                             +-----------------------------------------+
    +------------------------------------------------+
    |             BGP Route Announcement             |
    | Status|      Prefix     |        AS_PATH       |
    +------------------------------------------------+
    |   √   | 93.113.150.0/24 | * 6939 49367         |
    |   √   | 93.113.150.0/24 | * 2914 49367         |
    |   √   | 93.113.150.0/24 | * 6762 49367         |
    |   o   | 93.113.148.0/22 | * 6762 49367         |
    +------------------------------------------------+


         Figure 3: Prefix 93.113.148.0/22 announced by AS49367 is
     erroneously validated as "Unknown".  A 'o' symbol following the
    prefix indicates that it has been validated as "Unknown", while a
                      '√' symbol indicates "Valid".

   *  Traffic shaping, performance optimization, etc.  For reasons such
      as traffic shaping and performance optimization, an AS may
      announce multiple prefixes that have a parent-child relationship.
      In this case, if the AS has only been authorized to originate the
      sub-prefixes it owns, this would result in the parent prefix not
      being validated as "Valid".

2.3.  Incomplete or inaccurate registration

   RPKI is still in the process of incremental deployment; therefore,
   some prefixes have not yet been registered.  Additionally, some ISPs
   do not maintain consistency between the ROAs registered in RPKI and
   the prefixes they announce.  They may also fail to register the
   aggregated parent prefix in a timely manner after implementing an
   aggregation policy, leading to validation issues.

3.  Algorithm and Implementation of VRP Aggregation

   To address the problem described above, this document suggests
   extending VRPs by aggregating contiguous prefixes from the same AS
   into new VRPs.  This section introduces a preliminary algorithm for
   VRP aggregation and details the implementation process, ensuring the
   correctness of the newly aggregated VRP.



Zhang, et al.            Expires 29 August 2024                 [Page 7]

Internet-Draft               VRP Aggregation               February 2024


3.1.  Algorithm Rationality

   This document suggests extending VRPs by aggregating those that
   contain contiguous prefixes authorized to the same AS.  In this
   context, "contiguous" refers to IP address ranges that are
   sequentially contiguous in binary representation.  This implies that
   the IP address spaces represented by the prefixes do not overlap with
   each other and there are no gaps between them.

   The content of the ROA identifies that an IP address block holder has
   authorized an AS to announce routes to one or more prefixes within
   the address block.  If an AS is authorized to several multiple
   contiguous IP address prefixes, it signifies that the AS can
   facilitate route reachability for the IP address blocks corresponding
   to these prefixes.  Therefore, if this AS announces a parent prefix
   that aggregates these contiguous sub-prefixes, the routing to this
   parent prefix should also be considered accessible and recognized as
   a "Valid" route announcement.

   The address holder is often not aware of network routing policies
   when issuing ROAs.  The current RPKI architecture does not provide a
   mechanism to accommodate these dynamic changes in the registered
   ROAs.  Therefore, this document advocates for the development of
   specialized extending the aggregated VRP aggregation to address this
   issue and achieve the aforementioned goal.

3.2.  Aggregatable ROA Payload

   The fundamental principle of VRP Aggregation is to ensure the
   correctness of the newly generated prefixes after aggregation.  In
   line with this principle, this document puts forward three rules for
   VRP aggregation.

   1.  Only contiguous prefixes from the same AS can be aggregated.

   2.  Only contiguous prefixes with the same maxLength can be
       aggregated, taking into account the address holder's specific
       consideration of "maxLength" during ROA registration.  The
       resulting VRP will feature the aggregated parent prefix and will
       inherit the "AS number" and "maxLength" values from the original
       VRPs.

   3.  All aggregatable prefixes will be aggregated into a single,
       largest parent prefix.  Different sets of child prefixes may
       result in multiple potential parent prefixes, but only the
       largest one will be chosen.  For example, the four registered
       sub-prefixes in Figure 3 could be aggregated into either
       93.113.148.0/22 or into two separate prefixes: 93.113.148.0/23



Zhang, et al.            Expires 29 August 2024                 [Page 8]

Internet-Draft               VRP Aggregation               February 2024


       and 93.113.150.0/23.  However, only 93.113.148.0/22 will be
       retained, and the aggregated VRP will be represented as
       (93.113.148.0/22, AS49367, maxlength=24).  This approach ensures
       that if BGP route advertises any other parent prefixes that could
       potentially be aggregated into(e.g., 93.113.148.0/23), they can
       still be validated as "Valid" by referencing the largest
       aggregated ROA (93.113.148.0/22, AS49367, maxlength=24).

3.3.  Implementation of VRP Aggregation

   This document recommends feature extensions for routers.  An
   algorithm for implementation of the VRP Aggregation is outlined as
   follows.

   1.  Once synchronizing all the VRPs from RP, the router aggregates
       the current VRPs and stores the new, aggregated prefixes and AS
       numbers in the VRP format as specified in [RFC6811].  The
       original and aggregated VRPs are stored separately.

   2.  When the router receives a BGP update, it performs BGP Route
       Origin Validation (ROV) [RFC6811] with the original, unaggregated
       VRPs.

   3.  If the validity state of the received BGP route is determined to
       be "Valid", go to Step 4.  If the validity state of the received
       BGP route is "Invalid" or "Unknown", the router then performs ROV
       with the newly aggregated VRPs.  If the newly determined validity
       state is "Valid", the router accepts this BGP route.  However, if
       the new validity state remains "Invalid" or "Unknown", the router
       ignores this outcome, and the validity state of this BGP route
       remains as it was determined during the initial validation (Step
       2).

   4.  The router applies the validity state of the BGP route to the
       route selection [RFC6483].

   The usage of aggregated VRP is different from the original VRP.  The
   aggregated VRPs serve as a retrospective correction mechanism that
   supplements some potentially valid route announcements.  If there is
   a route announcement whose prefix and origin AS match the aggregated
   VRP, it allows that route announcement to be validated as "Valid".
   However, the presence of an aggregated VRP does not necessarily mean
   that the AS will announce the aggregated prefix, nor could it
   validate any other route announcements that do not match as
   "Invalid".  Consequently, routers require modifications to employ the
   ROV process differently for aggregated VRPs than for the original
   VRPs, as previously described.




Zhang, et al.            Expires 29 August 2024                 [Page 9]

Internet-Draft               VRP Aggregation               February 2024


3.4.  Considerations for VRP Aggregation Algorithm and Implementation

   In the context of VRP aggregation, only the validity state validated
   as "Valid" by the aggregated VRPs is adopted.  This is because the
   aggregated VRPs only provide certain potential BGP route
   announcements, indicating that these route announcements are
   reasonable if they occur.  However, it can not validate the state of
   route announcements originating from other ASes.

   For example, as shown in Figure 4, the two sub-prefixes authorized to
   be originated by AS4809 in two ROAs in RPKI could be aggregated in
   (202.111.192.0/19, AS4809, maxlength=20).  However, AS4809 does not
   announce the parent prefix 202.111.192.0/19; instead, its provider
   AS4134 does.  In this case, the aggregated VRP may cause the route
   announcement for the parent prefix to be validated as "Invalid"
   instead of "Unknown".  If the router were to reject this route
   announcement (202.111.192.0/19), it could disrupt the corresponding
   traffic.  Consequently, the validation results from the aggregated
   VRPs that are validated as "Invalid" are not accepted.

   In fact, such a situation can be avoided if the address space holders
   register all of the route announcements they may advertise in RPKI;
   for instance, AS4134 could be authorized to originate the prefix
   202.111.192.0/19.  However, given the current low rate of ROA
   registration in RPKI, we choose not to adopt the instances where the
   aggregated VRPs validate a route as "Invalid" or "Unknown", to avoid
   unnecessary discarding of traffic.



                           +----------------------------------------+
                           | Announce |     202.111.192.0/19        |
         (Provider)AS4134  +----------------------------------------+
                     |
                     |
                     |     +-----------------------------------------+
                     |     | Announce |      202.111.192.0/20        |
                     |     | Announce |      202.111.208.0/20        |
                     |     +-----------------------------------------+
         (Customer)AS4809  |          | 202.111.192.0/20, AS4809, 20 |
                           | RPKI ROA | 202.111.208.0/20, AS4809, 20 |
                           +-----------------------------------------+
                       +-----------------------------------------------+
                       | Aggregated VRP | 202.111.192.0/19, AS4809, 20 |
                       +-----------------------------------------------+






Zhang, et al.            Expires 29 August 2024                [Page 10]

Internet-Draft               VRP Aggregation               February 2024


          Figure 4: Prefix 202.111.192.0/19 announced by AS4134 is
       validated as "Invalid" by the aggregated VRP.  In such a case,
       the validity state will not be accepted and it will retain the
              validity state determined by the original VRPs.

4.  Security Considerations

   TBD.

5.  IANA Considerations

   TBD.

6.  References

6.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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6483]  Huston, G. and G. Michaelson, "Validation of Route
              Origination Using the Resource Certificate Public Key
              Infrastructure (PKI) and Route Origin Authorizations
              (ROAs)", RFC 6483, DOI 10.17487/RFC6483, February 2012,
              <https://www.rfc-editor.org/info/rfc6483>.

   [RFC6811]  Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
              Austein, "BGP Prefix Origin Validation", RFC 6811,
              DOI 10.17487/RFC6811, January 2013,
              <https://www.rfc-editor.org/info/rfc6811>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

6.2.  Informative References

   [RFC6481]  Huston, G., Loomans, R., and G. Michaelson, "A Profile for
              Resource Certificate Repository Structure", RFC 6481,
              DOI 10.17487/RFC6481, February 2012,
              <https://www.rfc-editor.org/info/rfc6481>.

   [RFC8897]  Ma, D. and S. Kent, "Requirements for Resource Public Key
              Infrastructure (RPKI) Relying Parties", RFC 8897,
              DOI 10.17487/RFC8897, September 2020,
              <https://www.rfc-editor.org/info/rfc8897>.



Zhang, et al.            Expires 29 August 2024                [Page 11]

Internet-Draft               VRP Aggregation               February 2024


Acknowledgements

   TBD.

Authors' Addresses

   Jia Zhang
   Zhongguancun Laboratory
   Email: zhangj@mail.zgclab.edu.cn


   Mingwei Xu
   Tsinghua University
   Email: xmw@cernet.edu.cn


   Yangyang Wang
   Tsinghua University
   Email: wangyy@cernet.edu.cn
































Zhang, et al.            Expires 29 August 2024                [Page 12]