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

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 1 Jul 2021 13:28:29 -0700

Hi Jen,

On Thu, Jul 01, 2021 at 03:13:46PM +1000, Jen Linkova wrote:
> Hi Ben,
> 
> Thanks a lot for your thorough review and text suggestions!
> 
> > 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.
> 
> Wow, [facepalm] - thanks a lot for catching this.
> I'll update the draft with the text you propose.

Okay.  I'm not tied to my specific proposal, if some other wording appears.

> 
> > 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"]
> 
> 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.
> "
> 
> >    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.
> 
> That's what happens when the author is lazy and not moving the draft
> forward fast enough...References become obsolete...Thanks, fixed!
> 
> > 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.
> 
> 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."

Excellent, thanks!

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

That looks okay to me, thanks.

> > 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".
> 
> Done.
> 
> > 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.
> 
> Yes, you are right.
> 
> >  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".
> 
> 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 re-write looks good to me on this point, thanks.  I am a little unsure
how the unicast NS (derived from the STALE->DELAY entry that uses the
host's address) in step 6 would result in a solicited NA from the rightful
owner in step 7, but I'm also not focusing very well right now.

(nit) I'd also add a comma, for "Without the unsolicited NA, packet which
are in the buffer at Step 8".

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

I don't think further clarification is needed; the current text should be
fine.

> > 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".
> 
> Removed.
> 
> > 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.
> 
> 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."

Looks good!

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

Makes sense to me; thanks for taking the time to think about it.

> > 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.
> 
> Yes, good point, fixed.

Thanks for all the updates and explanations,

Ben

---

From: Jen Linkova <[email-masked]>
Date: Fri, 2 Jul 2021 12:30:06 +1000

> owner in step 7, but I'm also not focusing very well right now.

No, you are absolutely right, the text is not clear enough - thanks a
lot for pointing this out, I do need someone fresh to proof-read it.
Your comments make the document so much better!
Step 7 is not triggered by Step 6 but Step 2.

New text:
"7. The rightful owner responds to the multicast NS sent at Step 2
with a solicited NA with the Override flag set."

and at the end of the section:
"This section focuses on the scenario when the solicited NA from the
rightful owner arrives after the unsolicited one sent from the
Optimistic address (Step 5 and Step 7 respectively). If the solicited
NA arrives first it changes the NC entry state from INCOMPLETE to
REACHABLE. As discussed in Section 5.1, there will be no disruption
for the rightful owner if the router already has a REACHABLE entry for
the address when an unsolicited NA is received."

> are in the buffer at Step 8".

Fixed, thanks.

-- 
SY, Jen Linkova aka Furry

---

From: Jen Linkova <[email-masked]>
Date: Fri, 2 Jul 2021 12:33:03 +1000

> Optimistic address (Step 5 and Step 7 respectively). If the solicited

This should be "Step 7 and Step 4" indeed.