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

[Mark Smith <[e-mail]>]

On Wed, 5 Aug 2020, 02:06 Vasilenko Eduard, <[e-mail]>
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:[e-mail]]
> Sent: 4 августа 2020 г. 13:01
> To: Vasilenko Eduard <[e-mail]>; Michael Richardson <
> [e-mail]>; Templin (US), Fred L <[e-mail]>
> Cc: v6ops list <[e-mail]>; 6man <[e-mail]>
> 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 <[e-mail]>
> > Sent: mardi 4 août 2020 11:08
> > To: Michael Richardson <[e-mail]>; Templin (US), Fred L
> > <[e-mail]>
> > Cc: Pascal Thubert (pthubert) <[e-mail]>; v6ops list
> > <[e-mail]>; 6man <[e-mail]>
> > 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:[e-mail]] On Behalf Of Michael
> > Richardson
> > Sent: 4 августа 2020 г. 2:57
> > To: Templin (US), Fred L <[e-mail]>
> > Cc: Pascal Thubert (pthubert) <pthubert=[e-mail]>;
> > v6ops list <[e-mail]>; 6man <[e-mail]>
> > Subject: Re: [v6ops] I-D Action: draft-ietf-6man-grand-01 - additional
> > security concerns
> >
> >
> > Templin (US), Fred L <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
> > - = IPv6 IoT consulting =-
> >
> >
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>