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] 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
Re: [GROW] IXP Route Server question
> 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. i do not wonder about adding complexity to specs and code in a security application. i know it's a bad idea. randy ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] IXP Route Server question
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. Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] IXP Route Server question
Hi Sriram, > 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", maybe my understanding is wrong, I will read the ASPA verification draft again. BR, Shunwan > -Original Message- > From: GROW [mailto:grow-boun...@ietf.org] On Behalf Of Sriram, > Kotikalapudi (Fed) > Sent: Thursday, March 10, 2022 11:31 AM > To: Nick Hilliard > Cc: grow@ietf.org; sidr...@ietf.org > Subject: Re: [GROW] IXP Route Server question > > Nick and all, > > Thank you. What you all shared/discussed is very useful info. > > >Almost all RS's are transparent these days. Usually IXPs go to lengths to > ensure that the RS ASN doesn't appear in the AS path. > > Good to know that. Well, that means there can be an occasional RS that is > non-transparent. When there is a non-transparent RS, could there be big ISPs > (Tier-1, Tier-2) present there as RS-clients? > > 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". > > Sriram > > -Original Message- > From: Nick Hilliard > Sent: Tuesday, March 8, 2022 4:28 PM > To: Sriram, Kotikalapudi (Fed) > Cc: grow@ietf.org; sidr...@ietf.org > Subject: Re: [GROW] IXP Route Server question > > Sriram, Kotikalapudi (Fed) wrote on 08/03/2022 19:36: > > This question has relevance to the ASPA method for route leak > > detection. > > > > Is it possible that an ISP AS A peers with a customer AS C via a > > non-transparent IXP AS B? > > IOW, the AS path in routes propagated by the ISP A for customer C's > > prefixes looks like this: A B C. > > I.e., can the AS of a non-transparent IXP/RS appear in an AS path in > > the middle between an ISP and its customer? > > Almost all RS's are transparent these days. Usually IXPs go to lengths to > ensure that the RS ASN doesn't appear in the AS path. > > Some organisations provide transit over IXPs, but it's a minority thing. > It would be very peculiar if an organisation provided transit over an IXP via > an RS. > > Some organisations provide transit to ASNs over a direct physical connection > while maintain peering with their customer over an IXP port. > Usually this happens by accident, but occasionally it can happen by design. > > The answer to your question is that it would be technically possible, but it > would be so peculiar and stupid that it should be considered a mistake in the > situations where it was intentional. In all other situations, it would be a > leak. > Generally it would be safe to assume that this sort of configuration was in > error. > > Nick > ___ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] IXP Route Server question
Sounds good. Thank you so much for the discussions and info. Sriram -Original Message- From: Ben Maddison Sent: Friday, March 11, 2022 2:23 AM To: Nick Hilliard Cc: Sriram, Kotikalapudi (Fed) ; grow@ietf.org; sidr...@ietf.org Subject: Re: [GROW] IXP Route Server question Hi Sriram, On 03/10, Nick Hilliard wrote: > Sriram, Kotikalapudi (Fed) wrote on 10/03/2022 03:31: [...] > > 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". > > yes, this is reasonable. > 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? A special mark in the ASPA itself perhaps, but yuk ;-) Cheers, Ben ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] IXP Route Server question
Hi Sriram, On 03/10, Nick Hilliard wrote: > Sriram, Kotikalapudi (Fed) wrote on 10/03/2022 03:31: [...] > > 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". > > yes, this is reasonable. > 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? A special mark in the ASPA itself perhaps, but yuk ;-) Cheers, Ben signature.asc Description: PGP signature ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] IXP Route Server question
Sriram, Kotikalapudi (Fed) wrote on 10/03/2022 03:31: Nick and all, Thank you. What you all shared/discussed is very useful info. Almost all RS's are transparent these days. Usually IXPs go to lengths to ensure that the RS ASN doesn't appear in the AS path. Good to know that. Well, that means there can be an occasional RS that is non-transparent. When there is a non-transparent RS, could there be big ISPs (Tier-1, Tier-2) present there as RS-clients? I would seriously doubt it. There are some "Tier 1" and "Tier 2" providers who peer using route servers at IXPs, but it's a bit unusual (and entertaining to hear them strenuously denying that this ever happens). Non-transparent RS's were used until a couple of years ago but I'm not aware of any left at this point. Even when non-transparent RS's were more widespread, I would have expected the intersection of these two groups to be null, and that if there were an intersection, the Tier1/Tier2 providers would not be upset if those paths were dropped / marked as invalid. 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". yes, this is reasonable. Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] IXP Route Server question
Nick and all, Thank you. What you all shared/discussed is very useful info. >Almost all RS's are transparent these days. Usually IXPs go to lengths to >ensure that the RS ASN doesn't appear in the AS path. Good to know that. Well, that means there can be an occasional RS that is non-transparent. When there is a non-transparent RS, could there be big ISPs (Tier-1, Tier-2) present there as RS-clients? 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". Sriram -Original Message- From: Nick Hilliard Sent: Tuesday, March 8, 2022 4:28 PM To: Sriram, Kotikalapudi (Fed) Cc: grow@ietf.org; sidr...@ietf.org Subject: Re: [GROW] IXP Route Server question Sriram, Kotikalapudi (Fed) wrote on 08/03/2022 19:36: > This question has relevance to the ASPA method for route leak > detection. > > Is it possible that an ISP AS A peers with a customer AS C via a > non-transparent IXP AS B? > IOW, the AS path in routes propagated by the ISP A for customer C's > prefixes looks like this: A B C. > I.e., can the AS of a non-transparent IXP/RS appear in an AS path in > the middle between an ISP and its customer? Almost all RS's are transparent these days. Usually IXPs go to lengths to ensure that the RS ASN doesn't appear in the AS path. Some organisations provide transit over IXPs, but it's a minority thing. It would be very peculiar if an organisation provided transit over an IXP via an RS. Some organisations provide transit to ASNs over a direct physical connection while maintain peering with their customer over an IXP port. Usually this happens by accident, but occasionally it can happen by design. The answer to your question is that it would be technically possible, but it would be so peculiar and stupid that it should be considered a mistake in the situations where it was intentional. In all other situations, it would be a leak. Generally it would be safe to assume that this sort of configuration was in error. Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] IXP Route Server question
Sriram, Kotikalapudi (Fed) wrote on 08/03/2022 19:36: This question has relevance to the ASPA method for route leak detection. Is it possible that an ISP AS A peers with a customer AS C via a non-transparent IXP AS B? IOW, the AS path in routes propagated by the ISP A for customer C's prefixes looks like this: A B C. I.e., can the AS of a non-transparent IXP/RS appear in an AS path in the middle between an ISP and its customer? Almost all RS's are transparent these days. Usually IXPs go to lengths to ensure that the RS ASN doesn't appear in the AS path. Some organisations provide transit over IXPs, but it's a minority thing. It would be very peculiar if an organisation provided transit over an IXP via an RS. Some organisations provide transit to ASNs over a direct physical connection while maintain peering with their customer over an IXP port. Usually this happens by accident, but occasionally it can happen by design. The answer to your question is that it would be technically possible, but it would be so peculiar and stupid that it should be considered a mistake in the situations where it was intentional. In all other situations, it would be a leak. Generally it would be safe to assume that this sort of configuration was in error. Nick ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
