Subject: ND cache entries creation on first-hop routers

From: Jen Linkova <[email-masked]>
Date: Wed, 3 Jul 2019 01:03:11 +1000

Hello,

I wrote a short draft to discuss and document an operational issue
related to the ND state machine and packet loss caused by how routers
create ND cache entries for new host addressed:

https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/

(taking into account some vendors have implemented one of the proposed
solution already, I guess it's a well-known problem but it might still
worth documenting)

Comments are appreciated!

-- 
SY, Jen Linkova aka Furry

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Jul 2019 11:37:36 -0400

I think that the discussion here is particularly relevant to constrained
devices/routers on route-over MESH(RPL,etc.) networks.

I also think that for L=0 networks, which RPL creates with RPL DIO messages
rather than (just) RAs, and 6LRs that need to support join operations
(like draft-ietf-6tisch-minimal-security) this may matter.

In particular, in the minimal-security case, we need to partition the ND
cache such that untrusted (unverified) malicious pledge nodes can not
attack the ND cache.

The behaviour 2.2.1.  Host Sending Unsolicited NA, should probably
never flush an old entry out of the ND.  I think that under attack
(whether from untrusted pledges, or from p0woned devices already on the
network), it is better to prefer communication from existing nodes rather
than new ones.  2.2.1.2 mentions this.

{typo:
      -It's recommended that thsi functionality is configurable and
      +It's recommended that this functionality is configurable and
}

I didn't really understand 2.2.2: is it exploiting some corner case in the
spec, or maybe just some part I am not well clued in about.  So maybe an
extra paragraph to explain things.

I kinda like the ping all routers trick.

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

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

---

From: Fred Baker <[email-masked]>
Date: Tue, 2 Jul 2019 10:54:15 -0700

Thanks for this. As usual, Ron and I are looking for supportive commentary on the list in vetting agenda items. My big question at this point is whether (following Michael's lead) it belongs in v6ops, 6man, or 6lo. Operationally, do you see it in non-IOT-attacks?

> On Jul 2, 2019, at 8:03 AM, Jen Linkova <[email-masked]> wrote:
> 
> Hello,
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: 神明達哉 <[email-masked]>
Date: Tue, 2 Jul 2019 13:50:04 -0700

At Wed, 3 Jul 2019 01:03:11 +1000,

> https://datatracker.ietf.org/doc/draft-linkova-v6ops-nd-cache-init/

I've read ver 00 of the draft.  I see the problem it discusses is
worth considering.

Some specific comments on the draft follow.

- Section 2.2.1: I'm not sure if sending an unsolicited NA for an
  optimistic address really respects the sense of RFC4429 Section 2.2.
  The high level rationale of the restrictions is to avoid "disrupting
  disrupt the rightful owner of the address in the case of a
  collision."  Even if the RFC text does not explicitly prohibit that
  (as long as the override flag is cleared), if we allow to send such
  an unsolicited NA, it can result in the creation of a new neighbor
  cache entry for that address (actually, that's the purpose of it in
  the sense of this draft).  But what if there's actually a collision
  with another "rightful owner" of it?  Isn't it considered a kind of
  interference that Section 2.2 of RFC4429 tries to prevent?

  It may still be justifiable after some more detailed analysis, but I
  think we need more explicit discussion in this sense.

- Section 2.2.3.2

   o  Responding to RS with RA is not instant but delayed by a random
      interval.  Additional delay would compromise the idea of
      populating the routers ND cache before the return traffic to the
      host GUA arrives.

  I don't understand what's the problem here.  Does it assume the
  delay of sending RA in response to the RS means delaying the
  creation of the neighbor cache entry?  My interpretation of RFC4861
  is that the delay only applies to sending the RA.  When to create
  the neighbor cache entry is up to the router implementation but I'd
  expect it's normally upon receiving the RS.  At least one
  implementation that I know of behaves that way.

  Or, if this means something totally different than that, I have no
  idea about what's the problem, so more clarification would help
  anyway.

- Section 2.2.3.2

   o  Some wireless devices are known to fiddle with ND packets and
      perform various non-obvious forms of ND proxy actions.  In some
      cases unsoliciated NAs might not even reach the routers.

  I suspect you meant RS, not NA here.

--
JINMEI, Tatuya

---

From: Jen Linkova <[email-masked]>
Date: Wed, 3 Jul 2019 15:09:01 +1000

On Wed, Jul 3, 2019 at 3:54 AM Fred Baker <[email-masked]> wrote:
>
> Thanks for this. As usual, Ron and I are looking for supportive commentary on the list in vetting agenda items.

If you see enough comments, I'd like to present this. I guess I'd need
5 mins for explaining the problem and options for solutions and maybe
10 mins for discussion?

>My big question at this point is whether (following Michael's lead) it belongs in v6ops, 6man, or 6lo.

Well...IMHO it's in the grey area between v6ops and 6man. It's an
operational issue. Caused by ND state machine design (I'm really not a
fun of a situation when legitimate packets are dropped by design). The
solution might be in v6ops or in 6man - we can either say 'oh, just
let hosts ping the routers or tweak their probing logic' or we might
look at ND state machine to see if anything could be done there.

> Operationally, do you see it in non-IOT-attacks?

I have no experience and very, very limited knowledge of IOT area. I
do see it as an operational issue on IPv6-only WiFi.
I'd have never expected it but users do notice when it takes 5-10
seconds for their phones to start using WiFi. I'd be happy to consider
it a cosmetic issue ("everything will start working, just be patient"
but by number of complains it competes with 'Spotify client is broken'
one...
So I believe we shall at least  try.

---

From: Jen Linkova <[email-masked]>
Date: Wed, 3 Jul 2019 16:51:57 +1000

> (like draft-ietf-6tisch-minimal-security) this may matter.

Disclaimer: I have very limited knowledge in that area.

> cache such that untrusted (unverified) malicious pledge nodes can not

The next version of the draft will have much more details on
discussing the security considerations indeed.

> never flush an old entry out of the ND.

I'd say that the router behaviour for creating a STALE entry upon
receiving an unsolicited NA should be the same as for creating an
entry for any other reason (e.g. for receiving an RS with SLLAO).
The same safety rules shall apply.

> I think that under attack

I guess your routers do purge old stale entries?

>       +It's recommended that this functionality is configurable and

Thanks, will fix in -01.

> extra paragraph to explain things.

It's just using the standard ND process: when the node B receives an
NS from node A and that NS contains the node B  address as a target
address and SLLAO contains node A LLA,
the node B would respond with NA and would create a STALE entry for
the node A - https://tools.ietf.org/html/rfc4861#section-7.2.3

> I kinda like the ping all routers trick.

I think it's a hack ;( we do have a mechanism for communicating
neighbours addresses/reachability called ND. It would be nice to
utilise its machinery.
Pinging creates additional overhead on routers and could get filtered.
But I'd not be surprised if it's the only way we have realistically to
mitigate the issue..

---

From: Loganaden Velvindron <[email-masked]>
Date: Wed, 3 Jul 2019 10:58:37 +0400

Comments inline

On Tue, Jul 2, 2019 at 7:04 PM Jen Linkova <[email-masked]> wrote:

>From abstract:
user-visible connectivity issues when a new (not beeing seen on the
beeing->being.

--

---

From: Jen Linkova <[email-masked]>
Date: Wed, 3 Jul 2019 17:09:58 +1000

Jinmei-san,

Thanks a lot for your feedback.

>   interference that Section 2.2 of RFC4429 tries to prevent?

Very good point. Two things are probably worth considering here:
1) Actions prohibited in the Section 2.2 of RFC4429 (sending NS from
the optimistic address and sending RS with SLLAO) would both *update*
the ND cache entry if such entry
exists. So I guess the risk of potential disruption is higher. What
the draft suggests is only creating an entry if one does not exist
already (it would also update INCOMPLETE entry).
If the entry exists (for the "rightful owner" ) the only thing which
might happen is REACHABLE -> STALE change which should not disrupt the
traffic flow.
2) the case when a rightful owner of the address exist but there is no
ND cache entry would probably mean there is no (or minimal) disruption
anyway - as there is no traffic to that address. The only corner case
seems to me 'there is an incomplete entry so the router has started ND
process and now the new owner came".

>   think we need more explicit discussion in this sense.

Sure, I'll add more details in -01.

>   implementation that I know of behaves that way.

Ah, thanks for pointing that out. I somehow assumed that the delay
might affect the entry creation as well. I'll fix the text in -01.

>   I suspect you meant RS, not NA here.

Yep, copy-n-paste is to blame..

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 3 Jul 2019 08:13:34 +0000

Hello Michael

6LoWPAN ND is immune to the remote DOS attacks on the ND cache, the ones coming from the outside of the subnet, i.e., from a place that is out of touch and virtually nowhere.
This is because in an RFC 6775/8505-only network, there is no reactive operation, a packet coming from the outside of the subnet for a node that is not registered to the router is just dropped. Just like an AP does not copy a packet on the wireless for a MAC that is not associated.

I'm baffled that the reactive ND is still the official technique for IPv6 lookup at 6MAN. The operations that you have to do in an enterprise-class router on a data packet, punt the packet to software, run ND, program the hardware, protect ND cache and CPU against DOS, are just from another age. So we have to run our own things (e.g., a LISP MSMR) on our fabrics when modernizing ND would do the trick in a standard fashion (see draft-thubert-6lo-unicast-lookup) .

Your point below remains correct, since the attack you describe is from a node that reaches the router at L2. Arguably, that attack is physically much harder to perform than the DOS packet from outer space.

All the best,

Pascal

> -----Original Message-----
> From: 6lo <[email-masked]> On Behalf Of Michael Richardson
> Sent: mardi 2 juillet 2019 17:38
> To: [email-masked]; Jen Linkova <[email-masked]>; [email-masked]
> Cc: V6 Ops List <[email-masked]>; 6man <[email-masked]>
> Subject: Re: [6lo] ND cache entries creation on first-hop routers
> 
> 
> rather than (just) RAs, and 6LRs that need to support join operations (like
> draft-ietf-6tisch-minimal-security) this may matter.
> 
> In particular, in the minimal-security case, we need to partition the ND cache
> such that untrusted (unverified) malicious pledge nodes can not attack the ND
> cache.
> 
> The behaviour 2.2.1.  Host Sending Unsolicited NA, should probably never flush
> an old entry out of the ND.  I think that under attack (whether from untrusted
> pledges, or from p0woned devices already on the network), it is better to
> prefer communication from existing nodes rather than new ones.  2.2.1.2
> mentions this.
> 
> {typo:
>       +It's recommended that this functionality is configurable and }
> 
> I didn't really understand 2.2.2: is it exploiting some corner case in the spec, or
> maybe just some part I am not well clued in about.  So maybe an extra
> paragraph to explain things.
> 
> Michael Richardson <[email-masked]>, Sandelman Software Works  -
> = IPv6 IoT consulting =-
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 3 Jul 2019 08:18:34 +0000

Hello Jen

The routers that Michael is talking about are real routers, deployed in large volumes in the field, e.g., in Smartgrid networks. 
They are not running ND as RFC 4861/4862 but as RFC 6775/8505, and then operate RPL routing within the ML subnet.
It would be great to have a section that describes that new ND operation and shows how it changes the deal. I'd be happy to help you on that if you need.
There are some hints in https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/.

All the best,

Pascal

> From: 6lo <[email-masked]> On Behalf Of Jen Linkova
> Sent: mercredi 3 juillet 2019 08:52
> To: Michael Richardson <[email-masked]>
> Cc: [email-masked]; 6man <[email-masked]>; V6 Ops List <[email-masked]>;
> [email-masked]
> > I think that the discussion here is particularly relevant to
> > constrained devices/routers on route-over MESH(RPL,etc.) networks.
> >
> > I also think that for L=0 networks, which RPL creates with RPL DIO
> > messages rather than (just) RAs, and 6LRs that need to support join
> > operations (like draft-ietf-6tisch-minimal-security) this may matter.
> 
> > In particular, in the minimal-security case, we need to partition the
> > ND cache such that untrusted (unverified) malicious pledge nodes can
> > not attack the ND cache.
> 
> The next version of the draft will have much more details on discussing the
> security considerations indeed.
> 
> I'd say that the router behaviour for creating a STALE entry upon receiving an
> unsolicited NA should be the same as for creating an entry for any other
> reason (e.g. for receiving an RS with SLLAO).
> > (whether from untrusted pledges, or from p0woned devices already on
> > the network), it is better to prefer communication from existing nodes
> > rather than new ones.  2.2.1.2 mentions this.
> 
> > I didn't really understand 2.2.2: is it exploiting some corner case in
> > the spec, or maybe just some part I am not well clued in about.  So
> > maybe an extra paragraph to explain things.
> 
> It's just using the standard ND process: when the node B receives an NS from
> node A and that NS contains the node B  address as a target address and
> SLLAO contains node A LLA, the node B would respond with NA and would
> create a STALE entry for the node A -
> https://tools.ietf.org/html/rfc4861#section-7.2.3
> 
> I think it's a hack ;( we do have a mechanism for communicating neighbours
> addresses/reachability called ND. It would be nice to utilise its machinery.
> But I'd not be surprised if it's the only way we have realistically to mitigate the
> issue..
> 
> >
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 3 Jul 2019 21:43:44 +0900

I would definitely like to see this issue discussed in Montreal. Actually I
think the primary motivating factor for this draft was not in the IOT
space, but operational issues observed with mobile hosts (phones, laptops)
just after they connect to an IPv6-only network. This unforeseen
consequence of the specifications causes common implementations to be much
slower in determining Internet connectivity on IPv6-only networks than on
networks with IPv4.

The reason this works in IPv4 is that in IPv4 there is only one address. So
when the host ARPs for the router for the first time, the router puts the
host's address in its ARP cache, the return ND cache entry is already
primed. This does not work in IPv6 the only packets that go directly to the
router come from the host's link-local address, not the global addresses
that the host is using to talk off-link.

I think this document belongs in v6ops, at least initially. It fits
squarely within the charter of finding operational problems with the IPv6
specifications.

On Wed, Jul 3, 2019 at 2:54 AM Fred Baker <[email-masked]> wrote:

> Thanks for this. As usual, Ron and I are looking for supportive commentary
> on the list in vetting agenda items. My big question at this point is
> whether (following Michael's lead) it belongs in v6ops, 6man, or 6lo.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 3 Jul 2019 21:54:14 +0900

On Wed, Jul 3, 2019 at 5:14 PM Pascal Thubert (pthubert) <[email-masked]>
wrote:

> 6LoWPAN ND is immune to the remote DOS attacks on the ND cache, the ones
> coming from the outside of the subnet, i.e., from a place that is out of
> touch and virtually nowhere.
> This is because in an RFC 6775/8505-only network, there is no reactive
> operation, a packet coming from the outside of the subnet for a node that
> is not registered to the router is just dropped. Just like an AP does not
> copy a packet on the wireless for a MAC that is not associated.
>

There are problems with registration-based models as well though.

First, complexity. Recovering state in the presence of router crashes is
complex. Also, depending on what guarantees the network needs to provide to
hosts, a registration-based model will likely use more router memory in the
common case that most hosts are well-behaved (because it cannot
aggressively time out entries that with classic ND can simply be thrown
away after a while).

Second, an explicit registration model where the router can refuse to
create an address entry provides a supported path for operators to limit
the number of IP addresses used by hosts, which has the negative
consequences described in RFC 7934. In fact, such a model is explicitly NOT
RECOMMENDED by RFC 7934 for general-purpose hosts. The relevant text is "it
is RECOMMENDED that the network give the host the ability to use new
addresses without requiring explicit requests."

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 3 Jul 2019 12:54:53 +0000

Hello Jen:

In Introduction:
"(previously unseen by the router)"
Another case is that the cache may have been flushed. The same issue will happen again.

In 2.2.3.2:
"
o Would not work for the host optimistic addresses ((see section 2.2
of [RFC4429] which prohibits using an Optimistic Address as the
source address of a Router Solicitation with a SLLAO.
"
The "would not work" is exaggerated since the behavior of the router c/should be to lookup the source of the RS to answer with a unicast RA. 
Some old implementations would always answer with a broadcast RA but hopefully things have evolved with the realization that broadcast may have its own issues, in particular with wireless and overlays. So this technique may work if the router responds unicast and the optimistic node also introduces a small delay before firing its probes to cover for the RA delay. 

In 3. Recommendations
I do not agree with the recommendation, because:
-  the host has no control or guarantee about whether the router will maintain the cache and for how long
-  multicast NA may be lost, more chances of that if the router is wireless. You may want something a bit more robust with an acknowledgement and a lifetime, see RFC 8505. 
- the all-routers is still a L2 broadcast on Ethernet and Wi-Fi. We are actually trying to deprecate the NA(O) at the end of the autoconf sequence.
- the proposed knob would have the routers learn all addresses of all hosts including those that do not get traffic from that router. This augments the chances of cache saturation, which recreates the problem you want to avoid.

Also note that the fiddling smart wireless well as smart fabrics may learn the location of the address from snooping the ND activity (see https://tools.ietf.org/html/draft-bi-savi-wlan). A sense if order of events like a sequence counter / time stamp is important for devices that move quickly. See for instance the discussion in https://tools.ietf.org/html/draft-ietf-rift-rift-06#section-5.3.3.1 .

All in all there' s a limit to stretching old designs and a time where a new one is needed. Ask plane makers...

All the best,

Pascal

> From: v6ops <[email-masked]> On Behalf Of Jen Linkova
> Sent: mardi 2 juillet 2019 17:03
> To: V6 Ops List <[email-masked]>
> Cc: 6man <[email-masked]>
> Subject: [v6ops] ND cache entries creation on first-hop routers
> 
> Hello,
> 
> I wrote a short draft to discuss and document an operational issue related to
> the ND state machine and packet loss caused by how routers create ND cache
> entries for new host addressed:
> 
> solution already, I guess it's a well-known problem but it might still worth
> documenting)
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 3 Jul 2019 22:00:40 +0900

On Wed, Jul 3, 2019 at 9:56 PM Pascal Thubert (pthubert) <[email-masked]>
wrote:

> -  multicast NA may be lost, more chances of that if the router is
> wireless. You may want something a bit more robust with an acknowledgement
> and a lifetime, see RFC 8505.
>

Not true on wifi. Multicast packets are always sent to the AP as unicast.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 3 Jul 2019 13:07:29 +0000

You are correct, and I said ” more chances if the router is wireless” meaning that the router is on the STA side or a L3 wireless bridge.

All the best,

Pascal

From: Lorenzo Colitti <[email-masked]>
Sent: mercredi 3 juillet 2019 15:01
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Jen Linkova <[email-masked]>; V6 Ops List <[email-masked]>; 6man <[email-masked]>
Subject: Re: [v6ops] ND cache entries creation on first-hop routers

On Wed, Jul 3, 2019 at 9:56 PM Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
-  multicast NA may be lost, more chances of that if the router is wireless. You may want something a bit more robust with an acknowledgement and a lifetime, see RFC 8505.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 3 Jul 2019 13:39:59 +0000

Hi again Lorenzo,

First, complexity. Recovering state in the presence of router crashes is complex.

  *   True; so far we have not designed for the case where the router dies and no-one knows. In the fabric models, the router relays to a central mapping system that it can query later. The case of an intermediate network could be addressed e.g., with a RA(I’m back), an interesting subject if 6MAN takes over the work. Compare this with the case where the router crashes, loses all ND caches, and has 100s of flows through for which a full ND operation (punt, lookup, program) must be done on the first packet.

Also, depending on what guarantees the network needs to provide to hosts, a registration-based model will likely use more router memory in the common case that most hosts are well-behaved (because it cannot aggressively time out entries that with classic ND can simply be thrown away after a while).

Ø    The router can reject a registration if out of memory and the node needs to register somewhere else or free an old registration of his. At least the use of memory is deterministic. Compare this with an ND cache that has less room than the active flows, LRU will create a permanent situation of flush/lookup.

Second, an explicit registration model where the router can refuse to create an address entry provides a supported path for operators to limit the number of IP addresses used by hosts, which has the negative consequences described in RFC 7934. In fact, such a model is explicitly NOT RECOMMENDED by RFC 7934 for general-purpose hosts. The relevant text is "it is RECOMMENDED that the network give the host the ability to use new addresses without requiring explicit requests."

Ø  The router can always refrain from creating an NCE if it does not want to, e.g., by policies that protect the ND cache. The registration does not create that situation. Thanks to your contribution, RFC 8505 SHOULDs conformance to RFC 7934 and has “The ability to return errors to address registrations is not intended to be used to restrict the ability of hosts to form and use multiple addresses. “. The rest is in the hands of the network admins, make sure they deploy resources adequately.

Cheers;

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Jul 2019 14:29:52 -0400

> look at ND state machine to see if anything could be done there.

It's not an IoT issue, it's just that constrained 6LRs have significantly
(orders of magnitude) fewer NC entries than typical routers, so we have
greater concerns.  If we can fix the ND state machine in some way, it
would likely help.

    > So I believe we shall at least  try.

So, you didn't answer the question ;-)
Are we seeing neigh-cache exhaustion attacks on IPv6 capable WIFI today?
5-10 seconds seems really high... it is really explained by just the
pathology you described?  Is it because the probes are not retried soon
enough after the first set failed?  Or is it because there are NC exhaustion?

In the IoT context, a sleepy device that wakes up and wants to do an
exchange out to the Internet, would benefit from anything that puts the
neigh cache entries in place faster.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Jul 2019 14:59:18 -0400

> the node A - https://tools.ietf.org/html/rfc4861#section-7.2.3

I read through https://tools.ietf.org/html/rfc4861#section-7.3.3
and it says:

   The first time a node sends a packet to a neighbor whose entry is
   STALE, the sender changes the state to DELAY and sets a timer to
   expire in DELAY_FIRST_PROBE_TIME seconds.  If the entry is still in
   the DELAY state when the timer expires, the entry's state changes to
   PROBE.  If reachability confirmation is received, the entry's state
   changes to REACHABLE.

   Upon entering the PROBE state, a node sends a unicast Neighbor
   Solicitation message to the neighbor using the cached link-layer
   address.  While in the PROBE state, a node retransmits Neighbor
   Solicitation messages every RetransTimer milliseconds until
   reachability confirmation is obtained.  Probes are retransmitted even
   if no additional packets are sent to the neighbor.  If no response is
   received after waiting RetransTimer milliseconds after sending the
   MAX_UNICAST_SOLICIT solicitations, retransmissions cease and the
   entry SHOULD be deleted.  Subsequent traffic to that neighbor will
   recreate the entry and perform address resolution again.

Is PROBE and DELAY different states? It almost feels like a typo here.

    > But I'd not be surprised if it's the only way we have realistically to

Yes, it's a hack.  It leverages existing behaviour, can be deployed
unilaterally by mobile phone makers, and does not require any new state in
the end device, as they don't even have to listen for the ECHO REPLY.

Let me suggest a different hack: use stateful DHCPv6.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Jul 2019 15:11:31 -0400

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > 6LoWPAN ND is immune to the remote DOS attacks on the ND cache, the
    > ones coming from the outside of the subnet, i.e., from a place that is
    > out of touch and virtually nowhere.

    > operation, a packet coming from the outside of the subnet for a node
    > that is not registered to the router is just dropped. Just like an AP
    > does not copy a packet on the wireless for a MAC that is not
    > associated.

There are a few attacks on the ND cache that I can think of.
One of them that we see on the IETF network is the script kiddies who
sequentially scan IP addresses.  We have a lot of them, and so we flood the
wifi with ARP queries (v4) and NS (v6).  We have mitigations for this.

In the route-over 6tisch/RPL space, we don't (as you indicate), use NS by the
router, we know who is on our network, and we would just have no /128 routes,
and just drop the packets.  Is this the attack that you are speak of as a
remote DOS?

    > Your point below remains correct, since the attack you describe is from
    > a node that reaches the router at L2. Arguably, that attack is
    > physically much harder to perform than the DOS packet from outer
    > space.

When I mentioned attacks on the ND cache, I am referring to those that can
occur from within the 6tisch network from malicious pledge nodes.  We have to
limit the NCE usage by untrusted nodes so that we have space for as many
registered nodes.
I think you are agreeing with me above.

I believe that the issue that Jen is describing would for unaware leaves that
were sleepy.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 4 Jul 2019 08:38:35 +1200

On 03-Jul-19 20:13, Pascal Thubert (pthubert) wrote:

...
> I'm baffled that the reactive ND is still the official technique for IPv6 lookup at 6MAN.

How can it be otherwise when a node can give itself a new address at any time without notice?

I'm not arguing with you about RFC 6775/8505 networks, but that doesn't apply everywhere.

    Brian

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 3 Jul 2019 20:50:20 +0000

Hello Michael 

Please see below 

> and just drop the packets.  Is this the attack that you are speak of as a

Yes, 

Scanning in v6 can hardly be used to discover addresses but it can be used as a DOS attack against the CPU because the silicon needs to punt on cache miss. It can also be used to DOS the neighbor cache. And it is hard to differentiate from legitimate new traffic.

The possibility for such an attack comes from the reactive nature of ND, which was designed when IP routing was in software and the network a happy Woodstock. Times have changed and a modern ND should protect itself and the addresses it manages (think SeND and SAVI) and should be friendly to fabrics, to wireless and to hardware forwarders. We have that on tiny devices but it’s still missing in the big irons.

> I think you are agreeing with me above.

Yes I certainly followed you there and agree. We had that discussion for 6TiSCH minimal security. My point was that this local DOS attack requires a physical presence and is much harder to achieve than the remote DOS.

> I believe that the issue that Jen is describing would for unaware leaves that

Unaware Leaves that follow the ROLL specs register their addresses and sleep. They can sleep for the whole lifetime of their registration, the router will maintain an ND entry and the network will protect the address ownership.
To your point the node must wake up and refresh the registration before it expires.

What’s left of Jen’s issue with registration is the asymmetrical routing. In the ROLL specs the router that has the registration injects the route in the MLSN and gets the traffic back so the issue does not exist. In a transit network the router would forward the registration state to a 6LBR that can answer unicast lookups from other routers, still incurring a delay, or may push a state to other routers or to a load balancer so the router with the registration gets the traffic first.

All the best,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 3 Jul 2019 21:03:15 +0000

Sorry Brian I miss your point.

The discussion here is to find a way for the node to autoconf an address and then notice the router(s) proactively so the ND NCE is ready when the first packet comes from the outside for this node.

I agree wholeheartedly with Jen’s requirement.

I agree less with the idea of overstretching ND as it stands to achieve this, for reasons I gave already. So prepopulate the NCE, yes, but do it right with protocol elements that guarantee a state that is accurate, secure, and persistent for a committed lifetime, not with yet another patch to the old structure.

I’m interested to have a parallel discussion on where RFC 8505 can not apply. In the products and use cases I’m aware of, it could, since we are actually faking it by snooping ND and DHCP to achieve similar but less accurate results.

Take care,

Pascal

> Le 3 juil. 2019 à 22:39, Brian E Carpenter <[email-masked]> a écrit :
>

---

From: 神明達哉 <[email-masked]>
Date: Wed, 3 Jul 2019 15:26:58 -0700

At Wed, 3 Jul 2019 17:09:58 +1000,

> >   optimistic address really respects the sense of RFC4429 Section 2.2.
[...]
> might happen is REACHABLE -> STALE change which should not disrupt the

Right.

> process and now the new owner came".

Or some external (off-link) nodes voluntarily sends packets to that
address through the router after the creation of the neighbor cache
entry due to the unsolicited NA (but not before that).  Without the NA
the packets should go to the "rightful owner" of the address, but they
are now forwarded to the node using the optimistic address.

--
JINMEI, Tatuya

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 4 Jul 2019 07:40:16 +0900

> Let me suggest a different hack: use stateful DHCPv6.

DHCPv6 doesn't fix this because a) DHCP goes to a server, not the router,
b) DHCPv6 uses link-local addresses and not the global addresses, c) there
is nothing in the DHCPv6 specs about explicitly populating ND caches.

For off-link servers, the router can perform layering violations such as
"snoop DHCPv6 replies and add them to the neighbour cache". But such
layering violations don't require DHCPv6. For example, the router can also
snoop DAD packets, or glean ND cache entries from forwarded packets.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 4 Jul 2019 11:20:00 +1200

> I agree wholeheartedly with Jen’s requirement.

Yes, I am not against satisfying this requirement, but we have a considerable legacy of stacks that don't do this - so until that legacy has vanished, the routers need to deal with it somehow.

> I’m interested to have a parallel discussion on where RFC 8505 can not apply. In the products and use cases I’m aware of, it could, since we are actually faking it by snooping ND and DHCP to achiev…

So if you are advocating a generalisation of RFC8505 to non-6lo LANs, that's certainly a discussion we could have, IMHO.

Regards
    Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Jul 2019 20:57:44 -0400

Brian E Carpenter <[email-masked]> wrote:
    >> I’m interested to have a parallel discussion on where RFC 8505 can not
    >> apply. In the products and use cases I’m aware of, it could, since we
    >> are actually faking it by snooping ND and DHCP to achieve similar but
    >> less accurate results.

    > So if you are advocating a generalisation of RFC8505 to non-6lo LANs,
    > that's certainly a discussion we could have, IMHO.

I think that it could be applied in situations of servers, such as data
centers where there are multiple tenants. (Many VM infrastructures have
shared front-end networks)

I think that temporary addressess are not a feature in some of those
deployments that everyone wants, and thus having a registration system is a
feature.

This does not solve the smartphone on new WIFI issue, which is a different
situation completely.

--
]               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: Jen Linkova <[email-masked]>
Date: Fri, 5 Jul 2019 13:32:29 +1000

Hi Pascal,

> There are some hints in https://datatracker.ietf.org/doc/draft-thubert-6man-ipv6-over-wireless/.

Oh, that's an interesting plot twist ;) Migrating from 4861/4862 to 6775/8505?
Sounds like smth we might want to explore as a strategy (while the
tactical fixes my draft mostly talks about might be still needed too).
I'll re-read RFCs  6775/8505 and will be back to you with some
questions later..Thanks for the suggestion!

---

From: Jen Linkova <[email-masked]>
Date: Fri, 5 Jul 2019 15:28:48 +1000

Hi Pascal,

> Another case is that the cache may have been flushed. The same issue will happen again.

I'll update the sentence to include that case as well.

> The "would not work" is exaggerated

What I meant is that it's devices are prohibited to do so by RFC4429.
I'll rephrase it.

>since the behavior of the router c/should be to lookup the source of the RS to answer with a unicast RA.

If the RS does not contain SLLAO, yes.
However in that case I'm not sure if the delay in sending the RA would
impact the cache entry creation (the issue we discussed with
Jinmei-san in this thread).
Thanks for pointing this out, I'll update the text to discuss both
options - with and w/o SLAAO included in RS.

> Some old implementations would always answer with a broadcast RA but hopefully things have evolved with the realization that broadcast may have its own issues, in particular with wireless and overlays.

Most enterprise-scale router vendors support rfc7772 now, so I hope
that unicast solicited RA is less of a problem nowadays..

>So this technique may work if the router responds unicast and the optimistic node also introduces a small delay before firing its probes to cover for the RA delay.

Yes, that's the concern. I'll update the text accordingly, thanks!

> - the proposed knob would have the routers learn all addresses of all hosts including those that do not get traffic from that router. This augments the chances of cache saturation, which recreates…

Hmm...In the scenario I'm thinking about (a WiFi segment in an
enterprise network, for example) all hosts are getting traffic from
all routers.
You are right it might get tricky in multihomed/mPVD case.
What should be noted here is that at least one major router vendor has
this knob implemented and it's actively used AFAIK. So having a knob
has been proved useful - it does not have to be a sole solution
through..

> Also note that the fiddling smart wireless well as smart fabrics may learn the location of the address from snooping the ND activity (see https://tools.ietf.org/html/draft-bi-savi-wlan). A sense if…

Thanks for the references, I'll check them out!

> All in all there' s a limit to stretching old designs and a time where a new one is needed. Ask plane makers...

It seems like we might do two things here:
- explore the option of using RFC8505 (strategic solution);
- have some tactical workarounds to deal with legacy hosts.

---

From: Jen Linkova <[email-masked]>
Date: Fri, 5 Jul 2019 16:06:23 +1000

> Are we seeing neigh-cache exhaustion attacks on IPv6 capable WIFI today?

Good question. I guess some people might. I'd suspect that IPv6
attacks are not very common still but it will change eventually.
Enterprise networks could see less of ND-exhaustion attacks because
many of those networks have stateful firewalls in front of the
first-hop routers.

> pathology you described?

Yes, because as soon as the NC entry appears in the router cache the
issue goes away. So users normally complain if they have not connected
the particular device to the network for a while.

> Is it because the probes are not retried soon enough after the first set failed?

Some probers have an exponential backoff.
https://tools.ietf.org/html/draft-linkova-v6ops-nd-cache-init-00#section-2.4

>Or is it because there are NC exhaustion?

No, there is no exhaustion. At least in the cases I've observed so far.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 5 Jul 2019 07:16:44 +0000

Hello Jen

> I'll update the sentence to include that case as well.

Please note that the problem behind the problem is that the host does not know when the router flushes the cache.
=> whatever trick the host plays to preload the cache at the time it creates the address cannot fix the issue that reappears asynchronously upon cache flush.

Bottom line is we want a contract between the host and the router; the router accepts to store the NCE for a guaranteed lifetime, renewable. 
Once you embrace that model, the host can go to sleep, or connect to the wireless in a dotted line to save power, the router will be able to protect the address and do tons of services like sleeping proxy, ND Proxy, route injection, feed a mapping server, you name it, for the duration of the contract.

Note that it is still SLAAC, not DHCP: the host is in control, the router only protects itself against overuse. As always there is a tension between extreme privacy and the quality of the services that can be offered when the server has information about the client. Here we're talking about the first hop router / L3-AP / L3-switch, and we are talking about generic device capabilities like wireless, power-concerned, not really leaking a bank account on the internet.

> > of [RFC4429] which prohibits using an Optimistic Address as the source
> > address of a Router Solicitation with a SLLAO.
> > "
> However in that case I'm not sure if the delay in sending the RA would impact
> the cache entry creation (the issue we discussed with Jinmei-san in this
> thread).
> Thanks for pointing this out, I'll update the text to discuss both options - with
> and w/o SLAAO included in RS.
> 
> > Some old implementations would always answer with a broadcast RA but
> hopefully things have evolved with the realization that broadcast may have its
> own issues, in particular with wireless and overlays.
> 
> Most enterprise-scale router vendors support rfc7772 now, so I hope that
> unicast solicited RA is less of a problem nowadays..
> 
> >So this technique may work if the router responds unicast and the optimistic
> node also introduces a small delay before firing its probes to cover for the RA
> delay.
> 

There's a depiction of this in https://datatracker.ietf.org/doc/html/draft-ietf-6lo-backbone-router#section-3.2 figure 2 in the context of RFC 8505. 

The RFC 8505 piece can be partially emulated by snooping ND, that's what we do today. It mostly works. RFC 8505 removes the "mostly", at least for the issues that we found over the 5+ years we've been shipping this trick. https://tools.ietf.org/html/draft-bi-savi-wlan is informative because it hints on what vendors actually do that may become interop trouble in the future. But experience says we'd rather leave it as a draft.

In that figure 2, the 6BBR is the L3-AP. The 6LBR is an optional mapping server that enables services like unicast lookups and overlays. The scenario is based on the "Tokyo Station" use case (see IEEE std 802.11ai aka FILS) where the traffic must start virtually instantly. The IEEE did its piece, but for the reasons that you discuss in the draft, and for the lack of ODAD, IPv6 may delay the access by more than one second. So, as you describe, we want ODAD, and we want to prepopulate the ND cache in the router.

> > -  multicast NA may be lost, more chances of that if the router is wireless.
> You may want something a bit more robust with an acknowledgement and a
> lifetime, see RFC 8505.
> > - the all-routers is still a L2 broadcast on Ethernet and Wi-Fi. We are actually
> trying to deprecate the NA(O) at the end of the autoconf sequence.
> 
> > - the proposed knob would have the routers learn all addresses of all hosts
> including those that do not get traffic from that router. This augments the
> chances of cache saturation, which recreates the problem you want to avoid.
> 
> Hmm...In the scenario I'm thinking about (a WiFi segment in an enterprise
> network, for example) all hosts are getting traffic from all routers.
> What should be noted here is that at least one major router vendor has this
> knob implemented and it's actively used AFAIK. So having a knob has been
> proved useful - it does not have to be a sole solution through..
> 
> > Also note that the fiddling smart wireless well as smart fabrics may learn the
> location of the address from snooping the ND activity (see
> https://tools.ietf.org/html/draft-bi-savi-wlan). A sense if order of events like a
> sequence counter / time stamp is important for devices that move quickly. See
> for instance the discussion in https://tools.ietf.org/html/draft-ietf-rift-rift-
> 06#section-5.3.3.1 .
> 

Yes, we have to design for long term coexistence. 

At Cisco, we've based our work-arounds on snooping and that's controlled by the router not the host. Being on the router side we know if the SLAAC address conflicts with an existing cache entry and if not, we can create what we call a binding cache entry based on the source MAC of ND packets (meaning even if there is no SLAAO). We can even have that triggered by data traffic. Then again, those are tricks that rely on side effects, just like the solutions that your draft proposes. They are less efficient on wireless because of loss and movement. And we cannot fully eliminate the reactive broadcasts; that will remain true as long as there is coexistence.

But then, the more hosts support RFC 8505 the less broadcasts everybody will get. This serves the community by saving energy not only for wireless host but over the whole L2 infra (think fabrics). I'd expect that smartphone manufacturers be quite sensitive to the "Tokyo Station" scenario as well. The effort to implement the client side of RFC 8505 does not seem so huge that it would take years to get it in the next version of the major smartphone OSes. Just that would be a quantum leap for the experience by IPv6 users.

All the best,

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Fri, 05 Jul 2019 15:07:37 -0400

> the particular device to the network for a while.

So let me ask the question differently: why is it taking 5-10 seconds for the
NC entry to appear?

Let me repeat what you wrote in my own words:

1) device gets online, gets address via RA, uses SLAAC/RFC4941, configures
   addr Q.  I don't think it matters if the device sees a multicast RA,
   or solicits one with a RS.
   The device also does DAD here.

2) device sends TCP SYN to "does this work" test A via router X.
   (http://detectportal.firefox.com/, etc.)

3) respond from A arrives at X, no NCE exists, sends out NS for Q, router X
   tries to buffer it, but since there are many devices, the reply gets
   dropped.

4) device answers NS with NA unicast to X, NCE is created.  No packet
   is released, since there isn't one.

  <delay>

5) device eventually retransmits TCP SYN to test A via router X.
6) reply gets back to Q since NCE exists.

It has been asserted above that as soon (4) occurs, that it's all good.
I'm skeptical, wondering isn't it (5) that is the key point.

So I assume that I mis-understand something about how things work.

---

From: Mark Smith <[email-masked]>
Date: Sat, 6 Jul 2019 10:58:33 +1000

> So I assume that I mis-understand something about how things work.

This is what is going to be happening, however the queue of 1 ND
trigger packet isn't big enough anymore. From what Jen has described
in her draft, nodes are attempting to establish far more than one
connection when they first attach to a link.

The problem occurring isn't really a new one. Cisco's original IOS ARP
implementation doesn't buffer any packets all that trigger an ARP
Request, which is why it is common to see the first packet lost when
e.g. pinging a destination behind a newly booted router. It would also
explain why IOS holds onto ARP entries for 4 hours, rather than the
more typical 5 minutes. RFC 1122 permits this behaviour although
advises against it.

A form of address registration is the only way to overcome this, and
also will completely mitigate router ND cache DoS attacks from
off-link sources. Host implementations would have to delay allowing
applications to attempt to establish connections until address
registration is confirmed.

Regards,
Mark.

---

From: Jen Linkova <[email-masked]>
Date: Sat, 6 Jul 2019 14:06:52 +1000

> So let me ask the question differently: why is it taking 5-10 seconds for the

I'm not saying it takes 5-10 secs for the NC entry to appear. It takes
5-10 secs for applications to receive all traffic they want (with
timeouts, retransmits and exponential backoffs)

>    (http://detectportal.firefox.com/, etc.)

Device might open multiple parallel connections to various destinations.

>    tries to buffer it, but since there are many devices, the reply gets

or because there are many packets arriving for Q - so the router
buffers the first one only.

>    is released, since there isn't one.

...or it's just one instead of many.

> It has been asserted above that as soon (4) occurs, that it's all good.

No, it's all good if (4) becomes (2.5) and happens *before* (3). So
when the packets arrive the router has the NC entry already - at least
in STALE state.

> I'm skeptical, wondering isn't it (5) that is the key point.

It is. As soon as (4) happens before (3), there is no delay and (5)
does not happen.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 06 Jul 2019 17:31:44 -0400

> when the packets arrive the router has the NC entry already - at least

Right, and that's what you are attempting to add.

    > It is. As soon as (4) happens before (3), there is no delay and (5)

I'm glad that my understanding of the problem is correct.

Back to the question of your solutions, and wondering what things can be done
unilaterally, and what actions require coordination to get any effect.

> 2.3.1: Host Sending Unsolicited NA.
Do any hosts do this already?  It seems that this would be a good thing to do
unilaterally.  This has a small airtime impact, but nothing compared to
retransmitting packets, I'd think.  Maybe there is a privacy impact if the
host sends an Unsolicited NA for a privacy address that it hasn't started
using yet.

It doesn't help unless routers start acting on them though, but you
note that this seems to already be implemented in some platforms.

>      cases unsolicited NAs might not even reach the routers.

so it might not work in some situations, and there little handset makers can
do.  That wifi network will just appear to suck.  I would love to have
automated, unspammable yelp for wifi networks...

> 2.3.2.  Host Sending NS to the Router Address from Its GUA

This seems to require no innovation (no new code on routers), but can't be
done until the address is out of the Optimistic State, so it takes longer.
Can this method be *combined* with 2.3.1?

> 2.3.3.  Host Sending Router Solicitation from its GUA

Also no new code on routers, same time restriction as 2.3.2, but reaches all
routers.  Can this method be combined with 2.3.1?  Seems like it is better
than 2.3.3