draft-ietf-v6ops-onlinkassumption-00.txt   draft-ietf-v6ops-onlinkassumption-01.txt 
Network Working Group S. Roy Network Working Group S. Roy
Internet-Draft A. Durand Internet-Draft A. Durand
Expires: April 19, 2004 J. Paugh Expires: August 31, 2004 J. Paugh
Sun Microsystems, Inc. Sun Microsystems, Inc.
October 20, 2003 March 2, 2004
IPv6 Neighbor Discovery On-Link Assumption Considered Harmful IPv6 Neighbor Discovery On-Link Assumption Considered Harmful
draft-ietf-v6ops-onlinkassumption-00.txt draft-ietf-v6ops-onlinkassumption-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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 http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. 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 April 19, 2004. This Internet-Draft will expire on August 31, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document proposes a change to the IPv6 Neighbor Discovery This document proposes a change to the IPv6 Neighbor Discovery
conceptual host sending algorithm. According to the algorithm, when conceptual host sending algorithm. According to the algorithm, when
a host's default router list is empty, the host assumes that all a host's default router list is empty, the host assumes that all
destinations are on-link. This document describes how making this destinations are on-link. This is particularly problematic with
IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g.,
no default router). This document describes how making this
assumption causes problems, and describes how these problems outweigh assumption causes problems, and describes how these problems outweigh
the benefits of this part of the conceptual sending algorithm. the benefits of this part of the conceptual sending algorithm.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background on the On-link Assumption . . . . . . . . . . . . . 3
3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 First Rule of Destination Address Selection . . . . . . . . . 5 3.1 First Rule of Destination Address Selection . . . . . . . . . 3
3.2 Delays Associated with Address Resolution . . . . . . . . . . 5 3.2 Delays Associated with Address Resolution . . . . . . . . . . 4
3.3 Multi-homing Ambiguity . . . . . . . . . . . . . . . . . . . . 6 3.3 Multi-homing Ambiguity . . . . . . . . . . . . . . . . . . . . 4
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4 Security Related Issues . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 4. Proposed Changes to RFC2461 . . . . . . . . . . . . . . . . . 5
Normative References . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
Informative References . . . . . . . . . . . . . . . . . . . . 10 Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Informative References . . . . . . . . . . . . . . . . . . . . 6
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 12 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
B. Changes from draft-ietf-v6ops-onlinkassumption-00 . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 8
1. Introduction 1. Introduction
Neighbor Discovery for IPv6 [ND] defines a conceptual sending Neighbor Discovery for IPv6 [ND] defines a conceptual sending
algorithm for hosts. This algorithm states that if a host's default algorithm for hosts. This algorithm states that if a host's default
router list is empty, then the host assumes that all destinations are router list is empty, then the host assumes that all destinations are
on-link. on-link.
This assumption creates problems for destination address selection as This assumption is problematic with IPv6-capable nodes that do not
defined in [ADDRSEL], and adds connection delays associated with have off-link IPv6 connectivity. Specifically, it creates problems
unnecessary address resolution and neighbor unreachability detection. for destination address selection as defined in [ADDRSEL], and adds
The behavior associated with the assumption is undefined in connection delays associated with unnecessary address resolution and
multihomed scenarios, and has some subtle security implications. All neighbor unreachability detection. The behavior associated with the
of these issues are discussed in this document. assumption is undefined in multihomed scenarios, and has some subtle
security implications. All of these issues are discussed in this
document.
2. Background 2. Background on the On-link Assumption
This part of Neighbor Discovery's [ND] conceptual sending algorithm This part of Neighbor Discovery's [ND] conceptual sending algorithm
was created to facilitate communication on a single link between was created to facilitate communication on a single link between
systems manually configured with different global prefixes. For systems manually configured with different global prefixes. For
example, two systems that are manually configured with global example, consider the case where two systems on separate links are
addresses while on separate links are then plugged in back-to-back. manually configured with global addresses, and are then plugged in
They can still communicate with each other via their global addresses back-to-back. They can still communicate with each other via their
because they'll correctly assume that each is on-link. global addresses because they'll correctly assume that each is
on-link.
Without the on-link assumption, the above scenario wouldn't work as Without the on-link assumption, the above scenario wouldn't work as
seamlessly. One workaround would be to use link-local addresses for seamlessly. One workaround would be to use link-local addresses for
this communication. Another is to configure new global addresses this communication. Another is to configure new global addresses
using the same /64 prefix on these systems, either by manually using the same /64 prefix on these systems, either by manually
configuring such addresses, or by placing a router on-link that configuring such addresses, or by placing a router on-link that
advertises this prefix. advertises this prefix.
3. Problems 3. Problems
skipping to change at page 6, line 10 skipping to change at page 4, line 44
For an IPv6 enabled host deployed on a network that has no IPv6 For an IPv6 enabled host deployed on a network that has no IPv6
routers, the result of the on-link assumption is that link-layer routers, the result of the on-link assumption is that link-layer
address resolution must be performed on all IPv6 addresses to which address resolution must be performed on all IPv6 addresses to which
the host sends packets. The Application will not receive the host sends packets. The Application will not receive
acknowledgment of the unreachability of destinations that are not acknowledgment of the unreachability of destinations that are not
on-link until at least address resolution has failed, which is no on-link until at least address resolution has failed, which is no
less than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER) less than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER)
(amplified by transport protocol delays). When the application has a (amplified by transport protocol delays). When the application has a
large list of off-link unreachable IPv6 addresses followed by at large list of off-link unreachable IPv6 addresses followed by at
least one reachable IPv4 address, the delay associated with NUD of least one reachable IPv4 address, the delay associated with Neighbor
each IPv6 addresses before successful communication with the IPv4 Unreachability Detection (NUD) of each IPv6 addresses before
address is unacceptable. successful communication with the IPv4 address is unacceptable.
3.3 Multi-homing Ambiguity 3.3 Multi-homing Ambiguity
There is no defined way to implement this aspect of the sending There is no defined way to implement this aspect of the sending
algorithm on a multi-homed node. From an implementor's point of algorithm on a multi-homed node. From an implementor's point of
view, there are three ways to handle sending an IPv6 packet to a view, there are three ways to handle sending an IPv6 packet to a
destination in the face of the on-link assumption on a multi-homed destination in the face of the on-link assumption on a multi-homed
node: node:
1. Attempt to resolve the destination on a single link. 1. Attempt to resolve the destination on a single link.
2. Attempt to resolve the destination on every link. 2. Attempt to resolve the destination on every link.
3. Drop the packet. 3. Drop the packet.
If the destination is indeed on-link, the first option may not If the destination is indeed on-link, the first option might not
succeed since the wrong link could be picked. The second option succeed since the wrong link could be picked. The second option
would always succeed in reaching the destination (assuming that it's might succeed in reaching a destination (assuming that one is
reachable) but is more complex to implement. Dropping the packet is reachable) but is more complex to implement, and isn't guaranteed to
equivalent to not making the on-link assumption at all. In other pick the correct destination. For example, there is still ambiguity
words, if there is no route to the destination, don't attempt to send about which link to use if more than one node answers the
the packet. solicitations on multiple links. Dropping the packet is equivalent
to not making the on-link assumption at all. In other words, if
there is no route to the destination, don't attempt to send the
packet.
4. Conclusion 3.4 Security Related Issues
The on-link assumption discussed here introduces a security
vulnerability to the Neighbor Discovery protocol described in section
4.2.2 of IPv6 Neighbor Discovery Trust Models and Threats [PSREQ]
titled "Default router is 'killed'". There is a threat that a host's
router can be maliciously killed in order to cause the host to start
sending all packets on-link. The attacker can then spoof off-link
nodes by sending packets on the same link as the host. The
vulnerability is discussed in detail in [PSREQ].
Another security related side-effect of the on-link assumption has to
do with VPN's. It has been observed that some commercially available
VPN software solutions that don't support IPv6 send IPv6 packets to
the local media in the clear (their security policy doesn't simply
drop IPv6 packets). Consider a scenario where a system has a single
Ethernet interface with VPN software that encrypts and encapsulates
certain packets. The system attempts to send a packet to an IPv6
destination that it obtained by doing a DNS lookup, and the packet
ends up going in the clear to the local media. A malicious second
party could then spoof the destination on-link.
4. Proposed Changes to RFC2461
This document suggests the following changes to the Neighbor This document suggests the following changes to the Neighbor
Discovery [ND] specification: Discovery [ND] specification:
The last sentence of the second paragraph of section 5.2 The last sentence of the second paragraph of section 5.2
("Conceptual Sending Algorithm") should be removed. This sentence ("Conceptual Sending Algorithm") should be removed. This sentence
is currently, "If the Default Router List is empty, the sender is currently, "If the Default Router List is empty, the sender
assumes that the destination is on-link. assumes that the destination is on-link.
Bullet item 3) in section 6.3.6 ("Default Router Selection") Bullet item 3) in section 6.3.6 ("Default Router Selection")
skipping to change at page 8, line 7 skipping to change at page 6, line 24
The result of these changes is that destinations are considered The result of these changes is that destinations are considered
unreachable when there is no routing information for that destination unreachable when there is no routing information for that destination
(through a default router or otherwise). Instead of attempting (through a default router or otherwise). Instead of attempting
link-layer address resolution when sending to such a destination, a link-layer address resolution when sending to such a destination, a
node should send an ICMPv6 Destination Unreachable message (code 0 - node should send an ICMPv6 Destination Unreachable message (code 0 -
no route to destination) message up the stack. no route to destination) message up the stack.
5. Security Considerations 5. Security Considerations
The on-link assumption discussed here introduces a security The removal of the on-link assumption from Neighbor Discovery removes
vulnerability to the Neighbor Discovery protocol described in section some security related vulnerabilities of the protocol as described in
4.2.2 of IPv6 Neighbor Discovery Trust Models and Threats [PSREQ] Section 3.4.
titled "Default router is 'killed'". There is a threat that a host's
router can be maliciously killed in order to cause the host to start
sending all packets on-link. The attacker can then spoof off-link
nodes by sending packets on the same link as the host. The
vulnerability is discussed in detail in [PSREQ].
Another security related side-effect of the on-link assumption has to
do with VPN's. It has been observed that some commercially available
VPN software solutions that don't support IPv6 send IPv6 packets to
the local media in the clear (their security policy doesn't simply
drop IPv6 packets). Consider a scenario where a system has a single
Ethernet interface with VPN software that encrypts and encapsulates
certain packets. The system attempts to send a packet to an IPv6
destination that it obtained by doing a DNS lookup, and the packet
ends up going in the clear to the local media. A malicious second
party could then spoof the destination on-link.
Normative References Normative References
[ADDRSEL] Draves, R., "Default Address Selection for Internet [ADDRSEL] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor [ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998. 1998.
[PSREQ] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor [PSREQ] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
Discovery trust models and threats", Discovery trust models and threats", October 2003.
draft-ietf-send-psreq-04, October 2003.
draft-ietf-send-psreq-04
Informative References Informative References
[AUTOCONF] [AUTOCONF]
Thomson, S. and T. Narten, "IPv6 Stateless Address Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
Authors' Addresses Authors' Addresses
Sebastien Roy Sebastien Roy
skipping to change at page 12, line 5 skipping to change at page 7, line 36
UMPK17-202 UMPK17-202
Menlo Park, CA 94025 Menlo Park, CA 94025
EMail: james.paugh@sun.com EMail: james.paugh@sun.com
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors gratefully acknowledge the contributions of Jim Bound, The authors gratefully acknowledge the contributions of Jim Bound,
Mika Liljeberg, Erik Nordmark, Pekka Savola, and Ronald van der Pol. Mika Liljeberg, Erik Nordmark, Pekka Savola, and Ronald van der Pol.
Appendix B. Changes from draft-ietf-v6ops-onlinkassumption-00
o Clarrified in the abstract and introduction that the problem is
with systems that are IPv6 enabled but have no off-link
connectivity.
o In section Section 3.3, clarified that soliciting on all links
could have ambiguous results.
o The old Security Considerations section was moved to section
Section 3.4, and the new Security Considerations section refers to
that new section.
o Miscelaneous editorial changes.
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 or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
skipping to change at page 12, line 29 skipping to change at page 8, line 29
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

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