Subject: Re: FW: New Version Notification for draft-gont-6man-lla-opt-validation-00.txt

From: Jen Linkova <[email-masked]>
Date: Tue, 4 Mar 2014 20:25:24 +0100

Hi Ron,
Few years ago I observed the situation when multicast MAC <-> unicast VIP
mapping (in ARP replies) was used by Microsoft server load balancing. Not
sure if it is still the case and if they are using the same trick for ipv6
but IMHO it worth investigating before prohibiting it.
On 14 Feb 2014 20:36, "Ronald Bonica" <[email-masked]> wrote:

> Folks,
>
> Please review and provide comments.
>
>                    Ron
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, February 14, 2014 9:54 AM
> To: Shucheng LIU (Will); Will Liu; Fernando Gont; Ronald Bonica; Fernando
> Gont; Ronald Bonica
> Subject: New Version Notification for
> draft-gont-6man-lla-opt-validation-00.txt
>
>
> A new version of I-D, draft-gont-6man-lla-opt-validation-00.txt
> has been successfully submitted by Fernando Gont and posted to the IETF
> repository.
>
> Name:           draft-gont-6man-lla-opt-validation
> Revision:       00
> Title:          Validation of Neighbor Discovery Source Link-Layer Address
> (SLLA) and Target Link-layer Address (TLLA) options
> Document date:  2014-02-14
> Group:          Individual Submission
> Pages:          10
> URL:
> http://www.ietf.org/internet-drafts/draft-gont-6man-lla-opt-validation-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-gont-6man-lla-opt-validation/
> Htmlized:
> http://tools.ietf.org/html/draft-gont-6man-lla-opt-validation-00
>
>
> 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.
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Jen Linkova <[email-masked]>
Date: Tue, 4 Mar 2014 23:43:16 +0100

oops, sorry, please disregard my previous mail. My memory fails me -
Microsoft NLB used *static* ARP entry for unicast IP - multicast MAC,
not ARP replies indeed (as it is prohibited by RFC1812.
Sorry, should have verified before sending an email ;)

-- 
SY, Jen Linkova aka Furry