Network Working Group R. Pashby Internet Draft Bowhead Support Document: draft-pashby-ipv6-detecting-spoofing-00.txt July 2005 Expires: January 2006 Detection of IPv6 Neighbor Discovery and Host Redirection Spoofing Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 January 2006. Abstract The purpose of this draft is to provide a method to detect exploitation of inherent vulnerabilities in the Neighbor Discovery processes. There are two well documented vulnerabilities in the basic IPv6 architecture: Neighbor Discover spoofing and Host Redirection. There already exists the SeND RFC [send] that addresses authenticating these interactions. Certain networks may choose not to uses (or cannot use) SeND, for instance, networks that use DHCP or statically assigned addresses. There is an underlying security principle that says, "If you can block a attack do it. If you cannot block it, detect it. Even if you can block it, detect it." This proposal outlines simple modifications to the basic protocols to allow for easily detecting these attacks. Through proactive systems, once an attack is detected it could easily provide blocking by isolating the attacking host via Access Control Lists (ACLs) or disabling ports. The basic method proposed is to force packets used in these attacks to be multicast to the attacked nodes Solicited Node Multicast group, thus allowing a security device to detect when it is occurring. Table of Contents: 1. Introduction 2. Applicability 3. Recommended Changes to Neighbor Discovery RFC [nd] 4. Security Considerations 5. Acknowledgments 6. References 7. Author's Information 1. Introduction The purpose of this draft is to provide a method to detect exploitation of inherent vulnerabilities in the Neighbor Discovery processes. There are two well documented vulnerabilities in the basic IPv6 architecture: Neighbor Discover spoofing and Host Redirection. There is the SeND RFC [send] that addresses authenticating these interactions. Certain networks may choose not to uses (or cannot use) SeND, for instance, networks that use DHCP or statically assigned addresses. There is an underlying security principle that says, "If you can block an attack do it. If you cannot block it, detect it. Even if you can block it, detect it." This proposal outlines simple modifications to the basic protocols to allow for easily detecting these attacks. Through proactive systems, once an attack is detected it could easily provide blocking by isolating the attacking host via ACLs or disabling ports. The basic method proposed is to force packets used in these attacks to be multicast to the attacked nodes Solicited Node Multicast group, thus allowing a security device to detect when it is occurring. There is a related [snoop] document that recommends that Solicited Node Multicast groups will be sent to all ports via MLD Snooping enabled switches. 2. Applicability This recommendation applies to all IPv6 Nodes and shall be implemented in all conforming IPv6 stacks. 3. Recommended Changes to Neighbor Discovery RFC [nd] 3.1 Require that Neighbor Advertisements must be sent to the recipient's Solicited-node Multicast Address (SNA). 3.2 Require that a node shall silently discard Neighbor Advertisements received that are not addressed to the node's SNA. This requirement may administratively be disabled to allow for interoperability with non-conforming node. The default configuration shall be to provide this requirement. 3.3 Require Host Redirection messages to be sent to the destination node's SNA. 3.4 Require that a node shall silently discard Host Redirection packets received that are not addressed to the node's SNA. This requirement may administratively be disabled to allow for interoperability with non-conforming node. The default configuration shall be to provide this requirement. 4. Security Considerations This recommendation provides for a way to detect the occurrences of well know vulnerabilities. It does not increase security vulnerabilities than those already existing in the base IPv6 specifications. 5. Acknowledgments Haberman, Brian, John Hopkins University O'Donoghue, Karen, Department of Navy 6. References [nd] Narten, T., Nordmark, E., Simpson, W., "Neighbor Discovery for IP Version 6 (IPv6)", RFC2461, December 1998 [send] Arkko, J., Kempf, J., Zill, B., Nikander, P., "SEcure Neighbor Discovery (SEND)", RFC3971, [snoop] Pashby, R., "Simplifying IPv6 MLD Snooping Switches", draft- pashby-magma-simplify-mld-snooping-00, July 2005 7. Author's Information Ronald Pashby Bowhead Support Services Ronald.Pashby.ctr@navy.mil (540) 653-6070 Copyright (C) The Internet Society (2005) 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. 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.