Subject: [v6ops] draft-jaeggli-v6ops-indefensible-nd

From: Ron Bonica <[email-masked]>
Date: Mon, 10 Sep 2018 14:25:08 +0000

Folks,

Each week between now and IETF 103, we will review and discuss one draft with an eye towards progressing it.

This week, please review and comment on draft-jaeggli-v6ops-indefensible-nd.

                                      Fred and Ron

---

From: Lee Howard <[email-masked]>
Date: Mon, 10 Sep 2018 16:23:21 -0400

Should there be some mention of SeND (rfc3971), and the several SAVI 
documents? Maybe rc6105 (RA Guard), but that's specific to RA, not ND.

I also know of at least one vendor that allows configuration limiting 
neighbor table cache size, and prioritizing NA timer refresh over new 
discovery.

Operationally, I'd advise logging neighbor table changes, and throwing 
an alert if they exceed some reasonably high threshold. I can't say what 
"reasonable" is; I recently had a home gateway sending 70 RAs per second.

3.4 Firewalls. Is there any scenario where you'd want to allow NDP from 
off-link?  BCP38, don't allow SRC=LLA Link1, DST=GUA Link2, or vice versa.

Theoretically you could limit vulnerability by giving each host a VLAN. 
Or any other L3 segmentation. You could use L2/L3 ACLs to lock down ports.

I'm not sure this document currently provides enough value to advance. 
With the stuff above added in, maybe it consolidates enough advice into 
one place to be useful.

Lee

On 09/10/2018 10:25 AM, Ron Bonica wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 11 Sep 2018 14:34:45 +0900

> draft-jaeggli-v6ops-indefensible-nd.

It seems easy to solve this problem by saying that routers can create
speculative incomplete ND cache entries from DAD probes, and that such
incomplete entries take precedence over incomplete entries due to forwarded
packets. Because all addresses require DAD, this would ensure that any host
that is on the router's link would have ND cache entries for all its
addresses as soon as the host joins the link.

In the presence of non-zero packet loss, this obviously does not increase
the reliability to 100%. However, on most networks it probably lowers the
payoff to such an extent to make the attack not useful in practice.

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Sep 2018 08:15:22 +0200

You might want to include that this problem has been solved with a stateful address assignment mechanism like DHCP, possibly combined with SAVI. 

The ND ARO option would also have solved this. 

Or you could deploy P2P Ethernet, where there is no address resolution. 

Depending on DAD for this lie Lorenzo proposed seems ill-advised. It’s even less robust in wired networks (blocked ports). 

Cheers 
Ole

> On 10 Sep 2018, at 16:25, Ron Bonica <[email-masked]> wrote:
> 
> Folks,
>

---

From: Erik Kline <[email-masked]>
Date: Tue, 11 Sep 2018 15:22:05 +0900

> Depending on DAD for this lie Lorenzo proposed seems ill-advised. It’s even less robust in wired networks (blocked ports).

But...in such a network NS/NA works?  (alternatively: what does
"blocked" mean here)

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Sep 2018 08:34:18 +0200

Erik,

> On 11 Sep 2018, at 08:22, Erik Kline <[email-masked]> wrote:
> 

NS/NA has retransmission. 
Blocked as in 802.1D. Default 30s from link-up until port will switch user traffic. 

DAD is unreliable for lots of reasons . Didn’t we write a draft on that?

Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 11 Sep 2018 15:47:24 +0900

You don't need stateful addressing (which has lots of downsides) to solve
this problem. SAVI-FCFS is sufficient.

On Tue, 11 Sep 2018, 15:15 Ole Troan, <[email-masked]> wrote:

> You might want to include that this problem has been solved with a
> stateful address assignment mechanism like DHCP, possibly combined with
> SAVI.
>
> Depending on DAD for this lie Lorenzo proposed seems ill-advised. It’s
> even less robust in wired networks (blocked ports).
>
> Cheers
> Ole
>

---

From: Erik Kline <[email-masked]>
Date: Tue, 11 Sep 2018 15:48:45 +0900

> Blocked as in 802.1D. Default 30s from link-up until port will switch user traffic.

Do hosts receive RAs during this 30s window?  If not, then the
blocking affects DAD for link-local addresses, but not necessarily for
GUAs.

NOTE: I am most definitely /not/ attempting to argue that DAD is reliable.  ;-)

I had a notion about matching forwarding addresses not in cache
against the MLD info associated with the /104 for a given forwarding
destination address.  Seems like routers gathering MLD data might use
that list to prioritize forwarding for destinations not yet in the
neighbor cache.

> DAD is unreliable for lots of reasons . Didn’t we write a draft on that?

https://tools.ietf.org/html/draft-yourtchenko-6man-dad-issues ?

---

From: Ole Troan <[email-masked]>
Date: Tue, 11 Sep 2018 08:56:12 +0200

> On 11 Sep 2018, at 08:47, Lorenzo Colitti <[email-masked]> wrote:
> 
> You don't need stateful addressing (which has lots of downsides) to solve this problem. SAVI-FCFS is sufficient.

SLAAC and SAVI FCFS wouldn’t detect a quiet listening host. And I almost managed to not make any comments about the horrible state everywhere layer violating properties of SAVI.

ARO, DHCP or P2P are the only reliable ways of doing this as far as I know.

If you’re happy with, works most of the time, then sure...

Ole

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 11 Sep 2018 07:32:03 +0000

We have greatly improved the ARO at 6lo and tried in the process to alleviate Lorenzo ‘s concerns about it being an undesirable way to remove freedom of address formation. We also discussed Bob’s concerns on IPv6 stability at length so hopefully we are passed that as well.

The new ARO (EARO) is clearly intended to protect the address ownership. The NP AD draft associates a crypto token to the registration but does not constrain the IID like SEND did. 

The EARO is already referenced by a number of drafts (at ROLL 6lo and RIFT) as the abstract way for a host to announce its addresses to selected routers and get services back, eg routing or ND proxy.

Regards,

Pascal

> Le 11 sept. 2018 à 08:49, Erik Kline <ek=[email-masked]> a écrit :
> 
>>>> Or you could deploy P2P Ethernet, where there is no address resolution..
>>>>

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Sep 2018 17:50:15 +1000

On Tue., 11 Sep. 2018, 15:35 Lorenzo Colitti, <lorenzo=
[email-masked]> wrote:

> packets. Because all addresses require DAD,
>

Actually, on-link anycast addresses don't, as DAD is specifically disabled
for them. Granted, on-link anycast aren't common.

I've been meaning to forward to Joel this draft by Joel et. al. from
Ericsson for reference that describes using DAD for ND DoS protection.

https://tools.ietf.org/html/draft-halpern-6man-nd-pre-resolve-addr-00

Regards,
Mark.

this would ensure that any host that is on the router's link would have ND
> cache entries for all its addresses as soon as the host joins the link.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 11 Sep 2018 16:52:30 +0900

On Tue, Sep 11, 2018 at 3:56 PM Ole Troan <[email-masked]> wrote:

> SLAAC and SAVI FCFS wouldn’t detect a quiet listening host.
>

In the real world, quiet listening hosts don't exist.

   1. Pretty much every OS these days is very chatty.
   2. The IPv6 protocol requires that you announce every IPv6 address using
   DAD.

Perhaps you mean an IP address that does not originate connections?

> And I almost managed to not make any comments about the horrible state
> everywhere layer violating properties of SAVI.
>

If security is what you're after, then DHCPv6 is not secure without SAVI,
either. I'd argue that the whole idea of a network blocking you at L2
because of your L3 address is a layering violation, anyway.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 11 Sep 2018 16:54:19 +0900

On Tue, Sep 11, 2018 at 4:32 PM Pascal Thubert (pthubert) <pthubert=
[email-masked]> wrote:

> We have greatly improved the ARO at 6lo and tried in the process to
> alleviate Lorenzo ‘s concerns about it being an undesirable way to remove
> freedom of address formation. We also discussed Bob’s concerns on IPv6
> stability at length so hopefully we are passed that as well.
>
> The new ARO (EARO) is clearly intended to protect the address ownership.
> The NP AD draft associates a crypto token to the registration but does not
> constrain the IID like SEND did.
>
> The EARO is already referenced by a number of drafts (at ROLL 6lo and
> RIFT) as the abstract way for a host to announce its addresses to selected
> routers and get services back, eg routing or ND proxy.
>

I don't see how requiring any form of ARO can respect IPv6 addressing best
practices. RFC 7934 section 8 says: "it is RECOMMENDED that the network
give the host the ability to use new addresses without requiring explicit
requests". An ARO is an explicit request.

---

From: Mark Smith <[email-masked]>
Date: Tue, 11 Sep 2018 18:58:32 +1000

On Tue., 11 Sep. 2018, 16:49 Erik Kline, <ek=[email-masked]>
wrote:

> > >> Depending on DAD for this lie Lorenzo proposed seems ill-advised.
> It’s even less robust in wired networks (blocked ports).
> > >

So did I ;-)

https://tools.ietf.org/html/draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-02

> > >>> Each week between now and IETF 103, we will review and discuss one
> draft with an eye towards progressing it.
> > >>>