Re: [GROW] IXP Route Server question
Hi Sriram, Thanks for your pointers! I will read them carefully. Best regards, Shunwan > -Original Message- > From: Sriram, Kotikalapudi (Fed) [mailto:kotikalapudi.sri...@nist.gov] > Sent: Monday, March 14, 2022 12:45 AM > To: Zhuangshunwan > Cc: grow@ietf.org; sidr...@ietf.org > Subject: RE: [GROW] IXP Route Server question > > Hi Shunwan, > > >> The ASPA verification draft treats the relationship of RS to > >> RS-client as similar to that of Provider to Customer. Seems > >> reasonable? The AS of an RS client includes the RS's AS in its ASPA as a > "Provider". > > >IMO, the ASPA verification draft regards the relationship between RS > >and RS-client as "peer-to-peer", > > That is not correct. > > >maybe my understanding is wrong, I will read the ASPA verification draft > again. > > OK. Just FYI... the draft needs a revision. It does not contain yet the > enhanced > ASPA upstream/downstream verification algorithms/procedures. Not sure if > you've followed sidrops discussions on the algorithms since January 2021. > Some pointers: > https://datatracker.ietf.org/meeting/110/materials/slides-110-sidrops-srira > m-aspa-alg-accuracy-01 > https://mailarchive.ietf.org/arch/msg/sidrops/C6Ethp2aC9sJsxDtBrLQDjmCq > k4/ > > Thanks. > > Sriram > > > > > > ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Sidrops] IXP Route Server question
Sriram, Kotikalapudi (Fed) wrote on 13/03/2022 16:20: Not sure why Ben even raised that question. To me, it doesn't seem relevant. In the route leak detection procedures, the receiving/validating AS does not require information about the nature of ASes (RS or not RS) in the AS Path except for the sending/neighbor AS which it knows to be an RS in case it knows itself to be an RS-client. The procedures rely only on ASPA objects for the origin AS and ASes in the middle. Stepping back a bit, there's no fundamental difference between the behaviour of a transparent RS and a non-transparent RS, except that the transparent RS happens to elide the RS AS number from the AS path. The remainder of the AS path will be the same in either case. The algorithm for check_ix_path() implements a check to flip between upstream path verification and downstream path verification based on whether the RS is transparent or non-transparent. Even if it gives a workable outcome, I think this is the wrong approach from an algorithmic point of view. The algorithm needs to accept that the two situations are basically the same except that in one (rare) case, the RS ASN is present in the AS path, and in the other, it isn't. Section 5.3 says that the client has prior knowledge about whether the peer is a RS. I.e. the draft already admits that rs client implementations will need a config flag. So rather than discussing whether non-transparent ASNs are included in the specification, the discussion needs to focus on whether RS ASN's should be included in the ASPA verification algorithm at all, and if so / if not, how this should be done. The answer to this question is (surprisingly) not immediately clear. RSs do not partake in traffic forwarding, so they are not part of the data path between two ASNs; they're only part of the signaling path between the two ASNs. This is a useful hack from a practical point of view, but it causes algorithmic breakage in places which assume congruency between the data plane and the signaling plane. One of these places is AS path verification. This changes the question of whether or not a hack is deployed to mitigate the effects of RS hackiness, but simply what style of hack should be used. The current proposal is a mitigation approach, but can I propose an alternative approach, namely that the draft reintroduces congruence between the data plane and the signaling plane from the point of view of ASPA verification? I.e. if the WG opinion is to include RS's as being in scope, then the AS path that the aspa algorithm operates on should include the RS ASN, regardless of how the RS is transparent or non-transparent. Alternatively, if WG opinion is to exclude RS's from the scope of this draft, then ASPA should be handled on the basis that the RS ASN is deleted from the as path list. The only information necessary is whether the rs-client is aware that it's talking to a RS, but we already know that. If RS's are kept in scope, then the RS should be treated as a provider by the rs client; the rs client should include the RS ASN in its SPAS; the rs client should evaluate ASPA as if the RS ASN were included in the path; the rs should evaluate clients as customers If they're out of scope, then ASPA verification should elide the RS ASN from the AS PATH if it has not already been elided, and ASPA verification should proceed as if the two rs-client ASNs were directly connected and each should treat the other as a provider. Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] IXP Route Server question
Hi Shunwan, >> The ASPA verification draft treats the relationship of RS to RS-client >> as similar to that of Provider to Customer. Seems reasonable? The AS >> of an RS client includes the RS's AS in its ASPA as a "Provider". >IMO, the ASPA verification draft regards the relationship between RS and >RS-client as "peer-to-peer", That is not correct. >maybe my understanding is wrong, I will read the ASPA verification draft again. OK. Just FYI... the draft needs a revision. It does not contain yet the enhanced ASPA upstream/downstream verification algorithms/procedures. Not sure if you've followed sidrops discussions on the algorithms since January 2021. Some pointers: https://datatracker.ietf.org/meeting/110/materials/slides-110-sidrops-sriram-aspa-alg-accuracy-01 https://mailarchive.ietf.org/arch/msg/sidrops/C6Ethp2aC9sJsxDtBrLQDjmCqk4/ Thanks. Sriram ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] IXP Route Server question
Nick, >Ben Maddison wrote on 11/03/2022 07:23: >> Essential, I would think: how could a far end relying party know that >> an AS in the middle of a received AS_PATH is a non-transparent IXP RS >> in order to apply any other treatment? >given that they're a shrinking rarity, would it not make sense to completely >exclude non-transparent RSs from the ASPA definition? In the short term this >would cause problems for ASNs which connect to non-transparent RSs, but there >are hardly any left, and only one sizeable one. >I wonder whether it's a good idea to design a long term security mechanism >which includes a specific carve-out for a legacy corner case like this. Not sure why Ben even raised that question. To me, it doesn't seem relevant. In the route leak detection procedures, the receiving/validating AS does not require information about the nature of ASes (RS or not RS) in the AS Path except for the sending/neighbor AS which it knows to be an RS in case it knows itself to be an RS-client. The procedures rely only on ASPA objects for the origin AS and ASes in the middle. Sriram ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
