idnits 2.17.1 draft-baker-ipv6-nd-session-hijack-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 28, 2009) is 5376 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance F. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Informational July 28, 2009 5 Expires: January 29, 2010 7 Session Hijack in Neighbor Discovery 8 draft-baker-ipv6-nd-session-hijack-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 29, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This memo is to point out a security issue in IPv6 Neighbor 47 Discovery. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Session Hijack via Neighbor Discovery . . . . . . . . . . . . . 3 53 3. Possible mitigations . . . . . . . . . . . . . . . . . . . . . 4 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 55 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 56 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 57 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 59 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 1. Introduction 64 This memo, which augments [RFC3756], is to point out a security issue 65 in IPv6 [RFC2460], Neighbor Discovery [RFC4861] and Secure Neighbor 66 Discovery [RFC3971]. 68 2. Session Hijack via Neighbor Discovery 70 The attack is as follows. Imagine a LAN (wired or wireless, switched 71 or direct) like Figure 1 or Figure 2. 73 /---+--------+-------+---/ 74 | | | 75 +---+--+ +---+--+ +--+---+ 76 |Host 1| |Host 2| |Host 3| 77 +------+ +------+ +------+ 79 Figure 1: Sample local session 81 /---+--------+-------+---/ 82 | | | 83 +---+--+ +---+--+ +--+---+ 84 |Host 1| | RTR 1| |Host 3| 85 +------+ +---+--+ +------+ 86 | 87 / 88 | 89 +---+--+ 90 | RTR 2| 91 +---+--+ 92 | 93 /---+-----+---/ 94 | 95 +---+--+ 96 |Host 2| 97 +------+ 99 Figure 2: Sample remote session 101 Host 1 properly allocates an address by whatever means including 102 manual configuration, DHCPv6, SeND, or ND, and uses the address to 103 open a session with Host 2. The fact that it has allocated the 104 address is observed by Host 3, perhaps by receipt of a Neighbor 105 Solicitation during Duplicate Address Detection. 107 Host 1 now experiences a link-down event, losing the use of the 108 address. This might be because the switch rebooted, Host 1's 109 connectivity to the LAN was temporarily lost, or because Host 1 110 itself failed. 112 Host 3 now issues a Neighbor Solicitation for Host 1's address, and 113 because Host 1 has lost its memory of the address or is unavailable 114 at the time the request goes out. It has therefore correctly 115 allocated the address to itself. 117 In this case, it would appear that the session between Host 1 and 118 Host 2 is transferred, so that it is now between Host 2 and Host 3. 120 3. Possible mitigations 122 First one should note that in a cloud computing environment this may 123 be an intended behavior. If it is unintended, it constitutes an 124 attack. 126 There are a number of possible mitigations: 128 o Obviously, if the hosts have any form of session security 129 including IPsec AH, IPsec ESP, TLS, etc, the applications will be 130 prevented from communicating. Host 3 will still, however, be 131 aware that the sessions existed. 133 o Neighbor Discovery could be augmented to prevent movement of the 134 IPv6 address from one MAC Address to another without an 135 application-obvious hiccup. 137 o If a SAVI switch is in use, the SAVI behavior could similarly be 138 extended to prevent the movement of the address from Host 1 to 139 Host 3 without an application-obvious hiccup. 141 4. IANA Considerations 143 This memo asks the IANA for no new parameters. 145 Note to RFC Editor: This section will have served its purpose if it 146 correctly tells IANA that no new assignments or registries are 147 required, or if those assignments or registries are created during 148 the RFC publication process. From the author"s perspective, it may 149 therefore be removed upon publication as an RFC at the RFC Editor"s 150 discretion. 152 5. Security Considerations 154 This note augments [RFC3756], and constitutes a security 155 consideration. 157 6. Acknowledgements 159 The observation came out of a discussion regarding threats in a SAVI 160 environment, among the author, Jun Bi, Guang Yao, and Eric Levy- 161 Abegnoli. 163 7. References 165 7.1. Normative References 167 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 168 (IPv6) Specification", RFC 2460, December 1998. 170 7.2. Informative References 172 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 173 Discovery (ND) Trust Models and Threats", RFC 3756, 174 May 2004. 176 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 177 Neighbor Discovery (SEND)", RFC 3971, March 2005. 179 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 180 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 181 September 2007. 183 Author's Address 185 Fred Baker 186 Cisco Systems 187 Santa Barbara, California 93117 188 USA 190 Email: fred@cisco.com