Network Working Group G. Jones, Ed.
Request for Comments: 3871 The MITRE Corporation
Category: Informational September 2004
Network Working Group G. Jones, Ed.
Request for Comments: 3871 The MITRE Corporation
Category: Informational September 2004
Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure
大型互联网服务提供商（ISP）IP网络基础设施的操作安全要求
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document defines a list of operational security requirements for the infrastructure of large Internet Service Provider (ISP) IP networks (routers and switches). A framework is defined for specifying "profiles", which are collections of requirements applicable to certain network topology contexts (all, core-only, edge-only...). The goal is to provide network operators a clear, concise way of communicating their security requirements to vendors.
本文件定义了大型互联网服务提供商（ISP）IP网络（路由器和交换机）基础设施的操作安全要求列表。定义了用于指定“概要文件”的框架，这些概要文件是适用于特定网络拓扑上下文（全部、仅核心、仅边缘…）的需求集合。目标是为网络运营商提供一种清晰、简洁的方式，向供应商传达其安全要求。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Goals. . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Definition of a Secure Network . . . . . . . . . . . . . 6
1.5. Intended Audience. . . . . . . . . . . . . . . . . . . . 6
1.6. Format . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.7. Intended Use . . . . . . . . . . . . . . . . . . . . . . 7
1.8. Definitions. . . . . . . . . . . . . . . . . . . . . . . 7
2. Functional Requirements . . . . . . . . . . . . . . . . . . . 11
2.1. Device Management Requirements . . . . . . . . . . . . . 11
2.1.1. Support Secure Channels For Management. . . . . 11
2.2. In-Band Management Requirements. . . . . . . . . . . . . 12
2.2.1. Use Cryptographic Algorithms Subject To
Open Review . . . . . . . . . . . . . . . . . . 12
2.2.2. Use Strong Cryptography . . . . . . . . . . . . 13
2.2.3. Use Protocols Subject To Open Review For
Management. . . . . . . . . . . . . . . . . . . 14
2.2.4. Allow Selection of Cryptographic Parameters . . 15
2.2.5. Management Functions Should Have Increased
Priority. . . . . . . . . . . . . . . . . . . . 16
2.3. Out-of-Band (OoB) Management Requirements . . . . . . . 16
2.3.1. Support a 'Console' Interface . . . . . . . . . 17
2.3.2. 'Console' Communication Profile Must Support
Reset . . . . . . . . . . . . . . . . . . . . . 19
2.3.3. 'Console' Requires Minimal Functionality of
Attached Devices. . . . . . . . . . . . . . . . 19
2.3.4. 'Console' Supports Fall-back Authentication . . 20
2.3.5. Support Separate Management Plane IP
Interfaces. . . . . . . . . . . . . . . . . . . 21
2.3.6. No Forwarding Between Management Plane And Other
Interfaces. . . . . . . . . . . . . . . . . . . 21
2.4. Configuration and Management Interface Requirements. . . 22
2.4.1. 'CLI' Provides Access to All Configuration and
Management Functions. . . . . . . . . . . . . . 22
2.4.2. 'CLI' Supports Scripting of Configuration . . . 23
2.4.3. 'CLI' Supports Management Over 'Slow' Links . . 24
2.4.4. 'CLI' Supports Idle Session Timeout . . . . . . 25
2.4.5. Support Software Installation . . . . . . . . . 25
2.4.6. Support Remote Configuration Backup . . . . . . 27
2.4.7. Support Remote Configuration Restore. . . . . . 27
2.4.8. Support Text Configuration Files. . . . . . . . 28
2.5. IP Stack Requirements. . . . . . . . . . . . . . . . . . 29
2.5.1. Ability to Identify All Listening Services. . . 29
2.5.2. Ability to Disable Any and All Services . . . . 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Goals. . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Scope. . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Definition of a Secure Network . . . . . . . . . . . . . 6
1.5. Intended Audience. . . . . . . . . . . . . . . . . . . . 6
1.6. Format . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.7. Intended Use . . . . . . . . . . . . . . . . . . . . . . 7
1.8. Definitions. . . . . . . . . . . . . . . . . . . . . . . 7
2. Functional Requirements . . . . . . . . . . . . . . . . . . . 11
2.1. Device Management Requirements . . . . . . . . . . . . . 11
2.1.1. Support Secure Channels For Management. . . . . 11
2.2. In-Band Management Requirements. . . . . . . . . . . . . 12
2.2.1. Use Cryptographic Algorithms Subject To
Open Review . . . . . . . . . . . . . . . . . . 12
2.2.2. Use Strong Cryptography . . . . . . . . . . . . 13
2.2.3. Use Protocols Subject To Open Review For
Management. . . . . . . . . . . . . . . . . . . 14
2.2.4. Allow Selection of Cryptographic Parameters . . 15
2.2.5. Management Functions Should Have Increased
Priority. . . . . . . . . . . . . . . . . . . . 16
2.3. Out-of-Band (OoB) Management Requirements . . . . . . . 16
2.3.1. Support a 'Console' Interface . . . . . . . . . 17
2.3.2. 'Console' Communication Profile Must Support
Reset . . . . . . . . . . . . . . . . . . . . . 19
2.3.3. 'Console' Requires Minimal Functionality of
Attached Devices. . . . . . . . . . . . . . . . 19
2.3.4. 'Console' Supports Fall-back Authentication . . 20
2.3.5. Support Separate Management Plane IP
Interfaces. . . . . . . . . . . . . . . . . . . 21
2.3.6. No Forwarding Between Management Plane And Other
Interfaces. . . . . . . . . . . . . . . . . . . 21
2.4. Configuration and Management Interface Requirements. . . 22
2.4.1. 'CLI' Provides Access to All Configuration and
Management Functions. . . . . . . . . . . . . . 22
2.4.2. 'CLI' Supports Scripting of Configuration . . . 23
2.4.3. 'CLI' Supports Management Over 'Slow' Links . . 24
2.4.4. 'CLI' Supports Idle Session Timeout . . . . . . 25
2.4.5. Support Software Installation . . . . . . . . . 25
2.4.6. Support Remote Configuration Backup . . . . . . 27
2.4.7. Support Remote Configuration Restore. . . . . . 27
2.4.8. Support Text Configuration Files. . . . . . . . 28
2.5. IP Stack Requirements. . . . . . . . . . . . . . . . . . 29
2.5.1. Ability to Identify All Listening Services. . . 29
2.5.2. Ability to Disable Any and All Services . . . . 30
2.5.3. Ability to Control Service Bindings for
Listening Services. . . . . . . . . . . . . . . 30
2.5.4. Ability to Control Service Source Addresses . . 31
2.5.5. Support Automatic Anti-spoofing for
Single-Homed Networks . . . . . . . . . . . . . 32
2.5.6. Support Automatic Discarding Of Bogons and
Martians. . . . . . . . . . . . . . . . . . . . 33
2.5.7. Support Counters For Dropped Packets. . . . . . 34
2.6. Rate Limiting Requirements . . . . . . . . . . . . . . . 35
2.6.1. Support Rate Limiting . . . . . . . . . . . . . 35
2.6.2. Support Directional Application Of Rate
Limiting Per Interface. . . . . . . . . . . . . 36
2.6.3. Support Rate Limiting Based on State. . . . . . 36
2.7. Basic Filtering Capabilities . . . . . . . . . . . . . . 37
2.7.1. Ability to Filter Traffic . . . . . . . . . . . 37
2.7.2. Ability to Filter Traffic TO the Device . . . . 37
2.7.3. Ability to Filter Traffic THROUGH the Device. . 38
2.7.4. Ability to Filter Without Significant
Performance Degradation . . . . . . . . . . . . 38
2.7.5. Support Route Filtering . . . . . . . . . . . . 39
2.7.6. Ability to Specify Filter Actions . . . . . . . 40
2.7.7. Ability to Log Filter Actions . . . . . . . . . 40
2.8. Packet Filtering Criteria. . . . . . . . . . . . . . . . 41
2.8.1. Ability to Filter on Protocols. . . . . . . . . 41
2.8.2. Ability to Filter on Addresses. . . . . . . . . 42
2.8.3. Ability to Filter on Protocol Header Fields . . 42
2.8.4. Ability to Filter Inbound and Outbound. . . . . 43
2.9. Packet Filtering Counter Requirements. . . . . . . . . . 43
2.9.1. Ability to Accurately Count Filter Hits . . . . 43
2.9.2. Ability to Display Filter Counters. . . . . . . 44
2.9.3. Ability to Display Filter Counters per Rule . . 45
2.9.4. Ability to Display Filter Counters per Filter
Application . . . . . . . . . . . . . . . . . . 45
2.9.5. Ability to Reset Filter Counters. . . . . . . . 46
2.9.6. Filter Counters Must Be Accurate. . . . . . . . 47
2.10. Other Packet Filtering Requirements . . . . . . . . . . 47
2.10.1. Ability to Specify Filter Log Granularity . . . 47
2.11. Event Logging Requirements . . . . . . . . . . . . . . . 48
2.11.1. Logging Facility Uses Protocols Subject To
Open Review . . . . . . . . . . . . . . . . . . 48
2.11.2. Logs Sent To Remote Servers . . . . . . . . . . 49
2.11.3. Ability to Select Reliable Delivery . . . . . . 49
2.11.4. Ability to Log Locally. . . . . . . . . . . . . 50
2.11.5. Ability to Maintain Accurate System Time. . . . 50
2.11.6. Display Timezone And UTC Offset . . . . . . . . 51
2.11.7. Default Timezone Should Be UTC. . . . . . . . . 52
2.11.8. Logs Must Be Timestamped. . . . . . . . . . . . 52
2.11.9. Logs Contain Untranslated IP Addresses. . . . . 53
2.5.3. Ability to Control Service Bindings for
Listening Services. . . . . . . . . . . . . . . 30
2.5.4. Ability to Control Service Source Addresses . . 31
2.5.5. Support Automatic Anti-spoofing for
Single-Homed Networks . . . . . . . . . . . . . 32
2.5.6. Support Automatic Discarding Of Bogons and
Martians. . . . . . . . . . . . . . . . . . . . 33
2.5.7. Support Counters For Dropped Packets. . . . . . 34
2.6. Rate Limiting Requirements . . . . . . . . . . . . . . . 35
2.6.1. Support Rate Limiting . . . . . . . . . . . . . 35
2.6.2. Support Directional Application Of Rate
Limiting Per Interface. . . . . . . . . . . . . 36
2.6.3. Support Rate Limiting Based on State. . . . . . 36
2.7. Basic Filtering Capabilities . . . . . . . . . . . . . . 37
2.7.1. Ability to Filter Traffic . . . . . . . . . . . 37
2.7.2. Ability to Filter Traffic TO the Device . . . . 37
2.7.3. Ability to Filter Traffic THROUGH the Device. . 38
2.7.4. Ability to Filter Without Significant
Performance Degradation . . . . . . . . . . . . 38
2.7.5. Support Route Filtering . . . . . . . . . . . . 39
2.7.6. Ability to Specify Filter Actions . . . . . . . 40
2.7.7. Ability to Log Filter Actions . . . . . . . . . 40
2.8. Packet Filtering Criteria. . . . . . . . . . . . . . . . 41
2.8.1. Ability to Filter on Protocols. . . . . . . . . 41
2.8.2. Ability to Filter on Addresses. . . . . . . . . 42
2.8.3. Ability to Filter on Protocol Header Fields . . 42
2.8.4. Ability to Filter Inbound and Outbound. . . . . 43
2.9. Packet Filtering Counter Requirements. . . . . . . . . . 43
2.9.1. Ability to Accurately Count Filter Hits . . . . 43
2.9.2. Ability to Display Filter Counters. . . . . . . 44
2.9.3. Ability to Display Filter Counters per Rule . . 45
2.9.4. Ability to Display Filter Counters per Filter
Application . . . . . . . . . . . . . . . . . . 45
2.9.5. Ability to Reset Filter Counters. . . . . . . . 46
2.9.6. Filter Counters Must Be Accurate. . . . . . . . 47
2.10. Other Packet Filtering Requirements . . . . . . . . . . 47
2.10.1. Ability to Specify Filter Log Granularity . . . 47
2.11. Event Logging Requirements . . . . . . . . . . . . . . . 48
2.11.1. Logging Facility Uses Protocols Subject To
Open Review . . . . . . . . . . . . . . . . . . 48
2.11.2. Logs Sent To Remote Servers . . . . . . . . . . 49
2.11.3. Ability to Select Reliable Delivery . . . . . . 49
2.11.4. Ability to Log Locally. . . . . . . . . . . . . 50
2.11.5. Ability to Maintain Accurate System Time. . . . 50
2.11.6. Display Timezone And UTC Offset . . . . . . . . 51
2.11.7. Default Timezone Should Be UTC. . . . . . . . . 52
2.11.8. Logs Must Be Timestamped. . . . . . . . . . . . 52
2.11.9. Logs Contain Untranslated IP Addresses. . . . . 53
2.11.10. Logs Contain Records Of Security Events . . . . 54
2.11.11. Logs Do Not Contain Passwords . . . . . . . . . 55
2.12. Authentication, Authorization, and Accounting (AAA)
Requirements . . . . . . . . . . . . . . . . . . . . . . 55
2.12.1. Authenticate All User Access. . . . . . . . . . 55
2.12.2. Support Authentication of Individual Users. . . 56
2.12.3. Support Simultaneous Connections. . . . . . . . 56
2.12.4. Ability to Disable All Local Accounts . . . . . 57
2.12.5. Support Centralized User Authentication
Methods . . . . . . . . . . . . . . . . . . . . 57
2.12.6. Support Local User Authentication Method. . . . 58
2.12.7. Support Configuration of Order of
Authentication Methods . . . . . . . . . . . . 59
2.12.8. Ability To Authenticate Without Plaintext
Passwords . . . . . . . . . . . . . . . . . . . 59
2.12.9. No Default Passwords. . . . . . . . . . . . . . 60
2.12.10. Passwords Must Be Explicitly Configured Prior
To Use. . . . . . . . . . . . . . . . . . . . . 60
2.12.11. Ability to Define Privilege Levels. . . . . . . 61
2.12.12. Ability to Assign Privilege Levels to Users . . 62
2.12.13. Default Privilege Level Must Be 'None'. . . . . 62
2.12.14. Change in Privilege Levels Requires
Re-Authentication . . . . . . . . . . . . . . . 63
2.12.15. Support Recovery Of Privileged Access . . . . . 64
2.13. Layer 2 Devices Must Meet Higher Layer Requirements. . . 65
2.14. Security Features Must Not Cause Operational Problems. . 65
2.15. Security Features Should Have Minimal Performance
Impact . . . . . . . . . . . . . . . . . . . . . . . . . 66
3. Documentation Requirements . . . . . . . . . . . . . . . . . . 67
3.1. Identify Services That May Be Listening. . . . . . . . . 67
3.2. Document Service Defaults. . . . . . . . . . . . . . . . 67
3.3. Document Service Activation Process. . . . . . . . . . . 68
3.4. Document Command Line Interface. . . . . . . . . . . . . 68
3.5. 'Console' Default Communication Profile Documented . . . 69
4. Assurance Requirements . . . . . . . . . . . . . . . . . . . . 69
4.1. Identify Origin of IP Stack. . . . . . . . . . . . . . . 70
4.2. Identify Origin of Operating System. . . . . . . . . . . 70
5. Security Considerations . . . . . . . . . . . . . . . . . . . 71
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.1. Normative References . . . . . . . . . . . . . . . . . . 71
6.2. Informative References . . . . . . . . . . . . . . . . . 74
Appendices
A. Requirement Profiles . . . . . . . . . . . . . . . . . . . . . 75
A.1. Minimum Requirements Profile . . . . . . . . . . . . . . 75
A.2. Layer 3 Network Edge Profile . . . . . . . . . . . . . . 78
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 80
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 81
2.11.10. Logs Contain Records Of Security Events . . . . 54
2.11.11. Logs Do Not Contain Passwords . . . . . . . . . 55
2.12. Authentication, Authorization, and Accounting (AAA)
Requirements . . . . . . . . . . . . . . . . . . . . . . 55
2.12.1. Authenticate All User Access. . . . . . . . . . 55
2.12.2. Support Authentication of Individual Users. . . 56
2.12.3. Support Simultaneous Connections. . . . . . . . 56
2.12.4. Ability to Disable All Local Accounts . . . . . 57
2.12.5. Support Centralized User Authentication
Methods . . . . . . . . . . . . . . . . . . . . 57
2.12.6. Support Local User Authentication Method. . . . 58
2.12.7. Support Configuration of Order of
Authentication Methods . . . . . . . . . . . . 59
2.12.8. Ability To Authenticate Without Plaintext
Passwords . . . . . . . . . . . . . . . . . . . 59
2.12.9. No Default Passwords. . . . . . . . . . . . . . 60
2.12.10. Passwords Must Be Explicitly Configured Prior
To Use. . . . . . . . . . . . . . . . . . . . . 60
2.12.11. Ability to Define Privilege Levels. . . . . . . 61
2.12.12. Ability to Assign Privilege Levels to Users . . 62
2.12.13. Default Privilege Level Must Be 'None'. . . . . 62
2.12.14. Change in Privilege Levels Requires
Re-Authentication . . . . . . . . . . . . . . . 63
2.12.15. Support Recovery Of Privileged Access . . . . . 64
2.13. Layer 2 Devices Must Meet Higher Layer Requirements. . . 65
2.14. Security Features Must Not Cause Operational Problems. . 65
2.15. Security Features Should Have Minimal Performance
Impact . . . . . . . . . . . . . . . . . . . . . . . . . 66
3. Documentation Requirements . . . . . . . . . . . . . . . . . . 67
3.1. Identify Services That May Be Listening. . . . . . . . . 67
3.2. Document Service Defaults. . . . . . . . . . . . . . . . 67
3.3. Document Service Activation Process. . . . . . . . . . . 68
3.4. Document Command Line Interface. . . . . . . . . . . . . 68
3.5. 'Console' Default Communication Profile Documented . . . 69
4. Assurance Requirements . . . . . . . . . . . . . . . . . . . . 69
4.1. Identify Origin of IP Stack. . . . . . . . . . . . . . . 70
4.2. Identify Origin of Operating System. . . . . . . . . . . 70
5. Security Considerations . . . . . . . . . . . . . . . . . . . 71
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.1. Normative References . . . . . . . . . . . . . . . . . . 71
6.2. Informative References . . . . . . . . . . . . . . . . . 74
Appendices
A. Requirement Profiles . . . . . . . . . . . . . . . . . . . . . 75
A.1. Minimum Requirements Profile . . . . . . . . . . . . . . 75
A.2. Layer 3 Network Edge Profile . . . . . . . . . . . . . . 78
B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 80
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 81
This document defines a list of operational security requirements for the infrastructure of large IP networks (routers and switches). The goal is to provide network operators a clear, concise way of communicating their security requirements to equipment vendors.
本文件定义了大型IP网络（路由器和交换机）基础设施的操作安全要求列表。目标是为网络运营商提供一种清晰、简洁的方式，向设备供应商传达其安全要求。
Network operators need tools to ensure that they are able to manage their networks securely and to insure that they maintain the ability to provide service to their customers. Some of the threats are outlined in section 3.2 of [RFC2196]. This document enumerates features which are required to implement many of the policies and procedures suggested by [RFC2196] in the context of the infrastructure of large IP-based networks. Also see [RFC3013].
网络运营商需要工具来确保他们能够安全地管理他们的网络，并确保他们保持向客户提供服务的能力。[RFC2196]第3.2节概述了一些威胁。本文件列举了在基于IP的大型网络基础设施中实施[RFC2196]建议的许多政策和程序所需的功能。另请参见[RFC3013]。
The scope of these requirements is intended to cover the managed infrastructure of large ISP IP networks (e.g., routers and switches). Certain groups (or "profiles", see below) apply only in specific situations (e.g., edge-only).
这些要求的范围旨在涵盖大型ISP IP网络（如路由器和交换机）的托管基础设施。某些组（或“配置文件”，见下文）仅适用于特定情况（例如，仅限边缘）。
The following are explicitly out of scope:
以下内容明显超出范围：
o general purpose hosts that do not transit traffic including infrastructure hosts such as name/time/log/AAA servers, etc.,
o 不传输流量的通用主机，包括基础设施主机，如名称/时间/日志/AAA服务器等。，
o unmanaged devices,
o 非托管设备，
o customer managed devices (e.g., firewalls, Intrusion Detection System, dedicated VPN devices, etc.),
o 客户管理的设备（如防火墙、入侵检测系统、专用VPN设备等），
o SOHO (Small Office, Home Office) devices (e.g., personal firewalls, Wireless Access Points, Cable Modems, etc.),
o SOHO（小型办公室、家庭办公室）设备（如个人防火墙、无线接入点、电缆调制解调器等），
o confidentiality of customer data,
o 客户数据的保密性，
o integrity of customer data,
o 客户数据的完整性，
o physical security.
o 人身安全。
This means that while the requirements in the minimum profile (and others) may apply, additional requirements have not be added to account for their unique needs.
这意味着，虽然最低配置文件中的要求（和其他要求）可能适用，但由于其独特需求，未添加其他要求。
While the examples given are written with IPv4 in mind, most of the requirements are general enough to apply to IPv6.
虽然给出的示例是在考虑IPv4的情况下编写的，但大多数要求都非常通用，足以应用于IPv6。
For the purposes of this document, a secure network is one in which:
在本文件中，安全网络是指：
o The network keeps passing legitimate customer traffic (availability).
o 网络不断传递合法的客户流量（可用性）。
o Traffic goes where it is supposed to go, and only where it is supposed to go (availability, confidentiality).
o 流量去它应该去的地方，并且只去它应该去的地方（可用性、保密性）。
o The network elements remain manageable (availability).
o 网元保持可管理性（可用性）。
o Only authorized users can manage network elements (authorization).
o 只有经过授权的用户才能管理网元（授权）。
o There is a record of all security related events (accountability).
o 有所有安全相关事件的记录（责任）。
o The network operator has the necessary tools to detect and respond to illegitimate traffic.
o 网络运营商拥有检测和响应非法流量的必要工具。
There are two intended audiences: the network operator who selects, purchases, and operates IP network equipment, and the vendors who create them.
有两个目标受众：选择、购买和操作IP网络设备的网络运营商，以及创建这些设备的供应商。
The individual requirements are listed in the three sections below.
以下三节列出了各项要求。
o Section 2 lists functional requirements.
o 第2节列出了功能需求。
o Section 3 lists documentation requirements.
o 第3节列出了文件要求。
o Section 4 lists assurance requirements.
o 第4节列出了保证要求。
Within these areas, requirements are grouped in major functional areas (e.g., logging, authentication, filtering, etc.)
在这些领域内，需求按主要功能领域进行分组（例如，日志记录、身份验证、过滤等）
Each requirement has the following subsections:
每项要求都有以下小节：
o Requirement (what)
o 要求（什么）
o Justification (why)
o 理由（为什么）
o Examples (how)
o 示例（如何）
o Warnings (if applicable)
o 警告（如适用）
The requirement describes a policy to be supported by the device. The justification tells why and in what context the requirement is important. The examples section is intended to give examples of implementations that may meet the requirement. Examples cite technology and standards current at the time of this writing. See [RFC3631]. It is expected that the choice of implementations to meet the requirements will change over time. The warnings list operational concerns, deviation from standards, caveats, etc.
该要求描述了设备支持的策略。理由说明了为什么以及在什么情况下需求是重要的。示例部分旨在给出可能满足要求的实现示例。示例引用了撰写本文时的最新技术和标准。参见[RFC3631]。预计满足需求的实现选择将随着时间的推移而改变。警告列出了操作问题、与标准的偏差、警告等。
Security requirements will vary across different device types and different organizations, depending on policy and other factors. A desired feature in one environment may be a requirement in another. Classifications must be made according to local need.
根据策略和其他因素，不同设备类型和不同组织的安全要求会有所不同。一个环境中的所需特性可能是另一个环境中的需求。必须根据当地需要进行分类。
In order to assist in classification, Appendix A defines several requirement "profiles" for different types of devices. Profiles are concise lists of requirements that apply to certain classes of devices. The profiles in this document should be reviewed to determine if they are appropriate to the local environment.
为了帮助分类，附录A为不同类型的设备定义了几个要求“配置文件”。配置文件是适用于特定类别设备的简明需求列表。应审查本文件中的配置文件，以确定其是否适合当地环境。
It is anticipated that the requirements in this document will be used for the following purposes:
预计本文件中的要求将用于以下目的：
o as a checklist when evaluating networked products,
o 作为评估网络产品时的检查表，
o to create profiles of different subsets of the requirements which describe the needs of different devices, organizations, and operating environments,
o 创建不同需求子集的概要文件，描述不同设备、组织和操作环境的需求，
o to assist operators in clearly communicating their security requirements,
o 协助运营商明确传达其安全要求，
o as high level guidance for the creation of detailed test plans.
o 作为创建详细测试计划的高级指导。
RFC 2119 Keywords
RFC2119关键字
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The use of the RFC 2119 keywords is an attempt, by the editor, to assign the correct requirement levels ("MUST", "SHOULD", "MAY"...). It must be noted that different organizations, operational environments, policies and legal environments will generate different requirement levels. Operators and vendors should carefully consider the individual requirements listed here in their own context. One size does not fit all.
使用RFC 2119关键字是编辑试图分配正确的需求级别（“必须”、“应该”、“可能”…）。必须注意的是，不同的组织、运营环境、政策和法律环境将产生不同的需求级别。运营商和供应商应该仔细考虑在他们自己的上下文中列出的个人需求。一个尺码不适合所有人。
Bogon.
博根。
A "Bogon" (plural: "bogons") is a packet with an IP source address in an address block not yet allocated by IANA or the Regional Internet Registries (ARIN, RIPE, APNIC...) as well as all addresses reserved for private or special use by RFCs. See [RFC3330] and [RFC1918].
“Bogon”（复数：“bogons”）是指地址块中的IP源地址尚未由IANA或区域互联网注册中心（ARIN、RIME、APNIC…）分配的数据包，以及为RFC专用或特殊用途保留的所有地址。参见[RFC3330]和[RFC1918]。
CLI.
CLI。
Several requirements refer to a Command Line Interface (CLI). While this refers at present to a classic text oriented command interface, it is not intended to preclude other mechanisms which may meet all the requirements that reference "CLI".
一些要求涉及命令行界面（CLI）。虽然目前这指的是一个经典的面向文本的命令界面，但并不排除可能满足引用“CLI”的所有要求的其他机制。
Console.
安慰
Several requirements refer to a "Console". The model for this is the classic RS232 serial port which has, for the past 30 or more years, provided a simple, stable, reliable, well-understood and nearly ubiquitous management interface to network devices. Again, these requirements are intended primarily to codify the benefits provided by that venerable interface, not to preclude other mechanisms that meet all the same requirements.
若干要求涉及“控制台”。这方面的模型是经典的RS232串行端口，在过去30多年中，它为网络设备提供了一个简单、稳定、可靠、易于理解且几乎无处不在的管理接口。同样，这些要求主要是为了将这个古老的接口提供的好处编成代码，而不是排除满足所有相同要求的其他机制。
Filter.
滤器
In this document, a "filter" is defined as a group of one or more rules where each rule specifies one or more match criteria as specified in Section 2.8.
在本文件中，“过滤器”定义为一组一个或多个规则，其中每个规则指定了第2.8节中规定的一个或多个匹配标准。
In-Band management.
带内管理。
"In-Band management" is defined as any management done over the same channels and interfaces used for user/customer data. Examples would include using SSH for management via customer or Internet facing network interfaces.
“带内管理”是指在用于用户/客户数据的相同通道和接口上进行的任何管理。示例包括通过面向客户或Internet的网络接口使用SSH进行管理。
High Resolution Time.
高分辨率时间。
"High resolution time" is defined in this document as "time having a resolution greater than one second" (e.g., milliseconds).
“高分辨率时间”在本文件中定义为“分辨率大于1秒的时间”（例如毫秒）。
IP.
知识产权。
Unless otherwise indicated, "IP" refers to IPv4.
除非另有说明，“IP”指IPv4。
Management.
经营
This document uses a broad definition of the term "management". In this document, "management" refers to any authorized interaction with the device intended to change its operational state or configuration. Data/Forwarding plane functions (e.g., the transit of customer traffic) are not considered management. Control plane functions such as routing, signaling and link management protocols and management plane functions such as remote access, configuration and authentication are considered to be management.
本文件使用了“管理”一词的广义定义。在本文件中，“管理”是指与设备的任何授权交互，旨在改变其运行状态或配置。数据/转发平面功能（例如，客户流量传输）不被视为管理。控制平面功能（如路由、信令和链路管理协议）和管理平面功能（如远程访问、配置和身份验证）被视为管理。
Martian.
火星人。
Per [RFC1208] "Martian: Humorous term applied to packets that turn up unexpectedly on the wrong network because of bogus routing entries. Also used as a name for a packet which has an altogether bogus (non-registered or ill-formed) Internet address." For the purposes of this document Martians are defined as "packets having a source address that, by application of the current forwarding tables, would not have its return traffic routed back to the sender." "Spoofed packets" are a common source of martians.
根据[RFC1208]“火星人：一个幽默的术语，用于描述由于虚假路由条目而意外出现在错误网络上的数据包。也用作具有完全虚假（未注册或格式错误）互联网地址的数据包的名称。”在本文件中，火星人的定义如下：“具有源地址的数据包，通过应用当前转发表，其返回流量不会路由回发送方。”“伪造数据包”是火星人的常见来源。
Note that in some cases, the traffic may be asymmetric, and a simple forwarding table check might produce false positives. See [RFC3704]
请注意，在某些情况下，流量可能是不对称的，简单的转发表检查可能会产生误报。见[RFC3704]
Out-of-Band (OoB) management.
带外（OoB）管理。
"Out-of-Band management" is defined as any management done over channels and interfaces that are separate from those used for user/customer data. Examples would include a serial console interface or a network interface connected to a dedicated management network that is not used to carry customer traffic.
“带外管理”是指通过与用于用户/客户数据的通道和接口分离的通道和接口进行的任何管理。示例包括串行控制台接口或连接到不用于承载客户流量的专用管理网络的网络接口。
Open Review.
公开审查。
"Open review" refers to processes designed to generate public discussion and review of proposed technical solutions such as data communications protocols and cryptographic algorithms with the goals of improving and building confidence in the final solutions.
“公开审查”是指旨在对提议的技术解决方案（如数据通信协议和加密算法）进行公开讨论和审查的过程，目的是提高并建立对最终解决方案的信心。
For the purposes of this document "open review" is defined by [RFC2026]. All standards track documents are considered to have been through an open review process.
在本文件中，“公开审查”由[RFC2026]定义。所有标准跟踪文件均被视为已通过公开审查程序。
It should be noted that organizations may have local requirements that define what they view as acceptable "open review". For example, they may be required to adhere to certain national or international standards. Such modifications of the definition of the term "open review", while important, are considered local issues that should be discussed between the organization and the vendor.
应该注意的是，组织可能有本地要求，这些要求定义了他们认为可接受的“公开审查”。例如，他们可能需要遵守某些国家或国际标准。对“公开审查”一词定义的这种修改虽然重要，但被认为是本组织和供应商之间应讨论的地方问题。
It should also be noted that section 7 of [RFC2026] permits standards track documents to incorporate other "external standards and specifications".
还应注意，[RFC2026]第7节允许标准跟踪文件纳入其他“外部标准和规范”。
Service.
服务
A number of requirements refer to "services". For the purposes of this document a "service" is defined as "any process or protocol running in the control or management planes to which non-transit packets may be delivered". Examples might include an SSH server, a BGP process or an NTP server. It would also include the transport, network and link layer protocols since, for example, a TCP packet addressed to a port on which no service is listening will be "delivered" to the IP stack, and possibly result in an ICMP message being sent back.
许多要求涉及“服务”。在本文件中，“服务”定义为“在控制或管理平面上运行的任何进程或协议，非传输数据包可能会被传送到该控制或管理平面”。示例可能包括SSH服务器、BGP进程或NTP服务器。它还将包括传输层、网络层和链路层协议，因为，例如，发往没有服务正在侦听的端口的TCP数据包将“传递”到IP堆栈，并可能导致发送回ICMP消息。
Secure Channel.
安全通道。
A "secure channel" is a mechanism that ensures end-to-end integrity and confidentiality of communications. Examples include TLS [RFC2246] and IPsec [RFC2401]. Connecting a terminal to a console port using physically secure, shielded cable would provide confidentiality but possibly not integrity.
“安全通道”是一种确保通信端到端完整性和保密性的机制。示例包括TLS[RFC2246]和IPsec[RFC2401]。使用物理安全的屏蔽电缆将终端连接到控制台端口将提供机密性，但可能不会提供完整性。
Single-Homed Network.
单宿网络。
A "single-homed network" is defined as one for which
“单宿网络”定义为
* There is only one upstream connection
* 只有一个上游连接
* Routing is symmetric.
* 路由是对称的。
See [RFC3704] for a discussion of related issues and mechanisms for multihomed networks.
有关多宿网络的相关问题和机制的讨论，请参见[RFC3704]。
Spoofed Packet.
伪造的数据包。
A "spoofed packet" is defined as a packet that has a source address that does not correspond to any address assigned to the system which sent the packet. Spoofed packets are often "bogons" or "martians".
“伪造数据包”被定义为具有源地址的数据包，该源地址与分配给发送该数据包的系统的任何地址都不对应。伪造的数据包通常是“博根人”或“火星人”。
The requirements in this section are intended to list testable, functional requirements that are needed to operate devices securely.
本节中的要求旨在列出安全操作设备所需的可测试功能要求。
Requirement.
要求
The device MUST provide mechanisms to ensure end-to-end integrity and confidentiality for all network traffic and protocols used to support management functions. This MUST include at least protocols used for configuration, monitoring, configuration backup and restore, logging, time synchronization, authentication, and routing.
设备必须提供机制，以确保用于支持管理功能的所有网络流量和协议的端到端完整性和机密性。这必须至少包括用于配置、监视、配置备份和恢复、日志记录、时间同步、身份验证和路由的协议。
Justification.
正当理由
Integrity protection is required to ensure that unauthorized users cannot manage the device or alter log data or the results of management commands. Confidentiality is required so that unauthorized users cannot view sensitive information, such as keys, passwords, or the identity of users.
需要完整性保护，以确保未经授权的用户无法管理设备或更改日志数据或管理命令的结果。需要保密，以便未经授权的用户无法查看敏感信息，如密钥、密码或用户身份。
Examples.
例子。
See [RFC3631] for a current list of mechanisms that can be used to support secure management.
有关可用于支持安全管理的机制的当前列表，请参见[RFC3631]。
Later sections list requirements for supporting in-band management (Section 2.2) and out-of-band management (Section 2.3) as well as trade-offs that must be weighed in considering which is appropriate to a given situation.
后面的章节列出了支持带内管理（第2.2节）和带外管理（第2.3节）的要求，以及在考虑哪种情况适用时必须权衡的权衡。
Warnings.
警告。
None.
没有一个
This section lists security requirements that support secure in-band management. In-band management has the advantage of lower cost (no extra interfaces or lines), but has significant security disadvantages:
本节列出了支持安全带内管理的安全要求。带内管理具有成本较低（无额外接口或线路）的优点，但具有显著的安全缺点：
o Saturation of customer lines or interfaces can make the device unmanageable unless out-of-band management resources have been reserved.
o 客户线路或接口的饱和会使设备无法管理，除非已保留带外管理资源。
o Since public interfaces/channels are used, it is possible for attackers to directly address and reach the device and to attempt management functions.
o 由于使用了公共接口/通道，攻击者有可能直接寻址和访问设备，并尝试执行管理功能。
o In-band management traffic on public interfaces may be intercepted, however this would typically require a significant compromise in the routing system.
o 公共接口上的带内管理流量可能被拦截，但这通常需要路由系统中的重大妥协。
o Public interfaces used for in-band management may become unavailable due to bugs (e.g., buffer overflows being exploited) while out-of-band interfaces (such as a serial console device) remain available.
o 当带外接口（如串行控制台设备）保持可用时，用于带内管理的公共接口可能由于错误（例如，被利用的缓冲区溢出）而变得不可用。
There are many situations where in-band management makes sense, is used, and/or is the only option. The following requirements are meant to provide means of securing in-band management traffic.
在许多情况下，带内管理是有意义的、被使用的和/或是唯一的选择。以下要求旨在提供保护带内管理流量的方法。
Requirement.
要求
If cryptography is used to provide secure management functions, then there MUST be an option to use algorithms that are subject to "open review" as defined in Section 1.8 to provide these functions. These SHOULD be used by default. The device MAY optionally support algorithms that are not open to review.
如果使用加密技术提供安全管理功能，则必须选择使用第1.8节定义的“公开审查”算法来提供这些功能。默认情况下应使用这些选项。该设备可选择性地支持不公开审查的算法。
Justification.
正当理由
Cryptographic algorithms that have not been subjected to widespread, extended public/peer review are more likely to have undiscovered weaknesses or flaws than open standards and publicly reviewed algorithms. Network operators may have need or desire to
与开放标准和公开审查的算法相比，未经广泛、扩展的公众/同行审查的加密算法更有可能存在未发现的弱点或缺陷。网络运营商可能需要或希望
use non-open cryptographic algorithms. They should be allowed to evaluate the trade-offs and make an informed choice between open and non-open cryptography. See [Schneier] for further discussion.
使用非开放加密算法。应该允许他们评估权衡，并在开放和非开放加密之间做出明智的选择。有关进一步的讨论，请参见[Schneier]。
Examples.
例子。
The following are some algorithms that satisfy the requirement at the time of writing: AES [FIPS.197], and 3DES [ANSI.X9-52.1998] for applications requiring symmetric encryption; RSA [RFC3447] and Diffie-Hellman [PKCS.3.1993], [RFC2631] for applications requiring key exchange; HMAC [RFC2401] with SHA-1 [RFC3174] for applications requiring message verification.
以下是在撰写本文时满足要求的一些算法：AES[FIPS.197]和3DES[ANSI.X9-52.1998]，适用于需要对称加密的应用；RSA[RFC3447]和Diffie Hellman[PKCS.3.1993]，[RFC2631]用于需要密钥交换的应用程序；HMAC[RFC2401]和SHA-1[RFC3174]用于需要消息验证的应用程序。
Warnings.
警告。
This list is not exhaustive. Other strong, well-reviewed algorithms may meet the requirement. The dynamic nature of the field means that what is good enough today may not be in the future.
这份清单并非详尽无遗。其他强大的、经过充分审查的算法可能满足要求。该领域的动态性质意味着，今天足够好的东西可能不会出现在未来。
Open review is necessary but not sufficient. The strength of the algorithm and key length must also be considered. For example, 56-bit DES meets the open review requirement, but is today considered too weak and is therefore not recommended.
公开审查是必要的，但还不够。还必须考虑算法的强度和密钥长度。例如，56位DES符合开放式审查要求，但目前被认为太弱，因此不推荐使用。
Requirement.
要求
If cryptography is used to meet the secure management channel requirements, then the key lengths and algorithms SHOULD be "strong".
如果使用加密技术来满足安全管理通道要求，则密钥长度和算法应为“强”。
Justification.
正当理由
Short keys and weak algorithms threaten the confidentiality and integrity of communications.
短密钥和弱算法威胁通信的机密性和完整性。
Examples.
例子。
The following algorithms satisfy the requirement at the time of writing: AES [FIPS.197], and 3DES [ANSI.X9-52.1998] for applications requiring symmetric encryption; RSA [RFC3447] and Diffie-Hellman [PKCS.3.1993], [RFC2631] for applications requiring key exchange; HMAC [RFC2401] with SHA-1 [RFC3174] for applications requiring message verification.
以下算法满足撰写本文时的要求：AES[FIPS.197]和3DES[ANSI.X9-52.1998]，适用于需要对称加密的应用；RSA[RFC3447]和Diffie Hellman[PKCS.3.1993]，[RFC2631]用于需要密钥交换的应用程序；HMAC[RFC2401]和SHA-1[RFC3174]用于需要消息验证的应用程序。
Note that for *new protocols* [RFC3631] says the following: "Simple keyed hashes based on MD5 [RFC1321], such as that used in the BGP session security mechanism [RFC2385], are especially to be avoided in new protocols, given the hints of weakness in MD5." While use of such hashes in deployed products and protocols is preferable to a complete lack of integrity and authentication checks, this document concurs with the recommendation that new products and protocols strongly consider alternatives.
请注意，对于*新协议*[RFC3631]如下所述：“基于MD5[RFC1321]的简单密钥散列，例如BGP会话安全机制[RFC2385]中使用的密钥散列，鉴于MD5中的弱点提示，在新协议中尤其要避免。”虽然在部署的产品和协议中使用这样的散列比完全缺乏完整性和认证检查更可取，但该文档同意新产品和协议强烈考虑备选方案的建议。
Warnings.
警告。
This list is not exhaustive. Other strong, well-reviewed algorithms may meet the requirement. The dynamic nature of the field means that what is good enough today may not be in the future.
这份清单并非详尽无遗。其他强大的、经过充分审查的算法可能满足要求。该领域的动态性质意味着，今天足够好的东西可能不会出现在未来。
Strength is relative. Long keys and strong algorithms are intended to increase the work factor required to compromise the security of the data protected. Over time, as processing power increases, the security provided by a given algorithm and key length will degrade. The definition of "Strong" must be constantly reevaluated.
力量是相对的。长密钥和强算法旨在增加危害受保护数据安全性所需的工作系数。随着时间的推移，随着处理能力的提高，给定算法和密钥长度提供的安全性将降低。必须不断重新评估“强”的定义。
There may be legal issues governing the use of cryptography and the strength of cryptography used.
可能存在管理密码的使用和使用的密码强度的法律问题。
This document explicitly does not attempt to make any authoritative statement about what key lengths constitute "strong" cryptography. See [RFC3562] and [RFC3766] for help in determining appropriate key lengths. Also see [Schneier] chapter 7 for a discussion of key lengths.
本文档明确不试图就什么密钥长度构成“强”加密做出任何权威声明。请参阅[RFC3562]和[RFC3766]以获得确定适当密钥长度的帮助。有关键长度的讨论，请参见[Schneier]第7章。
Requirement.
要求
If cryptography is used to provide secure management channels, then its use MUST be supported in protocols that are subject to "open review" as defined in Section 1.8. These SHOULD be used by default. The device MAY optionally support the use of cryptography in protocols that are not open to review.
如果使用加密技术来提供安全的管理通道，则必须在第1.8节定义的“公开审查”协议中支持其使用。默认情况下应使用这些选项。该设备可选择性地支持在不公开审查的协议中使用加密技术。
Justification.
正当理由
Protocols that have not been subjected to widespread, extended public/peer review are more likely to have undiscovered weaknesses or flaws than open standards and publicly reviewed protocols Network operators may have need or desire to use non-open protocols They should be allowed to evaluate the trade-offs and make an informed choice between open and non-open protocols.
没有受到广泛影响的议定书，与开放标准和公开审查协议相比，扩展的公共/同行审查更可能存在未发现的弱点或缺陷。网络运营商可能需要或希望使用非开放协议。应允许他们评估权衡，并在开放协议和非开放协议之间作出知情选择。
Examples.
例子。
See TLS [RFC2246] and IPsec [RFC2401].
参见TLS[RFC2246]和IPsec[RFC2401]。
Warnings.
警告。
Note that open review is necessary but may not be sufficient. It is perfectly possible for an openly reviewed protocol to misuse (or not use) cryptography.
请注意，公开审查是必要的，但可能还不够。公开审查的协议完全有可能滥用（或不使用）加密技术。
Requirement.
要求
The device SHOULD allow the operator to select cryptographic parameters. This SHOULD include key lengths and algorithms.
设备应允许操作员选择加密参数。这应该包括密钥长度和算法。
Justification.
正当理由
Cryptography using certain algorithms and key lengths may be considered "strong" at one point in time, but "weak" at another. The constant increase in compute power continually reduces the time needed to break cryptography of a certain strength. Weaknesses may be discovered in algorithms. The ability to select a different algorithm is a useful tool for maintaining security in the face of such discoveries.
使用特定算法和密钥长度的加密在某个时间点可能被视为“强”，但在另一个时间点可能被视为“弱”。计算能力的不断提高不断减少了打破某种强度的加密所需的时间。算法中可能会发现弱点。选择不同算法的能力是在面临此类发现时维护安全性的有用工具。
Examples.
例子。
56-bit DES was once considered secure. In 1998 it was cracked by custom built machine in under 3 days. The ability to select algorithms and key lengths would give the operator options (different algorithms, longer keys) in the face of such developments.
56位DES一度被认为是安全的。1998年，它被定制的机器在3天内破解。选择算法和密钥长度的能力将为操作员提供面对此类发展的选项（不同的算法、更长的密钥）。
Warnings.
警告。
None.
没有一个
Requirement.
要求
Management functions SHOULD be processed at higher priority than non-management traffic. This SHOULD include ingress, egress, internal transmission, and processing. This SHOULD include at least protocols used for configuration, monitoring, configuration backup, logging, time synchronization, authentication, and routing.
管理功能的处理优先级应高于非管理流量。这应包括入口、出口、内部传输和处理。这至少应包括用于配置、监视、配置备份、日志记录、时间同步、身份验证和路由的协议。
Justification.
正当理由
Certain attacks (and normal operation) can cause resource saturation such as link congestion, memory exhaustion or CPU overload. In these cases it is important that management functions be prioritized to ensure that operators have the tools needed to recover from the attack.
某些攻击（和正常操作）可能导致资源饱和，如链路拥塞、内存耗尽或CPU过载。在这些情况下，重要的是要优先考虑管理功能，以确保操作员拥有从攻击中恢复所需的工具。
Examples.
例子。
Imagine a service provider with 1,000,000 DSL subscribers, most of whom have no firewall protection. Imagine that a large portion of these subscribers machines were infected with a new worm that enabled them to be used in coordinated fashion as part of large denial of service attack that involved flooding. It is entirely possible that without prioritization such an attack would cause link congestion resulting in routing adjacencies being lost. A DoS attack against hosts has just become a DoS attack against the network.
设想一个拥有1000000 DSL用户的服务提供商，其中大多数没有防火墙保护。想象一下，这些订阅者机器中的很大一部分感染了一种新的蠕虫病毒，使它们能够以协调的方式作为涉及洪水的大规模拒绝服务攻击的一部分使用。如果不确定优先级，这种攻击完全可能导致链路拥塞，从而导致路由邻近丢失。针对主机的DoS攻击刚刚成为针对网络的DoS攻击。
Warnings.
警告。
Prioritization is not a panacea. Routing update packets may not make it across a saturated link. This requirement simply says that the device should prioritize management functions within its scope of control (e.g., ingress, egress, internal transit, processing). To the extent that this is done across an entire network, the overall effect will be to ensure that the network remains manageable.
优先顺序不是万灵药。路由更新数据包可能无法通过饱和链路。该要求仅表示设备应在其控制范围内优先考虑管理功能（例如，入口、出口、内部传输、处理）。如果这是在整个网络中完成的，那么总体效果将是确保网络保持可管理性。
See Section 2.2 for a discussion of the advantages and disadvantages of In-band vs. Out-of-Band management.
有关带内管理与带外管理的优缺点的讨论，请参见第2.2节。
These requirements assume two different possible Out-of-Band topologies:
这些要求假设两种不同的带外拓扑：
o serial line (or equivalent) console connections using a CLI,
o 使用CLI的串行线路（或等效）控制台连接，
o network interfaces connected to a separate network dedicated to management.
o 连接到专用于管理的独立网络的网络接口。
The following assumptions are made about out-of-band management:
以下是关于带外管理的假设：
o The out-of-band management network is secure.
o 带外管理网络是安全的。
o Communications beyond the management interface (e.g., console port, management network interface) is secure.
o 管理接口（例如控制台端口、管理网络接口）以外的通信是安全的。
o There is no need for encryption of communication on out-of-band management interfaces, (e.g., on a serial connection between a terminal server and a device's console port).
o 不需要对带外管理接口上的通信进行加密（例如，在终端服务器和设备控制台端口之间的串行连接上）。
o Security measures are in place to prevent unauthorized physical access.
o 安全措施到位，以防止未经授权的物理访问。
Even if these assumptions hold it would be wise, as an application of defense-in-depth, to apply the in-band requirements (e.g., encryption) to out-of-band interfaces.
即使这些假设成立，作为纵深防御的应用，将带内要求（例如加密）应用于带外接口也是明智的。
Requirement.
要求
The device MUST support complete configuration and management via a 'console' interface that functions independently from the forwarding and IP control planes.
设备必须通过独立于转发和IP控制平面的“控制台”接口支持完整的配置和管理。
Justification.
正当理由
There are times when it is operationally necessary to be able to immediately and easily access a device for management or configuration, even when the network is unavailable, routing and network interfaces are incorrectly configured, the IP stack and/or operating system may not be working (or may be vulnerable to recently discovered exploits that make their use impossible/ inadvisable), or when high bandwidth paths to the device are unavailable. In such situations, a console interface can provide a way to manage and configure the device.
有时在操作上需要能够立即轻松地访问设备进行管理或配置，即使网络不可用、路由和网络接口配置不正确、IP堆栈和/或操作系统可能无法工作（或者可能容易受到最近发现的使其无法使用/不可取的利用漏洞的攻击），或者当设备的高带宽路径不可用时。在这种情况下，控制台界面可以提供管理和配置设备的方法。
Examples.
例子。
An RS232 (EIA232) interface that provides the capability to load new versions of the system software and to perform configuration via a command line interface. RS232 interfaces are ubiquitous and well understood.
RS232（EIA232）接口，提供加载新版本系统软件和通过命令行接口执行配置的能力。RS232接口随处可见，且易于理解。
A simple embedded device that provides management and configuration access via an Ethernet or USB interface.
通过以太网或USB接口提供管理和配置访问的简单嵌入式设备。
As of this writing, RS232 is still strongly recommended as it provides the following benefits:
在撰写本文时，仍然强烈建议使用RS232，因为它具有以下优点：
* Simplicity. RS232 is far simpler than the alternatives. It is simply a hardware specification. By contrast an Ethernet based solution might require an ethernet interface, an operating system, an IP stack and an HTTP server all to be functioning and properly configured.
* 简单RS232比其他选择简单得多。它只是一个硬件规范。相比之下，基于以太网的解决方案可能需要以太网接口、操作系统、IP堆栈和HTTP服务器才能正常工作和正确配置。
* Proven. RS232 has more than 30 years of use.
* 经过证实的。RS232已经使用了30多年。
* Well-Understood. Operators have a great deal of experience with RS232.
* 很好理解。操作员对RS232有丰富的经验。
* Availability. It works even in the presence of network failure.
* 可利用性即使出现网络故障，它也能工作。
* Ubiquity. It is very widely deployed in mid to high end network infrastructure.
* 无处不在。它广泛部署在中高端网络基础设施中。
* Low-Cost. The cost of adding a RS232 port to a device is small.
* 低成本。向设备添加RS232端口的成本很小。
* CLI-Friendly. An RS232 interface and a CLI are sufficient in most cases to manage a device. No additional software is required.
* 我很友好。RS232接口和CLI在大多数情况下足以管理设备。不需要额外的软件。
* Integrated. Operators have many solutions (terminal servers, etc.) currently deployed to support management via RS232.
* 集成的运营商目前部署了许多解决方案（终端服务器等），以支持通过RS232进行管理。
While other interfaces may be supplied, the properties listed above should be considered. Interfaces not having these properties may present challenges in terms of ease of use, integration or adoption. Problems in any of these areas could have negative security impacts, particularly in situations where the console must be used to quickly respond to incidents.
虽然可以提供其他接口，但应考虑上述属性。没有这些属性的接口可能会在易用性、集成性或采用性方面带来挑战。这些区域中的任何问题都可能对安全产生负面影响，特别是在必须使用控制台快速响应事件的情况下。
Warnings.
警告。
It is common practice is to connect RS232 ports to terminal servers that permit networked access for convenience. This increases the potential security exposure of mechanisms available only via RS232 ports. For example, a password recovery mechanism that is available only via RS232 might give a remote hacker to completely reconfigure a router. While operational procedures are beyond the scope of this document, it is important to note here that strong attention should be given to policies, procedures, access mechanisms and physical security governing access to console ports.
通常的做法是将RS232端口连接到终端服务器，以便进行网络访问。这增加了仅通过RS232端口可用的机制的潜在安全风险。例如，只有通过RS232才能使用的密码恢复机制可能会让远程黑客完全重新配置路由器。虽然操作程序超出了本文档的范围，但在此必须注意，应特别注意控制控制台端口访问的策略、程序、访问机制和物理安全。
Requirement.
要求
There MUST be a method defined and published for returning the console communication parameters to their default settings. This method must not require the current settings to be known.
必须定义并发布一个方法，用于将控制台通信参数返回到其默认设置。此方法不得要求知道当前设置。
Justification.
正当理由
Having to guess at communications settings can waste time. In a crisis situation, the operator may need to get on the console of a device quickly.
必须猜测通信设置可能会浪费时间。在紧急情况下，操作员可能需要快速进入设备控制台。
Examples.
例子。
One method might be to send a break on a serial line.
一种方法可能是在串行线路上发送中断。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The use of the 'console' interface MUST NOT require proprietary devices, protocol extensions or specific client software.
“控制台”界面的使用不得要求专有设备、协议扩展或特定的客户端软件。
Justification.
正当理由
The purpose of having the console interface is to have a management interface that can be made to work quickly at all times. Requiring complex or nonstandard behavior on the part of attached devices reduces the likelihood that the console will work without hassles.
拥有控制台界面的目的是拥有一个可以随时快速工作的管理界面。连接的设备需要复杂或非标准的行为，这降低了控制台正常工作的可能性。
Examples.
例子。
If the console is supplied via an RS232 interface, then it should function with an attached device that only implements a "dumb" terminal. Support of "advanced" terminal features/types should be optional.
如果控制台是通过RS232接口提供的，那么它应该与仅实现“哑”终端的连接设备一起工作。支持“高级”终端功能/类型应是可选的。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The 'console' SHOULD support an authentication mechanism which does not require functional IP or depend on external services. This authentication mechanism MAY be disabled until a failure of other preferred mechanisms is detected.
“控制台”应支持不需要功能IP或不依赖外部服务的身份验证机制。在检测到其他首选机制出现故障之前，可以禁用此身份验证机制。
Justification.
正当理由
It does little good to have a console interface on a device if you cannot get into the device with it when the network is not working.
如果在网络不工作的情况下无法进入设备，那么在设备上安装控制台接口没有什么好处。
Examples.
例子。
Some devices which use TACACS or RADIUS for authentication will fall back to a local account if the TACACS or RADIUS server does not reply to an authentication request.
如果TACACS或RADIUS服务器不响应身份验证请求，则使用TACACS或RADIUS进行身份验证的某些设备将退回到本地帐户。
Warnings.
警告。
This requirement represents a trade-off between being able to manage the device (functionality) and security. There are many ways to implement this which would provide reduced security for the device, (e.g., a back door for unauthorized access). Local policy should be consulted to determine if "fail open" or "fail
此要求表示能够管理设备（功能）和安全性之间的权衡。有许多方法可以实现这一点，这将降低设备的安全性（例如，未经授权访问的后门）。应咨询当地政策，以确定是“失效开放”还是“失效
closed" is the correct stance. The implications of "fail closed" (e.g., not being able to manage a device) should be fully considered.
“关闭”是正确的姿态。应充分考虑“故障关闭”（例如，无法管理设备）的含义。
If the fall-back mechanism is disabled, it is important that the failure of IP based authentication mechanism be reliably detected and the fall-back mechanism automatically enabled...otherwise the operator may be left with no means to authenticate.
如果禁用了回退机制，则必须可靠地检测基于IP的身份验证机制的故障，并自动启用回退机制……否则操作员可能无法进行身份验证。
Requirement.
要求
The device MAY provide designated network interface(s) that are used for management plane traffic.
设备可提供用于管理平面业务的指定网络接口。
Justification.
正当理由
A separate management plane interface allows management traffic to be segregated from other traffic (data/forwarding plane, control plane). This reduces the risk that unauthorized individuals will be able to observe management traffic and/or compromise the device.
单独的管理平面接口允许将管理流量与其他流量（数据/转发平面、控制平面）分离。这降低了未经授权的个人能够观察管理流量和/或危害设备的风险。
This requirement applies in situations where a separate OoB management network exists.
此要求适用于存在单独OoB管理网络的情况。
Examples.
例子。
Ethernet port dedicated to management and isolated from customer traffic satisfies this requirement.
专用于管理并与客户流量隔离的以太网端口满足此要求。
Warnings.
警告。
The use of this type of interface depends on proper functioning of both the operating system and the IP stack, as well as good, known configuration at least on the portions of the device dedicated to management.
这种类型接口的使用取决于操作系统和IP堆栈的正常运行，以及良好的已知配置，至少取决于设备专用于管理的部分。
Requirement.
要求
If the device implements separate network interface(s) for the management plane per Section 2.3.5 then the device MUST NOT forward traffic between the management plane and non-management plane interfaces.
如果设备根据第2.3.5节为管理平面实现单独的网络接口，则设备不得在管理平面和非管理平面接口之间转发流量。
Justification.
正当理由
This prevents the flow, intentional or unintentional, of management traffic to/from places that it should not be originating/terminating (e.g., anything beyond the customer-facing interfaces).
这可防止管理通信流有意或无意地流向/流出不应发起/终止的位置（例如，任何超出面向客户的接口）。
Examples.
例子。
Implementing separate forwarding tables for management plane and non-management plane interfaces that do not propagate routes to each other satisfies this requirement.
为不相互传播路由的管理平面和非管理平面接口实现单独的转发表满足此要求。
Warnings.
警告。
None.
没有一个
This section lists requirements that support secure device configuration and management methods. In most cases, this currently involves some sort of command line interface (CLI) and configuration files. It may be possible to meet these requirements with other mechanisms, for instance SNMP or a script-able HTML interface that provides full access to management and configuration functions. In the future, there may be others (e.g., XML based configuration).
本节列出了支持安全设备配置和管理方法的要求。在大多数情况下，这目前涉及某种命令行界面（CLI）和配置文件。可以使用其他机制来满足这些要求，例如SNMP或提供对管理和配置功能的完全访问的可编写脚本的HTML接口。将来可能还会有其他配置（例如，基于XML的配置）。
2.4.1. 'CLI' Provides Access to All Configuration and Management Functions
2.4.1. “CLI”提供对所有配置和管理功能的访问
Requirement.
要求
The Command Line Interface (CLI) or equivalent MUST allow complete access to all configuration and management functions. The CLI MUST be supported on the console (see Section 2.3.1) and SHOULD be supported on all other interfaces used for management.
命令行界面（CLI）或同等界面必须允许完全访问所有配置和管理功能。控制台上必须支持CLI（请参阅第2.3.1节），并且用于管理的所有其他接口上都应支持CLI。
Justification.
正当理由
The CLI (or equivalent) is needed to provide the ability to do reliable, fast, direct, local management and monitoring of a device. It is particularly useful in situations where it is not possible to manage and monitor the device in-band via "normal" means (e.g., SSH or SNMP [RFC3410], [RFC3411]) that depend on functional networking. Such situations often occur during security incidents such as bandwidth-based denial of service attacks.
需要CLI（或等效工具）来提供对设备进行可靠、快速、直接、本地管理和监视的能力。在无法通过依赖于功能网络的“正常”手段（例如SSH或SNMP[RFC3410]、[RFC3411]）来管理和监控带内设备的情况下，它特别有用。此类情况通常发生在安全事件期间，例如基于带宽的拒绝服务攻击。
Examples.
例子。
Examples of configuration include setting interface addresses, defining and applying filters, configuring logging and authentication, etc. Examples of management functions include displaying dynamic state information such as CPU load, memory utilization, packet processing statistics, etc.
配置示例包括设置接口地址、定义和应用过滤器、配置日志记录和身份验证等。管理功能示例包括显示动态状态信息，如CPU负载、内存利用率、数据包处理统计等。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The CLI or equivalent MUST support external scripting of configuration functions. This CLI SHOULD support the same command set and syntax as that in Section 2.4.1.
CLI或等效工具必须支持配置功能的外部脚本。此CLI应支持与第2.4.1节中相同的命令集和语法。
Justification.
正当理由
During the handling of security incidents, it is often necessary to quickly make configuration changes on large numbers of devices. Doing so manually is error prone and slow. Vendor supplied management solutions do not always foresee or address the type or scale of solutions that are required. The ability to script provides a solution to these problems.
在处理安全事件的过程中，经常需要对大量设备快速进行配置更改。手动执行此操作容易出错且速度缓慢。供应商提供的管理解决方案并不总能预见或解决所需解决方案的类型或规模。编写脚本的能力为这些问题提供了解决方案。
Examples.
例子。
Example uses of scripting include: tracking an attack across a large network, updating authentication parameters, updating logging parameters, updating filters, configuration fetching/ auditing, etc. Some languages that are currently used for scripting include expect, Perl and TCL.
脚本的示例用途包括：跨大型网络跟踪攻击、更新身份验证参数、更新日志参数、更新过滤器、配置获取/审核等。目前用于脚本编写的一些语言包括expect、Perl和TCL。
Warnings.
警告。
Some properties of the command language that enhance the ability to script are: simplicity, regularity and consistency. Some implementations that would make scripting difficult or impossible include: "text menu" style interfaces (e.g., "curses" on UNIX) or a hard-coded GUI interfaces (e.g., a native Windows or Macintosh GUI application) that communicate using a proprietary or undocumented protocol not based on a CLI.
命令语言的一些特性增强了编写脚本的能力：简单性、规则性和一致性。一些使脚本编写变得困难或不可能的实现包括：“文本菜单”样式的界面（例如，UNIX上的“诅咒”）或硬编码GUI界面（例如，本机Windows或Macintosh GUI应用程序），这些界面使用非基于CLI的专有或未记录的协议进行通信。
Requirement.
要求
The device MUST support a command line interface (CLI) or equivalent mechanism that works over low bandwidth connections.
设备必须支持在低带宽连接上工作的命令行界面（CLI）或等效机制。
Justification.
正当理由
There are situations where high bandwidth for management is not available, for example when in-band connections are overloaded during an attack or when low-bandwidth, out-of-band connections such as modems must be used. It is often under these conditions that it is most crucial to be able to perform management and configuration functions.
有些情况下无法使用高带宽进行管理，例如，在攻击期间带内连接过载，或者必须使用低带宽带外连接（如调制解调器）。通常在这些情况下，能够执行管理和配置功能是最关键的。
Examples.
例子。
The network is down. The network engineer just disabled routing by mistake on the sole gateway router in a remote unmanned data center. The only access to the device is over a modem connected to a console port. The data center customers are starting to call the support line. The GUI management interface is redrawing the screen multiple times...slowly... at 9600bps.
网络瘫痪了。网络工程师刚刚在远程无人数据中心的唯一网关路由器上错误地禁用了路由。只能通过连接到控制台端口的调制解调器访问设备。数据中心客户开始致电支持热线。GUI管理界面正在多次重新绘制屏幕…缓慢。。。9600bps。
One mechanism that supports operation over slow links is the ability to apply filters to the output of CLI commands which have potentially large output. This may be implemented with something similar to the UNIX pipe facility and "grep" command.
支持通过慢速链接进行操作的一种机制是，能够对可能具有较大输出的CLI命令的输出应用过滤器。这可以通过类似于UNIX管道工具和“grep”命令的方式实现。
For example,
例如
cat largefile.txt | grep interesting-string
cat largefile.txt | grep有趣的字符串
Another is the ability to "page" through large command output, e.g., the UNIX "more" command:
另一个功能是通过大型命令输出“分页”，例如UNIX“more”命令：
For example,
例如
cat largefile.txt | more
cat largefile.txt |更多信息
Warnings.
警告。
One consequence of this requirement may be that requiring a GUI interface for management is unacceptable unless it can be shown to work acceptably over slow links.
这一要求的一个后果可能是，除非可以显示GUI界面在慢速链接上工作，否则需要GUI界面进行管理是不可接受的。
Requirement.
要求
The command line interface (CLI) or equivalent mechanism MUST support a configurable idle timeout value.
命令行界面（CLI）或等效机制必须支持可配置的空闲超时值。
Justification.
正当理由
Network administrators go to lunch. They leave themselves logged in with administrative privileges. They forget to use screen-savers with password protection. They do this while at conferences and in other public places. This behavior presents opportunity for unauthorized access. Idle timeouts reduce the window of exposure.
网络管理员去吃午饭。他们让自己以管理权限登录。他们忘记使用带有密码保护的屏幕保护程序。他们在会议和其他公共场所这样做。此行为为未经授权的访问提供了机会。空闲超时减少了曝光窗口。
Examples.
例子。
The CLI may provide a configuration command that allows an idle timeout to be set. If the operator does not enter commands for that amount of time, the login session will be automatically terminated.
CLI可提供允许设置空闲超时的配置命令。如果操作员在该时间段内未输入命令，登录会话将自动终止。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST provide a means to install new software versions. It MUST be possible to install new software while the device is disconnected from all public IP networks. This MUST NOT rely on previous installation and/or configuration. While new software MAY be loaded from writable media (disk, flash, etc.), the capability to load new software MUST depend only on non-writable media (ROM, etc.). The installation procedures SHOULD support mechanisms to ensure reliability and integrity of data transfers.
设备必须提供安装新软件版本的方法。当设备与所有公共IP网络断开连接时，必须能够安装新软件。这不能依赖于以前的安装和/或配置。虽然可以从可写介质（磁盘、闪存等）加载新软件，但加载新软件的能力必须仅取决于不可写介质（ROM等）。安装程序应支持确保数据传输可靠性和完整性的机制。
Justification.
正当理由
* Vulnerabilities are often discovered in the base software (operating systems, etc.) shipped by vendors. Often mitigation of the risk presented by these vulnerabilities can only be accomplished by updates to the vendor supplied software (e.g., bug
* 通常在供应商提供的基础软件（操作系统等）中发现漏洞。通常，这些漏洞带来的风险的缓解只能通过更新供应商提供的软件（例如bug）来实现
fixes, new versions of code, etc.). Without a mechanism to load new vendor supplied code, it may not be possible to mitigate the risk posed by these vulnerabilities.
修复程序、新版本的代码等）。如果没有加载供应商提供的新代码的机制，可能无法减轻这些漏洞带来的风险。
* It is also conceivable that malicious behavior on the part of hackers or unintentional behaviors on the part of operators could cause software on devices to be corrupted or erased. In these situations, it is necessary to have a means to (re)load software onto the device to restore correct functioning.
* 还可以想象，黑客的恶意行为或操作员的无意行为可能导致设备上的软件被损坏或删除。在这些情况下，必须有一种方法（重新）将软件加载到设备上，以恢复正常功能。
* It is important to be able to load new software while disconnected from all public IP networks because the device may be vulnerable to old attacks before the update is complete.
* 在与所有公共IP网络断开连接的情况下加载新软件非常重要，因为在更新完成之前，设备可能容易受到旧的攻击。
* One has to assume that hackers, operators, etc. may erase or corrupt all writable media (disks, flash, etc.). In such situations, it is necessary to be able to recover starting with only non-writable media (e.g., CD-ROM, a true ROM-based monitor).
* 必须假设黑客、操作员等可能会擦除或损坏所有可写介质（磁盘、闪存等）。在这种情况下，必须能够从仅使用不可写介质（例如，CD-ROM，真正基于ROM的监视器）开始恢复。
* System images may be corrupted in transit (from vendor to customer, or during the loading process) or in storage (bit rot, defective media, etc.). Failure to reliably load a new image, for example after a hacker deletes or corrupts the installed image, could result in extended loss of availability.
* 系统映像可能在传输过程中（从供应商到客户，或在加载过程中）或在存储过程中（位腐烂、有缺陷的介质等）损坏。无法可靠地加载新映像（例如，在黑客删除或损坏已安装映像后），可能会导致可用性的进一步丧失。
Examples.
例子。
The device could support booting into a simple ROM-based monitor that supported a set of commands sufficient to load new operating system code and configuration data from other devices. The operating system and configuration might be loaded from:
该设备可以支持引导到一个简单的基于ROM的监视器中，该监视器支持一组足以从其他设备加载新操作系统代码和配置数据的命令。操作系统和配置可能从以下位置加载：
RS232. The device could support uploading new code via an RS232 console port.
RS232。该设备可以支持通过RS232控制台端口上传新代码。
CD-ROM. The device could support installing new code from a locally attached CD-ROM drive.
CD-ROM。该设备可支持从本地连接的CD-ROM驱动器安装新代码。
NETWORK. The device could support installing new code via a network interface, assuming that (a) it is disconnected from all public networks and (b) the device can boot an OS and IP stack from some read-only media with sufficient capabilities to load new code from the network.
网络该设备可以支持通过网络接口安装新代码，前提是（a）它与所有公共网络断开连接，（b）该设备可以从一些只读介质启动操作系统和IP堆栈，这些只读介质具有从网络加载新代码的足够能力。
FLASH. The device could support booting from flash memory cards.
闪光该设备可以支持从闪存卡引导。
Simple mechanisms currently in use to protect the integrity of system images and data transfer include image checksums and simple serial file transfer protocols such as XMODEM and Kermit.
目前用于保护系统映像和数据传输完整性的简单机制包括映像校验和和简单的串行文件传输协议，如XMODEM和Kermit。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST provide a means to store the system configuration to a remote server. The stored configuration MUST have sufficient information to restore the device to its operational state at the time the configuration is saved. Stored versions of the configuration MAY be compressed using an algorithm which is subject to open review, as long as the fact is clearly identified and the compression can be disabled. Sensitive information such as passwords that could be used to compromise the security of the device MAY be excluded from the saved configuration.
设备必须提供将系统配置存储到远程服务器的方法。存储的配置必须具有足够的信息，以便在保存配置时将设备恢复到其运行状态。只要事实清楚，并且可以禁用压缩，就可以使用公开审查的算法对存储的配置版本进行压缩。可能用于危害设备安全的敏感信息（如密码）可能会从保存的配置中排除。
Justification.
正当理由
Archived configurations are essential to enable auditing and recovery.
存档配置对于启用审核和恢复至关重要。
Examples.
例子。
Possible implementations include SCP, SFTP or FTP over a secure channel. See Section 2.1.1 for requirements related to secure communication channels for management protocols and data.
可能的实现包括通过安全通道的SCP、SFTP或FTP。有关管理协议和数据的安全通信通道的要求，请参见第2.1.1节。
Warnings.
警告。
The security of the remote server is assumed, with appropriate measures being outside the scope of this document.
假定远程服务器的安全性，适当的措施不在本文档的范围内。
Requirement.
要求
The device MUST provide a means to restore a configuration that was saved as described in Section 2.4.6. The system MUST be restored to its operational state at the time the configuration was saved.
设备必须提供恢复第2.4.6节所述保存配置的方法。必须将系统恢复到保存配置时的运行状态。
Justification.
正当理由
Restoration of archived configurations allows quick restoration of service following an outage (security related as well as from other causes).
存档配置的恢复允许在停机后快速恢复服务（与安全相关以及其他原因）。
Examples.
例子。
Configurations may be restored using SCP, SFTP or FTP over a secure channel. See Section 2.1.1 for requirements related to secure communication channels for management protocols and data.
可以通过安全通道使用SCP、SFTP或FTP恢复配置。有关管理协议和数据的安全通信通道的要求，请参见第2.1.1节。
Warnings.
警告。
The security of the remote server is assumed, with appropriate measures being outside the scope of this document.
假定远程服务器的安全性，适当的措施不在本文档的范围内。
Note that if passwords or other sensitive information are excluded from the saved copy of the configuration, as allowed by Section 2.4.6, then the restore may not be complete. The operator may have to set new passwords or supply other information that was not saved.
请注意，如果按照第2.4.6节的规定，密码或其他敏感信息被排除在已保存的配置副本之外，则恢复可能无法完成。操作员可能必须设置新密码或提供其他未保存的信息。
Requirement.
要求
The device MUST support display, backup and restore of system configuration in a simple well defined textual format. The configuration MUST also be viewable as text on the device itself. It MUST NOT be necessary to use a proprietary program to view the configuration.
设备必须支持以简单、定义良好的文本格式显示、备份和恢复系统配置。配置还必须在设备本身上以文本形式显示。无需使用专有程序来查看配置。
Justification.
正当理由
Simple, well-defined textual configurations facilitate human understanding of the operational state of the device, enable off-line audits, and facilitate automation. Requiring the use of a proprietary program to access the configuration inhibits these goals.
简单、定义良好的文本配置有助于人类了解设备的运行状态，支持离线审核，并促进自动化。要求使用专有程序访问配置会抑制这些目标。
Examples.
例子。
A 7-bit ASCII configuration file that shows the current settings of the various configuration options would satisfy the requirement, as would a Unicode configuration or any other "textual" representation. A structured binary format intended only for consumption by programs would not be acceptable.
显示各种配置选项的当前设置的7位ASCII配置文件可以满足要求，Unicode配置或任何其他“文本”表示也可以满足要求。仅供程序使用的结构化二进制格式是不可接受的。
Warnings.
警告。
Offline copies of configurations should be well protected as they often contain sensitive information such as SNMP community strings, passwords, network blocks, customer information, etc.
配置的脱机副本应该得到很好的保护，因为它们通常包含敏感信息，如SNMP社区字符串、密码、网络块、客户信息等。
"Well defined" and "textual" are open to interpretation. Clearly an ASCII configuration file with a regular, documented command oriented-syntax would meet the definition. These are currently in wide use. Future options, such as XML based configuration may meet the requirement. Determining this will require evaluation against the justifications listed above.
“定义明确”和“文本”是可以解释的。显然，一个具有常规的、文档化的、面向命令的语法的ASCII配置文件符合定义。它们目前正在广泛使用。将来的选项（例如基于XML的配置）可能会满足要求。确定这一点需要根据上述理由进行评估。
Requirement.
要求
The vendor MUST:
供应商必须：
* Provide a means to display all services that are listening for network traffic directed at the device from any external source.
* 提供一种显示所有正在侦听来自任何外部源的指向设备的网络流量的服务的方法。
* Display the addresses to which each service is bound.
* 显示每个服务绑定到的地址。
* Display the addresses assigned to each interface.
* 显示分配给每个接口的地址。
* Display any and all port(s) on which the service is listing.
* 显示服务所在的任何和所有端口。
* Include both open standard and vendor proprietary services.
* 包括开放标准和供应商专有服务。
Justification.
正当理由
This information is necessary to enable a thorough assessment of the security risks associated with the operation of the device (e.g., "does this protocol allow complete management of the device without also requiring authentication, authorization, or accounting?"). The information also assists in determining what steps should be taken to mitigate risk (e.g., "should I turn this service off ?")
此信息对于彻底评估与设备操作相关的安全风险是必要的（例如，“此协议是否允许在不需要认证、授权或记帐的情况下对设备进行完整管理？”）。该信息还有助于确定应采取哪些措施来降低风险（例如，“我应该关闭此服务吗？”）
Examples.
例子。
If the device is listening for SNMP traffic from any source directed to the IP addresses of any of its local interfaces, then this requirement could be met by the provision of a command which displays that fact.
如果设备正在侦听从任何源定向到其任何本地接口的IP地址的SNMP通信，则可以通过提供显示该事实的命令来满足此要求。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST provide a means to turn off any "services" (see Section 1.8).
设备必须提供关闭任何“服务”的方法（见第1.8节）。
Justification.
正当理由
The ability to disable services for which there is no operational need will allow administrators to reduce the overall risk posed to the device.
禁用不需要操作的服务的功能将允许管理员降低设备面临的总体风险。
Examples.
例子。
Processes that listen on TCP and UDP ports would be prime examples of services that it must be possible to disable.
侦听TCP和UDP端口的进程将是必须能够禁用的服务的主要示例。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST provide a means for the user to specify the bindings used for all listening services. It MUST support binding to any address or net-block associated with any interface local to the device. This must include addresses bound to physical or non-physical (e.g., loopback) interfaces.
设备必须为用户提供指定用于所有侦听服务的绑定的方法。它必须支持绑定到与设备本地接口关联的任何地址或网络块。这必须包括绑定到物理或非物理（如环回）接口的地址。
Justification.
正当理由
It is a common practice among operators to configure "loopback" pseudo-interfaces to use as the source and destination of management traffic. These are preferred to physical interfaces
运营商的一种常见做法是配置“环回”伪接口，将其用作管理流量的源和目标。这些是物理接口的首选
because they provide a stable, routable address. Services bound to the addresses of physical interface addresses might become unreachable if the associated hardware goes down, is removed, etc.
因为它们提供了一个稳定的、可路由的地址。如果相关硬件出现故障、被删除等情况，绑定到物理接口地址地址的服务可能无法访问。
This requirement makes it possible to restrict access to management services using routing. Management services may be bound only to the addresses of loopback interfaces. The loopback interfaces may be addressed out of net-blocks that are only routed between the managed devices and the authorized management networks/hosts. This has the effect of making it impossible for anyone to connect to (or attempt to DoS) management services from anywhere but the authorized management networks/hosts.
这一要求使得使用路由限制对管理服务的访问成为可能。管理服务只能绑定到环回接口的地址。环回接口可在仅在受管设备和授权管理网络/主机之间路由的网络块外寻址。这会使任何人都无法从授权管理网络/主机以外的任何位置连接（或尝试DoS）管理服务。
It also greatly reduces the need for complex filters. It reduces the number of ports listening, and thus the number of potential avenues of attack. It ensures that only traffic arriving from legitimate addresses and/or on designated interfaces can access services on the device.
它还大大减少了对复杂过滤器的需要。它减少了侦听端口的数量，从而减少了潜在攻击途径的数量。它确保只有来自合法地址和/或指定接口的流量才能访问设备上的服务。
Examples.
例子。
If the device listens for inbound SSH connections, this requirement means that it should be possible to specify that the device will only listen to connections destined to specific addresses (e.g., the address of the loopback interface) or received on certain interfaces (e.g., an Ethernet interface designated as the "management" interface). It should be possible in this example to configure the device such that the SSH is NOT listening to every address configured on the device. Similar effects may be achieved with the use of global filters, sometimes called "receive" or "loopback" ACLs, that filter traffic destined for the device itself on all interfaces.
如果设备侦听入站SSH连接，则此要求意味着可以指定设备将只侦听发送到特定地址（例如，环回接口的地址）或在某些接口（例如，指定为“管理”接口的以太网接口）上接收的连接。在本例中，应该可以配置设备，使SSH不会侦听设备上配置的每个地址。通过使用全局过滤器（有时称为“接收”或“环回”ACL），可以实现类似的效果，这些过滤器在所有接口上过滤发送给设备本身的流量。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST provide a means that allows the user to specify the source addresses used for all outbound connections or transmissions originating from the device. It SHOULD be possible to specify source addresses independently for each type of outbound connection or transmission. Source addresses MUST be limited to addresses that are assigned to interfaces (including loopbacks) local to the device.
设备必须提供一种方式，允许用户指定用于所有出站连接或源自设备的传输的源地址。应该可以为每种类型的出站连接或传输单独指定源地址。源地址必须限于分配给设备本地接口（包括环回）的地址。
Justification.
正当理由
This allows remote devices receiving connections or transmissions to use source filtering as one means of authentication. For example, if SNMP traps were configured to use a known loopback address as their source, the SNMP workstation receiving the traps (or a firewall in front of it) could be configured to receive SNMP packets only from that address.
这允许接收连接或传输的远程设备使用源过滤作为身份验证的一种手段。例如，如果SNMP陷阱配置为使用已知环回地址作为其源，则接收陷阱的SNMP工作站（或其前面的防火墙）可以配置为仅从该地址接收SNMP数据包。
Examples.
例子。
The operator may allocate a distinct block of addresses from which all loopbacks are numbered. NTP and syslog can be configured to use those loopback addresses as source, while SNMP and BGP may be configured to use specific physical interface addresses. This would facilitate filtering based on source address as one way of rejecting unauthorized attempts to connect to peers/servers.
操作员可以分配一个不同的地址块，所有环回都从该地址块进行编号。NTP和syslog可以配置为使用这些环回地址作为源，而SNMP和BGP可以配置为使用特定的物理接口地址。这将有助于根据源地址进行过滤，作为拒绝未经授权尝试连接到对等方/服务器的一种方法。
Warnings.
警告。
Care should be taken to assure that the addresses chosen are routable between the sending and receiving devices, (e.g., setting SSH to use a loopback address of 10.1.1.1 which is not routed between a router and all intended destinations could cause problems).
应注意确保选择的地址可在发送和接收设备之间路由（例如，将SSH设置为使用10.1.1.1的环回地址，该地址不是在路由器和所有预期目的地之间路由的，可能会导致问题）。
Note that some protocols, such as SCTP [RFC3309], can use more than one IP address as the endpoint of a single connection.
请注意，某些协议（如SCTP[RFC3309]）可以使用多个IP地址作为单个连接的端点。
Also note that [RFC3631] lists address-based authentication as an "insecurity mechanism". Address based authentication should be replaced or augmented by other mechanisms wherever possible.
还请注意，[RFC3631]将基于地址的身份验证列为“不安全机制”。基于地址的身份验证应尽可能由其他机制取代或增强。
Requirement.
要求
The device MUST provide a means to designate particular interfaces as servicing "single-homed networks" (see Section 1.8) and MUST provide an option to automatically drop "spoofed packets" (Section 1.8) received on such interfaces where application of the current forwarding table would not route return traffic back through the same interface. This option MUST work in the presence of dynamic routing and dynamically assigned addresses.
设备必须提供将特定接口指定为服务于“单宿网络”（见第1.8节）的方法，并且必须提供自动丢弃在此类接口上接收的“伪造数据包”（第1.8节）的选项，其中当前转发表的应用不会通过同一接口路由返回流量。此选项必须在存在动态路由和动态分配地址的情况下工作。
Justification.
正当理由
See sections 3 of [RFC1918], sections 5.3.7 and 5.3.8 of [RFC1812], and [RFC2827].
参见[RFC1918]第3节、[RFC1812]第5.3.7节和第5.3.8节以及[RFC2827]。
Examples.
例子。
This requirement could be satisfied in several ways. It could be satisfied by the provision of a single command that automatically generates and applies filters to an interface that implements anti-spoofing. It could be satisfied by the provision of a command that causes the return path for packets received to be checked against the current forwarding tables and dropped if they would not be forwarded back through the interface on which they were received.
这一要求可以通过几种方式得到满足。它可以通过提供一个命令来满足，该命令自动生成过滤器并将其应用于实现反欺骗的接口。可以通过提供一个命令来满足这一要求，该命令使接收到的数据包的返回路径根据当前转发表进行检查，如果这些数据包不通过接收它们的接口转发回来，则丢弃这些数据包。
See [RFC3704].
参见[RFC3704]。
Warnings.
警告。
This requirement only holds for single-homed networks. Note that a simple forwarding table check is not sufficient in the more complex scenarios of multi-homed or multi-attached networks, i.e., where the traffic may be asymmetric. In these cases, a more extensive check such as Feasible Path RPF could be very useful.
此要求仅适用于单宿网络。请注意，在多宿或多连接网络的更复杂场景中，简单的转发表检查是不够的，即，在通信量可能不对称的情况下。在这些情况下，更广泛的检查（如可行路径RPF）可能非常有用。
Requirement.
要求
The device MUST provide a means to automatically drop all "bogons" (Section 1.8) and "martians" (Section 1.8). This option MUST work in the presence of dynamic routing and dynamically assigned addresses.
该装置必须提供一种自动放下所有“博根人”（第1.8节）和“火星人”（第1.8节）的方法。此选项必须在存在动态路由和动态分配地址的情况下工作。
Justification.
正当理由
These sorts of packets have little (no?) legitimate use and are used primarily to allow individuals and organization to avoid identification (and thus accountability) and appear to be most often used for DoS attacks, email abuse, hacking, etc. In addition, transiting these packets needlessly consumes resources and may lead to capacity and performance problems for customers.
这些类型的数据包几乎没有（没有？）合法用途，主要用于让个人和组织避免身份识别（从而避免责任），并且似乎最常用于DoS攻击、电子邮件滥用、黑客攻击等。此外，传输这些数据包会不必要地消耗资源，并可能导致客户的容量和性能问题。
See sections 3 of [RFC1918], sections 5.3.7 and 5.3.8 of [RFC1812], and [RFC2827].
参见[RFC1918]第3节、[RFC1812]第5.3.7节和第5.3.8节以及[RFC2827]。
Examples.
例子。
This requirement could be satisfied by the provision of a command that causes the return path for packets received to be checked against the current forwarding tables and dropped if no viable return path exists. This assumes that steps are taken to assure that no bogon entries are present in the forwarding tables (for example filtering routing updates per Section 2.7.5 to reject advertisements of unassigned addresses).
可以通过提供一个命令来满足这一要求，该命令将根据当前转发表检查接收到的数据包的返回路径，如果不存在可行的返回路径，则将其丢弃。这假设已采取步骤确保转发表中不存在bogon条目（例如，根据第2.7.5节过滤路由更新以拒绝未分配地址的播发）。
See [RFC3704].
参见[RFC3704]。
Warnings.
警告。
This requirement only holds for single-homed networks. Note that a simple forwarding table check is not sufficient in the more complex scenarios of multi-homed or multi-attached networks, i.e., where the traffic may be asymmetric. In these cases, a more extensive check such as Feasible Path RPF could be very useful.
此要求仅适用于单宿网络。请注意，在多宿或多连接网络的更复杂场景中，简单的转发表检查是不够的，即，在通信量可能不对称的情况下。在这些情况下，更广泛的检查（如可行路径RPF）可能非常有用。
Requirement.
要求
The device MUST provide accurate, per-interface counts of spoofed packets dropped in accordance with Section 2.5.5 and Section 2.5.6.
根据第2.5.5节和第2.5.6节，设备必须提供准确的、每接口丢弃的伪造数据包计数。
Justification.
正当理由
Counters can help in identifying the source of spoofed traffic.
计数器可以帮助识别伪造流量的来源。
Examples.
例子。
An edge router may have several single-homed customers attached. When an attack using spoofed packets is detected, a quick check of counters may be able to identify which customer is attempting to send spoofed traffic.
边缘路由器可以连接多个单宿客户。当检测到使用伪造数据包的攻击时，快速检查计数器可能能够识别哪个客户正试图发送伪造流量。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST provide the capability to limit the rate at which it will pass traffic based on protocol, source and destination IP address or CIDR block, source and destination port, and interface. Protocols MUST include at least IP, ICMP, UDP, and TCP and SHOULD include any protocol.
设备必须能够根据协议、源和目标IP地址或CIDR块、源和目标端口以及接口限制其通过流量的速率。协议必须至少包括IP、ICMP、UDP和TCP，并且应包括任何协议。
Justification.
正当理由
This requirement provides a means of reducing or eliminating the impact of certain types of attacks. Also, rate limiting has the advantage that in some cases it can be turned on a priori, thereby offering some ability to mitigate the effect of future attacks prior to any explicit operator reaction to the attacks.
此要求提供了一种减少或消除某些类型攻击影响的方法。此外，速率限制的优点是，在某些情况下，它可以先验地启用，从而在操作员对攻击做出任何明确反应之前，提供某种能力来减轻未来攻击的影响。
Examples.
例子。
Assume that a web hosting company provides space in its data-center to a company that becomes unpopular with a certain element of network users, who then decide to flood the web server with inbound ICMP traffic. It would be useful in such a situation to be able to rate-filter inbound ICMP traffic at the data-center's border routers. On the other side, assume that a new worm is released that infects vulnerable database servers such that they then start spewing traffic on TCP port 1433 aimed at random destination addresses as fast as the system and network interface of the infected server is capable. Further assume that a data center has many vulnerable servers that are infected and simultaneously sending large amounts of traffic with the result that all outbound links are saturated. Implementation of this requirement, would allow the network operator to rate limit inbound and/or outbound TCP 1433 traffic (possibly to a rate of 0 packets/bytes per second) to respond to the attack and maintain service levels for other legitimate customers/traffic.
假设某个网络托管公司在其数据中心为某个公司提供空间，而该公司在某个网络用户中变得不受欢迎，然后这些用户决定向web服务器注入入站ICMP流量。在这种情况下，能够对数据中心边界路由器上的入站ICMP流量进行分级是非常有用的。另一方面，假设释放了一个新的蠕虫，该蠕虫会感染易受攻击的数据库服务器，然后这些服务器开始在TCP端口1433上以受感染服务器的系统和网络接口所能达到的速度向随机目标地址喷出流量。进一步假设一个数据中心有许多易受攻击的服务器受到感染，同时发送大量流量，导致所有出站链路饱和。此要求的实施将允许网络运营商对入站和/或出站TCP 1433流量进行速率限制（可能为每秒0个包/字节的速率），以响应攻击并维持其他合法客户/流量的服务级别。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST provide support to rate-limit input and/or output separately on each interface.
设备必须在每个接口上分别提供速率限制输入和/或输出支持。
Justification.
正当理由
This level of granular control allows appropriately targeted controls that minimize the impact on third parties.
这种粒度控制级别允许适当的目标控制，以最大限度地减少对第三方的影响。
Examples.
例子。
If an ICMP flood is directed a single customer on an edge router, it may be appropriate to rate-limit outbound ICMP only on that customers interface.
如果ICMP洪水定向到边缘路由器上的单个客户，则仅在该客户接口上对出站ICMP进行速率限制可能是合适的。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST be able to rate limit based on all TCP control flag bits. The device SHOULD support rate limiting of other stateful protocols where the normal processing of the protocol gives the device access to protocol state.
设备必须能够基于所有TCP控制标志位进行速率限制。设备应支持其他有状态协议的速率限制，协议的正常处理允许设备访问协议状态。
Justification.
正当理由
This allows appropriate response to certain classes of attack.
这允许对某些类型的攻击做出适当的响应。
Examples.
例子。
For example, for TCP sessions, it should be possible to rate limit based on the SYN, SYN-ACK, RST, or other bit state.
例如，对于TCP会话，应该可以基于SYN、SYN-ACK、RST或其他位状态设置速率限制。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST provide a means to filter IP packets on any interface implementing IP.
设备必须提供在任何实现IP的接口上过滤IP数据包的方法。
Justification.
正当理由
Packet filtering is important because it provides a basic means of implementing policies that specify which traffic is allowed and which is not. It also provides a basic tool for responding to malicious traffic.
数据包过滤非常重要，因为它提供了实现策略的基本方法，这些策略指定允许哪些通信量，哪些不允许。它还提供了响应恶意流量的基本工具。
Examples.
例子。
Access control lists that allow filtering based on protocol and/or source/destination address and or source/destination port would be one example.
允许基于协议和/或源/目标地址和/或源/目标端口进行过滤的访问控制列表就是一个例子。
Warnings.
警告。
None.
没有一个
Requirement.
要求
It MUST be possible to apply the filtering mechanism to traffic that is addressed directly to the device via any of its interfaces - including loopback interfaces.
必须能够将过滤机制应用于通过任何接口（包括环回接口）直接发送到设备的流量。
Justification.
正当理由
This allows the operator to apply filters that protect the device itself from attacks and unauthorized access.
这允许操作员应用过滤器，保护设备本身免受攻击和未经授权的访问。
Examples.
例子。
Examples of this might include filters that permit only BGP from peers and SNMP and SSH from an authorized management segment and directed to the device itself, while dropping all other traffic addressed to the device.
这方面的示例可能包括只允许来自对等方的BGP以及来自授权管理段并定向到设备本身的SNMP和SSH的筛选器，同时删除所有其他寻址到设备的流量。
Warnings.
警告。
None.
没有一个
Requirement.
要求
It MUST be possible to apply the filtering mechanism to traffic that is being routed (switched) through the device.
必须能够对通过设备路由（交换）的流量应用过滤机制。
Justification.
正当理由
This permits implementation of basic policies on devices that carry transit traffic (routers, switches, etc.).
这允许在传输传输流量的设备（路由器、交换机等）上实施基本策略。
Examples.
例子。
One simple and common way to meet this requirement is to provide the ability to filter traffic inbound to each interface and/or outbound from each interface. Ingress filtering as described in [RFC2827] provides one example of the use of this capability.
满足此要求的一种简单而常见的方法是提供过滤每个接口的入站流量和/或每个接口的出站流量的能力。[RFC2827]中描述的入口过滤提供了使用此功能的一个示例。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST provide a means to filter packets without significant performance degradation. This specifically applies to stateless packet filtering operating on layer 3 (IP) and layer 4 (TCP or UDP) headers, as well as normal packet forwarding information such as incoming and outgoing interfaces.
设备必须提供一种过滤数据包的方法，而不会显著降低性能。这特别适用于在第3层（IP）和第4层（TCP或UDP）头上运行的无状态数据包过滤，以及正常的数据包转发信息，如传入和传出接口。
The device MUST be able to apply stateless packet filters on ALL interfaces (up to the maximum number possible) simultaneously and with multiple filters per interface (e.g., inbound and outbound).
设备必须能够在所有接口上同时应用无状态数据包过滤器（最大可能数量），并且每个接口有多个过滤器（例如，入站和出站）。
Justification.
正当理由
This enables the implementation of filtering wherever and whenever needed. To the extent that filtering causes degradation, it may not be possible to apply filters that implement the appropriate policies.
这使得随时随地都可以实现过滤。如果过滤导致降级，则可能无法应用实现适当策略的过滤器。
Examples.
例子。
Another way of stating the requirement is that filter performance should not be the limiting factor in device throughput. If a device is capable of forwarding 30Mb/sec without filtering, then it should be able to forward the same amount with filtering in place.
说明要求的另一种方式是，过滤器性能不应成为设备吞吐量的限制因素。如果设备能够在不进行过滤的情况下以30Mb/秒的速度转发，那么在进行过滤的情况下，它应该能够转发相同数量的数据。
Warnings.
警告。
The definition of "significant" is subjective. At one end of the spectrum it might mean "the application of filters may cause the box to crash". At the other end would be a throughput loss of less than one percent with tens of thousands of filters applied. The level of performance degradation that is acceptable will have to be determined by the operator.
“重大”的定义是主观的。在光谱的一端，它可能意味着“应用过滤器可能会导致盒子崩溃”。另一方面，如果应用成千上万个过滤器，吞吐量损失将不到1%。可接受的性能下降水平必须由操作员确定。
Repeatable test data showing filter performance impact would be very useful in evaluating conformance with this requirement. Tests should include such information as packet size, packet rate, number of interfaces tested (source/destination), types of interfaces, routing table size, routing protocols in use, frequency of routing updates, etc. See [bmwg-acc-bench].
显示过滤器性能影响的可重复测试数据对于评估是否符合此要求非常有用。测试应包括数据包大小、数据包速率、测试接口数量（源/目的地）、接口类型、路由表大小、使用的路由协议、路由更新频率等信息。请参阅[bmwg acc bench]。
This requirement does not address stateful filtering, filtering above layer 4 headers or other more advanced types of filtering that may be important in certain operational environments.
此要求不涉及有状态过滤、第4层标头上方的过滤或其他在某些操作环境中可能很重要的更高级类型的过滤。
Requirement.
要求
The device MUST provide a means to filter routing updates for all protocols used to exchange external routing information.
设备必须提供一种方法来过滤用于交换外部路由信息的所有协议的路由更新。
Justification.
正当理由
See [RFC3013] and section 3.2 of [RFC2196].
参见[RFC3013]和[RFC2196]第3.2节。
Examples.
例子。
Operators may wish to ignore advertisements for routes to addresses allocated for private internets. See eBGP.
运营商可能希望忽略为专用互联网分配地址的路由广告。见eBGP。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST provide a mechanism to allow the specification of the action to be taken when a filter rule matches. Actions MUST include "permit" (allow the traffic), "reject" (drop with appropriate notification to sender), and "drop" (drop with no notification to sender). Also see Section 2.7.7 and Section 2.9
设备必须提供一种机制，允许在筛选规则匹配时指定要执行的操作。操作必须包括“允许”（允许流量）、“拒绝”（向发件人发出适当通知时丢弃）和“丢弃”（不向发件人发出通知时丢弃）。另见第2.7.7节和第2.9节
Justification.
正当理由
This capability is essential to the use of filters to enforce policy.
此功能对于使用筛选器强制执行策略至关重要。
Examples.
例子。
Assume that you have a small DMZ network connected to the Internet. You want to allow management using SSH coming from your corporate office. In this case, you might "permit" all traffic to port 22 in the DMZ from your corporate network, "rejecting" all others. Port 22 traffic from the corporate network is allowed through. Port 22 traffic from all other addresses results in an ICMP message to the sender. For those who are slightly more paranoid, you might choose to "drop" instead of "reject" traffic from unauthorized addresses, with the result being that *nothing* is sent back to the source.
假设您有一个连接到Internet的小型DMZ网络。您希望允许使用来自公司办公室的SSH进行管理。在这种情况下，您可以“允许”从公司网络到DMZ中端口22的所有流量，“拒绝”所有其他流量。允许来自公司网络的端口22流量通过。来自所有其他地址的端口22通信将向发送方发送ICMP消息。对于那些稍微有点偏执的人，您可能会选择“删除”而不是“拒绝”来自未经授权地址的通信，其结果是*没有*发送回源。
Warnings.
警告。
While silently dropping traffic without sending notification may be the correct action in security terms, consideration should be given to operational implications. See [RFC3360] for consideration of potential problems caused by sending inappropriate TCP Resets.
虽然在安全方面，无需发送通知而默默地丢弃流量可能是正确的操作，但应考虑操作影响。请参阅[RFC3360]了解发送不适当的TCP重置所导致的潜在问题。
Requirement.
要求
It MUST be possible to log all filter actions. The logging capability MUST be able to capture at least the following data:
必须能够记录所有筛选器操作。日志功能必须至少能够捕获以下数据：
* permit/deny/drop status,
* 允许/拒绝/放弃状态，
* source and destination IP address,
* 源和目标IP地址，
* source and destination ports (if applicable to the protocol),
* 源端口和目标端口（如果适用于协议），
* which network element received the packet (interface, MAC address or other layer 2 information that identifies the previous hop source of the packet).
* 哪个网元接收到数据包（接口、MAC地址或识别数据包前一跳源的其他第2层信息）。
Logging of filter actions is subject to the requirements of Section 2.11.
过滤器动作的记录应符合第2.11节的要求。
Justification.
正当理由
Logging is essential for auditing, incident response, and operations. Examples.
日志记录对于审核、事件响应和操作至关重要。例子。
A desktop network may not provide any services that should be accessible from "outside." In such cases, all inbound connection attempts should be logged as possible intrusion attempts.
桌面网络可能不提供任何应该从“外部”访问的服务。在这种情况下，所有入站连接尝试都应记录为可能的入侵尝试。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST provide a means to filter traffic based on the value of the protocol field in the IP header.
设备必须提供一种根据IP报头中协议字段的值过滤流量的方法。
Justification.
正当理由
Being able to filter on protocol is necessary to allow implementation of policy, secure operations and for support of incident response.
能够根据协议进行过滤是实现策略、安全操作和支持事件响应所必需的。
Examples.
例子。
Some denial of service attacks are based on the ability to flood the victim with ICMP traffic. One quick way (admittedly with some negative side effects) to mitigate the effects of such attacks is to drop all ICMP traffic headed toward the victim.
一些拒绝服务攻击是基于向受害者大量发送ICMP流量的能力。减轻此类攻击影响的一个快速方法（当然有一些负面影响）是丢弃所有指向受害者的ICMP流量。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The function MUST be able to control the flow of traffic based on source and/or destination IP address or blocks of addresses such as Classless Inter-Domain Routing (CIDR) blocks.
该功能必须能够基于源和/或目标IP地址或地址块（如无类域间路由（CIDR）块）控制流量。
Justification.
正当理由
The capability to filter on addresses and address blocks is a fundamental tool for establishing boundaries between different networks.
过滤地址和地址块的能力是在不同网络之间建立边界的基本工具。
Examples.
例子。
One example of the use of address based filtering is to implement ingress filtering per [RFC2827].
使用基于地址的过滤的一个示例是根据[RFC2827]实现入口过滤。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The filtering mechanism MUST support filtering based on the value(s) of any portion of the protocol headers for IP, ICMP, UDP and TCP. It SHOULD support filtering of all other protocols supported at layer 3 and 4. It MAY support filtering based on the headers of higher level protocols. It SHOULD be possible to specify fields by name (e.g., "protocol = ICMP") rather than bit-offset/length/numeric value (e.g., 72:8 = 1).
过滤机制必须支持基于IP、ICMP、UDP和TCP协议头任何部分的值进行过滤。它应该支持过滤第3层和第4层支持的所有其他协议。它可能支持基于更高级别协议的头进行过滤。应该可以按名称（例如，“协议=ICMP”）而不是位偏移量/长度/数值（例如72:8=1）指定字段。
Justification.
正当理由
Being able to filter on portions of the header is necessary to allow implementation of policy, secure operations, and support incident response.
能够对报头的某些部分进行筛选是实现策略、安全操作和支持事件响应所必需的。
Examples.
例子。
This requirement implies that it is possible to filter based on TCP or UDP port numbers, TCP flags such as SYN, ACK and RST bits, and ICMP type and code fields. One common example is to reject "inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear or SYN bit set+ACK,FIN and RST bits clear). Another common
此要求意味着可以根据TCP或UDP端口号、TCP标志（如SYN、ACK和RST位）以及ICMP类型和代码字段进行过滤。一个常见的示例是拒绝“入站”TCP连接尝试（TCP、SYN位集+ACK位清除或SYN位集+ACK、FIN和RST位清除）。另一个共同点
example is the ability to control what services are allowed in/out of a network. It may be desirable to only allow inbound connections on port 80 (HTTP) and 443 (HTTPS) to a network hosting web servers.
例如，控制允许哪些服务进出网络的能力。可能需要只允许端口80（HTTP）和443（HTTPS）上的入站连接到承载web服务器的网络。
Warnings.
警告。
None.
没有一个
Requirement.
要求
It MUST be possible to filter both incoming and outgoing traffic on any interface.
必须能够过滤任何接口上的传入和传出流量。
Justification.
正当理由
This requirement allows flexibility in applying filters at the place that makes the most sense. It allows invalid or malicious traffic to be dropped as close to the source as possible.
这一要求允许在最有意义的地方灵活应用过滤器。它允许在尽可能靠近源的位置丢弃无效或恶意流量。
Examples.
例子。
It might be desirable on a border router, for example, to apply an egress filter outbound on the interface that connects a site to its external ISP to drop outbound traffic that does not have a valid internal source address. Inbound, it might be desirable to apply a filter that blocks all traffic from a site that is known to forward or originate lots of junk mail.
例如，在边界路由器上可能需要在将站点连接到其外部ISP的接口上应用出站过滤器，以丢弃没有有效内部源地址的出站流量。入站时，可能需要应用一个过滤器来阻止来自已知转发或发起大量垃圾邮件的站点的所有流量。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST supply a facility for accurately counting all filter hits.
该设备必须提供一个设施，用于准确计算所有过滤器点击次数。
Justification.
正当理由
Accurate counting of filter rule matches is important because it shows the frequency of attempts to violate policy. This enables resources to be focused on areas of greatest need.
过滤规则匹配的准确计数非常重要，因为它显示了违反策略的尝试频率。这使得资源能够集中在最需要的领域。
Examples.
例子。
Assume, for example, that a ISP network implements anti-spoofing egress filters (see [RFC2827]) on interfaces of its edge routers that support single-homed stub networks. Counters could enable the ISP to detect cases where large numbers of spoofed packets are being sent. This may indicate that the customer is performing potentially malicious actions (possibly in violation of the ISPs Acceptable Use Policy), or that system(s) on the customers network have been "owned" by hackers and are being (mis)used to launch attacks.
例如，假设ISP网络在其支持单宿存根网络的边缘路由器的接口上实现反欺骗出口过滤器（请参见[RFC2827]）。计数器可以使ISP检测发送大量伪造数据包的情况。这可能表明客户正在执行潜在的恶意操作（可能违反ISPs可接受的使用策略），或者客户网络上的系统已被黑客“拥有”，并被（错误地）用于发起攻击。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST provide a mechanism to display filter counters.
设备必须提供显示过滤器计数器的机制。
Justification.
正当理由
Information that is collected is not useful unless it can be displayed in a useful manner.
收集的信息没有用处，除非它能以有用的方式显示出来。
Examples.
例子。
Assume there is a router with four interfaces. One is an up-link to an ISP providing routes to the Internet. The other three connect to separate internal networks. Assume that a host on one of the internal networks has been compromised by a hacker and is sending traffic with bogus source addresses. In such a situation, it might be desirable to apply ingress filters to each of the internal interfaces. Once the filters are in place, the counters can be examined to determine the source (inbound interface) of the bogus packets.
假设有一个路由器有四个接口。一个是向上链接到ISP，提供到Internet的路由。其他三个连接到单独的内部网络。假设某个内部网络上的主机已被黑客入侵，并使用伪造的源地址发送流量。在这种情况下，可能希望对每个内部接口应用入口过滤器。一旦过滤器就位，就可以检查计数器以确定假数据包的源（入站接口）。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST provide a mechanism to display filter counters per rule.
设备必须提供根据规则显示筛选计数器的机制。
Justification.
正当理由
This makes it possible to see which rules are matching and how frequently.
这样可以查看哪些规则匹配以及匹配的频率。
Examples.
例子。
Assume that a filter has been defined that has two rules, one permitting all SSH traffic (tcp/22) and the second dropping all remaining traffic. If three packets are directed toward/through the point at which the filter is applied, one to port 22, the others to different ports, then the counter display should show 1 packet matching the permit tcp/22 rule and 2 packets matching the deny all others rule.
假设定义了一个过滤器，该过滤器有两个规则，一个允许所有SSH流量（tcp/22），另一个删除所有剩余流量。如果有三个数据包指向/通过应用过滤器的点，一个指向端口22，另一个指向不同的端口，则计数器显示屏应显示1个与允许tcp/22规则匹配的数据包和2个与拒绝所有其他规则匹配的数据包。
Warnings.
警告。
None.
没有一个
Requirement.
要求
If it is possible for a filter to be applied more than once at the same time, then the device MUST provide a mechanism to display filter counters per filter application.
如果一个过滤器可以同时应用不止一次，那么设备必须提供一种机制来显示每个过滤器应用的过滤器计数器。
Justification.
正当理由
It may make sense to apply the same filter definition simultaneously more than one time (to different interfaces, etc.). If so, it would be much more useful to know which instance of a filter is matching than to know that some instance was matching somewhere.
同时多次应用相同的过滤器定义（对不同的接口等）可能是有意义的。如果是这样，那么知道过滤器的哪个实例正在匹配比知道某个实例在某处匹配更有用。
Examples.
例子。
One way to implement this requirement would be to have the counter display mechanism show the interface (or other entity) to which the filter has been applied, along with the name (or other designator) for the filter. For example if a filter named
实现此要求的一种方法是让计数器显示机制显示已应用过滤器的接口（或其他实体），以及过滤器的名称（或其他标识符）。例如，如果一个名为
"desktop_outbound" applied two different interfaces, say, "ethernet0" and "ethernet1", the display should indicate something like "matches of filter 'desktop_outbound' on ethernet0 ..." and "matches of filter 'desktop_outbound' on ethernet1 ..."
“desktop_outbound”应用了两个不同的接口，如“ethernet0”和“ethernet1”，显示屏上应显示类似“ethernet0上的过滤器‘desktop_outbound’匹配项…”和“ethernet1上的过滤器‘desktop_outbound’匹配项…”
Warnings.
警告。
None.
没有一个
Requirement.
要求
It MUST be possible to reset counters to zero on a per filter basis.
必须能够根据每个过滤器将计数器重置为零。
For the purposes of this requirement it would be acceptable for the system to maintain two counters: an "absolute counter", C[now], and a "reset" counter, C[reset]. The absolute counter would maintain counts that increase monotonically until they wrap or overflow the counter. The reset counter would receive a copy of the current value of the absolute counter when the reset function was issued for that counter. Functions that display or retrieve the counter could then display the delta (C[now] - C[reset]).
出于本要求的目的，系统可以维护两个计数器：一个“绝对计数器”，C[now]，和一个“重置”计数器，C[reset]。绝对计数器将保持单调递增的计数，直到它们包裹或溢出计数器。当为计数器发出重置功能时，重置计数器将收到绝对计数器当前值的副本。然后，显示或检索计数器的函数可以显示增量（C[now]-C[reset]）。
Justification.
正当理由
This allows operators to get a current picture of the traffic matching particular rules/filters.
这允许运营商获得与特定规则/过滤器匹配的流量的当前图片。
Examples.
例子。
Assume that filter counters are being used to detect internal hosts that are infected with a new worm. Once it is believed that all infected hosts have been cleaned up and the worm removed, the next step would be to verify that. One way of doing so would be to reset the filter counters to zero and see if traffic indicative of the worm has ceased.
假设筛选器计数器用于检测感染新蠕虫的内部主机。一旦确定所有受感染的主机都已被清除，蠕虫已被清除，下一步就是验证这一点。一种方法是将过滤器计数器重置为零，并查看指示蠕虫的流量是否已停止。
Warnings.
警告。
None.
没有一个
Requirement.
要求
Filter counters MUST be accurate. They MUST reflect the actual number of matching packets since the last counter reset. Filter counters MUST be capable of holding up to 2^32 - 1 values without overflowing and SHOULD be capable of holding up to 2^64 - 1 values.
过滤器计数器必须准确。它们必须反映自上次计数器重置以来匹配数据包的实际数量。过滤器计数器必须能够容纳最多2^32-1个值而不会溢出，并且应该能够容纳最多2^64-1个值。
Justification.
正当理由
Inaccurate data can not be relied on as the basis for action. Underreported data can conceal the magnitude of a problem.
不准确的数据不能作为采取行动的依据。少报数据可能掩盖问题的严重性。
Examples.
例子。
If N packets matching a filter are sent to/through a device, then the counter should show N matches.
如果N个与筛选器匹配的数据包被发送到/通过设备发送，则计数器应显示N个匹配项。
Warnings.
警告。
None.
没有一个
Requirement.
要求
It MUST be possible to enable/disable logging on a per rule basis.
必须能够根据每个规则启用/禁用日志记录。
Justification.
正当理由
The ability to tune the granularity of logging allows the operator to log only the information that is desired. Without this capability, it is possible that extra data (or none at all) would be logged, making it more difficult to find relevant information.
调整日志粒度的能力允许操作员只记录所需的信息。如果没有此功能，可能会记录额外的数据（或根本没有），从而更难找到相关信息。
Examples.
例子。
If a filter is defined that has several rules, and one of the rules denies telnet (tcp/23) connections, then it should be possible to specify that only matches on the rule that denies telnet should generate a log message.
如果定义了具有多个规则的筛选器，并且其中一个规则拒绝telnet（tcp/23）连接，则应该可以指定只有拒绝telnet的规则上的匹配项才会生成日志消息。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST provide a logging facility that is based on protocols subject to open review. See Section 1.8. Custom or proprietary logging protocols MAY be implemented provided the same information is made available.
该设备必须提供一个基于开放式审查协议的日志记录设施。见第1.8节。如果提供相同的信息，则可以实施自定义或专有日志记录协议。
Justification.
正当理由
The use of logging based on protocols subject to open review permits the operator to perform archival and analysis of logs without relying on vendor-supplied software and servers.
使用基于开放式审查协议的日志记录允许运营商在不依赖供应商提供的软件和服务器的情况下对日志进行归档和分析。
Examples.
例子。
This requirement may be satisfied by the use of one or more of syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+ [RFC1492] or RADIUS [RFC2865].
可通过使用一个或多个系统日志[RFC3164]、可靠交付的系统日志[RFC3195]、TACACS+[RFC1492]或RADIUS[RFC2865]来满足此要求。
Warnings.
警告。
While [RFC3164] meets this requirement, it has many security
issues and by itself does not meet the requirements of Section
2.1.1. See the security considerations section of [RFC3164] for
a list of issues. [RFC3195] provides solutions to most/all of
these issues....however at the time of this writing there are few
implementations. Other possible solutions might be to tunnel
syslog over a secure transport...but this often raises difficult
key management and scalability issues.
While [RFC3164] meets this requirement, it has many security
issues and by itself does not meet the requirements of Section
2.1.1. See the security considerations section of [RFC3164] for
a list of issues. [RFC3195] provides solutions to most/all of
these issues....however at the time of this writing there are few
implementations. Other possible solutions might be to tunnel
syslog over a secure transport...but this often raises difficult
key management and scalability issues.
The current best solution seems to be the following:
目前最好的解决方案似乎是：
* Implement [RFC3164].
* 执行[RFC3164]。
* Consider implementing [RFC3195].
* 考虑实施[RCF3195]。
Requirement.
要求
The device MUST support transmission of records of security related events to one or more remote devices. There MUST be configuration settings on the device that allow selection of servers.
设备必须支持将安全相关事件的记录传输到一个或多个远程设备。设备上必须有允许选择服务器的配置设置。
Justification.
正当理由
This is important because it supports individual accountability. It is important to store them on a separate server to preserve them in case of failure or compromise of the managed device.
这很重要，因为它支持个人问责制。重要的是将它们存储在单独的服务器上，以便在受管设备出现故障或损坏时保留它们。
Examples.
例子。
This requirement may be satisfied by the use of one or more of: syslog [RFC3164], syslog with reliable delivery [RFC3195], TACACS+ [RFC1492] or RADIUS [RFC2865].
可通过使用一个或多个系统日志[RFC3164]、可靠交付的系统日志[RFC3195]、TACACS+[RFC1492]或RADIUS[RFC2865]来满足该要求。
Warnings.
警告。
Note that there may be privacy or legal considerations when logging/monitoring user activity.
请注意，在记录/监视用户活动时，可能会考虑隐私或法律问题。
High volumes of logging may generate excessive network traffic and/or compete for scarce memory and CPU resources on the device.
大量日志记录可能会产生过多的网络流量和/或争夺设备上稀缺的内存和CPU资源。
Requirement.
要求
It SHOULD be possible to select reliable delivery of log messages.
应该可以选择日志消息的可靠传递。
Justification.
正当理由
Reliable delivery is important to the extent that log data is depended upon to make operational decisions and forensic analysis. Without reliable delivery, log data becomes a collection of hints.
可靠的交付非常重要，因为日志数据依赖于做出操作决策和法医分析。如果没有可靠的传递，日志数据将成为提示的集合。
Examples.
例子。
One example of reliable syslog delivery is defined in [RFC3195]. Syslog-ng provides another example, although the protocol has not been standardized.
[RFC3195]中定义了可靠系统日志交付的一个示例。Syslog ng提供了另一个示例，尽管该协议尚未标准化。
Warnings.
警告。
None.
没有一个
Requirement.
要求
It SHOULD be possible to log locally on the device itself. Local logging SHOULD be written to non-volatile storage.
应该可以在设备本身上本地登录。本地日志应写入非易失性存储器。
Justification.
正当理由
Local logging of failed authentication attempts to non-volatile storage is critical. It provides a means of detecting attacks where the device is isolated from its authentication interfaces and attacked at the console.
将失败的身份验证尝试本地记录到非易失性存储是至关重要的。它提供了一种检测攻击的方法，其中设备与其身份验证接口隔离，并在控制台受到攻击。
Local logging is important for viewing information when connected to the device. It provides some backup of log data in case remote logging fails. It provides a way to view logs relevant to one device without having to sort through a possibly large set of logs from other devices.
本地日志记录对于连接到设备时查看信息非常重要。它提供了一些日志数据备份，以防远程日志记录失败。它提供了一种查看与一个设备相关的日志的方法，而无需对来自其他设备的可能大量日志进行排序。
Examples.
例子。
One example of local logging would be a memory buffer that receives copies of messages sent to the remote log server. Another example might be a local syslog server (assuming the device is capable of running syslog and has some local storage).
本地日志记录的一个示例是一个内存缓冲区，它接收发送到远程日志服务器的消息副本。另一个示例可能是本地syslog服务器（假设设备能够运行syslog并具有一些本地存储）。
Warnings.
警告。
Storage on the device may be limited. High volumes of logging may quickly fill available storage, in which case there are two options: new logs overwrite old logs (possibly via the use of a circular memory buffer or log file rotation), or logging stops.
设备上的存储可能受到限制。大量日志记录可能会很快填满可用存储，在这种情况下，有两种选择：新日志覆盖旧日志（可能通过使用循环内存缓冲区或日志文件轮换），或停止日志记录。
Requirement.
要求
The device MUST maintain accurate, "high resolution" (see definition in Section 1.8) system time.
设备必须保持准确的“高分辨率”（见第1.8节中的定义）系统时间。
Justification.
正当理由
Accurate time is important to the generation of reliable log data. Accurate time is also important to the correct operation of some authentication mechanisms.
准确的时间对于生成可靠的测井数据非常重要。准确的时间对于某些身份验证机制的正确操作也很重要。
Examples.
例子。
This requirement may be satisfied by supporting Network Time Protocol (NTP), Simple Network Time Protocol (SNTP), or via direct connection to an accurate time source.
可通过支持网络时间协议（NTP）、简单网络时间协议（SNTP）或通过直接连接到精确时间源来满足此要求。
Warnings.
警告。
System clock chips are inaccurate to varying degrees. System time should not be relied upon unless it is regularly checked and synchronized with a known, accurate external time source (such as an NTP stratum-1 server). Also note that if network time synchronization is used, an attacker may be able to manipulate the clock unless cryptographic authentication is used.
系统时钟芯片在不同程度上不准确。除非定期检查系统时间并与已知、准确的外部时间源（如NTP stratum-1服务器）同步，否则不应依赖系统时间。还请注意，如果使用网络时间同步，攻击者可能会操纵时钟，除非使用加密身份验证。
Requirement.
要求
All displays and logs of system time MUST include a timezone or offset from UTC.
系统时间的所有显示和日志必须包括时区或UTC的偏移量。
Justification.
正当理由
Knowing the timezone or UTC offset makes correlation of data and coordination with data in other timezones possible.
了解时区或UTC偏移量可以使数据关联和与其他时区的数据协调成为可能。
Examples.
例子。
Bob is in Newfoundland, Canada which is UTC -3:30. Alice is somewhere in Indiana, USA. Some parts of Indiana switch to daylight savings time while others do not. A user on Bob's network attacks a user on Alice's network. Both are using logs with local timezones and no indication of UTC offset. Correlating these logs will be difficult and error prone. Including timezone, or better, UTC offset, eliminates these difficulties.
鲍勃在加拿大纽芬兰，UTC-3:30。艾丽斯在美国印第安纳州的某个地方。印第安纳州的一些地区改为夏令时，而另一些地区则不改。Bob网络上的用户攻击Alice网络上的用户。两者都使用带有本地时区的日志，并且没有UTC偏移指示。关联这些日志将很困难，而且容易出错。包括时区，或者更好的UTC偏移，可以消除这些困难。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The default timezone for display and logging SHOULD be UTC. The device MAY support a mechanism to allow the operator to specify the display and logging of times in a timezone other than UTC.
显示和记录的默认时区应为UTC。设备可能支持一种机制，允许操作员指定UTC以外时区的时间显示和记录。
Justification.
正当理由
Knowing the timezone or UTC offset makes correlation of data and coordination with data in other timezones possible.
了解时区或UTC偏移量可以使数据关联和与其他时区的数据协调成为可能。
Examples.
例子。
Bob in Newfoundland (UTC -3:30) and Alice in Indiana (UTC -5 or UTC -6 depending on the time of year and exact county in Indiana) are working an incident together using their logs. Both left the default settings, which was UTC, so there was no translation of time necessary to correlate the logs.
纽芬兰的鲍勃（UTC-3:30）和印第安纳州的爱丽丝（UTC-5或UTC-6，取决于一年中的时间和印第安纳州的确切县）正在使用他们的日志一起处理事件。两者都保留了默认设置，即UTC，因此不需要转换时间来关联日志。
Warnings.
警告。
None.
没有一个
Requirement.
要求
By default, the device MUST timestamp all log messages. The timestamp MUST be accurate to within a second or less. The timestamp MUST include a timezone. There MAY be a mechanism to disable the generation of timestamps.
默认情况下，设备必须为所有日志消息添加时间戳。时间戳必须精确到一秒钟或更短。时间戳必须包含时区。可能存在一种机制来禁用时间戳的生成。
Justification.
正当理由
Accurate timestamps are necessary for correlating events, particularly across multiple devices or with other organizations. This applies when it is necessary to analyze logs.
准确的时间戳对于关联事件是必要的，特别是在多个设备之间或与其他组织之间。这在需要分析日志时适用。
Examples.
例子。
This requirement MAY be satisfied by writing timestamps into syslog messages.
可以通过将时间戳写入syslog消息来满足此要求。
Warnings.
警告。
It is difficult to correlate logs from different time zones. Security events on the Internet often involve machines and logs from a variety of physical locations. For that reason, UTC is preferred, all other things being equal.
很难关联来自不同时区的日志。Internet上的安全事件通常涉及来自不同物理位置的计算机和日志。因此，在所有其他条件相同的情况下，首选UTC。
Requirement.
要求
Log messages MUST NOT list translated addresses (DNS names) associated with the address without listing the untranslated IP address where the IP address is available to the device generating the log message.
日志消息不得列出与该地址关联的已翻译地址（DNS名称），而不列出生成日志消息的设备可以使用该IP地址的未翻译IP地址。
Justification.
正当理由
Including IP address of access list violations authentication attempts, address lease assignments and similar events in logs enables a level of individual and organizational accountability and is necessary to enable analysis of network events, incidents, policy violations, etc.
将访问列表冲突的IP地址、身份验证尝试、地址租用分配和类似事件包含在日志中可以实现一定程度的个人和组织责任，并且是分析网络事件、事件、策略冲突等所必需的。
DNS entries tend to change more quickly than IP block assignments. This makes the address more reliable for data forensics.
DNS条目的更改速度往往比IP块分配更快。这使得数据取证的地址更加可靠。
DNS lookups can be slow and consume resources.
DNS查找可能会很慢并消耗资源。
Examples.
例子。
A failed network login should generate a record with the source address of the login attempt.
失败的网络登录应生成一条记录，其中包含登录尝试的源地址。
Warnings.
警告。
* Source addresses may be spoofed. Network-based attacks often use spoofed source addresses. Source addresses should not be completely trusted unless verified by other means.
* 源地址可能被欺骗。基于网络的攻击通常使用伪造的源地址。除非通过其他方式验证，否则不应完全信任源地址。
* Addresses may be reassigned to different individual, for example, in a desktop environment using DHCP. In such cases the individual accountability afforded by this requirement is weak. Having accurate time in the logs increases the chances that the use of an address can be correlated to an individual.
* 例如，在使用DHCP的桌面环境中，可以将地址重新分配给不同的个人。在这种情况下，这一要求所提供的个人责任是薄弱的。日志中有准确的时间会增加地址的使用与个人相关的机会。
* Network topologies may change. Even in the absence of dynamic address assignment, network topologies and address block assignments do change. Logs of an attack one month ago may not give an accurate indication of which host, network or organization owned the system(s) in question at the time.
* 网络拓扑可能会改变。即使在没有动态地址分配的情况下，网络拓扑和地址块分配也会发生变化。一个月前的攻击日志可能无法准确显示当时哪个主机、网络或组织拥有该系统。
Requirement.
要求
The device MUST be able to send a record of at least the following events:
设备必须能够发送至少以下事件的记录：
* authentication successes,
* 认证成功，
* authentication failures,
* 身份验证失败，
* session Termination,
* 会话终止，
* authorization changes,
* 授权变更，
* configuration changes,
* 配置更改，
* device status changes.
* 设备状态更改。
The device SHOULD be able to send a record of all other security related events.
设备应能够发送所有其他安全相关事件的记录。
Justification.
正当理由
This is important because it supports individual accountability. See section 4.5.4.4 of [RFC2196].
这很重要，因为它支持个人问责制。见[RFC2196]第4.5.4.4节。
Examples.
例子。
Examples of events for which there must be a record include: user logins, bad login attempts, logouts, user privilege level changes, individual configuration commands issued by users and system startup/shutdown events.
必须有记录的事件示例包括：用户登录、错误登录尝试、注销、用户权限级别更改、用户发出的单个配置命令以及系统启动/关闭事件。
Warnings.
警告。
This list is far from complete.
这份清单还远远不够完整。
Note that there may be privacy or legal considerations when logging/monitoring user activity.
请注意，在记录/监视用户活动时，可能会考虑隐私或法律问题。
Requirement.
要求
Passwords SHOULD be excluded from all audit records, including records of successful or failed authentication attempts.
应将密码从所有审核记录中排除，包括验证尝试成功或失败的记录。
Justification.
正当理由
Access control and authorization requirements differ for accounting records (logs) and authorization databases (passwords). Logging passwords may grant unauthorized access to individuals with access to the logs. Logging failed passwords may give hints about actual passwords. See section 4.5.4.4 of [RFC2196].
会计记录（日志）和授权数据库（密码）的访问控制和授权要求不同。记录密码可能会授予有权访问日志的个人未经授权的访问权限。记录失败的密码可能会提示实际密码。见[RFC2196]第4.5.4.4节。
Examples.
例子。
A user may make small mistakes in entering a password such as using incorrect capitalization ("my password" vs. "My Password").
用户在输入密码时可能会犯一些小错误，例如使用不正确的大写字母（“我的密码”与“我的密码”）。
Warnings.
警告。
There may be situations where it is appropriate/required to log passwords.
在某些情况下，可能需要记录密码。
Requirement.
要求
The device MUST provide a facility to perform authentication of all user access to the system.
该设备必须提供一种设施，用于对系统的所有用户访问进行身份验证。
Justification.
正当理由
This functionality is required so that access to the system can be restricted to authorized personnel.
此功能是必需的，这样才能限制授权人员访问系统。
Examples.
例子。
This requirement MAY be satisfied by implementing a centralized authentication system. See Section 2.12.5. It MAY also be satisfied using local authentication. See Section 2.12.6.
可通过实施集中认证系统来满足此要求。见第2.12.5节。使用本地身份验证也可以满足这一要求。见第2.12.6节。
Warnings.
警告。
None.
没有一个
Requirement.
要求
Mechanisms used to authenticate interactive access for configuration and management MUST support the authentication of distinct, individual users. This requirement MAY be relaxed to support system installation Section 2.4.5 or recovery of authorized access Section 2.12.15.
用于对配置和管理的交互访问进行身份验证的机制必须支持对不同的单个用户进行身份验证。可放宽该要求，以支持第2.4.5节的系统安装或第2.12.15节的授权访问恢复。
Justification.
正当理由
The use of individual accounts, in conjunction with logging, promotes accountability. The use of group or default accounts undermines individual accountability.
个人账户的使用，结合日志记录，促进了问责制。使用集团或默认账户会破坏个人责任。
Examples.
例子。
A user may need to log in to the device to access CLI functions for management. Individual user authentication could be provided by a centralized authentication server or a username/password database stored on the device. It would be a violation of this rule for the device to only support a single "account" (with or without a username) and a single password shared by all users to gain administrative access.
用户可能需要登录到设备才能访问CLI功能进行管理。个人用户身份验证可以由集中身份验证服务器或存储在设备上的用户名/密码数据库提供。如果设备仅支持一个“帐户”（有或没有用户名）和一个由所有用户共享的密码以获得管理访问权限，则违反了此规则。
Warnings.
警告。
This simply requires that the mechanism to support individual users be present. Policy (e.g., forbidding shared group accounts) and enforcement are also needed but beyond the scope of this document.
这只需要存在支持单个用户的机制。政策（例如，禁止共享集团账户）和强制执行也是必要的，但超出了本文件的范围。
Requirement.
要求
The device MUST support multiple simultaneous connections by distinct users, possibly at different authorization levels.
设备必须支持不同用户同时进行的多个连接，可能具有不同的授权级别。
Justification.
正当理由
This allows multiple people to perform authorized management functions simultaneously. This also means that attempted connections by unauthorized users do not automatically lock out authorized users.
这允许多人同时执行授权管理功能。这也意味着未经授权的用户尝试的连接不会自动锁定授权用户。
Examples.
例子。
None.
没有一个
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST provide a means of disabling all local accounts including:
设备必须提供禁用所有本地帐户的方法，包括：
* local users,
* 本地用户，
* default accounts (vendor, maintenance, guest, etc.),
* 默认帐户（供应商、维护、来宾等），
* privileged and unprivileged accounts.
* 特权帐户和非特权帐户。
A local account defined as one where all information necessary for user authentication is stored on the device.
一种本地帐户，定义为将用户身份验证所需的所有信息存储在设备上的帐户。
Justification.
正当理由
Default accounts, well-known accounts, and old accounts provide easy targets for someone attempting to gain access to a device. It must be possible to disable them to reduce the potential vulnerability.
默认帐户、知名帐户和旧帐户为试图访问设备的用户提供了简单的目标。必须能够禁用它们以减少潜在的漏洞。
Examples.
例子。
The implementation depends on the types of authentication supported by the device.
实现取决于设备支持的身份验证类型。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST support a method of centralized authentication of all user access via standard authentication protocols.
设备必须支持通过标准身份验证协议对所有用户访问进行集中身份验证的方法。
Justification.
正当理由
Support for centralized authentication is particularly important in large environments where the network devices are widely distributed and where many people have access to them. This reduces the effort needed to effectively restrict and track access to the system by authorized personnel.
在网络设备分布广泛且许多人都可以访问的大型环境中，对集中身份验证的支持尤为重要。这减少了有效限制和跟踪授权人员访问系统所需的工作。
Examples.
例子。
This requirement can be satisfied through the use of DIAMETER [RFC3588], TACACS+ [RFC1492], RADIUS [RFC2865], or Kerberos [RFC1510].
可通过使用直径[RFC3588]、TACACS+[RFC1492]、半径[RFC2865]或Kerberos[RFC1510]来满足此要求。
The secure management requirements (Section 2.1.1) apply to AAA.
安全管理要求（第2.1.1节）适用于AAA。
See [RFC3579] for a discussion security issues related to RADIUS.
有关RADIUS相关安全问题的讨论，请参阅[RFC3579]。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device SHOULD support a local authentication method. If implemented, the method MUST NOT require interaction with anything external to the device (such as remote AAA servers), and MUST work in conjunction with Section 2.3.1 (Support a 'Console' Interface) and Section 2.12.7 (Support Configuration of Order of Authentication Methods).
设备应支持本地身份验证方法。如果实施，该方法不得要求与设备外部的任何东西（如远程AAA服务器）进行交互，并且必须与第2.3.1节（支持“控制台”接口）和第2.12.7节（支持身份验证方法顺序的配置）结合使用。
Justification.
正当理由
Support for local authentication may be required in smaller environments where there may be only a few devices and a limited number of people with access. The overhead of maintaining centralized authentication servers may not be justified.
在较小的环境中，可能需要支持本地身份验证，因为只有少数设备和有限的人可以访问。维护集中身份验证服务器的开销可能是不合理的。
Examples.
例子。
The use of local, per-device usernames and passwords provides one way to implement this requirement.
使用本地、每设备用户名和密码提供了实现此要求的一种方法。
Warnings.
警告。
Authentication information must be protected wherever it resides. Having, for instance, local usernames and passwords stored on 100 network devices means that there are 100 potential points of failure where the information could be compromised vs. storing authentication data centralized server(s), which would reduce the potential points of failure to the number of servers and allow protection efforts (system hardening, audits, etc.) to be focused on, at most, a few servers.
无论身份验证信息驻留在何处，都必须对其进行保护。例如，将本地用户名和密码存储在100台网络设备上意味着存在100个潜在故障点，信息可能会受到损害，而将身份验证数据存储在集中式服务器上，这将减少服务器数量的潜在故障点，并允许采取保护措施（系统强化、审核等）最多集中在几个服务器上。
Requirement.
要求
The device MUST support the ability to configure the order in which supported authentication methods are attempted. Authentication SHOULD "fail closed", i.e., access should be denied if none of the listed authentication methods succeeds.
设备必须支持配置尝试支持的身份验证方法的顺序的功能。身份验证应“失败关闭”，即，如果所列身份验证方法均未成功，则应拒绝访问。
Justification.
正当理由
This allows the operator flexibility in implementing appropriate security policies that balance operational and security needs.
这使得运营商能够灵活地实施适当的安全策略，以平衡运营和安全需求。
Examples.
例子。
If, for example, a device supports RADIUS authentication and local usernames and passwords, it should be possible to specify that RADIUS authentication should be attempted if the servers are available, and that local usernames and passwords should be used for authentication only if the RADIUS servers are not available. Similarly, it should be possible to specify that only RADIUS or only local authentication be used.
例如，如果设备支持RADIUS身份验证以及本地用户名和密码，则可以指定如果服务器可用，则应尝试RADIUS身份验证，并且只有当RADIUS服务器不可用时，才应使用本地用户名和密码进行身份验证。类似地，应该可以指定仅使用RADIUS或仅使用本地身份验证。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST support mechanisms that do not require the transmission of plaintext passwords in all cases that require the transmission of authentication information across networks.
在所有需要跨网络传输身份验证信息的情况下，设备必须支持不需要传输明文密码的机制。
Justification.
正当理由
Plaintext passwords can be easily observed using packet sniffers on shared networks. See [RFC1704] and [RFC3631] for a through discussion.
在共享网络上使用数据包嗅探器可以很容易地观察到明文密码。有关详细讨论，请参见[RFC1704]和[RFC3631]。
Examples.
例子。
Remote login requires the transmission of authentication information across networks. Telnet transmits plaintext passwords. SSH does not. Telnet fails this requirement. SSH passes.
远程登录需要跨网络传输身份验证信息。Telnet传输明文密码。SSH没有。Telnet无法满足这一要求。SSH通过了。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The initial configuration of the device MUST NOT contain any default passwords or other authentication tokens.
设备的初始配置不得包含任何默认密码或其他身份验证令牌。
Justification.
正当理由
Default passwords provide an easy way for attackers to gain unauthorized access to the device.
默认密码为攻击者获得对设备的未经授权访问提供了一种简便方法。
Examples.
例子。
Passwords such as the name of the vendor, device, "default", etc. are easily guessed. The SNMP community strings "public" and "private" are well known defaults that provide read and write access to devices.
诸如供应商名称、设备、“默认值”等密码很容易猜到。SNMP团体字符串“public”和“private”是众所周知的默认值，提供对设备的读写访问。
Warnings.
警告。
Lists of default passwords for various devices are readily available at numerous websites.
各种设备的默认密码列表在许多网站上都可以找到。
Requirement.
要求
The device MUST require the operator to explicitly configure "passwords" prior to use.
设备必须要求操作员在使用前明确配置“密码”。
Justification.
正当理由
This requirement is intended to prevent unauthorized management access. Requiring the operator to explicitly configure passwords will tend to have the effect of ensuring a diversity of passwords. It also shifts the responsibility for password selection to the user.
此要求旨在防止未经授权的管理访问。要求操作员明确配置密码往往会产生确保密码多样性的效果。它还将密码选择的责任转移给用户。
Examples.
例子。
Assume that a device comes with console port for management and a default administrative account. This requirement together with No Default Passwords says that the administrative account should come with no password configured. One way of meeting this requirement would be to have the device require the operator to choose a password for the administrative account as part of a dialog the first time the device is configured.
假设设备带有用于管理的控制台端口和默认管理帐户。这个要求加上没有默认密码，说明管理帐户应该没有配置密码。满足此要求的一种方法是让设备要求操作员在第一次配置设备时在对话框中为管理帐户选择密码。
Warnings.
警告。
While this device requires operators to set passwords, it does not prevent them from doing things such as using scripts to configure hundreds of devices with the same easily guessed passwords.
虽然此设备要求操作员设置密码，但它并不阻止操作员使用脚本等方式使用相同的容易猜到的密码配置数百台设备。
Requirement.
要求
It MUST be possible to define arbitrary subsets of all management and configuration functions and assign them to groups or "privilege levels", which can be assigned to users per Section 2.12.12. There MUST be at least three possible privilege levels.
必须能够定义所有管理和配置功能的任意子集，并将其分配给组或“特权级别”，可根据第2.12.12节分配给用户。必须至少有三个可能的权限级别。
Justification.
正当理由
This requirement supports the implementation of the principal of "least privilege", which states that an individual should only have the privileges necessary to execute the operations he/she is required to perform.
这一要求支持实现“最低特权”原则，即个人只应拥有执行他/她需要执行的操作所需的特权。
Examples.
例子。
Examples of privilege levels might include "user" which only allows the initiation of a PPP or telnet session, "read only", which allows read-only access to device configuration and operational statistics, "root/superuser/administrator" which allows update access to all configurable parameters, and "operator" which allows updates to a limited, user defined set of
特权级别的示例可能包括“用户”，仅允许启动PPP或telnet会话，“只读”，允许对设备配置和操作统计数据进行只读访问，“root/superuser/administrator”，允许对所有可配置参数进行更新访问，以及“操作员”，允许对有限的，用户定义的一组
parameters. Note that privilege levels may be defined locally on the device or on centralized authentication servers.
参数。请注意，可以在设备或集中式身份验证服务器上本地定义权限级别。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST be able to assign a defined set of authorized functions, or "privilege level", to each user once they have authenticated themselves to the device. Privilege level determines which functions a user is allowed to execute. Also see Section 2.12.11.
一旦每个用户向设备进行了身份验证，设备必须能够将一组定义的授权功能或“特权级别”分配给每个用户。特权级别决定允许用户执行哪些功能。另见第2.12.11节。
Justification.
正当理由
This requirement supports the implementation of the principal of "least privilege", which states that an individual should only have the privileges necessary to execute the operations he/she is required to perform.
这一要求支持实现“最低特权”原则，即个人只应拥有执行他/她需要执行的操作所需的特权。
Examples.
例子。
The implementation of this requirement will obviously be closely coupled with the authentication mechanism. If RADIUS is used, an attribute could be set in the user's RADIUS profile that can be used to map the ID to a certain privilege level.
这一要求的实现显然将与身份验证机制紧密结合。如果使用RADIUS，则可以在用户的RADIUS配置文件中设置一个属性，该属性可用于将ID映射到某个特权级别。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The default privilege level SHOULD NOT allow any access to management or configuration functions. It MAY allow access to user-level functions (e.g., starting PPP or telnet). It SHOULD be possible to assign a different privilege level as the default. This requirement MAY be relaxed to support system installation per Section 2.4.5 or recovery of authorized access per Section 2.12.15.
默认权限级别不应允许对管理或配置功能进行任何访问。它可能允许访问用户级功能（例如，启动PPP或telnet）。应该可以指定不同的权限级别作为默认权限级别。可放宽该要求，以支持第2.4.5节规定的系统安装或第2.12.15节规定的授权访问恢复。
Justification.
正当理由
This requirement supports the implementation of the principal of "least privilege", which states that an individual should only have the privileges necessary to execute the operations he/she is required to perform.
这一要求支持实现“最低特权”原则，即个人只应拥有执行他/她需要执行的操作所需的特权。
Examples.
例子。
Examples of privilege levels might include "user" which only allows the initiation of a PPP or telnet session, "read-only", which allows read-only access to device configuration and operational statistics, "root/superuser/administrator" which allows update access to all configurable parameters, and "operator" which allows updates to a limited, user defined set of parameters. Note that privilege levels may be defined locally on the device or on centralized authentication servers.
特权级别的示例可能包括“用户”，仅允许启动PPP或telnet会话，“只读”，允许对设备配置和操作统计数据进行只读访问，“root/superuser/administrator”，允许对所有可配置参数进行更新访问，以及“操作员”，允许对有限的，用户定义的参数集。请注意，可以在设备或集中式身份验证服务器上本地定义权限级别。
Warnings.
警告。
It may be required to provide exceptions to support the requirements to support recovery of privileged access (Section 2.12.15) and to support OS installation and configuration (Section 2.4.5). For example, if the OS and/or configuration has somehow become corrupt an authorized individual with physical access may need to have "root" level access to perform an install.
可能需要提供例外情况，以支持恢复特权访问（第2.12.15节）和支持操作系统安装和配置（第2.4.5节）的要求。例如，如果操作系统和/或配置已损坏，则具有物理访问权限的授权个人可能需要具有“根”级访问权限才能执行安装。
Requirement.
要求
The device MUST re-authenticate a user prior to granting any change in user authorizations.
在授予用户授权的任何更改之前，设备必须重新验证用户。
Justification.
正当理由
This requirement ensures that users are able to perform only authorized actions.
此要求确保用户只能执行授权的操作。
Examples.
例子。
This requirement might be implemented by assigning base privilege levels to all users and allowing the user to request additional privileges, with the requests validated by the AAA server.
此要求可以通过为所有用户分配基本权限级别并允许用户请求附加权限来实现，请求由AAA服务器验证。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The device MUST support a mechanism to allow authorized individuals to recover full privileged administrative access in the event that access is lost. Use of the mechanism MUST require physical access to the device. There MAY be a mechanism for disabling the recovery feature.
设备必须支持一种机制，允许授权人员在访问丢失时恢复完全特权管理访问。使用该机制必须需要对设备进行物理访问。可能存在禁用恢复功能的机制。
Justification.
正当理由
There are times when local administrative passwords are forgotten, when the only person who knows them leaves the company, or when hackers set or change the password. In all these cases, legitimate administrative access to the device is lost. There should be a way to recover access. Requiring physical access to invoke the procedure makes it less likely that it will be abused. Some organizations may want an even higher level of security and be willing to risk total loss of authorized access by disabling the recovery feature, even for those with physical access.
有时，本地管理密码被遗忘，只有知道密码的人离开公司，或者黑客设置或更改密码。在所有这些情况下，对设备的合法管理访问都会丢失。应该有一种恢复访问的方法。需要物理访问才能调用该过程，这样就不太可能滥用该过程。有些组织可能希望获得更高级别的安全性，并愿意通过禁用恢复功能来冒完全失去授权访问的风险，即使对于那些具有物理访问权限的组织也是如此。
Examples.
例子。
Some examples of ways to satisfy this requirement are to have the device give the user the chance to set a new administrative password when:
满足此要求的一些方法示例是，在以下情况下，让设备为用户提供设置新管理密码的机会：
* The user sets a jumper on the system board to a particular position.
* 用户将系统板上的跳线设置到特定位置。
* The user sends a special sequence to the RS232 console port during the initial boot sequence.
* 在初始引导序列期间，用户向RS232控制台端口发送特殊序列。
* The user sets a "boot register" to a particular value.
* 用户将“引导寄存器”设置为特定值。
Warnings.
警告。
This mechanism, by design, provides a "back door" to complete administrative control of the device and may not be appropriate for environments where those with physical access to the device can not be trusted.
这种机制在设计上提供了一个“后门”来完成对设备的管理控制，并且可能不适合那些无法信任对设备进行物理访问的环境。
Also see the warnings in Section 2.3.1 (Support a 'Console' Interface).
另请参见第2.3.1节中的警告（支持“控制台”界面）。
Requirement.
要求
If a device provides layer 2 services that are dependent on layer 3 or greater services, then the portions that operate at or above layer 3 MUST conform to the requirements listed in this document.
如果设备提供依赖于第3层或更高层服务的第2层服务，则在第3层或以上运行的部分必须符合本文件中列出的要求。
Justification.
正当理由
All layer 3 devices have similar security needs and should be subject to similar requirements.
所有第3层设备都有类似的安全需求，并应遵守类似的要求。
Examples.
例子。
Signaling protocols required for layer 2 switching may exchange information with other devices using layer 3 communications. In such cases, the device must provide a secure layer 3 facility. Also, if higher layer capabilities (say, SSH or SNMP) are used to manage a layer 2 device, then the rest of the requirements in this document apply to those capabilities.
第2层交换所需的信令协议可以使用第3层通信与其他设备交换信息。在这种情况下，设备必须提供安全的第3层设施。此外，如果使用更高层的功能（如SSH或SNMP）来管理第2层设备，则本文档中的其余要求适用于这些功能。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The use of security features specified by the requirements in this document SHOULD NOT cause severe operational problems.
使用本文件要求规定的安全功能不应导致严重的操作问题。
Justification.
正当理由
Security features which cause operational problems are not useful and may leave the operator with no mechanism for enforcing appropriate policy.
导致操作问题的安全功能是无用的，并且可能使操作员没有执行适当策略的机制。
Examples.
例子。
Some examples of severe operational problems include:
严重操作问题的一些示例包括：
* The device crashes.
* 设备崩溃了。
* The device becomes unmanageable.
* 设备变得无法管理。
* Data is lost.
* 数据丢失。
* Use of the security feature consumes excessive resources (CPU, memory, bandwidth).
* 使用安全功能会消耗过多的资源（CPU、内存、带宽）。
Warnings.
警告。
Determination of compliance with this requirement involves a level of judgement. What is "severe"? Certainly crashing is severe, but what about a %5 loss in throughput when logging is enabled? It should also be noted that there may be unavoidable physical limitations such as the total capacity of a link.
确定是否符合该要求需要一定程度的判断。什么是“严重”？当然，崩溃是严重的，但是启用日志记录时，吞吐量会损失%5吗？还应注意，可能存在不可避免的物理限制，例如链路的总容量。
Requirement.
要求
Security features specified by the requirements in this document SHOULD be implemented with minimal impact on performance. Other sections of this document may specify different performance requirements (e.g., "MUST"s).
应在对性能影响最小的情况下实施本文档中要求规定的安全功能。本文件的其他章节可能会规定不同的性能要求（例如，“必须”。
Justification.
正当理由
Security features which significantly impact performance may leave the operator with no mechanism for enforcing appropriate policy.
严重影响性能的安全功能可能会使操作员无法执行适当的策略。
Examples.
例子。
If the application of filters is known to have the potential to significantly reduce throughput for non-filtered traffic, there will be a tendency, or in some cases a policy, not to use filters.
如果已知过滤器的应用有可能显著降低非过滤流量的吞吐量，则将有一种趋势，或在某些情况下有一种政策，即不使用过滤器。
Assume, for example, that a new worm is released that scans random IP addresses looking for services listening on TCP port 1433. An operator might want to investigate to see if any of the hosts on their networks were infected and trying to spread the worm. One way to do this would be to put up non-blocking filters counting and logging the number of outbound connection 1433, and then to block the requests that are determined to be from infected hosts. If any of these capabilities (filtering, counting, logging) have the potential to impose severe performance penalties, then this otherwise rational course of action might not be possible.
例如，假设发布了一个新的蠕虫，该蠕虫扫描随机IP地址，寻找TCP端口1433上侦听的服务。运营商可能希望调查其网络上是否有任何主机受到感染并试图传播蠕虫。一种方法是设置非阻塞过滤器，对出站连接1433的数量进行计数和记录，然后阻塞确定来自受感染主机的请求。如果这些功能（过滤、计数、日志记录）中的任何一项都有可能造成严重的性能损失，那么这种合理的做法可能是不可能的。
Warnings.
警告。
Requirements for which performance is a particular concern include: filtering, rate-limiting, counters, logging and anti-spoofing.
特别关注性能的要求包括：过滤、速率限制、计数器、日志记录和防欺骗。
The requirements in this section are intended to list information that will assist operators in evaluating and securely operating a device.
本节中的要求旨在列出有助于操作员评估和安全操作设备的信息。
Requirement.
要求
The vendor MUST provide a list of all services that may be active on the device. The list MUST identify the protocols and default ports (if applicable) on which the services listen. It SHOULD provide references to complete documentation describing the service.
供应商必须提供设备上可能活动的所有服务的列表。该列表必须标识服务侦听的协议和默认端口（如果适用）。它应该提供描述服务的完整文档的参考。
Justification.
正当理由
This information is necessary to enable a thorough assessment of the potential security risks associated with the operation of each service.
这些信息对于全面评估与每项服务的运行相关的潜在安全风险是必要的。
Examples.
例子。
The list will likely contain network and transport protocols such as IP, ICMP, TCP, UDP, routing protocols such as BGP and OSPF, application protocols such as SSH and SNMP along with references to the RFCs or other documentation describing the versions of the protocols implemented.
该列表可能包含网络和传输协议（如IP、ICMP、TCP、UDP）、路由协议（如BGP和OSPF）、应用程序协议（如SSH和SNMP）以及对RFC的参考或描述所实施协议版本的其他文档。
Web servers "usually" listen on port 80. In the default configuration of the device, it may have a web server listening on port 8080. In the context of this requirement "identify ... default port" would mean "port 8080".
Web服务器“通常”在端口80上侦听。在设备的默认配置中，它可能有一个web服务器监听端口8080。在本要求的上下文中，“标识…默认端口”将表示“端口8080”。
Warnings.
警告。
There may be valid, non-technical reasons for not disclosing the specifications of proprietary protocols. In such cases, all that needs to be disclosed is the existence of the service and the default ports (if applicable).
不披露专有协议规范可能存在有效的非技术原因。在这种情况下，需要公开的只是服务和默认端口（如果适用）的存在。
Requirement.
要求
The vendor MUST provide a list of the default state of all services.
供应商必须提供所有服务的默认状态列表。
Justification.
正当理由
Understanding risk requires understanding exposure. Each service that is enabled presents a certain level of exposure. Having a list of the services that is enabled by default makes it possible to perform meaningful risk analysis.
了解风险需要了解风险敞口。启用的每个服务都会呈现一定程度的暴露。拥有默认启用的服务列表可以执行有意义的风险分析。
Examples.
例子。
The list may be no more than the output of a command that implements Section 2.5.1.
该列表只能是执行第2.5.1节的命令的输出。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The vendor MUST concisely document which features enable and disable services.
供应商必须简洁地记录哪些功能启用和禁用服务。
Justification.
正当理由
Once risk has been assessed, this list provides the operator a quick means of understanding how to disable (or enable) undesired (or desired) services.
一旦对风险进行了评估，该列表为操作员提供了一种快速的方法，以了解如何禁用（或启用）不需要的（或期望的）服务。
Examples.
例子。
This may be a list of commands to enable/disable services one by one or a single command which enables/disables "standard" groups of commands.
这可以是逐个启用/禁用服务的命令列表，也可以是启用/禁用“标准”命令组的单个命令。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The vendor MUST provide complete documentation of the command line interface with each software release. The documentation SHOULD include highlights of changes from previous versions. The documentation SHOULD list potential output for each command.
供应商必须随每个软件版本提供命令行界面的完整文档。文档应包括以前版本的更改要点。文档应列出每个命令的潜在输出。
Justification.
正当理由
Understanding of inputs and outputs is necessary to support scripting. See Section 2.4.2.
理解输入和输出是支持脚本编写所必需的。见第2.4.2节。
Examples.
例子。
Separate documentation should be provided for each command listing the syntax, parameters, options, etc. as well as expected output (status, tables, etc.).
应为每个命令提供单独的文档，列出语法、参数、选项等以及预期输出（状态、表格等）。
Warnings.
警告。
None.
没有一个
Requirement.
要求
The console default profile of communications parameters MUST be published in the system documentation.
必须在系统文档中发布通信参数的控制台默认配置文件。
Justification.
正当理由
Publication in the system documentation makes the settings accessible. Failure to publish them could leave the operator having to guess.
通过在系统文档中发布，可以访问设置。如果发布失败，运营商可能不得不猜测。
Examples.
例子。
None.
没有一个
Warnings.
警告。
None.
没有一个
The requirements in this section are intended to
本节中的要求旨在
o identify behaviors and information that will increase confidence that the device will meet the security functional requirements.
o 识别可增强设备满足安全功能要求信心的行为和信息。
o Provide information that will assist in the performance of security evaluations.
o 提供有助于执行安全评估的信息。
Requirement.
要求
The vendor SHOULD disclose the origin or basis of the IP stack used on the system.
供应商应披露系统上使用的IP堆栈的来源或基础。
Justification.
正当理由
This information is required to better understand the possible security vulnerabilities that may be inherent in the IP stack.
需要这些信息才能更好地了解IP堆栈中可能存在的安全漏洞。
Examples.
例子。
"The IP stack was derived from BSD 4.4", or "The IP stack was implemented from scratch."
“IP堆栈源自BSD 4.4”，或“IP堆栈是从头开始实现的”
Warnings.
警告。
Many IP stacks make simplifying assumptions about how an IP packet should be formed. A malformed packet can cause unexpected behavior in the device, such as a system crash or buffer overflow which could result in unauthorized access to the system.
许多IP协议栈简化了IP数据包应该如何形成的假设。格式错误的数据包可能会导致设备出现意外行为，例如系统崩溃或缓冲区溢出，从而导致未经授权的系统访问。
Requirement.
要求
The vendor SHOULD disclose the origin or basis of the operating system (OS).
供应商应披露操作系统（OS）的来源或基础。
Justification.
正当理由
This information is required to better understand the security vulnerabilities that may be inherent to the OS based on its origin.
需要这些信息，以便更好地了解基于其来源的操作系统固有的安全漏洞。
Examples.
例子。
"The operating system is based on Linux kernel 2.4.18."
“操作系统基于Linux内核2.4.18。”
Warnings.
警告。
None.
没有一个
General
全体的
Security is the subject matter of this entire memo. The justification section of each individual requirement lists the security implications of meeting or not meeting the requirement.
安全是整个备忘录的主题。每个单独要求的理由部分列出了满足或不满足要求的安全影响。
SNMP
SNMP
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in the MIB.
SNMPv3之前的SNMP版本未包含足够的安全性。即使网络本身是安全的（例如通过使用IPSec），即使如此，也无法控制安全网络上的谁可以访问和获取/设置（读取/更改/创建/删除）MIB中的对象。
It is recommended that implementors consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy).
建议执行者考虑SNMPv3框架所提供的安全特性（参见[RCFC310]，第8节），包括对SNMPv3加密机制的完全支持（用于身份验证和隐私）。
Furthermore, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to MIB objects is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
此外，不建议部署SNMPv3之前的SNMP版本。相反，建议部署SNMPv3并启用加密安全性。然后，客户/运营商有责任确保对授予MIB对象访问权限的SNMP实体进行了正确配置，以便仅向那些拥有确实获取或设置（更改/创建/删除）对象的合法权限的主体（用户）授予对象访问权限。
[ANSI.X9-52.1998] American National Standards Institute, "Triple Data Encryption Algorithm Modes of Operation", ANSI X9.52, 1998.
[ANSI.X9-52.1998]美国国家标准协会，“三重数据加密算法操作模式”，ANSI X9.521998。
[FIPS.197] National Institute of Standards and Technology, "Advanced Encryption Standard", FIPS PUB 197, November 2001, <http://csrc.nist.gov/publications/fips/fips197/ fips-197.ps>.
[FIPS.197]国家标准与技术研究所，“高级加密标准”，FIPS PUB 197，2001年11月<http://csrc.nist.gov/publications/fips/fips197/ fips-197.ps>。
[PKCS.3.1993] RSA Laboratories, "Diffie-Hellman Key-Agreement Standard, Version 1.4", PKCS 3, November 1993.
[PKCS.3.1993]RSA实验室，“Diffie-Hellman密钥协议标准，1.4版”，PKCS 3，1993年11月。
[RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms", RFC 1208, March 1991.
[RFC1208]Jacobsen，O.和D.Lynch，“网络术语表”，RFC1208，1991年3月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]Rivest，R.，“MD5消息摘要算法”，RFC13211992年4月。
[RFC1492] Finseth, C., "An Access Control Protocol, Sometimes Called TACACS", RFC 1492, July 1993.
[RFC1492]Finseth，C.，“访问控制协议，有时称为TACACS”，RFC 1492，1993年7月。
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network Authentication Service (V5)", RFC 1510, September 1993.
[RFC1510]Kohl，J.和C.Neuman，“Kerberos网络身份验证服务（V5）”，RFC15101993年9月。
[RFC1704] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[RFC1704]Haller，N.和R.Atkinson，“互联网认证”，RFC17041994年10月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，Ed.，“IP版本4路由器的要求”，RFC 1812，1995年6月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.
[RFC2196]弗雷泽，B.，《现场安全手册》，第8期，RFC 2196，1997年9月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385]Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC2631]Rescorla，E.，“Diffie-Hellman密钥协商方法”，RFC 26311999年6月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865]Rigney，C.，Willens，S.，Rubens，A.，和W.Simpson，“远程认证拨入用户服务（RADIUS）”，RFC 28652000年6月。
[RFC3013] Killalea, T., "Recommended Internet Service Provider Security Services and Procedures", BCP 46, RFC 3013, November 2000.
[RFC3013]Killalea，T.，“推荐的互联网服务提供商安全服务和程序”，BCP 46，RFC 3013，2000年11月。
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
[RFC3164]Lonvick，C.，“BSD系统日志协议”，RFC31642001年8月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]Eastlake，D.和P.Jones，“美国安全哈希算法1（SHA1）”，RFC 3174，2001年9月。
[RFC3195] New, D. and M. Rose, "Reliable Delivery for syslog", RFC 3195, November 2001.
[RFC3195]New，D.和M.Rose，“系统日志的可靠交付”，RFC 31952001年11月。
[RFC3309] Stone, J., Stewart, R. and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[RFC3309]Stone，J.，Stewart，R.和D.Otis，“流控制传输协议（SCTP）校验和更改”，RFC 33092002年9月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330]IANA，“特殊用途IPv4地址”，RFC33302002年9月。
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002.
[RFC3360]Floyd，S.，“不适当的TCP重置被认为是有害的”，BCP 60，RFC 3360，2002年8月。
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]Case，J.，Mundy，R.，Partain，D.和B.Stewart，“互联网标准管理框架的介绍和适用性声明”，RFC 34102002年12月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]Harrington，D.，Presohn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
[RFC3562]Leech，M.，“TCP MD5签名选项的密钥管理注意事项”，RFC 3562，2003年7月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579]Aboba，B.和P.Calhoun，“RADIUS（远程认证拨入用户服务）对可扩展认证协议（EAP）的支持”，RFC 3579，2003年9月。
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC3588]Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, Eds., "Security Mechanisms for the Internet", RFC 3631, December 2003.
[RFC3631]Bellovin，S.，Schiller，J.，和C.Kaufman编辑，“互联网的安全机制”，RFC 36312003年12月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[bmwg-acc-bench] Poretsky, S., "Framework for Accelerated Stress Benchmarking", Work in Progress, October 2003.
[bmwg acc bench]Poretsky，S.，“加速压力基准测试框架”，进展中的工作，2003年10月。
[Schneier] Schneier, B., "Applied Cryptography, 2nd Ed., Publisher John Wiley & Sons, Inc.", 1996.
[Schneier]Schneier，B.，“应用密码学，第二版，出版商约翰·威利父子公司”，1996年。
This Appendix lists different profiles. A profile is a list of list of requirements that apply to a particular class of devices. The minimum requirements profile applies to all devices.
本附录列出了不同的配置文件。配置文件是适用于特定类别设备的需求列表。最低要求配置文件适用于所有设备。
The functionality listed here represents a minimum set of requirements to which managed infrastructure of large IP networks should adhere.
此处列出的功能代表了大型IP网络的托管基础设施应遵守的最低要求集。
The minimal requirements profile addresses functionality which will provide reasonable capabilities to manage the devices in the event of attacks, simplify troubleshooting, keep track of events which affect system integrity, help analyze causes of attacks, as well as provide administrators control over IP addresses and protocols to help mitigate the most common attacks and exploits.
最低要求概要介绍了在发生攻击时提供合理功能来管理设备、简化故障排除、跟踪影响系统完整性的事件、帮助分析攻击原因、，并为管理员提供对IP地址和协议的控制，以帮助减轻最常见的攻击和漏洞利用。
o Support Secure Channels For Management
o 支持安全的管理通道
o Use Protocols Subject To Open Review For Management
o 使用经公开审查的协议进行管理
o Use Cryptographic Algorithms Subject To Open Review
o 使用公开审查的加密算法
o Use Strong Cryptography
o 使用强加密
o Allow Selection of Cryptographic Parameters
o 允许选择加密参数
o Management Functions Should Have Increased Priority
o 管理职能应具有更高的优先性
o Support a 'Console' Interface
o 支持“控制台”界面
o 'Console' Communication Profile Must Support Reset
o “控制台”通信配置文件必须支持重置
o 'Console' Default Communication Profile Documented
o 记录“控制台”默认通信配置文件
o 'Console' Requires Minimal Functionality of Attached Devices.
o “控制台”需要连接设备的最小功能。
o Support Separate Management Plane IP Interfaces
o 支持独立的管理平面IP接口
o No Forwarding Between Management Plane And Other Interfaces
o 管理平面与其他接口之间无转发
o 'CLI' Provides Access to All Configuration and Management Functions
o “CLI”提供对所有配置和管理功能的访问
o 'CLI' Supports Scripting of Configuration
o “CLI”支持配置脚本
o 'CLI' Supports Management Over 'Slow' Links
o “CLI”支持通过“慢速”链接进行管理
o Document Command Line Interface
o 文档命令行界面
o Support Software Installation
o 支持软件安装
o Support Remote Configuration Backup
o 支持远程配置备份
o Support Remote Configuration Restore
o 支持远程配置还原
o Support Text Configuration Files
o 支持文本配置文件
o Ability to Identify All Listening Services
o 识别所有收听服务的能力
o Ability to Disable Any and All Services
o 能够禁用任何和所有服务
o Ability to Control Service Bindings for Listening Services
o 能够控制侦听服务的服务绑定
o Ability to Control Service Source Addresses
o 控制服务源地址的能力
o Ability to Filter Traffic
o 过滤流量的能力
o Ability to Filter Traffic TO the Device
o 能够过滤到设备的流量
o Support Route Filtering
o 支持路由过滤
o Ability to Specify Filter Actions
o 能够指定筛选器操作
o Ability to Log Filter Actions
o 能够记录过滤器操作
o Ability to Filter Without Significant Performance Degradation
o 能够在不显著降低性能的情况下进行过滤
o Ability to Specify Filter Log Granularity
o 能够指定筛选器日志粒度
o Ability to Filter on Protocols
o 根据协议进行过滤的能力
o Ability to Filter on Addresses
o 过滤地址的能力
o Ability to Filter on Protocol Header Fields
o 能够过滤协议头字段
o Ability to Filter Inbound and Outbound
o 能够筛选入站和出站
o Packet Filtering Counter Requirements
o 包过滤计数器要求
o Ability to Display Filter Counters
o 能够显示过滤器计数器
o Ability to Display Filter Counters per Rule
o 能够根据规则显示筛选器计数器
o Ability to Display Filter Counters per Filter Application
o 能够显示每个筛选器应用程序的筛选器计数器
o Ability to Reset Filter Counters
o 能够重置过滤器计数器
o Filter Counters Must Be Accurate
o 过滤器计数器必须准确
o Logging Facility Uses Protocols Subject To Open Review
o 日志记录设施使用开放审查的协议
o Logs Sent To Remote Servers
o 发送到远程服务器的日志
o Ability to Log Locally
o 本地登录的能力
o Ability to Maintain Accurate System Time
o 能够保持准确的系统时间
o Display Timezone And UTC Offset
o 显示时区和UTC偏移
o Default Timezone Should Be UTC
o 默认时区应为UTC
o Logs Must Be Timestamped
o 日志必须有时间戳
o Logs Contain Untranslated IP Addresses
o 日志包含未翻译的IP地址
o Logs Contain Records Of Security Events
o 日志包含安全事件的记录
o Authenticate All User Access
o 对所有用户访问进行身份验证
o Support Authentication of Individual Users
o 支持个人用户的身份验证
o Support Simultaneous Connections
o 支持同时连接
o Ability to Disable All Local Accounts
o 能够禁用所有本地帐户
o Support Centralized User Authentication Methods
o 支持集中式用户身份验证方法
o Support Local User Authentication Method
o 支持本地用户身份验证方法
o Support Configuration of Order of Authentication Methods
o 支持配置身份验证方法的顺序
o Ability To Authenticate Without Plaintext Passwords
o 无需明文密码即可进行身份验证
o Passwords Must Be Explicitly Configured Prior To Use
o 使用前必须明确配置密码
o No Default Passwords
o 没有默认密码
o Ability to Define Privilege Levels
o 能够定义权限级别
o Ability to Assign Privilege Levels to Users
o 为用户分配权限级别的能力
o Default Privilege Level Must Be 'None'
o 默认权限级别必须为“无”
o Change in Privilege Levels Requires Re-Authentication
o 权限级别的更改需要重新身份验证
o Support Recovery Of Privileged Access
o 支持恢复特权访问
o Logs Do Not Contain Passwords
o 日志不包含密码
o Security Features Must Not Cause Operational Problems
o 安全功能不得导致操作问题
o Security Features Should Have Minimal Performance Impact
o 安全功能应该对性能的影响最小
o Identify Services That May Be Listening
o 识别可能正在侦听的服务
o Document Service Defaults
o 文档服务默认值
o Document Service Activation Process
o 文档服务激活过程
o Identify Origin of IP Stack
o 标识IP堆栈的来源
o Identify Origin of Operating System
o 识别操作系统的来源
o Identify Origin of IP Stack
o 标识IP堆栈的来源
o Identify Origin of Operating System
o 识别操作系统的来源
o Layer 2 Devices Must Meet Higher Layer Requirements
o 第2层设备必须满足更高的层要求
This section builds on the minimal requirements listed in A.1 and adds more stringent security functionality specific to layer 3 devices which are part of the network edge. The network edge is typically where much of the filtering and traffic control policies are implemented.
本节以A.1中列出的最低要求为基础，并针对属于网络边缘的第3层设备添加了更严格的安全功能。网络边缘通常是实施大部分过滤和流量控制策略的地方。
An edge device is defined as a device that makes up the network infrastructure and connects directly to customers or peers. This would include routers connected to peering points, switches connecting customer hosts, etc.
边缘设备定义为构成网络基础设施并直接连接到客户或对等方的设备。这将包括连接到对等点的路由器、连接客户主机的交换机等。
o Support Automatic Anti-spoofing for Single-Homed Networks
o 支持单宿网络的自动反欺骗
o Support Automatic Discarding Of Bogons and Martians
o 支持自动丢弃博根人和火星人
o Support Counters For Dropped Packets
o 丢弃数据包的支持计数器
o Support Rate Limiting
o 支持率限制
o Support Directional Application Of Rate Limiting Per Interface
o 支持每个接口的速率限制定向应用
o Support Rate Limiting Based on State
o 基于状态的支持率限制
o Ability to Filter Traffic THROUGH the Device
o 能够过滤通过设备的流量
This document grew out of an internal security requirements document used by UUNET for testing devices that were being proposed for connection to the backbone.
本文档源于UUNET用于测试拟连接到主干网的设备的内部安全需求文档。
The editor gratefully acknowledges the contributions of: o Greg Sayadian, author of a predecessor of this document.
编辑非常感谢：o Greg Sayadian的贡献，他是本文件的前任作者。
o Eric Brandwine, a major source of ideas/critiques.
o Eric Brandwine，思想/评论的主要来源。
o The MITRE Corporation for supporting continued development of this document. NOTE: The editor's affiliation with The MITRE Corporation is provided for identification purposes only, and is not intended to convey or imply MITRE's concurrence with, or support for, the positions, opinions or viewpoints expressed by the editor.
o MITRE公司支持本文件的持续开发。注：编辑与米特公司的联系仅用于识别目的，并不表示或暗示米特同意或支持编辑表达的立场、观点或观点。
o The former UUNET network security team: Jared Allison, Eric Brandwine, Clarissa Cook, Dave Garn, Tae Kim, Kent King, Neil Kirr, Mark Krause, Michael Lamoureux, Maureen Lee, Todd MacDermid, Chris Morrow, Alan Pitts, Greg Sayadian, Bruce Snow, Robert Stone, Anne Williams, Pete White.
o 前UUNET网络安全团队：贾里德·艾利森、埃里克·布兰德温、克拉丽莎·库克、戴夫·加恩、泰金、肯特·金、尼尔·基尔、马克·克劳斯、迈克尔·拉莫鲁、莫林·李、托德·麦克德米德、克里斯·莫罗、艾伦·皮特、格雷格·萨亚迪亚、布鲁斯·斯诺、罗伯特·斯通、安妮·威廉姆斯、皮特·怀特。
o Others who have provided significant feedback at various stages of the life of this document are: Ran Atkinson, Fred Baker, Steve Bellovin, David L. Black, Michael H. Behringer, Matt Bishop, Scott Blake, Randy Bush, Pat Cain, Ross Callon, Steven Christey, Owen Delong, Sean Donelan, Robert Elmore, Barbara Fraser, Barry Greene, Jeffrey Haas, David Harrington, Dan Hollis, Jeffrey Hutzelman, Merike Kaeo, James Ko, John Kristoff, Chris Lonvick, Chris Liljenstolpe, James W. Laferriere, Jared Mauch, Perry E. Metzger, Mike O'Connor, Alan Paller, Rob Pickering, Pekka Savola, Gregg Schudel, Juergen Schoenwaelder, Don Smith, Rodney Thayer, David Walters, Joel N. Weber II, Russ White, Anthony Williams, Neal Ziring.
o 在本文件生命的各个阶段提供重要反馈的其他人有：Ran Atkinson、Fred Baker、Steve Bellovin、David L.Black、Michael H.Behringer、Matt Bishop、Scott Blake、Randy Bush、Pat Cain、Ross Callon、Steven Christey、Owen Delong、Sean Donelan、Robert Elmore、Barbara Fraser、Barry Greene、Jeffrey Haas、，大卫·哈林顿、丹·霍利斯、杰弗里·哈泽尔曼、梅里克·卡奥、詹姆斯·柯、约翰·克里斯托夫、克里斯·隆维克、克里斯·利延斯托尔佩、詹姆斯·W·拉费里埃、杰瑞德·莫奇、佩里·E·梅茨格、迈克·奥康纳、艾伦·帕勒、罗伯·皮克林、佩卡·萨沃拉、格雷格·舒德尔、于尔根·舍恩瓦尔德、唐·史密斯、罗德尼·泰尔、大卫·沃尔特斯、乔尔·韦伯二世、罗斯·怀特、，安东尼·威廉姆斯，尼尔·齐林。
o Madge B. Harrison and Patricia L. Jones, technical writing review.
o Madge B.Harrison和Patricia L.Jones，《技术写作评论》。
o This listing is intended to acknowledge contributions, not to imply that the individual or organizations approve the content of this document.
o 本清单旨在确认贡献，而不是暗示个人或组织批准本文件的内容。
o Apologies to those who commented on/contributed to the document and were not listed.
o 向对该文件发表评论/作出贡献但未列入名单的人致歉。
Author's Address
作者地址
George M. Jones, Editor The MITRE Corporation 7515 Colshire Drive, M/S WEST McLean, Virginia 22102-7508 U.S.A.
乔治·M·琼斯，米特尔公司编辑，美国弗吉尼亚州西麦克莱恩市科尔希尔大道7515号，邮编：22102-7508。
Phone: +1 703 488 9740
EMail: gmj3871@pobox.com
Phone: +1 703 488 9740
EMail: gmj3871@pobox.com
Full Copyright Statement
完整版权声明
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编辑功能的资金目前由互联网协会提供。