Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-00.txt
Thanks for the comments Jakob and for joining the draft. A new rev was just submitted. We are looking forward to working with you on this. I deleted that paragraph in the intro about pre-provisioning AS Prepends until we can come up with a solid solution. And the section on memory was updated. mike -Original Message- From: Jakob Heitz (jheitz) Sent: Saturday, October 31, 2020 10:57 PM To: Michael McBride Cc: grow@ietf.org Subject: RE: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-00.txt Michael, I support the document. I would not single out the incident of August in an RFC or indeed any other incident. BCPs are not created out of single incidents, but from a pattern emerging out of multiple incidents. It is enough to say that a certain scenario can occur and has occurred. Pre-provision of AS-prepend and then removing a prepend to the working ISP to prefer it over the failed ISP is not a solution. Suppose during normal operation you prepend to both of your transit providers. Then one of your providers can remove your prepends to gain an advantage over the other provider. Suppose the AS that wants to avoid the blackhole is not the origin AS of the route. If that AS were to pre-provision AS-prepends, then it would lose to other providers that don't. I notice that section 3.4 is a copy of one of my emails to the list. I did not intend for that to be placed into an RFC, but as some background for how memory is actually used. For the RFC, I would rephrase it as so: vvv Long AS-paths cause an increase in memory usage by BGP speakers. The memory usage is not so much a concern in the control plane BGP implementations, but more so when AS-paths are included in Netflow messages. Netflow is processed in the forwarding plane, where memory is more expensive than in the control plane. A concern about an AS-path longer than 255 is the extra complexity required to process it, because it needs to be encoded in more than one AS_SEQUENCE in the AS_PATH BGP path attribute. ^^^ Having contributed actual text to the draft, I'm happy to be co-author. Regards, Jakob. -Original Message- From: GROW On Behalf Of Michael McBride Sent: Friday, October 30, 2020 12:01 PM To: Jeffrey Haas Cc: grow@ietf.org Subject: Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-00.txt Thank you Jeffrey. We just update the draft with your comments. Perhaps we can discuss a bit more on the upcoming grow wg call. mike -Original Message- From: Jeffrey Haas Sent: Tuesday, October 27, 2020 1:49 PM To: Michael McBride Cc: grow@ietf.org Subject: Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-00.txt I'm rather far behind in my mail, but hopefully current on this thread. A few comments on the adopted draft: The thing I find most worthy in this document is the discussion about how excessive prepending increases your vulnerability to route hijacking. This issue will exist whenever you have a well connected peer that is willing to forge their AS_PATH. It's probably worth the general nod to bgpsec because it implies how you don't get out of that problem without locking down the contents of the as path. The well connected peer issue is inferred in 3.1. While I agree with Jakob's comments that lead to the updated section 3.4 text, trying to normalize "avoid other people's bugs" is awkward at best. 3.5 similarly fits in that category. Section 4 is a nice start to describing the solution space, but is problematic on a few levels: - Scoping communities from your directly attached ISP may not help you in some circumstances. - More specifics is a hard yank on traffic - if you're even permitted to originate them. If you're not lucky, your prefix is already so long from being a small service provider that you can't make it longer. - BGP origin code as a high order tie-breaker is a technique that works well, but only at places where as-paths are of equivalent length. For many situations resulting in long paths, I'm not sure that helps. Section 5's guidance of "no more than 5 prepends" is probably fine these days, but that is largely a matter of the current diameter of the Internet. Section 7 - Security Considerations - could likely use a paragraph discussing how long prepending may make you more vulernable to route hijacking. Feedback on the contents done, a personal anecdote: Just prior to 2000, I used to work for a small regional ISP. That ISP was multi-homed to a tier one and two tier two providers, each of which were trying to fight their way into tier-one space. Our motivations for our multihoming were one part resiliency, one part cheapest bandwidth for the dollar, and one part the fact that connectivity at the time to specific sites meant that we had a strong reason to use a specific provider. It was our exp
Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-00.txt
Michael, I support the document. I would not single out the incident of August in an RFC or indeed any other incident. BCPs are not created out of single incidents, but from a pattern emerging out of multiple incidents. It is enough to say that a certain scenario can occur and has occurred. Pre-provision of AS-prepend and then removing a prepend to the working ISP to prefer it over the failed ISP is not a solution. Suppose during normal operation you prepend to both of your transit providers. Then one of your providers can remove your prepends to gain an advantage over the other provider. Suppose the AS that wants to avoid the blackhole is not the origin AS of the route. If that AS were to pre-provision AS-prepends, then it would lose to other providers that don't. I notice that section 3.4 is a copy of one of my emails to the list. I did not intend for that to be placed into an RFC, but as some background for how memory is actually used. For the RFC, I would rephrase it as so: vvv Long AS-paths cause an increase in memory usage by BGP speakers. The memory usage is not so much a concern in the control plane BGP implementations, but more so when AS-paths are included in Netflow messages. Netflow is processed in the forwarding plane, where memory is more expensive than in the control plane. A concern about an AS-path longer than 255 is the extra complexity required to process it, because it needs to be encoded in more than one AS_SEQUENCE in the AS_PATH BGP path attribute. ^^^ Having contributed actual text to the draft, I'm happy to be co-author. Regards, Jakob. -Original Message- From: GROW On Behalf Of Michael McBride Sent: Friday, October 30, 2020 12:01 PM To: Jeffrey Haas Cc: grow@ietf.org Subject: Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-00.txt Thank you Jeffrey. We just update the draft with your comments. Perhaps we can discuss a bit more on the upcoming grow wg call. mike -Original Message- From: Jeffrey Haas Sent: Tuesday, October 27, 2020 1:49 PM To: Michael McBride Cc: grow@ietf.org Subject: Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-00.txt I'm rather far behind in my mail, but hopefully current on this thread. A few comments on the adopted draft: The thing I find most worthy in this document is the discussion about how excessive prepending increases your vulnerability to route hijacking. This issue will exist whenever you have a well connected peer that is willing to forge their AS_PATH. It's probably worth the general nod to bgpsec because it implies how you don't get out of that problem without locking down the contents of the as path. The well connected peer issue is inferred in 3.1. While I agree with Jakob's comments that lead to the updated section 3.4 text, trying to normalize "avoid other people's bugs" is awkward at best. 3.5 similarly fits in that category. Section 4 is a nice start to describing the solution space, but is problematic on a few levels: - Scoping communities from your directly attached ISP may not help you in some circumstances. - More specifics is a hard yank on traffic - if you're even permitted to originate them. If you're not lucky, your prefix is already so long from being a small service provider that you can't make it longer. - BGP origin code as a high order tie-breaker is a technique that works well, but only at places where as-paths are of equivalent length. For many situations resulting in long paths, I'm not sure that helps. Section 5's guidance of "no more than 5 prepends" is probably fine these days, but that is largely a matter of the current diameter of the Internet. Section 7 - Security Considerations - could likely use a paragraph discussing how long prepending may make you more vulernable to route hijacking. Feedback on the contents done, a personal anecdote: Just prior to 2000, I used to work for a small regional ISP. That ISP was multi-homed to a tier one and two tier two providers, each of which were trying to fight their way into tier-one space. Our motivations for our multihoming were one part resiliency, one part cheapest bandwidth for the dollar, and one part the fact that connectivity at the time to specific sites meant that we had a strong reason to use a specific provider. It was our experience at that time that it was necessary to use prepends in the range of 3-5 for portions of our address space in order to try to provide appropriate inbound load balancing. The number was that high because at the points we were trying to balance traffic for, the denseness of the Internet topology meant that the unpadded routes were often getting closely tied for path length. Prepending wasn't a complete panacea. We regularly experienced traffic spikes after traffic rebalancing until we found a prepend length that was stable
Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-00.txt
Thank you Jeffrey. We just update the draft with your comments. Perhaps we can discuss a bit more on the upcoming grow wg call. mike -Original Message- From: Jeffrey Haas Sent: Tuesday, October 27, 2020 1:49 PM To: Michael McBride Cc: grow@ietf.org Subject: Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-00.txt I'm rather far behind in my mail, but hopefully current on this thread. A few comments on the adopted draft: The thing I find most worthy in this document is the discussion about how excessive prepending increases your vulnerability to route hijacking. This issue will exist whenever you have a well connected peer that is willing to forge their AS_PATH. It's probably worth the general nod to bgpsec because it implies how you don't get out of that problem without locking down the contents of the as path. The well connected peer issue is inferred in 3.1. While I agree with Jakob's comments that lead to the updated section 3.4 text, trying to normalize "avoid other people's bugs" is awkward at best. 3.5 similarly fits in that category. Section 4 is a nice start to describing the solution space, but is problematic on a few levels: - Scoping communities from your directly attached ISP may not help you in some circumstances. - More specifics is a hard yank on traffic - if you're even permitted to originate them. If you're not lucky, your prefix is already so long from being a small service provider that you can't make it longer. - BGP origin code as a high order tie-breaker is a technique that works well, but only at places where as-paths are of equivalent length. For many situations resulting in long paths, I'm not sure that helps. Section 5's guidance of "no more than 5 prepends" is probably fine these days, but that is largely a matter of the current diameter of the Internet. Section 7 - Security Considerations - could likely use a paragraph discussing how long prepending may make you more vulernable to route hijacking. Feedback on the contents done, a personal anecdote: Just prior to 2000, I used to work for a small regional ISP. That ISP was multi-homed to a tier one and two tier two providers, each of which were trying to fight their way into tier-one space. Our motivations for our multihoming were one part resiliency, one part cheapest bandwidth for the dollar, and one part the fact that connectivity at the time to specific sites meant that we had a strong reason to use a specific provider. It was our experience at that time that it was necessary to use prepends in the range of 3-5 for portions of our address space in order to try to provide appropriate inbound load balancing. The number was that high because at the points we were trying to balance traffic for, the denseness of the Internet topology meant that the unpadded routes were often getting closely tied for path length. Prepending wasn't a complete panacea. We regularly experienced traffic spikes after traffic rebalancing until we found a prepend length that was stable enough. I recognize at this point that we were suffering from the effects of BGP Wedgies. (See RFC 4264.) I've been out of the operator game for a very long time. We've generally seen the diameter of the Internet decrease since I was in the business. The problems I was solving at the time still exist, but aren't quite as severe in the well connected bits of the Internet. I would not be shocked if some of the far corners of the Internet still need this for similar motivations than my employer had twenty years ago. I will offer one final bit of feedback: Some customers simply filter very long AS_PATHs. The issues noted in this draft are effectively self correcting in the presence of aggressive filter policies. On Tue, Sep 08, 2020 at 05:16:30PM +, Michael McBride wrote: > Hello wg, > > We have addressed all comments so far. Thank you. We still need to expand the > prepend alternatives section. Please give it another look and let's see what > else should be included. > > mike > > -Original Message- > From: GROW On Behalf Of > internet-dra...@ietf.org > Sent: Tuesday, September 08, 2020 9:58 AM > To: i-d-annou...@ietf.org > Cc: grow@ietf.org > Subject: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Global Routing Operations WG of the IETF. > > Title : AS Path Prepending > Authors : Mike McBride > Doug Madory > Jeff Tantsura > Robert Raszuk > Hongwei Li > Filename: draft-ietf-grow-as-path-prepending-00.txt > Pages : 10 > Date
Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-00.txt
I'm rather far behind in my mail, but hopefully current on this thread. A few comments on the adopted draft: The thing I find most worthy in this document is the discussion about how excessive prepending increases your vulnerability to route hijacking. This issue will exist whenever you have a well connected peer that is willing to forge their AS_PATH. It's probably worth the general nod to bgpsec because it implies how you don't get out of that problem without locking down the contents of the as path. The well connected peer issue is inferred in 3.1. While I agree with Jakob's comments that lead to the updated section 3.4 text, trying to normalize "avoid other people's bugs" is awkward at best. 3.5 similarly fits in that category. Section 4 is a nice start to describing the solution space, but is problematic on a few levels: - Scoping communities from your directly attached ISP may not help you in some circumstances. - More specifics is a hard yank on traffic - if you're even permitted to originate them. If you're not lucky, your prefix is already so long from being a small service provider that you can't make it longer. - BGP origin code as a high order tie-breaker is a technique that works well, but only at places where as-paths are of equivalent length. For many situations resulting in long paths, I'm not sure that helps. Section 5's guidance of "no more than 5 prepends" is probably fine these days, but that is largely a matter of the current diameter of the Internet. Section 7 - Security Considerations - could likely use a paragraph discussing how long prepending may make you more vulernable to route hijacking. Feedback on the contents done, a personal anecdote: Just prior to 2000, I used to work for a small regional ISP. That ISP was multi-homed to a tier one and two tier two providers, each of which were trying to fight their way into tier-one space. Our motivations for our multihoming were one part resiliency, one part cheapest bandwidth for the dollar, and one part the fact that connectivity at the time to specific sites meant that we had a strong reason to use a specific provider. It was our experience at that time that it was necessary to use prepends in the range of 3-5 for portions of our address space in order to try to provide appropriate inbound load balancing. The number was that high because at the points we were trying to balance traffic for, the denseness of the Internet topology meant that the unpadded routes were often getting closely tied for path length. Prepending wasn't a complete panacea. We regularly experienced traffic spikes after traffic rebalancing until we found a prepend length that was stable enough. I recognize at this point that we were suffering from the effects of BGP Wedgies. (See RFC 4264.) I've been out of the operator game for a very long time. We've generally seen the diameter of the Internet decrease since I was in the business. The problems I was solving at the time still exist, but aren't quite as severe in the well connected bits of the Internet. I would not be shocked if some of the far corners of the Internet still need this for similar motivations than my employer had twenty years ago. I will offer one final bit of feedback: Some customers simply filter very long AS_PATHs. The issues noted in this draft are effectively self correcting in the presence of aggressive filter policies. On Tue, Sep 08, 2020 at 05:16:30PM +, Michael McBride wrote: > Hello wg, > > We have addressed all comments so far. Thank you. We still need to expand the > prepend alternatives section. Please give it another look and let's see what > else should be included. > > mike > > -Original Message- > From: GROW On Behalf Of internet-dra...@ietf.org > Sent: Tuesday, September 08, 2020 9:58 AM > To: i-d-annou...@ietf.org > Cc: grow@ietf.org > Subject: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Global Routing Operations WG of the IETF. > > Title : AS Path Prepending > Authors : Mike McBride > Doug Madory > Jeff Tantsura > Robert Raszuk > Hongwei Li > Filename: draft-ietf-grow-as-path-prepending-00.txt > Pages : 10 > Date: 2020-09-08 -- Jeff ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-00.txt
Hello wg, We have addressed all comments so far. Thank you. We still need to expand the prepend alternatives section. Please give it another look and let's see what else should be included. mike -Original Message- From: GROW On Behalf Of internet-dra...@ietf.org Sent: Tuesday, September 08, 2020 9:58 AM To: i-d-annou...@ietf.org Cc: grow@ietf.org Subject: [GROW] I-D Action: draft-ietf-grow-as-path-prepending-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Global Routing Operations WG of the IETF. Title : AS Path Prepending Authors : Mike McBride Doug Madory Jeff Tantsura Robert Raszuk Hongwei Li Filename: draft-ietf-grow-as-path-prepending-00.txt Pages : 10 Date: 2020-09-08 Abstract: AS Path Prepending provides a tool to manipulate the BGP AS_Path attribute through prepending multiple entries of an AS. AS Path Prepending is used to deprioritize a route or alternate path. By prepending the local ASN multiple times, ASs can make advertised AS paths appear artificially longer. Excessive AS Path Prepending has caused routing issues in the internet. This document provides guidance,to the internet community, with how best to utilize AS Path Prepending in order to avoid negatively affecting the internet. The IETF datatracker status page for this draft is: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-grow-as-path-prepending%2Fdata=02%7C01%7Cmichael.mcbride%40futurewei.com%7C85f99135145d40bb677908d854186d26%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637351811189628159sdata=xR6LSEovFVpZ2L6RT4LB2oIpW7sDkkK19I1W9J4inEA%3Dreserved=0 There are also htmlized versions available at: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-grow-as-path-prepending-00data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C85f99135145d40bb677908d854186d26%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637351811189628159sdata=89D6qips6Kl%2BKzRVuBW3B30OUTbA2DFgvC%2F2mLWlkHY%3Dreserved=0 https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-grow-as-path-prepending-00data=02%7C01%7Cmichael.mcbride%40futurewei.com%7C85f99135145d40bb677908d854186d26%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637351811189628159sdata=m1nFaNxtfEoWMRXUIzhl2j%2B9CaYgmXcNeT4RiNFs8vw%3Dreserved=0 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: https://nam11.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Fftp.ietf.org%2Finternet-drafts%2Fdata=02%7C01%7Cmichael.mcbride%40futurewei.com%7C85f99135145d40bb677908d854186d26%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637351811189628159sdata=r4IovzlIk4d1KdnWoQzZ772pKNPgy2FwOY71vJEh0es%3Dreserved=0 ___ GROW mailing list GROW@ietf.org https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fgrowdata=02%7C01%7Cmichael.mcbride%40futurewei.com%7C85f99135145d40bb677908d854186d26%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637351811189628159sdata=%2BmQnF9Nd2oufiNN%2FynuGxsgWZWCsbgVuWONpAM4J1Lc%3Dreserved=0 ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
[GROW] I-D Action: draft-ietf-grow-as-path-prepending-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Global Routing Operations WG of the IETF. Title : AS Path Prepending Authors : Mike McBride Doug Madory Jeff Tantsura Robert Raszuk Hongwei Li Filename: draft-ietf-grow-as-path-prepending-00.txt Pages : 10 Date: 2020-09-08 Abstract: AS Path Prepending provides a tool to manipulate the BGP AS_Path attribute through prepending multiple entries of an AS. AS Path Prepending is used to deprioritize a route or alternate path. By prepending the local ASN multiple times, ASs can make advertised AS paths appear artificially longer. Excessive AS Path Prepending has caused routing issues in the internet. This document provides guidance,to the internet community, with how best to utilize AS Path Prepending in order to avoid negatively affecting the internet. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-grow-as-path-prepending/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-grow-as-path-prepending-00 https://datatracker.ietf.org/doc/html/draft-ietf-grow-as-path-prepending-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
