draft-ietf-opsec-framework-04.txt   draft-ietf-opsec-framework-05.txt 
OPSEC Working Group G. Jones OPSEC Working Group G. Jones
Internet-Draft Internet-Draft
Intended status: Informational R. Callon Intended status: Informational R. Callon
Expires: September 4, 2007 Juniper Networks Expires: September 21, 2007 Juniper Networks
M. Kaeo M. Kaeo
Double Shot Security Double Shot Security
March 3, 2007 March 20, 2007
Framework for Operational Security Capabilities for IP Network Framework for Operational Security Capabilities for IP Network
Infrastructure Infrastructure
draft-ietf-opsec-framework-04 draft-ietf-opsec-framework-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 4, 2007. This Internet-Draft will expire on September 21, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document outlines work to be done and documents to be produced This document outlines work done and documents produced by the
by the Operational Security Capabilities (OPSEC) Working Group. The Operational Security Capabilities (OPSEC) Working Group. The goal of
goal of the working group is to codify knowledge gained through the working group is to codify knowledge gained through operational
operational experience about feature sets that are needed to securely experience about feature sets that are needed to securely deploy and
deploy and operate managed network elements providing transit operate managed network elements providing transit services at the
services at the data link and IP layers. The intent is to provide data link and IP layers.
clear, concise documentation of capabilities necessary for operating
networks securely, to assist network operators in communicating their The intent is to provide clear, concise documentation of capabilities
requirements to vendors, and to provide vendors with input that is necessary for operating networks securely, to assist network
useful for building more secure devices. The working group will operators in communicating their requirements to vendors, and to
produce a list of capabilities appropriate for large Internet Service provide vendors with input that is useful for building more secure
Provider (ISP) and Enterprise Networks. This work is intended to devices. The working group produced a list of capabilities
refine [RFC3871]. appropriate for large Internet Service Provider (ISP) and Enterprise
Networks. This work is intended to refine [RFC3871].
This document also provides guidance for the creation of profile
documents which are lists of security features needed in specific
operating environments.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 5
1.3.1. Threats Addressed, Threats Not Addressed . . . . . . . 4 1.3.1. Threats Addressed, Threats Not Addressed . . . . . . . 5
1.3.2. Active, Passive and Combined Attacks . . . . . . . . . 5 1.3.2. Active, Passive and Combined Attacks . . . . . . . . . 6
1.3.3. Categories of Threats . . . . . . . . . . . . . . . . 5 1.3.3. Categories of Threats . . . . . . . . . . . . . . . . 6
1.3.4. Threat Sources . . . . . . . . . . . . . . . . . . . . 6 1.3.4. Threat Sources . . . . . . . . . . . . . . . . . . . . 7
1.4. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1. Passive attacks . . . . . . . . . . . . . . . . . . . 6 1.4.1. Passive attacks . . . . . . . . . . . . . . . . . . . 7
1.4.2. Eavesdropping/Sniffing . . . . . . . . . . . . . . . . 6 1.4.2. Eavesdropping/Sniffing . . . . . . . . . . . . . . . . 7
1.4.3. Off-line Cryptographic Attacks . . . . . . . . . . . . 7 1.4.3. Off-line Cryptographic Attacks . . . . . . . . . . . . 8
1.4.4. Active Attacks . . . . . . . . . . . . . . . . . . . . 7 1.4.4. Active Attacks . . . . . . . . . . . . . . . . . . . . 8
1.4.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . 7 1.4.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . 8
1.4.6. Message Insertion . . . . . . . . . . . . . . . . . . 7 1.4.6. Message Insertion . . . . . . . . . . . . . . . . . . 8
1.4.7. Message Modification . . . . . . . . . . . . . . . . . 8 1.4.7. Message Modification . . . . . . . . . . . . . . . . . 9
1.4.8. Message Deletion . . . . . . . . . . . . . . . . . . . 8 1.4.8. Message Deletion . . . . . . . . . . . . . . . . . . . 9
1.4.9. Man-In-The-Middle . . . . . . . . . . . . . . . . . . 8 1.4.9. Man-In-The-Middle . . . . . . . . . . . . . . . . . . 9
1.4.10. Invalid Message . . . . . . . . . . . . . . . . . . . 8 1.4.10. Invalid Message . . . . . . . . . . . . . . . . . . . 9
1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 9 1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6. Intended Audience . . . . . . . . . . . . . . . . . . . . 10 1.6. Intended Audience . . . . . . . . . . . . . . . . . . . . 10
1.7. Format and Definition of Capabilities . . . . . . . . . . 10 1.7. Format and Definition of Capabilities . . . . . . . . . . 11
1.8. Applicability . . . . . . . . . . . . . . . . . . . . . . 11 1.8. Applicability . . . . . . . . . . . . . . . . . . . . . . 11
1.9. Intended Use . . . . . . . . . . . . . . . . . . . . . . . 11 1.9. Intended Use . . . . . . . . . . . . . . . . . . . . . . . 12
1.10. Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 1.10. Definitions . . . . . . . . . . . . . . . . . . . . . . . 12
2. Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2. Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1. Framework Document . . . . . . . . . . . . . . . . . . . . 16 2.1. Framework Document . . . . . . . . . . . . . . . . . . . . 17
2.2. Operator Practices Survey . . . . . . . . . . . . . . . . 16 2.2. Operator Practices Survey . . . . . . . . . . . . . . . . 17
2.3. Standards Survey . . . . . . . . . . . . . . . . . . . . . 16 2.3. Standards Survey . . . . . . . . . . . . . . . . . . . . . 17
2.4. Capabilities Documents . . . . . . . . . . . . . . . . . . 16 2.4. Capabilities Documents . . . . . . . . . . . . . . . . . . 17
2.5. Profile Documents . . . . . . . . . . . . . . . . . . . . 17 2.5. Profile Documents . . . . . . . . . . . . . . . . . . . . 18
3. Security Considerations . . . . . . . . . . . . . . . . . . . 18 3. Security Considerations . . . . . . . . . . . . . . . . . . . 19
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
5. Non-Normative References . . . . . . . . . . . . . . . . . . . 20 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
Appendix A. Sample Capability Description . . . . . . . . . . . . 21 6. Non-Normative References . . . . . . . . . . . . . . . . . . . 22
A.1. Filtering TO the Device . . . . . . . . . . . . . . . . . 21 Appendix A. Sample Capability Description . . . . . . . . . . . . 24
A.1. Filtering TO the Device . . . . . . . . . . . . . . . . . 24
A.1.1. Ability to Filter Traffic on All Interfaces TO the A.1.1. Ability to Filter Traffic on All Interfaces TO the
Device . . . . . . . . . . . . . . . . . . . . . . . . 21 Device . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix B. Guide to writing profiles . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 23 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 25
B.2. Guidance . . . . . . . . . . . . . . . . . . . . . . . . . 25
B.3. Sample Profile . . . . . . . . . . . . . . . . . . . . . . 26
B.3.1. Required Capabilities for Edge Routers . . . . . . . . 26
B.3.2. Recommended Capabilities for Edge Routers . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 29
1. Introduction 1. Introduction
1.1. Goals 1.1. Goals
The goal of the Operational Security Working Group is to codify The goal of the Operational Security Working Group is to codify
knowledge gained through operational experience about feature sets knowledge gained through operational experience about feature sets
that are needed to securely deploy and operate managed network that are needed to securely deploy and operate managed network
elements providing transit services at the data link and IP layers. elements providing transit services at the data link and IP layers.
It is anticipated that the codification of this knowledge will be an It is anticipated that the codification of this knowledge will be an
aid to vendors in producing more securable network elements, and an aid to vendors in producing more securable network elements, and an
aid to operators in increasing security by deploying and configuring aid to operators in increasing security by deploying and configuring
more secure network elements. more secure network elements.
This framework document provides an overview of the work to be done This framework document provides an overview of the work done by the
by the working group, and describes the documents to be produced in working group, and describes the documents produced in this effort.
this effort.
1.2. Motivation 1.2. Motivation
Network operators need the appropriate feature sets and tools on Network operators need the appropriate feature sets and tools on
their infrastructure devices to ensure that they can effectively their infrastructure devices to ensure that they can effectively
deploy and manage their networks securely while maintaining the deploy and manage their networks securely while maintaining the
ability to provide reliable service to their customers. Vendors need ability to provide reliable service to their customers. Vendors need
guidelines on which security features and functionality are critical guidelines on which security features and functionality are critical
for operators to be able to reach that goal. for operators to be able to reach that goal.
1.3. Threat Model 1.3. Threat Model
1.3.1. Threats Addressed, Threats Not Addressed 1.3.1. Threats Addressed, Threats Not Addressed
This section describes the general classes of threats that this work This section describes the general classes of threats that this work
intends to address. Specific threats and attacks will be discussed intends to address. Specific threats and attacks are discussed in
in the documents which are referred to in this framework. Each of the documents which are referred to in this framework. Each of those
those documents will enumerate the capabilities which are required to documents enumerate the capabilities which are required to mitigate
mitigate the risk of these specific threats. the risk of these specific threats.
The intent is to address real-world threats to and attacks on network The intent is to address real-world threats to and attacks on network
infrastructure devices which have severely impacted network infrastructure devices which have severely impacted network
operations or have immediate potential to do so. The intent is NOT operations or have immediate potential to do so. The intent is NOT
to build a complete theoretical threat model or list every possible to build a complete theoretical threat model or list every possible
attack. attack.
The threats will be limited to those that affect the management of The threats are limited to those that affect the management of
network infrastructure and its ability to transit traffic. Threats network infrastructure and its ability to transit traffic. Threats
to the confidentiality and integrity of transit traffic will not be to the confidentiality and integrity of transit traffic are not
addressed. addressed.
1.3.2. Active, Passive and Combined Attacks 1.3.2. Active, Passive and Combined Attacks
[RFC3552] describes a general Internet threat model which readers of [RFC3552] describes a general Internet threat model which readers of
this document should be familiar with. It defines a threat model to this document should be familiar with. It defines a threat model to
describes the capabilities that an attacker is assumed to be able to describes the capabilities that an attacker is assumed to be able to
deploy against a resource. [RFC3552] classifies attacks into two deploy against a resource. [RFC3552] classifies attacks into two
main categories: passive attacks and active attacks. Passive attacks main categories: passive attacks and active attacks. Passive attacks
are ones where an attacker simply reads information off the network are ones where an attacker simply reads information off the network
skipping to change at page 6, line 15 skipping to change at page 7, line 15
1.3.4. Threat Sources 1.3.4. Threat Sources
The sources of threats in an operational network take many forms. The sources of threats in an operational network take many forms.
Some sources can be intentional, such as a malicious intruder Some sources can be intentional, such as a malicious intruder
actively gaining access to an unauthorized resource or causing a actively gaining access to an unauthorized resource or causing a
denial of service attack. Other sources can be unintentional but denial of service attack. Other sources can be unintentional but
still render the network unusable, such as software bugs or still render the network unusable, such as software bugs or
configuration mistakes. Many of the unintentional threat sources can configuration mistakes. Many of the unintentional threat sources can
be difficult to recognize or prevent. However wherever possible, be difficult to recognize or prevent. However wherever possible,
capabilities and functionality will be defined which minimize the capabilities and functionality is defined which minimizes the extent
extent of the damage done under these circumstances. of the damage done under these circumstances.
Threats can originate from outside or inside and can be due to Threats can originate from outside or inside and can be due to
vulnerabilities in a device or weaknesses in operational processes. vulnerabilities in a device or weaknesses in operational processes.
Inside threats pertain to an authorized participant in the operation Inside threats pertain to an authorized participant in the operation
of the network performing unauthorized actions. Outside threats of the network performing unauthorized actions. Outside threats
pertain to any unauthorized network devices or person causing havoc pertain to any unauthorized network devices or person causing havoc
with normal network operations. with normal network operations.
On Path network devices are able to read, modify, or remove any On Path network devices are able to read, modify, or remove any
datagram transmitted along a given path. Off-path hosts can transmit datagram transmitted along a given path. Off-path hosts can transmit
skipping to change at page 8, line 18 skipping to change at page 9, line 18
known and widely deployed. Malicious attackers therefore may be known and widely deployed. Malicious attackers therefore may be
familiar with the protocol software and be able to exploit known familiar with the protocol software and be able to exploit known
vulnerabilities. vulnerabilities.
1.4.7. Message Modification 1.4.7. Message Modification
In a message modification attack, the attacker removes a message from In a message modification attack, the attacker removes a message from
the wire, modifies it, and then resends it. The contents of the the wire, modifies it, and then resends it. The contents of the
message may be modified and/or the intended recipient. For example, message may be modified and/or the intended recipient. For example,
a hacker might try to modify a DNS response, in order to redirect a a hacker might try to modify a DNS response, in order to redirect a
client to the wrong server. [need example specific to network client to the wrong server.
operations where this would be harmful]
1.4.8. Message Deletion 1.4.8. Message Deletion
In a message deletion attack, the attacker simply removes a message In a message deletion attack, the attacker simply removes a message
from the wire. [need example specific to network operations where from the wire.
this is harmful]
1.4.9. Man-In-The-Middle 1.4.9. Man-In-The-Middle
A Man-In-The-Middle attack combines the above techniques in a special A Man-In-The-Middle attack combines the above techniques in a special
form: The attacker subverts the communication stream in order to pose form: The attacker subverts the communication stream in order to pose
as the sender to receiver and the receiver to the sender. This as the sender to receiver and the receiver to the sender. This
differs fundamentally from the above forms of attack because it differs fundamentally from the above forms of attack because it
attacks the identity of the communicating parties, rather than the attacks the identity of the communicating parties, rather than the
data stream itself. Consequently, many techniques which provide data stream itself. Consequently, many techniques which provide
integrity of the communications stream are insufficient to protect integrity of the communications stream are insufficient to protect
skipping to change at page 9, line 10 skipping to change at page 10, line 8
An invalid message attack refers to situations which can be either An invalid message attack refers to situations which can be either
deliberately invoked or are due to some non-malicious software or deliberately invoked or are due to some non-malicious software or
configuration error. This attack can be realized if vendors do not configuration error. This attack can be realized if vendors do not
conform to standards and send inappropriate control packets which can conform to standards and send inappropriate control packets which can
cause routing loops or neighboring routers to go down. Also, a cause routing loops or neighboring routers to go down. Also, a
malicious individual may launch DoS attacks which flood a device's malicious individual may launch DoS attacks which flood a device's
control plane with enough messages that the device becomes inoperable control plane with enough messages that the device becomes inoperable
due to resource starvation. due to resource starvation.
[Ed. - Need to review existing capabilities. Do the threats and
attack types listed above cover them all ? Are there capabilities
that imply threats and attack classes not listed above]
1.5. Scope 1.5. Scope
The working group will produce a list of capabilities appropriate The working group produced a lists of capabilities appropriate for:
for:
o Internet Service Provider (ISP) Networks o Internet Service Provider (ISP) Networks
o Enterprise Networks o Enterprise Networks
The following are explicitly out of scope: The following are explicitly out of scope:
o general purpose hosts that do not transit traffic including o general purpose hosts that do not transit traffic including
infrastructure hosts such as name/time/log/AAA servers, etc., infrastructure hosts such as name/time/log/AAA servers, etc.,
skipping to change at page 10, line 13 skipping to change at page 11, line 7
capabilities are general enough to apply to IPv6. capabilities are general enough to apply to IPv6.
1.6. Intended Audience 1.6. Intended Audience
There are two intended audiences: the network operator who selects, There are two intended audiences: the network operator who selects,
purchases, and operates IP network equipment, and the vendors who purchases, and operates IP network equipment, and the vendors who
create these devices. create these devices.
1.7. Format and Definition of Capabilities 1.7. Format and Definition of Capabilities
A separate document will be created for specific categories of Separate documents were created for specific categories of
capabilities. Each individual capability will have the following capabilities. Each individual capability has the following elements:
elements:
Capability (what) Capability (what)
The capability describes a policy to be supported by the device. The capability describes a policy to be supported by the device.
Capabilities are described in terms of "The device is able to...". Capabilities are described in terms of "The device is able to...".
Capability descriptions do not use [RFC2119] keywords, e.g. they Capability descriptions do not use [RFC2119] keywords, e.g. they
are not phrased as "The device MUST...". are not phrased as "The device MUST...".
Capabilities should not refer to specific technologies. It is Capabilities should not refer to specific technologies. It is
expected that desired capability will change little over time. expected that desired capability will change little over time.
skipping to change at page 11, line 44 skipping to change at page 12, line 37
requirements, requirements,
o as high level guidance for the creation of detailed test plans. o as high level guidance for the creation of detailed test plans.
o as guidance for vendors to make appropriate decisions for o as guidance for vendors to make appropriate decisions for
engineering feature roadmaps. engineering feature roadmaps.
1.10. Definitions 1.10. Definitions
NOTE: The following definitions are take from RFC3871. Unless NOTE: The following definitions are take from RFC3871. Unless
otherwise stated, the working group documents will use these terms as otherwise stated, the working group documents use these terms as
defined below. defined below.
Bogon. Bogon.
A "Bogon" (plural: "bogons") is a packet with an IP source address A "Bogon" (plural: "bogons") is a packet with an IP source address
in an address block not yet allocated by IANA or the Regional in an address block not yet allocated by IANA or the Regional
Internet Registries (ARIN, RIPE, APNIC...) as well as all Internet Registries (ARIN, RIPE, APNIC...) as well as all
addresses reserved for private or special use by RFCs. See addresses reserved for private or special use by RFCs. See
[RFC3330] and [RFC1918]. [RFC3330] and [RFC1918].
skipping to change at page 14, line 25 skipping to change at page 15, line 20
A condition where resources necessary for communication and proper A condition where resources necessary for communication and proper
functioning of a network element are unavailable. Such resources functioning of a network element are unavailable. Such resources
might include Bandwidth of a link, memory of a routing device, or might include Bandwidth of a link, memory of a routing device, or
CPU time on a routing processor. CPU time on a routing processor.
Secure Channel. Secure Channel.
A "secure channel" is a mechanism that ensures end-to-end A "secure channel" is a mechanism that ensures end-to-end
integrity and confidentiality of communications. Examples include integrity and confidentiality of communications. Examples include
TLS [RFC2246] and IPsec [RFC2401]. Connecting a terminal to a TLS [RFC4346] and IPsec [RFC4301]. Connecting a terminal to a
console port using physically secure, shielded cable would provide console port using physically secure, shielded cable would provide
confidentiality but possibly not integrity. confidentiality but possibly not integrity.
Service. Service.
A number of capabilities refer to "services". For the purposes of A number of capabilities refer to "services". For the purposes of
this document a "service" is defined as "any process or protocol this document a "service" is defined as "any process or protocol
running in the control or management planes to which non-transit running in the control or management planes to which non-transit
packets may be delivered". Examples might include an SSH server, packets may be delivered". Examples might include an SSH server,
a BGP process or an NTP server. It would also include the a BGP process or an NTP server. It would also include the
skipping to change at page 16, line 7 skipping to change at page 17, line 7
(authorization). (authorization).
* There is a record of all security related events * There is a record of all security related events
(accountability). (accountability).
* The network operator has the necessary tools to detect and * The network operator has the necessary tools to detect and
respond to illegitimate traffic. respond to illegitimate traffic.
2. Documents 2. Documents
The following describes the types of documents to be produced by the The following describes the documents produced by the OPSEC working
OPSEC working group. Each document is intended to cover an area group. Each document covers an area important to secure operation of
important to secure operation of large network infrastructure. See large network infrastructure.
the working group charter for a complete list of individual
documents.
2.1. Framework Document 2.1. Framework Document
Overview
This document. This document.
2.2. Operator Practices Survey 2.2. Operator Practices Survey
Overview [RFC4778].
This document provides a survey of current operator practices in This document provides a survey of current operator practices in the
the area of securing networks. It lists current practices that area of securing networks. It lists current practices that are cited
will be cited as justification for capabilities. It defines a as justification for capabilities. It defines a general threat model
general threat model and classes of attacks. and classes of attacks.
2.3. Standards Survey 2.3. Standards Survey
Overview [I-D.ietf-opsec-efforts].
This document provides an overview of other efforts in developing This document provides an overview of other efforts in developing
standards, guidelines, best practices, or other information standards, guidelines, best practices, or other information intended
intended to facilitate improvement in network security. Any to facilitate improvement in network security. Any effort which is
effort which is known, such as the ANSI T1.276, the NRIC V "Best known, such as the ANSI T1.276, the NRIC V "Best Practices", ITU-T
Practices", ITU-T M.3016 and X.805, the T1S1 effort on securing M.3016 and X.805, the T1S1 effort on securing signaling will be
signaling will be included. The intent is to provide a clear included. The intent is to provide a clear understanding of which
understanding of which efforts are complementary and/or efforts are complementary and/or contradictory such that any efforts
contradictory such that any efforts of future cross-certification of future cross-certification of standards may be facilitated.
of standards may be facilitated.
2.4. Capabilities Documents 2.4. Capabilities Documents
Overview [I-D.ietf-opsec-filter-caps],
[I-D.ietf-opsec-logging-caps],
[I-D.ietf-opsec-routing-capabilities].
Capability documents list capabilities needed to support security Capability documents list capabilities needed to support security
practices. Each capability document lists capabilities of one practices. Each capability document lists capabilities of one
logical group of functions (e.g. logging, filtering, etc.). They logical group of functions (e.g. logging, filtering, etc.). They
define a threat model, list individual capabilities, cite define a threat model, list individual capabilities, cite practices
practices supported in the Operator Practices Survey and in few supported in the Operator Practices Survey and in few cases may
cases may define additional practices. define additional practices.
2.5. Profile Documents 2.5. Profile Documents
Overview Profile documents are intended to list capabilities appropriate to
different operating environments such as large Network Service
Provider (NSP) core or edge devices or enterprise networks.
Profile documents list capabilities appropriate to different Appendix B provides guidance to organizations in creating their own
operating environments such as large Network Service Provider profiles.
(NSP) core or edge devices or enterprise networks. These profiles
MAY provide a good starting point for organizations to generate
their own list of requirements.
3. Security Considerations 3. Security Considerations
Security is the entire focus of this document. Security is the entire focus of this document.
4. IANA Considerations 4. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
5. Non-Normative References 5. Acknowledgments
The authors gratefully acknowledge the contributions of:
o Pat Cain who agitated for inclusion of the profile guide.
6. Non-Normative References
[I-D.ietf-opsec-efforts]
Lonvick, C. and D. Spak, "Security Best Practices Efforts
and Documents", draft-ietf-opsec-efforts-05 (work in
progress), December 2006.
[I-D.ietf-opsec-filter-caps]
Morrow, C., "Filtering and Rate Limiting Capabilities for
IP Network Infrastructure",
draft-ietf-opsec-filter-caps-05 (work in progress),
March 2007.
[I-D.ietf-opsec-logging-caps]
Cain, P. and G. Jones, "Logging Capabilities for IP
Network Infrastructure", draft-ietf-opsec-logging-caps-02
(work in progress), March 2007.
[I-D.ietf-opsec-routing-capabilities]
Zhao, Y., "Routing Control Plane Security Capabilities",
draft-ietf-opsec-routing-capabilities-01 (work in
progress), February 2007.
[RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms", [RFC1208] Jacobsen, O. and D. Lynch, "Glossary of networking terms",
RFC 1208, March 1991. RFC 1208, March 1991.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2196] Fraser, B., "Site Security Handbook", RFC 2196, [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196,
September 1997. September 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330,
September 2002. September 2002.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
July 2003. July 2003.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[RFC3871] Jones, G., "Operational Security Requirements for Large [RFC3871] Jones, G., "Operational Security Requirements for Large
Internet Service Provider (ISP) IP Network Internet Service Provider (ISP) IP Network
Infrastructure", RFC 3871, September 2004. Infrastructure", RFC 3871, September 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4778] Kaeo, M., "Operational Security Current Practices in [RFC4778] Kaeo, M., "Operational Security Current Practices in
Internet Service Provider Environments", RFC 4778, Internet Service Provider Environments", RFC 4778,
January 2007. January 2007.
Appendix A. Sample Capability Description Appendix A. Sample Capability Description
This appendix provides a sample capability description. Note the This appendix provides a sample capability description. Note the
lack of the use of "MUST", etc in the description of the capability. lack of the use of "MUST", etc in the description of the capability.
Also note that in the supported practices section it refers both to Also note that in the supported practices section it refers both to
the current practices document [RFC4778] and to sections of the same the current practices document [RFC4778] and to sections of the same
skipping to change at page 22, line 5 skipping to change at page 25, line 5
Many devices currently implement access control lists or filters Many devices currently implement access control lists or filters
that allow filtering based on protocol and/or source/destination that allow filtering based on protocol and/or source/destination
address and or source/destination port and allow these filters to address and or source/destination port and allow these filters to
be applied to interfaces. be applied to interfaces.
Considerations. Considerations.
None. None.
Appendix B. Guide to writing profiles
B.1. Introduction
This section provides guidelines for creating security capability
profiles. A profile is a list of features that are required to
operate a device in a a secure manner in a specific environment.
The determination of which capabilities are requirements is a local
decision driven by policy and operational need. In addition, the
needed capabilities are likely to change over time as operational
requirements and security threats change. Profile writes are
encouraged to share their output with the broader Internet community
to learn from others experiences.
It is likely that there are or will be other sources of capabilities
that could be cited in developing a profile. For example,
[I-D.ietf-opsec-efforts] could be used to identify industry-specific
standards or regulations that a specific network would need to
support.
B.2. Guidance
Profiles should:
o Be uniquely named
o Contain a brief description of the profile
o Describe the context/environment to which they apply
o Reference capabilities defined in appropriate documents. It is
assumed that referenced capabilities contain the elements outlined
in Section 1.7 and Appendix A, i.e. that there is no need for a
detailed description of the capability, justification, etc. in the
profile. If referencing documents that do not contain such
information, it might have to be included in the profile.
o Be broken down into functional sections (logging, filtering...)
o Indicate level of need for each capability ("required",
"recommended"...) in the defined context (NOT in the [RFC2119]
sense).
B.3. Sample Profile
The following is an incomplete sample of a profile for edge routers:
B.3.1. Required Capabilities for Edge Routers
Name: Edge Router Profile
Description: This profile defines the capabilities necessary for a
network edge device
Context: Large NSP/ISP network providing transit services.
The following are requirements for edge routers:
B.3.1.1. Packet Filtering Profile
o Select by Protocol, [I-D.ietf-opsec-filter-caps] Section 3.5
o Select by Addresses, [I-D.ietf-opsec-filter-caps] Section 3.6
o Select by Protocol Header Fields, [I-D.ietf-opsec-filter-caps]
Section 3.7
.
.
.
B.3.1.2. Logging
o Logs Sent To Remote Servers, [I-D.ietf-opsec-logging-caps] Section
2.2
o Ability to Select Reliable Delivery, [I-D.ietf-opsec-logging-caps]
Section 2.3
o Ability to Remotely Log Securely, [I-D.ietf-opsec-logging-caps]
Section 2.4
o Ability to Log Locally, [I-D.ietf-opsec-logging-caps] Section 2.5
.
.
.
B.3.2. Recommended Capabilities for Edge Routers
The following are desired capabilities for edge routers:
B.3.2.1. Packet Filtering Profile
o Minimal Performance Degradation, [I-D.ietf-opsec-filter-caps]
Section 6
.
.
.
Authors' Addresses Authors' Addresses
George M. Jones George M. Jones
Phone: +1 703 488 9740 Phone: +1 703 488 9740
Email: gmj3871@pobox.com Email: gmj3871@pobox.com
Ross Callon Ross Callon
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
 End of changes. 35 change blocks. 
118 lines changed or deleted 243 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/