IPv6 Neighbor Discovery (ND) Trust Models and Threats
RFC 3756
Document | Type |
RFC - Informational
(May 2004; No errata)
Was draft-ietf-send-psreq (send WG)
|
|
---|---|---|---|
Authors | James Kempf , Pekka Nikander , Erik Nordmark | ||
Last updated | 2020-07-29 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3756 (Informational) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Margaret Cullen | ||
Send notices to | (None) |
Network Working Group P. Nikander, Ed. Request for Comments: 3756 Ericsson Research Nomadic Lab Category: Informational J. Kempf DoCoMo USA Labs E. Nordmark Sun Microsystems Laboratories May 2004 IPv6 Neighbor Discovery (ND) Trust Models and Threats Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and Address Autoconfiguration mechanisms may be protected with IPsec Authentication Header (AH). However, the current specifications limit the security solutions to manual keying due to practical problems faced with automatic key management. This document specifies three different trust models and discusses the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements for Securing IPv6 Neighbor Discovery. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Remarks . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Previous Work. . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Trust Models . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Corporate Intranet Model. . . . . . . . . . . . . . . . . 5 3.2. Public Wireless Network with an Operator. . . . . . . . . 6 3.3. Ad Hoc Network. . . . . . . . . . . . . . . . . . . . . . 7 4. Threats on a (Public) Multi-Access Link. . . . . . . . . . . . 8 4.1. Non router/routing related threats. . . . . . . . . . . . 9 4.1.1. Neighbor Solicitation/Advertisement Spoofing . . . 9 4.1.2. Neighbor Unreachability Detection (NUD) failure. . 10 4.1.3. Duplicate Address Detection DoS Attack . . . . . . 11 4.2. Router/routing involving threats. . . . . . . . . . . . . 12 4.2.1. Malicious Last Hop Router. . . . . . . . . . . . . 12 Nikander, et al. Informational [Page 1] RFC 3756 IPv6 ND Trust Models and Threats May 2004 4.2.2. Default router is 'killed' . . . . . . . . . . . . 13 4.2.3. Good Router Goes Bad . . . . . . . . . . . . . . . 14 4.2.4. Spoofed Redirect Message . . . . . . . . . . . . . 14 4.2.5. Bogus On-Link Prefix . . . . . . . . . . . . . . . 14 4.2.6. Bogus Address Configuration Prefix . . . . . . . . 15 4.2.7. Parameter Spoofing . . . . . . . . . . . . . . . . 16 4.3. Replay attacks and remotely exploitable attacks . . . . . 17 4.3.1. Replay attacks . . . . . . . . . . . . . . . . . . 17 4.3.2. Neighbor Discovery DoS Attack. . . . . . . . . . . 18 4.4. Summary of the attacks. . . . . . . . . . . . . . . . . . 19 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 20 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 7. Informative References . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction The IPv6 Neighbor Discovery (ND) RFC 2461 [2] and Address Autoconfiguration RFC 2462 [3] mechanisms are used by nodes in an IPv6 network to learn the local topology, including the IP to MAC address mappings for the local nodes, the IP and MAC addresses of the routers present in the local network, and the routing prefixes served by the local routers. The current specifications suggest that IPsec AH RFC 2402 [1] may be used to secure the mechanisms, but does not specify how. It appears that using current AH mechanisms is problematic due to key management problems [8]. To solve the problem, the Secure Neighbor Discovery (SEND) working group was chartered in Fall 2002. The goal of the working group is to define protocol support for securing IPv6 Neighbor Discovery without requiring excessive manual keying. The purpose of this document is to define the types of networks in which the Secure IPv6 Neighbor Discovery mechanisms are expected to work, and the threats that the security protocol(s) must address. To fulfill this purpose, this document first defines three different trust models, roughly corresponding to secured corporate intranets, public wireless access networks, and pure ad hoc networks. AfterShow full document text