DNA WG JinHyeock Choi
Internet-Draft Samsung AIT
Expires: March 11, 2005 Greg Daley
CTIE Monash University
September 10, 2004
Detecting Network Attachment in IPv6 Goals
draft-ietf-dna-goals-01.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 11, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
At the time a host establishes a new link-layer connection, it may or
may not have a valid IP configuration for Internet connectivity. The
host may check for link change, i.e. determine whether a link change
has occurred, and then, based on the result, it can automatically
decide whether its IP configuration is still valid or not. During
link identity detection, the host may also collect necessary
information to initiate a new IP configuration for the case that the
IP subnet has changed. In this memo, this procedure is called
Choi & Daley Expires March 11, 2005 [Page 1]
Internet-Draft DNA Goals September 2004
Detecting Network Attachment (DNA). DNA schemes should be precise,
sufficiently fast, secure and of limited signaling.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problems in Detecting Network Attachment . . . . . . . . . . . 5
2.1 Wireless link properties . . . . . . . . . . . . . . . . . 5
2.2 Link identity detection with a single RA . . . . . . . . . 5
2.3 Delays . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Goals for Detecting Network Attachment . . . . . . . . . . . . 7
3.1 Goals list . . . . . . . . . . . . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1 Normative References . . . . . . . . . . . . . . . . . . . . 12
7.2 Informative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 14
Choi & Daley Expires March 11, 2005 [Page 2]
Internet-Draft DNA Goals September 2004
1. Introduction
When a host has established a new link-layer connection, it can send
and receive some IP packets at the link, particularly those used for
configuration. On the other hand, the host has full Internet
connectivity only when it is able to exchange packets with arbitrary
destinations.
When a link-layer connection is established or re-established, the
host may not know whether its existing IP configuration is still
valid for Internet connectivity. A subnet change might have occurred
when the host changed its attachment point.
In practice, the host doesn't know which of its addresses are valid
on the newly attached link. The host knows neither if its existing
default router is on this link, nor whether its neighbor cache
entries are valid. Correct configuration of each of these components
are necessary in order to send packets on and off the link.
To examine the status of the existing configuration, a host may check
whether a 'link change' has occurred. The term 'link' used in this
document is as defined in RFC 2461 [4].
Today a link change necessitates an IP configuration change.
Whenever a host detects that it has remained at the same link, it can
usually assume its IP configuration is still valid. Otherwise, the
existing one is no longer valid and a new configuration must be
acquired. Hence a host only needs to check for link change to
examine the validity of its IP configuration.
In the process of checking for link change, a host may collect some
of the necessary information for a new IP configuration, such as
on-link prefixes. So, when an IP subnet change has occurred, the
host can immediately initiate the process of getting a new IP
configuration. This may reduce handoff delay and minimize signaling.
Rapid attachment detection is required for a device that changes
subnet while having on-going sessions. This may be the case if a
host is connected intermittently, is a mobile node, or has urgent
data to transmit upon attachment to a link.
The process by which a host collects the appropriate information and
detects the identity of its currently attached link to ascertains the
validity of its IP configuration, is called Detecting Network
Attachment (DNA).
It is important to note that DNA process does not include the actual
IP configuration procedure. For example, with respect to DHCP, the
Choi & Daley Expires March 11, 2005 [Page 3]
Internet-Draft DNA Goals September 2004
DNA process may determine that the host needs to get some
configuration information from a DHCP server. However, the process
of actually retrieving the information from a DHCP server falls
beyond the scope of DNA.
Choi & Daley Expires March 11, 2005 [Page 4]
Internet-Draft DNA Goals September 2004
2. Problems in Detecting Network Attachment
There are a number of issues that make DNA complicated. First,
wireless connectivity is not as clear-cut as wired one. Second it's
difficult for a single RA message to indicate a link change. Third,
Router Discovery may take too long and result in service disruption.
2.1 Wireless link properties
Unlike wired environments, what constitutes wireless link is variable
in both time and space. It doesn't have clear boundaries. This may
be illustrated by the fact that a host may contact multiple (802.11)
access points at the same time. Moreover connectivity on a wireless
link can be very volatile, which may make link identity detection
hard. For example, it takes time for a host to check for link
change. If the host ping-pongs between two links and doesn't stay
enough time at a link, it can't complete DNA procedure.
2.2 Link identity detection with a single RA
Usually a host gets the information necessary for IP configuration
from RA messages. Based on the current definition [4], it's
difficult for a host to check for link change upon a single RA
reception.
To detect link identity, a host may compare the information in an RA,
such as router address or prefixes, with the existing one.
The host may use router address to try to check for link change. The
router address in the source address field of an RA is of link-local
scope, however, so its uniqueness is not guaranteed outside of a
link. If it happens that two different router interfaces on
different links have the same link-local address, the host can't
detect that it has moved from one link to another by checking the
router address in RA messages.
The set of all the global prefixes assigned to a link can represent
link identity. The host may compare the prefixes in an incoming RA
with the currently stored ones. An unsolicited RA message, however,
can omit some prefixes for convenience [4] and it's not easy for a
host to attain and retain all the prefixes on a link with certainty.
Hence, neither the absence of a previously known prefix nor the
presence of a previously unknown prefix in the RA guarantees that a
link change has occurred.
2.3 Delays
The following issues cause DNA delay that may result in communication
Choi & Daley Expires March 11, 2005 [Page 5]
Internet-Draft DNA Goals September 2004
disruption.
1) Delay for receiving a hint
Hint is an indication that a link change might have occurred. This
hint itself doesn't confirm a link change, but initiates appropriate
DNA procedures to detect the identity of the currently attached link.
Hints come in various forms, and differ in how they indicate a
possible link change. They can be link-layer event notifications,
the lack of RA from the default router or the receipt of a new RA.
The time taken to receive a hint also varies.
As soon as a new link-layer connection has been made, the link-layer
may send a link up notification to the IP layer. A host may
interpret the new link-layer connection as a hint for a possible link
change. With link-layer support, a host can receive a hint almost
instantly.
Mobile IPv6 [8] defines the use of RA Interval Timer expiry for a
hint. A host keeps monitoring periodic RAs and interprets the lack
of them as a hint. It may implement its own policy to determine the
number of missing RAs for a hint. Hence the delay depends on the
Router Advertisement interval.
Without the schemes such as above, a host must receive a new RA from
a new router to detect a possible link change. The detection time
then also depends on the Router advertisement frequency.
Periodic RA beaconing transmits packets within an interval varying
randomly between MinRtrAdvInterval to MaxRtrAdvInterval seconds.
Because a network attachment is unrelated to the advertisement time
on the new link, the host is expected to arrive on average half way
through the interval. This is approximately 1.75 seconds with
Neighbor Discovery [4] advertisement rates.
2) Random delay execution for RS/ RA exchange
Router Solicitation and Router Advertisement messages are used for
Router Discovery. According to [4], it is sometimes necessary for a
host to wait a random amount of time to send an RS and for a router
to wait to reply an RA.
Before a host sends an initial solicitation, it SHOULD delay the
transmission for a random amount of time between 0 and
MAX_RTR_SOLICITATION_DELAY (1 second). Also Router Advertisements
sent in response to a Router Solicitation MUST be delayed by a random
time between 0 and MAX_RA_DELAY_TIME (0.5 seconds).
Choi & Daley Expires March 11, 2005 [Page 6]
Internet-Draft DNA Goals September 2004
3. Goals for Detecting Network Attachment
DNA solutions should correctly determine whether a link change has
occurred. They also should be sufficiently fast lest there should be
service disruption. They should neither flood the link with related
signaling nor introduce new security holes.
It will be necessary to investigate the usage of available tools, NS/
NA messages, RS/RA messages, link-layer event notifications and other
features. This will allow precise description of procedures for
efficient DNA Schemes.
3.1 Goals list
G1 DNA schemes should detect the identity of the currently attached
link to ascertain the validity of the existing IP configuration.
They should recognize and determine whether a link change has
occurred and initiate the process of acquiring a new configuration
if necessary.
G2 When upper-layer protocol sessions are being supported, DNA
schemes should detect the identity of an attached link with
minimal latency lest there should be service disruption.
G3 In the case where a host has not changed a link, DNA schemes
should not falsely assume a link change and an IP configuration
change should not occur.
G4 DNA schemes should not cause undue signaling on a link.
G5 DNA schemes should make use of existing signaling mechanisms where
available.
G6 DNA schemes should make use of signaling within the link
(particularly link-local scope messages), since communication
off-link may not be achievable in the case of a link change.
G7 DNA schemes should be compatible with security schemes such as
Secure Neighbour Discovery [7].
G8 DNA schemes should not introduce new security vulnerabilities.
The node supporting DNA schemes should not expose itself or others
on a link to additional man in the middle or identity revealing or
denial of service attacks.
Choi & Daley Expires March 11, 2005 [Page 7]
Internet-Draft DNA Goals September 2004
G9 The nodes, such as routers or hosts, supporting DNA schemes should
work appropriately with unmodified nodes, such as routers or
hosts, which do not support DNA schemes.
G10 Hosts with multiple interfaces or in particular wireless
environments may perceive routers reachable on different links.
DNA schemes should take into consideration the case where a host
is attached to more than one link at the same time.
Choi & Daley Expires March 11, 2005 [Page 8]
Internet-Draft DNA Goals September 2004
4. IANA Considerations
No new message formats or services are defined in this document.
Choi & Daley Expires March 11, 2005 [Page 9]
Internet-Draft DNA Goals September 2004
5. Security Considerations
Because DNA schemes are based on Neighbor Discovery, its trust models
and threats are similar to the ones presented in [9]. Nodes
connected over wireless interfaces may be particularly susceptible to
jamming, monitoring and packet insertion attacks.
With unsecured DNA schemes, it is inadvisable for a host to adjust
its security based on which network it believes it is attached to.
For example, it would be inappropriate for a host to disable its
personal firewall based on the belief that it had connected to a home
network.
Even in the case where authoritative information (routing and prefix
state) are advertised, wireless network attackers may still prevent
soliciting nodes from receiving packets. This may cause unnecessary
IP configuration change in some devices. Such attacks may be used to
make a host preferentially select a particular configuration or
network access.
Devices receiving confirmations of reachability (for example from
upper-layer protocols) should be aware that unless these indications
are sufficiently authenticated, reachability may falsely be asserted
by an attacker. Similarly, such reachability tests, even if known to
originate from a trusted source should be ignored for reachability
confirmation if duplicates or stale. This may reduce the effective
window for attackers replaying otherwise authentic data.
It may be dangerous to receive link-change notifications from
link-layer and network-layer, if they are received from devices which
are insufficiently authenticated. In particular, notifications that
authentication has completed at the link-layer may not imply that a
security relationship is available at the network-layer. Additional
authentication may be required at the network layer to justify
modification of IP configuration.
Choi & Daley Expires March 11, 2005 [Page 10]
Internet-Draft DNA Goals September 2004
6. Acknowledgment
Erik Nordmark has contributed significantly to work predating this
draft. Also Ed Remmell's comments on the inconsistency of RA
information were most illuminating. The authors wish to express our
appreciation to Pekka Nikander for valuable feedback. We gratefully
acknowledge the generous assistance we received from Shubhranshu
Singh for clarifying the structure of the arguments. Thanks to Brett
Pentland, Nick Moore, Youn-Hee Han, JaeHoon Kim, Alper Yegin, Jim
Bound and Jari Arkko for their contributions to this draft.
Choi & Daley Expires March 11, 2005 [Page 11]
Internet-Draft DNA Goals September 2004
7. References
7.1 Normative References
[1] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
February 2004.
[2] Bradner, S., "Intellectual Property Rights in IETF Technology",
BCP 79, RFC 3668, February 2004.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", RFC 2461, December 1998.
[5] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[6] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document
Roadmap", RFC 2411, November 1998.
[7] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander,
"SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06
(work in progress), July 2004.
7.2 Informative References
[8] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[9] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[11] Nordmark, E., "MIPv6: from hindsight to foresight?",
draft-nordmark-mobileip-mipv6-hindsight-00 (work in progress),
November 2001.
[12] Pentland, B., "Router Advertisement Link Identification for
Mobile IPv6 Movement Detection",
draft-pentland-mobileip-linkid-02 (work in progress), July
2004.
Choi & Daley Expires March 11, 2005 [Page 12]
Internet-Draft DNA Goals September 2004
Authors' Addresses
JinHyeock Choi
Samsung AIT
Communication & N/W Lab
P.O.Box 111 Suwon 440-600
KOREA
Phone: +82 31 280 9233
EMail: jinchoe@samsung.com
Greg Daley
CTIE Monash University
Centre for Telecommunications and Information Engineering
Monash University
Clayton 3800 Victoria
Australia
Phone: +61 3 9905 4655
EMail: greg.daley@eng.monash.edu.au
Choi & Daley Expires March 11, 2005 [Page 13]
Internet-Draft DNA Goals September 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Choi & Daley Expires March 11, 2005 [Page 14]
