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.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/