[Sidrops] About registering more in ASPA: RE: Call for adoption of draft-spaghetti-sidrops-rpki-prefixlist

[gengnan <[e-mail]>]

Hi,

I think: besides the provider-set, registering more (such as neighbor-set, peer-set, customer-set, etc.) is useful though there will be some challenges.
  
Sriram and I (and others) have been discussing this possible direction for improving ASPA. There are some benefits and also some concerns (one of them is as described by Sriram below). 

Possible benefits if an AS can register more:
1. Cross-check the correctness of registration
2. Identify fake links if we know all neighbors/adjacencies (similar benefit to Geoff and George's previous draft: draft-huston-sidr-aao-profile)
3. Hop-check(Y, X) for Hop-check(X, Y) under partial registration (The process described by Sriram below)
4. (Optional) Cope with complex scenarios such as complex relationships and legitimate valley-paths (see Fredrik's comment on ASPA: https://www.manrs.org/2023/10/coordination-key-to-largest-rpki-deployment/)

Detailed analysis, simulation results, and deployment considerations can be found in the slides presented in APNIC56: https://conference.apnic.net/56/assets/files/APJS642/autonomous-system-re_1694481446.pdf

About Sriram's concern, the risk may exist, but:
1. The attacker cannot repudiate the attack if the attacker register the bogus ASRA data in advance. 
2. Without the usage of "Hop-check(Y, X) for Hop-check(X, Y)", there are also many other benefits (1,2, and 4 above).


Best,
Nan

> -----Original Message-----
> From: Sriram, Kotikalapudi (Fed) <[e-mail]>
> Sent: Monday, October 23, 2023 7:39 AM
> To: Randy Bush <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [Sidrops] Call for adoption of draft-spaghetti-sidrops-rpki-prefixlist
> 
> >if we like being able to check in both directions, why are we not also
> >working on APSA, As Provider Southbound Attestation, where an AS
> >declares it's downstreams?  it would provide a check similar to
> >prefixlist for mistakes in ASPAs.
> 
> I have been discussing this kind of object (and variants) with several people
> (Jeff Haas, Nan Geng, others).
> 
> It is harmful. It gives a weapon to a malicious leaker to foil or confuse the ASPA
> route leak detection.
> 
> Example (initially consider only ASPA deployed):
> 
> AS B is multihomed to transit providers AS A and AS C.
> 
> AS A  --- (P2C) --->  AS B  --- (C2P) ---> AS C
> 
> ASPA:  AS A {AS F, AS G}
> AS B has not registered any ASPA.
> Route path at AS C:  AS B  AS A
> 
> The route propagates from AS A and is received at AS C via AS B.
> AS C knows from its configuration that AS B is a customer.
> Presently, AS C can readily detect that the route is Invalid (a leak or infeasible
> path).
> Because AS A's ASPA attests that AS B is not a Provider (i.e., AS B is either a
> customer or lateral peer of AS A).
> 
> Now consider the *new* object.
> 
> If the proposed *new* object is deployed, AS B can maliciously register one
> attesting that AS A is a customer ☹.
> AS B's *new* object contradicts AS A's ASPA.
> In that case, which object is AS C supposed to trust for its path verification
> (route leak detection)?
> Suppose we (IETF) specify that if AS C determines there is a contradiction
> between what AS A and AS B assert, then it will consider the AS A to AS B hop
> to be "No Attestation".
> That would mean that the attacker (AS B) wins.
> The path will be determined "Unknow" at AS C rather than "Invalid".
> 
> There is far more utility and no discernible harm (IMO) if only provider
> attestations (ASPA) are deployed or used in the path verification algorithms.
> If an AS includes a customer in its ASPA provider list, it only hurts its customer.
> Route leak (or infeasible path) detection still works (unhampered).
> The prefixes of the customer AS (and its CC) will experience denial of service
> (unreachability) and they'll complain, and the AS will respond to correct its
> ASPA.
> 
> Sriram