An ISP offers to announce our prefix. Is that normal?
Hi, I have a question about the validly of an option provided by our ISP. Back story: We will move one of your office uplinks in germany next year to an other provider. They offered us various options how it could be implemented. In my personal option one option sounds technical crazier then the other, even that it is "enterprise". The management involved raised concern when the ISP noticed that if we wanna use "just BGP" we will loose any SLA for L3 services. With no doubt I see managements point but now it comes: Then the ISP offered us to announce _our_ prefix for us, from their ASN, and here I lost trust, and stopped the planning for now to get either confirmation or an other red flag. - Is this even "allowed" or recommend by RIPE policies or BCPs? - Wouldn't that be at least looks like a/an BGP hijacking (attempt)? Because I have not seen / read about that implementation anywhere... - Just in case this is ok-ish, how would I setup the ROA with RPKI so that it would be come valid? An other but related question: Regarding the "No SLA" thing: Could someone point me on how other ISPs handle this or what would be "industrial standard". I highly doubt the reasoning, that just because the customer is using his own gear that the ISP will get way with any disturbance of their service... Naive me thought that it would be like in your data center installations: You get transit v4 and v6 networks from the provider, configure BGP and are done. Yes this does not prevent a customer to mis-configure things but in this case we would just get a default route and announcing one or more prefixes. I hardly see any pitfalls here. Thanks in advise and for your time, Best, Bernd
On 11/12/19 12:16 PM, Bernd Naumann wrote:
Then the ISP offered us to announce _our_ prefix for us, from their ASN,
hi, this is BYOIP, Bring Your Own IP Addresses -- antonio
Dear Bernd, Good questions, thanks for bringing them up, this topic indeed doesn't receive much attention. I can't comment on the specifics of your case in regard to SLA and what the best choices are for your organisation, but I can share one small data point. On Tue, Nov 12, 2019 at 12:16:53PM +0100, Bernd Naumann wrote:
Then the ISP offered us to announce _our_ prefix for us, from their ASN, and here I lost trust, and stopped the planning for now to get either confirmation or an other red flag.
This actually is a common practise! Speaking from NTT's perspective we see that customer's used to run BGP in the past, but no longer have interest in maintaining that infrastructure and switch to a "Direct Internet Access" (DIA) product which usually is statically routing the IP space and perhaps using a first-hop redundancy protocol. In such cases the customers request NTT to announce the space on their behalf - which we can do provided that a RPKI ROA and IRR route object are created to demonstrate to the world that we in fact are allowed to originate the prefix.
- Is this even "allowed" or recommend by RIPE policies or BCPs?
yes, this is allowed; and if it adequately addresses the challenges you are trying to solve for your organisation I'd say it is even 'recommended' ;-) - the real answer is "it depends".
- Wouldn't that be at least looks like a/an BGP hijacking (attempt)?
it would not look like a BGP hijack if RPKI ROAs / IRR "route:/route6:" objects are created in the appropriate places authorising the ASN that originates the prefix.
- Just in case this is ok-ish, how would I setup the ROA with RPKI so that it would be come valid?
You'd go to the RIPE web portal, and create a RPKI ROA like you'd normally do, but instead of inputting your own ASN you input the ASN of the provider that will announce the space on your behalf. You create/have multiple ROAs covering the same prefix but with different Origin ASNs co-exist - this allows you to make-before-break in transitions such as you might be going through at this moment. A variant of the scenario you describe is "BYOIP" in context of the cloud providers. The analogy is that instead of routing your IP space to your office, some cloud providers offer to announce your IP space and route it to your virtual datacenter: https://aws.amazon.com/vpc/faqs/#Bring_Your_Own_IP https://developers.cloudflare.com/spectrum/getting-started/byoip/ https://cloud.ibm.com/docs/tutorials?topic=solution-tutorials-byoip https://www.zdnet.com/article/google-cloud-now-lets-you-bring-your-own-ip-ad... https://ideas.digitalocean.com/ideas/DO-I-566#:~:targetText=Support%20Bring%.... Your IP resources are yours*, and you are free to authorize anyone to route them on your behalf on the public internet. Kind regards, Job * not meaning to start debate about ownership, just wanted to emphasize that whether you do your own BGP or have someone do it on your behalf is the same.
If anyone could tell me how to get an ISP to 'un-announce' prefixes on your behalf I will buy them dinner. I have two prefixes of mine that PCCW won't to take down and at this point I have better chances of convincing Donald Trump to resign than I do getting PCCW to remove them from their announcements. J~ On 11/12/19, 6:48 AM, "members-discuss on behalf of Job Snijders" <members-discuss-bounces@ripe.net on behalf of job@ntt.net> wrote: Dear Bernd, Good questions, thanks for bringing them up, this topic indeed doesn't receive much attention. I can't comment on the specifics of your case in regard to SLA and what the best choices are for your organisation, but I can share one small data point. On Tue, Nov 12, 2019 at 12:16:53PM +0100, Bernd Naumann wrote: > Then the ISP offered us to announce _our_ prefix for us, from their > ASN, and here I lost trust, and stopped the planning for now to get > either confirmation or an other red flag. This actually is a common practise! Speaking from NTT's perspective we see that customer's used to run BGP in the past, but no longer have interest in maintaining that infrastructure and switch to a "Direct Internet Access" (DIA) product which usually is statically routing the IP space and perhaps using a first-hop redundancy protocol. In such cases the customers request NTT to announce the space on their behalf - which we can do provided that a RPKI ROA and IRR route object are created to demonstrate to the world that we in fact are allowed to originate the prefix. > - Is this even "allowed" or recommend by RIPE policies or BCPs? yes, this is allowed; and if it adequately addresses the challenges you are trying to solve for your organisation I'd say it is even 'recommended' ;-) - the real answer is "it depends". > - Wouldn't that be at least looks like a/an BGP hijacking (attempt)? it would not look like a BGP hijack if RPKI ROAs / IRR "route:/route6:" objects are created in the appropriate places authorising the ASN that originates the prefix. > - Just in case this is ok-ish, how would I setup the ROA with RPKI so that > it would be come valid? You'd go to the RIPE web portal, and create a RPKI ROA like you'd normally do, but instead of inputting your own ASN you input the ASN of the provider that will announce the space on your behalf. You create/have multiple ROAs covering the same prefix but with different Origin ASNs co-exist - this allows you to make-before-break in transitions such as you might be going through at this moment. A variant of the scenario you describe is "BYOIP" in context of the cloud providers. The analogy is that instead of routing your IP space to your office, some cloud providers offer to announce your IP space and route it to your virtual datacenter: https://urldefense.proofpoint.com/v2/url?u=https-3A__aws.amazon.com_vpc_faqs_-23Bring-5FYour-5FOwn-5FIP&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=r6F6zj0eWYSBLwke7RzsjRWmiMDnA48kBc8MtH6LHY4&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__developers.cloudflare.com_spectrum_getting-2Dstarted_byoip_&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=FVQO-bem3vPPgWp_IBnXM0T--YTxtYfdLWLEWXRQPQs&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__cloud.ibm.com_docs_tutorials-3Ftopic-3Dsolution-2Dtutorials-2Dbyoip&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=8REIxiHlVLSmo3TNJ7qNSmgsfGVHpxq5Ttd0mibZ0ww&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__www.zdnet.com_article_google-2Dcloud-2Dnow-2Dlets-2Dyou-2Dbring-2Dyour-2Down-2Dip-2Daddress-2Dto-2Dall-2D20-2Dregions_&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=TdoE7Lfs-p40nmMmMndCui0e-SGGPxEGMxGkvD9N9aQ&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__ideas.digitalocean.com_ideas_DO-2DI-2D566-23-3A-7E-3AtargetText-3DSupport-2520Bring-2520Your-2520Own-2520IP-2520Space-2Ctheir-2520AS-2520to-2520your-2520server&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=TYJoDyr0WewiKRJ3rLvbaA1Y1q2ICKACpeEI7stPDw8&e= . Your IP resources are yours*, and you are free to authorize anyone to route them on your behalf on the public internet. Kind regards, Job * not meaning to start debate about ownership, just wanted to emphasize that whether you do your own BGP or have someone do it on your behalf is the same. _______________________________________________ members-discuss mailing list members-discuss@ripe.net https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ripe.net_mailman_listinfo_members-2Ddiscuss&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=LLJl3WzcTkyuUBaUuRuuAvmBoRj00wIunLBsYcEpE1M&e= Unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ripe.net_mailman_options_members-2Ddiscuss_jason.bothe-2540invesco.com&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=zF-69Zepe30kowdDFJeO2wQGvCB9SrGXxicJii7w6Ug&e= **************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any device. ****************************************************************
Hi Jason, I would try to delete the route object referencing their ASN and then raise a ticket to their NOC/Peering contact (get them via peeringdb if avaiable) on which you tell them they are announcing a prefix without an IRR record and that they should retire it :) Daniel -- Daniel Ponticello Direttore Tecnico e CEO REDDER Telco T: 0444 1783651 | F: 0444 1783652 | daniel.ponticello@redder.it www.redder.it Il 12/11/2019 14:08, Bothe, Jason ha scritto:
If anyone could tell me how to get an ISP to 'un-announce' prefixes on your behalf I will buy them dinner. I have two prefixes of mine that PCCW won't to take down and at this point I have better chances of convincing Donald Trump to resign than I do getting PCCW to remove them from their announcements.
J~
On 11/12/19, 6:48 AM, "members-discuss on behalf of Job Snijders" <members-discuss-bounces@ripe.net on behalf of job@ntt.net> wrote:
Dear Bernd,
Good questions, thanks for bringing them up, this topic indeed doesn't receive much attention.
I can't comment on the specifics of your case in regard to SLA and what the best choices are for your organisation, but I can share one small data point.
On Tue, Nov 12, 2019 at 12:16:53PM +0100, Bernd Naumann wrote: > Then the ISP offered us to announce _our_ prefix for us, from their > ASN, and here I lost trust, and stopped the planning for now to get > either confirmation or an other red flag.
This actually is a common practise!
Speaking from NTT's perspective we see that customer's used to run BGP in the past, but no longer have interest in maintaining that infrastructure and switch to a "Direct Internet Access" (DIA) product which usually is statically routing the IP space and perhaps using a first-hop redundancy protocol. In such cases the customers request NTT to announce the space on their behalf - which we can do provided that a RPKI ROA and IRR route object are created to demonstrate to the world that we in fact are allowed to originate the prefix.
> - Is this even "allowed" or recommend by RIPE policies or BCPs?
yes, this is allowed; and if it adequately addresses the challenges you are trying to solve for your organisation I'd say it is even 'recommended' ;-) - the real answer is "it depends".
> - Wouldn't that be at least looks like a/an BGP hijacking (attempt)?
it would not look like a BGP hijack if RPKI ROAs / IRR "route:/route6:" objects are created in the appropriate places authorising the ASN that originates the prefix.
> - Just in case this is ok-ish, how would I setup the ROA with RPKI so that > it would be come valid?
You'd go to the RIPE web portal, and create a RPKI ROA like you'd normally do, but instead of inputting your own ASN you input the ASN of the provider that will announce the space on your behalf. You create/have multiple ROAs covering the same prefix but with different Origin ASNs co-exist - this allows you to make-before-break in transitions such as you might be going through at this moment.
A variant of the scenario you describe is "BYOIP" in context of the cloud providers. The analogy is that instead of routing your IP space to your office, some cloud providers offer to announce your IP space and route it to your virtual datacenter:
https://urldefense.proofpoint.com/v2/url?u=https-3A__aws.amazon.com_vpc_faqs_-23Bring-5FYour-5FOwn-5FIP&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=r6F6zj0eWYSBLwke7RzsjRWmiMDnA48kBc8MtH6LHY4&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__developers.cloudflare.com_spectrum_getting-2Dstarted_byoip_&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=FVQO-bem3vPPgWp_IBnXM0T--YTxtYfdLWLEWXRQPQs&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__cloud.ibm.com_docs_tutorials-3Ftopic-3Dsolution-2Dtutorials-2Dbyoip&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=8REIxiHlVLSmo3TNJ7qNSmgsfGVHpxq5Ttd0mibZ0ww&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__www.zdnet.com_article_google-2Dcloud-2Dnow-2Dlets-2Dyou-2Dbring-2Dyour-2Down-2Dip-2Daddress-2Dto-2Dall-2D20-2Dregions_&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=TdoE7Lfs-p40nmMmMndCui0e-SGGPxEGMxGkvD9N9aQ&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__ideas.digitalocean.com_ideas_DO-2DI-2D566-23-3A-7E-3AtargetText-3DSupport-2520Bring-2520Your-2520Own-2520IP-2520Space-2Ctheir-2520AS-2520to-2520your-2520server&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=TYJoDyr0WewiKRJ3rLvbaA1Y1q2ICKACpeEI7stPDw8&e= .
Your IP resources are yours*, and you are free to authorize anyone to route them on your behalf on the public internet.
Kind regards,
Job
* not meaning to start debate about ownership, just wanted to emphasize that whether you do your own BGP or have someone do it on your behalf is the same.
_______________________________________________ members-discuss mailing list members-discuss@ripe.net https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ripe.net_mailman_listinfo_members-2Ddiscuss&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=LLJl3WzcTkyuUBaUuRuuAvmBoRj00wIunLBsYcEpE1M&e= Unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ripe.net_mailman_options_members-2Ddiscuss_jason.bothe-2540invesco.com&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=zF-69Zepe30kowdDFJeO2wQGvCB9SrGXxicJii7w6Ug&e=
**************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any device. **************************************************************** _______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/daniel.ponticello%40r...
We have removed the objects and have ROAs with our AS, not theirs. Their peering contacts are my next avenue. J~ On 11/12/19, 7:26 AM, "Daniel Ponticello" <daniel.ponticello@redder.it> wrote: Hi Jason, I would try to delete the route object referencing their ASN and then raise a ticket to their NOC/Peering contact (get them via peeringdb if avaiable) on which you tell them they are announcing a prefix without an IRR record and that they should retire it :) Daniel -- Daniel Ponticello Direttore Tecnico e CEO REDDER Telco T: 0444 1783651 | F: 0444 1783652 | daniel.ponticello@redder.it https://urldefense.proofpoint.com/v2/url?u=http-3A__www.redder.it&d=DwIDaQ&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=djarHFR3gApXUPz0uomMVzynE12UqwLUGSAW200KhuU&s=tgF_Y5nzPrihCdM_rj-3QS3NuNRml6lBx_icFb3Q4PY&e= Il 12/11/2019 14:08, Bothe, Jason ha scritto: > If anyone could tell me how to get an ISP to 'un-announce' prefixes on your behalf I will buy them dinner. I have two prefixes of mine that PCCW won't to take down and at this point I have better chances of convincing Donald Trump to resign than I do getting PCCW to remove them from their announcements. > > J~ > > On 11/12/19, 6:48 AM, "members-discuss on behalf of Job Snijders" <members-discuss-bounces@ripe.net on behalf of job@ntt.net> wrote: > > Dear Bernd, > > Good questions, thanks for bringing them up, this topic indeed doesn't > receive much attention. > > I can't comment on the specifics of your case in regard to SLA and what > the best choices are for your organisation, but I can share one small > data point. > > On Tue, Nov 12, 2019 at 12:16:53PM +0100, Bernd Naumann wrote: > > Then the ISP offered us to announce _our_ prefix for us, from their > > ASN, and here I lost trust, and stopped the planning for now to get > > either confirmation or an other red flag. > > This actually is a common practise! > > Speaking from NTT's perspective we see that customer's used to run BGP > in the past, but no longer have interest in maintaining that > infrastructure and switch to a "Direct Internet Access" (DIA) product > which usually is statically routing the IP space and perhaps using a > first-hop redundancy protocol. In such cases the customers request NTT > to announce the space on their behalf - which we can do provided that a > RPKI ROA and IRR route object are created to demonstrate to the world > that we in fact are allowed to originate the prefix. > > > - Is this even "allowed" or recommend by RIPE policies or BCPs? > > yes, this is allowed; and if it adequately addresses the challenges you > are trying to solve for your organisation I'd say it is even > 'recommended' ;-) - the real answer is "it depends". > > > - Wouldn't that be at least looks like a/an BGP hijacking (attempt)? > > it would not look like a BGP hijack if RPKI ROAs / IRR "route:/route6:" > objects are created in the appropriate places authorising the ASN that > originates the prefix. > > > - Just in case this is ok-ish, how would I setup the ROA with RPKI so that > > it would be come valid? > > You'd go to the RIPE web portal, and create a RPKI ROA like you'd > normally do, but instead of inputting your own ASN you input the ASN of > the provider that will announce the space on your behalf. You > create/have multiple ROAs covering the same prefix but with different > Origin ASNs co-exist - this allows you to make-before-break in > transitions such as you might be going through at this moment. > > A variant of the scenario you describe is "BYOIP" in context of the > cloud providers. The analogy is that instead of routing your IP space to > your office, some cloud providers offer to announce your IP space and > route it to your virtual datacenter: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__aws.amazon.com_vpc_faqs_-23Bring-5FYour-5FOwn-5FIP&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=r6F6zj0eWYSBLwke7RzsjRWmiMDnA48kBc8MtH6LHY4&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__developers.cloudflare.com_spectrum_getting-2Dstarted_byoip_&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=FVQO-bem3vPPgWp_IBnXM0T--YTxtYfdLWLEWXRQPQs&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__cloud.ibm.com_docs_tutorials-3Ftopic-3Dsolution-2Dtutorials-2Dbyoip&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=8REIxiHlVLSmo3TNJ7qNSmgsfGVHpxq5Ttd0mibZ0ww&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.zdnet.com_article_google-2Dcloud-2Dnow-2Dlets-2Dyou-2Dbring-2Dyour-2Down-2Dip-2Daddress-2Dto-2Dall-2D20-2Dregions_&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=TdoE7Lfs-p40nmMmMndCui0e-SGGPxEGMxGkvD9N9aQ&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__ideas.digitalocean.com_ideas_DO-2DI-2D566-23-3A-7E-3AtargetText-3DSupport-2520Bring-2520Your-2520Own-2520IP-2520Space-2Ctheir-2520AS-2520to-2520your-2520server&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=TYJoDyr0WewiKRJ3rLvbaA1Y1q2ICKACpeEI7stPDw8&e= . > > Your IP resources are yours*, and you are free to authorize anyone to > route them on your behalf on the public internet. > > Kind regards, > > Job > > * not meaning to start debate about ownership, just wanted to emphasize > that whether you do your own BGP or have someone do it on your behalf > is the same. > > _______________________________________________ > members-discuss mailing list > members-discuss@ripe.net > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ripe.net_mailman_listinfo_members-2Ddiscuss&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=LLJl3WzcTkyuUBaUuRuuAvmBoRj00wIunLBsYcEpE1M&e= > Unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ripe.net_mailman_options_members-2Ddiscuss_jason.bothe-2540invesco.com&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=zF-69Zepe30kowdDFJeO2wQGvCB9SrGXxicJii7w6Ug&e= > > > > **************************************************************** > Confidentiality Note: The information contained in this > message, and any attachments, may contain confidential > and/or privileged material. It is intended solely for the > person(s) or entity to which it is addressed. Any review, > retransmission, dissemination, or taking of any action in > reliance upon this information by persons or entities other > than the intended recipient(s) is prohibited. If you received > this in error, please contact the sender and delete the > material from any device. > **************************************************************** > _______________________________________________ > members-discuss mailing list > members-discuss@ripe.net > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ripe.net_mailman_listinfo_members-2Ddiscuss&d=DwIDaQ&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=djarHFR3gApXUPz0uomMVzynE12UqwLUGSAW200KhuU&s=qNhfxsLHZwmPoc6_887sj6kcXxtB63qxl4k6R0-SbS8&e= > Unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ripe.net_mailman_options_members-2Ddiscuss_daniel.ponticello-2540redder.it&d=DwIDaQ&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=djarHFR3gApXUPz0uomMVzynE12UqwLUGSAW200KhuU&s=QZJll4LO-cP8KAJp0h062YYYZ56bxlFi5_KCtvaLv98&e= >
Hello, If the IP's are your's, PCCW should definitely not continue to announce them if you tell them not to, perhaps start announcing it from somewhere else and remove any route objects so that from everyone's perspective they are hijacking the IP range, this has happened to us before and we usually just threaten to make the issue public and talk to RIPE and usually it works. On Tue, Nov 12, 2019 at 1:09 PM Bothe, Jason <Jason.Bothe@invesco.com> wrote:
If anyone could tell me how to get an ISP to 'un-announce' prefixes on your behalf I will buy them dinner. I have two prefixes of mine that PCCW won't to take down and at this point I have better chances of convincing Donald Trump to resign than I do getting PCCW to remove them from their announcements.
J~
On 11/12/19, 6:48 AM, "members-discuss on behalf of Job Snijders" < members-discuss-bounces@ripe.net on behalf of job@ntt.net> wrote:
Dear Bernd,
Good questions, thanks for bringing them up, this topic indeed doesn't receive much attention.
I can't comment on the specifics of your case in regard to SLA and what the best choices are for your organisation, but I can share one small data point.
On Tue, Nov 12, 2019 at 12:16:53PM +0100, Bernd Naumann wrote: > Then the ISP offered us to announce _our_ prefix for us, from their > ASN, and here I lost trust, and stopped the planning for now to get > either confirmation or an other red flag.
This actually is a common practise!
Speaking from NTT's perspective we see that customer's used to run BGP in the past, but no longer have interest in maintaining that infrastructure and switch to a "Direct Internet Access" (DIA) product which usually is statically routing the IP space and perhaps using a first-hop redundancy protocol. In such cases the customers request NTT to announce the space on their behalf - which we can do provided that a RPKI ROA and IRR route object are created to demonstrate to the world that we in fact are allowed to originate the prefix.
> - Is this even "allowed" or recommend by RIPE policies or BCPs?
yes, this is allowed; and if it adequately addresses the challenges you are trying to solve for your organisation I'd say it is even 'recommended' ;-) - the real answer is "it depends".
> - Wouldn't that be at least looks like a/an BGP hijacking (attempt)?
it would not look like a BGP hijack if RPKI ROAs / IRR "route:/route6:" objects are created in the appropriate places authorising the ASN that originates the prefix.
> - Just in case this is ok-ish, how would I setup the ROA with RPKI so that > it would be come valid?
You'd go to the RIPE web portal, and create a RPKI ROA like you'd normally do, but instead of inputting your own ASN you input the ASN of the provider that will announce the space on your behalf. You create/have multiple ROAs covering the same prefix but with different Origin ASNs co-exist - this allows you to make-before-break in transitions such as you might be going through at this moment.
A variant of the scenario you describe is "BYOIP" in context of the cloud providers. The analogy is that instead of routing your IP space to your office, some cloud providers offer to announce your IP space and route it to your virtual datacenter:
Your IP resources are yours*, and you are free to authorize anyone to route them on your behalf on the public internet.
Kind regards,
Job
* not meaning to start debate about ownership, just wanted to emphasize that whether you do your own BGP or have someone do it on your behalf is the same.
_______________________________________________ members-discuss mailing list members-discuss@ripe.net
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ripe.net_mailman_listinfo_members-2Ddiscuss&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=LLJl3WzcTkyuUBaUuRuuAvmBoRj00wIunLBsYcEpE1M&e= Unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.ripe.net_mailman_options_members-2Ddiscuss_jason.bothe-2540invesco.com&d=DwICAg&c=MWFkEADu9ctt4KEmLIuwsQ&r=aNH3UFbvNKJFeaKLnEx5sWc0jPyXLBSnLQU0V6pTp1U&m=cngdDIcxq1dCVmEzgJd6Uq2XrWGQdta0BKRKcDWzHe4&s=zF-69Zepe30kowdDFJeO2wQGvCB9SrGXxicJii7w6Ug&e=
**************************************************************** Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any device. **************************************************************** _______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/miao%40epik.com
-- Kind Regards, Marcelo Goncalves Director of Network Operations and President of Sibyl Systems Skype: grumpycatofficial Discord: Miao#0001
Hi everyone! I want to say a huge thank you, to all of you, as I'm quiet overwhelmed by so many replies, also off-list, with so many useful firsthand information. This is really great! Thanks. So I can recap: * Bring your own IP Space is common * Same prefix by multiple AS is common, too [1] * This is covered by RPKI ROA, too And yes, we will definitely ask them on the Layer-3 SLA "bullshit". Maybe this was just a misunderstanding when the information passed down through 3 separated Layer-8s ;) Thanks again! Have a nice day, Bernd [1] Do somehow can pin point me to that section in the RFCs? I probably missed this obvious information!
I have a follow up question, regarding my impression that "it sounds broken (to me)" if more then one AS announces the same prefix as origin: /* I knew I have read it somewhere... Maybe it's just old and dusted and did not survive the turn of the millennium */ https://tools.ietf.org/html/rfc1930#page-8 from 1996
7. One prefix, one origin AS
Generally, a prefix can should belong to only one AS. This is a direct consequence of the fact that at each point in the Internet there can be exactly one routing policy for traffic destined to each prefix. In the case of an prefix which is used in neighbor peering between two ASes, a conscious decision should be made as to which AS this prefix actually resides in. With the introduction of aggregation it should be noted that a prefix may be represented as residing in more than one AS, however, this is very much the exception rather than the rule. This happens when aggregating using the AS_SET attribute in BGP, wherein the concept of origin is lost. In some cases the origin AS is lost altogether if there is a less specific aggregate announcement setting the ATOMIC_AGGREGATE attribute. So in the second paragraph: "this is very much the exception rather than the rule" -- does it just turned around over time? So today/in modern times: The same prefix, or the same specific network/subnet can be originated from more then one AS and things do not break? In this thread it was mentioned that even valid signed ROA can be created for this scenario. But I'm still puzzled if it is only me that validates it, or do both (the ISP and myself) do validate it? Thanks again for your time and help! Bernd
I think that for “belong” it means “originating from one AS at a time”, that is you don't announce the prefix from two AS at the same time, and it is not related to any other relationship (in the irr for istance). That is still the rule IMO, as if there are two origin for the same prefix it technically works fine but it is considered a route leak. WBR, Daniel Inviato dal mio BlackBerry, il dispositivo mobile più sicuro Messaggio originale Da: bena@spreadshirt.net Inviato: 13 novembre 2019 00:50 A: members-discuss@ripe.net Oggetto: Re: [members-discuss] An ISP offers to announce our prefix. Is that normal? I have a follow up question, regarding my impression that "it sounds broken (to me)" if more then one AS announces the same prefix as origin: /* I knew I have read it somewhere... Maybe it's just old and dusted and did not survive the turn of the millennium */ https://tools.ietf.org/html/rfc1930#page-8 from 1996
7. One prefix, one origin AS
Generally, a prefix can should belong to only one AS. This is a direct consequence of the fact that at each point in the Internet there can be exactly one routing policy for traffic destined to each prefix. In the case of an prefix which is used in neighbor peering between two ASes, a conscious decision should be made as to which AS this prefix actually resides in. With the introduction of aggregation it should be noted that a prefix may be represented as residing in more than one AS, however, this is very much the exception rather than the rule. This happens when aggregating using the AS_SET attribute in BGP, wherein the concept of origin is lost. In some cases the origin AS is lost altogether if there is a less specific aggregate announcement setting the ATOMIC_AGGREGATE attribute. So in the second paragraph: "this is very much the exception rather than the rule" -- does it just turned around over time? So today/in modern times: The same prefix, or the same specific network/subnet can be originated from more then one AS and things do not break? In this thread it was mentioned that even valid signed ROA can be created for this scenario. But I'm still puzzled if it is only me that validates it, or do both (the ISP and myself) do validate it? Thanks again for your time and help! Bernd _______________________________________________ members-discuss mailing list members-discuss@ripe.net https://lists.ripe.net/mailman/listinfo/members-discuss Unsubscribe: https://lists.ripe.net/mailman/options/members-discuss/daniel.ponticello%40r...
participants (6)
-
Antonio Prado -
Bernd Naumann -
Bothe, Jason -
Daniel Ponticello -
Job Snijders -
Marcelo Goncalves