Subject: [v6ops] SLAAC security concerns

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 4 Aug 2020 18:00:39 +0000

Hi Mark,
I believe that Multicast is so basic function of SLAAC that it does not make sense to delete it.
On contrary, I believe Multicast should help against information leakage.

I believe that trade-off of “Local DoS” against “Information Leakage” is possible:
if somebody would hijack your address - change your address (release it), despite you were the 1st to book it.
And ask others (especially router) to block this address for some time (for anybody), router would have to drop all packets that are in transit to this address (on the path from internet).
Collision should have the penalty for both parties. Unsolicited NA should be multicast-only. It has very low probability to happen unintentionally (1/2^64).
Let it would be “Local DoS” instead of “Information Leakage”.

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

On Wed, 5 Aug 2020, 02:06 Vasilenko Eduard, <[email-masked]<mailto:[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).

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

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

> -----Original Message-----
> From: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>
> Sent: mardi 4 août 2020 11:08
> To: Michael Richardson <[email-masked]<mailto:[email-masked]>>; Templin (US), Fred L
> <[email-masked]<mailto:[email-masked]>>
> Cc: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; v6ops list
> <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[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.
>
> >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]<mailto:[email-masked]>] On Behalf Of Michael
> Richardson
> Sent: 4 августа 2020 г. 2:57
> To: Templin (US), Fred L <[email-masked]<mailto:[email-masked]>>
> Cc: Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:[email-masked]>>;
> v6ops list <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
> Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional
> security concerns
>
>
> Templin (US), Fred L <[email-masked]<mailto:[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]<mailto:[email-masked]>>, Sandelman Software Works
> - = IPv6 IoT consulting =-
>
>

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

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

Eduard, NBMA allows for multicasts to reach only a bounded and well-managed set
of recipients instead of flooding the entire link. It is the method used by AERO/OMNI.

Fred

From: Vasilenko Eduard [mailto:[email-masked]]
Sent: Tuesday, August 04, 2020 11:01 AM
To: Mark Smith <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; Michael Richardson <[email-masked]>; Templin (US), Fred L <[email-masked]>; v6ops list <[email-masked]>; 6man <[email-masked]>
Subject: [EXTERNAL] SLAAC security concerns

This message was sent from outside of Boeing. Please do not click links or open attachments unless you recognize the sender and know that the content is safe.

Hi Mark,

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

Regards,
Mark.

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

Hello Eduard

All the best

Pascal

---

From: Gert Doering <[email-masked]>
Date: Tue, 4 Aug 2020 21:44:48 +0200

Hi,

> I believe that Multicast is so basic function of SLAAC that it does not make sense to delete it.

Have I heard "delete multicast" here?

Yes, please!

There is too many broken switch vendors out there that show again and
again that "implementing multicast is hard", breaking IPv6 ND in the 
process.

The motivation for going to multicast "back in the dark ages" might have
been honorable, but in today's networks, it just adds needless complications.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Aug 2020 16:15:22 -0400

> again that "implementing multicast is hard", breaking IPv6 ND in the 

Why don’t you return that switch for a refund?

(I’ve never run into a switch that had trouble with IPv6 multicast, but admittedly I only have four different switches in my house, so that’s not a very big sample.)

---

From: Gert Doering <[email-masked]>
Date: Tue, 4 Aug 2020 22:28:47 +0200

Hi,

On Tue, Aug 04, 2020 at 04:15:22PM -0400, Ted Lemon wrote:
> Why don???t you return that switch for a refund?
> 
> (I???ve never run into a switch that had trouble with IPv6 multicast, but admittedly I only have four different switches in my house, so that???s not a very big sample.)

$20 switches tend to be not affected.

It's the more expensive ones where developers intended to "do the right
thing with multicast!" and never came around to actually implement it.

Or where you need to turn on - or *off* - MLD to make link-local multicast
work, but the default is the wrong way around.

I have seen this on devices from three different vendors - Extreme, Juniper,
and "something that DECIX was using like 15 years ago" - and of course not
all models or all firmware versions are affected.  But when it happens, it's
life time you won't get back.

If I were to return every device in my network where a developer messed
up something the IETF made too complex in protocol design, I would have
a very secure, and very power-efficient result - but no network anymore.

(And your response very nicely demonstrates why operators get fed up
trying to participate in IETF)

Gert Doering
        -- NetMaster

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 4 Aug 2020 20:41:46 +0000

Talking about multicast might be misleading. Has anyone deployed L2 multicast? IEEE people told me they designed one and that after some hiccups it was made to work but not much implemented and deployed.

Even then this is pushing the scalability problem one layer down not solving it, like almost as many groups as there are addresses so what’s the point?

Else for all I know we are mostly broadcasting any DAD and lookup over the whole L2, causing storms and wasting the wireless bandwidth. This is also a major pain point for the deployment of large multi site fabrics.

Disclaimer: I have not seen IGMP snooping successfully turned on for link scope multicast; unclear if and how that can help or if as hinted in this thread it should be turned off. I’d be interested in return from experience there :)

Keep safe,

Pascal

Le 4 août 2020 à 22:17, Ted Lemon <[email-masked]> a écrit :

 On Aug 4, 2020, at 3:44 PM, Gert Doering <[email-masked]<mailto:[email-masked]>> wrote:
There is too many broken switch vendors out there that show again and
again that "implementing multicast is hard", breaking IPv6 ND in the
process.

[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 5 Aug 2020 08:54:06 +1200

> thing with multicast!" and never came around to actually implement it.

It's also a matter of scale. Multicast-dependent code that runs perfectly
on a small home network fails dramatically on a site network with defective
MLD implementation, and misbehaves significantly on a network with correct
MLD implementation but very heavy load. (I speak from experience with
the ANIMA GRASP protocol, that uses low rate multicast. On the IETF network,
for example, only about 10% of its multicasts were delivered, and this was
because the switches were doing MLD correctly and behaving exactly as intended
by the NOC. If you care, you can see that draft-ietf-anima-autonomic-control-plane
provides NBMA service for GRASP, even though it doesn't use that term.) 

> trying to participate in IETF)

All the same, Gert, we need frequent injections of reality. Thanks!

   Brian

---

From: Mark Smith <[email-masked]>
Date: Wed, 5 Aug 2020 09:32:56 +1000

> been honorable, but in today's networks, it just adds needless

Multicast also shifts and distributes state away from a central device.

A central device is a much bigger consequence point of failure, and is a
harder thing to make redundant due to having to invent a state
synchronisation and load selection or distribution method mechanism between
a primary and one or more backup nodes.

Nodes maintaining their own state is simpler and means that when a node
fails, the loss of state due to the failure only impacts the failed node.

A specific design for redundant DHCPv6 has to exist. Redundancy in SLAAC
came inherently in its design because a node failure only impacts that node.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Aug 2020 05:58:48 +0000

True, there are pros and cons and engineering trade offs as usual. That’s why we are here.

It doesn’t mean that this particular benefit is the most important consideration in all situations. The distributed approach has large consequences in usage of broadcast, security (DOS. SAVI, hijacking) and reactivity (Lookup reactive to outstanding packets) that make it unsuitable in many modern forms of l2 networks.

 In fact DHCP in the IPv4 world has survived quite successfully through the years without being the major pain point that broadcast storms have been.

The state in a centralized ND database can be synchronized. It’s not that hard. Routing protocols do that all the time. In fact a route type 2 in eVPN is exactly that.

Bottom line is that there may be a very large number of small deployments such as home where stateless ND and the associated multicast are quite fine. But there is  also a growing number of larger networks (enterprise, Conference wireless, distributed  Fabrics. cloud) where it’s completely Ill-suited.

So yes, we need an ND solution that uses only unicast, has inherent SAVI and ownership control, scales to large numbers of devices and is not an easy target for remote DoS.

Keep safe,

Pascal

Le 5 août 2020 à 01:34, Mark Smith <[email-masked]> a écrit :

On Wed, 5 Aug 2020, 05:44 Gert Doering, <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Yes, please!

A central device is a much bigger consequence point of failure, and is a harder thing to make redundant due to having to invent a state synchronisation and load selection or distribution method mechanism between a primary and one or more backup nodes.

Nodes maintaining their own state is simpler and means that when a node fails, the loss of state due to the failure only impacts the failed node.

A specific design for redundant DHCPv6 has to exist. Redundancy in SLAAC came inherently in its design because a node failure only impacts that node.

Gert Doering
        -- NetMaster

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 5 Aug 2020 06:23:28 +0000

Hi Fred,
I am not sure I fully understand your comment.
SLAAC currently heavily relay on Multicast. What additionally would be done with multicast – it would not increase multicast dependency.
Eduard
From: Templin (US), Fred L [mailto:[email-masked]]
Sent: 4 августа 2020 г. 22:39
To: Vasilenko Eduard <[email-masked]>; Mark Smith <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; Michael Richardson <[email-masked]>; v6ops list <[email-masked]>; 6man <[email-masked]>
Subject: RE: SLAAC security concerns

Fred

To: Mark Smith <[email-masked]<mailto:[email-masked]>>

Hi Mark,

Eduard

Regards,
Mark.

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

Hello Eduard

All the best

Pascal

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 5 Aug 2020 06:26:54 +0000

Hi Gert,
SLAAC dependency on multicast is so huge that it is not possible to make it worse by 1 additional function.
If L2 would lose ND packets, then many things in SLAAC would not work.
Eduard
-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: 4 августа 2020 г. 22:45
To: Vasilenko Eduard <[email-masked]>
Cc: Mark Smith <[email-masked]>; Michael Richardson <[email-masked]>; 6man <[email-masked]>; v6ops list <[email-masked]>
Subject: Re: [v6ops] SLAAC security concerns

Hi,

Yes, please!

There is too many broken switch vendors out there that show again and again that "implementing multicast is hard", breaking IPv6 ND in the process.

The motivation for going to multicast "back in the dark ages" might have been honorable, but in today's networks, it just adds needless complications.

Gert Doering
        -- NetMaster

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 5 Aug 2020 06:32:40 +0000

Bad vendor problem is rare in Enterprise in Carrier. Because:
1. Carrier do test all equipment heavily before any big purchase. Some Enterprise test too.
2. They both have big influence on vendor (he is interested in other sales) - vendors would fix problems promptly
Unfortunately, even such situation could create pressure on Operational, but it is a different story.

Vendor would not care too much about home user.
Ed/
-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: 4 августа 2020 г. 23:29
To: Ted Lemon <[email-masked]>
Cc: Gert Doering <[email-masked]>; Vasilenko Eduard <[email-masked]>; Michael Richardson <[email-masked]>; v6ops list <[email-masked]>; 6man <[email-masked]>
Subject: Re: [v6ops] SLAAC security concerns

Hi,

On Tue, Aug 04, 2020 at 04:15:22PM -0400, Ted Lemon wrote:
> > There is too many broken switch vendors out there that show again 
> > and again that "implementing multicast is hard", breaking IPv6 ND in 
> > the process.
> 
> (I???ve never run into a switch that had trouble with IPv6 multicast, 
> but admittedly I only have four different switches in my house, so 
> that???s not a very big sample.)

It's the more expensive ones where developers intended to "do the right thing with multicast!" and never came around to actually implement it.

Or where you need to turn on - or *off* - MLD to make link-local multicast work, but the default is the wrong way around.

I have seen this on devices from three different vendors - Extreme, Juniper, and "something that DECIX was using like 15 years ago" - and of course not all models or all firmware versions are affected.  But when it happens, it's life time you won't get back.

If I were to return every device in my network where a developer messed up something the IETF made too complex in protocol design, I would have a very secure, and very power-efficient result - but no network anymore.

(And your response very nicely demonstrates why operators get fed up trying to participate in IETF)

Gert Doering
        -- NetMaster

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 5 Aug 2020 06:43:54 +0000

Hi Pascal,
I was in business for long time. I am not much scared of bad vendor implementation of multicast or not implemented multicast at all.

Your concern that not every technology is good for multicast is right: WiFi (most popular type of connection our times) is not friendly to multicast whatever vendor would do about it.
Your point is very valid, but I do not want revolution in SLAAC. I want evolution – minimal number of changes to patch only biggest holes. Revolution would not be accepted by the market.
I agree that final picture is not ideal.

PS: If people would like revolution – you have the good proposal what to do. Let we see how much would be acceptance after additional 10 years.
Eduard
From: ipv6 [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: 4 августа 2020 г. 23:42
To: Ted Lemon <[email-masked]>
Cc: Michael Richardson <[email-masked]>; v6ops list <[email-masked]>; 6man <[email-masked]>; Gert Doering <[email-masked]>
Subject: Re: [v6ops] SLAAC security concerns

Keep safe,

Pascal

Le 4 août 2020 à 22:17, Ted Lemon <[email-masked]<mailto:[email-masked]>> a écrit :
 On Aug 4, 2020, at 3:44 PM, Gert Doering <[email-masked]<mailto:[email-masked]>> wrote:
There is too many broken switch vendors out there that show again and
again that "implementing multicast is hard", breaking IPv6 ND in the
process.

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 5 Aug 2020 13:31:39 +0000

Hi Eduard,

Hi Fred,

On AERO/OMNI NBMA we use link-scoped multicast for one purpose only – for the
sending of uNAs and uRAs to exactly the set of nodes that need to receive them.
Normally, the set will be small even though the collection of nodes on the link
may be enormous.

We do not do SLAAAC, so there is no multicasting for MLD/DAD. Address Resolution
follows a unicast route, so there is no multicasting for that. And, that is about it.

Again the multicasted uNAs/uRAs go to exactly the (small) set of nodes that need
to receive them and no others. And, that is about it for link-scoped multicast on
AERO/OMNI.

Fred

Eduard
From: Templin (US), Fred L [mailto:[email-masked]]
Sent: 4 августа 2020 г. 22:39
To: Vasilenko Eduard <[email-masked]<mailto:[email-masked]>>; Mark Smith <[email-masked]<mailto:[email-masked]>>
Cc: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; Michael Richardson <[email-masked]<mailto:[email-masked]>>; v6ops list <[email-masked]<mailto:[email-masked]>>; 6man <[email-masked]<mailto:[email-masked]>>
Subject: RE: SLAAC security concerns

Fred

Hi Mark,

Eduard

Regards,
Mark.

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

Hello Eduard

All the best

Pascal

---

From: Vasilenko Eduard <[email-masked]>
Date: Wed, 5 Aug 2020 13:47:44 +0000

Hi Fred,
Your technology is “very wireless”. No wonder that you deleted multicast – it is predictable/logical.

The question is: do you believe that multicast should be deleted from basic IPv6 neighbor discovery and address management? Should SLAAC have so big change?

Eduard
Sent: 5 августа 2020 г. 16:32

Hi Eduard,

Hi Fred,

Fred

Eduard

Fred

Hi Mark,

Eduard

Regards,
Mark.

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

Hello Eduard

All the best

Pascal

---

From: "Templin (US), Fred L" <[email-masked]>
Date: Wed, 5 Aug 2020 13:58:20 +0000

Hi Eduard,

>Your technology is “very wireless”. No wonder that you deleted multicast – it is predictable/logical.

Yes, it is friendly to wireless environments. But, no, we have not “deleted” multicast.
Multicast is still used but on a much more limited basis than traditional broadcast
media. It is used for a node that is having a “life event” to notify its next of kin only,
but that is about it.

>The question is: do you believe that multicast should be deleted from basic IPv6 neighbor discovery and address management? Should SLAAC have so big change?

No, multicast should appropriately remain in IPv6 ND. I am speaking here about one
link type only – the OMNI NBMA link. Other link types (e.g., Ethernet, Wifi and the
like) will still have need of link-scoped multicast.

Fred

From: Vasilenko Eduard [mailto:[email-masked]]
Sent: Wednesday, August 05, 2020 6:48 AM
To: Templin (US), Fred L <[email-masked]>; Mark Smith <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; Michael Richardson <[email-masked]>; v6ops list <[email-masked]>; 6man <[email-masked]>
Subject:  RE: SLAAC security concerns

Hi Fred,

Eduard

Hi Eduard,

Hi Fred,

Fred

Eduard

Fred

Hi Mark,

Eduard

Regards,
Mark.

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

Hello Eduard

All the best

Pascal

---

From: Gert Doering <[email-masked]>
Date: Wed, 5 Aug 2020 20:24:55 +0200

Hi,

> a primary and one or more backup nodes.

This asks for "broadcast", not for "multicast".

To get any benefits from multicast, you now require that all the network
elements listen to MLD and understand which multicast packets to hand
where.  And keep state.

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Wed, 5 Aug 2020 20:27:21 +0200

Hi,

> If L2 would lose ND packets, then many things in SLAAC would not work.

Yes.  Been there, cursed the vendor of the day, resorted to static ND
entries and/or got a software upgrade and/or found the necessary twiddle
to make that device well-behave.

Multicast for ND sucks about as hard as LLAs for BGP next-hops with a
TCP session over GUA.

Gert Doering
        -- NetMaster