Internet DRAFT - draft-callon-misc-cap
draft-callon-misc-cap
Network Working Group R. Callon
Internet-Draft Juniper Networks
Expires: April 17, 2006 G. Jones
The Mitre Corporation
October 14, 2005
Miscellaneous Capabilities for IP Network Infrastructure
draft-callon-misc-cap-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 17, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Framework for Operational Security Capabilities [11] outlines the
proposed effort of the IETF OPSEC working group. This includes
producing a series of drafts to codify knowledge gained through
operational experience about feature sets that are needed to securely
deploy and operate managed network elements providing transit
services at the data link and IP layers. Current plans include
separate capabilities documents for Packet Filtering; Event Logging;
Callon & Jones Expires April 17, 2006 [Page 1]
Internet-Draft Miscellaneous Capabilities October 2005
In-Band and Out-of-Band Management; Configuration and Management
Interfaces; AAA; and Documentation and Assurance. This document
describes some additional miscellaneous capabilities which do not fit
into any of these specific catagories, and whose descriptions are
brief enough that it does not seem appropriate to create a separate
document for each.
Operational Security Current Practices [12] lists current operator
practices related to securing networks. This document lists
miscellaneous capabilities needed to support those practices.
Capabilities are defined without reference to specific technologies.
This is done to leave room for deployment of new technologies that
implement the capability. Each capability cites the practices it
supports. Current implementations that support the capability may be
cited. Special considerations are discussed as appropriate listing
operational and resource constraints, limitations of current
implementations, tradeoffs, etc.
Callon & Jones Expires April 17, 2006 [Page 2]
Internet-Draft Miscellaneous Capabilities October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Threat model . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Capabilities versus Requirements . . . . . . . . . . . . . 4
1.3. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Terms Used in this Document . . . . . . . . . . . . . . . 5
1.5. RFC 2119 Keywords . . . . . . . . . . . . . . . . . . . . 6
2. Route Filtering Capabilities . . . . . . . . . . . . . . . . . 7
3. IP Stack Capabilities . . . . . . . . . . . . . . . . . . . . 7
3.1. Ability to Identify All Listening Services . . . . . . . . 7
3.2. Ability to Disable Any and All Services . . . . . . . . . 8
3.3. Ability to Control Service Bindings for Listening
Services . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Ability to Control Service Source Addresses . . . . . . . 10
3.5. Support Automatic Anti-Spoofing for Single-Homed
Networks . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.6. Support Automatic Discarding of Bogons and Martians . . . 11
3.7. Support Counters for Dropped Packets . . . . . . . . . . . 12
4. Performance and Prioritization . . . . . . . . . . . . . . . . 13
4.1. Security Features Should Have Minimal Performance
Impact . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Prioritization of Management Functions . . . . . . . . . . 14
4.3. Prioritization of Routing Functions . . . . . . . . . . . 14
4.4. Resources used by IP Multicast . . . . . . . . . . . . . . 15
5. Security Features Must Not Cause Operational Problems . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
8.2. Informational References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 21
Callon & Jones Expires April 17, 2006 [Page 3]
Internet-Draft Miscellaneous Capabilities October 2005
1. Introduction
This document is defined in the context of [11] and [12].
The Framework for Operational Security Capabilities [11] outlines the
proposed effort of the IETF OPSEC working group. This includes
producing a series of drafts to codify knowledge gained through
operational experience about feature sets that are needed to securely
deploy and operate managed network elements providing transit
services at the data link and IP layers. Current plans include
separate capabilities documents for Packet Filtering; Event Logging;
In-Band and Out-of-Band Management; Configuration and Management
Interfaces; AAA; and Documentation and Assurance. This document
describes some additional miscellaneous capabilities which do not fit
into any of these specific catagories, and whose descriptions are
brief enough that it does not seem appropriate to create a separate
document for each.
Operational Security Current Practices [12] defines the goals,
motivation, scope, definitions, intended audience, threat model,
potential attacks and give justifications for each of the practices.
Many of the capabilities listed here refine or add to capabilities
listed in rfc3871 [14]
EDITORS NOTE: This is a first draft. Additional work will be needed
to further refine the listed practices, to respond to comments, and
to try to align the supported practices with the practices listed in
[12].
1.1. Threat model
The capabities listed in this document are intended to aid in
preventing or mitigating the threats outlined in [11] and [12].
1.2. Capabilities versus Requirements
Capabilities may or may not be requirements. That is a local
determination that must be made by each operator with reference to
the policies that they must support. It is hoped that this document,
together with [12] will assist operators in identifying their
security capability requirements and communicating them clearly to
vendors.
1.3. Format
Each capability has the following subsections:
Callon & Jones Expires April 17, 2006 [Page 4]
Internet-Draft Miscellaneous Capabilities October 2005
o Capability (what)
o Supported Practices (why)
o Current Implementations (how)
o Considerations (caveats, resource issues, protocol issues, etc.)
The Capability section describes a feature to be supported by the
device. The Supported Practice section cites practices described in
[CurPrc] that are supported by this capability. The Current
Implementation section is intended to give examples of
implementations of the capability, citing technology and standards
current at the time of writing. See rfc3631 [13]. It is expected
that the choice of features to implement the capabilities will change
over time. The Considerations section lists operational and resource
constraints, limitations of current implementations, tradeoffs, etc.
1.4. Terms Used in this Document
The following terms are used in this document. These definitions are
taken from rfc3871 [14].
Bogon
A "Bogon" (plural: "bogons") is a packet with an IP source address
in an address block not yet allocated by IANA or the Regional
Internet Registries (ARIN, RIPE, APNIC...) as well as all
addresses reserved for private or special use by RFCs. See
rfc3330 [9] and rfc1918 [3].
Martian
Per rfc1208 [1] "Martian: Humorous term applied to packets that
turn up unexpectedly on the wrong network because of bogus routing
entries. Also used as a name for a packet which has an altogether
bogus (non-registered or ill-formed) Internet address." For the
purposes of this document Martians are defined as "packets having
a source address that, by application of the current forwarding
tables, would not have its return traffic routed back to the
sender." "Spoofed packets" are a common source of martians. Note
that in some cases, the traffic may be asymmetric, and a simple
forwarding table check might produce false positives. See rfc3704
[10].
Service
Callon & Jones Expires April 17, 2006 [Page 5]
Internet-Draft Miscellaneous Capabilities October 2005
A number of requirements refer to "services". For the purposes of
this document a "service" is defined as "any process or protocol
running in the control or management planes to which non-transit
packets may be delivered". Examples might include an SSH server,
a BGP process or an NTP server. It would also include the
transport, network and link layer protocols since, for example, a
TCP packet addressed to a port on which no service is listening
will be "delivered" to the IP stack, and possibly result in an
ICMP message being sent back.
Single-Homed Network.
A "single-homed network" is defined as one for which
* There is only one upstream connection
* Routing is symmetric.
See rfc3704 [10] for a discussion of related issues and mechanisms
for multihomed networks.
Spoofed Packet.
A "spoofed packet" is defined as a packet that has a source
address that does not correspond to any address assigned to the
system which sent the packet. Spoofed packets are often "bogons"
or "martians".
1.5. RFC 2119 Keywords
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in rfc2119 [4].
The use of the RFC 2119 keywords is an attempt, by the authors, to
assign the correct requirement levels ("MUST", "SHOULD", "MAY"...).
It must be noted that different organizations, operational
environments, policies and legal environments will generate different
requirement levels.
NOTE: This document defines capabilities. This document does not
define requirements, and there is no requirement that any particular
capability be implemented or deployed. The use of the terms MUST,
SHOULD, and so on are in the context of each capability in the sense
that if you conform to any particular capability then you MUST or
SHOULD do what is specified for that capability, but there is no
requirement that you actually do conform to any particular
capability.
Callon & Jones Expires April 17, 2006 [Page 6]
Internet-Draft Miscellaneous Capabilities October 2005
2. Route Filtering Capabilities
EDITOR'S NOTE: This is taken from section 2.7.5 of RFC3871.
Capability.
The device MUST provide a means to filter routing updates for all
protocols used to exchange external routing information.
Supported Practices.
See rfc3013 [7] and section 3.2 of rfc2196 [5].
Current Implementations.
Typically BGP implementations allow operators to apply a variety
of filters to restrict which incoming updates are accepted from
BGP peers, as well as to limit which updates are sent out to BGP
peers.
Considerations.
Operators may wish to ignore advertisements for routes to
addresses allocated for private internets. See eBGP.
3. IP Stack Capabilities
EDITOR'S NOTE: This is taken from section 2.5 of RFC3871.
3.1. Ability to Identify All Listening Services
Capability.
The vendor MUST:
* Provide a means to display all services that are listening for
network traffic directed at the device from any external source.
* Display the addresses to which each service is bound.
* Display the addresses assigned to each interface.
* Display any and all port(s) on which the service is listing.
* Include both open standard and vendor proprietary services.
Supported Practices.
Callon & Jones Expires April 17, 2006 [Page 7]
Internet-Draft Miscellaneous Capabilities October 2005
This information is necessary to enable a thorough assessment of
the security risks associated with the operation of the device
(e.g., "does this protocol allow complete management of the device
without also requiring authentication, authorization, or
accounting?"). The information also assists in determining what
steps should be taken to mitigate risk (e.g., "should I turn this
service off?")
Current Implementations.
tbd.
Considerations.
If the device is listening for SNMP traffic from any source
directed to the IP addresses of any of its local interfaces, then
this requirement could be met by the provision of a command which
displays that fact.
3.2. Ability to Disable Any and All Services
Capability.
The device MUST provide a means to turn off any "services" (see
section 1.4.1).
Supported Practices.
The ability to disable services for which there is no operational
need will allow administrators to reduce the overall risk posed to
the device.
Current Implementations.
tbd.
Considerations.
Processes that listen on TCP and UDP ports would be prime examples
of services that it must be possible to disable.
3.3. Ability to Control Service Bindings for Listening Services
Capability.
The device MUST provide a means for the user to specify the
bindings used for all listening services. It MUST support binding
to any address or net-block associated with any interface local to
Callon & Jones Expires April 17, 2006 [Page 8]
Internet-Draft Miscellaneous Capabilities October 2005
the device. This must include addresses bound to physical or non-
physical (e.g., loopback) interfaces.
Supported Practices.
It is a common practice among operators to configure "loopback"
pseudo-interfaces to use as the source and destination of
management traffic. These are preferred to physical interfaces
because they provide a stable, routable address. Services bound
to the addresses of physical interface addresses might become
unreachable if the associated hardware goes down, is removed, etc.
This requirement makes it possible to restrict access to
management services using routing. Management services may be
bound only to the addresses of loopback interfaces. The loopback
interfaces may be addressed out of net-blocks that are only routed
between the managed devices and the authorized management
networks/hosts. This has the effect of making it impossible for
anyone to connect to (or attempt to DoS) management services from
anywhere but the authorized management networks/hosts.
It also greatly reduces the need for complex filters. It reduces
the number of ports listening, and thus the number of potential
avenues of attack. It ensures that only traffic arriving from
legitimate addresses and/or on designated interfaces can access
services on the device.
Current Implementations.
tbd.
Considerations.
If the device listens for inbound SSH connections, this
requirement means that it should be possible to specify that the
device will only listen to connections destined to specific
addresses (e.g., the address of the loopback interface) or
received on certain interfaces (e.g., an Ethernet interface
designated as the "management" interface). It should be possible
in this example to configure the device such that the SSH is NOT
listening to every address configured on the device. Similar
effects may be achieved with the use of global filters, sometimes
called "receive" or "loopback" ACLs, that filter traffic destined
for the device itself on all interfaces.
Callon & Jones Expires April 17, 2006 [Page 9]
Internet-Draft Miscellaneous Capabilities October 2005
3.4. Ability to Control Service Source Addresses
Capability.
The device MUST provide a means that allows the user to specify
the source addresses used for all outbound connections or
transmissions originating from the device. It SHOULD be possible
to specify source addresses independently for each type of
outbound connection or transmission. Source addresses MUST be
limited to addresses that are assigned to interfaces (including
loopbacks) local to the device.
Supported Practices.
This allows remote devices receiving connections or transmissions
to use source filtering as one means of authentication. For
example, if SNMP traps were configured to use a known loopback
address as their source, the SNMP workstation receiving the traps
(or a firewall in front of it) could be configured to receive SNMP
packets only from that address.
Current Implementations.
tbd.
Considerations.
The operator may allocate a distinct block of addresses from which
all loopbacks are numbered. NTP and syslog can be configured to
use those loopback addresses as source, while SNMP and BGP may be
configured to use specific physical interface addresses. This
would facilitate filtering based on source address as one way of
rejecting unauthorized attempts to connect to peers/servers.
Care should be taken to assure that the addresses chosen are
routable between the sending and receiving devices, (e.g., setting
SSH to use a loopback address of 10.1.1.1 which is not routed
between a router and all intended destinations could cause
problems).
Note that some protocols, such as SCTP [8], can use more than one
IP address as the endpoint of a single connection.
Also note that rfc3631 [13] lists address-based authentication as
an "insecurity mechanism". Address based authentication should be
replaced or augmented by other mechanisms wherever possible.
Callon & Jones Expires April 17, 2006 [Page 10]
Internet-Draft Miscellaneous Capabilities October 2005
3.5. Support Automatic Anti-Spoofing for Single-Homed Networks
Capability.
The device MUST provide a means to designate particular interfaces
as servicing "single-homed networks" (see Section 1.4.1) and MUST
provide an option to automatically drop "spoofed packets" (Section
1.4.1) received on such interfaces where application of the
current forwarding table would not route return traffic back
through the same interface. This option MUST work in the presence
of dynamic routing and dynamically assigned addresses.
Supported Practices.
See section 3 of rfc1918 [3], sections 5.3.7 and 5.3.8 of rfc1812
[2], and rfc2827 [6].
Current Implementations.
This requirement could be satisfied in several ways. It could be
satisfied by the provision of a single command that automatically
generates and applies filters to an interface that implements
anti-spoofing. It could be satisfied by the provision of a
command that causes the return path for packets received to be
checked against the current forwarding tables and dropped if they
would not be forwarded back through the interface on which they
were received.
Considerations.
See rfc3704 [10].
This requirement only holds for single-homed networks. Note that
a simple forwarding table check is not sufficient in the more
complex scenarios of multi-homed or multi-attached networks, i.e.,
where the traffic may be asymmetric. In these cases, a more
extensive check such as Feasible Path RPF could be very useful.
3.6. Support Automatic Discarding of Bogons and Martians
Capability.
The device MUST provide a means to automatically drop all "bogons"
(Section 1.4.1) and "martians" (Section 1.4.1). This option MUST
work in the presence of dynamic routing and dynamically assigned
addresses.
Supported Practices.
Callon & Jones Expires April 17, 2006 [Page 11]
Internet-Draft Miscellaneous Capabilities October 2005
These sorts of packets have little (no?) legitimate use and are
used primarily to allow individuals and organization to avoid
identification (and thus accountability) and appear to be most
often used for DoS attacks, email abuse, hacking, etc. In
addition, transiting these packets needlessly consumes resources
and may lead to capacity and performance problems for customers.
See section 3 of rfc1918 [3], sections 5.3.7 and 5.3.8 of rfc1812
[2], and rfc2827 [6].
Current Implementations.
This requirement could be satisfied by the provision of a command
that causes the return path for packets received to be checked
against the current forwarding tables and dropped if no viable
return path exists. This assumes that steps are taken to assure
that no bogon entries are present in the forwarding tables.
Considerations.
See rfc3704 [10].
This requirement only holds for single-homed networks. Note that
a simple forwarding table check is not sufficient in the more
complex scenarios of multi-homed or multi-attached networks, i.e.,
where the traffic may be asymmetric. In these cases, a more
extensive check such as Feasible Path RPF could be very useful.
3.7. Support Counters for Dropped Packets
Capability.
The device MUST provide accurate, per-interface counts of spoofed
packets dropped in accordance with Section 3.5 and Section 3.6.
Supported Practices.
Counters can help in identifying the source of spoofed traffic.
Current Implementations.
tbd.
Considerations.
An edge router may have several single-homed customers attached.
When an attack using spoofed packets is detected, a quick check of
counters may be able to identify which customer is attempting to
Callon & Jones Expires April 17, 2006 [Page 12]
Internet-Draft Miscellaneous Capabilities October 2005
send spoofed traffic.
4. Performance and Prioritization
EDITOR'S NOTE: This section is taken from section 2.15 and a slightly
expanded section 2.2.5 of RFC3871.
4.1. Security Features Should Have Minimal Performance Impact
Capability.
Security features specified by the requirements in this document
SHOULD be implemented with minimal impact on performance. Other
sections of this document or other OPSEC capabilities documents
may specify different performance requirements (e.g., "MUST"s).
Supported Practices.
Security features which significantly impact performance may leave
the operator with no mechanism for enforcing appropriate policy.
Current Implementations.
tbd.
Considerations.
If the application of filters is known to have the potential to
significantly reduce throughput for non-filtered traffic, there
will be a tendency, or in some cases a policy, not to use filters.
Assume, for example, that a new worm is released that scans random
IP addresses looking for services listening on TCP port 1433. An
operator might want to investigate to see if any of the hosts on
their networks were infected and trying to spread the worm. One
way to do this would be to put up non-blocking filters counting
and logging the number of outbound connection 1433, and then to
block the requests that are determined to be from infected hosts.
If any of these capabilities (filtering, counting, logging) have
the potential to impose severe performance penalties, then this
otherwise rational course of action might not be possible.
Requirements for which performance is a particular concern
include: filtering, rate-limiting, counters, logging and anti-
spoofing.
Callon & Jones Expires April 17, 2006 [Page 13]
Internet-Draft Miscellaneous Capabilities October 2005
4.2. Prioritization of Management Functions
Capability.
Management functions SHOULD be processed at higher priority than
non-management traffic. This SHOULD include ingress, egress,
internal transmission, and processing. This SHOULD include at
least protocols used for configuration, monitoring, configuration
backup, logging, time synchronization, and authentication.
Supported Practices.
Certain attacks (and normal operation) can cause resource
saturation such as link congestion, memory exhaustion or CPU
overload. In these cases it is important that management
functions be prioritized to ensure that operators have the tools
needed to recover from the attack.
Current Implementations.
tbd.
Considerations.
Imagine a service provider with 1,000,000 DSL subscribers, most of
whom have no firewall protection. Imagine that a large portion of
these subscribers machines were infected with a new worm that
enabled them to be used in coordinated fashion as part of large
denial of service attack that involved flooding. It is entirely
possible that without prioritization such an attack would cause
processor saturation or other internal resource saturation on
routers causing the routers to become unmanageable. A DoS attack
against hosts could therefore become a DoS attack against the
network.
Prioritization is not a panacea. Control packets may not make it
across a saturated link. This requirement simply says that the
device should prioritize management functions within its scope of
control (e.g., ingress, egress, internal transit, processing). To
the extent that this is done across an entire network, the overall
effect will be to ensure that the network remains manageable.
4.3. Prioritization of Routing Functions
Capability.
Routing functions SHOULD be processed at higher priority than user
data traffic. This SHOULD include ingress, egress, internal
Callon & Jones Expires April 17, 2006 [Page 14]
Internet-Draft Miscellaneous Capabilities October 2005
transmission, and processing. This SHOULD include all packets
necessary for routing protocol operation, and specifically MUST
include priority processing of routing HELLO packets for BGP,
IS-IS, and OSPF.
Supported Practices.
Certain attacks (and normal operation) can cause resource
saturation such as link congestion, memory exhaustion or CPU
overload. In these cases it is important that routing functions
be prioritized to ensure that the network continues to operate
(for example, that routes can be computed in order to allow
management traffic to be delivered). For many routing protocols
the loss of HELLO packets can cause the protocol to drop
adjacencies and/or to send out additional routing packets,
potentially adding to whatever congestion may be causing the
problem.
Current Implementations.
tbd.
Considerations.
If routing HELLO packets are not prioritized, then it is possible
during DoS attacks or during severe network congestion for routing
protocols to drop HELLO packets, causing routing adjacencies to be
lost. This in turn can cause overall failure of a network. A DoS
attack against hosts can therefore become a DoS attack against the
network.
Prioritization within routers is not a panacea. Routing update
packets may not make it across a saturated link (thus for example
it may also be desirable to prioritize routing packets for
transmission across link layer devices such as Ethernet switches).
This requirement simply says that the device should prioritize
routing functions within its scope of control (e.g., ingress,
egress, internal transit, processing). To the extent that this is
done across an entire network, the overall effect will be to
ensure that the network continues to operate.
4.4. Resources used by IP Multicast
Capability.
Routers SHOULD provide some mechanism(s) to allow the control
plane resources used by IP multicast, including processing and
memory, to be limited to some level which is less than 100% of the
Callon & Jones Expires April 17, 2006 [Page 15]
Internet-Draft Miscellaneous Capabilities October 2005
total available processing and memory. The maximum limit of
resources used by multicast MAY be configurable. Routers SHOULD
also provide a mechanism(s) to allow the amount of link bandwidth
consumed by IP multicast on any particular link to be limited to
some level which is less than 100% of total available bandwidth on
that link.
Supported Practices.
IP multicast has characteristics which may potentially impact the
availability of IP networks. In particular, IP multicast requires
that routers perform control plane processing and maintain state
in response to data plane traffic. Also, the use of multicast
implies that a single packet input into the network can result in
a large number of packets being delivered throughout the network.
Also, it is possible in some situations for a multicast traffic to
*both* enter a loop, and also be delivered to some destinations
(implying that many copies of the same packet could be delivered).
Current Implementations.
tbd.
Considerations.
If the amount of resources used by multicast are not limited, then
it is possible during an attack for multicast to consume
potentially as much as 100% of available memory, processing, or
bandwidth resources, thereby causing network problems.
5. Security Features Must Not Cause Operational Problems
EDITOR'S NOTE: This is taken from section 2.14 of RFC3871.
Capability.
The use of security features specified by the requirements in this
document SHOULD NOT cause severe operational problems.
Supported Practices.
Security features which cause operational problems are not useful
and may leave the operator with no mechanism for enforcing
appropriate policy.
Current Implementations.
Callon & Jones Expires April 17, 2006 [Page 16]
Internet-Draft Miscellaneous Capabilities October 2005
tbd.
Considerations.
Some examples of severe operational problems include:
* The device crashes.
* The device becomes unmanageable.
* Data is lost.
* Use of the security feature consumes excessive resources (CPU,
memory, bandwidth).
Determination of compliance with this requirement involves a level
of judgement. What is "severe"? Certainly crashing is severe,
but what about a %5 loss in throughput when logging is enabled?
It should also be noted that there may be unavoidable physical
limitations such as the total capacity of a link.
6. Security Considerations
General
Security is the subject matter of this entire document. This
document lists device capabilities intended to improve the ability
of the network to withstand security threats. Operational
Security Current Practices [12] defines the threat model and
practices, and lists justifications for each practice.
7. Acknowledgements
The authors gratefully acknowledge the contributions of:
o xxx, yyy, ...
o The MITRE Corporation for supporting development of this
document. NOTE: An 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 authors.
o This listing is intended to acknowledge contributions, not to
imply that the individual or organizations approve the content of
Callon & Jones Expires April 17, 2006 [Page 17]
Internet-Draft Miscellaneous Capabilities October 2005
this document.
o Apologies to those who commented on/contributed to the document
and were not listed.
8. References
8.1. Normative References
[1] Jacobsen, O. and D. Lynch, "Glossary of networking terms",
RFC 1208, March 1991.
[2] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
June 1995.
[3] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
Lear, "Address Allocation for Private Internets", BCP 5,
RFC 1918, February 1996.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Fraser, B., "Site Security Handbook", RFC 2196, September 1997.
[6] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[7] Killalea, T., "Recommended Internet Service Provider Security
Services and Procedures", BCP 46, RFC 3013, November 2000.
[8] Stone, J., Stewart, R., and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC 3309,
September 2002.
[9] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[10] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
8.2. Informational References
[11] Jones, G., "Framework for Operational Security Capabilities for
IP Network Infrastructure", draft-ietf-opsec-framework-00
(work in progress), June 2005.
[12] Kaeo, M., "Operational Security Current Practices",
Callon & Jones Expires April 17, 2006 [Page 18]
Internet-Draft Miscellaneous Capabilities October 2005
draft-ietf-opsec-current-practices-01 (work in progress),
July 2005.
[13] Bellovin, S., Schiller, J., and C. Kaufman, "Security
Mechanisms for the Internet", RFC 3631, December 2003.
[14] Jones, G., "Operational Security Requirements for Large
Internet Service Provider (ISP) IP Network Infrastructure",
RFC 3871, September 2004.
Callon & Jones Expires April 17, 2006 [Page 19]
Internet-Draft Miscellaneous Capabilities October 2005
Authors' Addresses
Ross W. Callon
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
Email: rcallon@juniper.net
George Jones
The Mitre Corporation
7515 Colshire Drive
McLean, Virginia, VA 22102-7508
USA
Email: gmjones@mitre.org
Callon & Jones Expires April 17, 2006 [Page 20]
Internet-Draft Miscellaneous Capabilities October 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Callon & Jones Expires April 17, 2006 [Page 21]
