Subject: Benjamin Kaduk's No Objection on draft-ietf-6man-grand-05: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 30 Jun 2021 10:16:57 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6man-grand-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-grand/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the comprehensive and systematic analysis of the approach
selected, as well as the discussion of approaches not selected!

Section 1

   return traffic flow.  While waiting for the resolution to complete
   routers only keep a very small number of packets in the queue, as
   recommended in Section 7.2.2 [RFC4861].  All subsequent packets
   arriving before the resolution process finishes are likely to be
   dropped.  [...]

My reading of RFC 4861 is that it suggests for new packets arriving to
replace the oldest entry in this queue of packets, which doesn't really
seem consistent with "all subsequent packets [...] are likely to be
dropped".  "Any additional packets arriving before the resolution
process finishes are likely to result in dropped packets" might be more
consistent with the RFC 4861 guidance.

Section 2

                                      As per Section 7.2.2 of [RFC4861]
       Routers MUST buffer at least one data packet and MAY buffer more,
       while resolving the packet destination address.  However most
       router implementations limit the buffer size to a few packets
       only, so all subsequent packets for the host global address are
       dropped, until the address resolution process is completed.

[same as above re "subsequent"]

   router's neighbor cache.  However, the same sequence of events happen
   when the host starts using a new global address previously unseen by
   the router, such as a new privacy address [RFC4941] or if the
   router's Neighbor Cache has been flushed.

RFC 4941 has been obsoleted by RFC 8981.

Section 3

   o  If the router does not have a Neighbor Cache entry for the
      address, a STALE entry needs to be created.

(editorial) The lead-in to this list leaves me unclear about when it's
desired for this entry to be created.  The conditional nature of this
statement suggests that creating as a result of receiving the first
packet for that address might be okay, but I don't think that's actually
the intent.

Section 4.1

   To minimize the potential disruption in case of duplicate addresses
   the node should not set the Override flag for a preferred address and
   must not set the Override flag if the address is in Optimistic
   [RFC4429] state.

I suggest adding "preferred address" to the terminology list (with RFC
4862 reference).

   It should be noted that the proposed mechanism does not cause any
   significant increase in multicast traffic.  The additional multicast
   unsolicited NA would proactively create a STALE cache entry on
   routers as discussed below.  When the router receives the return
   traffic flows it does not need to send multicast NSes to the
   solicited node multicast address but would be sending unicast NSes
   instead.  Therefore the total amount of multicast traffic should not
   increase.

Hmm, I might frame this as "this procedure would only produce an
increase in the overall amount of multicast traffic if no return traffic
arrives to the node that sent the unsolicited NA".

Section 4.2

   This document updates [RFC4861] so that routers create a new Neighbor
   Cache entry upon receiving an unsolicited Neighbor Advertisement.

I'd suggest "upon receiving an unsolicited Neighbor Advertisement for an
address that does not already have a Neighbor Cache entry".

Section 5.2

   However most likely those packets would have been dropped anyway:
   creating the INCOMPLETE entry is usually triggered by traffic, so the
   router probably has some packets in the buffer already, dropping
   subsequent packets received before the address resolution is
   completed.

I *think* the packet-dropping scenario here is the same one that I
mentioned previously in the context of "subsequent packets" (not) being
dropped, involving the very small queue on the router of packets to an
address waiting for resolution.  If so, I might suggest a phrasing such
as "the creation of the INCOMPLETE entry is usually triggered by inbound
traffic, and due to the limited queue size on the router for packets
directed to addresses that are waiting for resolution, most packets
arriving prior to the solicited NA would be dropped anyway".

Section 5.3.1

As a thought experiment, I tried comparing this scenario to a similar
one where the host uses optimistic DAD but does not send an unsolicited
NA.  In that case, it seems like the optimistic traffic would go out,
and when the return traffic arrives the router would create a STALE
entry and do full discovery to find the original owner of the address,
so some of the responses to the optimistic (probe) traffic might make it
to the original owner of the address.  That's in contrast to this
scenario where the return traffic goes to the host that triggered it.
IIUC in both cases we rely on the host properly doing DAD to stop using
the optimistic address, and so the scenarios do seem pretty similar
overall.

Section 6.1.1

   NEW TEXT:

   ------------------------------------------------------------------

   When a valid Neighbor Advertisement is received (either solicited or
   unsolicited), the Neighbor Cache is searched for the target's entry.
   If no entry exists, hosts SHOULD silently discard the advertisement.
   There is no need to create an entry if none exists, since the
   recipient has apparently not initiated any communication with the
   target.  Routers SHOULD create a new entry for the target address
   with the link-layer address set to the Target link-layer address
   option (if supplied).  The entry's reachability state MUST also be
   set to STALE.  If the received Neighbor Advertisement does not
   contain the Target link-layer address option the advertisement SHOULD
   be silently discarded.

(nit) I'm not sure why we need the word "also" in "MUST also be set to
STALE".

Section 10

I'd probably reiterate the (small) risk of the 7-second window of loss
of traffic discussed in §5.3.2 as a known+accepted security
consideration.

   A malicious host could attempt to exhaust the neighbor cache on the
   router by creating a large number of STALE entries.  However this
   attack vector is not new and this document does not increase the risk
   of such an attack: the attacker could do it, for example, by sending
   a NS or RS packet with SLLAO included.  All recommendations from
   [RFC6583] still apply.

Would there be any value in having the neighbor cache entries created on
routers by unsolicited NA be placed in a dedicated storage class, such
that the NDP prioritization recommended by RFC 6583 would be expanded to
include "never seen", "unsolicited NA", and "seen before" categories
with corresponding eviction priorities?

Section 12.1

RFC 6775 and 8505 probably don't need to be normative, since the
registration-based approach to ND is the approach not taken by this
document.

We also only cite RFC 8305 once, just as an example, so that may not
need to be normative either.

---

From: Jen Linkova <[email-masked]>
Date: Thu, 1 Jul 2021 15:13:46 +1000

Hi Ben,

Thanks a lot for your thorough review and text suggestions!

> consistent with the RFC 4861 guidance.

Wow, [facepalm] - thanks a lot for catching this.
I'll update the draft with the text you propose.

> [same as above re "subsequent"]

I'll update the text with the following:
"However, most router implementations limit the buffer size to a few
packets only, and some implementations are known to buffer just one
packet.
So any subsequent packets arriving before the address resolution
process is completed are causing packet loss by replacing older
packets in the buffer.
"

> RFC 4941 has been obsoleted by RFC 8981.

That's what happens when the author is lazy and not moving the draft
forward fast enough...References become obsolete...Thanks, fixed!

> packet for that address might be okay, but I don't think that's actually

How about:
"If the router does not have a Neighbor Cache entry for the address, a
STALE entry needs to be created proactively, prior to arrival of the
first packet intended for that address."

> I suggest adding "preferred address" to the terminology list (with RFC

Done.

> arrives to the node that sent the unsolicited NA".

How about this text:
"It should be noted that the proposed mechanism does not cause any
significant increase in multicast traffic. The additional multicast
unsolicited NA would proactively create a STALE cache entry on routers
as discussed below. When the router receives the return traffic flows
it does not need to send multicast NSes to the solicited node
multicast address but would be sending unicast NSes instead. Therefore
this procedure would only produce an increase in the overall amount of
multicast traffic if no return traffic arrives for the address that
sent the unsolicited NA or if the router does not create a STALE entry
upon receiving such NA. The increase would be negligible as that
additional traffic is a few orders of magnitude less than the usual
level of Neighbor Discovery multicast traffic."

> address that does not already have a Neighbor Cache entry".

Done.

> address waiting for resolution.

Yes, you are right.

>  If so, I might suggest a phrasing such

Actually as a result of other comments that section has been re-written anyway.
The new text:
https://datatracker.ietf.org/doc/html/draft-ietf-6man-grand-06#section-5.2

Please let me know if it does not address your concerns or more work is needed.

> the optimistic address, and so the scenarios do seem pretty similar

Yes. The last paragraph of that section is saying more or less the
same (well, at least that was my intention, not sure if that section
is clear enough).
Do you think the text shall be clarified further?

>    NEW TEXT:

Removed.

> of traffic discussed in §5.3.2 as a known+accepted security

I've added the following text:
"As discussed in Section 5.3.2 the worst case scenario might cause a
disruption for up to 7 seconds. This risk is considered acceptable due
to very low probability of that scenario. More importantly, for all
cases described in Section 5 the rightful owner can prevent disruption
caused by an accidental address duplication just by implementing the
mechanism described in this document. If the rightful owner sends
unsolicited NAs before using the address, the STALE entry would be
created on the router NC and any subsequent unsolicited NAs sent from
the host with an Optimistic address would not override the NC entry."

> with corresponding eviction priorities?

To be honest I'm not sure what kind of attack it would prevent.
Treating "never seen" differently from "seen before" (aka STALE and
REACHABLE) helps protecting from outside scanning.
For the host inside the segment there are multiple ways to create a
STALE entry, as mentioned above. So the router shall probably just
treat all STALE entries the same way.

> need to be normative either.

Yes, good point, fixed.

--
SY, Jen Linkova aka Furry