[v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns

[Vasilenko Eduard <[e-mail]>]

Hi Jen,
You did ask a feedback yesterday about severity of 7sec security hole that has very low probability.
I have intention here to show that probability is 100%, 7sec could be prolonged to forever, and the final result is the full interception of innocent host traffic by intruder (successful "man-in-the-middle").

Pre-request for success:
- no multicast snooping (MLD) and filtering on a switch, that is perfectly possible
- Intruder should be already on the same subnet (gained control over other host by exploiting of different vulnerability)
- intruder should suppress DAD on Intruder's controlled host (is Windows firewall capable to filter out DAD?)
- We assume that we are talking about the future when this draft is used by majority of nodes (victim should use it)

Procedure: 
Intruder's controlled host does listen to all-routers multicast address (ff02::2).
As soon as it would eavesdrop unsolicited NA from victim node (probably after boot) - Intruder would immediately (a few milliseconds) duplicate NA in router's direction, but with 2 changes: (1) his LLA (MAC); (2) Override bit set.
Intruder has time only up to the point that response to victim's traffic would be returned from the Internet (from tens of milliseconds to many seconds if victim would not start sending immediately), - but it is enough time: local communication should be faster.
Theoretically, RetransTimer should be imposed on unsolicited NA (section 7.2.6), but low chances that this timer is checked on receiving side (router), because RetransTimer is specified for transmission side.
According RFC 4681 section 7.2.5 clause II: O bit set should not just rewrite ND cache, but additionally mark ND record as REACHABLE. According to section 7.2.6: " The Override flag (for unsolicited NA) MAY be set to either zero or one". Despite it contradicts to the logic of the whole RFC 4681 (O bit should not be set in unsolicited NA - it is mentioned in a few places of RFC 4681). But because section 7.2.5 and section 7.2.6 clearly permit to use Override flag - higher probability that particular implementation would not just rewrite LLA on router, but additionally put it into REACHABLE.
Intruder could be sure that at least STALE state would be created according to section 7.2.5 clause I, - this ND record would be against his LLA anyway.
After receiving return traffic (if it was created as STALE, not REACHABLE) - router would ask intruder about reachability (solicited NS-NA) - intruder would confirm his LLA - it would finally put ND cache record into REACHABLE.
That's it: upstream traffic of victim host is going to router, traffic back is going through Intruder.
I have consulted with penetration tests professional (these are people with the same qualification as hackers but they play on legal side): what he would be doing next? He said that he would return traffic to legitimate host - victim should not see performance degradation. He would collect cookies and some other valuable information. He would finally see DNS response, change it and redirect everything to himself on the permanent basis - he does want to see both directions of victim exchange. He has qualified Man-in-the-middle as full fiasco - it does open many opportunities for him. He has mentioned very good feature of this draft that there is no any interruption for victim's traffic flow, no any excessive traffic to victim, that is very rear benefit for hacker's tool.

What to do about it?
1. Potentially it is possible to do RPF-like check for Source LLA addresses. Upstream traffic from victim's SLLA would not be in ND cache - such traffic could be discarded. It is better to block communication than permit intruder to exploit vulnerability.
2. Increase RetransTimer and ask receiver side (router) to check on sending side delay between ND record override (for the same SLLA). But how long should be the timer? Host could wait a lo-o-o-ng time before it would request 1st information from internet. It would decrease probability, but would not completely eliminate attack vector.

My proposition for this draft is disruptive:
I believe that ND is very complicated (some could say "fragile") - it is better not to touch it.
Additionally I do not like to wait till all hosts would refresh to new draft (to get new functionality).
I propose to change only router behavior: check Source LLA (MAC) for every packet, if this SLLA is absent in ND cache - then request solicited NS-NA immediately. It would probably resolve faster than traffic would return from the internet.
Effectively I do proposed the same SLLA RPF that is needed to fix current solution, but:
- without any modification to host OSes
- without any modification of standard (it is local recommendation for router, NS-NA is exactly the same from RFC 4681, NA is unicast - it is important for security)
- without any risk to break ND fragile algorithm
- it could be optional, or even configurable on the router as "value add feature" in competitive tender
Because it is just best practice recommendation - may be it make sense to move it to "v6ops"?

PS: Looking to the above - unsolicited NA should be really delayed by additional big timer (not by RetransTimer that is used for solicited NS/NA) and checked on receiver side - this modification of standard is really needed to close Unsolicited NA vulnerability.
Somebody said on the call that it is already a feature of some OS (Android?) - it is bad: it means that this OS is already vulnerable.
It is just important to understand: do they practice it on tethering? I do not see the reason to practice it on 3GPP link.

Eduard
-----Original Message-----
From: ipv6 [mailto:[e-mail]] On Behalf Of Jen Linkova
Sent: 27 июля 2020 г. 7:49
To: 6man <[e-mail]>
Subject: Re: I-D Action: draft-ietf-6man-grand-01.txt

Hello,

The -01 version addresses comments received (thanks everyone who provided feedback). Also, Section 3 (Avoiding Disruption) has been expanded and discussed a corner case when two devices start using the same address almost at the same time (the second device configures an optimistic address after the rightful owner sent some packets but before the return traffic arrives).
Feedback on the updated section 3.3
(https://tools.ietf.org/html/draft-ietf-6man-grand-01#section-3.3) is very much appreciated.

On Sun, Jul 26, 2020 at 10:14 AM <[e-mail]> wrote:
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the IPv6 Maintenance WG of the IETF.
>
>         Title           : Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on First-Hop Routers
>         Author          : Jen Linkova
>         Filename        : draft-ietf-6man-grand-01.txt
>         Pages           : 12
>         Date            : 2020-07-25
>
> Abstract:
>    Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the
>    link-layer addresses of neighboring nodes as well as to discover and
>    maintain reachability information.  This document updates RFC4861 to
>    allow routers to proactively create a Neighbor Cache entry when a new
>    IPv6 address is assigned to a node.  It also updates RFC4861 and
>    recommends nodes to send unsolicited Neighbor Advertisements upon
>    assigning a new IPv6 address.  The proposed change will minimize the
>    delay and packet loss when a node initiate connections to off-link
>    destination from a new IPv6 address.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6man-grand/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6man-grand-01
> https://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-01
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-grand-01
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------



--
SY, Jen Linkova aka Furry

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------