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

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Aug 2020 19:57:16 -0400

Templin (US), Fred L <[email-masked]> wrote:
    > I wish this group could open its eyes. ND as defined in the last
    > century is not suited for modern fabrics, virtual machines and
    > wireless. It is a pain for silicon-based forwarding. Time to upgrade is
    > overdue.

You are right!

We either need SEND (RFC3971), or some technology that addresses the same use case (RFC3756).
We need a for nodes to reserve resources on the router.

Many of us would prefer that we avoid making it stateful, but in wifi
networks, are already allocate crypto state, and we should just leverage
that. (ND is just wasted effort on encrypted wifi in my opinion)

    > There is nothing broken with IPv6 ND that needs changing; it just needs a new option.
    > We have seen how that is possible through publications like RFC8801.

Also RFC8505.
I think, it's really really time to stop pretending everything is big-blue coaxial ethernet.

    > BTW, IPv6 itself is a last-century technology but the architects had the wisdom to allow
    > for future extensions without needing to modify the core architecture.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Aug 2020 20:04:18 -0400

Tony Finch <[email-masked]> wrote:
    > Owen DeLong <[email-masked]> wrote:
    >>
    >> Indeed, as an operator, IMHO, if there’s a place we need to focus on
    >> improving L2 attack surface in v6, it’s in finding better ways for
    >> {routers, hosts, switches} to mitigate/absorb this type of resource
    >> exhaustion attack. Unfortunately, this is a hard problem to solve, so we
    >> focus on moving the deck chairs we can move while ignoring the
    >> elephant-sized hole in the bulkheads that we don’t know how to patch.

    > If GRAND is deployed, would that allow routers to assume their neighbour
    > tables are complete, so they can just drop ND exhaustion attacks?

As said elsewhere in the thread, in general no.

Could a router develop heuristic in this direction that would help it protect
traffic during ND exhaustion attacks?  I think so.

Perhaps a signal from host to router in the ND that it does grand would be in order.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Aug 2020 20:08:21 -0400

SEND is/was too expensive to deploy because 15 years ago, hosts did not have
identities that other hosts or routers could easily validate.
We did not come up with a reasonable TOFU mechanism either.

I believe that there are probably now environments (such as yours Fred) where
the cost/benefit of deploying those identities now has become positive.
This because the cost of deploying identities is much lower than it used to
be (both the administrative cost of doing it, as well as the CPU/network cost
of doing the signing), while the benefit of mitigating the risks is higher.

But, this has gone beyond GRAND.
GRAND is useful without SEND, but would be enhanced by SEND.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 03 Aug 2020 20:38:46 -0400

Ted Lemon <[email-masked]> wrote:
    > On Jul 31, 2020, at 1:17 PM, Templin (US), Fred L <[email-masked]> wrote:
    >> Ted, I think SEND would solve the neighbor cache resource exhaustion attack since a NCE is
    >> only created on receipt of an authentic (SEND-protected) IPv6 ND message.

    > OK, but an attacker can just generate a bazillion key pairs, right? So
    > it can still exhaust the cache, at the cost of some computation work.

If you do a TUFO trust model, yes.
If you do something else, because you are in a different environment than a
IETF meeting network^W^W^Wcoffee shop, then the potential win is quite large.

Even if you do a TOFU trust model, keys which were first used prior to the
attack, could continue to be be used, protecting the cache.

This pushes the exhaustion attack from one part of the control plane (where
ND messages are processed), to another part of the control plane (where keys
are trusted on first use).
Is that a good thing?  Maybe.

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 4 Aug 2020 09:07:49 +0000

Hi Michael,
It is strange that most dangerous attack (unsolicited NA - leading to leakage of information) was not mentioned in RFC 3756.

>We need a for nodes to reserve resources on the router.
Then router would be stateful (in respect of ND) - it is a very big architecture change. The industry has the big inertia - I do not believe that it is possible to return IPv6 address management to stateful model (except government intrusion - see below).
By the way, stateful DHCPv6 exist. Switch could easily snoop all messages and assist to IPv6 in security (like it is done for IPv4).
I propose do not push SLAAC in stateful direction - anyone who would like - could use DHCPv6 or 6lo (stateful on router too).
I propose to think how to save SLAAC - keeping it with distributed address management.

> Many of us would prefer that we avoid making it stateful, but in wifi networks, are already allocate crypto state, and we should just leverage that.
Our days big campuses are deployed without CAT5/6 cabling - everything is WiFi.
SLAAC for WiFi looks like not the best technology. State repository (AP) is mandatory anyway. But anyone could use 6lo - it is developed specifically for such environment (not effective multicast, frame loss).
IMHO: It does not make sense to reinvent the wheel. RFC 6775 and 8505 do have good stateful solution for WiFi.
SLAAC has been left with the small niche for the future - if it would have fixes for biggest security problems (personal data protection).

Looking to all these "data privacy protection legislation" world-wide (in many countries): SLAAC could be banned by some government at any movement.
Experts would easily point to alternative: (1) stateful DHCPv6 (natural IPv4 prolong); (2) 6lo (it is optimized for wireless).
Probably DHCPv6 would win, because it is easy to understand for IT&IP professionals.
If any government would push - switchover to DHCPv6 would be fast.
Then fixing SLAAC would be too late. It would be the time for deprecation RFC.

Eduard
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: 4 августа 2020 г. 2:57
To: Templin (US), Fred L <[email-masked]>
Cc: Pascal Thubert (pthubert) <pthubert=[email-masked]>; v6ops list <[email-masked]>; 6man <[email-masked]>
Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns

You are right!

Many of us would prefer that we avoid making it stateful, but in wifi networks, are already allocate crypto state, and we should just leverage that. (ND is just wasted effort on encrypted wifi in my opinion)

Also RFC8505.

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 4 Aug 2020 10:01:00 +0000

Hello Eduard

You need to qualify what you mean by dangerous. In my book an attack that is easy to trigger remotely and anonymously is more "dangerous" than the same attack if it has to be done from within the local network. Reactive (cache and lookup) ND enables a remote DoS attack on the ND cache by scanning 2^64 addresses with pings. Proactive (Stateful) ND avoids that attack but can be more sensitive to local attacks.

SLAAC has 2 main properties, the Distributed Address Allocation and the Reactive ND Binding Cache management. Those properties are orthogonal: DHCPv6 today uses the latter but not the former. RFC 8505 allows former but does not use the latter. => I guess that by SLAAC you mean that you 'prefer' the Reactive Binding Cache management and are not talking about the Address Allocation piece since that piece is not at stake here. "Preference" is another thing that you'll have to specify (vs. operational requirements).

The current situation is (to my best knowledge):
1) DHCPv6 allocation is not available in some stacks (Android). 
2) SLAAC is globally available in hosts and routers but it happens to be barred by some enterprise policies
3) In many modern environments the switches and routers need to maintain the full tables of the attached nodes (e.g., fabrics like eVPN, proxy ND for Wi-Fi APs). Today they do it by snooping the protocols so we get the worst of both worlds.
4) RFC 8505 is not limited to IoT devices. It is very generic. It allows to build a network where the remote ND cache DOS becomes inefficient.
5) It is possible to build a network that uses both stateful and stateless, see https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/. This looks a lot like what you seems to be asking, Proactive at the WiFi edge and Stateless on the wire. If you mix, the remote DOS is still possible, but there are more ways to alleviate it.

All the best

Pascal

> From: Vasilenko Eduard <[email-masked]>
> Sent: mardi 4 août 2020 11:08
> To: Michael Richardson <[email-masked]>; Templin (US), Fred L
> <[email-masked]>
> Cc: Pascal Thubert (pthubert) <[email-masked]>; v6ops list
> <[email-masked]>; 6man <[email-masked]>
> Subject: RE: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security
> concerns
> 
> Hi Michael,
> It is strange that most dangerous attack (unsolicited NA - leading to leakage of
> information) was not mentioned in RFC 3756.
> 
> Then router would be stateful (in respect of ND) - it is a very big architecture
> change. The industry has the big inertia - I do not believe that it is possible to
> return IPv6 address management to stateful model (except government
> intrusion - see below).
> By the way, stateful DHCPv6 exist. Switch could easily snoop all messages and
> assist to IPv6 in security (like it is done for IPv4).
> I propose do not push SLAAC in stateful direction - anyone who would like -
> could use DHCPv6 or 6lo (stateful on router too).
> networks, are already allocate crypto state, and we should just leverage that.
> SLAAC for WiFi looks like not the best technology. State repository (AP) is
> mandatory anyway. But anyone could use 6lo - it is developed specifically for
> such environment (not effective multicast, frame loss).
> SLAAC has been left with the small niche for the future - if it would have fixes
> for biggest security problems (personal data protection).
> 
> Looking to all these "data privacy protection legislation" world-wide (in many
> countries): SLAAC could be banned by some government at any movement.
> Experts would easily point to alternative: (1) stateful DHCPv6 (natural IPv4
> prolong); (2) 6lo (it is optimized for wireless).
> Cc: Pascal Thubert (pthubert) <pthubert=[email-masked]>; v6ops
> list <[email-masked]>; 6man <[email-masked]>
> Many of us would prefer that we avoid making it stateful, but in wifi networks,
> are already allocate crypto state, and we should just leverage that. (ND is just
> wasted effort on encrypted wifi in my opinion)
> 
>     > for future extensions without needing to modify the core architecture..
> 
> --

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 4 Aug 2020 16:06:02 +0000

Hi Pascal,
My priority here is coincide with many governments priorities: leakage of information is strictly mandatory to prevent (privacy protection).
DoS is the second priority. You are right that remote DoS is more dangerous, because for local DoS intruder should initially break-through into subnet (exploit other vulnerability to gain root access on 1 host).

I agree that Full ND cache on router is the good basement for protection against Remote DoS.

Thanks for good example of classification! "Centralized/Distributed Address Allocation", "Reactive/Proactive cache management".
Could I add to classification "Ownership protection for Interface ID"? Because I could not imagine how to protect against DoS attack from inside subnet without proper trust anchor. The last would probably not happen for many years to come.

Yes, I have made comment below that if Address Allocation would be changed to Centralized, then it is probably not SLAAC anymore. Then it is better to adopt DHCPv6.

But why you said that DHCPv6 is only about "Proactive cache management"? DHCP has attribute of "Centralized Address Allocation" too.

I have read your https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router 
Proxy is not universal solution and should not be mainstream. It is complicated: IP subnet is split for many broadcast domains, proxy stitch it back.

Eduard
-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: 4 августа 2020 г. 13:01
To: Vasilenko Eduard <[email-masked]>; Michael Richardson <[email-masked]>; Templin (US), Fred L <[email-masked]>
Cc: v6ops list <[email-masked]>; 6man <[email-masked]>
Subject: RE: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional security concerns

Hello Eduard

All the best

Pascal

> Subject: RE: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional 
> security concerns
> 
> Hi Michael,
> Then router would be stateful (in respect of ND) - it is a very big 
> architecture change. The industry has the big inertia - I do not 
> believe that it is possible to return IPv6 address management to 
> stateful model (except government intrusion - see below).
> By the way, stateful DHCPv6 exist. Switch could easily snoop all 
> messages and assist to IPv6 in security (like it is done for IPv4).
> I propose do not push SLAAC in stateful direction - anyone who would 
> like - could use DHCPv6 or 6lo (stateful on router too).
> SLAAC for WiFi looks like not the best technology. State repository 
> (AP) is mandatory anyway. But anyone could use 6lo - it is developed 
> specifically for such environment (not effective multicast, frame loss).
> SLAAC has been left with the small niche for the future - if it would 
> have fixes for biggest security problems (personal data protection).
> 
> Experts would easily point to alternative: (1) stateful DHCPv6 
> (natural IPv4 prolong); (2) 6lo (it is optimized for wireless).
> Cc: Pascal Thubert (pthubert) <pthubert=[email-masked]>; 
> v6ops list <[email-masked]>; 6man <[email-masked]>
> networks, are already allocate crypto state, and we should just 
> leverage that. (ND is just wasted effort on encrypted wifi in my 
> opinion)
> 
> - = IPv6 IoT consulting =-
> 
>

---

From: Mark Smith <[email-masked]>
Date: Wed, 5 Aug 2020 03:18:39 +1000

On Wed, 5 Aug 2020, 02:06 Vasilenko Eduard, <[email-masked]>
wrote:

> Hi Pascal,
> My priority here is coincide with many governments priorities: leakage of
> information is strictly mandatory to prevent (privacy protection).
>

So when you've modified SLAAC and somehow deployed it to not use
multicasts, are you going to move on to DHCPv6? Then Multicast DNS? OSPF?
Spanning Tree? RIPv2?

Modifying existing and widely deployed protocols not to use multicasts is a
far harder way of solving the problem of unauthorised nodes receiving those
multicasts.

Using also existing and widely deployed layer 2 security or isolation
methods to limit the reach of multicasts to only authorised nodes is the
easiest and quickest solution.

Regards,
Mark.

DoS is the second priority. You are right that remote DoS is more
> dangerous, because for local DoS intruder should initially break-through
> into subnet (exploit other vulnerability to gain root access on 1 host).
>
> Thanks for good example of classification! "Centralized/Distributed
> Address Allocation", "Reactive/Proactive cache management".
> Could I add to classification "Ownership protection for Interface ID"?
> Because I could not imagine how to protect against DoS attack from inside
> subnet without proper trust anchor. The last would probably not happen for
> many years to come.
>
> Yes, I have made comment below that if Address Allocation would be changed
> to Centralized, then it is probably not SLAAC anymore. Then it is better to
> adopt DHCPv6.
>
> But why you said that DHCPv6 is only about "Proactive cache management"?
> DHCP has attribute of "Centralized Address Allocation" too.
>
> I have read your
> https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router
> Proxy is not universal solution and should not be mainstream. It is
> complicated: IP subnet is split for many broadcast domains, proxy stitch it
> back.
>
> Eduard
> To: Vasilenko Eduard <[email-masked]>; Michael Richardson <
> [email-masked]>; Templin (US), Fred L <[email-masked]>
> You need to qualify what you mean by dangerous. In my book an attack that
> is easy to trigger remotely and anonymously is more "dangerous" than the
> same attack if it has to be done from within the local network. Reactive
> (cache and lookup) ND enables a remote DoS attack on the ND cache by
> scanning 2^64 addresses with pings. Proactive (Stateful) ND avoids that
> attack but can be more sensitive to local attacks.
>
> SLAAC has 2 main properties, the Distributed Address Allocation and the
> Reactive ND Binding Cache management. Those properties are orthogonal:
> DHCPv6 today uses the latter but not the former. RFC 8505 allows former but
> does not use the latter. => I guess that by SLAAC you mean that you
> 'prefer' the Reactive Binding Cache management and are not talking about
> the Address Allocation piece since that piece is not at stake here.
> "Preference" is another thing that you'll have to specify (vs. operational
> requirements).
>
> 3) In many modern environments the switches and routers need to maintain
> the full tables of the attached nodes (e.g., fabrics like eVPN, proxy ND
> for Wi-Fi APs). Today they do it by snooping the protocols so we get the
> worst of both worlds.
> 4) RFC 8505 is not limited to IoT devices. It is very generic. It allows
> to build a network where the remote ND cache DOS becomes inefficient.
> 5) It is possible to build a network that uses both stateful and
> stateless, see
> https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/. This
> looks a lot like what you seems to be asking, Proactive at the WiFi edge
> and Stateless on the wire. If you mix, the remote DOS is still possible,
> but there are more ways to alleviate it.
>
> All the best
>
> Pascal
>
> that.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 4 Aug 2020 18:02:34 +0000

Hi, about SEND I was just doing a maintenance update of the AERO draft and noticed
that the subject is already covered there in full detail in Section 3.22:

https://datatracker.ietf.org/doc/draft-templin-intarea-6706bis/

So, for those who have participated in this discussion, please refer to the AERO spec
and realize that the only thing missing in OMNI is an appropriate reference citation
to AERO. However, a point that could be considered by the OMNI design team is
whether the SEND text in AERO should instead be moved into the OMNI draft.

Please review and comment,

Fred

> Sent: Monday, August 03, 2020 5:39 PM
> To: Ted Lemon <[email-masked]>; v6ops list <[email-masked]>; 6man <[email-masked]>
> Subject: Re: [EXTERNAL] Improving ND security
> 
>

---

From: Jen Linkova <[email-masked]>
Date: Fri, 7 Aug 2020 12:04:13 +1000

HI Pascal,

Sorry for not responding, vacation..

It looks to me that what you are suggesting can be achieved by setting
L bit to zero in PIOs. In that case hosts would send all traffic to
routers and upon receiving a redirect would learn that the given
destination is actually on-link.
Or am I missing anything?

On Sat, Aug 1, 2020 at 2:21 AM Pascal Thubert (pthubert)
<pthubert=[email-masked]> wrote:
>
> Hello Jen
>
> Since the router is prepopulated, it knows the ND resolution before hosts do.
>
> So say a third party host has traffic to send and the prefix is online. It will store one packet and multicast a lookup to the snma of this node. It will drop the other packets.
>
> An alternate behavior in a network where GRAND is enabled could be to start by forwarding the packets to the router in case of aN ND cache miss.
>
> If the router already has an NCE there will not be a lookup at all. The router will redirect immediately and relay the packets in the meantime. No delay, no loss. And no multicast...
>
> If the router does not have a cache, it will do the NS lookup. And eventually redirect anyway if the traffic continues. Same overall cost, with the benefit that the router now has the cache ready in case yet another host needs it.
>
> Overall benefits day 1, incrementally useful as GRAND gets deployed.
>
> Cherry on the cake: the router may be more SAVI-savvy than this host so it may redirect to the real first-come node.
>
> What do you think?
>
> Pascal
>
> Le 30 juil. 2020 à 12:37, Lorenzo Colitti <lorenzo=[email-masked]> a écrit :
>
> 
> I think the fact is that ND is inherently insecure from on-link attacks. If security is desired, then it needs to be provided in other ways, such as via SEND or SAVI. But it's also not particularly desirable to provide security at this layer. Traffic snooping is not very useful (not zero utility, but difficult to use well) when all traffic is encrypted, and on-link DoS attacks just aren't very useful these days given that many devices have a variety of connectivity options.
>
> On Thu, Jul 30, 2020 at 5:05 PM Vasilenko Eduard <[email-masked]> wrote:
>>
>> Then it is not logical for me:
>> Many people understand that "Unsolicited NA" is a big security hole per se,
>> But instead of fixing it (may be even deprecate - should be investigated)
>> Additional functionality is building on top of it.
>> It would additionally challenge this security problem resolution in the future!
>>
>> Again: "Unsolicited NA" with Override bit set - is a disaster now..
>> IMHO: it is better to prohibit "Unsolicited NA". Let's wait timers for the case of MAC address change on legitimate host.
>> May be we could think about other solutions.
>> But if additional functionality would be built on top of "Unsolicited NA" - less options would be available ("deprecate" would be not a choice anymore).
>>
>> If something is ill - it should be cured first - bodybuilding make sense only after this.
>>
>> Jen, I have not understood below why you did mention RA Guard. Intruder does not need it. He just claim (by Unsolicited NA) that his MAC is connected to GUA of victim.
>> Intruder could claim it every 5 seconds to keep cache in STALE state (for the case of very careful vendor implementation of ND).
>> As you mentioned - no help from MLD snooping on switches - it would be enough to just listen to DAD. Switch could not help in principle.
>> The first modified DNS response would convert traffic flow to bi-directional for Intruder.
>>
>> Ed/
>> From: Jen Linkova [mailto:[email-masked]]
>> Sent: 30 июля 2020 г. 5:07
>> To: Vasilenko Eduard <[email-masked]>
>> Cc: 6man <[email-masked]>; [email-masked]
>> Subject: Re: I-D Action: draft-ietf-6man-grand-01 - additional security concerns
>>
>> On Thu, Jul 30, 2020 at 5:56 AM Vasilenko Eduard <[email-masked]> wrote:
>> > 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.
>>
>> 1) the 7 seconds corner case was for 'preventing address collision for Optimistic DAD', not for any intentional attacks case. Because:
>> 2) What you are describing could be done today, now, anytime w/o the changes described in the draft. If there is no MLD snooping then the intruder would see the DAD packet from the victim, so it would know the victim address anyway  - no reason even to join ff02::2. Now all the attacker needs to do is to keep sending NA with S=1, O=1 - hoping that when the first packet of the return flows arrive and the router creates an INCOMPLETE entry and sends an NS, the attacker's packet would come before the victim's NA. Done, the  entry is changed to REACHABLE, all traffic goes to the attacker.
>> Actually even simpler. The attacker does not need to deal with timing.
>> Let's say the router has an NC entry for the victim address in any other state than INCOMPLETE. The attacker sends an NA with S=1, O=1, Target address = the victim's IPv6 address, the TLLA = the attacker MAC address.  Done. The router updates the cache entry and changes it to REACHABLE state.
>>
>> There is nothing new here. We have the same issue with ARP - the attacker can override ARP entry on the router.
>>
>> > 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.
>>
>> For all that doom and gloom the attacker would also need to see the traffic *from* the victim. Assuming the network has RA Guard in place it would be a bit harder. If the network does not have RA Guard our poor victim has much bigger problems already.
>>
>> > 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).
>>
>> Well, only hosts which want to connect to the network faster need to implement this. So host OS developers have pretty good incentive here.
>> Please keep in mind that the proposed behavior is not currently prohibited. We are not changing any MUST NOT to anything else. All we are doing is to making some recommendations more explicit.
>>
>> > 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.
>>
>> Have you checked the problem statement draft?
>> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-03#section-3.7
>> specificatlly?
>> What you are proposing does make sense, however it would not help in case of multiple routers. Also I recall some people having strong opinions on performance implications.
>>
>> > 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"?
>>
>> See https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-03
>>
>> > 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.
>>
>> I was saying that some routing platforms have this already implemented. Search for 'glean' here:
>> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_basic/configuration/15-e/ip6b-15-e-book/ip6-nd-cache-mgmt.html
>>
>> AFAIK there are implementations which are also prepopulating NC from DAD packets but I can not find you a reference right now.
>>
>> > From: ipv6 [mailto:[email-masked]] On Behalf Of Jen Linkova
>> > Sent: 27 июля 2020 г. 7:49
>> > To: 6man <[email-masked]>
>> > 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 <[email-masked]> 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 [email-masked] Administrative
>> > > Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > > --------------------------------------------------------------------
>> >
>> >
>> >
>> > --
>> > SY, Jen Linkova aka Furry
>> >
>> > --------------------------------------------------------------------
>> > IETF IPv6 working group mailing list
>> > [email-masked]
>> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> > --------------------------------------------------------------------
>>
>>
>>
>> --
>> SY, Jen Linkova aka Furry

-- 
SY, Jen Linkova aka Furry

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 7 Aug 2020 08:32:54 +0000

Hello Jen

I'm effectively describing the behavior of the host when the prefix is not on-link, in combination with GRAND. Together, they can mostly eliminate multicast lookup., which is, well, grand.

As I read it, the L bit when reset indicates an address from that prefix is not signaled to be reachable on the multicast domain. IOW It may or may not be reachable. So the RFC 4861 address resolution may not work, better not use it. Instead pass the packets to the router to route beyond the broadcast domain. 

So yes, one quick and dirty way to get there would be to RECOMMEND that the prefix is advertised as not on-link (L=0) in general. We get the correct operation, but then this defeats the semantics of the bit, doesn't it?

- ITOH, the L bit is a valuable signal to indicate NBMA topologies, multilink subnets etc... We want to avoid NS(lookup) in a topology like that. We are using that heavily in LLNs and mandating it in the backbone router draft, problem solved there (see    
https://tools.ietf.org/html/draft-ietf-6lo-backbone-router-20#section-7). 

- OTOH, if we set it also in transit links, we get the right behavior but lose the indication that the prefix is onlink though we do not want multicast resolution. So though using the L bit would get us there, at the same time that would make it lose an important part of its substance.

Note that in a real NBMA, it can be quite risky to redirect. e.g., in FR or ATM, the router does not know if there is a circuit between a pair of hosts, and what DLCI (VPI/VCI) that would be. Ideally the L bit reset would be an indicator that there is no direct host to host.

So what I'm after is the host behavior of "not onlink" for the lookup phase, the router behavior of onlink for the redirect phase, and the L bit set iff the link is P2P or a transit. E.g., in a distributed fabric, all addresses "reside on-link and can be reached directly without going through a router" and yet we want to avoid broadcast lookups.

Take care,

Pascal

> From: Jen Linkova <[email-masked]>
> Sent: vendredi 7 août 2020 04:04
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: Jen Linkova <[email-masked]>; IPv6 Operations <[email-masked]>;
> 6man <[email-masked]>
> Subject: Re: [v6ops] draft-ietf-6man-grand : saving lookups
> 
> HI Pascal,
> 
> It looks to me that what you are suggesting can be achieved by setting L bit to
> zero in PIOs. In that case hosts would send all traffic to routers and upon
> receiving a redirect would learn that the given destination is actually on-link.
> > So say a third party host has traffic to send and the prefix is online. It will
> store one packet and multicast a lookup to the snma of this node. It will drop
> the other packets.
> >
> > An alternate behavior in a network where GRAND is enabled could be to
> start by forwarding the packets to the router in case of aN ND cache miss.
> >
> > If the router already has an NCE there will not be a lookup at all. The router
> will redirect immediately and relay the packets in the meantime. No delay, no
> loss. And no multicast...
> >
> > If the router does not have a cache, it will do the NS lookup. And eventually
> redirect anyway if the traffic continues. Same overall cost, with the benefit
> that the router now has the cache ready in case yet another host needs it.
> >
> > Cherry on the cake: the router may be more SAVI-savvy than this host so it
> may redirect to the real first-come node.
> >
> > What do you think?
> >
> > Pascal
> >
> > Le 30 juil. 2020 à 12:37, Lorenzo Colitti
> <lorenzo=[email-masked]> a écrit :
> >
> > 
> > I think the fact is that ND is inherently insecure from on-link attacks. If
> security is desired, then it needs to be provided in other ways, such as via
> SEND or SAVI. But it's also not particularly desirable to provide security at this
> layer. Traffic snooping is not very useful (not zero utility, but difficult to use
> well) when all traffic is encrypted, and on-link DoS attacks just aren't very
> useful these days given that many devices have a variety of connectivity
> options.
> >
> > On Thu, Jul 30, 2020 at 5:05 PM Vasilenko Eduard
> <vasilenko.eduard@huawei..com> wrote:
> >>
> >> Many people understand that "Unsolicited NA" is a big security hole
> >> per se, But instead of fixing it (may be even deprecate - should be
> >> investigated) Additional functionality is building on top of it.
> >> IMHO: it is better to prohibit "Unsolicited NA". Let's wait timers for the
> case of MAC address change on legitimate host.
> >> But if additional functionality would be built on top of "Unsolicited NA" -
> less options would be available ("deprecate" would be not a choice anymore).
> >>
> >> Jen, I have not understood below why you did mention RA Guard. Intruder
> does not need it. He just claim (by Unsolicited NA) that his MAC is connected
> to GUA of victim.
> >> Intruder could claim it every 5 seconds to keep cache in STALE state (for
> the case of very careful vendor implementation of ND).
> >> As you mentioned - no help from MLD snooping on switches - it would be
> enough to just listen to DAD. Switch could not help in principle.
> >> > 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:
> >> > - Intruder should be already on the same subnet (gained control
> >> > over other host by exploiting of different vulnerability)
> >> > 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.
> >>
> >> 1) the 7 seconds corner case was for 'preventing address collision for
> Optimistic DAD', not for any intentional attacks case. Because:
> >> 2) What you are describing could be done today, now, anytime w/o the
> changes described in the draft. If there is no MLD snooping then the intruder
> would see the DAD packet from the victim, so it would know the victim
> address anyway  - no reason even to join ff02::2. Now all the attacker needs to
> do is to keep sending NA with S=1, O=1 - hoping that when the first packet of
> the return flows arrive and the router creates an INCOMPLETE entry and sends
> an NS, the attacker's packet would come before the victim's NA. Done, the
> entry is changed to REACHABLE, all traffic goes to the attacker.
> >> Let's say the router has an NC entry for the victim address in any other
> state than INCOMPLETE. The attacker sends an NA with S=1, O=1, Target
> address = the victim's IPv6 address, the TLLA = the attacker MAC address.
> Done. The router updates the cache entry and changes it to REACHABLE state.
> >>
> >> > 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.
> >>
> >> For all that doom and gloom the attacker would also need to see the traffic
> *from* the victim. Assuming the network has RA Guard in place it would be a
> bit harder. If the network does not have RA Guard our poor victim has much
> bigger problems already.
> >>
> >> > 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.
> >> >
> >> Well, only hosts which want to connect to the network faster need to
> implement this. So host OS developers have pretty good incentive here.
> >> Please keep in mind that the proposed behavior is not currently prohibited.
> We are not changing any MUST NOT to anything else. All we are doing is to
> making some recommendations more explicit.
> >>
> >> > 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.
> >>
> >> What you are proposing does make sense, however it would not help in
> case of multiple routers. Also I recall some people having strong opinions on
> performance implications.
> >>
> >> > - 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)
> >> > - 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"?
> >>
> >> See
> >> https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-nd-cache-init-
> >> 03
> >>
> >> > 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.
> >>
> >> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_basic/configur
> >> ation/15-e/ip6b-15-e-book/ip6-nd-cache-mgmt.html
> >>
> >> AFAIK there are implementations which are also prepopulating NC from
> DAD packets but I can not find you a reference right now.
> >>
> >> > 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).
> >> > > -----------------------------------------------------------------
> >> > > --- IETF IPv6 working group mailing list [email-masked]
> >> > > Administrative
> >> > -------------------------------------------------------------------
> >> > - IETF IPv6 working group mailing list [email-masked] Administrative

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 7 Aug 2020 09:28:14 +0000

Hi Pascal,
You proposition for "how to avoid multicast" (by initial redirect through router) is interesting. I would think about it more: it has pros and cons.

But how is it related to GRAND? It should not help to warm-up cache on Router.
GRAND assumes that host sends 1st packet with user data, router does not have proper entry for this host yet.
Redirect function would not help to populate router cache in initial stage (that is GRAND trying to solve).

Or you assume that new host would initially communicate inside subnet (with some other host), that would populate router cache,
And only after this new host would go outside subnet.
IMHO: Host would probably go outside of subnet 1st, because Active Directory, DNS, and many other things.

Eduard
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: 7 августа 2020 г. 11:33
To: Jen Linkova <[email-masked]>
Cc: 6man <[email-masked]>; IPv6 Operations <[email-masked]>; Jen Linkova <[email-masked]>
Subject: Re: [v6ops] draft-ietf-6man-grand : saving lookups

Hello Jen

Take care,

Pascal

> routers and upon receiving a redirect would learn that the given destination is actually on-link.
> > Since the router is prepopulated, it knows the ND resolution before 
> > hosts
> do.
> >
> store one packet and multicast a lookup to the snma of this node. It 
> will drop the other packets.
> >
> will redirect immediately and relay the packets in the meantime. No 
> delay, no loss. And no multicast...
> >
> redirect anyway if the traffic continues. Same overall cost, with the 
> benefit that the router now has the cache ready in case yet another host needs it.
> >
> security is desired, then it needs to be provided in other ways, such 
> as via SEND or SAVI. But it's also not particularly desirable to 
> provide security at this layer. Traffic snooping is not very useful 
> (not zero utility, but difficult to use
> well) when all traffic is encrypted, and on-link DoS attacks just 
> aren't very useful these days given that many devices have a variety 
> of connectivity options.
> >
> >> It would additionally challenge this security problem resolution in 
> >> the
> future!
> >>
> >> If something is ill - it should be cured first - bodybuilding make 
> >> sense only
> after this.
> >>
> does not need it. He just claim (by Unsolicited NA) that his MAC is 
> connected to GUA of victim.
> >> The first modified DNS response would convert traffic flow to 
> >> bi-directional
> for Intruder.
> >>
> >> Ed/
> >> > You did ask a feedback yesterday about severity of 7sec security 
> >> > hole that
> has very low probability.
> 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:
> >> > - 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).
> 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.
> 7.2.6), but low chances that this timer is checked on receiving side 
> (router), because RetransTimer is specified for transmission side.
> 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..
> according to section 7.2.5 clause I, - this ND record would be against 
> his LLA anyway.
> router would ask intruder about reachability (solicited NS-NA) - 
> intruder would confirm his LLA - it would finally put ND cache record into REACHABLE.
> >>
> changes described in the draft. If there is no MLD snooping then the 
> intruder would see the DAD packet from the victim, so it would know 
> the victim address anyway  - no reason even to join ff02::2. Now all 
> the attacker needs to do is to keep sending NA with S=1, O=1 - hoping 
> that when the first packet of the return flows arrive and the router 
> creates an INCOMPLETE entry and sends an NS, the attacker's packet 
> would come before the victim's NA. Done, the entry is changed to REACHABLE, all traffic goes to the attacker.
> >> There is nothing new here. We have the same issue with ARP - the 
> >> attacker
> can override ARP entry on the router.
> >>
> >> > That's it: upstream traffic of victim host is going to router, 
> >> > traffic back is
> going through Intruder.
> 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.
> >>
> *from* the victim. Assuming the network has RA Guard in place it would 
> be a bit harder. If the network does not have RA Guard our poor victim 
> has much bigger problems already.
> >>
> >> > What to do about it?
> 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.
> >>
> 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.
> >> >
> >> > 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).
> >>
> We are not changing any MUST NOT to anything else. All we are doing is 
> to making some recommendations more explicit.
> >>
> 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.
> >>
> >> 03#section-3.7
> case of multiple routers. Also I recall some people having strong 
> opinions on performance implications.
> >>
> >> > Effectively I do proposed the same SLLA RPF that is needed to fix 
> >> > current
> solution, but:
> >> > - without any modification of standard (it is local 
> >> > recommendation for router, NS-NA is exactly the same from RFC 
> >> > 4681, NA is unicast
> 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.
> >> https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipv6_basic/config
> >> ur ation/15-e/ip6b-15-e-book/ip6-nd-cache-mgmt.html
> >>
> 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).
> >> > (https://tools.ietf.org/html/draft-ietf-6man-grand-01#section-3.3
> >> > ) is very
> much appreciated.
> >> >
> >> > > A New Internet-Draft is available from the on-line 
> >> > > Internet-Drafts
> directories.
> >> > >    maintain reachability information.  This document updates 
> >> > > RFC4861
> to
> >> > >    allow routers to proactively create a Neighbor Cache entry 
> >> > > when a
> new
> >> > > 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.
> >> > >
> >> > > ---
> >> > -

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 7 Aug 2020 09:56:57 +0000

Hello Eduard

The idea is that With GRAND this host prepopulates the NCE in the routers. When another host starts a communication with this and though this host is on-link, the other acts as if it is not determined as so. So the other passes all packets to the router which is populated and immediately forwards to this. This way there is no packet loss.

Later (when the lower layer is ready, think vxlan or transparent bridging) the router redirects to the host which can fall back to normal on link traffic behavior.

 No multicast no delay no loss.

Keep safe,

Pascal

> Le 7 août 2020 à 11:29, Vasilenko Eduard <[email-masked]> a écrit :
> 
> Hi Pascal,

---

From: Vasilenko Eduard <[email-masked]>
Date: Fri, 7 Aug 2020 11:57:08 +0000

OK. Understood.
You are building additional functionality on top of the GRAND.
GRAND is pre-request.
Ed/
-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: 7 августа 2020 г. 12:57
To: Vasilenko Eduard <[email-masked]>
Cc: Jen Linkova <[email-masked]>; 6man <[email-masked]>; IPv6 Operations <[email-masked]>; Jen Linkova <[email-masked]>
Subject: Re: [v6ops] draft-ietf-6man-grand : saving lookups

Hello Eduard

Keep safe,

Pascal

> Or you assume that new host would initially communicate inside subnet 
> (with some other host), that would populate router cache, And only after this new host would go outside subnet.
>> It looks to me that what you are suggesting can be achieved by 
>> setting L bit to zero in PIOs. In that case hosts would send all 
>> traffic to routers and upon receiving a redirect would learn that the given destination is actually on-link.
>> 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:
>> 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:
>> 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..
>> according to section 7.2.5 clause I, - this ND record would be 
>> against his LLA anyway.
>> 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.
>>>> 
>> *from* the victim. Assuming the network has RA Guard in place it 
>> would be a bit harder. If the network does not have RA Guard our poor 
>> victim has much bigger problems already.
>>>> 
>>>>> What to do about it?
>> 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.
>>>>> 
>>>>> Additionally I do not like to wait till all hosts would refresh to 
>>>>> new draft
>> We are not changing any MUST NOT to anything else. All we are doing 
>> is to making some recommendations more explicit.
>>>> 
>> NS/NA) and checked on receiver side - this modification of standard 
>> is really needed to close Unsolicited NA vulnerability.
>>>>>>   allow routers to proactively create a Neighbor Cache entry when 
>>>>>> a
>> new

---

From: Jen Linkova <[email-masked]>
Date: Sat, 8 Aug 2020 21:16:21 +1000

> I'm effectively describing the behavior of the host when the prefix is not on-link, in combination with GRAND. Together, they can mostly eliminate multicast lookup., which is, well, grand.

There is one catch here, I'm afraid. I might be mistaken but AFAIK
hosts are able to cache more packets while doing address resolution
than routers.
So if hosts start sending all traffic to onlink-destinations and the
router does not have the NC entry for that address, then we are back
to the original problem of 'all packets but the very first one is
dropped' but at the bigger scale.

> So yes, one quick and dirty way to get there would be to RECOMMEND that the prefix is advertised as not on-link (L=0) in general. We get the correct operation, but then this defeats the semantics o…

Does it? I don't think so... Setting L=1 means 'addresses in that
prefix are considered on-link', so if the address does not exist in
the NC, the host needs to send an NS for that address. L=0 means 'if
you haven't received an explicit indication that the address is
onlink, don't use Neighbor Discovery for that address but use your
default route instead'. Isn't it what you want?

We also need to take into account reliability of redirects here..
Anyway, just to confirm - it doesn't look like your suggestion changes
anything for this draft, right? Possible optimisations built on top of
GRAND can be described separately..

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 8 Aug 2020 11:38:43 +0000

Regards,

Pascal

> Le 8 août 2020 à 13:17, Jen Linkova <[email-masked]> a écrit :
> 

True, Jen.

That’s probably ok if that packet is just the original SYN. 

Still we’d want to avoid that situation. Maybe the host should renew the NCE in the router periodically ?

> default route instead'. Isn't it what you want?

Yes, I want the same host behavior but for another reason.

> GRAND can be described separately..

True too, Jen. Depends how much benefit we want to derive from the spec.

Keep safe,

Pascal

---

From: Jen Linkova <[email-masked]>
Date: Sun, 9 Aug 2020 19:28:51 +1000

On Sat, Aug 8, 2020 at 9:38 PM Pascal Thubert (pthubert)
<[email-masked]> wrote:
> Maybe the host should renew the NCE in the router periodically ?

GRAND currently focuses on 'a new address being added to the
interface' scenario. It does not solve the case of a node starts using
an already configured address after a long period of inactivity.

I guess we can add to the very end of the Section 4.1.2 (the new text):
"A node MAY send unsolicited NAs for its preferred addresses
periodically to refresh the Neighbor Cache on the first hop routers."

On the other hand it might pollute the router NC with entries for
addresses which the node has configured but is not going to use.

What does the WG think?

---

From: Mark Smith <[email-masked]>
Date: Sun, 9 Aug 2020 19:40:00 +1000

> addresses which the node has configured but is not going to use.

Won't NUD probes keep those entries current in the routers' cache, even
though hosts may not be actively using them?

I've thought that something like GRAND + NUD is starting to approach an
address registration protocol, or at least, makes the routers' cache the
"active addresses on a link" database.

Regards,
Mark.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 9 Aug 2020 13:50:30 +0000

We are facing 2 issues in the field that hurt especially in distributed fabrics with spanning L2 emulation (think eVPN and VxLAN)

One is with old privacy addresses that the host does not plan to use anymore. If the router NUDs them to check if they still exist, we create activity that gives a false sense of liveliness and renews the state indiscriminately with addresses that are really in use. A better NCE management could be achieved if we knew the intent of the host; but the current protocol does not expose that.

The second is with silent nodes like printers. Such a node has a fixed address but very rare connectivity. The printer may live a long time without any ND traffic and the network may forget the guy. The only way to find him is the multicast which as you know means broadcast.

If the host volunteers a periodic refresh of its active addresses at a period that the router can fathom then both issues can be avoided.

Ideally the period would depend on the usage to the address and the type of device. So it should also be suggested by the device.

Obviously we can do better than that but that’s a start...

Pascal

Le 9 août 2020 à 11:40, Mark Smith <[email-masked]> a écrit :

On Sun, 9 Aug 2020, 19:29 Jen Linkova, <[email-masked]<mailto:[email-masked]>> wrote:
On Sat, Aug 8, 2020 at 9:38 PM Pascal Thubert (pthubert)

Won't NUD probes keep those entries current in the routers' cache, even though hosts may not be actively using them?

I've thought that something like GRAND + NUD is starting to approach an address registration protocol, or at least, makes the routers' cache the "active addresses on a link" database.

Regards,
Mark.

What does the WG think?

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Philip Homburg <[email-masked]>
Date: Sun, 09 Aug 2020 17:46:48 +0200

> So what I'm after is the host behavior of "not onlink" for the
> lookup phase, the router behavior of onlink for the redirect phase,
> and the L bit set iff the link is P2P or a transit. E.g., in a
> distributed fabric, all addresses "reside on-link and can be reached
> directly without going through a router" and yet we want to avoid
> broadcast lookups.

Suppose we have a no-multicast bit, that tells a host to send traffic to
its default router when it doesn't have a neighbor in the NC cache.

It is not clear to me how the semantics would be different from clearing the
L-bit, but if you think there are considerable differences, why no write 
a draft that describes the use of such a bit.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 9 Aug 2020 12:03:32 -0400

Do we have data that indicates that this would be an improvement?  

> On Aug 9, 2020, at 11:47, Philip Homburg <[email-masked]> wrote:
> 
> 
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 9 Aug 2020 18:56:48 +0000

We have some Ted;

In large meetings we measured way above 100 ND multicast messages per second on the wire, for 90 minutes in a row.

This was on the wire because we use proprietary tech to dampen the wireless side, things like ND proxy but based on snooping for the lack of a better information.

I asked for the figures at the last 2 in person IETF meetings but never got them. First time I asked too late, there needs to be due process to guarantee anonymity. Not sure if they were captured in Singapore and if so where they are.

Take care,

Pascal

> Le 9 août 2020 à 18:04, Ted Lemon <[email-masked]> a écrit :
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 9 Aug 2020 18:58:33 +0000

Yes, Phil, 

I was suggesting to do that within GRAND so we have a path to ship. Reason is those functions really work well together.

That is, most of the time as Jen pointed out.

All the best,

Pascal

> Le 9 août 2020 à 17:47, Philip Homburg <[email-masked]> a écrit :
> 
> 
>>

---

From: Bob Hinden <[email-masked]>
Date: Sun, 9 Aug 2020 12:13:12 -0700

Pascal,

> On Aug 9, 2020, at 11:56 AM, Pascal Thubert (pthubert) <pthubert=[email-masked]> wrote:
> 
> We have some Ted;
> 

What does “way above 100” mean?   101, 1000, 10000, ?

100 per second doesn’t seem excessive to me.  What percentage of overall messages was that?  How many nodes on the link?

Bob

---

From: Michael Richardson <[email-masked]>
Date: Sun, 09 Aug 2020 16:02:30 -0400

Vasilenko Eduard <[email-masked]> wrote:
    > Yes, I have made comment below that if Address Allocation would be
    > changed to Centralized, then it is probably not SLAAC anymore. Then it
    > is better to adopt DHCPv6.

SLAAC has the features that it is seems completely stateless for the routers.
One can as many add routers to the network as desired to deal with whatever
resilience issues one has.   Many IPv4 experienced people are startled to
realize that one does not need VRRP or anything to have redundant routers in
IPv6.

Full stateful DHCPv6, can also be made resilient through redundancy, but it
seems significantly less popular, and it isn't particularly more secure when
it comes to ND, just to controlling address allocation.

There are things in between, as Pascal keep repeating: RFC8505 provides for
statefulness ND.  It's not mutually exclusive with SLAAC, as it does not deal
with assignment, just defense (DAD).

    > complicated: IP subnet is split for many broadcast domains, proxy
    > stitch it back.

But, the database which is the proxy is present in almost every single ethernet system today.
It's just that it exists at the layer-2 in the form of MAC address forwarding
tables.  We don't get to see them, don't get to securely update them, and
they are impossible to debug.  These are what I call layer-2 games.
We need to stop playing them, and architecture our layer-3 around the real
physical topology.  We need to do this for security, latency and efficiency
reasons.

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 9 Aug 2020 21:08:30 +0100

> realize that one does not need VRRP or anything to have redundant routers in

with respect, ND/RA has awful failover characteristics if a router 
disappears.  NHRPs like VRRP do a much better job.

Nick

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 9 Aug 2020 21:23:51 +0000

By memory this was around 300/s Bob.

This might look innocuous on a wire but on Wireless the broadcast is expensive, because it is sent at the lowest speed in all directions. 

This clogs the medium, maybe 5 to 10% of it; for no value at all but to offer the stick to beat us; well would have If we had let all that over the wire.

It is expensive too when a fabric spans multiple remote sites. 

Dismissing the problem, looking elsewhere is just not the way to go. 

Regards,

Pascal

> Le 9 août 2020 à 21:13, Bob Hinden <[email-masked]> a écrit :
> 
> Pascal,
>

---

From: Mark Smith <[email-masked]>
Date: Mon, 10 Aug 2020 07:43:16 +1000

> > directly without going through a router" and yet we want to avoid

I'm pretty sure IPv6 can support that already.

RFC5942,  IPv6 Subnet Model: The Relationship between Links and Subnet
Prefixes says hosts are to consider destinations, with exception to
link-local destinations, off-link by default. Off-link by default can be
overridden for individual asdresses via redirects, or for a contiguous
range of addesses, i.e. a prefix, via an RA PIO with L=1 (the A bit value
being irrelevant to this). If you want everything hair pinned through the
router all of the time you disable it sending redirects.

As I mentioned, the exception is link-locals, which RFC5942 says are always
on link. Here is my idea on how to change that - nothing that fancy, create
LL prefix POIs with L=0, that overrides host default of LL prefix being
on-link.

("Off Link" should really be in quotes in the draft title. "On-Link" is
probably a bit too broad a term, something like "directly link reachable",
meaning to ND for it rather than go via the default router, might have been
a bit more descriptive.)

https://tools.ietf.org/html/draft-smith-6man-link-locals-off-link-00

Regards,
Mark.

---

From: Jen Linkova <[email-masked]>
Date: Mon, 10 Aug 2020 09:41:37 +1000

> Won't NUD probes keep those entries current in the routers' cache, even though hosts may not be actively using them?

No, why would it? By the definition, for STALE entries no attempts are
made to verify the neighbor reachability. So if the node has not been
receiving traffic for that address, the STALE entry would stay there
until the router cleans it up.
So if we recommend sending periodic unsolicited NAs it might
re-populate the router cache with unused addresses which have been
cleaned up.
As sending periodic NAs would make sense for the very specific
scenario - the was sleeping, has woken up and is going to send some
traffic it might be a bit tricky to give guidance on that. In all
other cases I do not see much benefits...
Strictly speaking nothing described in this draft is prohibited in
RFC4861 anyway. So hosts can send unsolicited NAs anyway ;)

> I've thought that something like GRAND + NUD is starting to approach an address registration protocol, or at least, makes the routers' cache the "active addresses on a link" database.

I'd say 'most active addresses' as we can not guarantee that
unsolicited NAs reach routers.

---

From: Bob Hinden <[email-masked]>
Date: Sun, 9 Aug 2020 16:42:18 -0700

> On Aug 9, 2020, at 2:23 PM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 

Do you have a reference?  Also, answers to my other questions?

> It is expensive too when a fabric spans multiple remote sites.

I thought we learned long ago to not create large distributed broadcast/multicast domains.

Bob

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 10 Aug 2020 07:59:33 +0000

Hi Mark, Hi Pascal,
I have not understood why you have concerns on this: “even though hosts may not be actively using them” and “old privacy addresses that the host does not plan to use anymore”.
Jen did mention clearly in her quote “preferred addresses”. I believe that it is the terminology of RFC 4862: preferred and deprecated addresses.
If address is deprecated by host, then host would stop cache refreshment (logical assumption).

Hi Jen, may be to avoid such misunderstanding in the future you could change statement to:

"A node MAY send unsolicited NAs for its preferred addresses periodically to refresh the Neighbor Cache on the first hop routers.

A node SHOULD refrain from unsolicited cache refreshments for address in deprecated state"
And maybe it make sense to copy “deprecated” and “preferred” from 4862 to 1.2 (Terminology).

Eduard
From: v6ops [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: 9 августа 2020 г. 16:51
To: Mark Smith <[email-masked]>
Cc: Jen Linkova <[email-masked]>; 6man <[email-masked]>; IPv6 Operations <[email-masked]>
Subject: Re: [v6ops] draft-ietf-6man-grand : saving lookups

Pascal

Le 9 août 2020 à 11:40, Mark Smith <[email-masked]<mailto:[email-masked]>> a écrit :

Regards,
Mark.

What does the WG think?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Aug 2020 08:22:13 +0000

Hello Bob

The data was not published. This is why I asked for a measurement during the IETF meetings.

I do not know the ratio of traffic ND represents and you should know that it is meaningless on wireless if you do not account for relative PHY speed and loss of spectrum reuse and MUMIMO. I do not know the number of users, that was an excessively large room, bigger than our usual plenary though by far not a stadium.

What’s more interesting is that this group does not have such numbers. Shouldn’t we ?

For your last comment, we may consider doing protocols so that people can do what they want as opposed to ask them to bend their deployments to match inappropriate designs. 

This lack of consideration makes the bed of newIP-like endeavors, uncontrolled middlebox operations and proprietary tricks in switches and routers. But maybe a maintenance group is not the place to upgrade the protocol. Maybe we need an IPv6 working group again.

Just look at how BESS is doing DAD today. Then think SAVI. And we are in 2020. 

Regards,

Pascal

> Le 10 août 2020 à 01:42, Bob Hinden <[email-masked]> a écrit :
> 
> 
>

---

From: Jen Linkova <[email-masked]>
Date: Mon, 10 Aug 2020 18:24:30 +1000

> I have not understood why you have concerns on this: “even though hosts may not be actively using them” and “old privacy addresses that the host does not plan to use anymore”.

My understanding is that Mark's comment about 'even though hosts may
not be actively using them' was about the assumption that the router
would perform NUD for existing STALE entries so they would be
refreshed. So there is no reason to periodically send NAs.

> Jen did mention clearly in her quote “preferred addresses”. I believe that it is the terminology of RFC 4862: preferred and deprecated addresses.

Indeed.

> A node SHOULD refrain from unsolicited cache refreshments for address in deprecated state"

If we want to do this I'd change "SHOULD refrain from" to "MUST NOT send".
Personally I'm not convinced we shall be adding this text.
However the main question would be: how often does the device need to
send those NAs?
The frequency would actually depend on the NC garbage collector/clean
up timer on the router side. It means that node can not know it.
As the main use case is to help nodes waking up after a period of long
inactivity (long ==  long enough for the default routers to remove
their addresses from their NCs),
the node would need to send the unsolicited NA right after wake up and
before sending any traffic. Not sure how complicated it would be from
the host implementers PoV.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 10 Aug 2020 08:39:42 +0000

Hi Jen,
About this new idea (not yet incorporated into your GRAND): to send unsolicited NA after wake-up. What is wake-up? IMHO: it is timer only.
I hate additional timers. Could you choose any existing timer from RFC 4861? (even if it would be not very optimal)
Then "send unsolicited NA to routers if traffic has not been sent from preferred address to off-link for timer T"
Eduard
-----Original Message-----
From: Jen Linkova [mailto:[email-masked]] 
Sent: 10 августа 2020 г. 11:25
To: Vasilenko Eduard <[email-masked]>
Cc: Pascal Thubert (pthubert) <pthubert=[email-masked]>; Mark Smith <[email-masked]>; Jen Linkova <[email-masked]>; IPv6 Operations <[email-masked]>; 6man <[email-masked]>
Subject: Re: [v6ops] draft-ietf-6man-grand : saving lookups

> I have not understood why you have concerns on this: “even though hosts may not be actively using them” and “old privacy addresses that the host does not plan to use anymore”.

My understanding is that Mark's comment about 'even though hosts may not be actively using them' was about the assumption that the router would perform NUD for existing STALE entries so they would be refreshed. So there is no reason to periodically send NAs.

Indeed.

If we want to do this I'd change "SHOULD refrain from" to "MUST NOT send".
Personally I'm not convinced we shall be adding this text.
However the main question would be: how often does the device need to send those NAs?
The frequency would actually depend on the NC garbage collector/clean up timer on the router side. It means that node can not know it.
As the main use case is to help nodes waking up after a period of long inactivity (long ==  long enough for the default routers to remove their addresses from their NCs), the node would need to send the unsolicited NA right after wake up and before sending any traffic. Not sure how complicated it would be from the host implementers PoV.

> We are facing 2 issues in the field that hurt especially in 
> distributed fabrics with spanning L2 emulation (think eVPN and VxLAN)
>
>
>

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 10 Aug 2020 10:36:28 +0100

> I thought we learned long ago to not create large distributed broadcast/multicast domains.

We did, but what's disheartening is that people persistently use this 
model as rationale to justify a protocol change of one form or another.

Maybe we need an ID which states this explicitly: "Large broadcast 
domains considered harmful"?  As long as we have broadcast domains, 
people will be tempted to make them too large and will express surprise 
that they don't scale well.

Nick

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 10 Aug 2020 10:12:49 +0000

Hello Jen

If you tell the router then in most cases it will adapt without a problem. In practice we (routers) end up with too many addresses when we store a great many temporary ones that the hosts do not use anymore. You need to realize that those addresses and their bindings are published, e.g., via BGP route type 2. 

Regards,

Pascal

> Le 10 août 2020 à 11:37, Nick Hilliard <[email-masked]> a écrit :
> 
> We did, but what's disheartening is that people persistently use this model as rationale to justify a protocol change of one form or another.
> 
> Maybe we need an ID which states this explicitly: "Large broadcast domains considered harmful"?  As long as we have broadcast domains, people will be tempted to make them too large and will express surprise that they don't scale well.
> 
> Nick

---

From: Bob Hinden <[email-masked]>
Date: Mon, 10 Aug 2020 07:58:25 -0700

Nick,

> On Aug 10, 2020, at 2:36 AM, Nick Hilliard <[email-masked]> wrote:
> 

I agree on both points.   I would be willing to help write such a draft, but think it would be better with authors who have direct operational experience.

Bob

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Aug 2020 12:44:57 -0400

> We did, but what's disheartening is that people persistently use this model
    > as rationale to justify a protocol change of one form or another.

And, we continue to pretend that we have these large domains in our analysis
of performance and security. And additionally, we are expending large amounts
of L2 logic to continue to simulate them with very little increase is
performance or security.

    > Maybe we need an ID which states this explicitly: "Large broadcast domains
    > considered harmful"?  As long as we have broadcast domains, people will be
    > tempted to make them too large and will express surprise that they don't
    > scale well.

Just remove the word "large" :-)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Philip Homburg <[email-masked]>
Date: Tue, 11 Aug 2020 10:28:05 +0200

>addresses which the node has configured but is not going to use.

A few thoughts:

1) It has to specified how often the host has to refresh entries

2) I think MAY is too weak to rely on. One possibility to deal with 1)
   and 2) is to have an RA option that specifies the interval. Then we
   can make sending the NAs if the option is present a SHOULD or MUST

3) What happens if there are more entries then fit in the router's NC?

4) It has been argued against DHCPv6 IA_NA that hosts may need more 
   addresses than can be handled by the DHCP server. There is an RFC
   that says something to that effect. If so, then we can expect
   more address than can be handled by the router NC as well. I think
   we need to be consistent here. Or is this only for some special 
   networks where host have only few addresses?
   can also expect hoss

5) Hosts have to inform all routers, so this would require hosts to track
   all routers and just a few of them

6) It seems to me that this would something for a new draft

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Tue, 11 Aug 2020 14:54:50 +0000

Hi Bob,

> > Maybe we need an ID which states this explicitly: "Large broadcast domains considered harmful"?  As long as we have broadcast
> domains, people will be tempted to make them too large and will express surprise that they don't scale well.
> 

Some NBMA links can be *very* large, with all nodes on the link as candidates for receiving
link-scoped multicast. However, with proper controls on limiting the transmission of link
scoped multicast, the transmissions can be effectively propagated to exactly that (small)
group of nodes on the link that actually need to receive them. So, if there is going to be a
draft please make sure to add a note to the effect that properly engineered NBMA links
are an exception, and can in fact support a very large broadcast domain.

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Aug 2020 10:59:50 -0400

> are an exception, and can in fact support a very large broadcast domain.

This seems related to the notion that rather than doing unacknowledged multicasts on WiFi, the AP should simply unicast the multicast packet to all interested stations serially.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 11 Aug 2020 14:35:16 -0400

> What does “way above 100” mean?   101, 1000, 10000, ?

Do you remember IETF 99 (July 16-21, 2017,  Prague, Czech Republic,
1230 onsite attendees) and the Terrible, Horrible, No Good, Very Bad
Network? This was on the order of 2,000 broadcast / multicast packets
per second.
https://tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-problems-11,
Section 3.2.4.  Spurious Neighbor Discovery - "Around 2,000 broadcasts
per second have been observed at the IETF NOC during face-to-face
meetings."

Apart from destroying the wireless, this kills mobile device battery life....

> 100 per second doesn’t seem excessive to me.  What percentage of overall messages was that?  How many nodes on the link?

For many networks, the broadcast/multicast load DECREASES as the
number of nodes INCREASES. For something like the IETF network, we are
constantly getting background radiation from scanners, etc. This leads
to neighbor discovery / ARP requests for unused space, leading to B&M.
Once the network gets "fuller" the neighbor discovery traffic drops
significantly....

See also https://tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-problems-11
, Section 4, esp 4.6, Section 5.1, and, well, all of the other
sections too....

> > This was on the wire because we use proprietary tech to dampen the wireless side, things like ND proxy but based on snooping for the lack of a better information.

Yes, modern wifi devices do many many non-standard (and often
blackmagic/poorly documented) things to try and mitigate these issues.
Unfortunately they often fail in bizarre and difficult to troubleshoot
ways...

> > I asked for the figures at the last 2 in person IETF meetings but never got them. First time I asked too late, there needs to be due process to guarantee anonymity. Not sure if they were captured…

Who / where did you ask for this? And what exactly were you wanting to
collect -- a simple rate of broadcast / multicast would probably have
been easy, and not privacy invasive...
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Jen Linkova <[email-masked]>
Date: Wed, 12 Aug 2020 13:54:16 +1000

> 1) It has to specified how often the host has to refresh entries

Yes, and it would be very tricky because (as I've mentioned in another
email in this thread) finding the useful interval requires knowing the
timers for NC garbage collection on routers.

>    can make sending the NAs if the option is present a SHOULD or MUST

I'm not convinced we shall be doing it in the first place ;) And MUST
or even SHOULD look like a very strong requirement on all hosts just
to cover the very special case of sleeping devices.

> 3) What happens if there are more entries then fit in the router's NC?

I guess the same thing which happens in other scenarios when  the
router is trying to create an entry and there is no free space.

>    networks where host have only few addresses?

Yes, I agree. Normally when a host *assigns* an address it's very
likely that the host is going to use it soon.
Periodic announcements for all preferred addresses does look like an
overkill to me.

>    all routers and just a few of them

I'm not sure about this - ff02::2 should work.

> 6) It seems to me that this would something for a new draft

i totally agree.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 12 Aug 2020 11:05:05 +0200

>Periodic announcements for all preferred addresses does look like an

[Just commenting on this particular point]

It is not clear to me where the notion comes from that deprecated address
can be ignored.

Deprecated addresses are perfectly fine addresses, they are just not
used to set up new connections (unless there is no alternative).

In particular, during renumbering deprecated address can still be in 
DNS. Decrecated address can be used in various ways to separate outgoing
from incoming traffic.

So if we want to inform a router about addresses that belong to a host,
then we should report all addresses.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 12 Aug 2020 11:13:12 +0200

> I was suggesting to do that within GRAND so we have a path to ship.
> Reason is those functions really work well together.

Given the complexity of this subject, it is in my opinion better to have
a series of small drafts that can be discussed separately.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 12 Aug 2020 23:09:46 +0900

> to cover the very special case of sleeping devices.

+1 to not doing this, because some of those "sleeping devices" might also
be routers (e.g., a phone that is sharing the wifi connection). Per spec,
any packet to ff02::2 will reach and potentially wake up those devices. If
these packets become common, the devices will be forced to choose between
a) bad battery life and b) violating the spec (or at least nullifying its
utility) by dropping the packets.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 12 Aug 2020 14:32:03 +0000

Sleeping devices should have a helper that covers for them; the more troubling case is that if a silent device, like this printer in the corner.

Not sleeping just sitting there and very sure that it will get packets for a very long time. As opposed to a phone that would fully benefit from grand, that guy will not benefit at all after day one? Unless it renews the binding.

To Jen’s point, the host does not need to guess the lifetime in the BCE. When something is needed we must add a protocol element to pass it, that’s what protocols do.

Now I’d argue that all addresses should not get the same service from the router, and only the host k owe if the address should be short or long lived. This is why the lifetime in of the binding in the router should be requested by the host and granted by the router. This is nothing new, mobile IP works exactly like that.

Regards,

Pascal

Le 12 août 2020 à 16:10, Lorenzo Colitti <lorenzo=[email-masked]> a écrit :

+1 to not doing this, because some of those "sleeping devices" might also be routers (e.g., a phone that is sharing the wifi connection). Per spec, any packet to ff02::2 will reach and potentially wake up those devices. If these packets become common, the devices will be forced to choose between a) bad battery life and b) violating the spec (or at least nullifying its utility) by dropping the packets.
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Gyan Mishra <[email-masked]>
Date: Wed, 12 Aug 2020 11:27:05 -0400

As these issues can get overwhelming complex as we dig into the weeds, I
agree a series of small drafts to address these issues makes sense.

Thanks

Gyan

On Wed, Aug 12, 2020 at 10:32 AM Pascal Thubert (pthubert) <pthubert=
[email-masked]> wrote:

> Sleeping devices should have a helper that covers for them; the more
> troubling case is that if a silent device, like this printer in the
> corner.
>
> Not sleeping just sitting there and very sure that it will get packets for
> a very long time. As opposed to a phone that would fully benefit from
> grand, that guy will not benefit at all after day one? Unless it renews the
> binding.
>
> To Jen’s point, the host does not need to guess the lifetime in the BCE.
> When something is needed we must add a protocol element to pass it, that’s
> what protocols do.
>
> Now I’d argue that all addresses should not get the same service from the
> router, and only the host k owe if the address should be short or long
> lived. This is why the lifetime in of the binding in the router should be
> requested by the host and granted by the router. This is nothing new,
> mobile IP works exactly like that.
>
>
> Regards,
>
> Pascal
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD