Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS 03/22/2023 (Mar 22 2023)

[Yangyang Wang <[e-mail]>]

Hi Sriram and Claudio,

Thank you for your responses. They are make sense for me and I support
advancing the draft.

(I repost my reply here:) I understand that the ASPA solution is cautious.
In the process of incremental deployment of ASPA,  some ASes have not yet
provided authorization data. In some cases, a path of being route leak may
be validated as "unknown" (i.e., false negative) due to lack of information.
But it does not lead to false positives (i.e., valley-free paths are checked
as "invalid").

If the provider shortened the length by creating a forged link ( shown in
Section 12), this cheating can only attract the traffic from customer, and
can be detected using upstream algorithm at the providers and literal peers
of the provider. It implies that the affected area of this cheating can be
limited if many ASes register ASPA.

The ASPA can cover most routing policy on the Internet. And, I just note
that the scenario in
https://datatracker.ietf.org/doc/draft-shen-sidrops-regionalized-as-relation
ships/ is a problem. A few ASes may have hybrid relationship, which is not
able to be expressed in ASPA. If two ASes, 1 and 2, have customer-provider
link at location A and peer-peer link at location B, It seems that SPAS of
AS 1 will include AS 2 (at location 1), but also should not include AS2 (at
location 2).  This might make the operator of AS A confused about how to
register ASPA.

Best regards,
Yangyang
2023-03-14


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Sriram, Kotikalapudi (Fed)
> Sent: 2023年3月9日 11:58
> To: Yangyang Wang <[e-mail]>; [e-mail]
> Cc: Claudio Jeker <[e-mail]>; draft-ietf-sidrops-aspa-
> [e-mail]; [e-mail]
> Subject: Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS
> 03/22/2023 (Mar 22 2023)
> 
> Hi Yangyang,
> 
> Thank you for the comments. My responses are inline below marked with
> [KS:].
> 
> My responses to #3 and #4 complement Claudio's
> ( https://mailarchive.ietf.org/arch/msg/sidrops/jTlhzDKCKv21WIUd-
> Kv00Qtsmk8/ ).
> 
> Sriram
> 
> -----Original Message-----
> From: Yangyang Wang <[e-mail]>
> 
> Comments as follows.
> 1. a few typos.
> In section 3, "The definition of Provider AS in given in Section 1"
-->"The
> definition of Provider AS is given in Section 1"
> Page 7, "If N = 1, then then the procedure" --> remove the extra "then"
> Page 10, downstream path verification procedure, step 4 "lowest value of v
> (2 <= u <= N)" --> " lowest value of u (2 <= u <= N)"
> 
> [KS:] Thanks. Will fix those.
> 
> 2. This draft claims that "An AS SHOULD NOT have more than one ASPA".
> If a Customer AS signs only one ASPA object including all its Provider
ASes, it
> needs to resign and update it when any one of the provider ASes changes.
> It may affect the validation.
> 
> [KS:] The AS operator would follow the principle of make before break.
> Create a new ASPA first and then delete the old one. It is not a MUST NOT.
So,
> two ASPAs may exist for a short period. The ASPA profile draft authors
(cc'ed
> here) may include an operational guidance statement about this in that
draft.
> 
> 3. In the algorithm for downstream paths, it says that if 1 <= N <=2, then
the
> AS_PATH is trivially Valid.
> If N=2, assuming AS_PATH is (AS2, AS1), the path verification is just hop-
> check hop(AS(1), AS(2)) and may be one of "Provider", "Not Provider" and
> "no Attestation".
> If it is "Provider", the AS_PATH is Valid.
> If it is "Not Provider" or "no Attestation", I feel that the AS_PATH is
actually
> unclear, which may be Valid, or forged link as the (AS(5), AS(2)) shown in
> Section 12.
> 
> [KS:] The path is (AS2, AS1) and received by a validating AS (say AS3)
that is
> downstream (i.e., AS2 is a provider to AS3). Without even looking at the
ASPA,
> this path is trivially Valid because no matter whether AS1 to AS2 is C2P,
P2C,
> or p2p (lateral peers), there is no valley in the path and hence there is
no
> route leak.
> 
> [KS:] For the case of a forged-origin attack (with provider doing mischief
on a
> customer) that you mention, I feel the draft discusses that security
concern
> adequately in Section 12. The strength of the ASPA method is in detecting
> route leaks and a majority of (but not all) path manipulation attacks. It
> cannot catch all path manipulations -- BGPsec would be needed for that.
> 
> 4. It seems that the algorithms for path verification are not complete to
cover
> all possible cases.
> 
> For example, shown in the figure below:
> 
> Receiving & validating AS 5 --  AS(4)
> 				 \
> 				   \
>                                                           AS(3)     AS(1)
>                                                               \        /
> 			 	      \     /
>                                                                 AS(2)
> ASPAs: {AS(2), [AS(3), AS(1)]}
> 
> AS5 is the Receiving & Validating AS. And, only AS(2) register an ASPA
object
> in RPKI.
> It assumes that AS5 receives an AS_PATH [AS(4), AS(3), AS(2), AS(1)], and
> there is a route leak from AS(3) to AS(1) by the customer AS(2) hop(AS(1),
> AS(2)) = "no attestation"
> hop(AS(2), AS(3)) = "Provider"
> hop(AS(3), AS(4)) = "no attestation"
> According to the step 4 and 5 of the algorithm for upstream paths in
section
> 6.1,  there is not an i for which hop(AS(i-1), AS(i)) = "not Provider".
This path
> is invalid, but will be verified as "Unknown".
> 
> Maybe I'm missing something or make a mistake.
> 
> [KS:] To add what Claudio has said... please keep in mind that AS(1) has
no
> ASPA and that means that a sibling relationship between AS1 and AS2 is
still
> possible. See the definition of sibling in Section 2 and the corresponding
> ASPA registration requirement in Section 4. So, if AS1 and AS2 are
siblings,
> then the path would be Valid. If they are not siblings, the path would be
> Invalid. So, given that AS1 does not have an ASPA, the algorithm correctly
> gives "Unknown" result.
> 
> Sriram
> 
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops