draft-ietf-opsec-framework-00.txt   draft-ietf-opsec-framework-01.txt 
OPSEC Working Group G. Jones OPSEC Working Group G. Jones
Internet-Draft The MITRE Corporation Internet-Draft The MITRE Corporation
Expires: April 21, 2005 R. Callon Expires: April 20, 2006 R. Callon
Juniper Networks Juniper Networks
M. Kaeo M. Kaeo
Double Shot Security Double Shot Security
October 21, 2004 October 17, 2005
Framework for Operational Security Capabilities for IP Network Framework for Operational Security Capabilities for IP Network
Infrastructure Infrastructure
draft-ietf-opsec-framework-00 draft-ietf-opsec-framework-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 April 21, 2005. This Internet-Draft will expire on April 20, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document outlines work to be done and documents to be produced This document outlines work to be done and documents to be produced
by the Operational Security Capabilities (OPSEC) Working Group. The by the Operational Security Capabilities (OPSEC) Working Group. The
goal of the working group is to codify knowledge gained through goal of the working group is to codify knowledge gained through
operational experience about feature sets that are needed to securely operational experience about feature sets that are needed to securely
deploy and operate managed network elements providing transit deploy and operate managed network elements providing transit
services at the data link and IP layers. The intent is to provide services at the data link and IP layers. The intent is to provide
clear, concise documentation of capabilities necessary for operating clear, concise documentation of capabilities necessary for operating
networks securely, to assist network operators in communicating their networks securely, to assist network operators in communicating their
requirements to vendors, and to provide vendors with input that is requirements to vendors, and to provide vendors with input that is
useful for building more secure devices. The working group will useful for building more secure devices. The working group will
produce a list of capabilities appropriate for large Internet Service produce a list of capabilities appropriate for large Internet Service
Provider (ISP) and Enterprise Networks. This work is intended to Provider (ISP) and Enterprise Networks. This work is intended to
refine [RFC3871]. refine [RFC3871].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Threats Addressed, Threats Not Addressed . . . . . . . 4 1.3.1. Threats Addressed, Threats Not Addressed . . . . . . . 4
1.3.2 Active, Passive and Combined Attacks . . . . . . . . . 5 1.3.2. Active, Passive and Combined Attacks . . . . . . . . . 5
1.3.3 Categories of Threats . . . . . . . . . . . . . . . . 5 1.3.3. Categories of Threats . . . . . . . . . . . . . . . . 5
1.3.4 Threat Sources . . . . . . . . . . . . . . . . . . . . 6 1.3.4. Threat Sources . . . . . . . . . . . . . . . . . . . . 6
1.4 Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.1 Passive attacks . . . . . . . . . . . . . . . . . . . 6 1.4.1. Passive attacks . . . . . . . . . . . . . . . . . . . 6
1.4.2 Eavesdropping/Sniffing . . . . . . . . . . . . . . . . 6 1.4.2. Eavesdropping/Sniffing . . . . . . . . . . . . . . . . 6
1.4.3 Off-line Cryptographic Attacks . . . . . . . . . . . . 7 1.4.3. Off-line Cryptographic Attacks . . . . . . . . . . . . 7
1.4.4 Active Attacks . . . . . . . . . . . . . . . . . . . . 7 1.4.4. Active Attacks . . . . . . . . . . . . . . . . . . . . 7
1.4.5 Replay Attacks . . . . . . . . . . . . . . . . . . . . 7 1.4.5. Replay Attacks . . . . . . . . . . . . . . . . . . . . 7
1.4.6 Message Insertion . . . . . . . . . . . . . . . . . . 7 1.4.6. Message Insertion . . . . . . . . . . . . . . . . . . 7
1.4.7 Message Modification . . . . . . . . . . . . . . . . . 8 1.4.7. Message Modification . . . . . . . . . . . . . . . . . 8
1.4.8 Message Deletion . . . . . . . . . . . . . . . . . . . 8 1.4.8. Message Deletion . . . . . . . . . . . . . . . . . . . 8
1.4.9 Man-In-The-Middle . . . . . . . . . . . . . . . . . . 8 1.4.9. Man-In-The-Middle . . . . . . . . . . . . . . . . . . 8
1.5 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.4.10. Invalid Message . . . . . . . . . . . . . . . . . . . 8
1.6 Intended Audience . . . . . . . . . . . . . . . . . . . . 9 1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.7 Format and Definition of Capabilities . . . . . . . . . . 9 1.6. Intended Audience . . . . . . . . . . . . . . . . . . . . 9
1.8 Applicability . . . . . . . . . . . . . . . . . . . . . . 10 1.7. Format and Definition of Capabilities . . . . . . . . . . 10
1.9 Intended Use . . . . . . . . . . . . . . . . . . . . . . . 10 1.8. Applicability . . . . . . . . . . . . . . . . . . . . . . 11
1.10 Definitions . . . . . . . . . . . . . . . . . . . . . . . 11 1.9. Intended Use . . . . . . . . . . . . . . . . . . . . . . . 11
2. Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.10. Definitions . . . . . . . . . . . . . . . . . . . . . . . 11
2.1 Framework Document . . . . . . . . . . . . . . . . . . . . 14 2. Documents . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Operator Practices Survey . . . . . . . . . . . . . . . . 14 2.1. Framework Document . . . . . . . . . . . . . . . . . . . . 17
2.3 Standards Survey . . . . . . . . . . . . . . . . . . . . . 14 2.2. Operator Practices Survey . . . . . . . . . . . . . . . . 17
2.4 Capabilities Documents . . . . . . . . . . . . . . . . . . 14 2.3. Standards Survey . . . . . . . . . . . . . . . . . . . . . 17
2.5 Profile Documents . . . . . . . . . . . . . . . . . . . . 14 2.4. Capabilities Documents . . . . . . . . . . . . . . . . . . 17
2.6 Deliberations Document . . . . . . . . . . . . . . . . . . 15 2.5. Profile Documents . . . . . . . . . . . . . . . . . . . . 18
3. Security Considerations . . . . . . . . . . . . . . . . . . . 16 2.6. Deliberations Document . . . . . . . . . . . . . . . . . . 18
4. Normative References . . . . . . . . . . . . . . . . . . . . . 16 3. Security Considerations . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 4. Normative References . . . . . . . . . . . . . . . . . . . . . 19
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
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 to be done
by the working group, and describes the documents to be produced in by the working group, and describes the documents to be 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 will be discussed
in the documents which are referred to in this framework. Each of in the documents which are referred to in this framework. Each of
those documents will enumerate the capabilities which are required to those documents will enumerate the capabilities which are required to
mitigate the risk of these specific threats. mitigate 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 will be 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 will not be
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
and obtains confidential and/or private information which can be used and obtains confidential and/or private information which can be used
to compromise network systems. Active attacks are ones where the to compromise network systems. Active attacks are ones where the
attacker writes data to the network and can include replay attacks, attacker writes data to the network and can include replay attacks,
message insertion, message deletion, message modification and message insertion, message deletion, message modification and man-in-
man-in-the-middle attacks. Often, these passive and active attacks the-middle attacks. Often, these passive and active attacks are
are combined. For example, routing information is diverted via a combined. For example, routing information is diverted via a man-in-
man-in-the-middle attack to force confidential information to transit the-middle attack to force confidential information to transit a
a network path on which the attacker is able to perform network path on which the attacker is able to perform eavesdropping.
eavesdropping.
1.3.3 Categories of Threats 1.3.3. Categories of Threats
The following sections provide a model that can be used to further The following sections provide a model that can be used to further
categorize attacks on infrastructure devices and/or the operating categorize attacks on infrastructure devices and/or the operating
behavior of these devices, and also gives some examples of attacks behavior of these devices, and also gives some examples of attacks
which fall into each classification. which fall into each classification.
It is common to categorize threats based on the effects or damage It is common to categorize threats based on the effects or damage
caused by associated attacks. For example, threats generally fall caused by associated attacks. For example, threats generally fall
under one of the three categories as defined in [RFC2196]: under one of the three categories as defined in [RFC2196]:
skipping to change at page 6, line 5 skipping to change at page 6, line 6
categorizing threats based on the result of the threat therefore categorizing threats based on the result of the threat therefore
results in categories which are orthogonal to the cause of the results in categories which are orthogonal to the cause of the
effect, and thus orthogonal to the device capabilities which are effect, and thus orthogonal to the device capabilities which are
needed. needed.
Categorization of attacks based on the capabilities required to mount Categorization of attacks based on the capabilities required to mount
the attack will allow the analysis and description of the attacks to the attack will allow the analysis and description of the attacks to
be more closely aligned with the product capabilities required to be more closely aligned with the product capabilities required to
defeat or mitigate the attack. defeat or mitigate the attack.
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 will be defined which minimize the
extent of the damage done under these circumstances. extent of the damage done under these circumstances.
skipping to change at page 6, line 29 skipping to change at page 6, line 30
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
arbitrary datagrams that appear to come from any hosts but cannot arbitrary datagrams that appear to come from any hosts but cannot
necessarily receive datagrams intended for other hosts. necessarily receive datagrams intended for other hosts.
1.4 Attacks 1.4. Attacks
This section specifies attack categories based on the capabilities This section specifies attack categories based on the capabilities
required to mount the attack and provides more granular detail of required to mount the attack and provides more granular detail of
many of the identifiable and recognized threats to which network many of the identifiable and recognized threats to which network
infrastructure devices are susceptible. infrastructure devices are susceptible.
1.4.1 Passive attacks 1.4.1. Passive attacks
Passive attacks are ones where an attacker simply reads information Passive attacks are ones where an attacker simply reads information
off the network and obtains confidential and/or private information off the network and obtains confidential and/or private information
which can be used to compromise network systems. which can be used to compromise network systems.
1.4.2 Eavesdropping/Sniffing 1.4.2. Eavesdropping/Sniffing
The most common form of passive attack is eavesdropping, where the The most common form of passive attack is eavesdropping, where the
attacker is able to read the data which is being transmitted from the attacker is able to read the data which is being transmitted from the
sender to the receiver. In any operational network, the entire data sender to the receiver. In any operational network, the entire data
path and every device involved in the data path must be considered path and every device involved in the data path must be considered
for this type of attack. Any information which could be used to for this type of attack. Any information which could be used to
potentially gain unauthorized access to a device or is private must potentially gain unauthorized access to a device or is private must
be protected. This includes passwords, configuration files and log be protected. This includes passwords, configuration files and log
files. It is common to think only of protecting the data path and to files. It is common to think only of protecting the data path and to
make sure that data is not diverted along a different path which may make sure that data is not diverted along a different path which may
be easier to eavesdrop on, such as a wireless network. In many be easier to eavesdrop on, such as a wireless network. In many
instances it would be wise to consider cryptographically protecting instances it would be wise to consider cryptographically protecting
data confidentiality wherever sensitive information is involved. data confidentiality wherever sensitive information is involved.
1.4.3 Off-line Cryptographic Attacks 1.4.3. Off-line Cryptographic Attacks
These attacks typically capture some data which has been These attacks typically capture some data which has been
cryptographically protected and then use varying means to try and cryptographically protected and then use varying means to try and
recover the original data. Poor password protection protocols can recover the original data. Poor password protection protocols can
easily be reverse engineered and poorly chosen passwords can also be easily be reverse engineered and poorly chosen passwords can also be
easily deciphered. As described in [RFC3552], a number of popular easily deciphered. As described in [RFC3552], a number of popular
password-based challenge response protocols are vulnerable to a password-based challenge response protocols are vulnerable to a
dictionary attack. The attacker captures a challenge-response pair dictionary attack. The attacker captures a challenge-response pair
and then proceeds to try entries from a list of common words (such as and then proceeds to try entries from a list of common words (such as
a dictionary file) until he finds a password that produces the right a dictionary file) until he finds a password that produces the right
response. response.
1.4.4 Active Attacks 1.4.4. Active Attacks
Active attacks are ones where the attacker writes data to the Active attacks are ones where the attacker writes data to the
network. Generally, any part of a data packet can be forged. When network. Generally, any part of a data packet can be forged. When
the source IP address is forged, the attack is generally referred to the source IP address is forged, the attack is generally referred to
as a spoofing attack. These attacks can be mitigated by filtering as a spoofing attack. These attacks can be mitigated by filtering
traffic based on IP addresses to only allow legitimate traffic traffic based on IP addresses to only allow legitimate traffic to/
to/from a network. from a network.
Not all active attacks require forged addresses and most systems are Not all active attacks require forged addresses and most systems are
susceptible to a number of common attack patterns which are described susceptible to a number of common attack patterns which are described
in the next sections. Note that any type of active attack can be in the next sections. Note that any type of active attack can be
used for Denial of Service if the traffic is sent at such a rate that used for Denial of Service if the traffic is sent at such a rate that
it exceeds a networks link capacity or exhausts device resources. it exceeds a networks link capacity or exhausts device resources.
1.4.5 Replay Attacks 1.4.5. Replay Attacks
A replay attack is a combination of a passive and an active attack. A replay attack is a combination of a passive and an active attack.
In this type of attack, the attacker records some number of messages In this type of attack, the attacker records some number of messages
off of the wire and then plays them back to the original recipient. off of the wire and then plays them back to the original recipient.
Note that the attacker does not need to be able to understand the Note that the attacker does not need to be able to understand the
messages. He merely needs to capture and re-transmit them. messages. He merely needs to capture and re-transmit them.
1.4.6 Message Insertion 1.4.6. Message Insertion
In a message insertion attack, the attacker forges one or more In a message insertion attack, the attacker forges one or more
messages and injects them into the network. Often these messages messages and injects them into the network. Often these messages
will have a forged source address in order to disguise the identity will have a forged source address in order to disguise the identity
of the attacker. of the attacker.
Message insertion attacks can be used to exploit known Message insertion attacks can be used to exploit known
vulnerabilities in protocol software. Routers and switches implement vulnerabilities in protocol software. Routers and switches implement
protocols which in some cases make use of software which is well protocols which in some cases make use of software which is well
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. [need example message may be modified and/or the intended recipient. [need example
specific to network operations where this would be harmful] specific to network 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. [need example specific to network operations where
this is harmful] 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
against man-in-the-middle attacks. against man-in-the-middle attacks.
Man-in-the-middle attacks are possible whenever peer entity Man-in-the-middle attacks are possible whenever peer entity
authentication is not used. For example, it is trivial to mount authentication is not used. For example, it is trivial to mount man-
man-in-the-middle attacks on local networks via ARP spoofing where in-the-middle attacks on local networks via ARP spoofing where the
the attacker forges an ARP with the victim's IP address and his own attacker forges an ARP with the victim's IP address and his own MAC
MAC address to gain access to a network. The attacker can then do address to gain access to a network. The attacker can then do
further damage by sending forged messages. Imagine if the victim^Ós further damage by sending forged messages. Imagine if the victim^Os
IP address was that of a TFTP server. The attacker could potentially IP address was that of a TFTP server. The attacker could potentially
download invalid system images or configuration files to a network download invalid system images or configuration files to a network
device and subsequently compromise that network device. device and subsequently compromise that network device.
1.4.10. Invalid Message
An invalid message attack refers to situations which can be either
deliberately invoked or are due to some non-malicious software or
configuration error. This attack can be realized if vendors do not
conform to standards and send inappropriate control packets which can
cause routing loops or neighboring routers to go down. Also, a
malicious individual may launch DoS attacks which flood a device's
control plane with enough messages that the device becomes inoperable
due to resource starvation.
[Ed. - Need to review existing capabilities. Do the threats and [Ed. - Need to review existing capabilities. Do the threats and
attack types listed above cover them all ? Are there capabilities attack types listed above cover them all ? Are there capabilities
that imply threats and attack classes not listed above] 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 will produce a list 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.,
o unmanaged devices, o unmanaged devices,
o customer managed devices (e.g. firewalls, Intrusion Detection o customer managed devices (e.g. firewalls, Intrusion Detection
System, dedicated VPN devices, etc.), System, dedicated VPN devices, etc.),
o SOHO (Small Office, Home Office) devices (e.g. personal
firewalls, Wireless Access Points, Cable Modems, etc.), o SOHO (Small Office, Home Office) devices (e.g. personal firewalls,
Wireless Access Points, Cable Modems, etc.),
o confidentiality of customer data, o confidentiality of customer data,
o integrity of customer data, o integrity of customer data,
o physical security. o physical security.
These limitations have been made to keep the amount of work and size These limitations have been made to keep the amount of work and size
of documents manageable. While the capabilities listed here may of documents manageable. While the capabilities listed here may
apply to systems outside the scope, no capabilities have been added apply to systems outside the scope, no capabilities have been added
to account for their unique needs. to account for their unique needs.
While the examples given are written with IPv4 in mind, most of the While the examples given are written with IPv4 in mind, most of the
capabilities are general enough to apply to IPv6. capabilities are general enough to apply to IPv6.
skipping to change at page 9, line 29 skipping to change at page 9, line 48
o physical security. o physical security.
These limitations have been made to keep the amount of work and size These limitations have been made to keep the amount of work and size
of documents manageable. While the capabilities listed here may of documents manageable. While the capabilities listed here may
apply to systems outside the scope, no capabilities have been added apply to systems outside the scope, no capabilities have been added
to account for their unique needs. to account for their unique needs.
While the examples given are written with IPv4 in mind, most of the While the examples given are written with IPv4 in mind, most of the
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 A separate document will be created for specific categories of
capabilities. Each individual capability will have the following capabilities. Each individual capability will have 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 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.
Supported Practices (why) Supported Practices (why)
The Supported Practice section cites practices described in
CITE-OPERATOR-SURVEY-RFC that are supported by this capability. The Supported Practice section cites practices described in CITE-
The need to support the cited practices provides the justification OPERATOR-SURVEY-RFC that are supported by this capability. The
for the feature. need to support the cited practices provides the justification for
the feature.
In a few cases, practices not listed in CITE-OPERATOR-SURVEY-RFC In a few cases, practices not listed in CITE-OPERATOR-SURVEY-RFC
may be listed at the end of the capability document and cited as may be listed at the end of the capability document and cited as
justification for a capability. This may be necessary if a justification for a capability. This may be necessary if a
practice becomes common after CITE-OPERATOR-SURVEY-RFC is finished practice becomes common after CITE-OPERATOR-SURVEY-RFC is finished
or if there is widespread consensus that the practice would or if there is widespread consensus that the practice would
improve security but it is not, for whatever reason, in widespread improve security but it is not, for whatever reason, in widespread
deployment. deployment.
Current Implementations (how) Current Implementations (how)
skipping to change at page 10, line 14 skipping to change at page 10, line 35
In a few cases, practices not listed in CITE-OPERATOR-SURVEY-RFC In a few cases, practices not listed in CITE-OPERATOR-SURVEY-RFC
may be listed at the end of the capability document and cited as may be listed at the end of the capability document and cited as
justification for a capability. This may be necessary if a justification for a capability. This may be necessary if a
practice becomes common after CITE-OPERATOR-SURVEY-RFC is finished practice becomes common after CITE-OPERATOR-SURVEY-RFC is finished
or if there is widespread consensus that the practice would or if there is widespread consensus that the practice would
improve security but it is not, for whatever reason, in widespread improve security but it is not, for whatever reason, in widespread
deployment. deployment.
Current Implementations (how) Current Implementations (how)
The Current Implementation section is intended to give examples of The Current Implementation section is intended to give examples of
implementations of the capability, citing technology and standards implementations of the capability, citing technology and standards
current at the time of writing. Examples of configuration and current at the time of writing. Examples of configuration and
usage may also be given. usage may also be given.
Considerations Considerations
The Considerations section lists operational and resource The Considerations section lists operational and resource
constraints, limitations of current implementations, tradeoffs, constraints, limitations of current implementations, tradeoffs,
etc. etc.
1.8 Applicability 1.8. Applicability
These capabilities are intended to give guidance on how best to These capabilities are intended to give guidance on how best to
protect communications infrastructure. Service Providers, Network protect communications infrastructure. Service Providers, Network
Operators, and Equipment Suppliers are encouraged to study these Operators, and Equipment Suppliers are encouraged to study these
capabilities, and prioritize the extent and manner in which they may capabilities, and prioritize the extent and manner in which they may
implement and/or deploy equipment supporting these capabilities. implement and/or deploy equipment supporting these capabilities.
Decisions of whether or not to support a specific capabilities are Decisions of whether or not to support a specific capabilities are
intended to be left with the responsible organization (e.g., Service intended to be left with the responsible organization (e.g., Service
Provider, Network Operator, or Equipment Supplier). Due to the Provider, Network Operator, or Equipment Supplier). Due to the
continuously evolving nature of security threats to networks, and due continuously evolving nature of security threats to networks, and due
to significant variations in the specific security threats and to significant variations in the specific security threats and
requirements in different network environments, it is not appropriate requirements in different network environments, it is not appropriate
to mandate implementation of these capabilities through legislation to mandate implementation of these capabilities through legislation
or regulation, nor would any mandate be consistent with their intent. or regulation, nor would any mandate be consistent with their intent.
1.9 Intended Use 1.9. Intended Use
It is anticipated that the capabilities in these documents will be It is anticipated that the capabilities in these documents will be
used for the following purposes: used for the following purposes:
o as a checklist when evaluating networked products, o as a checklist when evaluating networked products,
o to create profiles of different subsets of the capabilities which o to create profiles of different subsets of the capabilities which
describe the needs of different devices, organizations, and describe the needs of different devices, organizations, and
operating environments, operating environments,
o to assist operators in clearly communicating their security o to assist operators in clearly communicating their security
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
RFC 2119 Keywords RFC 2119 Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in [RFC2119]. in this document are to be interpreted as described in [RFC2119].
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 will 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].
CLI. CLI.
Several capabilities refer to a Command Line Interface (CLI). Several capabilities refer to a Command Line Interface (CLI).
While this refers at present to a classic text oriented command While this refers at present to a classic text oriented command
interface, it is not intended to preclude other mechanisms which interface, it is not intended to preclude other mechanisms which
may provide all the capabilities that reference "CLI". may provide all the capabilities that reference "CLI".
Conformance.
Adherence to proposed standards.
Console. Console.
Several capabilities refer to a "Console". The model for this is Several capabilities refer to a "Console". The model for this is
the classic RS232 serial port which has, for the past 30 or more the classic RS232 serial port which has, for the past 30 or more
years, provided a simple, stable, reliable, well-understood and years, provided a simple, stable, reliable, well-understood and
nearly ubiquitous management interface to network devices. Again, nearly ubiquitous management interface to network devices. Again,
these capabilities are intended primarily to codify the benefits these capabilities are intended primarily to codify the benefits
provided by that venerable interface, not to preclude other provided by that venerable interface, not to preclude other
mechanisms that provide the same capabilities. mechanisms that provide the same capabilities.
Filter. Filter.
In this document, a "filter" is defined as a group of one or more In this document, a "filter" is defined as a group of one or more
rules where each rule specifies one or more match criteria. rules where each rule specifies one or more match criteria.
In-Band management. In-Band management.
"In-Band management" is defined as any management done over the "In-Band management" is defined as any management done over the
same channels and interfaces used for user/customer data. same channels and interfaces used for user/customer data.
Examples would include using SSH for management via customer or Examples would include using SSH for management via customer or
Internet facing network interfaces. Internet facing network interfaces.
High Resolution Time. High Resolution Time.
"High resolution time" is defined in this document as "time having "High resolution time" is defined in this document as "time having
a resolution greater than one second" (e.g. milliseconds). a resolution greater than one second" (e.g. milliseconds).
IP. IP.
Unless otherwise indicated, "IP" refers to IPv4. Unless otherwise indicated, "IP" refers to IPv4.
Management. Management.
This document uses a broad definition of the term "management". This document uses a broad definition of the term "management".
In this document, "management" refers to any authorized In this document, "management" refers to any authorized
interaction with the device intended to change its operational interaction with the device intended to change its operational
state or configuration. Data/Forwarding plane functions (e.g. state or configuration. Data/Forwarding plane functions (e.g. the
the transit of customer traffic) are not considered management. transit of customer traffic) are not considered management.
Control plane functions such as routing, signaling and link Control plane functions such as routing, signaling and link
management protocols and management plane functions such as remote management protocols and management plane functions such as remote
access, configuration and authentication are considered to be access, configuration and authentication are considered to be
management. management.
Martian. Martian.
Per [RFC1208] "Martian: Humorous term applied to packets that turn Per [RFC1208] "Martian: Humorous term applied to packets that turn
up unexpectedly on the wrong network because of bogus routing up unexpectedly on the wrong network because of bogus routing
entries. Also used as a name for a packet which has an altogether entries. Also used as a name for a packet which has an altogether
bogus (non-registered or ill-formed) Internet address." For the bogus (non-registered or ill-formed) Internet address." For the
purposes of this document Martians are defined as "packets having purposes of this document Martians are defined as "packets having
a source address that, by application of the current forwarding a source address that, by application of the current forwarding
tables, would not have its return traffic routed back to the tables, would not have its return traffic routed back to the
sender." "Spoofed packets" are a common source of martians. sender." "Spoofed packets" are a common source of martians.
skipping to change at page 12, line 25 skipping to change at page 14, line 4
Martian. Martian.
Per [RFC1208] "Martian: Humorous term applied to packets that turn Per [RFC1208] "Martian: Humorous term applied to packets that turn
up unexpectedly on the wrong network because of bogus routing up unexpectedly on the wrong network because of bogus routing
entries. Also used as a name for a packet which has an altogether entries. Also used as a name for a packet which has an altogether
bogus (non-registered or ill-formed) Internet address." For the bogus (non-registered or ill-formed) Internet address." For the
purposes of this document Martians are defined as "packets having purposes of this document Martians are defined as "packets having
a source address that, by application of the current forwarding a source address that, by application of the current forwarding
tables, would not have its return traffic routed back to the tables, would not have its return traffic routed back to the
sender." "Spoofed packets" are a common source of martians. sender." "Spoofed packets" are a common source of martians.
Note that in some cases, the traffic may be asymmetric, and a Note that in some cases, the traffic may be asymmetric, and a
simple forwarding table check might produce false positives. See simple forwarding table check might produce false positives. See
[RFC3704] [RFC3704]
Out-of-Band (OoB) management. Out-of-Band (OoB) management.
"Out-of-Band management" is defined as any management done over "Out-of-Band management" is defined as any management done over
channels and interfaces that are separate from those used for channels and interfaces that are separate from those used for
user/customer data. Examples would include a serial console user/customer data. Examples would include a serial console
interface or a network interface connected to a dedicated interface or a network interface connected to a dedicated
management network that is not used to carry customer traffic. management network that is not used to carry customer traffic.
Open Review. Open Review.
"Open review" refers to processes designed to generate public "Open review" refers to processes designed to generate public
discussion and review of technical solutions such as data discussion and review of technical solutions such as data
communications protocols and cryptographic algorithms with the communications protocols and cryptographic algorithms with the
goals of improving and building confidence in the final solutions. goals of improving and building confidence in the final solutions.
For the purposes of this document "open review" is defined by For the purposes of this document "open review" is defined by
[RFC2026]. All standards track documents are considered to have [RFC2026]. All standards track documents are considered to have
been through an open review process. been through an open review process.
It should be noted that organizations may have local requirements It should be noted that organizations may have local requirements
that define what they view as acceptable "open review". For that define what they view as acceptable "open review". For
example, they may be required to adhere to certain national or example, they may be required to adhere to certain national or
international standards. Such modifications of the definition of international standards. Such modifications of the definition of
the term "open review", while important, are considered local the term "open review", while important, are considered local
issues that should be discussed between the organization and the issues that should be discussed between the organization and the
vendor. vendor.
It should also be noted that section 7 of [RFC2026] permits It should also be noted that section 7 of [RFC2026] permits
standards track documents to incorporate other "external standards standards track documents to incorporate other "external standards
and specifications". and specifications".
PBR.
Policy Based Routing.
Resource Starvation.
A condition where resources necessary for communication and proper
functioning of a network element are unavailable. Such resources
might include Bandwidth of a link, memory of a routing device, or
CPU time on a routing processor.
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.
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
transport, network and link layer protocols since, for example, a transport, network and link layer protocols since, for example, a
TCP packet addressed to a port on which no service is listening TCP packet addressed to a port on which no service is listening
will be "delivered" to the IP stack, and possibly result in an will be "delivered" to the IP stack, and possibly result in an
ICMP message being sent back. ICMP message being sent back.
Secure Channel.
A "secure channel" is a mechanism that ensures end-to-end Session.
integrity and confidentiality of communications. Examples include
TLS [RFC2246] and IPsec [RFC2401]. Connecting a terminal to a An instance of protocol establishment, e.g. telnet, BGP, OSPF,
console port using physically secure, shielded cable would provide etc.
confidentiality but possibly not integrity.
Single-Homed Network. Single-Homed Network.
A "single-homed network" is defined as one for which A "single-homed network" is defined as one for which
* There is only one upstream connection * There is only one upstream connection
* Routing is symmetric. * Routing is symmetric.
See [RFC3704] for a discussion of related issues and mechanisms See [RFC3704] for a discussion of related issues and mechanisms
for multi-homed networks. for multi-homed networks.
Spoofed Packet. Spoofed Packet.
A "spoofed packet" is defined as a packet that has a source A "spoofed packet" is defined as a packet that has a source
address that does not correspond to any address assigned to the address that does not correspond to any address assigned to the
system which sent the packet. Spoofed packets are often "bogons" system which sent the packet. Spoofed packets are often "bogons"
or "martians". or "martians".
Secure Network Secure Network
For the purposes of these documents, a secure network is one in For the purposes of these documents, a secure network is one in
which: which:
* The network keeps passing legitimate customer traffic * The network keeps passing legitimate customer traffic
(availability). (availability).
* Traffic goes where it is supposed to go, and only where it is * Traffic goes where it is supposed to go, and only where it is
supposed to go (availability, confidentiality). supposed to go (availability, confidentiality).
* The network elements remain manageable (availability). * The network elements remain manageable (availability).
* Only authorized users can manage network elements * Only authorized users can manage network elements
(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 types of documents to be produced by the
OPSEC working group. Each document is intended to cover an area OPSEC working group. Each document is intended to cover an area
important to secure operation of large network infrastructure. See important to secure operation of large network infrastructure. See
the working group charter for a complete list of individual the working group charter for a complete list of individual
documents. documents.
skipping to change at page 14, line 13 skipping to change at page 17, line 13
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 types of documents to be produced by the
OPSEC working group. Each document is intended to cover an area OPSEC working group. Each document is intended to cover an area
important to secure operation of large network infrastructure. See important to secure operation of large network infrastructure. See
the working group charter for a complete list of individual the working group charter for a complete list of individual
documents. documents.
2.1 Framework Document 2.1. Framework Document
Overview Overview
This document. This document.
2.2 Operator Practices Survey 2.2. Operator Practices Survey
Overview Overview
This document is intended to provide a survey of current operator This document is intended to provide a survey of current operator
practices in the area of securing networks. It lists current practices in the area of securing networks. It lists current
practices that will be cited as justification for capabilities. practices that will be cited as justification for capabilities.
It defines a general threat model and classes of attacks. It defines a general threat model and classes of attacks.
2.3 Standards Survey 2.3. Standards Survey
Overview Overview
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 to facilitate improvement in network security. Any intended to facilitate improvement in network security. Any
effort which is known, such as the ANSI T1.276, the NRIC V "Best effort which is known, such as the ANSI T1.276, the NRIC V "Best
Practices", ITU-T M.3016 and X.805, the T1S1 effort on securing Practices", ITU-T M.3016 and X.805, the T1S1 effort on securing
signalling will be included. The intent is to provide a clear signalling will be included. The intent is to provide a clear
understanding of which efforts are complementary and/or understanding of which efforts are complementary and/or
contradictory such that any efforts of future cross-certification contradictory such that any efforts of future cross-certification
of standards may be facilitated. of standards may be facilitated.
skipping to change at page 14, line 36 skipping to change at page 17, line 42
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 to facilitate improvement in network security. Any intended to facilitate improvement in network security. Any
effort which is known, such as the ANSI T1.276, the NRIC V "Best effort which is known, such as the ANSI T1.276, the NRIC V "Best
Practices", ITU-T M.3016 and X.805, the T1S1 effort on securing Practices", ITU-T M.3016 and X.805, the T1S1 effort on securing
signalling will be included. The intent is to provide a clear signalling will be included. The intent is to provide a clear
understanding of which efforts are complementary and/or understanding of which efforts are complementary and/or
contradictory such that any efforts of future cross-certification contradictory such that any efforts of future cross-certification
of standards may be facilitated. of standards may be facilitated.
2.4 Capabilities Documents 2.4. Capabilities Documents
Overview Overview
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 supported in the Operator Practices Survey and in few practices supported in the Operator Practices Survey and in few
cases may define additional practices. cases may define additional practices.
2.5 Profile Documents 2.5. Profile Documents
Overview Overview
Profile documents list capabilities appropriate to different Profile documents list capabilities appropriate to different
operating environments such as large Network Service Provider operating environments such as large Network Service Provider
(NSP) core or edge devices or enterprise networks. These profiles (NSP) core or edge devices or enterprise networks. These profiles
MAY provide a good starting point for organizations to generate MAY provide a good starting point for organizations to generate
their own list of requirements. their own list of requirements.
2.6 Deliberations Document 2.6. Deliberations Document
Overview Overview
The deliberations document is intended to capture discussion, list The deliberations document is intended to capture discussion, list
reasons for choices made, and give reasons for the inclusion and reasons for choices made, and give reasons for the inclusion and
exclusion of certain capabilities form the documents. This is exclusion of certain capabilities form the documents. This is
intended to provide insight to future work. intended to provide insight to future work.
3. Security Considerations 3. Security Considerations
Security is the entire focus of this document. Security is the entire focus of this document.
4 Normative References 4. Normative References
[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", BCP E. Lear, "Address Allocation for Private Internets",
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, September [RFC2196] Fraser, B., "Site Security Handbook", RFC 2196,
1997. September 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[RFC3013] Killalea, T., "Recommended Internet Service Provider [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330,
Security Services and Procedures", BCP 46, RFC 3013, September 2002.
November 2000.
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, 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, July Text on Security Considerations", BCP 72, RFC 3552,
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.
Appendix A. Acknowledgments
The authors gratefully acknowledge the contributions of:
o Acknowledgments to be determined.
o The MITRE Corporation for supporting development of this document.
NOTE: The author'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 author.
o This listing is intended to acknowledge contributions, not to
imply that the individual or organizations approve the content of
this document.
o Apologies to those who commented on/contributed to the document
and were not listed.
Authors' Addresses Authors' Addresses
George M. Jones George M. Jones
The MITRE Corporation The MITRE Corporation
7515 Colshire Drive, M/S WEST 7515 Colshire Drive, M/S WEST
McLean, Virginia 22102-7508 McLean, Virginia 22102-7508
U.S.A. U.S.A.
Phone: +1 703 488 9740 Phone: +1 703 488 9740
EMail: gmjones@mitre.org Email: gmjones@mitre.org
Ross Callon Ross Callon
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
U.S.A. U.S.A.
Phone: +1 978 692 6724 Phone: +1 978 692 6724
EMail: rcallon@juniper.net Email: rcallon@juniper.net
Merike Kaeo Merike Kaeo
Double Shot Security Double Shot Security
520 Washington Blvd. #363 520 Washington Blvd. #363
Marina Del Rey, CA 90292 Marina Del Rey, CA 90292
U.S.A. U.S.A.
Phone: +1 310 866 0165 Phone: +1 310 866 0165
EMail: kaeo@merike.com Email: kaeo@merike.com
Appendix A. Acknowledgments
The authors gratefully acknowledge the contributions of:
o Acknowledgments to be determined.
o The MITRE Corporation for supporting development of this document.
NOTE: The author'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 author.
o This listing is intended to acknowledge contributions, not to
imply that the individual or organizations approve the content of
this document.
o Apologies to those who commented on/contributed to the document
and were not listed.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 19, line 41 skipping to change at page 22, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 114 change blocks. 
137 lines changed or deleted 236 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/