draft-ietf-v6ops-security-overview-05.txt   draft-ietf-v6ops-security-overview-06.txt 
IPv6 Operations E. Davies IPv6 Operations E. Davies
Internet-Draft Consultant Internet-Draft Consultant
Intended status: Informational S. Krishnan Intended status: Informational S. Krishnan
Expires: March 4, 2007 Ericsson Expires: April 25, 2007 Ericsson
P. Savola P. Savola
CSC/Funet CSC/Funet
August 31, 2006 October 22, 2006
IPv6 Transition/Co-existence Security Considerations IPv6 Transition/Co-existence Security Considerations
draft-ietf-v6ops-security-overview-05.txt draft-ietf-v6ops-security-overview-06.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 March 4, 2007. This Internet-Draft will expire on April 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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 21 skipping to change at page 2, line 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Issues Due to IPv6 Protocol . . . . . . . . . . . . . . . . . 4 2. Issues Due to IPv6 Protocol . . . . . . . . . . . . . . . . . 4
2.1. IPv6 Protocol-specific Issues . . . . . . . . . . . . . . 5 2.1. IPv6 Protocol-specific Issues . . . . . . . . . . . . . . 5
2.1.1. Routing Headers and Hosts . . . . . . . . . . . . . . 5 2.1.1. Routing Headers and Hosts . . . . . . . . . . . . . . 5
2.1.2. Routing Headers for Mobile IPv6 and Other Purposes . . 6 2.1.2. Routing Headers for Mobile IPv6 and Other Purposes . . 6
2.1.3. Site-scope Multicast Addresses . . . . . . . . . . . . 7 2.1.3. Site-scope Multicast Addresses . . . . . . . . . . . . 7
2.1.4. ICMPv6 and Multicast . . . . . . . . . . . . . . . . . 7 2.1.4. ICMPv6 and Multicast . . . . . . . . . . . . . . . . . 7
2.1.5. Bogus Errored Packets in ICMPv6 Error Messages . . . . 8 2.1.5. Bogus Errored Packets in ICMPv6 Error Messages . . . . 8
2.1.6. Anycast Traffic Identification and Security . . . . . 9 2.1.6. Anycast Traffic Identification and Security . . . . . 9
2.1.7. Address Privacy Extensions Interact with DDoS 2.1.7. Address Privacy Extensions Interact with DDoS
Defenses . . . . . . . . . . . . . . . . . . . . . . . 9 Defenses . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.8. Dynamic DNS: Stateless Address Auto-Configuration, 2.1.8. Dynamic DNS: Stateless Address Auto-Configuration,
Privacy Extensions and SEND . . . . . . . . . . . . . 10 Privacy Extensions and SEND . . . . . . . . . . . . . 10
2.1.9. Extension Headers . . . . . . . . . . . . . . . . . . 11 2.1.9. Extension Headers . . . . . . . . . . . . . . . . . . 11
2.1.10. Fragmentation: Reassembly and Deep Packet 2.1.10. Fragmentation: Reassembly and Deep Packet
Inspection . . . . . . . . . . . . . . . . . . . . . . 14 Inspection . . . . . . . . . . . . . . . . . . . . . . 14
2.1.11. Fragmentation Related DoS Attacks . . . . . . . . . . 15 2.1.11. Fragmentation Related DoS Attacks . . . . . . . . . . 15
2.1.12. Link-Local Addresses and Securing Neighbor 2.1.12. Link-Local Addresses and Securing Neighbor
Discovery . . . . . . . . . . . . . . . . . . . . . . 15 Discovery . . . . . . . . . . . . . . . . . . . . . . 15
2.1.13. Securing Router Advertisements . . . . . . . . . . . . 17 2.1.13. Securing Router Advertisements . . . . . . . . . . . . 17
2.1.14. Host to Router Load Sharing . . . . . . . . . . . . . 17 2.1.14. Host to Router Load Sharing . . . . . . . . . . . . . 18
2.1.15. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . 18 2.1.15. Mobile IPv6 . . . . . . . . . . . . . . . . . . . . . 18
2.2. IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . 18 2.2. IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . 18
2.3. Increased End-to-End Transparency . . . . . . . . . . . . 20 2.3. Increased End-to-End Transparency . . . . . . . . . . . . 20
2.3.1. IPv6 Networks without NATs . . . . . . . . . . . . . . 20 2.3.1. IPv6 Networks without NATs . . . . . . . . . . . . . . 20
2.3.2. Enterprise Network Security Model for IPv6 . . . . . . 20 2.3.2. Enterprise Network Security Model for IPv6 . . . . . . 20
2.4. IPv6 in IPv6 Tunnels . . . . . . . . . . . . . . . . . . . 22 2.4. IPv6 in IPv6 Tunnels . . . . . . . . . . . . . . . . . . . 22
3. Issues Due to Transition Mechanisms . . . . . . . . . . . . . 22 3. Issues Due to Transition Mechanisms . . . . . . . . . . . . . 22
3.1. IPv6 Transition/Co-existence Mechanism-specific Issues . . 22 3.1. IPv6 Transition/Co-existence Mechanism-specific Issues . . 22
3.2. Automatic Tunneling and Relays . . . . . . . . . . . . . . 23 3.2. Automatic Tunneling and Relays . . . . . . . . . . . . . . 23
3.3. Tunneling IPv6 Through IPv4 Networks May Break IPv4 3.3. Tunneling IPv6 Through IPv4 Networks May Break IPv4
Network Security Assumptions . . . . . . . . . . . . . . . 23 Network Security Assumptions . . . . . . . . . . . . . . . 24
4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . . 25 4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . . 25
4.1. Avoiding the Trap of Insecure IPv6 Service Piloting . . . 25 4.1. Avoiding the Trap of Insecure IPv6 Service Piloting . . . 25
4.2. DNS Server Problems . . . . . . . . . . . . . . . . . . . 27 4.2. DNS Server Problems . . . . . . . . . . . . . . . . . . . 27
4.3. Addressing Schemes and Securing Routers . . . . . . . . . 27 4.3. Addressing Schemes and Securing Routers . . . . . . . . . 27
4.4. Consequences of Multiple Addresses in IPv6 . . . . . . . . 27 4.4. Consequences of Multiple Addresses in IPv6 . . . . . . . . 27
4.5. Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 28 4.5. Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 28
4.5.1. Problems Resulting from ICMPv6 Transparency . . . . . 29 4.5.1. Problems Resulting from ICMPv6 Transparency . . . . . 29
4.6. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 29 4.6. IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 29
4.7. Reduced Functionality Devices . . . . . . . . . . . . . . 30 4.7. Reduced Functionality Devices . . . . . . . . . . . . . . 30
4.8. Operational Factors when Enabling IPv6 in the Network . . 30 4.8. Operational Factors when Enabling IPv6 in the Network . . 30
4.9. Ingress Filtering Issues Due to Privacy Addresses . . . . 31 4.9. Security Issues Due to Neighbor Discovery Proxies . . . . 31
4.10. Security Issues Due to Neighbor Discovery Proxies . . . . 31
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 6. Security Considerations . . . . . . . . . . . . . . . . . . . 31
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . . 33 8.2. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix A. IPv6 Probing/Mapping Considerations . . . . . . . . . 36 Appendix A. IPv6 Probing/Mapping Considerations . . . . . . . . . 36
Appendix B. IPv6 Privacy Considerations . . . . . . . . . . . . . 37 Appendix B. IPv6 Privacy Considerations . . . . . . . . . . . . . 37
B.1. Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 37 B.1. Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 37
B.2. Exposing Multiple Devices . . . . . . . . . . . . . . . . 38 B.2. Exposing Multiple Devices . . . . . . . . . . . . . . . . 38
B.3. Exposing the Site by a Stable Prefix . . . . . . . . . . . 38 B.3. Exposing the Site by a Stable Prefix . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . . . . 40 Intellectual Property and Copyright Statements . . . . . . . . . . 40
skipping to change at page 5, line 49 skipping to change at page 5, line 49
enabled. The Requirements for Internet Hosts [RFC1122] permits enabled. The Requirements for Internet Hosts [RFC1122] permits
implementations to perform "local source routing", that is forwarding implementations to perform "local source routing", that is forwarding
a packet with a routing header through the same interface on which it a packet with a routing header through the same interface on which it
was received: no restrictions are placed on this operation even on was received: no restrictions are placed on this operation even on
hosts. In combination, these rules can result in hosts forwarding hosts. In combination, these rules can result in hosts forwarding
received traffic to another node if there are segments left in the received traffic to another node if there are segments left in the
Routing Header when it arrives at the host. Routing Header when it arrives at the host.
A number of potential security issues associated with this behavior A number of potential security issues associated with this behavior
have been identified. Some of these issues have been resolved (a have been identified. Some of these issues have been resolved (a
separate routing header (Type 2) is now used for Mobile IPv6 separate routing header (Type 2) has been standardized for Mobile
[RFC3775] and ICMP Traceback has not been standardized), but two IPv6 [RFC3775] and ICMP Traceback has not been standardized), but two
issues remain: issues remain:
o Routing headers can be used to evade access controls based on o Both existing types of routing header can be used to evade access
destination addresses. This could be achieved by sending a packet controls based on destination addresses. This could be achieved
ostensibly to a publicly accessible host address but with a by sending a packet ostensibly to a publicly accessible host
routing header containing a 'forbidden' address. If the publicly address but with a routing header containing a 'forbidden'
accessible host is processing routing headers it will forward the address. If the publicly accessible host is processing routing
packet to the destination address in the routing header that would headers it will forward the packet to the destination address in
have been forbidden by the packet filters if the address had been the routing header that would have been forbidden by the packet
in the destination field when the packet was checked. filters if the address had been in the destination field when the
o If the packet source address in the previous case can be spoofed, packet was checked.
any host could be used to mediate an anonymous reflection denial- o If the packet source address can be spoofed when using a Type 0
of-service attack by having any publicly accessible host redirect routing header, the mechanism described in the previous bullet
the attack packets. could be used with any host to mediate an anonymous reflection
denial-of-service attack by having any publicly accessible host
redirect the attack packets. (This attack cannot use Type 2
routing headers because the packet cannot be forwarded outside the
host that processes the routing header, i.e., the original
destination of the packet.)
To counteract these threats, if a device is enforcing access controls To counteract these threats, if a device is enforcing access controls
based on destination addresses, it needs to examine both the based on destination addresses, it needs to examine both the
destination address in the base IPv6 header and any waypoint destination address in the base IPv6 header and any waypoint
destinations in a routing header that have not yet been reached by destinations in a routing header that have not yet been reached by
the packet at the point where it is being checked. the packet at the point where it is being checked.
Various forms of amplification attack on routers and firewalls using Various forms of amplification attack on routers and firewalls using
the routing header could be envisaged. A simple form involves the routing header could be envisaged. A simple form involves
repeating the address of a waypoint several times in the routing repeating the address of a waypoint several times in the routing
header. More complex forms could involve alternating waypoint header. More complex forms could involve alternating waypoint
skipping to change at page 10, line 10 skipping to change at page 10, line 17
The purpose of the privacy extensions for stateless address auto- The purpose of the privacy extensions for stateless address auto-
configuration [I-D.ietf-ipv6-privacy-addrs-v2] is to change the configuration [I-D.ietf-ipv6-privacy-addrs-v2] is to change the
interface identifier (and hence the global scope addresses generated interface identifier (and hence the global scope addresses generated
from it) from time to time. By varying the addresses used, from it) from time to time. By varying the addresses used,
eavesdroppers and other information collectors find it more difficult eavesdroppers and other information collectors find it more difficult
to identify which transactions actually relate to a specific node. to identify which transactions actually relate to a specific node.
A security issue may result from this if the frequency of node A security issue may result from this if the frequency of node
address change is sufficiently great to achieve the intended aim of address change is sufficiently great to achieve the intended aim of
the privacy extensions: with a relatively high rate of change, the the privacy extensions: with a relatively high rate of change, the
observed behavior of the node could look very like that of a observed behavior has some characteristics of a node or nodes
compromised node that was the source of a Distributed Denial-of- involved in a Distributed Denial-of-Service (DDoS) attack. It should
Service (DDoS) attack. It would thus be difficult for any future be noted, however, that addresses created in this way are
defenses against DDoS attacks to distinguish between a high rate of topologically correct and that the other characteristics of the
change of addresses resulting from genuine use of the privacy traffic may reveal that there is no malicious intent.
extensions and a compromised node being used as the source of a DDoS
with 'in-prefix' spoofed source addresses as described in
[I-D.ietf-ipv6-privacy-addrs-v2].
Even if a node is well behaved, the change in the address could make This issue can be addressed in most cases by tuning the rate of
it harder for a security administrator to define a policy rule (e.g., change in an appropriate manner.
access control list) that takes into account a specific node.
Note that even if a node is well behaved, a change in the address
could make it harder for a security administrator to define an
address-based policy rule (e.g., access control list). However,
nodes that employ privacy addresses do not have to use them for all
communications.
2.1.8. Dynamic DNS: Stateless Address Auto-Configuration, Privacy 2.1.8. 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
of Dynamic Domain Name System (DDNS). With manual addressing or the of Dynamic Domain Name System (DDNS). With manual addressing or the
use of DHCP, the number of security associations that need to be use of DHCP, the number of security associations that need to be
maintained to secure access to the Domain Name Service (DNS) server maintained to secure access to the Domain Name Service (DNS) server
is limited, assuming any necessary updates are carried out by the is limited, assuming any necessary updates are carried out by the
skipping to change at page 31, line 15 skipping to change at page 31, line 20
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. Security Issues Due to Neighbor Discovery Proxies
[I-D.ietf-ipv6-privacy-addrs-v2] describes a method for creating
temporary addresses on IPv6 nodes to address privacy issues created
by the use of a constant identifier. In a large network implementing
such a mechanism new temporary addresses may be created at a fairly
high rate. As discussed in Section 2.1.7, this might make it hard
for ingress filtering mechanisms to distinguish between legitimately
changing temporary addresses and spoofed source addresses, which are
"in-prefix" (i.e., they use a topologically correct prefix and non-
existent interface ID). This can be addressed by using finer grained
access control mechanisms on a per address basis at the network
egress point as suggested in the Security Considerations section of
[I-D.ietf-ipv6-privacy-addrs-v2].
4.10. Security Issues Due to Neighbor Discovery 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
experimental capability is being trialled in IPv6 to proxy Neighbor experimental capability is being trialled in IPv6 to proxy Neighbor
Discovery messages. A node with this capability will be called an Discovery messages. A node with this capability will be called an
NDProxy (see [RFC4389]. NDProxies are susceptible to the same NDProxy (see [RFC4389]. NDProxies are susceptible to the same
security issues as the ones faced by hosts using unsecured Neighbor security issues as the ones faced by hosts using unsecured Neighbor
Discovery or ARP. These proxies may process unsecured messages, and Discovery or ARP. These proxies may process unsecured messages, and
update the neighbor cache as a result of such processing, thus update the neighbor cache as a result of such processing, thus
allowing a malicious node to divert or hijack traffic. This may allowing a malicious node to divert or hijack traffic. This may
undermine the advantages of using SEND [RFC3971]. undermine the advantages of using SEND [RFC3971].
skipping to change at page 32, line 43 skipping to change at page 32, line 32
the issues with the base IPv6 specification which are documented the issues with the base IPv6 specification which are documented
here. here.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-ipv6-privacy-addrs-v2] [I-D.ietf-ipv6-privacy-addrs-v2]
Narten, T., "Privacy Extensions for Stateless Address Narten, T., "Privacy Extensions for Stateless Address
Autoconfiguration in IPv6", Autoconfiguration in IPv6",
draft-ietf-ipv6-privacy-addrs-v2-04 (work in progress), draft-ietf-ipv6-privacy-addrs-v2-05 (work in progress),
December 2005. October 2006.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[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.
skipping to change at page 34, line 15 skipping to change at page 34, line 6
draft-ietf-tcpm-icmp-attacks-00 (work in progress), draft-ietf-tcpm-icmp-attacks-00 (work in progress),
February 2006. February 2006.
[I-D.ietf-v6ops-icmpv6-filtering-recs] [I-D.ietf-v6ops-icmpv6-filtering-recs]
Davies, E. and J. Mohacsi, "Recommendations for Filtering Davies, E. and J. Mohacsi, "Recommendations for Filtering
ICMPv6 Messages in Firewalls", ICMPv6 Messages in Firewalls",
draft-ietf-v6ops-icmpv6-filtering-recs-02 (work in draft-ietf-v6ops-icmpv6-filtering-recs-02 (work in
progress), July 2006. progress), July 2006.
[I-D.ietf-v6ops-nap] [I-D.ietf-v6ops-nap]
Velde, G., "IPv6 Network Architecture Protection", Velde, G., "Network Architecture Protection for IPv6",
draft-ietf-v6ops-nap-03 (work in progress), July 2006. draft-ietf-v6ops-nap-04 (work in progress), October 2006.
[I-D.ietf-v6ops-natpt-to-exprmntl] [I-D.ietf-v6ops-natpt-to-exprmntl]
Aoun, C. and E. Davies, "Reasons to Move NAT-PT to Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
Experimental", draft-ietf-v6ops-natpt-to-exprmntl-03 (work Experimental", draft-ietf-v6ops-natpt-to-exprmntl-03 (work
in progress), October 2005. in progress), October 2005.
[I-D.ietf-v6ops-scanning-implications] [I-D.ietf-v6ops-scanning-implications]
Chown, T., "IPv6 Implications for Network Scanning", Chown, T., "IPv6 Implications for Network Scanning",
draft-ietf-v6ops-scanning-implications-00 (work in draft-ietf-v6ops-scanning-implications-00 (work in
progress), June 2006. progress), June 2006.
 End of changes. 16 change blocks. 
56 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/