[要約] 要約：RFC 3871は、大規模なインターネットサービスプロバイダ（ISP）のIPネットワークインフラストラクチャに対する運用セキュリティ要件を定義しています。目的：このRFCの目的は、ISPが適切なセキュリティ対策を実施し、ネットワークインフラストラクチャの安全性を確保するためのガイドラインを提供することです。
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）The Internet Society（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
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
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 Name/Time/Log/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.
意図された2人の視聴者がいます。IPネットワーク機器を選択、購入、運用するネットワークオペレーターと、それらを作成するベンダーです。
The individual requirements are listed in the three sections below.
個々の要件は、以下の3つのセクションにリストされています。
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 Warnings (if applicable)
o 例（方法）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
RFC 2119キーワード
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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キーワードの使用は、編集者が正しい要件レベル（「必須」、「必須」、「5月」）を割り当てようとする試みです。さまざまな組織、運用環境、ポリシー、および法的環境が異なる要件レベルを生み出すことに注意する必要があります。オペレーターとベンダーは、独自のコンテキストでここにリストされている個々の要件を慎重に検討する必要があります。1つのサイズがすべてに適合しません。
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」）は、IANAまたは地域のインターネットレジストリ（Arin、Ripe、Apnic ...）によってまだ割り当てられていないアドレスブロックにIPソースアドレスを備えたパケットです。RFCSによるプライベートまたは特別な使用。[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.
いくつかの要件は「コンソール」を指します。このモデルは、過去30年以上にわたって、シンプルで安定した、信頼性が高く、よく理解されており、ほぼユビキタスな管理インターフェイスをネットワークデバイスに提供してきた古典的なRS232シリアルポートです。繰り返しますが、これらの要件は、主に、その由緒あるインターフェイスによって提供される利点を成文化することを目的としており、同じ要件をすべて満たす他のメカニズムを排除することではありません。
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で指定されているように、各ルールが1つ以上の一致基準を指定する1つ以上のルールのグループとして定義されます。
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.
「インバンド管理」とは、ユーザー/顧客データに使用される同じチャネルとインターフェイスで行われた管理として定義されます。例には、顧客またはインターネット向けのネットワークインターフェイスを介して管理に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.
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.
「Open Review」とは、最終的なソリューションの信頼を向上させ、構築するという目標を持つ、データ通信プロトコルや暗号化アルゴリズムなどの提案された技術ソリューションの公開討論とレビューを生成するために設計されたプロセスを指します。
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.
このドキュメントの目的のために、「Open Review」は[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
* 上流の接続は1つだけです
* 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]、[RFC2631]。メッセージの検証を必要とするアプリケーションのために、SHA-1 [RFC3174]を備えたHMAC [RFC2401]。
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]、[RFC2631]。メッセージの検証を必要とするアプリケーションのために、SHA-1 [RFC3174]を備えたHMAC [RFC2401]。
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の弱さのヒント。」展開された製品とプロトコルでのこのようなハッシュの使用は、完全性と認証チェックの完全な欠如よりも好ましいが、このドキュメントは、新製品とプロトコルが代替案を強く検討するという推奨事項に同意している。
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.
1,000,000人の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:
これらの要件は、2つの異なる可能性のある帯域外のトポロジを想定しています。
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.
ネットワークが利用できない場合でも、管理または構成のためにデバイスにすぐに簡単にアクセスできるようにすることが動作的に必要な場合があります。（または、使用することを不可能/不可能にする最近発見されたエクスプロイトに対して脆弱である可能性があります）、またはデバイスへの帯域幅の高いパスが利用できない場合。このような状況では、コンソールインターフェイスは、デバイスを管理および構成する方法を提供できます。
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.
* CLIフレンドリー。ほとんどの場合、デバイスを管理するには、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.
1つの方法は、シリアルラインで休憩を送信することです。
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を参照）、管理に使用される他のすべてのインターフェイスでサポートする必要があります。
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 [RFC3411]、[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.
スクリプトの例には、大規模なネットワーク間の攻撃の追跡、認証パラメーターの更新、ロギングパラメーターの更新、フィルターの更新、構成の取得/監査などが含まれます。
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インターフェイス（例：ネイティブウィンドウまたはマッキントッシュ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.
ゆっくりとしたリンクの操作をサポートするメカニズムの1つは、潜在的に大きな出力を持つCLIコマンドの出力にフィルターを適用する機能です。これは、UNIXパイプ機能と「GREP」コマンドに似たもので実装できます。
For example,
例えば、
cat largefile.txt | grep interesting-string
cat largefile.txt |グレップ興味深い弦
Another is the ability to "page" through large command output, e.g., the UNIX "more" command:
もう1つは、大規模なコマンド出力を介して「ページ」する機能です。たとえば、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.
この要件の結果の1つは、管理に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 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).
* ハッカー、オペレーターなどが、すべての書き込み可能なメディア（ディスク、フラッシュなど）を消去または破損する可能性があると仮定する必要があります。このような状況では、執筆不可能なメディア（たとえば、真の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）すべてのパブリックネットワークから切断されていると仮定して、ネットワークインターフェイスを介して新しいコードのインストールをサポートできます。ネットワークから。
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.
* Open Standardとベンダーの両方の専有サービスを含めます。
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.
これにより、接続または送信を受信するリモートデバイスがソースフィルタリングを1つの認証手段として使用できます。たとえば、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は特定の物理インターフェイスアドレスを使用するように構成できます。これにより、ピア/サーバーに接続する不正な試みを拒否する1つの方法として、ソースアドレスに基づいてフィルタリングが容易になります。
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).
この要件は、受信したパケットが現在の転送テーブルに対してチェックされ、実行可能なリターンパスが存在しない場合にドロップされるコマンドの提供によって満たされる可能性があります。これは、転送テーブルにボーゴンエントリが存在しないことを保証するための手順が取られていることを前提としています（たとえば、セクション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トラフィックでWebサーバーにあふれることにしたと仮定します。このような状況では、データセンターのボーダールーターでインバウンドICMPトラフィックを評価できるようにすることが役立ちます。反対側では、脆弱なデータベースサーバーに感染する新しいワームがリリースされ、その後、感染したサーバーのシステムとネットワークインターフェイスと同じくらい速くランダムな宛先アドレスを対象としたTCPポート1433のトラフィックの噴出を開始すると仮定します。さらに、データセンターには感染している多くの脆弱なサーバーがあり、同時に大量のトラフィックを送信して、すべてのアウトバウンドリンクが飽和していると仮定します。この要件の実装により、ネットワークオペレーターは、インバウンドおよび/またはアウトバウンドTCP 1433トラフィック（おそらく1秒あたり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フラッドがEdgeルーターに単一の顧客に指示されている場合、その顧客インターフェイスでのみAutbound 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.
プロトコルおよび/またはソース/宛先アドレス、またはソース/宛先ポートに基づいてフィルタリングを可能にするアクセス制御リストが1つの例です。
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のみを許可されているフィルターと、承認された管理セグメントからのSSHと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.
この要件を満たす簡単で一般的な方法の1つは、各インターフェイスにインバウンドおよび/または各インターフェイスからアウトバウンドにインバウンドするトラフィックをフィルタリングする機能を提供することです。[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.
要件を述べるもう1つの方法は、フィルターのパフォーマンスがデバイススループットの制限要因であってはならないということです。デバイスがフィルタリングなしで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].
フィルターのパフォーマンスへの影響を示す繰り返し可能なテストデータは、この要件との適合性を評価するのに非常に役立ちます。テストには、パケットサイズ、パケットレート、テストされたインターフェイスの数（ソース/宛先）、インターフェイスの種類、ルーティングテーブルサイズ、使用中のルーティングプロトコル、ルーティングアップデートの頻度などなどの情報を含める必要があります。。
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].
[RFC2196]の[RFC3013]およびセクション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.
インターネットに接続された小さな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.
通知を送信せずに静かにトラフィックを落とすことは、セキュリティ用語で正しいアクションである可能性がありますが、運用上の意味を考慮する必要があります。不適切なTCPリセットを送信することによって引き起こされる潜在的な問題を考慮するについては、[RFC3360]を参照してください。
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のトラフィックで被害者にあふれる能力に基づいています。そのような攻撃の影響を軽減するための1つの迅速な方法（確かにいくつかの否定的な副作用を伴う）は、被害者に向かっているすべての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].
アドレスベースのフィルタリングの使用の1つの例は、[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でサポートされている他のすべてのプロトコルのフィルタリングをサポートする必要があります。高レベルプロトコルのヘッダーに基づいてフィルタリングをサポートする場合があります。ビットオフセット/長さ/数値（例：72：8 = 1）ではなく、名前（例：「プロトコル= ICMP」）でフィールドを指定することが可能である必要があります。
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 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.
この要件は、TCPまたはUDPポート番号、Syn、ACK、RST BITSなどのTCPフラグ、ICMPタイプとコードフィールドに基づいてフィルタリングできることを意味します。一般的な例の1つは、「インバウンド」TCP接続試行を拒否することです（TCP、Syn Bit Set ACK BIT CLEARまたはSYN BIT SET ACK、FIN、RST BITS CLEAR）。もう1つの一般的な例は、ネットワーク内/外出を許可されるサービスを制御する機能です。ネットワークホスティングWebサーバーにポート80（HTTP）と443（HTTPS）のインバウンド接続のみを許可することが望ましい場合があります。
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は、多数のスプーフィングされたパケットが送信されているケースを検出できます。これは、顧客が潜在的に悪意のあるアクションを実行していることを示している可能性があります（おそらくISPの許容可能な使用ポリシーに違反している可能性があります）、または顧客ネットワーク上のシステムはハッカーによって「所有」されており、攻撃の起動に使用されています（MIS）。
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.
4つのインターフェイスを備えたルーターがあると仮定します。1つは、インターネットへのルートを提供するISPのアップリンクです。他の3つは、個別の内部ネットワークに接続します。内部ネットワークの1つのホストがハッカーによって侵害されており、偽のソースアドレスでトラフィックを送信していると仮定します。このような状況では、各内部インターフェイスにイングレスフィルターを適用することが望ましい場合があります。フィルターが配置されると、カウンターを調べて、偽のパケットのソース（インバウンドインターフェイス）を決定できます。
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.
2つのルールがあるフィルターが定義されていると仮定します。1つはすべてのSSHトラフィック（TCP/22）を許可し、2番目のルールを許可し、残りのすべてのトラフィックを削除します。3つのパケットがフィルターが適用されるポイント、1つはポート22に、その他は異なるポートに向けられている場合、カウンターディスプレイには、許可TCP/22ルールに一致する1つのパケットと、すべての拒否と一致する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.
同じフィルター定義を同時に1回以上（異なるインターフェイスなど）適用することは理にかなっています。もしそうなら、あるインスタンスがどこかで一致していることを知るよりも、フィルターのどのインスタンスが一致しているかを知る方がはるかに便利です。
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
この要件を実装する1つの方法は、フィルターの名前（または他の設計者）とともに、フィルターが適用されているインターフェイス（または他のエンティティ）をカウンターディスプレイメカニズムに表示することです。たとえば、フィルターという名前の場合
"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」という2つの異なるインターフェイスを適用しました。ディスプレイは、「ethernet0の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]).
この要件の目的のために、システムが2つのカウンターを維持することは許容されます：「絶対カウンター」、C [NOW]、および「リセット」カウンター、C [リセット]。絶対カウンターは、カウンターを巻き付けたりオーバーフローするまで単調に増加するカウントを維持します。リセットカウンターは、そのカウンターに対してリセット関数が発行されたときに、絶対カウンターの現在の値のコピーを受け取ります。カウンターを表示または取得する関数は、Delta（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.
新しいワームに感染した内部ホストを検出するために、フィルターカウンターが使用されていると仮定します。感染したすべての宿主がクリーンアップされ、ワームが削除されたと信じられたら、次のステップはそれを確認することです。そうすることの1つは、フィルターカウンターをゼロにリセットし、ワームを示すトラフィックが停止しているかどうかを確認することです。
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.
いくつかのルールがあるフィルターが定義されており、ルールの1つが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].
この要件は、1つ以上のSyslog [RFC3164]、信頼できる配信[RFC3195]、TACACS [RFC1492]または半径[RFC2865]を備えたSyslogを使用することで満たされる場合があります。
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.
The current best solution seems to be the following:
現在の最良の解決策は次のとおりです。
* Implement [RFC3164].
* [RFC3164]を実装します。
* Consider implementing [RFC3195].
* [RFC3195]の実装を検討してください。
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.
デバイスは、セキュリティ関連のイベントの記録の送信を1つ以上のリモートデバイスにサポートする必要があります。デバイスには、サーバーの選択を可能にする構成設定が必要です。
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].
この要件は、1つ以上のSyslog [RFC3164]、信頼できる配信[RFC3195]、TACACS [RFC1492]、または半径[RFC2865]を使用するSyslogを使用することで満たされる場合があります。
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.
信頼性の高いSyslog配信の1つの例は、[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.
ローカルロギングは、デバイスに接続されたときに情報を表示するために重要です。リモートロギングが失敗した場合に備えて、ログデータのバックアップを提供します。他のデバイスからのログの可能性が高い可能性のあるログを並べ替えることなく、1つのデバイスに関連するログを表示する方法を提供します。
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).
ローカルロギングの1つの例は、リモートログサーバーに送信されたメッセージのコピーを受信するメモリバッファーです。別の例は、ローカル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.
デバイス上のストレージは制限される場合があります。大量のロギングは、利用可能なストレージをすばやく入力する可能性があります。この場合、2つのオプションがあります。新しいログは、古いログ（おそらく円形メモリバッファーまたはログファイルの回転を使用して）を上書きするか、ロギングの停止を上書きします。
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.
TimeZoneまたは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であるカナダのニューファンドランドにいます。アリスは米国インディアナ州のどこかにあります。インディアナ州の一部の部分は、夏時間に切り替えますが、他の部分はそうではありません。ボブのネットワーク上のユーザーは、アリスのネットワークでユーザーを攻撃します。どちらもローカルタイムゾーンでログを使用しており、UTCオフセットの兆候はありません。これらのログを相関させることは困難であり、エラーが発生しやすくなります。TimeZone、またはそれ以上の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.
TimeZoneまたは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.
デフォルトでは、デバイスはすべてのログメッセージをタイムスタンプする必要があります。タイムスタンプは、1秒以内に正確でなければなりません。タイムスタンプにはタイムゾーンを含める必要があります。タイムスタンプの生成を無効にするメカニズムがあるかもしれません。
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.
異なるタイムゾーンのログを相関させることは困難です。インターネット上のセキュリティイベントには、多くの場合、さまざまな物理的な場所からの機械とログが含まれます。そのため、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.
ログメッセージは、ログメッセージを生成するデバイスでIPアドレスが使用可能な翻訳されていないIPアドレスをリストせずに、アドレスに関連付けられた翻訳されたアドレス（DNS名）をリストしてはなりません。
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.
* ネットワークトポロジは変更される場合があります。動的アドレスの割り当てがない場合でも、ネットワークトポロジとアドレスブロックの割り当てが変更されます。1か月前の攻撃のログは、当時、どのホスト、ネットワーク、または組織が問題のシステムを所有していたかを正確に示していない場合があります。
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.
半径に関連するディスカッションセキュリティの問題については、[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.
ローカル、デバイスごとのユーザー名とパスワードを使用すると、この要件を実装する1つの方法が提供されます。
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.
Plantextパスワードは、共有ネットワーク上のパケットスニファーを使用して簡単に観察できます。スルーディスカッションについては、[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コミュニティの文字列「パブリック」および「プライベート」は、デバイスへの読み取りおよび書き込みアクセスを提供するよく知られているデフォルトです。
Warnings.
警告。
Lists of default passwords for various devices are readily available at numerous websites.
さまざまなデバイスのデフォルトパスワードのリストは、多数のWebサイトで簡単に入手できます。
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.
デバイスには、管理用のコンソールポートとデフォルトの管理アカウントが付属していると仮定します。この要件は、デフォルトのパスワードなしで、管理アカウントにはパスワードが構成されていない必要があると述べています。この要件を満たす方法の1つは、デバイスが最初に設定されたときにダイアログの一部として、オペレーターに管理アカウントのパスワードを選択するようにデバイスに要求することです。
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ごとにユーザーに割り当てることができるグループまたは「特権レベル」に割り当てることができなければなりません。少なくとも3つの可能な特権レベルが必要です。
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セッションの開始のみを許可する「ユーザー」、「読み取り専用」が含まれます。すべての構成可能なパラメーターと、限られたユーザー定義のパラメーターセットへの更新を可能にする「演算子」に。特権レベルは、デバイスまたは集中認証サーバーでローカルに定義される場合があることに注意してください。
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を使用すると、IDを特定の特権レベルにマッピングするために使用できるユーザーのRADIUSプロファイルに属性を設定できます。
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セッションの開始を可能にする「ユーザー」、「読み取り専用」が含まれる場合があります。これにより、デバイスの構成と運用統計への読み取り専用アクセス、「ルート/スーパーユーザー/管理者」すべての構成可能なパラメーターへのアクセス、および限られたユーザー定義のパラメーターセットへの更新を可能にする「演算子」。特権レベルは、デバイスまたは集中認証サーバーでローカルに定義される場合があることに注意してください。
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）をサポートし、OSのインストールと構成（セクション2.4.5）をサポートするための要件をサポートするための例外を提供する必要がある場合があります。たとえば、OSおよび/または構成が何らかの形で破損した場合、物理的アクセスを持つ認定された個人がインストールを実行するために「ルート」レベルアクセスが必要になる場合があります。
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機能を提供する必要があります。また、レイヤー2デバイスを管理するために高層機能（SSHまたはSNMPなど）を使用している場合、このドキュメントの残りの要件はそれらの機能に適用されます。
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.
たとえば、TCPポート1433でリスニングされるサービスを探しているランダムなIPアドレスをスキャンする新しいワームがリリースされていると仮定します。オペレーターは、ネットワーク上のホストのいずれかが感染しているかどうかを調べてワームを広めようとしている可能性があります。これを行う1つの方法は、アウトバウンド接続の数をカウントして記録する非ブロッキングフィルターを作成し、感染したホストからのものと判断されたリクエストをブロックすることです。これらの機能（フィルタリング、カウント、ロギング）のいずれかが深刻なパフォーマンスの罰則を課す可能性がある場合、そうでなければ合理的な行動方針は不可能かもしれません。
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でリッスンします。デバイスのデフォルト構成では、ポート8080でWebサーバーがリスニングされている場合があります。この要件のコンテキストでは、「識別...デフォルトポート」は「ポート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.
これは、「標準」のコマンドグループを有効/無効にする1つまたは単一のコマンドを1つまたは単一のコマンドで有効/無効にするコマンドのリストです。
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.
この情報は、OSに基づいてOSに固有のセキュリティの脆弱性をよりよく理解するために必要です。
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を使用して）安全である場合でも、それでもセキュアネットワークで誰がアクセスして取得/設定（読み取り/変更/作成/削除/削除）を制御することはできません。ミブ。
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暗号化メカニズム（認証とプライバシーのため）の完全なサポートを含む、SNMPV3フレームワーク（[RFC3410]、セクション8を参照）で提供されるセキュリティ機能を考慮することをお勧めします。
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] American National Standards Institute、「トリプルデータ暗号化アルゴリズムモードモード」、ANSI X9.52、1998。
[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]国立標準技術研究所、「Advanced Encryption Standard」、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 Laboratories、「Diffie-Hellman Key-Agreement Standard、バージョン1.4」、PKCS 3、1993年11月。
[RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms", RFC 1208, March 1991.
[RFC1208]ヤコブセン、O。およびD.リンチ、「ネットワーキング条件の用語集」、RFC 1208、1991年3月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジストアルゴリズム」、RFC 1321、1992年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、「The Kerberos Network Authentication Service（V5）」、RFC 1510、1993年9月。
[RFC1704] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[RFC1704]ハラー、N。およびR.アトキンソン、「インターネット認証について」、RFC 1704、1994年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、「Private Internetsのアドレス割り当て」、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] Fraser、B。、「サイトセキュリティハンドブック」、FYI 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」、RFC 2246、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 Key Asmatement Method」、RFC 2631、1999年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 2865、2000年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。、「The BSD Syslog Protocol」、RFC 3164、2001年8月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174] Eastlake、D。およびP. Jones、「US Secure Hash Algorithm 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、「Syslogの信頼できる配信」、RFC 3195、2001年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。and D. Otis、「Stream Control Transmission Protocol（SCTP）チェックサムの変更」、RFC 3309、2002年9月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330] IANA、「特別使用IPv4アドレス」、RFC 3330、2002年9月。
[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", BCP 60, RFC 3360, August 2002.
[RFC3360]フロイド、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 3410、2002年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.、Presuhn、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、「Public-Key Cryptography Standards（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、eds。、「インターネットのセキュリティメカニズム」、RFC 3631、2003年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 3704、2004年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。、「Applied Cryptography、第2版、出版社John Wiley＆Sons、Inc。」、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' Supports Management Over 'Slow' Links
o 「CLI」は構成のスクリプトをサポートしています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 Ability to Display Filter Counters per Filter Application
o ルールごとにフィルターカウンターを表示する機能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 Default Privilege Level Must Be 'None'
o ユーザーに特権レベルを割り当てる能力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 Support Directional Application Of Rate Limiting Per Interface
o サポートレート制限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.
編集者は、このドキュメントの前身の著者であるGreg Sayadianの貢献に感謝して認めています。
o Eric Brandwine, a major source of ideas/critiques.
o アイデア/批評の主要な源であるエリック・ブランドワイン。
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 このドキュメントの継続的な開発をサポートするためのMiter Corporation。注：編集者のMiter Corporationとの提携は、識別目的でのみ提供されており、編集者が表明したポジション、意見、または視点とのMiterの同意またはサポートを伝えるか、サポートすることを意図したものではありません。
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ネットワークセキュリティチーム：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スノー、ロバート・ストーン、アン・ウィリアムズ、ピート・ホワイト。
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、スティーブン・クリスティー、オーウェン・デロング、ショーン・ドネラン、ロバート・エルモア、バーバラ・フレイザー、バリー・グリーン、ジェフリー・ハース、デビッド・ハースン、ダン・ホリス、ジェフリー・ハッツェルマン、メリケオ、ジェームズ・コ、ジョン・キリストフ、クリス・ロンヴィック、クリス・ライアリー、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、ニールジリング。
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コルシャードライブ、M/Sウェストマクリーン、バージニア22102-7508 U.S.A.
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）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。