Internet Engineering Task Force P. Savola
Internet Draft CSC/FUNET
Expiration Date: August 2004
February 2004
IPv6 Transition/Co-existence Security Considerations
draft-savola-v6ops-security-overview-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
The transition/co-existance from IPv4 to IPv4/IPv6 causes one to
consider the security considerations of such a process. In this
memo, I try to give an overview of different aspects relating to IPv6
grouped in three categories: issues due to IPv6 protocol itself,
issues due to transition mechanisms, and issues due to IPv6
deployment.
Savola [Expires August 2004] [Page 1]
Internet Draft draft-savola-v6ops-security-overview-01.txt February 2004
Table of Contents
1. Introduction ............................................... 2
2. Issues Due to IPv6 Protocol ................................ 3
2.1. IPv6 Protocol-specific Issues .......................... 3
2.2. IPv4-mapped IPv6 Addresses ............................. 4
2.3. Increased End-to-End Transparency ...................... 4
3. Issues Due to Transition Mechanisms ........................ 5
3.1. IPv6 Transition/Co-existence Mechanism-specific Issues . 5
3.2. Automatic Tunneling and Relays ......................... 5
3.3. Tunneling May Break Security Assumptions ............... 6
4. Issues Due to IPv6 Deployment .............................. 7
4.1. IPv6 Service Piloting Done Insecurely .................. 7
4.2. Enabling IPv6 by Default Brings the Usability Down ..... 8
4.3. Operational Factors when Enabling IPv6 in the Network .. 8
5. Acknowledgements ........................................... 9
6. Security Considerations .................................... 9
7. References ................................................. 9
7.1. Normative .............................................. 9
7.2. Informative ............................................ 9
Author's Address ............................................... 11
A. IPv6 Probing/Mapping Considerations ........................ 11
B. IPv6 Privacy Considerations ................................ 12
B.1. Exposing MAC Addresses ................................. 12
B.2. Exposing Multiple Devices .............................. 12
Intellectual Property Statement ................................ 13
Full Copyright Statement ....................................... 13
1. Introduction
The transition/co-existance from IPv4 to IPv4/IPv6 causes one to
consider the security considerations of such a process. In this
memo, I try to give an overview of different aspects relating to IPv6
grouped in three categories: issues due to IPv6 protocol itself,
issues due to transition mechanisms, and issues due to IPv6
deployment.
A view of IPv6 transition has been presented in a separate document
[TRANS]; it is important to read it at least cursorily to understand
that the point is not about replacing IPv4 with IPv6 (in the short
term), but adding IPv6 alongside IPv4.
This document also (at the moment, may be removed in future versions)
describes two "non-issues", in Appedix A and B: considerations about
probing/mapping IPv6 addresses, and considerations wrt. privacy in
Savola [Expires August 2004] [Page 2]
Internet Draft draft-savola-v6ops-security-overview-01.txt February 2004
IPv6.
2. Issues Due to IPv6 Protocol
2.1. IPv6 Protocol-specific Issues
Some features of IPv6 are a bit different from IPv4, and may include
some potential problems specification-wise. Some examples include at
least:
o how hosts should interact with routing headers (they must act as
forwarders) [RHHOSTS]
o how routing headers may be too generic contructs to be useful for
e.g. MIPv6 purposes [RHHAOSEC]
o how home address option was previously specified (fixed now)
[RHHAOSEC]
o how ICMPv6 messages, in some cases, may be generated in response
to multicast packets (where in IPv4 they can't) [FW]
o how the privacy IPv6 addresses may not actually provide all that
much privacy (ie. the applicability is unclear) [3041HARM]
o how IPv6 has been specified wrt. middleboxes such as firewalls
(e.g. when new extension headers etc. are used) [FW]
On the other hand, there are several aspects where IPv4 security is
weak have been made stronger (at least by additional specifications),
at least:
o threats related to local links, comparable to different ARP
spoofing techniques; the ND threats have been documented
[SENDREQ] and fixes specified [SEND]
o Mobile IPv6 depends on the return routability checks for its
security; this seems relatively robust form of security; the
design has been described in [RRSEC]
Appendix A lists (typically bogus) considerations related to IPv6
network mapping or probing. Appendix B lists mainly unfound claims
about the lack of privacy in IPv6.
Savola [Expires August 2004] [Page 3]
Internet Draft draft-savola-v6ops-security-overview-01.txt February 2004
2.2. IPv4-mapped IPv6 Addresses
Overloaded functionality is always a double-edged sword: it may yield
some deployment benefits, but often also incurs the price which comes
with ambiguity.
One example of such is IPv4-mapped IPv6 addresses: a representation
of IPv4 address as an IPv6 address inside an operating system. Since
then, IPv4-mapped addresses have been extended to be used with a
transition mechanism [SIIT], on the wire.
Therefore, it becomes difficult to unambiguously discern whether an
IPv4 mapped address is really an IPv4 address represented in the IPv6
address format *or* an IPv6 address received from the wire (which may
be subject to address forgery, etc.).
In addition, special cases like these, while giving deployment
benefits in some arenas, require some amount of code complexity (e.g.
in the implementations of bind() system calls) which we might be
better off without [V4MAPPEDA] [V4MAPPEDW].
At least, the mapped addresses should be disallowed on the wire.
Changing the application behavior would have significant impact on
application porting methods, though.
2.3. Increased End-to-End Transparency
With IPv6, increased end-to-end transparency in general can sometimes
be seen as a threat. Some seem to want limited end-to-end
capabilities, e.g. in the form of private, local addressing, even
when it is not necessary.
People have gotten used to the perceived, dubious security benefits
of NATs and perimeter firewalls, and the bidirectionality and
transparency that IPv6 can provide may seem undesirable at times.
This is a really important issue especially for most enterprise
network managers.
It is worth noting that IPv6 does not *require* end-to-end
connectivity. It merely provides end-to-end addressability; the
connectivity can still be controlled using firewalls (or other
mechanisms), and it is indeed wise to do so.
Savola [Expires August 2004] [Page 4]
Internet Draft draft-savola-v6ops-security-overview-01.txt February 2004
3. Issues Due to Transition Mechanisms
3.1. IPv6 Transition/Co-existence Mechanism-specific Issues
The more complicated the IPv6 transition/co-existence becomes, the
more danger there is to introduce security issues in the mechanisms
(which may or may not be readily apparent). Therefore it would be
desirable to keep the mechanisms simple, in as small pieces as
possible.
One case where such security issues have been analyzed is [6TO4SEC].
As tunneling has been proposed as a model for quite a bit more cases
than are currently being used, its security properties should be
analyzed in more detail. There are some generic dangers to
tunneling:
o it may be easier to avoid ingress filtering checks
o it is possible to attack the tunnel interface: several IPv6
security mechanisms depend on checking that Hop Limit equals 255
on receipt and that link-local addresses are used. Sending such
packets to the tunnel interface is much easier than gaining
access to a physical segment and sending them there.
o automatic tunneling mechanisms are typically particularly
dangerous as the other end-point is unspecified, and packets have
to be accepted and decapsulated from everywhere. Therefore,
special care should be observed when specifying automatic
tunneling techniques.
3.2. Automatic Tunneling and Relays
Two mechanisms have been (or are being) specified which use automatic
tunneling over IPv4 or UDP/IPv4 between the nodes enabling the same
mechanism for connectivity: 6to4 and Teredo (respectively).
The first obvious issue (as mentioned above) in such approaches is
that such nodes must allow decapsulation of traffic from anywhere in
the Internet. That kind of decapsulation function must be extremely
well secured as it's so wide open.
Even more difficult problem is how these mechanisms are able to
communicate with native IPv6 nodes or between the automatic tunneling
mechanisms: such connectivity requires the use of some kind of
"relays". These relays could be deployed e.g., in all native IPv6
nodes, native IPv6 sites, IPv6 ISPs, or just somewhere in the
Internet. This has some obvious trust and scaling issues. As
Savola [Expires August 2004] [Page 5]
Internet Draft draft-savola-v6ops-security-overview-01.txt February 2004
authentication of such a relay service is very difficult, and more so
in some of those deployment models, relays provide a means to for
address spoofing, (reflected) Denial-of-Service attacks, and other
threats.
Threats related to 6to4 are discussed in [6TO4SEC].
3.3. Tunneling May Break Security Assumptions
NATs and firewalls have been deployed extensively in the IPv4
Internet, for the good or the bad. People who deploy them typically
have some security/operational requirements in mind (e.g. a desire to
block inbound connection attempts), whether misguided or not.
Tunneling can change that model. IPv6-over-IPv4 tunneling is
typically explicitly allowed or disallowed implicitly. Tunneling
IPv6 over IPv4 with UDP, however, is often an entirely different
thing: as UDP must usually be allowed through, at least in part and
in a possibly stateful manner, one can "punch holes" in NAT's and
firewalls using UDP. Actually, the mechanisms have been explicitly
designed to traverse both NATs and firewalls in a similar fashion.
One could say that tunneling is especially questionable in home/SOHO
environments where the level of network administration is not that
high; in these environments the hosts may not be as managed as in
others (e.g., network services might be enabled unnecessarily),
leading to possible security break-ins or other vulnerabilities.
Holes can be punched both intentionally and unintentionally. In case
it is a willing choice from the administrator/user, this is less of a
problem (but e.g., enterprises might want to block IPv6 tunneling
explicitly if some employees would do something like this willingly
on their own). On the other hand, if a hole is punched
transparently, without people understanding the consequences, it will
very probably result in a serious threat sooner or later.
When deploying tunneling solutions, especially tunneling solutions
which are automatic and/or can be enabled easily by users not
understanding the consequences, care should be taken not to
compromise the security assumptions held by the users.
For example, NAT traversal should not be performed by default unless
there is a firewall producing a similar by-default security policy as
IPv4 NAT provides. Protocol-41 tunneling is 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 well.
Savola [Expires August 2004] [Page 6]
Internet Draft draft-savola-v6ops-security-overview-01.txt February 2004
As has been shown in Appendix A, it is relatively easy to find out
IPv6 address of an IPv4, so one should never rely on "security by
obscurity" i.e., relying that nobody is able to guess or know the
IPv6 address of the host.
4. Issues Due to IPv6 Deployment
4.1. IPv6 Service Piloting Done Insecurely
In many cases, IPv6 service piloting is done in a manner which is
considered to be less secure than as one would do with IPv4. For
example, hosts and routers might not be protected by IPv6 firewalls,
even if in IPv4 firewalls are being used.
The other possible alternative, in some places, is that no service
piloting is done at all because IPv6 firewalls may not be widely used
-- and IPv6 deployment suffers (of course, this is also one of the
nice excuses for not doing IPv6).
This problem may be partially due to a slow speed of IPv6-capable
firewall development and deployment. However, it is also a problem
with a lack of information: actually, there are quite a few IPv6
packet filters and firewalls already, which could be used for
sufficient access controls, but network administrators may not be
aware of them yet.
However, there appears to be a real lack in two areas: "personal
firewalls" and enterprise firewalls; the same devices that support
and are used for IPv4 today are often expected to also become
IPv6-capable -- even though this is not really required. That is,
IPv4 access could be filtered by one firewall, and when IPv6 access
is added, it could be protected by another firewall; they don't have
to be the same, and even their models don't have to be the same.
Another, smaller factor may be that due to a few decisions on how
IPv6 was built, it's more difficult for firewalls to be implemented
and work under all the cases (e.g. when new extension headers etc.
are used) [FW]: it's a bit more difficult for intermediate nodes to
process the IPv6 header chains than IPv4 packets.
A similar argument, stated to hinder IPv6 deployment, has been the
lack of Intrusion Detection Systems (IDS). It's not clear whether
this is more of an excuse than a real reason.
Savola [Expires August 2004] [Page 7]
Internet Draft draft-savola-v6ops-security-overview-01.txt February 2004
4.2. Enabling IPv6 by Default Brings the Usability Down
A practical disadvantage of enabling IPv6 as of this writing is that
it typically brings the observed service level down a bit; that is,
the usability suffers.
This is due to at least three reasons:
o global IPv6 routing is still rather unstable, leading to packet
loss, lower throughput, and higher delay [6BMESS]
o some applications can not properly handle both IPv4 and IPv6 or
may have problems handling all the fallbacks and failure modes
(and in some cases, e.g. if the TCP timeout kicks in, this may be
very difficult)
o some DNS server implementations have flaws that severely affect
DNS queries for IPv6 addresses [DNSA4]
Actually, some would be 100% ready to release IPv6 services (e.g.
web) today, but that would mean trouble for many of their dual-
stacked customers or users all over the world so they don't: these
are often published under a separate domain or subdomain, and are
practically not used that often.
These issues are also described at some length in [ONBYDEF].
4.3. Operational Factors when Enabling IPv6 in the Network
You have to be careful when enabling IPv6 in the network gear for
multiple reasons:
IPv6-enabled router software may be unstable(r) yet; either IPv6 is
unstable, or the software you have to run to be able to run IPv6 is
different (from non-IPv6 parts) from the one you would run otherwise,
making the software in practice more unstable -- and raising the bar
for IPv6 adoption.
IPv6 processing may not happen at (near) line speed (or in the same
level as IPv4). A high amount of IPv6 traffic (even legitimate, e.g.
NNTP) could easily overload the software-based IPv6 processing and
cause harm also to IPv4 processing, affecting availability. That is,
if people don't feel confident enough in the IPv6 support, they will
be hesitant to enable it in their "production" networks.
Sometimes required features may be missing from the vendors' software
releases; an example is a software enabling IPv6 telnet/SSH access,
but having no ability to turn it off or limit access to it!
Savola [Expires August 2004] [Page 8]
Internet Draft draft-savola-v6ops-security-overview-01.txt February 2004
Sometimes the default IPv6 configuration is insecure. For example,
in one vendor, if you've restricted IPv4 telnet to only a few hosts
in the configuration, you need to be aware that IPv6 telnet will be
automatically enabled, that the configuration commands 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 lock
down the IPv6 telnet access.
Many operator networks have to run interior routing protocols for
both IPv4 and IPv6. It's possible to run the both in one routing
protocol, or have two separate routing protocols; either approach has
its tradeoffs. If multiple routing protocols are used, one should
note that this causes double the number of processing when links flap
or recalculation is otherwise needed -- which might more easily
overload the routers' CPU, causing slightly slower convergence time.
5. Acknowledgements
Alain Durand, Alain Baudot, Luc Beloeil, and Andras Kis-Szabo
provided feedback to improve this memo. Michael Wittsend and Michael
Cole discussed issues relating to probing/mapping and privacy.
6. Security Considerations
This memo tries to give an overview of security considerations of the
different aspects of IPv6.
7. References
7.1. Normative
[TRANS] Savola, P., "A View on IPv6 Transition Architecture",
draft-savola-v6ops-transarch-03.txt, Jan 2004.
7.2. Informative
[3041HARM] Dupont, F., Savola, P., "RFC 3041 Considered Harmful",
draft-dupont-ipv6-rfc3041harmful-04.txt, Feb 2004.
[6BMESS] Savola, P., "Moving from 6bone to IPv6 Internet",
draft-savola-v6ops-6bone-mess-01.txt, Nov 2002.
[6TO4SEC] Savola, P., Patel, C., "Security Considerations for
6to4", draft-ietf-v6ops-6to4-security-01.txt, Feb 2004.
[DNSA4] Morishita., Y., Jinmei, T., "Common Misbehavior against
DNS Queries for IPv6 Addresses", draft-morishita-dnsop-
misbehavior-against-aaaa-00.txt, Jun 2003.
Savola [Expires August 2004] [Page 9]
Internet Draft draft-savola-v6ops-security-overview-01.txt February 2004
[FNAT] Bellovin, S., "A Technique for Counting NATted Hosts",
Second Internet Measurement Workshop,
http://www.research.att.com/~smb/papers/fnat.pdf,
Nov 2003.
[FW] Savola, P. "Firewalling Considerations for IPv6",
draft-savola-v6ops-firewalling-02.txt, Oct 2003.
[MAPPING] Schild, C., Strauf, C., "Guide to Mapping IPv4 to IPv6
Subnets", draft-schild-v6ops-guide-v4mapping-00.txt,
Dec 2003.
[ONBYDEF] Roy, S., et al., "Dual Stack IPv6 on by Default",
draft-ietf-v6ops-v6onbydefault-00.txt, Jun 2003.
[PORTSCAN] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning",
draft-chown-v6ops-port-scanning-implications-00.txt,
Oct 2003.
[RHHAOSEC] Savola, P. "Security of IPv6 Routing Header and
Home Address Options",
draft-savola-ipv6-rh-ha-security-03.txt, Dec 2002.
[RHHOSTS] Savola, P. "Note about Routing Header Processing on IPv6
Hosts", draft-savola-ipv6-rh-hosts-00.txt, Feb 2002.
[RRSEC] Nikander, P, et al., "Mobile IP version 6 Route
Optimization Security Design Background",
draft-nikander-mobileip-v6-ro-sec-02.txt, Dec 2003.
[SEND] Arkko, J., et al., "SEcure Neighbor Discovery (SEND)",
draft-ietf-send-ndopt-03.txt, Jan 2004.
[SENDREQ] Nikander, P., et al., "IPv6 Neighbor Discovery trust
models and threats", draft-ietf-send-psreq-04.txt,
Oct 2003.
[SIIT] Nordmark, E., "Stateless IP/ICMP Translation Algorithm",
RFC276, February 2000.
[V4MAPPEDA] Metz, C., Hagino, J., "IPv4-Mapped address API considered
harmful", draft-cmetz-v6ops-v4mapped-api-harmful-01.txt,
Oct 2003.
[V4MAPPEDW] Metz, C., Hagino, J., "IPv4-Mapped Addresses on the Wire
Considered Harmful",
draft-itojun-v6ops-v4mapped-harmful-02.txt, Oct 2003.
Savola [Expires August 2004] [Page 10]
Internet Draft draft-savola-v6ops-security-overview-01.txt February 2004
Author's Address
Pekka Savola
CSC/FUNET
Espoo, Finland
EMail: psavola@funet.fi
A. IPv6 Probing/Mapping Considerations
Some want the IPv6 numbering topology (either at network or node
level) [MAPPING] match IPv4 as exactly as possible, the others see
this as a security threat because IPv6 could have different security
properties than IPv4.
That is, if an attacker knows the IPv4 address of the node, he might
want to try to probe the corresponding IPv6 address, based on the
assumption that the security defenses might be lower. This might be
the case particularly for nodes which are behind a NAT in IPv4, but
globally addressable in IPv6. Naturally, this is not a concern if
the similar security policies are in place.
On the other hand, brute-force scanning or probing is unfeasible
[PORTSCAN].
For example, automatic tunneling mechanisms use rather deterministic
methods for generating IPv6 addresses, so probing/port-scanning an
IPv6 node is simplified. The IPv4 address is embedded at least in
6to4, Teredo and ISATAP address. Further than that, it's possible
(in the case of 6to4 in particular) to learn the address behind the
prefix; for example, Microsoft 6to4 implementation uses the address
2002:V4ADDR::V4ADDR while Linux and BSD implementations default to
2002:V4ADDR::1. This could also be used as one way to identify an
implementation.
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
6to4 router (whether a host or a router) will return an ICMPv6 Hop
Limit Exceeded message, revealing the IP address. Hosts behind the
6to4 router can use methods such as RFC 3041 addresses to conceal
themselves, though.
To conclude, it seems that with an IPv4 address, the respective IPv6
address, when automatic tunneling mechanism is being used, could
possibly be guessed with relative ease. This has significant
implications if the IPv6 security policy isn't the same as IPv4.
Savola [Expires August 2004] [Page 11]
Internet Draft draft-savola-v6ops-security-overview-01.txt February 2004
B. IPv6 Privacy Considerations
It has 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
The MAC address, which with stateless address autoconfiguration,
results in an EUI64, exposes the model of network card. The concern
has been that a user might not want to expose the details of the
system to outsiders, e.g., in the fear of a resulting burglary (e.g.,
if a crook identifies expensive equipment from the MAC addresses).
In most cases, this seems completely unfounded. First, such an
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
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
eavesdrop the traffic to learn such addresses (e.g., by the
compromise of DSL or Cable modem physical media) seems also quite
far-fetched. Further, using RFC 3041 addresses for such purposes is
straightforward if worried about the risk. Second, the burglar would
have to be able to map the IP address to the physical location; this
is typically only available in the private customer database of the
ISP.
B.2. Exposing Multiple Devices
Another presented concern is whether the user wants to show off as
having a lot of computers or other devices at a network; NAT "hides"
everything behind an address, but is not perfect either [FNAT].
One practical reason why some may find this desirable is being able
to thwart certain ISPs' business models, where one should pay extra
for additional computers (and not the connectivity as a whole).
Similar feasibility issues as described above apply. To a degree,
the counting avoidance could be performed by the sufficiently
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
difficult to estimate whether they are generated by just one host or
multiple hosts.
Savola [Expires August 2004] [Page 12]
Internet Draft draft-savola-v6ops-security-overview-01.txt February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
Savola [Expires August 2004] [Page 13]
Internet Draft draft-savola-v6ops-security-overview-01.txt February 2004
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Savola [Expires August 2004] [Page 14]