draft-ietf-opsec-filter-caps-04.txt		draft-ietf-opsec-filter-caps-05.txt
	None. C. Morrow		None. C. Morrow
	Internet-Draft UUNET Technologies		Internet-Draft UUNET Technologies
	Intended status: Informational G. Jones		Intended status: Informational G. Jones
	Expires: March 5, 2007 The MITRE Corporation		Expires: September 2, 2007
	V. Manral		V. Manral
	IP Infusion		IP Infusion
	September 1, 2006		March 1, 2007
	Filtering and Rate Limiting Capabilities for IP Network Infrastructure		Filtering and Rate Limiting Capabilities for IP Network Infrastructure
	draft-ietf-opsec-filter-caps-04		draft-ietf-opsec-filter-caps-05
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 37		skipping to change at page 1, line 37
	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 March 5, 2007.		This Internet-Draft will expire on September 2, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	[I-D.ietf-opsec-current-practices] lists operator practices related		[RFC4778] lists operator practices related to securing networks.
	to securing networks. This document lists filtering and rate		This document lists filtering and rate limiting capabilities needed
	limiting capabilities needed to support those practices.		to support those practices. Capabilities are limited to filtering
	Capabilities are limited to filtering and rate limiting packets as		and rate limiting packets as they enter or leave the device. Route
	they enter or leave the device. Route filters and service specific		filters and service specific filters (e.g. SNMP, telnet) are not
	filters (e.g. SNMP, telnet) are not addressed.		addressed.
	Capabilities are defined without reference to specific technologies.		Capabilities are defined without reference to specific technologies.
	This is done to leave room for deployment of new technologies that		This is done to leave room for deployment of new technologies that
	implement the capability. Each capability cites the practices it		implement the capability. Each capability cites the practices it
	supports. Current implementations that support the capability are		supports. Current implementations that support the capability are
	cited. Special considerations are discussed as appropriate listing		cited. Special considerations are discussed as appropriate listing
	operational and resource constraints, limitations of current		operational and resource constraints, limitations of current
	implementations, trade-offs, etc.		implementations, trade-offs, etc.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Packet Selection for Management and Data Plane Controls . . . 6		2. Packet Selection for Management and Data Plane Controls . . . 6
	3. Packet Selection Criteria . . . . . . . . . . . . . . . . . . 7		3. Packet Selection Criteria . . . . . . . . . . . . . . . . . . 7
	3.1. Select Traffic on All Interfaces . . . . . . . . . . . . . 7		3.1. Select Traffic on All Interfaces . . . . . . . . . . . . . 7
	3.2. Select Traffic To the Device . . . . . . . . . . . . . . . 8		3.2. Select Traffic To the Device . . . . . . . . . . . . . . . 7
	3.3. Select Transit Traffic . . . . . . . . . . . . . . . . . . 8		3.3. Select Transit Traffic . . . . . . . . . . . . . . . . . . 8
	3.4. Select Inbound and/or Outbound . . . . . . . . . . . . . . 9		3.4. Select Inbound and/or Outbound . . . . . . . . . . . . . . 9
	3.5. Select by Protocols . . . . . . . . . . . . . . . . . . . 10		3.5. Select by Protocols . . . . . . . . . . . . . . . . . . . 10
	3.6. Select by Addresses . . . . . . . . . . . . . . . . . . . 11		3.6. Select by Addresses . . . . . . . . . . . . . . . . . . . 10
	3.7. Select by Protocol Header Fields . . . . . . . . . . . . . 12		3.7. Select by Protocol Header Fields . . . . . . . . . . . . . 11
	4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		4. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	4.1. Specify Filter Actions . . . . . . . . . . . . . . . . . . 14		4.1. Specify Filter Actions . . . . . . . . . . . . . . . . . . 13
	4.2. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 14		4.2. Specify Rate Limits . . . . . . . . . . . . . . . . . . . 13
	4.3. Specify Log Actions . . . . . . . . . . . . . . . . . . . 15		4.3. Specify Log Actions . . . . . . . . . . . . . . . . . . . 14
	4.4. Specify Log Granularity . . . . . . . . . . . . . . . . . 16		4.4. Specify Log Granularity . . . . . . . . . . . . . . . . . 15
	4.5. Ability to Display Filter Counters . . . . . . . . . . . . 17		4.5. Ability to Display Filter Counters . . . . . . . . . . . . 16
	5. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		5. Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	5.1. Filter Counters Displayed Per Application . . . . . . . . 18		5.1. Filter Counters Displayed Per Application . . . . . . . . 17
	5.2. Ability to Reset Filter Counters . . . . . . . . . . . . . 18		5.2. Ability to Reset Filter Counters . . . . . . . . . . . . . 17
	5.3. Filter Hits are Counted . . . . . . . . . . . . . . . . . 19		5.3. Filter Hits are Counted . . . . . . . . . . . . . . . . . 18
	5.4. Filter Counters are Accurate . . . . . . . . . . . . . . . 20		5.4. Filter Counters are Accurate . . . . . . . . . . . . . . . 19
	6. Minimal Performance Degradation . . . . . . . . . . . . . . . 21		6. Minimal Performance Degradation . . . . . . . . . . . . . . . 20
	7. Additional Operational Practices . . . . . . . . . . . . . . . 23		7. Additional Operational Practices . . . . . . . . . . . . . . . 22
	7.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 23		7.1. Profile Current Traffic . . . . . . . . . . . . . . . . . 22
	7.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 23		7.2. Block Malicious Packets . . . . . . . . . . . . . . . . . 22
	7.3. Limit Sources of Management . . . . . . . . . . . . . . . 23		7.3. Limit Sources of Management . . . . . . . . . . . . . . . 22
	7.4. Respond to Incidents Based on Accurate Data . . . . . . . 23		7.4. Respond to Incidents Based on Accurate Data . . . . . . . 22
	7.5. Implement Filters Where Necessary . . . . . . . . . . . . 24		7.5. Implement Filters Where Necessary . . . . . . . . . . . . 23
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 25		8. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	9. Non-normative References . . . . . . . . . . . . . . . . . . . 26		9. Non-normative References . . . . . . . . . . . . . . . . . . . 25
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 27		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
	Intellectual Property and Copyright Statements . . . . . . . . . . 29		Intellectual Property and Copyright Statements . . . . . . . . . . 28
	1. Introduction		1. Introduction
	This document is defined in the context of		This document is defined in the context of [RFC4778]. [RFC4778]
	[I-D.ietf-opsec-current-practices].		defines the goals, motivation, scope, definitions, intended audience,
	[I-D.ietf-opsec-current-practices] defines the goals, motivation,		threat model, potential attacks and give justifications for each of
	scope, definitions, intended audience, threat model, potential		the practices. Many of the capabilities listed here refine or add to
	attacks and give justifications for each of the practices. Many of		capabilities listed in [RFC3871].
	the capabilities listed here refine or add to capabilities listed in
	[RFC3871].
	Also see [I-D.lewis-infrastructure-security] for a useful description		Also see [I-D.lewis-infrastructure-security] for a useful description
	of techniques for protecting infrastructure devices, including the		of techniques for protecting infrastructure devices, including the
	use of filtering.		use of filtering.
	1.1. Threat Model		1.1. Threat Model
	Threats in today's networked environment range from simple packet		Threats in today's networked environment range from simple packet
	floods with overwhelming bandwidth toward a leaf network to subtle		floods with overwhelming bandwidth toward a leaf network to subtle
	attacks aimed at subverting known vulnerabilities in existing		attacks aimed at subverting known vulnerabilities in existing
	skipping to change at page 5, line 30		skipping to change at page 5, line 28
	o Capability (what)		o Capability (what)
	o Supported Practices (why)		o Supported Practices (why)
	o Current Implementations (how)		o Current Implementations (how)
	o Considerations (caveats, resource issues, protocol issues, etc.)		o Considerations (caveats, resource issues, protocol issues, etc.)
	The Capability section describes a feature to be supported by the		The Capability section describes a feature to be supported by the
	device. The Supported Practice section cites practices described in		device. The Supported Practice section cites practices described in
	[I-D.ietf-opsec-current-practices] that are supported by this		[RFC4778] that are supported by this capability. The Current
	capability. The Current Implementation section is intended to give		Implementation section is intended to give examples of
	examples of implementations of the capability, citing technology and		implementations of the capability, citing technology and standards
	standards current at the time of writing. It is expected that the		current at the time of writing. It is expected that the choice of
	choice of features to implement the capabilities will change over		features to implement the capabilities will change over time. The
	time. The Considerations section lists operational and resource		Considerations section lists operational and resource constraints,
	constraints, limitations of current implementations, trade-offs, etc.		limitations of current implementations, trade-offs, etc.
	2. Packet Selection for Management and Data Plane Controls		2. Packet Selection for Management and Data Plane Controls
	In this document Section 3 describes a number of criteria for		In this document Section 3 describes a number of criteria for
	performing packet selection. It is assumed in this document that		performing packet selection. It is assumed in this document that
	o all of these criteria can be used to select packets for both		o all of these criteria can be used to select packets for both
	filtering and rate limiting packets,		filtering and rate limiting packets,
	o management plane controls can be implemented by applying these		o management plane controls can be implemented by applying these
	skipping to change at page 7, line 19		skipping to change at page 7, line 19
	3.1. Select Traffic on All Interfaces		3.1. Select Traffic on All Interfaces
	Capability.		Capability.
	The device provides a means to filter IP packets on any interface		The device provides a means to filter IP packets on any interface
	implementing IP.		implementing IP.
	Supported Practices.		Supported Practices.
	* Security Practices for Device Management		* Security Practices for Device Management ([RFC4778], Section
	([I-D.ietf-opsec-current-practices], Section 2.2.2)		2.2.2)
	* Security Practices for Data Path ([I-D.ietf-opsec-current-		* Security Practices for Data Path ([I-D.ietf-opsec-current-
	practices], Section 2.3.2)		practices], Section 2.3.2)
	* Security Practices for Software Upgrades and Configuration		* Security Practices for Software Upgrades and Configuration
	Integrity/Validation ([I-D.ietf-opsec-current-practices],		Integrity/Validation ([I-D.ietf-opsec-current-practices],
	Section 2.5.2)		Section 2.5.2)
	* Data Plane Filtering ([I-D.ietf-opsec-current-practices],		* Data Plane Filtering ([RFC4778], Section 2.7.1)
	Section 2.7.1)
	* Management Plane Filtering ([I-D.ietf-opsec-current-practices],		* Management Plane Filtering ([RFC4778], Section 2.7.2)
	Section 2.7.2)
	* Profile Current Traffic (Section 7.1)		* Profile Current Traffic (Section 7.1)
	* Block Malicious Packets (Section 7.2)		* Block Malicious Packets (Section 7.2)
	Current Implementations.		Current Implementations.
	Many devices currently implement access control lists or filters		Many devices currently implement access control lists or filters
	that allow filtering based on protocol and/or source/destination		that allow filtering based on protocol and/or source/destination
	address and or source/destination port and allow these filters to		address and or source/destination port and allow these filters to
	skipping to change at page 8, line 6		skipping to change at page 8, line 4
	Many devices currently implement access control lists or filters		Many devices currently implement access control lists or filters
	that allow filtering based on protocol and/or source/destination		that allow filtering based on protocol and/or source/destination
	address and or source/destination port and allow these filters to		address and or source/destination port and allow these filters to
	be applied to interfaces.		be applied to interfaces.
	Considerations.		Considerations.
	None.		None.
	3.2. Select Traffic To the Device		3.2. Select Traffic To the Device
	Capability.		Capability.
	It is possible to apply the filtering mechanism to traffic that is		It is possible to apply the filtering mechanism to traffic that is
	addressed directly to the device via any of its interfaces -		addressed directly to the device via any of its interfaces -
	including loopback interfaces.		including loopback interfaces.
	Supported Practices.		Supported Practices.
	* Security Practices for Device Management		* Security Practices for Device Management ([RFC4778], Section
	([I-D.ietf-opsec-current-practices], Section 2.2.2)		2.2.2)
	* Security Practices for Software Upgrades and Configuration		* Security Practices for Software Upgrades and Configuration
	Integrity/Validation ([I-D.ietf-opsec-current-practices],		Integrity/Validation ([RFC4778], Section 2.5.2)
	Section 2.5.2)
	* Management Plane Filtering ([I-D.ietf-opsec-current-practices],		* Management Plane Filtering ([RFC4778], Section 2.7.2)
	Section 2.7.2)
	Current Implementations.		Current Implementations.
	Many devices currently implement access control lists or filters		Many devices currently implement access control lists or filters
	that allow filtering based on protocol and/or source/destination		that allow filtering based on protocol and/or source/destination
	address and or source/destination port and allow these filters to		address and or source/destination port and allow these filters to
	be applied to services offered by the device.		be applied to services offered by the device.
	Examples of this might include filters that permit only BGP from		Examples of this might include filters that permit only BGP from
	peers and SNMP and SSH from an authorized management segment and		peers and SNMP and SSH from an authorized management segment and
	skipping to change at page 8, line 50		skipping to change at page 8, line 45
	3.3. Select Transit Traffic		3.3. Select Transit Traffic
	Capability.		Capability.
	It is possible to apply the filtering mechanism to traffic that		It is possible to apply the filtering mechanism to traffic that
	will transit the device via any of its interfaces.		will transit the device via any of its interfaces.
	Supported Practices.		Supported Practices.
	* Security Practices for Data Path		* Security Practices for Data Path ([RFC4778], Section 2.3.2)
	([I-D.ietf-opsec-current-practices], Section 2.3.2)
	* Data Plane Filtering ([I-D.ietf-opsec-current-practices],
	Section 2.7.1)
			* Data Plane Filtering ([RFC4778], Section 2.7.1)
	Current Implementations.		Current Implementations.
	Many devices currently implement access control lists or filters		Many devices currently implement access control lists or filters
	that allow filtering based on protocol and/or source/destination		that allow filtering based on protocol and/or source/destination
	address and or source/destination port and allow these filters to		address and or source/destination port and allow these filters to
	be applied to the interfaces on the device in order to protect		be applied to the interfaces on the device in order to protect
	assets attached to the network.		assets attached to the network.
	Examples of this may include filtering all traffic save SMTP		Examples of this may include filtering all traffic save SMTP
	(tcp/25) destined to a mail server. A common use of this today		(tcp/25) destined to a mail server. A common use of this today
	skipping to change at page 9, line 35		skipping to change at page 9, line 32
	3.4. Select Inbound and/or Outbound		3.4. Select Inbound and/or Outbound
	Capability.		Capability.
	It is possible to filter both incoming and outgoing traffic on any		It is possible to filter both incoming and outgoing traffic on any
	interface.		interface.
	Supported Practices.		Supported Practices.
	* Security Practices for Device Management		* Security Practices for Device Management ([RFC4778], Section
	([I-D.ietf-opsec-current-practices], Section 2.2.2)		2.2.2)
	* Security Practices for Data Path		* Security Practices for Data Path ([RFC4778], Section 2.3.2)
	([I-D.ietf-opsec-current-practices], Section 2.3.2)
	* Security Practices for Software Upgrades and Configuration		* Security Practices for Software Upgrades and Configuration
	Integrity/Validation ([I-D.ietf-opsec-current-practices],		Integrity/Validation ([RFC4778], Section 2.5.2)
	Section 2.5.2)
	* Data Plane Filtering ([I-D.ietf-opsec-current-practices],		* Data Plane Filtering ([RFC4778], Section 2.7.1)
	Section 2.7.1)
			* Management Plane Filtering ([RFC4778], Section 2.7.2)
	* Management Plane Filtering ([I-D.ietf-opsec-current-practices],
	Section 2.7.2)
	Current Implementations.		Current Implementations.
	It might be desirable on a border router, for example, to apply an		It might be desirable on a border router, for example, to apply an
	egress filter outbound on the interface that connects a site to		egress filter outbound on the interface that connects a site to
	its external ISP to drop outbound traffic that does not have a		its external ISP to drop outbound traffic that does not have a
	valid internal source address. Inbound, it might be desirable to		valid internal source address. Inbound, it might be desirable to
	apply a filter that blocks all traffic from a site that is known		apply a filter that blocks all traffic from a site that is known
	to forward or originate large amounts of junk mail.		to forward or originate large amounts of junk mail.
	Considerations.		Considerations.
	skipping to change at page 10, line 29		skipping to change at page 10, line 21
	3.5. Select by Protocols		3.5. Select by Protocols
	Capability.		Capability.
	The device provides a means to filter traffic based on the value		The device provides a means to filter traffic based on the value
	of the protocol field in the IP header.		of the protocol field in the IP header.
	Supported Practices.		Supported Practices.
	* Security Practices for Device Management		* Security Practices for Device Management ([RFC4778], Section
	([I-D.ietf-opsec-current-practices], Section 2.2.2)		2.2.2)
	* Security Practices for Data Path		* Security Practices for Data Path ([RFC4778], Section 2.3.2)
	([I-D.ietf-opsec-current-practices], Section 2.3.2)
	* Security Practices for Software Upgrades and Configuration		* Security Practices for Software Upgrades and Configuration
	Integrity/Validation		Integrity/Validation ([RFC4778],Section 2.5.2)
	([I-D.ietf-opsec-current-practices],Section 2.5.2)
	* Data Plane Filtering ([I-D.ietf-opsec-current-practices],		* Data Plane Filtering ([RFC4778], Section 2.7.1)
	Section 2.7.1)
	* Management Plane Filtering ([I-D.ietf-opsec-current-practices],		* Management Plane Filtering ([RFC4778], Section 2.7.2)
	Section 2.7.2)
	Current Implementations.		Current Implementations.
	Some denial of service attacks are based on the ability to flood		Some denial of service attacks are based on the ability to flood
	the victim with ICMP traffic. One quick way (admittedly with some		the victim with ICMP traffic. One quick way (admittedly with some
	negative side effects) to mitigate the effects of such attacks is		negative side effects) to mitigate the effects of such attacks is
	to drop all ICMP traffic headed toward the victim.		to drop all ICMP traffic headed toward the victim.
	Considerations.		Considerations.
	skipping to change at page 11, line 14		skipping to change at page 11, line 4
	Considerations.		Considerations.
	Being able to filter on protocol is necessary to allow		Being able to filter on protocol is necessary to allow
	implementation of policy, secure operations and for support of		implementation of policy, secure operations and for support of
	incident response. Filtering all traffic to a destination host is		incident response. Filtering all traffic to a destination host is
	not often possible, business requirements will dictate that		not often possible, business requirements will dictate that
	critical traffic be permitted if at all possible.		critical traffic be permitted if at all possible.
	3.6. Select by Addresses		3.6. Select by Addresses
	Capability.		Capability.
	The device is able to control the flow of traffic based on source		The device is able to control the flow of traffic based on source
	and/or destination IP address or blocks of addresses such as		and/or destination IP address or blocks of addresses such as
	Classless Inter-Domain Routing (CIDR) blocks.		Classless Inter-Domain Routing (CIDR) blocks.
	Supported Practices.		Supported Practices.
	* Security Practices for Device Management		* Security Practices for Device Management ([RFC4778], Section
	([I-D.ietf-opsec-current-practices], Section 2.2.2)		2.2.2)
	* Security Practices for Data Path		* Security Practices for Data Path ([RFC4778], Section 2.3.2)
	([I-D.ietf-opsec-current-practices], Section 2.3.2)
	* Security Practices for Software Upgrades and Configuration		* Security Practices for Software Upgrades and Configuration
	Integrity/Validation ([I-D.ietf-opsec-current-practices],		Integrity/Validation ([RFC4778], Section 2.5.2
	Section 2.5.2
	* Data Plane Filtering ([I-D.ietf-opsec-current-practices],		* Data Plane Filtering ([RFC4778], Section 2.7.1)
	Section 2.7.1)
	* Management Plane Filtering ([I-D.ietf-opsec-current-practices],		* Management Plane Filtering ([RFC4778], Section 2.7.2)
	Section 2.7.2)
	Current Implementations.		Current Implementations.
	One example of the use of address based filtering is to implement		One example of the use of address based filtering is to implement
	ingress filtering per [RFC2827]		ingress filtering per [RFC2827]
	Considerations.		Considerations.
	The capability to filter on addresses and address blocks is a		The capability to filter on addresses and address blocks is a
	fundamental tool for establishing boundaries between different		fundamental tool for establishing boundaries between different
	skipping to change at page 12, line 19		skipping to change at page 11, line 49
	The filtering mechanism supports filtering based on the value(s)		The filtering mechanism supports filtering based on the value(s)
	of any portion of the protocol headers for IP, ICMP, UDP and TCP		of any portion of the protocol headers for IP, ICMP, UDP and TCP
	by specifying fields by name (e.g., "protocol = ICMP") rather than		by specifying fields by name (e.g., "protocol = ICMP") rather than
	bit- offset/length/numeric value (e.g., 72:8 = 1).		bit- offset/length/numeric value (e.g., 72:8 = 1).
	It supports arbitrary header-based filtering (possibly using bit-		It supports arbitrary header-based filtering (possibly using bit-
	offset/length/value) of all other protocols.		offset/length/value) of all other protocols.
	Supported Practices.		Supported Practices.
	* Security Practices for Device Management		* Security Practices for Device Management ([RFC4778], Section
	([I-D.ietf-opsec-current-practices], Section 2.2.2)		2.2.2)
			* Security Practices for Data Path ([RFC4778], Section 2.3.2)
	* Security Practices for Data Path
	([I-D.ietf-opsec-current-practices], Section 2.3.2)
	* Security Practices for Software Upgrades and Configuration		* Security Practices for Software Upgrades and Configuration
	Integrity/Validation ([I-D.ietf-opsec-current-practices],		Integrity/Validation ([RFC4778], Section 2.5.2)
	Section 2.5.2)
	* Data Plane Filtering ([I-D.ietf-opsec-current-practices],		* Data Plane Filtering ([RFC4778], Section 2.7.1)
	Section 2.7.1)
	* Management Plane Filtering ([I-D.ietf-opsec-current-practices],		* Management Plane Filtering ([RFC4778], Section 2.7.2)
	Section 2.7.2)
	Current Implementations.		Current Implementations.
	This capability implies that it is possible to filter based on TCP		This capability implies that it is possible to filter based on TCP
	or UDP port numbers, TCP flags such as SYN, ACK and RST bits, and		or UDP port numbers, TCP flags such as SYN, ACK and RST bits, and
	ICMP type and code fields. One common example is to reject		ICMP type and code fields. One common example is to reject
	"inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear		"inbound" TCP connection attempts (TCP, SYN bit set+ACK bit clear
	or SYN bit set+ACK,FIN and RST bits clear). Another common		or SYN bit set+ACK,FIN and RST bits clear). Another common
	example is the ability to control what services are allowed in/out		example is the ability to control what services are allowed in/out
	of a network. It may be desirable to only allow inbound		of a network. It may be desirable to only allow inbound
	skipping to change at page 14, line 19		skipping to change at page 13, line 19
	Capability.		Capability.
	The device provides a mechanism to allow the specification of the		The device provides a mechanism to allow the specification of the
	action to be taken when a filter rule matches. Actions include		action to be taken when a filter rule matches. Actions include
	"permit" (allow the traffic), "reject" (drop with appropriate		"permit" (allow the traffic), "reject" (drop with appropriate
	notification to sender), and "drop" (drop with no notification to		notification to sender), and "drop" (drop with no notification to
	sender).		sender).
	Supported Practices.		Supported Practices.
	* Data Origin Authentication ([I-D.ietf-opsec-current-practices],		* Data Origin Authentication ([RFC4778], Section 2.3.3)
	Section 2.3.3)
	Current Implementations.		Current Implementations.
	Assume that your management devices for deployed networking		Assume that your management devices for deployed networking
	devices live on several subnets, use several protocols, and are		devices live on several subnets, use several protocols, and are
	controlled by several different parts of your organization. There		controlled by several different parts of your organization. There
	might exist a reason to have disparate policies for access to the		might exist a reason to have disparate policies for access to the
	devices from these parts of the organization.		devices from these parts of the organization.
	Actions such as "permit", "reject", and "drop" are essential in		Actions such as "permit", "reject", and "drop" are essential in
	skipping to change at page 15, line 18		skipping to change at page 14, line 13
	actions include "transmit" (permit the traffic because it's below		actions include "transmit" (permit the traffic because it's below
	the specified limit), "limit" (limit traffic because it exceeds		the specified limit), "limit" (limit traffic because it exceeds
	the specified limit). Limits should be applicable by both bits		the specified limit). Limits should be applicable by both bits
	per second and packets per timeframe (possible timeframes might		per second and packets per timeframe (possible timeframes might
	include second, minute, hour). Limits should able to be placed in		include second, minute, hour). Limits should able to be placed in
	both inbound and outbound directions.		both inbound and outbound directions.
	Supported Practices.		Supported Practices.
	* Denial of Service Tracking/Tracing with Rate Limiting		* Denial of Service Tracking/Tracing with Rate Limiting
	([I-D.ietf-opsec-current-practices], Section 2.8.4)		([RFC4778], Section 2.8.4)
	Current Implementations.		Current Implementations.
	Assume that your management devices for deployed networking		Assume that your management devices for deployed networking
	devices live on several subnets, use several protocols, and are		devices live on several subnets, use several protocols, and are
	controlled by several different parts of your organization. There		controlled by several different parts of your organization. There
	might exist a reason to have disparate policies for access to the		might exist a reason to have disparate policies for access to the
	devices from these parts of the organization with respect to		devices from these parts of the organization with respect to
	priority access to these services. Rate Limits may be used to		priority access to these services. Rate Limits may be used to
	enforce these prioritizations.		enforce these prioritizations.
	skipping to change at page 16, line 10		skipping to change at page 15, line 4
	Capability.		Capability.
	It is possible to log all filter actions. The logging capability		It is possible to log all filter actions. The logging capability
	is able to capture at least the following data:		is able to capture at least the following data:
	* permit/reject/drop status		* permit/reject/drop status
	* source and destination IP address		* source and destination IP address
	* source and destination ports (if applicable to the protocol)		* source and destination ports (if applicable to the protocol)
	* which network element received or was sending the packet		* which network element received or was sending the packet
	(interface, MAC address or other layer 2 information that		(interface, MAC address or other layer 2 information that
	identifies the previous hop source of the packet).		identifies the previous hop source of the packet).
	Supported Practices.		Supported Practices.
	* Logging Security Practices([I-D.ietf-opsec-current-practices],		* Logging Security Practices([RFC4778], Section 2.6.2)
	Section 2.6.2)
	Current Implementations.		Current Implementations.
	Actions such as "permit", "reject", "drop" are essential in		Actions such as "permit", "reject", "drop" are essential in
	defining the security policy for the services offered by the		defining the security policy for the services offered by the
	network devices. Auditing the frequency, sources and destinations		network devices. Auditing the frequency, sources and destinations
	of these attempts is essential for tracking ongoing issues today.		of these attempts is essential for tracking ongoing issues today.
	Considerations.		Considerations.
	skipping to change at page 16, line 45		skipping to change at page 15, line 37
	syslog or other similar network logging mechanism.		syslog or other similar network logging mechanism.
	4.4. Specify Log Granularity		4.4. Specify Log Granularity
	Capability.		Capability.
	It is possible to enable/disable logging on a per rule basis.		It is possible to enable/disable logging on a per rule basis.
	Supported Practices.		Supported Practices.
	* Logging Security Practices([I-D.ietf-opsec-current-practices],		* Logging Security Practices([RFC4778], Section 2.6.2)
	Section 2.6.2)
	Current Implementations.		Current Implementations.
	If a filter is defined that has several rules, and one of the		If a filter is defined that has several rules, and one of the
	rules denies telnet (tcp/23) connections, then it should be		rules denies telnet (tcp/23) connections, then it should be
	possible to specify that only matches on the rule that denies		possible to specify that only matches on the rule that denies
	telnet should generate a log message.		telnet should generate a log message.
	Considerations.		Considerations.
	skipping to change at page 23, line 7		skipping to change at page 22, line 7
	that may be important in certain operational environments.		that may be important in certain operational environments.
	Finally, if key infrastructure devices crash or experience severe		Finally, if key infrastructure devices crash or experience severe
	performance degradation when filtering under heavy load, or even		performance degradation when filtering under heavy load, or even
	have the reputation of doing so, it is likely that security		have the reputation of doing so, it is likely that security
	personnel will be forbidden, by policy, from using filtering in		personnel will be forbidden, by policy, from using filtering in
	ways that would otherwise be appropriate for fear that it might		ways that would otherwise be appropriate for fear that it might
	cause unnecessary service disruption.		cause unnecessary service disruption.
	7. Additional Operational Practices		7. Additional Operational Practices
	This section describes practices not covered in		This section describes practices not covered in [RFC4778]. They are
	[I-D.ietf-opsec-current-practices]. They are included here to		included here to provide justification for capabilities that
	provide justification for capabilities that reference them.		reference them.
	7.1. Profile Current Traffic		7.1. Profile Current Traffic
	This capability allows a network operator to monitor traffic across		This capability allows a network operator to monitor traffic across
	an active interface in the network at a minimal level. This helps to		an active interface in the network at a minimal level. This helps to
	determine probable cause for interface or network problems.		determine probable cause for interface or network problems.
	The ability to separate and distinguish traffic at a layer-3 or		The ability to separate and distinguish traffic at a layer-3 or
	layer-4 level allows the operator to characterize beyond simple		layer-4 level allows the operator to characterize beyond simple
	interface counters the traffic in question. This is critical because		interface counters the traffic in question. This is critical because
	skipping to change at page 25, line 9		skipping to change at page 24, line 9
	This enables the implementation of filters on whichever services are		This enables the implementation of filters on whichever services are
	necessary. To the extent that filtering causes degradation, it may		necessary. To the extent that filtering causes degradation, it may
	not be possible to apply filters that implement the appropriate		not be possible to apply filters that implement the appropriate
	policies.		policies.
	8. Security Considerations		8. Security Considerations
	General		General
	Security is the subject matter of this entire memo. The		Security is the subject matter of this entire memo. The
	capabilities listed cite practices in		capabilities listed cite practices in [RFC4778] that they are
	[I-D.ietf-opsec-current-practices] that they are intended to		intended to support. [RFC4778] defines the threat model,
	support. [I-D.ietf-opsec-current-practices] defines the threat		practices and lists justifications for each practice.
	model, practices and lists justifications for each practice.
	9. Non-normative References		9. Non-normative References
	[I-D.ietf-opsec-current-practices]
	Kaeo, M., "Operational Security Current Practices",
	draft-ietf-opsec-current-practices-04 (work in progress),
	June 2006.
	[I-D.lewis-infrastructure-security]		[I-D.lewis-infrastructure-security]
	Lewis, D., "Service Provider Infrastructure Security",		Lewis, D., "Service Provider Infrastructure Security",
	draft-lewis-infrastructure-security-00 (work in progress),		draft-lewis-infrastructure-security-00 (work in progress),
	June 2006.		June 2006.
	[I-D.savola-rtgwg-backbone-attacks]		[I-D.savola-rtgwg-backbone-attacks]
	Savola, P., "Backbone Infrastructure Attacks and		Savola, P., "Backbone Infrastructure Attacks and
	Protections", draft-savola-rtgwg-backbone-attacks-01 (work		Protections", draft-savola-rtgwg-backbone-attacks-03 (work
	in progress), June 2006.		in progress), January 2007.
	[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:		[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
	Defeating Denial of Service Attacks which employ IP Source		Defeating Denial of Service Attacks which employ IP Source
	Address Spoofing", BCP 38, RFC 2827, May 2000.		Address Spoofing", BCP 38, RFC 2827, May 2000.
	[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828,		[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828,
	May 2000.		May 2000.
	[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful",		[RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful",
	BCP 60, RFC 3360, August 2002.		BCP 60, RFC 3360, August 2002.
	[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.
			[RFC4778] Kaeo, M., "Operational Security Current Practices in
			Internet Service Provider Environments", RFC 4778,
			January 2007.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	The authors gratefully acknowledge the contributions of:		The authors gratefully acknowledge the contributions of:
	o Merike Kaeo for help aligning these capabilities with supported		o Merike Kaeo for help aligning these capabilities with supported
	practices		practices
	o The MITRE Corporation for supporting development of this document.
	NOTE: The editor's affiliation with The MITRE Corporation is
	provided for identification purposes only, and is not intended to
	convey or imply MITRE's concurrence with, or support for, the
	positions, opinions or viewpoints expressed by the editor.
	Authors' Addresses		Authors' Addresses
	Christopher L. Morrow		Christopher L. Morrow
	UUNET Technologies		UUNET Technologies
	21830 UUNet Way		21830 UUNet Way
	Ashburn, Virginia 21047		Ashburn, Virginia 21047
	U.S.A.		U.S.A.
	Phone: +1 703 886 3823		Phone: +1 703 886 3823
	Email: chris@uu.net		Email: chris@uu.net
	George M. Jones		George M. Jones
	The MITRE Corporation
	7515 Colshire Drive, M/S WEST
	McLean, Virginia 22102-7508
	U.S.A.
	Phone: +1 703 488 9740		Phone: +1 703 488 9740
	Email: gmjones@mitre.org		Email: gmj3871@pobox.com
	Vishwas Manral		Vishwas Manral
	IP Infusion		IP Infusion
	Ground Floor, 5th Cross Road, Off 8th Main Road		Ground Floor, 5th Cross Road, Off 8th Main Road
	Bangalore, 52		Bangalore, 52
	India		India
	Phone: +91-80-4113-1268		Phone: +91-80-4113-1268
	Email: vishwas@ipinfusion.com		Email: vishwas@ipinfusion.com
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	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, THE IETF TRUST AND
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE 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.
	Intellectual Property		Intellectual Property
	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
End of changes. 54 change blocks.
	148 lines changed or deleted		106 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/