draft-ietf-v6ops-security-overview-00.txt   draft-ietf-v6ops-security-overview-01.txt 
IPv6 Operations E. Davies IPv6 Operations E. Davies
Internet-Draft Consultant Internet-Draft Consultant
Expires: November 13, 2005 S. Krishnan Expires: January 6, 2006 S. Krishnan
Ericsson Ericsson
P. Savola P. Savola
CSC/Funet CSC/Funet
May 12, 2005 July 5, 2005
IPv6 Transition/Co-existence Security Considerations IPv6 Transition/Co-existence Security Considerations
draft-ietf-v6ops-security-overview-00.txt draft-ietf-v6ops-security-overview-01.txt
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 November 13, 2005. This Internet-Draft will expire on January 6, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
The transition from a pure IPv4 network to a network where IPv4 and The transition from a pure IPv4 network to a network where IPv4 and
IPv6 co-exist brings a number of extra security considerations that IPv6 co-exist brings a number of extra security considerations that
need to be taken into account when deploying IPv6 and operating the need to be taken into account when deploying IPv6 and operating the
skipping to change at page 2, line 27 skipping to change at page 2, line 27
2.1.4 ICMPv6 and Multicast . . . . . . . . . . . . . . . . . 6 2.1.4 ICMPv6 and Multicast . . . . . . . . . . . . . . . . . 6
2.1.5 Anycast Traffic Identification and Security . . . . . 7 2.1.5 Anycast Traffic Identification and Security . . . . . 7
2.1.6 Address Privacy Extensions Interact with DDoS 2.1.6 Address Privacy Extensions Interact with DDoS
Defenses . . . . . . . . . . . . . . . . . . . . . . . 7 Defenses . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.7 Dynamic DNS: Stateless Address Auto-Configuration, 2.1.7 Dynamic DNS: Stateless Address Auto-Configuration,
Privacy Extensions and SEND . . . . . . . . . . . . . 8 Privacy Extensions and SEND . . . . . . . . . . . . . 8
2.1.8 Extension Headers . . . . . . . . . . . . . . . . . . 8 2.1.8 Extension Headers . . . . . . . . . . . . . . . . . . 8
2.1.9 Fragmentation: Reassembly and Deep Packet Inspection . 10 2.1.9 Fragmentation: Reassembly and Deep Packet Inspection . 10
2.1.10 Fragmentation Related DoS Attacks . . . . . . . . . 11 2.1.10 Fragmentation Related DoS Attacks . . . . . . . . . 11
2.1.11 Link-Local Addresses and Securing Neighbor 2.1.11 Link-Local Addresses and Securing Neighbor
Discovery . . . . . . . . . . . . . . . . . . . . . 11 Discovery . . . . . . . . . . . . . . . . . . . . . 12
2.1.12 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . 13 2.1.12 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . 13
2.2 IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . 13 2.2 IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . 14
2.3 Increased End-to-End Transparency . . . . . . . . . . . . 14 2.3 Increased End-to-End Transparency . . . . . . . . . . . . 15
2.3.1 IPv6 Networks without NATs . . . . . . . . . . . . . . 14 2.3.1 IPv6 Networks without NATs . . . . . . . . . . . . . . 15
2.3.2 Enterprise Network Security Model for IPv6 . . . . . . 15 2.3.2 Enterprise Network Security Model for IPv6 . . . . . . 15
3. Issues Due to Transition Mechanisms . . . . . . . . . . . . 16 3. Issues Due to Transition Mechanisms . . . . . . . . . . . . 17
3.1 IPv6 Transition/Co-existence Mechanism-specific Issues . . 16 3.1 IPv6 Transition/Co-existence Mechanism-specific Issues . . 17
3.2 Automatic Tunneling and Relays . . . . . . . . . . . . . . 16 3.2 Automatic Tunneling and Relays . . . . . . . . . . . . . . 17
3.3 Tunneling May Break Security Assumptions . . . . . . . . . 17 3.3 Tunneling May Break Security Assumptions . . . . . . . . . 18
4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . 18 4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . 19
4.1 IPv6 Service Piloting Done Insecurely . . . . . . . . . . 18 4.1 IPv6 Service Piloting Done Insecurely . . . . . . . . . . 19
4.2 Enabling IPv6 by Default Reduces Usability . . . . . . . . 19 4.2 Enabling IPv6 by Default Reduces Usability . . . . . . . . 20
4.3 Addressing Schemes and Securing Routers . . . . . . . . . 20 4.3 Addressing Schemes and Securing Routers . . . . . . . . . 21
4.4 Consequences of Multiple Addresses in IPv6 . . . . . . . . 20 4.4 Consequences of Multiple Addresses in IPv6 . . . . . . . . 21
4.5 Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 21 4.5 Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 22
4.5.1 Problems Resulting from ICMPv6 Transparency . . . . . 22 4.5.1 Problems Resulting from ICMPv6 Transparency . . . . . 23
4.6 IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 22 4.6 IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 23
4.7 Reduced Functionality Devices . . . . . . . . . . . . . . 23 4.7 Reduced Functionality Devices . . . . . . . . . . . . . . 23
4.8 Operational Factors when Enabling IPv6 in the Network . . 23 4.8 Operational Factors when Enabling IPv6 in the Network . . 24
4.9 Ingress Filtering Issues Due to Privacy Addresses . . . . 24 4.9 Ingress Filtering Issues Due to Privacy Addresses . . . . 25
4.10 Security Issues Due to ND Proxies . . . . . . . . . . . 24 4.10 Security Issues Due to ND Proxies . . . . . . . . . . . 25
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . 25 6. Security Considerations . . . . . . . . . . . . . . . . . . 25
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
7.1 Normative References . . . . . . . . . . . . . . . . . . . 25 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.2 Informative References . . . . . . . . . . . . . . . . . . 26 8.1 Normative References . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 8.2 Informative References . . . . . . . . . . . . . . . . . . 27
A. IPv6 Probing/Mapping Considerations . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
B. IPv6 Privacy Considerations . . . . . . . . . . . . . . . . 30 A. IPv6 Probing/Mapping Considerations . . . . . . . . . . . . 30
B.1 Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 30 B. IPv6 Privacy Considerations . . . . . . . . . . . . . . . . 31
B.2 Exposing Multiple Devices . . . . . . . . . . . . . . . . 31 B.1 Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 32
B.3 Exposing the Site by a Stable Prefix . . . . . . . . . . . 31 B.2 Exposing Multiple Devices . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . 32 B.3 Exposing the Site by a Stable Prefix . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . 34
1. Introduction 1. Introduction
The transition from a pure IPv4 network to a network where IPv4 and The transition from a pure IPv4 network to a network where IPv4 and
IPv6 co-exist brings a number of extra security considerations that IPv6 co-exist brings a number of extra security considerations that
need to be taken into account when deploying IPv6 and operating the need to be taken into account when deploying IPv6 and operating the
dual-protocol network with its associated transition mechanisms. dual-protocol network with its associated transition mechanisms.
This document attempts to give an overview of the various issues This document attempts to give an overview of the various issues
grouped into three categories: grouped into three categories:
o issues due to the IPv6 protocol itself, o issues due to the IPv6 protocol itself,
o issues due to transition mechanisms, and o issues due to transition mechanisms, and
o issues due to IPv6 deployment. o issues due to IPv6 deployment.
It is important to understand that we have to be concerned not about It is important to understand that we have to be concerned not about
replacing IPv4 with IPv6 (in the short term), but with adding IPv6 to replacing IPv4 with IPv6 (in the short term), but with adding IPv6 to
be operated in parallel with IPv4 [I-D.savola-v6ops-transarch]. be operated in parallel with IPv4 [I-D.savola-v6ops-transarch].
This document also describes two matters which have have been wrongly This document also describes two matters which have been wrongly
identified as potential security concerns for IPv6 in the past and identified as potential security concerns for IPv6 in the past and
explains why they are unlikely to cause problems: considerations explains why they are unlikely to cause problems: considerations
about probing/mapping IPv6 addresses (Appendix A), and considerations about probing/mapping IPv6 addresses (Appendix A), and considerations
with respect to privacy in IPv6 (Appendix B). with respect to privacy in IPv6 (Appendix B).
2. Issues Due to IPv6 Protocol 2. Issues Due to IPv6 Protocol
2.1 IPv6 Protocol-specific Issues 2.1 IPv6 Protocol-specific Issues
There are significant differences between the features of IPv6 and There are significant differences between the features of IPv6 and
IPv4: some of these specification changes may result in potential IPv4: some of these specification changes may result in potential
security issues. Several of these issues have been discussed in security issues. Several of these issues have been discussed in
separate drafts but are summarised here to avoid normative references separate drafts but are summarized here to avoid normative references
which may not become RFCs. The following specification-related which may not become RFCs. The following specification-related
problems have been identified, but this is not necessarily a complete problems have been identified, but this is not necessarily a complete
list: list:
2.1.1 Routing Headers and Hosts 2.1.1 Routing Headers and Hosts
All IPv6 nodes must be able to process Routing Headers [RFC2460]. All IPv6 nodes must be able to process Routing Headers [RFC2460].
This RFC can be interpreted, although it is not clearly stated, to This RFC can be interpreted, although it is not clearly stated, to
mean that all nodes (including hosts) must have this processing mean that all nodes (including hosts) must have this processing
enabled. This can result in hosts forwarding received traffic if enabled. This can result in hosts forwarding received traffic if
skipping to change at page 5, line 7 skipping to change at page 5, line 7
host. host.
A number of potential security issues associated with this behavior A number of potential security issues associated with this behavior
were documented in [I-D.savola-ipv6-rh-hosts]. Some of these issues were documented in [I-D.savola-ipv6-rh-hosts]. Some of these issues
have been resolved (a separate routing header type is now used for have been resolved (a separate routing header type is now used for
Mobile IPv6 [RFC3775] and ICMP Traceback has not been standardized), Mobile IPv6 [RFC3775] and ICMP Traceback has not been standardized),
but two issues remain: but two issues remain:
o Routing headers can be used to evade access controls based on o Routing headers can be used to evade access controls based on
destination addresses. This could be achieved by sending a packet destination addresses. This could be achieved by sending a packet
ostensibly to a publically accessible host address but with a ostensibly to a publicly accessible host address but with a
routing header which will cause the publically accessible host to routing header containing a 'forbidden' address. If the publicly
forward the packet to a destination which would have been accessible host is processing routing headers it will forward the
forbidden by the packet filters if the address had been in the packet to the destination address in the routing header which
destination field when the packet was checked. would have been forbidden by the packet filters if the address had
been in the destination field when the packet was checked.
o If the packet source address in the previous case can be spoofed, o If the packet source address in the previous case can be spoofed,
any host could be used to mediate an anonymous reflection denial- any host could be used to mediate an anonymous reflection denial-
of-service attack by having any publically accessible host of-service attack by having any publicly accessible host redirect
redirect the attack packets. the attack packets.
2.1.2 Routing Headers for Mobile IPv6 and Other Purposes 2.1.2 Routing Headers for Mobile IPv6 and Other Purposes
In addition to the basic Routing Header (Type 0), which is intended In addition to the basic Routing Header (Type 0), which is intended
to influence the trajectory of a packet through a network by to influence the trajectory of a packet through a network by
specifying a sequence of router 'waypoints', Routing Header (Type 2) specifying a sequence of router 'waypoints', Routing Header (Type 2)
has been defined as part of the Mobile IPv6 specifications in has been defined as part of the Mobile IPv6 specifications in
[RFC3775]. The Type 2 Routing Header is intended for use by hosts to [RFC3775]. The Type 2 Routing Header is intended for use by hosts to
handle 'interface local' forwarding needed when packets are sent to handle 'interface local' forwarding needed when packets are sent to
the care-of address of a mobile node which is away from its home the care-of address of a mobile node which is away from its home
address. address.
It is important that nodes treat the different types of routing It is important that nodes treat the different types of routing
header appropriately. It should be possible to apply separate header appropriately. It should be possible to apply separate
filtering rules to the different types of Routing Header. By design filtering rules to the different types of Routing Header. By design,
hosts must process Type 2 Routing Headers to support Mobile IPv6 but hosts must process Type 2 Routing Headers to support Mobile IPv6 but
routers should not: to avoid the issues in Section 2.1.1 it may be routers should not: to avoid the issues in Section 2.1.1 it may be
desirable to forbid or limit the processing of Type 0 Routing Headers desirable to forbid or limit the processing of Type 0 Routing Headers
in hosts and some routers. in hosts and some routers.
Routing Headers are an extremely powerful and general capability. Routing Headers are an extremely powerful and general capability.
Alternative future uses of Routing Headers need to be carefully Alternative future uses of Routing Headers need to be carefully
assessed to ensure that they do not open new avenues of attack that assessed to ensure that they do not open new avenues of attack that
can be exploited. can be exploited.
skipping to change at page 6, line 7 skipping to change at page 6, line 8
Particular examples are the 'all routers' (FF05::2) and 'all DHCP Particular examples are the 'all routers' (FF05::2) and 'all DHCP
servers' (FF05::1:3) addresses defined in [RFC2375]: an attacker that servers' (FF05::1:3) addresses defined in [RFC2375]: an attacker that
is able to infiltrate a message destined for these addresses on to is able to infiltrate a message destined for these addresses on to
the site will potentially receive in return information identifying the site will potentially receive in return information identifying
key resources on the site. This information can then be the target key resources on the site. This information can then be the target
of directed attacks ranging from simple flooding to more specific of directed attacks ranging from simple flooding to more specific
mechanisms designed to subvert the device. mechanisms designed to subvert the device.
Some of these addresses have current legitimate uses within a site. Some of these addresses have current legitimate uses within a site.
The risk can be minimised by ensuring that all firewalls and site The risk can be minimized by ensuring that all firewalls and site
boundary routers are configured to drop packets with site scope boundary routers are configured to drop packets with site scope
destination addresses. Also nodes should not join multicast groups destination addresses. Also nodes should not join multicast groups
for which there is no legitimate use on the site and site routers for which there is no legitimate use on the site and site routers
should be configured to drop packets directed to these unused should be configured to drop packets directed to these unused
addresses. addresses.
2.1.4 ICMPv6 and Multicast 2.1.4 ICMPv6 and Multicast
It is possible to launch a denial-of-service (DoS) attack using IPv6 It is possible to launch a denial-of-service (DoS) attack using IPv6
which could be amplified by the multicast infrastructure. which could be amplified by the multicast infrastructure.
Unlike ICMP for IPv4, ICMPv6 [RFC2463] allows error notification Unlike ICMP for IPv4, ICMPv6 [RFC2463] allows error notification
responses to be sent when certain unprocessable packets are sent to responses to be sent when certain unprocessable packets are sent to
multicast addresses. multicast addresses.
The cases in which responses are sent are: The cases in which responses are sent are:
o The received packet is longer than the next link MTU: 'Packet Too o The received packet is longer than the next link MTU: 'Packet Too
Big' responses are needed to support Path MTU Discovery for Big' responses are needed to support Path MTU Discovery for
multicast traffic. multicast traffic.
o The received packet contains an unrecognised option in a hop-by- o The received packet contains an unrecognized option in a hop-by-
hop or destination options extension header with the first two hop or destination options extension header with the first two
bits of the option type set to binary '10': 'Parameter Problem' bits of the option type set to binary '10': 'Parameter Problem'
responses are intended to inform the source that some or all of responses are intended to inform the source that some or all of
the receipients cannot handle the option in question. the recipients cannot handle the option in question.
If an attacker can craft a suitable packet sent to a multicast If an attacker can craft a suitable packet sent to a multicast
destination, it may be possible to elicit multiple responses directed destination, it may be possible to elicit multiple responses directed
at the victim (the spoofed source of the multicast packet). On the at the victim (the spoofed source of the multicast packet). On the
other hand, the use of 'reverse path forwarding' checks to eliminate other hand, the use of 'reverse path forwarding' checks to eliminate
loops in multicast forwarding automatically limits the range of loops in multicast forwarding automatically limits the range of
addresses which can be spoofed. addresses which can be spoofed.
In practice an attack using oversize packets is unlikely to cause In practice an attack using oversize packets is unlikely to cause
much amplification unless the attacker is able to carefully tune the much amplification unless the attacker is able to carefully tune the
packet size to exploit a network with smaller MTU in the edge than packet size to exploit a network with smaller MTU in the edge than
the core. Similarly a packet with an unrecognised hop-by-hop option the core. Similarly a packet with an hop-by-hop option would be
would be dropped by the first router. However a packet with an dropped by the first router. However a packet with an destination
unrecognised destination option could generate multiple responses. option could generate multiple responses.
In addition to amplification, this kind of attack would potentially In addition to amplification, this kind of attack would potentially
consume large amounts of forwarding state resources in routers on consume large amounts of forwarding state resources in routers on
multicast-enabled networks. These attacks are discussed in more multicast-enabled networks. These attacks are discussed in more
detail in [I-D.savola-v6ops-firewalling]. detail in [I-D.savola-v6ops-firewalling].
2.1.5 Anycast Traffic Identification and Security 2.1.5 Anycast Traffic Identification and Security
IPv6 introduces the notion of anycast addresses and services. IPv6 introduces the notion of anycast addresses and services.
Originally the IPv6 standards diasallowed using an anycast address as Originally the IPv6 standards disallowed using an anycast address as
the source address of a packet, so that responses from an anycast the source address of a packet. Responses from an anycast server
server would supply a unicast address for the server in responses. would therefore supply a unicast address for the responding server.
To avoid exposing knowledge about the internal structure of the To avoid exposing knowledge about the internal structure of the
network, it is recommended that anycast servers now take advantage of network, it is recommended that anycast servers now take advantage of
the ability to return responses with the anycast address as the the ability to return responses with the anycast address as the
source address if possible. source address if possible.
If the server needs to use a unicast address for any reason, it may If the server needs to use a unicast address for any reason, it may
be desirable to consider using specialised addresses for anycast be desirable to consider using specialized addresses for anycast
servers which are not used for any other part of the network to servers which are not used for any other part of the network to
restrict the information exposed. Alternatively operators may wish restrict the information exposed. Alternatively operators may wish
to restrict the use of anycast services from outside the domain, thus to restrict the use of anycast services from outside the domain, thus
requiring firewalls to filter anycast requests. For this purpose, requiring firewalls to filter anycast requests. For this purpose,
firewalls need to know which addresses are being used for anycast firewalls need to know which addresses are being used for anycast
services: these addresses are arbitrary and look just like any other services: these addresses are arbitrary and not distinguishable from
IPv6 unicast address. any other IPv6 unicast address by structure or pattern.
One particular class of anycast addresses that should be given One particular class of anycast addresses that should be given
special attention is the set of Subnet-Router anycast addresses special attention is the set of Subnet-Router anycast addresses
defined in The IPv6 Addressing Architecture [RFC3513]. All routers defined in The IPv6 Addressing Architecture [RFC3513]. All routers
are required to support these addresses for all subnets for which are required to support these addresses for all subnets for which
they have interfaces. For most subnets using global unicast they have interfaces. For most subnets using global unicast
addresses, filtering anycast requests to these addresses can be addresses, filtering anycast requests to these addresses can be
achieved by dropping packets with the lower 64 bits (the Interface achieved by dropping packets with the lower 64 bits (the Interface
Identifier) set to all zeroes. Identifier) set to all zeroes.
2.1.6 Address Privacy Extensions Interact with DDoS Defenses 2.1.6 Address Privacy Extensions Interact with DDoS Defenses
The purpose of the privacy extensions for stateless address auto- The purpose of the privacy extensions for stateless address auto-
configuration [RFC3041] is to change the interface identifier (and configuration [RFC3041][I-D.ietf-ipv6-privacy-addrs-v2] is to change
hence the global scope addresses generated from it) from time to time the interface identifier (and hence the global scope addresses
in order to make it more difficult for eavesdroppers and other generated from it) from time to time. By varying the addresses used,
information collectors to identify when different addresses used in eavesdroppers and other information collectors find it more difficult
different transactions actually correspond to the same node. to identify which transactions actually relate to a specific node.
The security issue resulting from this is that if the frequency of A security issue may result from this if the frequency of node
change of the addresses used by a node is sufficiently great to address change is sufficiently great to achieve the intended aim of
achieve the intended aim of the privacy extensions, the observed the privacy extensions: with a relatively high rate of change, the
behavior of the node could look very like that of a compromised node observed behavior of the node could look very like that of a
which was being used as the source of a distributed denial-of-service compromised node which was the source of a distributed denial of
(DDoS). It would thus be difficult to for any future defenses service (DDoS). It would thus be difficult to for any future
against DDoS attacks to distinguish between a high rate change of defenses against DDoS attacks to distinguish between a high rate of
addresses resulting from genuine use of the privacy extensions and a change of addresses resulting from genuine use of the privacy
compromised node being used as the source of a DDoS with 'in-prefix' extensions and a compromised node being used as the source of a DDoS
spoofed source addresses as described in [I-D.dupont-ipv6- with 'in-prefix' spoofed source addresses as described in
rfc3041harmful]. [I-D.dupont-ipv6-rfc3041harmful].
Even if a node is well behaved, the change in the address could make Even if a node is well behaved, the change in the address could make
it harder for a security administrator to define a policy rule (e.g. it harder for a security administrator to define a policy rule (e.g.
access control list) that takes into account a specific node. access control list) that takes into account a specific node.
2.1.7 Dynamic DNS: Stateless Address Auto-Configuration, Privacy 2.1.7 Dynamic DNS: Stateless Address Auto-Configuration, Privacy
Extensions and SEND Extensions and SEND
The introduction of Stateless Address Auto-Configuration (SLAAC) The introduction of Stateless Address Auto-Configuration (SLAAC)
[RFC2462] with IPv6 provides an additional challenge to the security [RFC2462] with IPv6 provides an additional challenge to the security
skipping to change at page 8, line 28 skipping to change at page 8, line 28
secure access to the DNS server is limited, assuming any necessary secure access to the DNS server is limited, assuming any necessary
updates are carried out by the DHCP server. This is true equally for updates are carried out by the DHCP server. This is true equally for
IPv4 and IPv6. IPv4 and IPv6.
Since SLAAC does not make use of a single and potentially trusted Since SLAAC does not make use of a single and potentially trusted
DHCP server, but depends on the node obtaining the address, securing DHCP server, but depends on the node obtaining the address, securing
the insertion of updates into DDNS may need a security association the insertion of updates into DDNS may need a security association
between each node and the DDNS server. This is discussed further in between each node and the DDNS server. This is discussed further in
[I-D.ietf-dnsop-ipv6-dns-issues]. [I-D.ietf-dnsop-ipv6-dns-issues].
Using the Privacy Extensions to SLAAC [RFC3041] may significantly Using the Privacy Extensions to SLAAC [RFC3041][I-D.ietf-ipv6-
increase the rate of updates of DDNS. Even if a node using the privacy-addrs-v2] may significantly increase the rate of updates of
Privacy Extensions does not publish its address for 'forward' lookup DDNS. Even if a node using the Privacy Extensions does not publish
(as that would effectively compromise the privacy which it is its address for 'forward' lookup (as that would effectively
seeking), it may still need to update the reverse DNS records so that compromise the privacy which it is seeking), it may still need to
reverse routability checks can be carried out. If the rate of change update the reverse DNS records so that reverse routability checks can
needed to achieve real privacy has to be increased as is mentioned in be carried out. If the rate of change needed to achieve real privacy
Section 2.1.6 the update rate for DDNS may be excessive. has to be increased as is mentioned in Section 2.1.6 the update rate
for DDNS may be excessive.
Similarly, the cryptographically generated addresses used by SEND Similarly, the cryptographically generated addresses used by SEND
[RFC3971] are expected to be periodically regenerated in line with [RFC3971] are expected to be periodically regenerated in line with
recommendations for maximum key lifetimes. This regeneration could recommendations for maximum key lifetimes. This regeneration could
also impose a significant extra load on DDNS. also impose a significant extra load on DDNS.
2.1.8 Extension Headers 2.1.8 Extension Headers
A number of issues relating to the specification of IPv6 Extension A number of issues relating to the specification of IPv6 Extension
headers have been identified. Several of these are discussed in headers have been identified. Several of these are discussed in
[I-D.savola-v6ops-firewalling]. [I-D.savola-v6ops-firewalling].
2.1.8.1 Processing Extension Headers in Middleboxes 2.1.8.1 Processing Extension Headers in Middleboxes
In IPv4 deep packet inspection techniques are used to implement In IPv4 deep packet inspection techniques are used to implement
policing and filtering both as part of routers and in middleboxes policing and filtering both as part of routers and in middleboxes
such as firewalls. Fully extending these techniques to IPv6 would such as firewalls. Fully extending these techniques to IPv6 would
require inspection of all the extension headers in a packet to ensure require inspection of all the extension headers in a packet. This is
that policy constraints on the use of certain headers and options essential to ensure that policy constraints on the use of certain
were enforced and to remove packets containing potentially damaging headers and options are enforced and to remove, at the earliest
unknown options at the earliest opportunity. opportunity, packets containing potentially damaging unknown options.
This requirement appears to conflict with Section 4 of the IPv6 This requirement appears to conflict with Section 4 of the IPv6
specification in [RFC2460] which requires that destination options specification in [RFC2460] which requires that destination options
are not processed at all until the packet reaches the appropriate are not processed at all until the packet reaches the appropriate
destination (either the final destination or a routing header destination (either the final destination or a routing header
waypoint). waypoint).
Also [RFC2460] forbids processing the headers other than in the order Also [RFC2460] forbids processing the headers other than in the order
in which they appear in the packet. in which they appear in the packet.
A further ambiguity relates to whether an intermediate node should A further ambiguity relates to whether an intermediate node should
discard a packet which contains a header or destination option which discard a packet which contains a header or destination option which
it does not recognise. If the rules above are followed slavishly, it it does not recognize. If the rules above are followed slavishly, it
is not (or may not be) legitimate for the intermediate node to is not (or may not be) legitimate for the intermediate node to
discard the packet because it should not be processing those headers discard the packet because it should not be processing those headers
or options. or options.
[RFC2460] therefore does not appear to take account of the behavior [RFC2460] therefore does not appear to take account of the behavior
of middleboxes and other non-final destinations which may be of middleboxes and other non-final destinations which may be
inspecting the packet, and thereby potentially limits the security inspecting the packet, and thereby potentially limits the security
protection of these boxes. protection of these boxes.
2.1.8.2 Processing Extension Header Chains 2.1.8.2 Processing Extension Header Chains
There is a further problem for middleboxes that want to examine the There is a further problem for middleboxes that want to examine the
transport headers which are located at the end of the IPv6 header transport headers which are located at the end of the IPv6 header
chain. In order to locate the transport header or other protocol chain. In order to locate the transport header or other protocol
data unit, the node has to parse the header chain. data unit, the node has to parse the header chain.
The IPv6 specification [RFC2460] does not mandate the use of the The IPv6 specification [RFC2460] does not mandate the use of the
Type-Length-Value format with a fixed layout for the start of each Type-Length-Value format with a fixed layout for the start of each
header although it is used for the majority of headers currently header although it is used for the majority of headers currently
defined. (Only the Type field is guaranteed in size and offset). defined. (Only the Type field is guaranteed in size and offset).
For example the fragment header does not conform to the TLV format
used for all the other headers.
A middlebox cannot therefore guarantee to be able to process header A middlebox cannot therefore guarantee to be able to process header
chains which may contain headers defined after the box was chains which may contain headers defined after the box was
manufactured. As noted in Section 2.1.8.1, middleboxes ought not to manufactured. As noted in Section 2.1.8.1, middleboxes ought not to
have to know about all header types in use but still need to be able have to know about all header types in use but still need to be able
to skip over such headers to find the transport PDU start. This to skip over such headers to find the transport PDU start. This
either limits the security which can be applied in firewalls or makes either limits the security which can be applied in firewalls or makes
it difficult to deploy new extension header types. it difficult to deploy new extension header types.
At the time of writing, only the Fragment Header does not fully
conform to the TLV format used for other extension headers. In
practice, many firewalls reconstruct fragmented packets before
performing deep packet inspection, so this divergence is less
problematic than it might have been, and is at least partially
justified because the full header chain is not present in all
fragments.
Destination Options may also contain unknown options. However, the Destination Options may also contain unknown options. However, the
options are encoded in TLV format so that intermediate nodes can skip options are encoded in TLV format so that intermediate nodes can skip
over them during processing, unlike the enclosing extension headers. over them during processing, unlike the enclosing extension headers.
2.1.8.3 Unknown Headers/Destination Options and Security Policy 2.1.8.3 Unknown Headers/Destination Options and Security Policy
A strict security policy might dictate that packets containing either A strict security policy might dictate that packets containing either
unknown headers or destination options are discarded by firewalls or unknown headers or destination options are discarded by firewalls or
other filters. This requires the firewall to process the whole other filters. This requires the firewall to process the whole
extension header chain which may be currently in conflict with the extension header chain which may be currently in conflict with the
IPv6 specification as discussed in Section 2.1.8.1. IPv6 specification as discussed in Section 2.1.8.1.
Even if the firewall does inspect the whole header chain, it may not Even if the firewall does inspect the whole header chain, it may not
be sensible to discard packets with items unrecognised by the be sensible to discard packets with items by the firewall: the
firewall because the intermediate node has no knowledge of which intermediate node has no knowledge of which options and headers are
options and headers are implemented in the destination node. Hence implemented in the destination node. Hence it is highly desirable to
it is highly desirable to make the discard policy configurable to make the discard policy configurable. This will avoid firewalls
avoid firewalls dropping packets with legitimate items that they do dropping packets with legitimate items that they do not recognize
not recognise because their hardware or software is not aware of a because their hardware or software is not aware of a new definition.
new definition.
2.1.8.4 Excessive Hop-by-Hop Options 2.1.8.4 Excessive Hop-by-Hop Options
IPv6 does not limit the number of hop by hop options which can be IPv6 does not limit the number of hop by hop options which can be
present in a hop-by-hop option header. This can be used for mounting present in a hop-by-hop option header. The lack of a limit can be
denial of service attacks affecting all nodes on a path as described used to mount denial of service attacks affecting all nodes on a path
in [I-D.krishnan-ipv6-hopbyhop]. as described in [I-D.krishnan-ipv6-hopbyhop].
2.1.8.5 Overuse of Router Alert Option 2.1.8.5 Overuse of Router Alert Option
The IPv6 router alert option specifies a hop-by-hop option that, if The IPv6 router alert option specifies a hop-by-hop option that, if
present, signals the router to take a closer look at the packet. present, signals the router to take a closer look at the packet.
This can be used for denial of service attacks. By sending a large This can be used for denial of service attacks. By sending a large
number of packets with the router alert option present an attacker number of packets containing a router alert option an attacker can
can deplete the processor cycles on the routers available to deplete the processor cycles on the routers available to legitimate
legitimate traffic. traffic.
2.1.9 Fragmentation: Reassembly and Deep Packet Inspection 2.1.9 Fragmentation: Reassembly and Deep Packet Inspection
The current specifications of IPv6 in [RFC2460] do not mandate any The current specifications of IPv6 in [RFC2460] do not mandate any
minimum packet size for the fragments of a packet before the last minimum packet size for the fragments of a packet before the last
one, except for the need to carry the unfragmentable part in all one, except for the need to carry the unfragmentable part in all
fragments. fragments.
The unfragmentable part does not include the transport port numbers The unfragmentable part does not include the transport port numbers
so that it is possible that the first fragment does not contain so that it is possible that the first fragment does not contain
sufficient information to carry out deep packet inspection involving sufficient information to carry out deep packet inspection involving
the port numbers. the port numbers.
Also the reassembly rules for fragmented packets in [RFC2460] do not Also the reassembly rules for fragmented packets in [RFC2460] do not
mandate behavior which would minimise the effects of overlapping mandate behavior which would minimize the effects of overlapping
fragments. fragments.
Depending on the implementation of packet reassembly and the Depending on the implementation of packet reassembly and the
treatment of packet fragments in firewalls and other nodes which use treatment of packet fragments in firewalls and other nodes which use
deep packet inspection for traffic filtering, this potentially leaves deep packet inspection for traffic filtering, this potentially leaves
IPv6 open to the sort of attacks described in [RFC1858] and [RFC3128] IPv6 open to the sort of attacks described in [RFC1858] and [RFC3128]
for IPv4. for IPv4.
There is no reason to allow overlapping packet fragments and overlaps There is no reason to allow overlapping packet fragments and overlaps
could be prohibited in a future revision of the protocol could be prohibited in a future revision of the protocol
skipping to change at page 11, line 41 skipping to change at page 11, line 48
Packet reassembly in IPv6 hosts also opens up the possibility of Packet reassembly in IPv6 hosts also opens up the possibility of
various fragment-related security attacks. Some of these are various fragment-related security attacks. Some of these are
analogous to attacks identified for IPv4. Of particular concern is a analogous to attacks identified for IPv4. Of particular concern is a
DoS attack based on sending large numbers of small fragments without DoS attack based on sending large numbers of small fragments without
a terminating last fragment which would potentially overload the a terminating last fragment which would potentially overload the
reconstruction buffers and consume large amounts of CPU resources. reconstruction buffers and consume large amounts of CPU resources.
Mandating the size of packet fragments could reduce the impact of Mandating the size of packet fragments could reduce the impact of
this kind of attack by limiting the rate at which fragments could this kind of attack by limiting the rate at which fragments could
arrive. arrive and limiting the number of fragments which need to be
processed.
2.1.11 Link-Local Addresses and Securing Neighbor Discovery 2.1.11 Link-Local Addresses and Securing Neighbor Discovery
All IPv6 nodes are required to configure a link-local address on each All IPv6 nodes are required to configure a link-local address on each
interface which they have in order to communicate with other nodes interface. This address is used to communicate with other nodes
directly connected to the link accessed via the interface, especially directly connected to the link accessed via the interface, especially
during the neighbor discovery and auto-configuration processes. during the neighbor discovery and auto-configuration processes.
Link-local addresses are fundamental to the operation of the Neighbor Link-local addresses are fundamental to the operation of the Neighbor
Discovery Protocol (NDP) [RFC2461] and SLAAC [RFC2462]. NDP also Discovery Protocol (NDP) [RFC2461] and SLAAC [RFC2462]. NDP also
provides the functionality of associating link layer and IP addresses provides the functionality of associating link layer and IP addresses
for which the Address Resolution Protocol (ARP) was needed in IPv4 provided by the Address Resolution Protocol (ARP) in IPv4 networks.
networks.
The standard version of NDP is subject to a number of security The standard version of NDP is subject to a number of security
threats related to ARP spoofing attacks on IPv4. These threats have threats related to ARP spoofing attacks on IPv4. These threats have
been documented in [RFC3756] and mechanisms to combat them specified been documented in [RFC3756] and mechanisms to combat them specified
in SEcure Neighbor Discovery (SEND) [RFC3971]. SEND is an optional in SEcure Neighbor Discovery (SEND) [RFC3971]. SEND is an optional
mechanism which is particularly applicable to wireless and other mechanism which is particularly applicable to wireless and other
environments where it is difficult to physically secure the link. environments where it is difficult to physically secure the link.
Because the link-local address can, by default, be acquired without Because the link-local address can, by default, be acquired without
external intervention or control, it allows an attacker to commence external intervention or control, it allows an attacker to commence
communication on the link without needing to acquire information communication on the link without needing to acquire information
about the address prefixes in use or communicate with any authorities about the address prefixes in use or communicate with any authorities
on the link. This feature gives a malicious node the opportunity to on the link. This feature gives a malicious node the opportunity to
mount an attack on any other node which is attached to this link; mount an attack on any other node which is attached to this link;
this vulnerability exists in addition to possible direct attacks on this vulnerability exists in addition to possible direct attacks on
NDP. NDP. Link-local addresses may also facilitate the unauthorized use
of the link bandwidth ('bandwidth theft') to communicate with another
unauthorized node on the same link.
Link-local addresses allocated from the prefix 169.254.0.0/16 are Link-local addresses allocated from the prefix 169.254.0.0/16 are
available in IPv4 as well and procedures for using them are described available in IPv4 as well and procedures for using them are described
in [I-D.ietf-zeroconf-ipv4-linklocal] but the security issues were in [I-D.ietf-zeroconf-ipv4-linklocal] but the security issues were
not as pronounced as for IPv6 for the following reasons: not as pronounced as for IPv6 for the following reasons:
o link-local addresses are not mandatory in IPv4 and are primarily o link-local addresses are not mandatory in IPv4 and are primarily
intended for isolated or ad hoc networks that cannot acquire a intended for isolated or ad hoc networks that cannot acquire a
routable IPv4 address by other means, routable IPv4 address by other means,
o IPv4 link local addresses are not universally supported across o IPv4 addresses are not universally supported across operating
operating systems, and systems, and
o the IPv4 link local address should be removed when a non-link o the IPv4 link-local address should be removed when a non-link-
local address is configured on the interface and will generally local address is configured on the interface and will generally
not be allocated unless other means of acquiring an address are not be allocated unless other means of acquiring an address are
not available. not available.
This vulnerability can be mitigated in several ways. A general These vulnerabilities can be mitigated in several ways. A general
solution will require solution will require
o authenticating the link layer connectivity, for example by using o authenticating the link layer connectivity, for example by using
IEEE 802.1x functionality, port-based MAC address security IEEE 802.1x functionality, port-based MAC address security
(locking), or physical security, and (locking), or physical security, and
o using SEcure Neighbor Discovery (SEND) to create a o using SEcure Neighbor Discovery (SEND) to create a
cryptographically generated link-local address as described in cryptographically generated link-local address as described in
[RFC3972] which is tied to the authenticated link layer address. [RFC3971] which is tied to the authenticated link layer address.
This solution would be particularly appropriate in wireless LAN This solution would be particularly appropriate in wireless LAN
deployments where it is difficult to physically secure the deployments where it is difficult to physically secure the
infrastructure infrastructure
In wired environments, where the physical infrastructure is In wired environments, where the physical infrastructure is
reasonably secure, it may be sufficient to ignore communication reasonably secure, it may be sufficient to ignore communication
requests originating from a link-local address for other than local requests originating from a link-local address for other than local
network management purposes. This requires that nodes should only network management purposes. This requires that nodes should only
accept packets with link-local addresses for a limited set of accept packets with link-local addresses for a limited set of
protocols including NDP, MLD and other functions of ICMPv6. protocols including NDP, MLD and other functions of ICMPv6.
2.1.11.1 Securing Router Advertisements
As part of the Neighbor Discovery process, routers on a link
advertise their capabilities in Router Advertisement messages. The
version of NDP defined in [RFC2461] does not protect the integrity of
these messages or validate the assertions made in the messages with
the result that any node which connects to the link can maliciously
claim to offer routing services which it will not fulfill, and
advertise inappropriate prefixes and parameters. These threats have
been documented in [RFC3756].
SEND [RFC3971] can be used to provide verification that routers are
authorized to provide the services they advertise through a
certificate-based mechanism. This capability of SEND is also
particularly appropriate for wireless environments where clients are
reliant on the assertions of the routers rather than a physically
secured connection.
2.1.12 Mobile IPv6 2.1.12 Mobile IPv6
Mobile IPv6 offers significantly enhanced security compared with Mobile IPv6 offers significantly enhanced security compared with
Mobile IPv4 especially when using optimized routing and care-of Mobile IPv4 especially when using optimized routing and care-of
addresses. Return routability checks are used to provide relatively addresses. Return routability checks are used to provide relatively
robust assurance that the different addresses which a mobile node robust assurance that the different addresses which a mobile node
uses as it moves through the network do indeed all refer to the same uses as it moves through the network do indeed all refer to the same
node. The threats and solutions are described in [RFC3775] and a node. The threats and solutions are described in [RFC3775] and a
more extensive discussion of the security aspects of the design can more extensive discussion of the security aspects of the design can
be be found in [I-D.ietf-mip6-ro-sec]. be found in [I-D.ietf-mip6-ro-sec].
2.1.12.1 Obsolete Home Address Option in Mobile IPv6 2.1.12.1 Obsolete Home Address Option in Mobile IPv6
The Home Address option specified in early drafts of Mobile IPv6 The Home Address option specified in early drafts of Mobile IPv6
would have allowed a trivial source spoofing attack: hosts were would have allowed a trivial source spoofing attack: hosts were
required to substitute the source address of incoming packets with required to substitute the source address of incoming packets with
the address in the option, thereby potentially evading checks on the the address in the option, thereby potentially evading checks on the
packet source address. This is discussed at greater length in packet source address. This is discussed at greater length in
[I-D.savola-ipv6-rh-ha-security]. The version of Mobile IPv6 as [I-D.savola-ipv6-rh-ha-security]. The version of Mobile IPv6 as
standardised in [RFC3775] has removed this issue by ensuring that the standardized in [RFC3775] has removed this issue by ensuring that the
Home Address destination option is only processed if there is a Home Address destination option is only processed if there is a
corresponding binding cache entry and securing Binding Update corresponding binding cache entry and securing Binding Update
messages. messages.
A number of pre-standard implementations of Mobile IPv6 were A number of pre-standard implementations of Mobile IPv6 were
available which implemented this obsolete and insecure option: care available which implemented this obsolete and insecure option: care
should be taken to avoid running such obsolete systems. should be taken to avoid running such obsolete systems.
2.2 IPv4-mapped IPv6 Addresses 2.2 IPv4-mapped IPv6 Addresses
skipping to change at page 14, line 27 skipping to change at page 15, line 8
standalone transition mechanism. Given the issues that have been standalone transition mechanism. Given the issues that have been
identified, it seems appropriate that mapped addresses should not be identified, it seems appropriate that mapped addresses should not be
used on the wire. However, changing application behavior by used on the wire. However, changing application behavior by
deprecating the use of mapped addresses in the operating system deprecating the use of mapped addresses in the operating system
interface would have significant impact on application porting interface would have significant impact on application porting
methods [RFC4038]and needs further study. methods [RFC4038]and needs further study.
2.3 Increased End-to-End Transparency 2.3 Increased End-to-End Transparency
One of the major design aims of IPv6 has been to maintain the One of the major design aims of IPv6 has been to maintain the
original IP architectural concept of end-to-end transparency. To original IP architectural concept of end-to-end transparency.
fully utilize this capability for further innovation in technologies Transparency can help foster technological innovation in areas such
such as peer-to-peer communication whilst maintaining the security of as peer-to-peer communication but maintaining the security of the
the network requires some modifications in the network architecture network at the same time requires some modifications in the network
and, ultimately, in the security model as compared with the norms for architecture. Ultimately, it is also likely to need changes in the
IPv4 networks security model as compared with the norms for IPv4 networks.
2.3.1 IPv6 Networks without NATs 2.3.1 IPv6 Networks without NATs
The necessity of introducing Network Address Translators (NATs) into The necessity of introducing Network Address Translators (NATs) into
IPv4 networks, resulting from a shortage of IPv4 addresses, has IPv4 networks, resulting from a shortage of IPv4 addresses, has
removed the end-to-end transparency of most IPv4 connections: the use removed the end-to-end transparency of most IPv4 connections: the use
of IPv6 would restore this transparency. However, the use of NATs, of IPv6 would restore this transparency. However, the use of NATs,
and the associated private addressing schemes, has become and the associated private addressing schemes, has become
inappropriately linked to the provision of security in enterprise inappropriately linked to the provision of security in enterprise
networks. The restored end-to-end transparency of IPv6 networks can networks. The restored end-to-end transparency of IPv6 networks can
skipping to change at page 15, line 8 skipping to change at page 15, line 38
of IPv6 addresses. of IPv6 addresses.
Recommendations for designing an IPv6 network to meet the perceived Recommendations for designing an IPv6 network to meet the perceived
security and connectivity requirements implicit in the current usage security and connectivity requirements implicit in the current usage
of IPv4 NATs whilst maintaining the advantages of IPv6 end-to-end of IPv4 NATs whilst maintaining the advantages of IPv6 end-to-end
transparency are described in IPv6 Network Architecture Protection transparency are described in IPv6 Network Architecture Protection
[I-D.ietf-v6ops-nap]. [I-D.ietf-v6ops-nap].
2.3.2 Enterprise Network Security Model for IPv6 2.3.2 Enterprise Network Security Model for IPv6
The favoured model for enterprise network security in IPv4 stresses The favored model for enterprise network security in IPv4 stresses
the use of a security perimeter policed by autonomous firewalls and the use of a security perimeter policed by autonomous firewalls and
incorporating the NATs. Both perimeter firewalls and NATs introduce incorporating the NATs. Both perimeter firewalls and NATs introduce
asymmetry and reduce the transparency of communications through these asymmetry and reduce the transparency of communications through these
perimeters. The symmetric bidirectionality and transparency which perimeters. The symmetric bidirectionality and transparency which
are extolled as virtues of IPv6 may seem to be at odds with this are extolled as virtues of IPv6 may seem to be at odds with this
model, and hence may even be seen as undesirable attributes, given model. Consequently network managers may even see them as
the threats to and attacks on networks which network managers have to undesirable attributes, in conflict with their need to control
control as a major component of their work. threats to and attacks on the networks they administer.
It is worth noting that IPv6 does not *require* end-to-end It is worth noting that IPv6 does not *require* end-to-end
connectivity. It merely provides end-to-end addressability; the connectivity. It merely provides end-to-end addressability; the
connectivity can still be controlled using firewalls (or other connectivity can still be controlled using firewalls (or other
mechanisms), and it is indeed wise to do so. mechanisms), and it is indeed wise to do so.
A number of matters indicate that IPv6 networks should migrate A number of matters indicate that IPv6 networks should migrate
towards an improved security model, which will increase the overall towards an improved security model, which will increase the overall
security of the network but facilitate end-to-end communication: security of the network but facilitate end-to-end communication:
o Increased usage of end-to-end security especially at the network o Increased usage of end-to-end security especially at the network
layer. IPv6 mandates the provision of IPsec capability in all layer. IPv6 mandates the provision of IPsec capability in all
nodes and increasing usage of end-to-end security is a challenge nodes and increasing usage of end-to-end security is a challenge
to current autonomous firewalls which are unable to perform deep to current autonomous firewalls that are unable to perform deep
packet inspection on encrypted packets. It is also incompatible packet inspection on encrypted packets. It is also incompatible
with NATs because they modify the packets, even when packets are with NATs because they modify the packets, even when packets are
only authenticated rather than encrypted. only authenticated rather than encrypted.
o Acknowledgement that over-reliance on the perimeter model is o Acknowledgement that over-reliance on the perimeter model is
potentially dangerous. An attacker who can penetrate today's potentially dangerous. An attacker who can penetrate today's
perimeters will have free rein within the perimeter, in many perimeters will have free rein within the perimeter, in many
cases. Also a successful attack will generally allow the attacker cases. Also a successful attack will generally allow the attacker
to capture information or resources and make use of them to capture information or resources and make use of them.
o Development of mechanisms such as 'Trusted Computing' which will o Development of mechanisms such as 'Trusted Computing' which will
increase the level of trust which network managers are able to increase the level of trust which network managers are able to
place on hosts. place on hosts.
o Development of centralized security policy repositories and o Development of centralized security policy repositories and secure
distribution mechanisms which, in conjunction with trusted hosts, distribution mechanisms which, in conjunction with trusted hosts,
will allow network managers to place more reliance on security will allow network managers to place more reliance on security
mechanisms at the end points and allow end points to influence the mechanisms at the end points. The mechanisms are likely to
behavior of perimeter firewalls. include end-node firewalling and intrusion detection systems as
well as secure protocols that allow end points to influence the
behavior of perimeter security devices.
o Review of the role of perimeter devices with increased emphasis on
intrusion detection, network resource protection and coordination
to thwart distributed denial of service attacks.
Several of the technologies required to support an enhanced security Several of the technologies required to support an enhanced security
model are still under development, including secure protocols to model are still under development, including secure protocols to
allow end points to control firewalls: the complete security model allow end points to control firewalls: the complete security model
utilizing these technologies is now emerging but still requires some utilizing these technologies is now emerging but still requires some
development. development.
In the meantime, initial deployments will need to make use of similar In the meantime, initial deployments will need to make use of similar
firewalling and intrusion detection techniques to IPv4 which may firewalling and intrusion detection techniques to IPv4 which may
limit end-to-end transparency temporarily, but should be prepared to limit end-to-end transparency temporarily, but should be prepared to
use the new security model as it develops and avoid the use of NATs use the new security model as it develops and avoid the use of NATs
by the use of the architectural techniques described in [I-D.ietf- by the use of the architectural techniques described in [I-D.ietf-
v6ops-nap]. v6ops-nap]. In particular, using NAT-PT [RFC2766] as a general
purpose transition mechanism should be avoided as it is likely to
limit the exploitation of end-to-end security and other IPv6
capabilities in future as explained in [I-D.ietf-v6ops-natpt-to-
exprmntl].
3. Issues Due to Transition Mechanisms 3. Issues Due to Transition Mechanisms
3.1 IPv6 Transition/Co-existence Mechanism-specific Issues 3.1 IPv6 Transition/Co-existence Mechanism-specific Issues
The more complicated the IPv6 transition/co-existence becomes, the The more complicated the IPv6 transition/co-existence becomes, the
greater the danger that security issues will be introduced either greater the danger that security issues will be introduced either
o in the mechanisms themselves, o in the mechanisms themselves,
o in the interaction between mechanisms, or o in the interaction between mechanisms, or
o by introducing unsecured paths through multiple mechanisms. o by introducing unsecured paths through multiple mechanisms.
skipping to change at page 17, line 47 skipping to change at page 18, line 41
NATs and firewalls have been deployed extensively in the IPv4 NATs and firewalls have been deployed extensively in the IPv4
Internet, as discussed in Section 2.3. Operators who deploy them Internet, as discussed in Section 2.3. Operators who deploy them
typically have some security/operational requirements in mind (e.g. a typically have some security/operational requirements in mind (e.g. a
desire to block inbound connection attempts), which may or may not be desire to block inbound connection attempts), which may or may not be
misguided. misguided.
The addition of tunneling can change the security model which such The addition of tunneling can change the security model which such
deployments are seeking to enforce. IPv6-over-IPv4 tunneling using deployments are seeking to enforce. IPv6-over-IPv4 tunneling using
protocol 41 is typically either explicitly allowed, or disallowed protocol 41 is typically either explicitly allowed, or disallowed
implicitly. Tunneling IPv6 over IPv4 encapsulated in UDP constitutes implicitly. Tunneling IPv6 over IPv4 encapsulated in UDP constitutes
a more difficult problem: as UDP must usually be allowed to pass a more difficult problem as UDP must usually be allowed to pass
through NATs and firewalls, at least in part and in a possibly through NATs and firewalls. Consequently, using UDP implies the
stateful manner, one can "punch holes" in NAT's and firewalls using ability to punch holes in NAT's and firewalls although, depending on
UDP. In practice, the mechanisms have been explicitly designed to the implementation, this ability may be limited or only achieved in a
traverse both NATs and firewalls in a similar fashion. stateful manner. In practice, the mechanisms have been explicitly
designed to traverse both NATs and firewalls in a similar fashion.
One possible view is that use of tunneling is especially questionable One possible view is that use of tunneling is especially questionable
in home/SOHO environments where the level of expertise in network in home/SOHO environments where the level of expertise in network
administration is typically not very high; in these environments the administration is typically not very high; in these environments the
hosts may not be as tightly managed as in others (e.g., network hosts may not be as tightly managed as in others (e.g., network
services might be enabled unnecessarily), leading to possible services might be enabled unnecessarily), leading to possible
security break-ins or other vulnerabilities. security break-ins or other vulnerabilities.
Holes can be punched both intentionally and unintentionally. In Holes can be punched both intentionally and unintentionally. In
cases where the administrator or user makes an explicit decision to cases where the administrator or user makes an explicit decision to
skipping to change at page 18, line 35 skipping to change at page 19, line 29
the security assumptions held by the users. the security assumptions held by the users.
For example, NAT traversal should not be performed by default unless For example, NAT traversal should not be performed by default unless
there is a firewall producing a similar by-default security policy to there is a firewall producing a similar by-default security policy to
that provided by IPv4 NAT. IPv6-in-IPv4 (protocol 41) tunneling is that provided by IPv4 NAT. IPv6-in-IPv4 (protocol 41) tunneling is
less of a problem, as it is easier to block if necessary; however, if less of a problem, as it is easier to block if necessary; however, if
the host is protected in IPv4, the IPv6 side should be protected as the host is protected in IPv4, the IPv6 side should be protected as
well. well.
As has been shown in Appendix A, it is relatively easy to determine As has been shown in Appendix A, it is relatively easy to determine
the IPv6 address corresponding to an IPv4 address, so especially if the IPv6 address corresponding to an IPv4 address in tunneling
one is using automatic tunneling mechanisms, one should not rely on deployments. It is therefore vital NOT to rely on "security by
"security by obscurity" i.e., relying that nobody is able to guess or obscurity" i.e., assuming that nobody is able to guess or determine
determine the IPv6 address of the host. the IPv6 address of the host especially when using automatic
tunneling transition mechanisms.
4. Issues Due to IPv6 Deployment 4. Issues Due to IPv6 Deployment
4.1 IPv6 Service Piloting Done Insecurely 4.1 IPv6 Service Piloting Done Insecurely
In many cases, IPv6 service piloting is done in a manner which is In many cases, IPv6 service piloting is done in a manner which is
less secure than can be achieved for an IPv4 production service. For less secure than can be achieved for an IPv4 production service. For
example, hosts and routers might not be protected by IPv6 firewalls, example, hosts and routers might not be protected by IPv6 firewalls,
even if the corresponding IPv4 service is fully protected by even if the corresponding IPv4 service is fully protected by
firewalls. firewalls.
skipping to change at page 20, line 22 skipping to change at page 21, line 18
Actually, some providers are fully ready to offer IPv6 services (e.g. Actually, some providers are fully ready to offer IPv6 services (e.g.
web) today, but because that would (or, at least, might) result in web) today, but because that would (or, at least, might) result in
problems for many of their customers or users who are, by default, problems for many of their customers or users who are, by default,
using active dual-stack systems the services are not turned on: as a using active dual-stack systems the services are not turned on: as a
compromise,the services are often published under a separate domain compromise,the services are often published under a separate domain
or subdomain, and are, in practice, not much used as a consequence. or subdomain, and are, in practice, not much used as a consequence.
These issues are also described at some length in [I-D.ietf-v6ops- These issues are also described at some length in [I-D.ietf-v6ops-
v6onbydefault]. v6onbydefault].
An additional problem is the limited implementation of high
availability capabilities supporting IPv6. In particular,
development of the IPv6 version of the Virtual Router Redundancy
Protocol (VRRP) [I-D.ietf-vrrp-ipv6-spec] has lagged the development
of the main IPv6 protocol although alternatives may be available for
some environments.
4.3 Addressing Schemes and Securing Routers 4.3 Addressing Schemes and Securing Routers
Whilst in general terms brute force scanning of IPv6 subnets is Whilst in general terms brute force scanning of IPv6 subnets is
essentially impossible due to the enormously larger address space of essentially impossible due to the enormously larger address space of
IPv6 and the 64 bit interface identifiers (see Appendix A), this will IPv6 and the 64 bit interface identifiers (see Appendix A), this will
be obviated if administrators do not take advantage of the large be obviated if administrators do not take advantage of the large
space to use unguessable interface identifiers. space to use unguessable interface identifiers.
Because the unmemorability of complete IPv6 addresses there is a Because the unmemorability of complete IPv6 addresses there is a
temptation for administrators to use small integers as interface temptation for administrators to use small integers as interface
skipping to change at page 21, line 16 skipping to change at page 22, line 19
locals). However, the security hazards of using link-local addresses locals). However, the security hazards of using link-local addresses
for non-management purposes as documented in Section 2.1.11 should be for non-management purposes as documented in Section 2.1.11 should be
borne in mind. borne in mind.
On the other hand, the possibility that a node or interface can have On the other hand, the possibility that a node or interface can have
multiple global scope addresses makes access control filtering both multiple global scope addresses makes access control filtering both
on ingress and egress more complex and requires higher maintenance on ingress and egress more complex and requires higher maintenance
levels. levels.
The addresses could be from the same network prefix (for example, The addresses could be from the same network prefix (for example,
privacy mechanisms [RFC3041] will periodically create new addresses privacy mechanisms [RFC3041][I-D.ietf-ipv6-privacy-addrs-v2] will
taken from the same prefix and two or more of these may be active at periodically create new addresses taken from the same prefix and two
the same time), or from different prefixes (for example, when a or more of these may be active at the same time), or from different
network is multihomed or is implementing anycast services). In prefixes (for example, when a network is multihomed or is
either case, it is possible that a single host could be using several implementing anycast services). In either case, it is possible that
different addresses with different prefixes. It would be desirable a single host could be using several different addresses with
that the Security Administrator should be able to identify that the different prefixes. It would be desirable that the Security
same host is behind all these addresses. Administrator should be able to identify that the same host is behind
all these addresses.
4.5 Deploying ICMPv6 4.5 Deploying ICMPv6
In IPv4 it is generally accepted that some filtering of ICMP packets In IPv4 it is commonly accepted that some filtering of ICMP packets
by firewalls is essential to maintain security. Because of the by firewalls is essential to maintain security. Because of the
extended use that is made of ICMPv6 with a multitude of functions, extended use that is made of ICMPv6 [RFC2461] with a multitude of
the simple set of dropping rules that are usually applied in IPv4 functions, the simple set of dropping rules that are usually applied
need to be significantly developed for IPv6. The blanket dropping of in IPv4 need to be significantly developed for IPv6. The blanket
all ICMP messages that is used in some very strict environments is dropping of all ICMP messages that is used in some very strict
simply not possible for IPv6. environments is simply not possible for IPv6.
In an IPv6 firewall, policy needs to allow some messages through the In an IPv6 firewall, policy needs to allow some messages through the
firewall but also has to permit certain messages to and from the firewall but also has to permit certain messages to and from the
firewall, especially those with link local sources on links to which firewall, especially those with link-local sources on links to which
the firewall is attached. the firewall is attached. These messages must be permitted to ensure
that Neighbor Discovery [RFC2462], Multicast Listener Discovery
AUTHOR'S NOTE: It may not be the place of this document to specify [RFC2710], [RFC3810] and Stateless Address Configuration [RFC2463]
BCP as regards what ICMPv6 messages should be filtered by firewalls. work as expected.
We solicit input on whether this should be incorporated in a separate
document.
In order for the firewall to function correctly as an IPv6 node, it
must accept and process ICMPv6 messages from link local addresses
received on its interfaces. It also needs to accept at least some
ICMPv6 messages directed to global unicast addresses of the firewall:
o ICMPv6 Type 2 - packet too big - The firewall itself has to
participate in Path MTU Discovery.
o ICMPv6 Type 4 - Parameter Problem - Needs further investigation
because of possible abuse.
To support effective functioning of IPv6, firewalls should typically Recommendations for filtering ICMPv6 messages can be found in
allow the following messages (defined in [RFC2463]) to pass through [I-D.davies-v6ops-icmpv6-filtering-bcp].
the firewall (the first four are equivalent to the typical IPv4
filtering allowance):
o ICMPv6 Type 1, Code 0 - No route to destination error
o ICMPv6 Type 3 - Time exceeded error
o ICMPv6 Type 128 - Echo request
o ICMPv6 Type 129 - Echo response
o ICMPv6 Type 2 - Packet too big (required for Path MTU Discovery)
o ICMPv6 Type 4 - Parameter problem (this type needs to be
investigated further as it is possible that it can be abused.
4.5.1 Problems Resulting from ICMPv6 Transparency 4.5.1 Problems Resulting from ICMPv6 Transparency
As described in Section 4.5, certain ICMPv6 error packets need to be As described in Section 4.5, certain ICMPv6 error packets need to be
passed through a firewall in both directions. This means that the passed through a firewall in both directions. This means that some
ICMPv6 error packets can be exchanged between inside and outside ICMPv6 error packets can be exchanged between inside and outside
without any filtering. without any filtering.
Using this feature, malicious users can communicate between the Using this feature, malicious users can communicate between the
inside and outside of a firewall bypassing the administrator's inside and outside of a firewall bypassing the administrator's
inspection (proxy, firewall etc.). For example in might be possible inspection (proxy, firewall etc.). For example in might be possible
to carry out a covert conversation through the payload of ICMPv6 to carry out a covert conversation through the payload of ICMPv6
error messages or tunnel inappropriate encapsulated IP packets in error messages or tunnel inappropriate encapsulated IP packets in
ICMPv6 error messages. This problem can be alleviated by filtering ICMPv6 error messages. This problem can be alleviated by filtering
ICMPv6 errors using a stateful packet inspection mechanism to ensure ICMPv6 errors using a stateful packet inspection mechanism to ensure
skipping to change at page 23, line 7 skipping to change at page 23, line 41
way which is generally not available to IPv4. way which is generally not available to IPv4.
To secure IPv6 end-to-end communications, IPsec transport mode would To secure IPv6 end-to-end communications, IPsec transport mode would
generally be the solution of choice. However, use of these IPsec generally be the solution of choice. However, use of these IPsec
security features can result in novel problems for network security features can result in novel problems for network
administrators and decrease the effectiveness of perimeter firewalls administrators and decrease the effectiveness of perimeter firewalls
because of the increased prevalence of encrypted packets on which the because of the increased prevalence of encrypted packets on which the
firewalls cannot perform deep packet inspection and filtering. firewalls cannot perform deep packet inspection and filtering.
One example of such problems is the lack of security solutions in the One example of such problems is the lack of security solutions in the
middle-box, including effective content-filtering, ability to provide middlebox, including effective content-filtering, ability to provide
DoS prevention based on the expected TCP protocol behavior, and DoS prevention based on the expected TCP protocol behavior, and
intrusion detection. Future solutions to this problem are discussed intrusion detection. Future solutions to this problem are discussed
in Section 2.3.2. Another example is an IPsec-based DoS (e.g., in Section 2.3.2. Another example is an IPsec-based DoS (e.g.,
sending malformed ESP/AH packets) which can be especially detrimental sending malformed ESP/AH packets) which can be especially detrimental
to software-based IPsec implementations. to software-based IPsec implementations.
4.7 Reduced Functionality Devices 4.7 Reduced Functionality Devices
With the deployment of IPv6 we can expect the attachment of a very With the deployment of IPv6 we can expect the attachment of a very
large number of new IPv6-enabled devices with scarce resources and large number of new IPv6-enabled devices with scarce resources and
low computing capacity. However, they tend to have scarce resources low computing capacity. The resource limitations are generally
and low computing capacity because of a market requirement for cost because of a market requirement for cost reduction. Some such
reduction. Some such devices may not be able even to perform the devices may not be able even to perform the minimum set of functions
minimum set of functions required to protect themselves (e.g. required to protect themselves (e.g. 'personal' firewall, automatic
'personal' firewall, automatic firmware update, enough CPU power to firmware update, enough CPU power to endure DoS attacks). This means
endure DoS attacks). This means a different security scheme may be a different security scheme may be necessary for such embedded
necessary for such embedded devices. devices.
4.8 Operational Factors when Enabling IPv6 in the Network 4.8 Operational Factors when Enabling IPv6 in the Network
There are a number of reasons which make it essential to take There are a number of reasons which make it essential to take
particular care when enabling IPv6 in the network equipment: particular care when enabling IPv6 in the network equipment:
Initially, IPv6-enabled router software may be less stable than Initially, IPv6-enabled router software may be less stable than
current IPv4 only implementations and there is less experience with current IPv4-only implementations and there is less experience with
configuring IPv6 routing, which can result in disruptions to the IPv6 configuring IPv6 routing, which can result in disruptions to the IPv6
routing environment and (IPv6) network outages. routing environment and (IPv6) network outages.
IPv6 processing may not happen at (near) line speed (or at a IPv6 processing may not happen at (near) line speed (or at a
comparable performance level to IPv4 in the same equipment). A high comparable performance level to IPv4 in the same equipment). A high
level of IPv6 traffic (even legitimate, e.g. NNTP) could easily level of IPv6 traffic (even legitimate, e.g. Network News Transport
overload IPv6 processing especially when it is software-based without Protocol, NNTP) could easily overload IPv6 processing especially when
the hardware support typical in high-end routers. This may it is software-based without the hardware support typical in high-end
potentially have deleterious knock-on effects on IPv4 processing, routers. This may potentially have deleterious knock-on effects on
affecting availability of both services. Accordingly, if people IPv4 processing, affecting availability of both services.
don't feel confident enough in the IPv6 capabilities of their Accordingly, if people don't feel confident enough in the IPv6
equipment, they will be reluctant to enable it in their "production" capabilities of their equipment, they will be reluctant to enable it
networks. in their "production" networks.
Sometimes essential features may be missing from early releases of Sometimes essential features may be missing from early releases of
vendors' software; an example is provision of software enabling IPv6 vendors' software; an example is provision of software enabling IPv6
telnet/SSH access, but without the ability to turn it off or limit telnet/SSH access (e.g., to the configuration application of a
access to it! router), but without the ability to turn it off or limit access to
it!
Sometimes the default IPv6 configuration is insecure. For example, Sometimes the default IPv6 configuration is insecure. For example,
in one vendor's implementation, if you have restricted IPv4 telnet to in one vendor's implementation, if you have restricted IPv4 telnet to
only a few hosts in the configuration, you need to be aware that IPv6 only a few hosts in the configuration, you need to be aware that IPv6
telnet will be automatically enabled, that the configuration commands telnet will be automatically enabled, that the configuration commands
used previously do not block IPv6 telnet, IPv6 telnet is open to the used previously do not block IPv6 telnet, IPv6 telnet is open to the
world by default, and that you have to use a separate command to also world by default, and that you have to use a separate command to also
lock down the IPv6 telnet access. lock down the IPv6 telnet access.
Many operator networks have to run interior routing protocols for Many operator networks have to run interior routing protocols for
both IPv4 and IPv6. It is possible to run the both in one routing both IPv4 and IPv6. It is possible to run the both in one routing
protocol, or have two separate routing protocols; either approach has protocol, or have two separate routing protocols; either approach has
its tradeoffs [RFC4029]. If multiple routing protocols are used, one its tradeoffs [RFC4029]. If multiple routing protocols are used, one
should note that this causes double the amount of processing when should note that this causes double the amount of processing when
links flap or recalculation is otherwise needed -- which might more links flap or recalculation is otherwise needed -- which might more
easily overload the router's CPU, causing slightly slower convergence easily overload the router's CPU, causing slightly slower convergence
time. time.
4.9 Ingress Filtering Issues Due to Privacy Addresses 4.9 Ingress Filtering Issues Due to Privacy Addresses
[RFC3041] describes a method for creating temporary addresses on IPv6 [RFC3041][I-D.ietf-ipv6-privacy-addrs-v2] describes a method for
nodes to address privacy issues created by the use of a constant creating temporary addresses on IPv6 nodes to address privacy issues
identifier. In a network, which implements such a mechanism, with a created by the use of a constant identifier. In a network, which
large number of nodes, new temporary addresses may be created at a implements such a mechanism, with a large number of nodes, new
fairly high rate. This might make it hard for ingress filtering temporary addresses may be created at a fairly high rate. This might
mechanisms to distinguish between legitimately changing temporary make it hard for ingress filtering mechanisms to distinguish between
addresses and spoofed source addresses, which are "in-prefix" (They legitimately changing temporary addresses and spoofed source
use a topologically correct prefix and non-existent interface ID). addresses, which are "in-prefix" (They use a topologically correct
This can be addressed by using finer grained access control prefix and non-existent interface ID). This can be addressed by
mechanisms on the network egress point. using finer grained access control mechanisms on the network egress
point.
4.10 Security Issues Due to ND Proxies 4.10 Security Issues Due to ND Proxies
In order to span a single subnet over multiple physical links, a new In order to span a single subnet over multiple physical links, a new
capability is being introduced in IPv6 to proxy Neighbor Discovery capability is being introduced in IPv6 to proxy Neighbor Discovery
messages. This node will be called an NDProxy (see [I-D.ietf-ipv6- messages. This node will be called an NDProxy (see [I-D.ietf-ipv6-
ndproxy]. NDProxies are susceptible to the same security issues as ndproxy]. NDProxies are susceptible to the same security issues as
the ones faced by hosts using unsecured Neighbor Discovery or ARP. the ones faced by hosts using unsecured Neighbor Discovery or ARP.
These proxies may process unsecured messages, and update the neighbor These proxies may process unsecured messages, and update the neighbor
cache as a result of such processing, thus allowing a malicious node cache as a result of such processing, thus allowing a malicious node
to divert or hijack traffic. This may undermine the advantages of to divert or hijack traffic. This may undermine the advantages of
using SEND [RFC3971]. using SEND [RFC3971].
To resolve the security issues introduced by NDProxies, SEND needs to To resolve the security issues introduced by NDProxies, SEND needs to
be extended to be NDProxy aware. be extended to be NDProxy aware.
5. Acknowledgements 5. IANA Considerations
Alain Durand, Alain Baudot, Luc Beloeil, and Andras Kis-Szabo This memo does not contain any actions for IANA.
provided feedback to improve this memo. SUSZUKI Shinsuke provided a
number of additional issues in cooperation with the Deployment
Working Group of the Japanese IPv6 Promotion Council. Michael
Wittsend and Michael Cole discussed issues relating to probing/
mapping and privacy.
6. Security Considerations 6. Security Considerations
This memo attempts to give an overview of security considerations of This memo attempts to give an overview of security considerations of
the different aspects of IPv6. the different aspects of IPv6.
7. References 7. Acknowledgements
7.1 Normative References Alain Durand, Alain Baudot, Luc Beloeil, Andras Kis-Szabo, Alvaro
Vives, Janos Mohacsi and Mark Smith provided feedback to improve this
memo. SUSZUKI Shinsuke provided a number of additional issues in
cooperation with the Deployment Working Group of the Japanese IPv6
Promotion Council. Michael Wittsend and Michael Cole discussed
issues relating to probing/mapping and privacy.
8. References
8.1 Normative References
[I-D.huitema-v6ops-teredo] [I-D.huitema-v6ops-teredo]
Huitema, C., "Teredo: Tunneling IPv6 over UDP through Huitema, C., "Teredo: Tunneling IPv6 over UDP through
NATs", draft-huitema-v6ops-teredo-05 (work in progress), NATs", draft-huitema-v6ops-teredo-05 (work in progress),
April 2005. April 2005.
[I-D.ietf-ipv6-privacy-addrs-v2]
Narten, T., "Privacy Extensions for Stateless Address
Autoconfiguration in IPv6",
draft-ietf-ipv6-privacy-addrs-v2-04 (work in progress),
May 2005.
[I-D.ietf-v6ops-natpt-to-exprmntl]
Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
Experimental", draft-ietf-v6ops-natpt-to-exprmntl-00 (work
in progress), February 2005.
[I-D.ietf-vrrp-ipv6-spec]
Hinden, R., "Virtual Router Redundancy Protocol for IPv6",
draft-ietf-vrrp-ipv6-spec-07 (work in progress),
October 2004.
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address [RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
Assignments", RFC 2375, July 1998. Assignments", RFC 2375, July 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998. December 1998.
skipping to change at page 26, line 17 skipping to change at page 27, line 24
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3964] Savola, P. and C. Patel, "Security Considerations for [RFC3964] Savola, P. and C. Patel, "Security Considerations for
6to4", RFC 3964, December 2004. 6to4", RFC 3964, December 2004.
7.2 Informative References 8.2 Informative References
[FNAT] Bellovin, S., "Technique for Counting NATted Hosts", Proc. [FNAT] Bellovin, S., "Technique for Counting NATted Hosts", Proc.
Second Internet Measurement Workshop , November 2002, Second Internet Measurement Workshop , November 2002,
<http://www.research.att.com/~smb/papers/fnat.pdf>. <http://www.research.att.com/~smb/papers/fnat.pdf>.
[I-D.chown-v6ops-port-scanning-implications] [I-D.chown-v6ops-port-scanning-implications]
Chown, T., "IPv6 Implications for TCP/UDP Port Scanning", Chown, T., "IPv6 Implications for TCP/UDP Port Scanning",
draft-chown-v6ops-port-scanning-implications-01 (work in draft-chown-v6ops-port-scanning-implications-01 (work in
progress), July 2004. progress), July 2004.
[I-D.cmetz-v6ops-v4mapped-api-harmful] [I-D.cmetz-v6ops-v4mapped-api-harmful]
Metz, C. and J. Hagino, "IPv4-Mapped Address API Metz, C. and J. Hagino, "IPv4-Mapped Address API
Considered Harmful", Considered Harmful",
draft-cmetz-v6ops-v4mapped-api-harmful-01 (work in draft-cmetz-v6ops-v4mapped-api-harmful-01 (work in
progress), October 2003. progress), October 2003.
[I-D.davies-v6ops-icmpv6-filtering-bcp]
Davies, E., "Best Current Practice for Filtering ICMPv6
Messages in Firewalls",
draft-davies-v6ops-icmpv6-filtering-bcp-00 (work in
progress), July 2005.
[I-D.dupont-ipv6-rfc3041harmful] [I-D.dupont-ipv6-rfc3041harmful]
Dupont, F. and P. Savola, "RFC 3041 Considered Harmful", Dupont, F. and P. Savola, "RFC 3041 Considered Harmful",
draft-dupont-ipv6-rfc3041harmful-05 (work in progress), draft-dupont-ipv6-rfc3041harmful-05 (work in progress),
June 2004. June 2004.
[I-D.ietf-dnsop-ipv6-dns-issues] [I-D.ietf-dnsop-ipv6-dns-issues]
Durand, A., Ihren, J., and P. Savola, "Operational Durand, A., Ihren, J., and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", Considerations and Issues with IPv6 DNS",
draft-ietf-dnsop-ipv6-dns-issues-10 (work in progress), draft-ietf-dnsop-ipv6-dns-issues-10 (work in progress),
October 2004. October 2004.
[I-D.ietf-dnsop-misbehavior-against-aaaa] [I-D.ietf-dnsop-misbehavior-against-aaaa]
Morishita, Y. and T. Jinmei, "Common Misbehavior against Morishita, Y. and T. Jinmei, "Common Misbehavior against
DNS Queries for IPv6 Addresses", DNS Queries for IPv6 Addresses",
draft-ietf-dnsop-misbehavior-against-aaaa-02 (work in draft-ietf-dnsop-misbehavior-against-aaaa-02 (work in
progress), October 2004. progress), October 2004.
[I-D.ietf-ipv6-ndproxy] [I-D.ietf-ipv6-ndproxy]
Thaler, D., "Bridge-like Neighbor Discovery Proxies (ND Thaler, D., "Bridge-like Neighbor Discovery Proxies (ND
Proxy)", draft-ietf-ipv6-ndproxy-01 (work in progress), Proxy)", draft-ietf-ipv6-ndproxy-02 (work in progress),
February 2005. May 2005.
[I-D.ietf-mip6-ro-sec] [I-D.ietf-mip6-ro-sec]
Nikander, P., "Mobile IP version 6 Route Optimization Nikander, P., "Mobile IP version 6 Route Optimization
Security Design Background", draft-ietf-mip6-ro-sec-02 Security Design Background", draft-ietf-mip6-ro-sec-03
(work in progress), October 2004. (work in progress), May 2005.
[I-D.ietf-v6ops-nap] [I-D.ietf-v6ops-nap]
Velde, G., "IPv6 Network Architecture Protection", Velde, G., "IPv6 Network Architecture Protection",
draft-ietf-v6ops-nap-00 (work in progress), March 2005. draft-ietf-v6ops-nap-01 (work in progress), June 2005.
[I-D.ietf-v6ops-v6onbydefault] [I-D.ietf-v6ops-v6onbydefault]
Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack Roy, S., Durand, A., and J. Paugh, "Issues with Dual Stack
IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
(work in progress), July 2004. (work in progress), July 2004.
[I-D.ietf-zeroconf-ipv4-linklocal] [I-D.ietf-zeroconf-ipv4-linklocal]
Aboba, B., "Dynamic Configuration of Link-Local IPv4 Aboba, B., "Dynamic Configuration of Link-Local IPv4
Addresses", draft-ietf-zeroconf-ipv4-linklocal-17 (work in Addresses", draft-ietf-zeroconf-ipv4-linklocal-17 (work in
progress), July 2004. progress), July 2004.
skipping to change at page 28, line 30 skipping to change at page 29, line 42
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858, Considerations for IP Fragment Filtering", RFC 1858,
October 1995. October 1995.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm
(SIIT)", RFC 2765, February 2000. (SIIT)", RFC 2765, February 2000.
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny [RFC3128] Miller, I., "Protection Against a Variant of the Tiny
Fragment Attack (RFC 1858)", RFC 3128, June 2001. Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004. May 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P. [RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
Savola, "Scenarios and Analysis for Introducing IPv6 into Savola, "Scenarios and Analysis for Introducing IPv6 into
ISP Networks", RFC 4029, March 2005. ISP Networks", RFC 4029, March 2005.
[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
Castro, "Application Aspects of IPv6 Transition", Castro, "Application Aspects of IPv6 Transition",
RFC 4038, March 2005. RFC 4038, March 2005.
Authors' Addresses Authors' Addresses
skipping to change at page 29, line 32 skipping to change at page 30, line 43
Email: suresh.krishnan@ericsson.com Email: suresh.krishnan@ericsson.com
Pekka Savola Pekka Savola
CSC/Funet CSC/Funet
Email: psavola@funet.fi Email: psavola@funet.fi
Appendix A. IPv6 Probing/Mapping Considerations Appendix A. IPv6 Probing/Mapping Considerations
One school of thought wants the IPv6 numbering topology (either at One school of thought wants the IPv6 numbering topology (either at
network or node level) [I-D.schild-v6ops-guide-v4mapping] match IPv4 network or node level) [I-D.schild-v6ops-guide-v4mapping] to match
as exactly as possible, whereas others see IPv6 as giving more IPv4 as exactly as possible, whereas others see IPv6 as giving more
flexibility to the address plans, not wanting to constrain the design flexibility to the address plans, not wanting to constrain the design
of IPv6 addressing. Mirroring the address plans may also be seen as of IPv6 addressing. Mirroring the address plans may also be seen as
a security threat because an IPv6 deployment may have different a security threat because an IPv6 deployment may have different
security properties from IPv4. security properties from IPv4.
Given the relatively immature state of IPv6 network security, if an Given the relatively immature state of IPv6 network security, if an
attacker knows the IPv4 address of the node and believes it to be attacker knows the IPv4 address of the node and believes it to be
dual-stacked with IPv4 and IPv6, he might want to try to probe the dual-stacked with IPv4 and IPv6, he might want to try to probe the
corresponding IPv6 address, based on the assumption that the security corresponding IPv6 address, based on the assumption that the security
defenses might be lower. This might be the case particularly for defenses might be lower. This might be the case particularly for
skipping to change at page 30, line 8 skipping to change at page 31, line 21
IPv6. Naturally, this is not a concern if similar and adequate IPv6. Naturally, this is not a concern if similar and adequate
security policies are in place. security policies are in place.
On the other hand, brute-force scanning or probing of addresses is On the other hand, brute-force scanning or probing of addresses is
computationally infeasible due to the large search space of interface computationally infeasible due to the large search space of interface
identifiers on most IPv6 subnets (somewhat less than 64 bits wide, identifiers on most IPv6 subnets (somewhat less than 64 bits wide,
depending on how identifiers are chosen), always provided that depending on how identifiers are chosen), always provided that
identifiers are chosen at random out of the available space, as identifiers are chosen at random out of the available space, as
discussed in [I-D.chown-v6ops-port-scanning-implications]. discussed in [I-D.chown-v6ops-port-scanning-implications].
For example, automatic tunneling mechanisms use rather deterministic For example, automatic tunneling mechanisms typically use
methods for generating IPv6 addresses, so probing/port-scanning an deterministic methods for generating IPv6 addresses, so probing/
IPv6 node is simplified. The IPv4 address is embedded at least in port-scanning an IPv6 node is simplified. The IPv4 address is
6to4, Teredo and ISATAP address. Further than that, it's possible embedded at least in 6to4, Teredo and ISATAP addresses.
(in the case of 6to4 in particular) to learn the address behind the Additionally, it is possible (in the case of 6to4 in particular) to
prefix; for example, Microsoft 6to4 implementation uses the address learn the address behind the prefix; for example, Microsoft 6to4
2002:V4ADDR::V4ADDR while Linux and BSD implementations default to implementation uses the address 2002:V4ADDR::V4ADDR while older Linux
2002:V4ADDR::1. This could also be used as one way to identify an and FreeBSD implementations default to 2002:V4ADDR::1. This could
implementation. also be used as one way to identify an implementation and hence
target any specific weaknesses.
One proposal has been to randomize the addresses or subnet identifier One proposal has been to randomize the addresses or subnet identifier
in the address of the 6to4 router. This doesn't really help, as the in the address of the 6to4 router. This does not really help, as the
6to4 router (whether a host or a router) will return an ICMPv6 Hop 6to4 router (whether a host or a router) will return an ICMPv6 Hop
Limit Exceeded message, revealing the IP address. Hosts behind the Limit Exceeded message, revealing the IP address. Hosts behind the
6to4 router can use methods such as RFC 3041 addresses to conceal 6to4 router can use methods such as RFC 3041 addresses to conceal
themselves, though. themselves, though.
To conclude, it seems that when automatic tunneling mechanism is To conclude, it seems that when an automatic tunneling mechanism is
being used, given an IPv4 address, the corresponding IPv6 address being used, given an IPv4 address, the corresponding IPv6 address
could possibly be guessed with relative ease. This has significant could possibly be guessed with relative ease. This has significant
implications if the IPv6 security policy is less adequate than that implications if the IPv6 security policy is less adequate than that
for IPv4. for IPv4.
Appendix B. IPv6 Privacy Considerations Appendix B. IPv6 Privacy Considerations
It has been claimed that IPv6 harms the privacy of the user, either The generation of IPv6 addresses of IPv6 addresses from MAC addresses
by exposing the MAC address, or by exposing the number of nodes potentially allows the behavior of users to be tracked in a way which
connected to a site. may infringe their privacy. [RFC3041] specifies mechanisms which can
be used to reduce the risk of infringement. It has also been claimed
that IPv6 harms the privacy of the user, either by exposing the MAC
address, or by exposing the number of nodes connected to a site.
B.1 Exposing MAC Addresses B.1 Exposing MAC Addresses
The MAC address, which with stateless address autoconfiguration, Using stateless address autoconfiguration results in the MAC address
results in an EUI64, exposes the model of network card. The concern being incorporated in an EUI64 that exposes the model of network
has been that a user might not want to expose the details of the card. The concern has been that a user might not want to expose the
system to outsiders, e.g., in the fear of a resulting burglary (e.g., details of the system to outsiders, e.g., fearing a resulting
if a crook identifies expensive equipment from the MAC addresses). burglary if a thief identifies expensive equipment from the vendor
identifier embedded in MAC addresses.
In most cases, this seems completely unfounded. First, such an In most cases, this seems completely unfounded. First, such an
address must be learned somehow -- this is a non-trivial process; the address must be learned somehow -- this is a non-trivial process; the
addresses are visible e.g., in web site access logs, but the chances addresses are visible e.g., in web site access logs, but the chances
that a random web site owner is collecting this kind of information that a random web site owner is collecting this kind of information
(or whether it would be of any use) are quite slim. Being able to (or whether it would be of any use) are quite slim. Being able to
eavesdrop the traffic to learn such addresses (e.g., by the eavesdrop the traffic to learn such addresses (e.g., by the
compromise of DSL or Cable modem physical media) seems also quite compromise of DSL or Cable modem physical media) seems also quite
far-fetched. Further, using RFC 3041 addresses for such purposes is far-fetched. Further, using RFC 3041 addresses for such purposes is
straightforward if worried about the risk. Second, the burglar would straightforward if worried about the risk. Second, the burglar would
have to be able to map the IP address to the physical location; this have to be able to map the IP address to the physical location;
is typically only available in the private customer database of the typically this would only be possible with information from the
ISP. private customer database of the ISP and, for large sites, the
administrative records of the site.
B.2 Exposing Multiple Devices B.2 Exposing Multiple Devices
Another presented concern is whether the user wants to show off as Another concern that has been aired involves the user wanting to
having a lot of computers or other devices at a network; NAT "hides" conceal the presence of a large number of computers or other devices
everything behind an address, but is not perfect either [FNAT]. connected to a network; NAT can "hide" all this equipment behind a
single address, but is not perfect either [FNAT].
One practical reason why some may find this desirable is being able One practical reason why some administrators may find this desirable
to thwart certain ISPs' business models, where one should pay extra is being able to thwart certain ISPs' business models. These models
for additional computers (and not the connectivity as a whole). require payment based on the number of connected computers, rather
than the connectivity as a whole.
Similar feasibility issues as described above apply. To a degree, Similar feasibility issues as described above apply. To a degree,
the counting avoidance could be performed by the sufficiently the number of machines present could be obscured by the sufficiently
frequent re-use of RFC 3041 addresses -- that is, if during a short frequent re-use of RFC 3041 addresses -- that is, if during a short
period, dozens of generated addresses seem to be in use, it's period, dozens of generated addresses seem to be in use, it's
difficult to estimate whether they are generated by just one host or difficult to estimate whether they are generated by just one host or
multiple hosts. multiple hosts.
B.3 Exposing the Site by a Stable Prefix B.3 Exposing the Site by a Stable Prefix
When an ISP provides an IPv6 connectivity to its customers, it When an ISP provides IPv6 connectivity to its customers, it delegates
delegates a fixed global routing prefix (usually a /48) to them. a fixed global routing prefix (usually a /48) to them.
Due to this fixed allocation, it is easier to correlate the global Due to this fixed allocation, it is easier to correlate the global
routing prefix to a network site. In case of consumer users, this routing prefix to a network site. In case of consumer users, this
correlation leads to a privacy issue, since a site is often equal to correlation leads to a privacy issue, since a site is often
an individual or a family in such a case. That is, some users might equivalent to an individual or a family in such a case. That is,
be concerned about being able to be tracked based on their /48 some users might be concerned about being able to be tracked based on
allocation if it is static [I-D.dupont-ipv6-rfc3041harmful]. their /48 allocation if it is static [I-D.dupont-ipv6-
rfc3041harmful].
This problem remains unsolved even when a user changes his/her This problem remains unsolved even when a user changes his/her
interface ID or subnet ID, because malicious users can still discover interface ID or subnet ID, because malicious users can still discover
this binding. This problem can be solved by untraceable IPv6 this binding. This problem can be solved by untraceable IPv6
addresses as described in [I-D.ietf-v6ops-nap]. addresses as described in [I-D.ietf-v6ops-nap].
Intellectual Property Statement Intellectual Property Statement
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
 End of changes. 

This html diff was produced by rfcdiff 1.24, available from http://www.levkowetz.com/ietf/tools/rfcdiff/