DNA WG JinHyeock Choi Internet-Draft Samsung AIT Expires: June 17, 2005 Greg Daley CTIE Monash University December 17, 2004 Goals of Detecting Network Attachment in IPv6 draft-ietf-dna-goals-04.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 June 17, 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 June 17, 2005 [Page 1]
Internet-Draft DNA Goals December 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Goals for Detecting Network Attachment . . . . . . . . . . . . 8 3.1 Goals list . . . . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 7.2 Informative References . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 15 Choi & Daley Expires June 17, 2005 [Page 2]
Internet-Draft DNA Goals December 2004 1. Introduction When a host has established a new link-layer connection, it can send and receive some IPv6 packets on the link, including those used for configuration. On the other hand, the host has Internet connectivity only when it is able to exchange packets with off-link 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. It also doesn't know whether its existing default router is on this link nor if its neighbor cache entries are valid. Correct configuration of each of these components is 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 [1]. The notion 'link' is not identical with the notion 'subnet' as defined in RFC 3753 [2]. For example, there may be more than one subnet on a link and a host connected to a link may be part of one or more of the subnets on the link. 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, to examine the validity of an IP configuration, all that is required is that the host checks for link change. 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 ascertain the validity of its IP configuration, is called Detecting Network Attachment (DNA). Choi & Daley Expires June 17, 2005 [Page 3]
Internet-Draft DNA Goals December 2004 DNA schemes are typically run per interface. When a host has multiple interfaces, the host separately checks for link changes on each interface. It is important to note that DNA process does not include the actual IP configuration procedure. For example, with respect to DHCP, the 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. This draft considers the DNA procedure only from the IPv6 point of view, unless otherwise explicitly mentioned. Hence, the term "IP" is to be understood to denote IPv6, by default. For the IPv4 case, refer to [7]. Choi & Daley Expires June 17, 2005 [Page 4]
Internet-Draft DNA Goals December 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 connectivity. Second, it's difficult for a single Router Advertisement message to indicate a link change. Third, the current Router Discovery specification specifies that routers wait a random delay of 0-.5 seconds prior to responding with a solicited RA. This delay can be significant and may result in service disruption. 2.1 Wireless link properties Unlike wired environments, what constitutes a wireless link is variable both in time and space. Wireless links do not have clear boundaries. This may be illustrated by the fact that a host may be within the coverage area of 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 long enough at a given link, it can't complete the 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 [1], 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 locally stored information. The host may use received router addresses 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 [1] 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 Choi & Daley Expires June 17, 2005 [Page 5]
Internet-Draft DNA Goals December 2004 link change has occurred. 2.3 Delays The following issues cause DNA delay that may result in communication 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 [6], 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 such a hint almost instantly. Mobile IPv6 [4] defines the use of RA Interval Timer expiry for a hint. A host keeps monitoring for periodic RAs and interprets the lack of them as a hint. It may implement its own policy to determine the number of missing RAs needed to interpret that as a hint. Hence, the delay depends on the Router Advertisement interval. Without schemes such as the ones 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, hosts are expected to arrive, on average, half way through the interval. This is approximately 1.75 seconds with Neighbor Discovery [1] advertisement rates. 2) Random delay execution for RS/ RA exchange Router Solicitation and Router Advertisement messages are used for Router Discovery. According to [1], it is sometimes necessary for a host to wait a random amount of time before it may send an RS, and for a router to wait before it may reply with an RA. Choi & Daley Expires June 17, 2005 [Page 6]
Internet-Draft DNA Goals December 2004 According to RFC 2461 [1]: - 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). - Furthermore, any Router Advertisement 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 June 17, 2005 [Page 7]
Internet-Draft DNA Goals December 2004 3. Goals for Detecting Network Attachment The DNA working group has been chartered to define an improved scheme for detecting IPv6 network attachment. In this section, we define the goals that any such solution should aim to fulfil. DNA solutions should correctly determine whether a link change has occurred. Additionally, they should be sufficiently fast so that there would be no or at most minimal service disruption. They should neither flood the link with related signaling nor introduce new security holes. When defining new solutions, it is necessary to investigate the usage of available tools, Neighbor Solicitation/Neighbor Advertisement messages, RS/RA messages, link-layer event notifications [6], 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 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 [3]. Choi & Daley Expires June 17, 2005 [Page 8]
Internet-Draft DNA Goals December 2004 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, identity revealing, or denial of service attacks. 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, especially in 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 June 17, 2005 [Page 9]
Internet-Draft DNA Goals December 2004 4. IANA Considerations No new message formats or services are defined in this document. Choi & Daley Expires June 17, 2005 [Page 10]
Internet-Draft DNA Goals December 2004 5. Security Considerations DNA process is intimately related to Neighbor Discovery protocol [1] and its trust model and threats have much in common with the ones presented in RFC 3756 [5]. 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 the packets are not fresh, or have been replayed. 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 June 17, 2005 [Page 11]
Internet-Draft DNA Goals December 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 June 17, 2005 [Page 12]
Internet-Draft DNA Goals December 2004 7. References 7.1 Normative References [1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [2] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [3] 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 [4] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [5] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [6] Yegin, A., "Link-layer Event Notifications for Detecting Network Attachments", draft-ietf-dna-link-information-00 (work in progress), September 2004. [7] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", draft-ietf-dhc-dna-ipv4-09 (work in progress), October 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 Choi & Daley Expires June 17, 2005 [Page 13]
Internet-Draft DNA Goals December 2004 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 June 17, 2005 [Page 14]
Internet-Draft DNA Goals December 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 June 17, 2005 [Page 15]