Network Working Group O. Kolkman
Request for Comments: 3757 RIPE NCC
Updates: 3755, 2535 J. Schlyter
Category: Standards Track NIC-SE
E. Lewis
ARIN
April 2004
Network Working Group O. Kolkman
Request for Comments: 3757 RIPE NCC
Updates: 3755, 2535 J. Schlyter
Category: Standards Track NIC-SE
E. Lewis
ARIN
April 2004
Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag
域名系统密钥（DNSKEY）资源记录（RR）安全入口点（SEP）标志
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
With the Delegation Signer (DS) resource record (RR), the concept of a public key acting as a secure entry point (SEP) has been introduced. During exchanges of public keys with the parent there is a need to differentiate SEP keys from other public keys in the Domain Name System KEY (DNSKEY) resource record set. A flag bit in the DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP. The flag bit is intended to assist in operational procedures to correctly generate DS resource records, or to indicate what DNSKEYs are intended for static configuration. The flag bit is not to be used in the DNS verification protocol. This document updates RFC 2535 and RFC 3755.
在委托签名者（DS）资源记录（RR）中，引入了公钥作为安全入口点（SEP）的概念。在与父级交换公钥期间，需要将SEP密钥与域名系统密钥（DNSKEY）资源记录集中的其他公钥区分开来。DNSKEY RR中的标志位用于指示DNSKEY将用作SEP。标志位用于帮助操作过程正确生成DS资源记录，或指示用于静态配置的DNSKEY。在DNS验证协议中不使用标志位。本文件更新了RFC 2535和RFC 3755。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Secure Entry Point (SEP) Flag. . . . . . . . . . . . . . . 4
3. DNSSEC Protocol Changes. . . . . . . . . . . . . . . . . . . . 4
4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
7. Internationalization Considerations. . . . . . . . . . . . . . 6
8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 6
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Secure Entry Point (SEP) Flag. . . . . . . . . . . . . . . 4
3. DNSSEC Protocol Changes. . . . . . . . . . . . . . . . . . . . 4
4. Operational Guidelines . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6
7. Internationalization Considerations. . . . . . . . . . . . . . 6
8. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 6
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Normative References . . . . . . . . . . . . . . . . . . 6
9.2. Informative References . . . . . . . . . . . . . . . . . 6
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
"All keys are equal but some keys are more equal than others" [6].
“所有键都相等，但有些键比其他键更相等”[6]。
With the definition of the Delegation Signer Resource Record (DS RR) [5], it has become important to differentiate between the keys in the DNSKEY RR set that are (to be) pointed to by parental DS RRs and the other keys in the DNSKEY RR set. We refer to these public keys as Secure Entry Point (SEP) keys. A SEP key either used to generate a DS RR or is distributed to resolvers that use the key as the root of a trusted subtree [3].
根据委托签名者资源记录（DS RR）[5]的定义，区分父母DS RR指向的DNSKEY RR集中的密钥和DNSKEY RR集中的其他密钥变得非常重要。我们将这些公钥称为安全入口点（SEP）密钥。SEP密钥用于生成DS RR，或分发给使用该密钥作为可信子树根的解析程序[3]。
In early deployment tests, the use of two (kinds of) key pairs for each zone has been prevalent. For one kind of key pair the private key is used to sign just the zone's DNSKEY resource record (RR) set. Its public key is intended to be referenced by a DS RR at the parent or configured statically in a resolver. The private key of the other kind of key pair is used to sign the rest of the zone's data sets. The former key pair is called a key-signing key (KSK) and the latter is called a zone-signing key (ZSK). In practice there have been usually one of each kind of key pair, but there will be multiples of each at times.
在早期部署测试中，对每个区域使用两个（种类）密钥对已经很普遍。对于一种密钥对，私钥仅用于对区域的DNSKEY资源记录（RR）集进行签名。它的公钥旨在由父级的DS RR引用或在解析器中静态配置。另一种密钥对的私钥用于对区域的其余数据集进行签名。前一个密钥对称为密钥签名密钥（KSK），后一个称为区域签名密钥（ZSK）。实际上，每种密钥对通常都有一个，但每次都会有多个。
It should be noted that division of keys pairs into KSK's and ZSK's is not mandatory in any definition of DNSSEC, not even with the introduction of the DS RR. But, in testing, this distinction has been helpful when designing key roll over (key super-cession) schemes. Given that the distinction has proven helpful, the labels KSK and ZSK have begun to stick.
应该注意的是，在DNSSEC的任何定义中，将密钥对划分为KSK和ZSK都不是强制性的，即使引入DS RR也不是强制性的。但是，在测试中，这种区别在设计密钥翻滚（密钥超级让与）方案时非常有用。鉴于这种区别已经证明是有帮助的，KSK和ZSK的标签已经开始贴上。
There is a need to differentiate the public keys for the key pairs that are used for key signing from keys that are not used key signing (KSKs vs ZSKs). This need is driven by knowing which DNSKEYs are to be sent for generating DS RRs, which DNSKEYs are to be distributed to resolvers, and which keys are fed to the signer application at the appropriate time.
需要区分用于密钥签名的密钥对的公钥与未用于密钥签名的密钥（KSK与ZSK）。这一需求的驱动因素是知道要发送哪些DNSKEY以生成DS RRs，哪些DNSKEY要分发给解析程序，以及哪些密钥在适当的时间提供给签名者应用程序。
In other words, the SEP bit provides an in-band method to communicate a DNSKEY RR's intended use to third parties. As an example we present 3 use cases in which the bit is useful:
换句话说，SEP位提供带内方法，将DNSKEY RR的预期用途传达给第三方。作为一个例子，我们给出了3个bit有用的用例：
The parent is a registry, the parent and the child use secured DNS queries and responses, with a preexisting trust-relation, or plain DNS over a secured channel to exchange the child's DNSKEY RR sets. Since a DNSKEY RR set will contain a complete DNSKEY RRset the SEP bit can be used to isolate the DNSKEYs for which a DS RR needs to be created.
父级是一个注册表，父级和子级使用安全DNS查询和响应（具有预先存在的信任关系）或通过安全通道的普通DNS来交换子级的DNSKEY RR集。由于DNSKEY RR集将包含完整的DNSKEY RR集，因此SEP位可用于隔离需要为其创建DS RR的DNSKEY。
An administrator has configured a DNSKEY as root for a trusted subtree into security aware resolver. Using a special purpose tool that queries for the KEY RRs from that domain's apex, the administrator will be able to notice the roll over of the trusted anchor by a change of the subset of KEY RRs with the DS flag set.
管理员已将DNSKEY配置为受信任子树的根目录，并将其配置为具有安全意识的冲突解决程序。使用从该域的顶点查询密钥RRs的专用工具，管理员将能够通过设置DS标志更改密钥RRs子集来注意到受信任锚的滚动。
A signer might use the SEP bit on the public key to determine which private key to use to exclusively sign the DNSKEY RRset and which private key to use to sign the other RRsets in the zone.
签名者可以使用公钥上的SEP位来确定使用哪个私钥对DNSKEY RRset进行独占签名，以及使用哪个私钥对区域中的其他RRset进行签名。
As demonstrated in the above examples it is important to be able to differentiate the SEP keys from the other keys in a DNSKEY RR set in the flow between signer and (parental) key-collector and in the flow between the signer and the resolver configuration. The SEP flag is to be of no interest to the flow between the verifier and the authoritative data store.
如上述示例所示，在签名者和（家长）密钥收集器之间的流以及签名者和解析程序配置之间的流中，能够将SEP密钥与DNSKEY RR集合中的其他密钥区分开来非常重要。SEP标志与验证器和权威数据存储之间的流无关。
The reason for the term "SEP" is a result of the observation that the distinction between KSK and ZSK key pairs is made by the signer, a key pair could be used as both a KSK and a ZSK at the same time. To be clear, the term SEP was coined to lessen the confusion caused by the overlap. (Once this label was applied, it had the side effect of removing the temptation to have both a KSK flag bit and a ZSK flag bit.)
术语“SEP”的原因是由于观察到签名者对KSK和ZSK密钥对进行了区分，密钥对可以同时用作KSK和ZSK。明确地说，SEP一词的出现是为了减少重叠造成的混乱。（应用此标签后，其副作用是消除同时使用KSK标志位和ZSK标志位的诱惑。）
The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED", "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
本文件中的关键词“可”、“不可”、“必须”、“不得”、“要求”、“建议”、“应”和“不应”应按照BCP 14、RFC 2119[1]中的说明进行解释。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |S| protocol | algorithm |
| |E| | |
| |P| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags |S| protocol | algorithm |
| |E| | |
| |P| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
/ public key /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DNSKEY RR Format This document assigns the 15th bit in the flags field as the secure entry point (SEP) bit. If the bit is set to 1 the key is intended to be used as secure entry point key. One SHOULD NOT assign special meaning to the key if the bit is set to 0. Operators can recognize the secure entry point key by the even or odd-ness of the decimal representation of the flag field.
DNSKEY RR格式此文档将标志字段中的第15位指定为安全入口点（SEP）位。如果位设置为1，则该密钥将用作安全入口点密钥。如果位设置为0，则不应为键指定特殊含义。操作员可以通过标志字段十进制表示的偶数或奇数来识别安全入口点密钥。
The bit MUST NOT be used during the resolving and verification process. The SEP flag is only used to provide a hint about the different administrative properties of the key and therefore the use of the SEP flag does not change the DNS resolution protocol or the resolution process.
解析和验证过程中不得使用位。SEP标志仅用于提供有关密钥的不同管理属性的提示，因此使用SEP标志不会更改DNS解析协议或解析过程。
The SEP bit is set by the key-pair-generator and MAY be used by the zone signer to decide whether the public part of the key pair is to be prepared for input to a DS RR generation function. The SEP bit is recommended to be set (to 1) whenever the public key of the key pair will be distributed to the parent zone to build the authentication chain or if the public key is to be distributed for static configuration in verifiers.
SEP位由密钥对生成器设置，区域签名者可以使用SEP位来决定密钥对的公共部分是否准备好输入DS RR生成函数。每当密钥对的公钥将分发到父区域以构建身份验证链时，或者如果要分发公钥以在验证器中进行静态配置时，建议将SEP位设置为（1）。
When a key pair is created, the operator needs to indicate whether the SEP bit is to be set in the DNSKEY RR. As the SEP bit is within the data that is used to compute the 'key tag field' in the SIG RR, changing the SEP bit will change the identity of the key within DNS. In other words, once a key is used to generate signatures, the setting of the SEP bit is to remain constant. If not, a verifier will not be able to find the relevant KEY RR.
创建密钥对时，操作员需要指示是否在DNSKEY RR中设置SEP位。由于SEP位位于用于计算SIG RR中“密钥标记字段”的数据中，因此更改SEP位将更改DNS中密钥的标识。换句话说，一旦密钥用于生成签名，SEP位的设置将保持不变。如果没有，验证器将无法找到相关的密钥RR。
When signing a zone, it is intended that the key(s) with the SEP bit set (if such keys exist) are used to sign the KEY RR set of the zone. The same key can be used to sign the rest of the zone data too. It is conceivable that not all keys with a SEP bit set will sign the DNSKEY RR set, such keys might be pending retirement or not yet in use.
对区域进行签名时，打算使用SEP位设置的密钥（如果存在此类密钥）对区域的密钥RR集进行签名。同样的密钥也可以用于对区域数据的其余部分进行签名。可以想象，并非所有具有SEP位集的密钥都会对DNSKEY RR集进行签名，这些密钥可能正在等待退役或尚未使用。
When verifying a RR set, the SEP bit is not intended to play a role. How the key is used by the verifier is not intended to be a consideration at key creation time.
验证RR集时，SEP位不起作用。验证器如何使用密钥并不打算在密钥创建时考虑。
Although the SEP flag provides a hint on which public key is to be used as trusted root, administrators can choose to ignore the fact that a DNSKEY has its SEP bit set or not when configuring a trusted root for their resolvers.
尽管SEP标志提供了将哪个公钥用作受信任根的提示，但在为其解析程序配置受信任根时，管理员可以选择忽略DNSKEY是否设置了SEP位这一事实。
Using the SEP flag a key roll over can be automated. The parent can use an existing trust relation to verify DNSKEY RR sets in which a new DNSKEY RR with the SEP flag appears.
使用SEP标志可以自动进行钥匙翻滚。父级可以使用现有的信任关系来验证DNSKEY RR集合，其中显示了带有SEP标志的新DNSKEY RR。
As stated in Section 3 the flag is not to be used in the resolution protocol or to determine the security status of a key. The flag is to be used for administrative purposes only.
如第3节所述，该标志不得用于解决协议或确定密钥的安全状态。该标志仅用于管理目的。
No trust in a key should be inferred from this flag - trust MUST be inferred from an existing chain of trust or an out-of-band exchange.
不应从该标志推断密钥中的信任-必须从现有信任链或带外交换推断信任。
Since this flag might be used for automating public key exchanges, we think the following consideration is in place.
由于此标志可能用于自动化公钥交换，因此我们认为需要考虑以下事项。
Automated mechanisms for roll over of the DS RR might be vulnerable to a class of replay attacks. This might happen after a public key exchange where a DNSKEY RR set, containing two DNSKEY RRs with the SEP flag set, is sent to the parent. The parent verifies the DNSKEY RR set with the existing trust relation and creates the new DS RR from the DNSKEY RR that the current DS RR is not pointing to. This key exchange might be replayed. Parents are encouraged to implement a replay defense. A simple defense can be based on a registry of keys that have been used to generate DS RRs during the most recent roll over. These same considerations apply to entities that configure keys in resolvers.
DS RR的自动翻滚机制可能容易受到一类重放攻击的攻击。这可能发生在公钥交换之后，其中一个DNSKEY RR集（包含两个带有SEP标志集的DNSKEY RR）被发送到父级。父级使用现有信任关系验证DNSKEY RR集，并从当前DS RR未指向的DNSKEY RR创建新的DS RR。此密钥交换可能会被重播。鼓励家长实施重播防御。一个简单的防御可以基于最近一次翻滚期间用于生成DS RRs的注册表项。这些注意事项同样适用于在解析器中配置密钥的实体。
IANA has assigned the 15th bit in the DNSKEY Flags Registry (see Section 4.3 of [4]) as the Secure Entry Point (SEP) bit.
IANA已将DNSKEY标志注册表中的第15位（见[4]第4.3节）指定为安全入口点（SEP）位。
Although SEP is a popular acronym in many different languages, there are no internationalization considerations.
虽然SEP在许多不同的语言中都是一个流行的首字母缩略词，但没有国际化的考虑。
The ideas documented in this document are inspired by communications we had with numerous people and ideas published by other folk. Among others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson, Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler have contributed ideas and provided feedback.
本文件中记录的想法来自于我们与许多人的交流以及其他人发表的想法。马克·安德鲁斯、罗布·奥斯汀、米克·吉本、奥拉弗尔·古德蒙德森、丹尼尔·卡伦伯格、丹·梅西、斯科特·罗斯、马科斯·桑兹和萨姆·韦勒等都提出了自己的想法并提供了反馈。
This document saw the light during a workshop on DNSSEC operations hosted by USC/ISI in August 2002.
2002年8月，在USC/ISI主办的DNSSEC运营研讨会上，本文件得以发布。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[2] Eastlake，D.，“域名系统安全扩展”，RFC 25351999年3月。
[3] Lewis, E., "DNS Security Extension Clarification on Zone Status", RFC 3090, March 2001.
[3] Lewis，E.“关于区域状态的DNS安全扩展澄清”，RFC 3090，2001年3月。
[4] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, April 2004.
[4] Weiler，S.，“委托签名者（DS）的传统解析器兼容性”，RFC 3755，2004年4月。
[5] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)", RFC 3658, December 2003.
[5] Gudmundsson，O.，“委托签署人（DS）资源记录（RR）”，RFC3658，2003年12月。
[6] Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy Story", ISBN 0151002177 (50th anniversary edition), April 1996.
[6] 奥威尔，G.和R.斯蒂德曼（插图画家），“动物农场；童话故事”，ISBN 0151002177（50周年纪念版），1996年4月。
Olaf M. Kolkman RIPE NCC Singel 256 Amsterdam 1016 AB NL
Olaf M.Kolkman成熟NCC Singel 256阿姆斯特丹1016 AB NL
Phone: +31 20 535 4444
EMail: olaf@ripe.net
URI: http://www.ripe.net/
Phone: +31 20 535 4444
EMail: olaf@ripe.net
URI: http://www.ripe.net/
Jakob Schlyter NIC-SE Box 5774 SE-114 87 Stockholm Sweden
Jakob Schlyter NIC-SE信箱5774 SE-114 87瑞典斯德哥尔摩
EMail: jakob@nic.se
URI: http://www.nic.se/
EMail: jakob@nic.se
URI: http://www.nic.se/
Edward P. Lewis ARIN 3635 Concorde Parkway Suite 200 Chantilly, VA 20151 US
爱德华·P·刘易斯·阿林3635协和式公园道套房200号，弗吉尼亚州尚蒂利，美国20151
Phone: +1 703 227 9854
EMail: edlewis@arin.net
URI: http://www.arin.net/
Phone: +1 703 227 9854
EMail: edlewis@arin.net
URI: http://www.arin.net/
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。