LibinLiu0189
commented
3 weeks ago Revision: We have removed Figure 4 and only introduced the four available SAV information sources including RPKI ROA and ASPA objects, local routing information, IRR data, and SAV-specific information in Section 5 as suggested.
[KS:] The draft enumerates 5 types of data that can be helpful for constructing SAV tables. Without an actual study to compare them, it seems premature to assign priority labels to them. In any case, as the draft also says, they are complementary to each other for SAV. IMO, BGP data and RPKI data (ROA, ASPA) are not less important than SAV-specific data. I do see that the draft tries to soften it all by stating, “It is noteworthy that the priority ranking of SAV information sources in Figure 5 is recommended rather than mandated.”
[Libin:] The recommendation is based on the analysis in Section 5. IMO, SAV is not only related to the information sources, but also how to utilize them to construct the SAV table, which depends on the SAV solutions/algorithms. Therefore, in the third paragraph of Section 6, the draft further states that "A new inter-domain SAVNET mechanism, in line with the inter-domain SAVNET architecture, has the flexibility to determine the utilized SAV information sources and their priorities accordingly."
KS:] I think the characterization of the data types in the table in Figure 4 (Section 5) seems like it is based on conjectures. So, it does not seem based on accurate analysis. Clearly, in a scenario where a customer cone has full deployment of ROA and ASPA, and full deployment of SAV based on ROA and ASPA data alone, there should be no improper blocking or improper admit (in all scenarios, i.e., NO_EXPORT, DSR, reflection or direct attack). So, the statement in the table (Fig. 4) that ROA and ASPA data result in improper blocking and improper admit does not seem correct.
[Libin:] Full deployment of SAV with full deployment of ROA and ASPA seems too strong and not practical. The analysis of existing data sources provides the evidence in Section 5: (1) For ROA and ASPA objects, a recent study [1] reported that the process of updating RPKI information is not timely, even requiring an hour. (2) For local routing information, the analysis is based on the PS draft, which analyzes existing SAV solutions using local routing information. (3) IRR data may not be always accurate, which is also stated in RFC8704. It may be more practical and general to discuss SAV deployment on the validation and source ASes, instead of full deployment, which I call general scenarios. In these general scenarios, for SAV only using ROA and ASPA objects, the validation AS may permit the spoofing traffic from the intermediate ASes between the source and validation ASes, for example, AS 5 may permit the spoofing traffic from AS 4 with source addresses in P1 in the attached figure. BTW, the late update of RPKI objects may lead to the late updates of SAV rules for solutions based on ROA and/or ASPA objects, and improper block may happen for such scenarios.
[KS:] I am in favor of exploring other data types and solutions in the SAVNET WG. The architecture draft really should just mention there are these various types of data sources for SAV: (1) local BGP data, (2) RPKI data (ROA, ASPA, etc.), and (3) proposed new SAV-specific inter-AS messages. (Side note: There is also IRR data, but it may or may not be listed as 4th type. The trust factor of IRR data is not certain. Also, the increasing deployment of ROA is possibly making IRR route object data less relevant. But I don’t mind if IRR data is included as a 4th type.) The inter-domain SAV architecture draft is misleading about the types of solutions. I think there are only two types of solutions that the SAVNET WG is envisioning: (1) SAV making complementary use of local BGP data and RPKI data, (2) SAV making complementary use of local BGP data and SAV-specific inter-AS messages (may include RPKI data also?) In partial deployment scenarios, it is necessary to make complementary use of multiple data types. Many details about (1) for the customer and lateral peer interfaces are known through the BAR-SAV draft. The details of (2) are not as well-known as present. Most importantly, I feel that the table in Figure 4 is misleading and ill-advised. In the performance assessment of each data type, the draft unfortunately appears to assume that there is a SAV solution based on each type of data by itself. That is incorrect. There are only two broad types of solutions making complementary use of the different data types as mentioned above. Also, there is no need to compare the performance of solutions in this document because this document is meant to provide architectural guidance to the solutions and should not pre-suppose solutions.
[Libin:] I think your suggested added paragraph in your previous email on Oct. 25 has include this. Is it okay? [Libin:] If we remove Figure 4 and only discuss the four available data sources for SAV in Section 5, are such revisions okay for you? Or do you have any more suggested revisions?