Internet DRAFT - draft-pashby-ipv6-detecting-spoofing
draft-pashby-ipv6-detecting-spoofing
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
<draft-pashby-ipv6-detecting-spoofing-00.txt>
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.
