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

[Acee Lindem <[e-mail]>]

Hi Alvaro, 

> On Aug 31, 2023, at 11:36 AM, Alvaro Retana <[e-mail]> wrote:
> 
> 
> 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

Right - I agree. 


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


Yeah, Keyur and I still need to talk about error handling and synchronization.  Due to scheduling and there not being a simple solution, we still haven’t done this.

I wanted to go ahead and publish what I had pushed to the repository. 


Thanks,
Acee