[6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-backbone-router-16: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6lo-backbone-router-16: Discuss

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 IESG DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for this -- it was a good read.  I just have a few super-boring
poitns of apparent internal inconsistency to fix before publication.

There seems to be an internal inconsistency relating to the handling of
link-local addresses by a Bridging Proxy: Section 8 descriptively says
that such addresses are (always) registered ("[t]he Bridging Proxy
registers any Binding including for a Link-Local address to the 6LBR"),
but Section 9 has this behavior as optional ("[a] Bridging Proxy MAY
register Link Local addresses at the 6BBR and proxy ND for these
addresses over the backbone").

Similarly, I see Section 6 saying that when a 6BBR generates an NA in
response to an NS(DAD), it "MUST have the Override flag set", but
Section 9.2 says "MUST be answered ... the Override flag not set" (for
the "different registration" case, i.e., second bullet) and nothing at
all about the Override flag for the "not as fresh"/"Moved" case (i.e.,
the third bullet).  Am I misreading something?

Continuing the theme, Section 10 notes that a "Registering Node SHOULD
register all of its IPv6 Addresses to its 6LR, which is the 6BBR when
they are connected at Layer 2", but Appendix B states the stronger
condition that "[t]he 6BBR assumes that if a node registers at least one
IPv6 Address to it, then the node registers all of its Addresses to the
6BBR."


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

In Section 3 we talk about the Binding Table as a "distributed
database", but I didn't see much further exposition on that topic.  It
would be great to have a bit of discussion about what the logical
contents of a row in the database are (e.g., IP address, MAC address,
ROVR, registration state, associated host route, ...), as well as what
the concurrency and consistency properties of the distributed database
are expected or required to be.

I also am not quite sure I understand the full picture for backwards
compatibility/incremental deployment: it seems like we may need the
6LBR(s) to be updated to support this spec before anything else can use
it, though I'm not sure.  For example, if we need both IPv6 ND's DAD and
EDAR/EDAC between 6BBR/6LBR, does that mean the 6LBR has to be updated
first?

Section 1

   Because IPv6 ND messages sent to the SNMA group are broadcast at the
   radio MAC Layer, wireless nodes that do not belong to the SNMA group
   still have to keep their radio turned on to listen to multicast NS
   messages, which is a total waste of energy for them.  In order to

nit: "total waste" might be a stronger statement than you want to have
to defend (vs. just "waste").

   These problems can be alleviated by reducing the IPv6 ND broadcasts
   over wireless access links.  This has been done by splitting the
   broadcast domains and routes between subnets, or even by assigning a
   /64 prefix to each wireless node (see [RFC8273]).

"If there are already solutions, why do we need more solutions?" ;)
(Maybe it's worth mentioning that these proposed workarounds have
weaknesses, or even what those weaknesses are.)

   Another way is to proxy at the boundary of the wired and wireless
   domains the Layer 3 protocols that rely on MAC Layer broadcast
   operations.  For instance, IEEE 802.11 [IEEEstd80211] situates proxy-
   ARP (IPv4) and proxy-ND (IPv6) functions at the Access Points (APs).
   The 6BBR provides a proxy-ND function and can be extended for proxy-
   ARP in a continuation specification.

nit-ish: it might be worth saying something about "in an analogous
manner" and/or "for LLNs" in the last sentence.

Section 2.2

   Sleeping Proxy:  A 6BBR acts as a Sleeping Proxy if it answers ND
      Neighbor Solicitations over the Backbone on behalf of the
      Registering Node which might be in a sleep state in a low power
      network.  The Sleeping Proxy that is also a Bridging Proxy will
      preferably forward the relevant messages to the Registering Node
      as unicast frames in accord to the duty cycle of the Registering
      Node and let it respond.

Should we expect the reader to know what "the relevant messages" are
that the bridging proxy forwards to the registering node?  Without
additional context, the text here implies that the ND NS messages are
the "relevant" ones, with the awkward implication that the 6BBR both
answers on behalf of the registering node and forwards messages to it.

   Bridging Proxy:  A Bridging Proxy provides IPv6 ND proxy functions
      while preserving forwarding continuity at the MAC Layer.  The
      Bridging Proxy advertises the MAC Address of the Registering Node
      as the TLLA in the proxied NAs over the Backbone.  In that case,
      the MAC Address and the mobility of 6LN is still visible across
      the bridged Backbone, and the 6BBR may be configured to proxy for
      Link Local Addresses.

nit: I think there's a singular/plural issue for "mobility of 6LN".

Section 2.4

nit: the current structure doesn't do a good job of indicating why the
references are grouped into bullet points as opposed to a single
consolidated list.

Section 3

nit: the list after figure 1 is missing a blank line between the last
two elements.

   *  Advertise a Registered Address over the Backbone using an
      unsolicited NA message, asynchronously or as a response to a NS
      message.  This includes joining the multicast group associated to

nit: I think the binding of "unsolicited" is not quite right, as it
currently also applies to the "as a response to a NS" case.

   The first of these functions enables the 6BBR to fulfill its role as
   a Routing Registrar for each of its attached LLNs.  The remaining
   functions fulfill the role of the 6BBRs as the border routers
   connecting the Multi-link IPv6 subnet to the Internet.

I'm a bit confused by this last sentence (probably just me, but...) --
the functions in question are things like forwarding/briding traffic
between LLN and backbone, so why is "the Internet" required to be in
play?

   The registration to a proxy service uses an NS/NA(EARO) exchange.

nit(?): does the "(EARO)" apply to just NA, or to NS as well?

   The 6BBRs use the Extended Address Registration Option (EARO) defined
   in [RFC8505] as follows:
      [...]
   *  The Link Layer Address (LLA) that the 6BBR advertises for the
      Registered Address on behalf of the Registered Node over the
      Backbone can belong to the Registering Node; in that case, the
      6BBR (acting as a Bridging Proxy (see Section 8)) bridges the
      unicast packets.  Alternatively, the LLA can be that of the 6BBR
      on the Backbone interface, in which case the 6BBR (acting as a
      Routing Proxy(see Section 7)) receives the unicast packets at
      Layer 3 and routes over.

I'm not seeing how the EARO is used as part of this.

Section 3.1

Would it be worth a forward-reference to Section 9 (for it's list of
"6LR operation is modified as follows")?

   Note: [RFC6775] requires that the registration NS(EARO) contains an
   SLLAO and [RFC4862] that the NS(DAD) is sent from the unspecified

nit: RFC 6775 predates RFC 8505 that introduces the EARO, so it's hard
to see how 6775 specifically requires this of a registration NS(EARO).

Section 3.3

side note: some of our previous discussions on 6lo documents gave me the
impression that a 6LBR was more of a privileged/distinguished thing than
Figure 4 makes it out to be, e.g., that there would be one logical 6LBR
per network.  Going back and re-reading (e.g., RFC 8505) it seems I was
mistaken, and it's okay to have many independent 6LBRs like this; they
just need to be managing distinct LLNs.

Section 3.4

   *  Identical registrations (same TID, same ROVR) from the same
      Registering Node are accepted with a status of 0 (Success).  In
      Tentative state, the response is held and may be overwritten, but

nit: is this still "the EDAC response" as in the previous item?

Section 3.5

   A 6BBR may optionally be primary or secondary.  The primary is the

I'm not sure what the "optionally" means here -- is it an implementation
choice to just not think about the question of primary vs. secondary and
alawys behave the same [as primary]?  The next paragraph implies that it
is so, but perhaps more clarity is warranted.

Section 4

   Nodes located inside the subnet do not perform the IPv6 Path MTU
   Discovery [RFC8201].  [...]

nit(?): I couldn't find where in RFC 8201 it's specified that PMTUD is
not performed for same-subnet paths; is that specified elsewhere or just
a consequence of the nature of a subnet?

Section 5

   This specification allows for an address to be registered to more
   than one 6BBR.  Consequently a 6LBR MUST be capable of maintaining
   state for each of the 6BBR having registered with the same TID and
   same ROVR.

This seems like something worth calling out in the "Updating RFC 6775"
section.

Section 6

   The 6BBR advertises and defends the Registered Addresses over the
   Backbone Link using RS, NS(DAD) and NA messages with the Registered
   Address as the Source or Target address, respectively.

nit: I don't think "respectively" is right, since there are three
elements in the first list (RS, NS(DAD), and NA) but only two in the
second (Source address, Target address).

   An NA message generated in response to an NS(DAD) MUST have the
   Override flag set and a status of 1 (Duplicate) or 3 (Moved) in the
   EARO.  An NA message generated in response to an NS(Lookup) or an
   NS(NUD) MUST NOT have the Override flag set.

I think there's an implicit "by the 6BBR" in both the "message
generated"s here, but please confirm.

   This specification enables proxy operation for the IPv6 ND resolution
   of LLN devices and a prefix that is used across a Multi-Link Subnet
   MAY be advertised as on-link over the Backbone.  This is done for
   backward compatibility with existing IPv6 hosts by setting the L flag
   in the Prefix Information Option (PIO) of RA messages [RFC4861].

Are there any drawbacks to providing this backwards-compatible behavior
worth mentioning?

Section 7

   EUI-48).  Since a 6LN may not be able to resolve an arbitrary
   destination in the MLSN directly, the MLSN prefix MUST NOT be
   advertised as on-link in RA messages sent towards the LLN.

nit(?): is there a single distinguished MLSN prefix to merit the
definite article here?  (I note that in the previous section we speak
only of "a prefix that is used across a [MLSN]".)

Section 8

   If the Registering Node owns the Registered Address, then its
   mobility does not impact existing NCEs over the Backbone.  Otherwise,
   when the 6LN selects another Registering Node, the new Registering
   Node SHOULD send a multicast NA with the Override flag set to fix the
   existing NCEs across the Backbone.

I think I'm confused about the distinction between "Registering Node"
and "6LN", here -- in my head they are the same entity.  (If I replace
"Registering Node" with "6BBR" in the second and third occurrences,
things seem to make more sense and are roughly analogous to the
discussion in Section 7...but looks can be deceiving.)
[ed. Section 10 does describe a case where Registering Node and 6LN are
different]

Section 9

   even for a duplicate address.  Consequently, and unless
   administratively overridden, the 6BBR still needs to perform IPv6 ND
   DAD over the backbone after an EDAC with a status code of 0 or 9.

I'd be curious to see a pointer to the discussions that caused "unless
administratively overridden" to be introduced, as naively that note does
not seem necessary.

   If a registration is received for an existing Binding with a non-null
   Registration Lifetime and the registration is fresher (same ROVR,
   fresher TID), then the Binding is updated, with the new Registration
   Lifetime, TID, and possibly Registering Node.  In Tentative state
   (see Section 9.1), the current DAD operation continues unaltered.  In
   other states (see Section 9.2 and Section 9.3 ), the Binding is
   placed in Reachable state for the Registration Lifetime, and the 6BBR
   returns an NA(EARO) to the Registering Node with a status of 0
   (Success).

Does this mean we don't re-do DAD for registrations already in a Stale
state when we receive an updated registration for them?

   Upon a registration that is identical (same ROVR, TID, and
   Registering Node), the 6BBR returns an NA(EARO) back to the
   Registering Node with a status of 0 (Success).  A registration that
   is not as fresh (same ROVR, older TID) is ignored.

What (if anything) happens to the registration lifetime in this case?

   registering node.  It MAY preserve a temporary state in order to
   forward packets in flight.  The state may be a NCE formed based on a
   received NA message, or a Binding in Stale state and pointing at the
   new 6BBR on the backbone.

nit: is this an exhaustive list of permitted ways to implement
"temporary state"?

   The implementation should also use REDIRECT messages as specified in
   [RFC4861] to update the correspondents for the Registered Address,
   pointing the new 6BBR.

s/should/SHOULD/?

Section 9.1

   *  The Binding MUST be removed if an NA message is received over the
      Backbone for the Registered Address with no EARO, or containing an
      EARO with a status of 1 (Duplicate) that indicates an existing
      registration owned by a different Registering Node.  In that case,
      an NA MUST be sent back to the Registering Node with a status of 1
      (Duplicate) in the EARO.  This behavior might be overriden by
      policy, in particular if the registration is trusted, e.g., based
      on the validation of the ROVR field (see [I-D.ietf-6lo-ap-nd]).

I suggest to reword this to say "an NA is sent back to the Registering
Node" to avoid having a normative "MUST" that is then overridden by the
last sentence.  (Similarly for the next item as well.)

Also, to check my understanding, the first two bullets in combination
mean that if we somehow end up in a state with identical Tentative
bindings at two different 6BBRs, they will both respond to each others'
NS(DAD) with an NA, causing both bindings to be removed (i.e., "everyone
loses")?

Section 10

   The Registering Node may be the 6LN owning the IPv6 Address, or a
   6LBR that performs the registration on its behalf in a Route-Over
   mesh.

Having this earlier would probably have saved me some confusion :)

   The Registering Node SHOULD register all of its IPv6 Addresses to its
   6LR, which is the 6BBR when they are connected at Layer 2.  Failure
   to register an address may result in the address being unreachable by
   other parties if the 6BBR cancels the NS(Lookup) over the LLN or to
   selected LLN nodes that are known to register their addresses.

I'm not sure I'm parsing the second sentence correctly -- what's the
antecedent for "or to selected LLN nodes"?

   The Registering Node SHOULD also follow [RFC7772] in order to limit

This is BCP 202, right?

Section 11

We force a sequencing that has EDAR/EDAC occur before normal NS(DAD); does
this provide a new DoS avenue by virtue of delaying the normal NS(DAD)
procedure by (e.g.) dropping the EDAC messages?

It might be worth a brief preface that since we're modifying the
ND and DAD processes, the attacks in scope are basically limited to
blocking discovery of taking over addresses from other nodes (which, to
be fair, can in some cases have substantial consequences in terms of
reading the "stolen" traffic!).

   This specification applies to LLNs and a backbone in which the
   individual links are protected against rogue access, e.g., by
   authenticating a node that attaches to the network and encrypting at
   the MAC layer the transmissions that may be overheard.  In
   particular, the LLN MAC is required to provide secure unicast to/from
   the Backbone Router and secure Broadcast from the Backbone Router in
   a way that prevents tampering with or replaying the RA messages.

It seems like it would be worth stating these requirements/applicability
statement much earlier in the document (possibly in addition to here),
e.g., in the Introduction.

   provide the proof-of-ownership.  A possible attack over the backbone
   can be done by sending an NS with an EARO and expecting the NA(EARO)
   back to contain the TID and ROVR fields of the existing state.  With
   that information, the attacker can easily increase the TID and take
   over the Binding.

The 6BBR can also perform such an attack, right?  It might be worth
explicitly stating that we trust it to behave honestly in order for this
stuff to work properly.

We could also discuss how things break if the "distributed database" of
registrations gets out of sync across 6BBRs/etc..

How do things degrade if a secondary 6BBR "stands back" to let a primary
handle a given message but the primary 6BBR has gone offline unbeknownst
to the secondary?

Are there any noteworthy scaling requirements to the bridging and
routing proxy modes?  (I don't think so, and we just allude to
"dimensioned for the number of registrations that each needs to support"
in Appendix B, but it doesn't hurt to ask.)

Section 15

RFC 6550 is only mentioned once, as a "non-normative example", so seems
more appropriately placed in the Informative References.

Section 16

It might be worth replacing RFC 6830 with draft-ietf-lisp-rfc6830bis,
which is both significantly different from RFC 6830 and fairly close to
done.

We have "SHOULD [...] support Packet-Loss Resiliency for Router
Solicitations [RFC7559]" which, per
https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
would put it in the Normative References.  Likewise for RFC 7772.

Appendix A

   By default the specification does not have a trust model, e.g.,
   whereby nodes that associate their address with a proof-of-ownership
   [I-D.ietf-6lo-ap-nd] should be more trusted than nodes that do not.
   Such a trust model and related signaling could be added in the future
   to override the default operation and favor trusted nodes.

Well, we kind of have a trust model: "anyone on the backbone and anyone
that can authenticate to the LLN MAC is trusted equally; others are not
trusted".  So perhaps it's more appropriate to go with "does not have a
fine-grained trust model: all nodes that can authenticate to the LLN MAC
or attach to the backbone are equally trusted.  It would be desirable to
provide a stronger authorization model, e.g., [...]"?

   Future documents may extend this specification by allowing the 6BBR
   to redistribute Host routes in routing protocols that would operate
   over the Backbone, or in MIPv6, or FMIP, or the Locator/ID Separation

Is there a reference for FMIP?  We don't mention it elsewhere in the
document, as we do for MIPv6.

Appendix B

We seem to cover the requirements from Appendix B of RFC 8505 out of
order: B.3, B.1, B.4, B.6, then B.2.  I didn't think very hard about
whether there's good rhetorical reason for the current order, though.

   The impact if the IPv6 ND operation is limited to one of the
   federated LLNs, enabling the number of 6LNs to grow.  The Routing

nit: I don't think this is a well-formed sentence.  Possibly it's just
suffering from a typo (s/if/of/), though I'm not entirely sure.