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

[gengnan <[e-mail]>]

Thank Sriram. The draft was given a major update and reads well. I also support advancing the draft.

IMO, although the problem shown in Figure 3 is unlikely to occur, it does possibly occur (inadvertently or intentionally). It would be better if the problem can be fixed. Another problem is how ASPA can work better when the registration data is scarce. I'm just throwing my thoughts out for discussion. I think they do not need to be resolved in this draft even they really matter. 

I am also waiting for more operational feedbacks about ASPA. 

Nit-picking:
1. The title of Figure 1 : Hop Check Function --> Hop-check function
2. "not Provider" --> "Not Provider"; "no Attestation" --> "No Attestation"
3. Sec. 12, "{{AS(5), AS(3) ..." and "{{AS(5), AS(1)...", where "{{" -->"{"


Best,
Nan

> -----Original Message-----
> From: Sidrops <[e-mail]> On Behalf Of Yangyang Wang
> Sent: Tuesday, March 14, 2023 11:42 AM
> To: 'Sriram, Kotikalapudi (Fed)'
> <kotikalapudi.sriram=[e-mail]>; [e-mail]
> Cc: 'Claudio Jeker' <[e-mail]>;
> [e-mail];
> [e-mail]
> Subject: Re: [Sidrops] WGLC = draft-ietf-sidrops-aspa-verification - ENDS
> 03/22/2023 (Mar 22 2023)
> 
> 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
> 
> _______________________________________________
> Sidrops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sidrops