Re: [Lsvr] Alvaro's Remaining Comments: New Version Notification for draft-ietf-lsvr-bgp-spf-27.txt

[Alvaro Retana <[e-mail]>]

Hi!

I looked at the diffs from -27.

Thanks for addressing the issues with the next hop and the link identifiers
-- I have a nit with this last part:

§5.2.2:

    ...discovering the Link Remote Identifier is beyond the scope of this
    document.  ...it is RECOMMENDED that the Link Remote Identifiers be
known
    (e.g., discovered using alternate mechanisms or configured) in the
    presence of parallel unnumbered links.

Leaving the discovery out of scope is fine.  However, making it normatively
RECOMMENDED is a contradiction (because it is out of scope).
 s/RECOMMENDED/recommended



My only major issue left is the text from §7.4 that can result in endless
session resets and provide an easy vector to affect the network's
stability.  See below.


Thanks!

Alvaro.

On August 2, 2023 at 2:53:35 PM, Alvaro Retana ([e-mail])
wrote:

...
The new section says this:

   7.4. BGP-LS-SPF Link State NLRI Database Synchronization

      While uncommon, there may be situations where the LSNDBs of two BGP-
      LS-SPF speakers lose synchronization. In these situations, the BGP
      session MUST be reset. The mechanisms to detect loss of
      synchronization are beyond the scope of this document.

Resetting the session should result in a resync, so it is not a bad
recommendation.  [A route refresh could also be used.]

All the cases of BGP-LS drop and treat-as-withdraw specified in §7.1 lead
to loss in synchronization and resetting the session won't necessarily fix
the problem.  In the specific case of §5.1.2 (where the BGP-LS attribute is
discarded because of the message size) the action will result in the
session bouncing forever -- and all the other routes being lost,
potentially leaving a part of the network without any reachability.

A rogue node can then remove the BGP-LS attribute, or manipulate the TLVs
to cause any other error to affect the whole session -- not just a single
route.  IOW, the impact is beyond that is mentioned in the Security
Considerations:

   If an authorized BGP peer is compromised, that BGP peer could advertise
   modified Node, Link, or Prefix NLRI which result in misrouting,
repeating
   origination of NLRI, and/or excessive SPF calculations.