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

[Benjamin Kaduk <[e-mail]>]

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