Re: [Sidrops] WG Adoption call for draft-sriram-sirops-bar-sav-02.txt - ENDS 01/30/2023 (Jan 30 2023)

["Sriram, Kotikalapudi (Fed)" <[e-mail]>]

Hi Amreesh,

Thank you for the review and comments.

>As BAR-SAV relies on BGP Update AS_PATH data, I would like the authors to
>provide a little more information on how it deals with manipulated AS_PATH
>information.

The BAR-SAV algorithm requires excluding BGP Updates that are considered Invalid by the ASPA-based path verification algorithm. From Sec. 4, page 6:

   As a measure of security, validation of the AS_PATH data in Adj-RIBs-
   In [RFC4271] SHOULD be performed using the procedures in
   [I-D.ietf-sidrops-aspa-verification] and any Invalid AS_PATHs must be
   excluded from inputs to the BAR-SAV procedure.  This ensures that BGP
   UPDATEs containing route leaks are not considered for BAR-SAV filter
   design.

>Finally, just a thought, can BAR-SAV use BGPSEC data instead of or in
>combination with ASPA data?

BGPsec path validation is an assurance that the Update actually traveled the path shown in the BGPsec_PATH Attribute. However, it does not detect route leaks (valley-free violations). ASPA path validation on the other hand can offer assurance that the path appearing in the AS_PATH attribute is route-leak free but it cannot assure that the Update actually traveled that path. Nevertheless, we can think of the ASPA valid paths as feasible.  That is a trade-off between the BGPsec and ASPA methods. People generally seem to agree that wide deployment of ASPA is more likely and possibly in a much shorter time frame than wide deployment of BGPsec. Additionally, ASPA data in combination with ROA data helps significantly in uncovering any hidden prefixes for SAV filter design and that in turn significantly lowers the probability of false positives for BAR-SAV.

Having said that, your suggestion makes sense for the future. If BGPsec deployment comes into play, it can be another means for eliminating "manipulated AS_PATH
information" from being considered. 

Sriram

-----------------------------------------------
From: Amreesh Phokeer <[e-mail]> Mon, 30 January 2023

Hello all,

I support the adoption of the draft "Source Address Validation Using BGP
UPDATEs, ASPA, and ROA (BAR-SAV)", as I believe it tries to solve a
real-world problem.
I like the fact that it uses information from existing objects i.e. ASPA
and ROA but I also share the concern that ASPA is not an RFC yet (hopefully
soon).

As BAR-SAV relies on BGP Update AS_PATH data, I would like the authors to
provide a little more information on how it deals with manipulated AS_PATH
information.

Finally, just a thought, can BAR-SAV use BGPSEC data instead of or in
combination with ASPA data?

Regards,
Amreesh