< draft-ietf-opsec-current-practices-04.txt		draft-ietf-opsec-current-practices-05.txt >
	OPSEC M. Kaeo		OPSEC M. Kaeo
	Internet-Draft Double Shot Security, Inc.		Internet-Draft Double Shot Security, Inc.
	Expires: December 27, 2006 June 25, 2006		Expires: January 6, 2007 July 5, 2006
	Operational Security Current Practices		Operational Security Current Practices
	draft-ietf-opsec-current-practices-04		draft-ietf-opsec-current-practices-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 33 ¶		skipping to change at page 1, line 33 ¶
	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 December 27, 2006.		This Internet-Draft will expire on January 6, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document is a survey of the current practices used in today's		This document is a survey of the current practices used in today's
	large ISP operational networks to secure layer 2 and layer 3		large ISP operational networks to secure layer 2 and layer 3
	infrastructure devices. The information listed here is the result of		infrastructure devices. The information listed here is the result of
	skipping to change at page 2, line 21 ¶		skipping to change at page 2, line 21 ¶
	1.4. Operational Security Impact from Threats . . . . . . . . . 5		1.4. Operational Security Impact from Threats . . . . . . . . . 5
	1.5. Document Layout . . . . . . . . . . . . . . . . . . . . . 7		1.5. Document Layout . . . . . . . . . . . . . . . . . . . . . 7
	1.6. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8		1.6. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8
	2. Protected Operational Functions . . . . . . . . . . . . . . . 9		2. Protected Operational Functions . . . . . . . . . . . . . . . 9
	2.1. Device Physical Access . . . . . . . . . . . . . . . . . . 9		2.1. Device Physical Access . . . . . . . . . . . . . . . . . . 9
	2.2. Device In-Band Management . . . . . . . . . . . . . . . . 11		2.2. Device In-Band Management . . . . . . . . . . . . . . . . 11
	2.3. Device Out-of-Band Management . . . . . . . . . . . . . . 15		2.3. Device Out-of-Band Management . . . . . . . . . . . . . . 15
	2.4. Data Path . . . . . . . . . . . . . . . . . . . . . . . . 20		2.4. Data Path . . . . . . . . . . . . . . . . . . . . . . . . 20
	2.5. Routing Control Plane . . . . . . . . . . . . . . . . . . 22		2.5. Routing Control Plane . . . . . . . . . . . . . . . . . . 22
	2.6. Software Upgrades and Configuration Integrity /		2.6. Software Upgrades and Configuration Integrity /
	Validation . . . . . . . . . . . . . . . . . . . . . . . . 25		Validation . . . . . . . . . . . . . . . . . . . . . . . . 26
	2.7. Logging Considerations . . . . . . . . . . . . . . . . . . 29		2.7. Logging Considerations . . . . . . . . . . . . . . . . . . 29
	2.8. Filtering Considerations . . . . . . . . . . . . . . . . . 32		2.8. Filtering Considerations . . . . . . . . . . . . . . . . . 32
	2.9. Denial of Service Tracking / Tracing . . . . . . . . . . . 33		2.9. Denial of Service Tracking / Tracing . . . . . . . . . . . 33
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 35		3. Security Considerations . . . . . . . . . . . . . . . . . . . 35
	4. Normative References . . . . . . . . . . . . . . . . . . . . . 35		4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 36		4.1. Normative References . . . . . . . . . . . . . . . . . . . 36
	Appendix B. Protocol Specific Attacks . . . . . . . . . . . . . . 37		4.2. Informational References . . . . . . . . . . . . . . . . . 36
	B.1. Layer 2 Attacks . . . . . . . . . . . . . . . . . . . . . 37		Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 37
	B.2. IPv4 Attacks . . . . . . . . . . . . . . . . . . . . . . . 37		Appendix B. Protocol Specific Attacks . . . . . . . . . . . . . . 38
	B.3. IPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . . 38		B.1. Layer 2 Attacks . . . . . . . . . . . . . . . . . . . . . 38
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 39		B.2. IPv4 Attacks . . . . . . . . . . . . . . . . . . . . . . . 38
	Intellectual Property and Copyright Statements . . . . . . . . . . 40		B.3. IPv6 Attacks . . . . . . . . . . . . . . . . . . . . . . . 39
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 41
			Intellectual Property and Copyright Statements . . . . . . . . . . 42
	1. Introduction		1. Introduction
	Security practices are well understood by the network operators who		Security practices are well understood by the network operators who
	have for many years gone through the growing pains of securing their		have for many years gone through the growing pains of securing their
	network infrastructures. However, there does not exist a written		network infrastructures. However, there does not exist a written
	document that enumerates these security practices. Network attacks		document that enumerates these security practices. Network attacks
	are continually increasing and although it is not necessarily the		are continually increasing and although it is not necessarily the
	role of an ISP to act as the Internet police, each ISP has to ensure		role of an ISP to act as the Internet police, each ISP has to ensure
	that certain security practices are followed to ensure that their		that certain security practices are followed to ensure that their
	skipping to change at page 20, line 50 ¶		skipping to change at page 20, line 50 ¶
	2.4.2. Security Practices		2.4.2. Security Practices
	Filtering and rate limiting are the primary mechanism to provide risk		Filtering and rate limiting are the primary mechanism to provide risk
	mitigation of malicious traffic rendering the ISP services		mitigation of malicious traffic rendering the ISP services
	unavailable. However, filtering and rate limiting of data path		unavailable. However, filtering and rate limiting of data path
	traffic is deployed in a variety of ways depending on how automated		traffic is deployed in a variety of ways depending on how automated
	the process is and what the capabilities and performance limitations		the process is and what the capabilities and performance limitations
	of existing deployed hardware are.		of existing deployed hardware are.
	The ISPs which do not have performance issues with their equipment		The ISPs which do not have performance issues with their equipment
	follow BCP38 [BCP38] and BCP84 [BCP84] guidelines. Null routes and		follow BCP38 [RFC2827] and BCP84 [RFC3704] guidelines for ingress
	black-hole triggered routing [BHTR] are used to deter any detected		filtering. BCP38 recommends filtering ingress packets with obviously
	malicious traffic streams. Most ISPs consider layer 4 filtering		spoofed and/or 'reserved' source addresses to limit the effects of
	useful but it is only implemented if performance limitations allow		denial of service attacks while BCP84 extends the recommendation for
	for it. Layer 4 filtering is typically only when no other option		multi-homed environments. Null routes and black-hole triggered
	exists since it does pose a large administrative overhead and ISPs		routing are used to deter any detected malicious traffic streams.
	are very much opposed to acting as the Internet firewall. Netflow is		These techniques are described in more detail in section 2.9 below.
	used for tracking traffic flows but there is some concern whether
	sampling is good enough to detect malicious behavior.		Most ISPs consider layer 4 filtering useful but it is only
			implemented if performance limitations allow for it. Layer 4
			filtering is typically only when no other option exists since it does
			pose a large administrative overhead and ISPs are very much opposed
			to acting as the Internet firewall. Netflow is used for tracking
			traffic flows but there is some concern whether sampling is good
			enough to detect malicious behavior.
	Unicast RPF is not consistently implemented. Some ISPs are in		Unicast RPF is not consistently implemented. Some ISPs are in
	process of doing so while other ISPs think that the perceived benefit		process of doing so while other ISPs think that the perceived benefit
	of knowing that spoofed traffic comes from legitimate addresses are		of knowing that spoofed traffic comes from legitimate addresses are
	not worth the operational complexity. Some providers have a policy		not worth the operational complexity. Some providers have a policy
	of implementing uRPF at link speeds of DS3 and below.		of implementing uRPF at link speeds of DS3 and below.
	2.4.3. Security Services		2.4.3. Security Services
	o User Authentication - Not applicable		o User Authentication - Not applicable
	skipping to change at page 24, line 14 ¶		skipping to change at page 24, line 19 ¶
	2.5.7. Security Practices		2.5.7. Security Practices
	Securing the routing control plane takes many features which are		Securing the routing control plane takes many features which are
	generally deployed as a system. MD5 authentication is used by some		generally deployed as a system. MD5 authentication is used by some
	ISPs to validate the sending peer and to ensure that the data in		ISPs to validate the sending peer and to ensure that the data in
	transit has not been altered. Some ISPs only deploy MD5		transit has not been altered. Some ISPs only deploy MD5
	authentication at customer's request. Additional sanity checks to		authentication at customer's request. Additional sanity checks to
	ensure with reasonable certainty that the received routing update was		ensure with reasonable certainty that the received routing update was
	originated by a valid routing peer include route filters and the		originated by a valid routing peer include route filters and the
	Generalized TTL Security Mechanism (GTSM) feature [GTSM] (sometimes		Generalized TTL Security Mechanism (GTSM) feature [RFC3682]
	also referred to as the TTL-Hack). Note that validating whether a		(sometimes also referred to as the TTL-Hack). Note that validating
	legitimate peer has the authority to send the contents of the routing		whether a legitimate peer has the authority to send the contents of
	update is a difficult problem that needs yet to be resolved.		the routing update is a difficult problem that needs yet to be
			resolved.
	In the case of BGP routing, a variety of policies are deployed to		In the case of BGP routing, a variety of policies are deployed to
	limit the propagation of invalid routing information. These include:		limit the propagation of invalid routing information. These include:
	incoming and outgoing prefix filters for BGP customers, incoming and		incoming and outgoing prefix filters for BGP customers, incoming and
	outgoing prefix filters for peers and upstream neighbors, incoming		outgoing prefix filters for peers and upstream neighbors, incoming
	AS-PATH filter for BGP customers, outgoing AS-PATH filter towards		AS-PATH filter for BGP customers, outgoing AS-PATH filter towards
	peers and upstream neighbors, route dampening and rejecting selected		peers and upstream neighbors, route dampening and rejecting selected
	attributes and communities. Consistency between these policies		attributes and communities. Consistency between these policies
	varies greatly although there is a trend to start depending on AS-		varies greatly although there is a trend to start depending on AS-
	PATH filters because they are much more manageable than the large		PATH filters because they are much more manageable than the large
	skipping to change at page 31, line 47 ¶		skipping to change at page 32, line 11 ¶
	o Access Control - Filtering on logging host and server IP address		o Access Control - Filtering on logging host and server IP address
	to ensure that syslog information only goes to specific syslog		to ensure that syslog information only goes to specific syslog
	hosts.		hosts.
	o Data Integrity - Not implemented		o Data Integrity - Not implemented
	o Data Confidentiality - Not implemented		o Data Confidentiality - Not implemented
	o Auditing / Logging - This entire section deals with logging.		o Auditing / Logging - This entire section deals with logging.
	o DoS Mitigation - Logs are useful in providing traceback		o DoS Mitigation - An OOB management system is used and sometimes
	information to potentially trace the attack to as close to the		different syslog servers are used for logging information from
	source as possible.		varying equipment. Exception logging tries to keep information to
			a minimum.
	2.7.4. Additional Considerations		2.7.4. Additional Considerations
	There is no security with syslog and ISPs are fully cognizant of		There is no security with syslog and ISPs are fully cognizant of
	this. IPsec is considered too operationally expensive and cumbersome		this. IPsec is considered too operationally expensive and cumbersome
	to deploy. Syslog-ng and stunnel are being looked at for providing		to deploy. Syslog-ng and stunnel are being looked at for providing
	better authenticated and integrity protected solutions. Mechanisms		better authenticated and integrity protected solutions. Mechanisms
	to prevent unauthorized personnel from tampering with logs is		to prevent unauthorized personnel from tampering with logs is
	constrained to auditing who has access to the logging servers and		constrained to auditing who has access to the logging servers and
	files.		files.
	skipping to change at page 32, line 34 ¶		skipping to change at page 32, line 45 ¶
	sections, this section will provide some more insights to the		sections, this section will provide some more insights to the
	filtering considerations that are currently being taken into account.		filtering considerations that are currently being taken into account.
	Filtering is now being categorized into three specific areas: data		Filtering is now being categorized into three specific areas: data
	plane, management plane and routing control plane.		plane, management plane and routing control plane.
	2.8.1. Data Plane Filtering		2.8.1. Data Plane Filtering
	Data plane filters control the traffic that traverses through a		Data plane filters control the traffic that traverses through a
	device and affect transit traffic. Most ISPs deploy these kinds of		device and affect transit traffic. Most ISPs deploy these kinds of
	filters at the customer facing edge devices to mitigate spoofing		filters at the customer facing edge devices to mitigate spoofing
	attacks.		attacks using BCP38 and BCP84 guidelines.
	2.8.2. Management Plane Filtering		2.8.2. Management Plane Filtering
	Management filters control the traffic to and from a device. All of		Management filters control the traffic to and from a device. All of
	the protocols which are used for device management fall under this		the protocols which are used for device management fall under this
	category and includes SSH, Telnet, SNMP, NTP, http, DNS, TFTP, FTP,		category and includes SSH, Telnet, SNMP, NTP, HTTP, DNS, TFTP, FTP,
	SCP and Syslog. This type of traffic is often filtered per interface		SCP and Syslog. This type of traffic is often filtered per interface
	and is based on any combination of protocol, source and destination		and is based on any combination of protocol, source and destination
	IP address and source and destination port number. Some devices		IP address and source and destination port number. Some devices
	support functionality to apply management filters to the device		support functionality to apply management filters to the device
	rather than to the specific interfaces (e.g. receive ACL or loopback		rather than to the specific interfaces (e.g. receive ACL or loopback
	interface ACL) which is gaining wider acceptance. Note that logging		interface ACL) which is gaining wider acceptance. Note that logging
	the filtering rules can today place a burden on many systems and more		the filtering rules can today place a burden on many systems and more
	granularity is often required to more specifically log the required		granularity is often required to more specifically log the required
	exceptions.		exceptions.
			Any services that are not specifically used are turned off.
	IPv6 networks require the use of specific ICMP messages for proper		IPv6 networks require the use of specific ICMP messages for proper
	protocol operation. Therefore, ICMP cannot be completely filtered to		protocol operation. Therefore, ICMP cannot be completely filtered to
	and from a device. Instead, granular ICMPv6 filtering is always		and from a device. Instead, granular ICMPv6 filtering is always
	deployed to allow for specific ICMPv6 types to be sourced or destined		deployed to allow for specific ICMPv6 types to be sourced or destined
	to a network device.		to a network device. A good guideline for IPv6 filtering is in the
			draft work in progress on Best Current Practices for Filtering ICMPv6
			Messages in Firewalls [I-D.ietf-v6ops-icmpv6-filtering-bcp].
	2.8.3. Routing Control Plane Filtering		2.8.3. Routing Control Plane Filtering
	Routing filters are used to control the flow of routing information.		Routing filters are used to control the flow of routing information.
	In IPv6 networks, some providers are liberal in accepting /48s due to		In IPv6 networks, some providers are liberal in accepting /48s due to
	the still unresolved multihoming issues. Any announcement received		the still unresolved multihoming issues. Any announcement received
	that is longer than a /48 for IPv6 routing and a /24 for IPv4 routing		that is longer than a /48 for IPv6 routing and a /24 for IPv4 routing
	is filtered out of eBGP. Note that this is for non-customer traffic.		is filtered out of eBGP. Note that this is for non-customer traffic.
	Most ISPs will accept any agreed upon prefix length from its		Most ISPs will accept any agreed upon prefix length from its
	customer(s).		customer(s).
	skipping to change at page 33, line 45 ¶		skipping to change at page 34, line 14 ¶
	2.9.1. Sink Hole Routing		2.9.1. Sink Hole Routing
	Sink hole routing refers to injecting a more specific route for any		Sink hole routing refers to injecting a more specific route for any
	known attack traffic which will ensure that the malicious traffic is		known attack traffic which will ensure that the malicious traffic is
	redirected to a valid device or specific system where it can be		redirected to a valid device or specific system where it can be
	analyzed.		analyzed.
	2.9.2. Black-Hole Triggered Routing		2.9.2. Black-Hole Triggered Routing
	Black-hole triggered routing is a technique where the BGP routing		Black-hole triggered routing (also referred to as Remote Triggered
	protocol is used to propagate routes which in turn redirects attack		Black Hole Filtering) is a technique where the BGP routing protocol
	traffic to the null interface where it is effectively dropped. This		is used to propagate routes which in turn redirects attack traffic to
	technique is often used in large routing infrastructures since BGP		the null interface where it is effectively dropped. This technique
	can propagate the information in a fast effective manner as opposed		is often used in large routing infrastructures since BGP can
	to using any packet-based filtering techniques on hundreds or		propagate the information in a fast effective manner as opposed to
	thousands of routers.		using any packet-based filtering techniques on hundreds or thousands
			of routers. [refer to the following NANOG presentation for a more
			complete description http://www.nanog.org/mtg-0402/pdf/morrow.pdf]
	2.9.3. Unicast Reverse Path Forwarding		2.9.3. Unicast Reverse Path Forwarding
	Unicast Reverse Path Forwarding (uRPF) is a mechanism for validating		Unicast Reverse Path Forwarding (uRPF) is a mechanism for validating
	whether an incoming packet has a legitimate source address or not.		whether an incoming packet has a legitimate source address or not.
	It has two modes: strict mode and loose mode. In strict mode, uRPF		It has two modes: strict mode and loose mode. In strict mode, uRPF
	checks whether the incoming packet has a source address that matches		checks whether the incoming packet has a source address that matches
	a prefix in the routing table, and whether the interface expects to		a prefix in the routing table, and whether the interface expects to
	receive a packet with this source address prefix. If the incoming		receive a packet with this source address prefix. If the incoming
	packet fails the unicast RPF check, the packet is not accepted on the		packet fails the unicast RPF check, the packet is not accepted on the
	skipping to change at page 35, line 8 ¶		skipping to change at page 35, line 8 ¶
	SYN attack where a large number of resources get allocated for		SYN attack where a large number of resources get allocated for
	spoofed TCP traffic. Although this technique does not stop an		spoofed TCP traffic. Although this technique does not stop an
	attack, it can sometimes lessen the damage and impact on a specific		attack, it can sometimes lessen the damage and impact on a specific
	service. However, it can also make the impact of a DDoS attack much		service. However, it can also make the impact of a DDoS attack much
	worse if the rate limiting is impacting (i.e. discarding) more		worse if the rate limiting is impacting (i.e. discarding) more
	legitimate traffic.		legitimate traffic.
	3. Security Considerations		3. Security Considerations
	This entire document deals with current security practices in large		This entire document deals with current security practices in large
	ISP environments. As a synopsis, a table is shown below which		ISP environments. It lists specific practices used in today's
	summarizes the operational functions which are to be protected and		environments and as such does not in itself pose any security risk.
	the security services which currently deployed security practices
	offer: [ Table to be added ]
	4. Normative References		4. References
			4.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC2827] 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.
	[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828,		[RFC2828] Shirey, R., "Internet Security Glossary", RFC 2828,
	May 2000.		May 2000.
	[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC		[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
	Text on Security Considerations", BCP 72, RFC 3552,		Text on Security Considerations", BCP 72, RFC 3552,
	July 2003.		July 2003.
			[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL
			Security Mechanism (GTSM)", RFC 3682, February 2004.
			[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
			Networks", BCP 84, RFC 3704, March 2004.
			4.2. Informational References
			[I-D.ietf-v6ops-icmpv6-filtering-bcp]
			Davies, E. and J. Mohacsi, "Best Current Practice for
			Filtering ICMPv6 Messages in Firewalls",
			draft-ietf-v6ops-icmpv6-filtering-bcp-01 (work in
			progress), March 2006.
			[I-D.lewis-infrastructure-security]
			Lewis, D., "Service Provider Infrastructure Security",
			draft-lewis-infrastructure-security-00 (work in progress),
			June 2006.
			[I-D.savola-bcp84-urpf-experiences]
			Savola, P., "Experiences from Using Unicast RPF",
			draft-savola-bcp84-urpf-experiences-01 (work in progress),
			June 2006.
			[I-D.savola-rtgwg-backbone-attacks]
			Savola, P., "Backbone Infrastructure Attacks and
			Protections", draft-savola-rtgwg-backbone-attacks-01 (work
			in progress), June 2006.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	The editor gratefully acknowledges the contributions of: George		The editor gratefully acknowledges the contributions of: George
	Jones, who has been instrumental in providing guidance and direction		Jones, who has been instrumental in providing guidance and direction
	for this document and the insighful comments from Ross Callon, Ron		for this document and the insighful comments from Ross Callon, Ron
	Bonica, Gaurab Upadhaya, Warren Kumari and the numerous ISP operators		Bonica, Gaurab Upadhaya, Warren Kumari and the numerous ISP operators
	who supplied the information which is depicted in this document.		who supplied the information which is depicted in this document.
	Appendix B. Protocol Specific Attacks		Appendix B. Protocol Specific Attacks
	This section will enumerate many of the traditional protocol based		This section will list many of the traditional protocol based attacks
	attacks which have been observed over the years to cause malformed		which have been observed over the years to cause malformed packets
	packets and/or exploit protocol deficiencies.		and/or exploit protocol deficiencies. Note that they all exploit
			vulnerabilities in the actual protocol itself and often, additional
			authentication and auditing mechanisms are now used to detect and
			mitigate the impact of these attacks. The list is not exhaustive but
			is a fraction of the representation of what types of attacks are
			possible for varying protocols.
	B.1. Layer 2 Attacks		B.1. Layer 2 Attacks
	o ARP Flooding		o ARP Flooding
	B.2. IPv4 Attacks		B.2. IPv4 Attacks
	o IP Stream Option		o IP Stream Option
	o IP Address Spoofing		o IP Address Spoofing
	o IP Source Route Option		o IP Source Route Option
	o IP Short header		o IP Short header
	o IP Malformed Packet		o IP Malformed Packet
	o Ip Bad Option		o IP Bad Option
	o Ip Address Session Limit		o IP Address Session Limit
	o Fragmenmts - too many		o Fragments - too many
	o Fragments - large offset		o Fragments - large offset
	o Fragments - same offset		o Fragments - same offset
	o Fragments - reassembly with different offsets (TearDrop Attac)		o Fragments - reassembly with different offsets (TearDrop Attac)
	o Fragments - reassembly off by one IP header (Nestea Attack)		o Fragments - reassembly off by one IP header (Nestea Attack)
	o Fragment - flooding only initial fragment (Rose Attack)		o Fragment - flooding only initial fragment (Rose Attack)
	skipping to change at page 38, line 34 ¶		skipping to change at page 39, line 40 ¶
	o SYN Flood		o SYN Flood
	o SYN with IP Spoofing (Land Attack)		o SYN with IP Spoofing (Land Attack)
	o SYN and FIN bits set		o SYN and FIN bits set
	o TCP port scan attack		o TCP port scan attack
	o UDP spoofed broadcast echo (Fraggle Attack)		o UDP spoofed broadcast echo (Fraggle Attack)
	o UDP attack on diag ports (Pepsi Attack)		o UDP attack on diagnostic ports (Pepsi Attack)
	B.3. IPv6 Attacks		B.3. IPv6 Attacks
	Any of the above-mentioned IPv4 attacks could be used in IPv6		Any of the above-mentioned IPv4 attacks could be used in IPv6
	networks with the exception of any fragmentation and broadcast		networks with the exception of any fragmentation and broadcast
	traffic, which operate differently in IPv6.		traffic, which operate differently in IPv6. Note that all of these
			attacks are based on either spoofing or misusing any part of the
			protocol field(s).
	Today, IPv6 enabled hosts are starting to be used to create IPv6		Today, IPv6 enabled hosts are starting to be used to create IPv6
	tunnels which can effectively hide botnet and other malicious traffic		tunnels which can effectively hide botnet and other malicious traffic
	if firewalls and network flow collection tools are not capable of		if firewalls and network flow collection tools are not capable of
	detecting this traffic.		detecting this traffic. The security measures used for protecting
			IPv6 infrastructures should be the same as in IPv4 networks but with
			additional considerations for IPv6 network operations which may be
			different from IPv4.
	Author's Address		Author's Address
	Merike Kaeo		Merike Kaeo
	Double Shot Security, Inc.		Double Shot Security, Inc.
	3518 Fremont Avenue North #363		3518 Fremont Avenue North #363
	Seattle, WA 98103		Seattle, WA 98103
	U.S.A.		U.S.A.
	Phone: +1 310 866 0165		Phone: +1 310 866 0165
End of changes. 24 change blocks.
	52 lines changed or deleted		111 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/