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]