Re: [v6ops] SLAAC security concerns

[Brian E Carpenter <[e-mail]>]

On 05-Aug-20 08:28, Gert Doering wrote:
> Hi,
> 
> On Tue, Aug 04, 2020 at 04:15:22PM -0400, Ted Lemon wrote:
>> On Aug 4, 2020, at 3:44 PM, Gert Doering <[e-mail]> 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.
>>
>> 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.

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.) 

> 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)

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

   Brian