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] [Sidrops] IXP Route Server question
Ben, >I know of several transit providers that will allow customers to use an IXP as >a kind of virtual access circuit (which itself is a poor idea), but I would be >*very* surprised if any of them allow RS peerings to be the control plane >interconnection (intentionally, at least). Good. Thanks for that insight. Consistent with what Nick and others observed. >If the underlying question is "should the ASPA path validation algorithm have >a corner case that accommodates this?", that is a very, very firm "no" from me! No. I didn't have that question or idea in mind. But see a couple of other new questions I asked in my reply to Nick. Thank you. Sriram ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Sidrops] IXP Route Server question
>> If the underlying question is "should the ASPA path validation >> algorithm have a corner case that accommodates this?", that is a >> very, very firm "no" from me! > > aol opologies, it seems i used an american idiom, and an antique one at that. a few folk were brave enough to ask, so ... tl;dr: precursor of +1 long, and probably somewhat incorrect, answer in the spirit of trying to keep net cultural history alive. someone better at net cultural history than i can probably point you to historical documents. back in the '80s, there were two large walled gardens of dial-up users, America Online (AOL) and CompuServe. when the pressure of the internet's success started forcing their gates, the first breach was gateways to the usenet. aol citizens were over enthusiastic eager beavers known for "meee tooo!" so the first shorthand for "me too" became "aol." i am not sure when "+1" came in, but a decade or so later. maybe folk had to learn to count first. along a similar vein, the precursor to the SWAT attack was having a truckload of compuserve install cd-roms sent to someone's home. i am not sure it was actually done, or was just apocrypha. randy ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Sidrops] IXP Route Server question
> If the underlying question is "should the ASPA path validation > algorithm have a corner case that accommodates this?", that is a > very, very firm "no" from me! aol ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Sidrops] IXP Route Server question
On 03/08, Christopher Morrow wrote: > On Tue, Mar 8, 2022 at 2:36 PM Sriram, Kotikalapudi (Fed) > wrote: > > > 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? > > > > > it seems unlikely to me that an ISP would pick up a 'customer' (someone > that pays them to transport packets) at an IXP fabric. > Might it happen? sure? is it messy? yes! > I know of several transit providers that will allow customers to use an IXP as a kind of virtual access circuit (which itself is a poor idea), but I would be *very* surprised if any of them allow RS peerings to be the control plane interconnection (intentionally, at least). If the underlying question is "should the ASPA path validation algorithm have a corner case that accommodates this?", that is a very, very firm "no" from me! Cheers, Ben signature.asc Description: PGP signature ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] [Sidrops] IXP Route Server question
On Tue, Mar 8, 2022 at 3:33 PM Robert Raszuk wrote: > > Right - but IMO route leaking can happen both in the Internet or in > customer <- via IXP -> content provider interconnects. > > And in the latter case - especially for those with open peering policy - > often going via RS. After all this is how route servers are mainly used > today :) So both sides will be peering to IXP RS while IXP RS will (in most > cases) not appear in the AS_PATH. > > > sure! that was my re-wording of sriram's question, effectively. (or I think that was the re-wording!) > > > On Tue, Mar 8, 2022 at 9:26 PM Christopher Morrow < > christopher.mor...@gmail.com> wrote: > >> >> >> On Tue, Mar 8, 2022 at 3:15 PM Robert Raszuk wrote: >> >>> Well I think the answer is - it depends. >>> >>> First IXP fabric can be used as pure L3 share LAN or can be used (and it >>> is often the case) as a p2p emulated VLAN over such L3 shared LAN. >>> >>> Now if this is L3 shared LAN still customer and ISP may peer directly >>> and no third party traffic would be accepted at either end. >>> >>> If we talk about emulating L2 IXP fabric becomes just an emulated >>> circuit and from the perspective of routing it a p2p interface. >>> >>> Sure the other aspects of the IXP quality, port monitoring, >>> oversubscription etc... always will apply but there are ways to mitigate or >>> handle those in real IXPs. >>> >>> >> I don't dispute your content here, except that Sriram's question was >> about seeing 'customer routes via the RS'... which I think would obviate >> the emulation examples you provided. >> (well in a bunch of cases it would, you COULD hook up some tomfoolery to >> get this to work, but... that sounds complex and prone to disaster) >> >> >>> Best, >>> R. >>> >>> >>> >>> >>> >>> >>> >>> >>> On Tue, Mar 8, 2022 at 9:05 PM Christopher Morrow < >>> christopher.mor...@gmail.com> wrote: >>> On Tue, Mar 8, 2022 at 2:36 PM Sriram, Kotikalapudi (Fed) wrote: > 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? > > it seems unlikely to me that an ISP would pick up a 'customer' (someone that pays them to transport packets) at an IXP fabric. Might it happen? sure? is it messy? yes! 1) that's probably a shared port 2) there are other folk feeding routes and packets into the mix 3) how many came through the 'customer' port (which you can't really know easily) vs other participants on the ix 4) what capacity planning could the 'customer' do here? (none, basically with respect to the remote ISP port) Your question might work also as: "ISP A has a customer C on a direct link in location Y. ISP A is present at IXP-Z, so is customer C, though they do not bilaterally peer (not do they interconnect at the IXP). ISP A can still see Customer C's routes through the IXP-Z Route Server." that seems plausible, but not a desired outcome for the ISP :) since they will be unlikely to collect pesos for the traffic which MAY pass across that interconnect. ___ 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] [Sidrops] IXP Route Server question
Right - but IMO route leaking can happen both in the Internet or in customer <- via IXP -> content provider interconnects. And in the latter case - especially for those with open peering policy - often going via RS. After all this is how route servers are mainly used today :) So both sides will be peering to IXP RS while IXP RS will (in most cases) not appear in the AS_PATH. Kind regards, R. On Tue, Mar 8, 2022 at 9:26 PM Christopher Morrow < christopher.mor...@gmail.com> wrote: > > > On Tue, Mar 8, 2022 at 3:15 PM Robert Raszuk wrote: > >> Well I think the answer is - it depends. >> >> First IXP fabric can be used as pure L3 share LAN or can be used (and it >> is often the case) as a p2p emulated VLAN over such L3 shared LAN. >> >> Now if this is L3 shared LAN still customer and ISP may peer directly and >> no third party traffic would be accepted at either end. >> >> If we talk about emulating L2 IXP fabric becomes just an emulated circuit >> and from the perspective of routing it a p2p interface. >> >> Sure the other aspects of the IXP quality, port monitoring, >> oversubscription etc... always will apply but there are ways to mitigate or >> handle those in real IXPs. >> >> > I don't dispute your content here, except that Sriram's question was about > seeing 'customer routes via the RS'... which I think would obviate the > emulation examples you provided. > (well in a bunch of cases it would, you COULD hook up some tomfoolery to > get this to work, but... that sounds complex and prone to disaster) > > >> Best, >> R. >> >> >> >> >> >> >> >> >> On Tue, Mar 8, 2022 at 9:05 PM Christopher Morrow < >> christopher.mor...@gmail.com> wrote: >> >>> >>> >>> On Tue, Mar 8, 2022 at 2:36 PM Sriram, Kotikalapudi (Fed) >>> wrote: >>> 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? >>> it seems unlikely to me that an ISP would pick up a 'customer' (someone >>> that pays them to transport packets) at an IXP fabric. >>> Might it happen? sure? is it messy? yes! >>> >>> 1) that's probably a shared port >>> 2) there are other folk feeding routes and packets into the mix >>> 3) how many came through the 'customer' port (which you can't really >>> know easily) vs other participants on the ix >>> 4) what capacity planning could the 'customer' do here? (none, basically >>> with respect to the remote ISP port) >>> >>> Your question might work also as: >>> "ISP A has a customer C on a direct link in location Y. >>>ISP A is present at IXP-Z, so is customer C, though they do not >>> bilaterally peer (not do they interconnect at the IXP). >>> ISP A can still see Customer C's routes through the IXP-Z Route >>> Server." >>> >>> that seems plausible, but not a desired outcome for the ISP :) since >>> they will be unlikely to collect pesos for the traffic >>> which MAY pass across that interconnect. >>> >>> ___ >>> 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] [Sidrops] IXP Route Server question
On Tue, Mar 8, 2022 at 3:15 PM Robert Raszuk wrote: > Well I think the answer is - it depends. > > First IXP fabric can be used as pure L3 share LAN or can be used (and it > is often the case) as a p2p emulated VLAN over such L3 shared LAN. > > Now if this is L3 shared LAN still customer and ISP may peer directly and > no third party traffic would be accepted at either end. > > If we talk about emulating L2 IXP fabric becomes just an emulated circuit > and from the perspective of routing it a p2p interface. > > Sure the other aspects of the IXP quality, port monitoring, > oversubscription etc... always will apply but there are ways to mitigate or > handle those in real IXPs. > > I don't dispute your content here, except that Sriram's question was about seeing 'customer routes via the RS'... which I think would obviate the emulation examples you provided. (well in a bunch of cases it would, you COULD hook up some tomfoolery to get this to work, but... that sounds complex and prone to disaster) > Best, > R. > > > > > > > > > On Tue, Mar 8, 2022 at 9:05 PM Christopher Morrow < > christopher.mor...@gmail.com> wrote: > >> >> >> On Tue, Mar 8, 2022 at 2:36 PM Sriram, Kotikalapudi (Fed) >> wrote: >> >>> 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? >>> >>> >> it seems unlikely to me that an ISP would pick up a 'customer' (someone >> that pays them to transport packets) at an IXP fabric. >> Might it happen? sure? is it messy? yes! >> >> 1) that's probably a shared port >> 2) there are other folk feeding routes and packets into the mix >> 3) how many came through the 'customer' port (which you can't really know >> easily) vs other participants on the ix >> 4) what capacity planning could the 'customer' do here? (none, basically >> with respect to the remote ISP port) >> >> Your question might work also as: >> "ISP A has a customer C on a direct link in location Y. >>ISP A is present at IXP-Z, so is customer C, though they do not >> bilaterally peer (not do they interconnect at the IXP). >> ISP A can still see Customer C's routes through the IXP-Z Route Server." >> >> that seems plausible, but not a desired outcome for the ISP :) since they >> will be unlikely to collect pesos for the traffic >> which MAY pass across that interconnect. >> >> ___ >> 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] [Sidrops] IXP Route Server question
Well I think the answer is - it depends. First IXP fabric can be used as pure L3 share LAN or can be used (and it is often the case) as a p2p emulated VLAN over such L3 shared LAN. Now if this is L3 shared LAN still customer and ISP may peer directly and no third party traffic would be accepted at either end. If we talk about emulating L2 IXP fabric becomes just an emulated circuit and from the perspective of routing it a p2p interface. Sure the other aspects of the IXP quality, port monitoring, oversubscription etc... always will apply but there are ways to mitigate or handle those in real IXPs. Best, R. On Tue, Mar 8, 2022 at 9:05 PM Christopher Morrow < christopher.mor...@gmail.com> wrote: > > > On Tue, Mar 8, 2022 at 2:36 PM Sriram, Kotikalapudi (Fed) > wrote: > >> 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? >> >> > it seems unlikely to me that an ISP would pick up a 'customer' (someone > that pays them to transport packets) at an IXP fabric. > Might it happen? sure? is it messy? yes! > > 1) that's probably a shared port > 2) there are other folk feeding routes and packets into the mix > 3) how many came through the 'customer' port (which you can't really know > easily) vs other participants on the ix > 4) what capacity planning could the 'customer' do here? (none, basically > with respect to the remote ISP port) > > Your question might work also as: > "ISP A has a customer C on a direct link in location Y. >ISP A is present at IXP-Z, so is customer C, though they do not > bilaterally peer (not do they interconnect at the IXP). > ISP A can still see Customer C's routes through the IXP-Z Route Server." > > that seems plausible, but not a desired outcome for the ISP :) since they > will be unlikely to collect pesos for the traffic > which MAY pass across that interconnect. > > ___ > 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] [Sidrops] IXP Route Server question
On Tue, Mar 8, 2022 at 2:36 PM Sriram, Kotikalapudi (Fed) wrote: > 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? > > it seems unlikely to me that an ISP would pick up a 'customer' (someone that pays them to transport packets) at an IXP fabric. Might it happen? sure? is it messy? yes! 1) that's probably a shared port 2) there are other folk feeding routes and packets into the mix 3) how many came through the 'customer' port (which you can't really know easily) vs other participants on the ix 4) what capacity planning could the 'customer' do here? (none, basically with respect to the remote ISP port) Your question might work also as: "ISP A has a customer C on a direct link in location Y. ISP A is present at IXP-Z, so is customer C, though they do not bilaterally peer (not do they interconnect at the IXP). ISP A can still see Customer C's routes through the IXP-Z Route Server." that seems plausible, but not a desired outcome for the ISP :) since they will be unlikely to collect pesos for the traffic which MAY pass across that interconnect. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
