Validation of Neighbor Discovery Source Link-Layer Address (SLLA) and Target Link-layer Address (TLLA) options
draft-gont-6man-lla-opt-validation-00
Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
---|---|---|---|
Authors | Fernando Gont , Ron Bonica , Will (Shucheng) LIU | ||
Last updated | 2014-08-18 (Latest revision 2014-02-14) | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Expired | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
This memo documents two scenarios in which an on-link attacker emits a crafted IPv6 Neighbor Discovery (ND) packet that poisons its victim's neighbor cache. In the first scenario, the attacker causes a victim to map a local IPv6 address to a local router's own link- layer address. In the second scenario, the attacker causes the victim to map a unicast IP address to a link layer broadcast address. In both scenarios, the attacker can exploit the poisoned neighbor cache to perform a subsequent forwording-loop attack, thus potentially causing a Denial of Service. Finally, this memo specifies simple validations that the recipient of an ND message can execute in order to protect itself against the above-mentioned threats.
Authors
Fernando Gont
Ron Bonica
Will (Shucheng) LIU
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)